World: r3wp

do/args http://polly.rebol.it/test/test/scratch/simcon.r[
probe event-port
# length? system/ports/wait-list
# same? first system/ports/wait-list system/view/event-port
# get in system/view/event-port 'awake
# probe we: get in system/view 'wake-event
# insert second :we [prin "*"] 
# view layout[area] none
]

So I made modified function to:

loadMapImg: func [
	mapUrl
	/local rezImg tmpWl
][
	if exists? %mapImg.gif [ delete %mapImg.gif ]
	either attempt [
		tmpWl: copy system/ports/wait-list
		clear system/ports/wait-list
		rezImg: load-thru/to mapUrl %mapImg.gif
;		rezImg: load mapUrl	
	][
		system/ports/wait-list: tmpWl
		return load %mapImg.gif
;		return rezImg
	][
		return none
	]
]

It works for me! Thanks!
Is it correct?

I looked into system/ports/wait-list - there is a lot variables and 
awake function.
For what else wait-list is good?

All ports there are automatically active on 'wait.

for other ports you have to wait[port1 port2 ..]. Ports in wait-list 
are automatically "added".

looking into - yes, prboing ports is long. i suggest using some visual 
tool like anamonitor.

Are there any docs available about wait-list on the net?

So I mean a bit detailed docs about wait-list system ...

Got my knowledge by source/ML/chatting. I guess google finds some 
ML. Maybe there are more "real" docs somewhere.

Sorry, what is "source/ML/chatting"?

looking inside rebol with 'source etc, mailing-list, altme/ios.

Hmm, both anamonitor and roam can not dump that port.

So what exacly is wait-list? 
It is block of what?
Where can I see all those active ports?

yes, a block. with ports in it.
 echo on probe system/ports/wait-list
then look in %rebol-echo.txt with an editor.

The same I can see with just probe.
O'k I see now - in this case it is just one 'EVENT port!

thats true. but its big. in an editor you have find, matching parens 
and such. thats why i use echo.

other ports you have to put in yourself.

i guess a search for "awake rebol" would turn something up.

maybe something like this: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlGKXQ

Yep.

Now I just trying to better understand, how it all works. I have 
some feelings and now my script works like expected.
I hope my method is correct.
Now I want to make working progess bar by using read-thru.
But now it is quite late - I am gonna to sleep.
Thanks Volker for your advice!

goodnight Janeks :)

Gabriele, that is good! I had completely forgotten about this, but 
now I remember it was mentioned before. You have to use it yourself 
to remember it well...

Now the question is about progress face. I dumped my progress face 
and see there also text atribute. But 
code 
		mapDwnlProgr/text: "Test"
		show mapDwnlProgr
does nothing.
So for what is used text atribute in progress face?

You cannot see the text attribute, unfortunately, because it is covered 
by a subface, the blue progress amount.

If we set the font color to white and move the subface a little bit 
we can see the text.

view layout [progress 200x50 "hello there" font-color white with 
[data: 0.6 append init [pane/offset: size / 5]]]

Mmm, you could do it like this:

view layout [progress 200x50 "hello there" font-color white with 
[data: 0.6 append init [pane/offset: size / 6 pane/effect: [merge 
alphamul 128]]]]

But the text is still partly obscured by the blue progress.

I wrote my own progress style to overcome some of the default's limitations.

I used one face and used the draw dialect to draw the blue progress 
amount. It should be more efficient because it only uses one face.

(and face/text is rendered over the top of draw dialect graphics).

do http://www.lexicon.net/antonr/rebol/gui/demo-percent-progress.r

There was some work on a progress in "RebGUI" group arround 24-nov-2005.


For those who don't like setting Altme message limit too high (sync 
bug) there is :
http://membres.lycos.fr/didec/rebol/altme-chat-reader.r
Save it to your %Altme\ folder for easier use.

Thanks, Anton and DideC!

It seems, that there could be make very interesting progress indicators 
by the Rebol.

In this case I made it in simplest way - just put over progress one 
of text styles.

HKEY_CURRENT_USER\Software\Rebol\View\Home = d:\anton\dev\rebol\view

HKEY_CURRENT_USER\Software\Rebol\View\Sandbox =d:\anton\dev\rebol\view

Sandbox goes into view-root, if I recall correctly.

I set them to the same path to get the "traditional" rebol behaviour, 
public cache under the same program directory.

where is user.r being looked for by default?

In view-root, I believe. But you can just try experimenting with 
the two paths to see what happens.

Also check system/options/home and system/options/boot

well, exactly ... that is a mess however ...

now print this, send this to novice user, he will be disgusted. We 
forgot things should be simple ....

Not as bad as you think. It's quite simple, really. I just can't 
remember exactly, so I'm not being precise right now.

not as simple, as what happens if you have user.r in your .exe placement 
dir - will it be used instead of the one placed in the cache?

user.r is not used in the cache. Public cache is determined from 
view-root but that does not mean it *is* view-root.

public cache is at view-root/public/

PATH-THRU defines where the public cache is:
>> ?? path-thru
path-thru: func [
    "Return a path relative to the disk cache."
    url /local purl
][
    if file? url [return url]
    if not all [purl: decode-url url purl/host] [return none]

    rejoin [view-root/public slash purl/host slash any [purl/path ""] 
    any [purl/target ""]]
]

I also don't believe RT fixed installation process, if it can ever 
be fixed. You install for one user, then for another, that is ok. 
Now one of them tries to uninstall. The icon in "control panel/uninstall 
sw" will be removed, so you can't clean the system from the cache 
of the secondary user ...

There you see "view-root/public". This is the basis for all the public 
cache functions, LOAD-THRU, READ-THRU, EXISTS-THRU? etc.