World: r3wp

And is there a simple way to add mouse-wheel support to a text-list?

In 1.3 text-list style has an 'update function to do so.

For mouse-wheel it still tricky as the event is only send to the 
window feel/detect function, and not at the face level.

(bad english today, sorry)

/update doesn't work for me WRT to slider positioning.

I'm doing something like this:

	list/data: make block! []

	<do-something-on list/data>

	sort list/data
	show list/update

Update should work if there is no item selected. If there is one 
it try to position it at the top (what I dislike)

I have done some work on it for the word-browser. Just look the code 
(desktop\rebol.com\tools\word-browser) :

- There is a patch to the resize function (maybe you can use it to 
refresh the list to the same size?) line 65

- There is a scroll-text-list func (line 414) that is called by the 
window/feel (line 381) for the mouse-wheel

Have also a look at line 259 : it's what is done to refresh the words 
text-list when you select a different category.

Thanks, I take a look.

Janeks, read-thru is using WAIT, so you get other events while inside 
read-thru

Why FEEL actions (down, up, avay events) behaviour changes when I 
changed LOAD  for a face image to READ-THRU or LOAD-THRU?

Thanks, Gabriele!
So what is the trick, to manage all other events?

It seems, that I had somewhere read about it but now I can't remeber. 
Could you, please, point me to the right direction!

O'k me gone Googling ...

Mmm.. WAIT always starts the View event system and handles events. 
Perhaps this automatic feature of WAIT is not so desirable . Anybody 
else agree with me ? What's your opinion, Gabriele ?

Maybe an /ONLY refinement should be added to wait only for the items 
specified (not automatically including View events).

Microsoft's Sparkle: Is It a Flash *cough* view *cough* Killer?  
http://www.eweek.com/article2/0,1895,1914903,00.asp

Anton: one workaround is to clear the wait-list. Janeks: the behavior 
is not changing, it's just that LOAD blocks your feels, while READ-THRU 
does not block them. this is probably creating problems in your script, 
hard to say exactly what without looking at the source.

to clear the wait-list

 - This works AFAIK because event-port is a normal port and thus in 
 the wait-list. Everything there is processed on wait. 


So you could remove only this port temporary. Other tricks with that 
behavior: with read-thru rebservices/beer would still be active while 
downloading. maybe a bit less responsive, because a /no-wait introduces 
little delays?   

And you can caugh events before everything else, like this:

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.