World: r3wp

and I am sure it has been the source of many dumbfounded looks for 
many of us in the past!

Maxim - isn't that a known fact? But for those things, talk to Cyphre, 
he has some experience there iirc.

it might be known.. but its not obvious or common... I was simply 
stating it here, for those who might not be aware.

Maxim: this is a known fact. I think it is better to have full control 
on timer than not be able to have backgound timers running.

Here is an example of proper timer handling:

view l: layout [
	b: box red with [
		rate: 1
		feel: make feel [
			engage: func [f a e][
				if e/time [
					print ["tick" now/time]
				]
			]
		]
	]
	button "hide" [
		print "hide"
		hide b
	]
	button "show" [
		print "show"
		show b
	]
	button "remove" [
		print "remove"
		if face: find l/pane b [hide face/1 remove face show l]
	]
	button "add" [
		unless find l/pane b [
			print "add"
			append l/pane b
			b/show?: true
			show l
		]
	]
]

its just that I am working with a multi-pane application which have 
timers and (obviously) we only want to refresh what is actually withing 
windows... what happens is that eventually, all the panes start kicking 
out timers!  (and I need the time event to be local to the actual 
face to relate its animation ... otherwise, I'd cross the animation 
from one pane to another ! :-)

so I just added a little bit of "stop timer" handling on top of the 
"show pane" handling.. it works.. its just not obvious that an invisible 
pane (actually not within a window's pane structure) can still receive 
events. 


 I agree that the feature IS usefull.  maybe it should be more obviously 
 documented (next to the note in the docs that a show is required) 
 that timers trigger even if faces are hidden and event if not actually 
 displayed...

I didn't think it would be so much effort to implement a "simple" 
menu.

do http://anton.wildit.net.au/rebol/gui/demo-menu.r

Menues have so many little features in them... With this one I made 
a decision to severely limit the layout possibilities. It's a "standard" 
menu based on the one I can see in Crimson Editor here on XP.

I get this:

connecting to: www.lexicon.net

Include: Couldn't load-thru http://www.lexicon.net/antonr/rebol/gui/menu.r
** Script Error: menu-style has no value
** Where: do-facets
** Near: menu-style

he's not at lexicon.net anymore ... must be old cold

code

a domain costs US$5/year ... sometimes it's worth it!!

I'm with you, Graham.

Chris had same trouble. Problem is at rebol.net. I think since the 
server crash, the Sites rebsite index reverted to an old one. I also 
can't update it at the moment because the cgi updater hasn't been 
restored yet either.

This fixes the rebsite index temporarily:

; Needed until rebol.net Sites rebsite index is updateable and updated.
old: as-string read-thru http://www.rebol.net/reb/index.r

replace (new: copy old) "www.lexicon.net/antonr" "anton.wildit.net.au"
write/binary path-thru http://www.rebol.net/reb/index.rnew

Now try again.

do http://anton.wildit.net.au/rebol/gui/demo-menu.r

Same error here.

Gregg, did you try the above fix ?

I've also just updated the menu with today's improvements, by the 
way.

Not yet. Have to run and watch my daughter open presents right now. 
She's 12 today.

Ah ok.

The fix worked for me...

Very good.

I've just updated the menu with a backwards compatibility fix so 
it can also work on View 1.3.2.

load-thru/update http://anton.wildit.net.au/rebol/gui/menu.r
do http://anton.wildit.net.au/rebol/gui/demo-menu.r

I use do-service to issue a RS request. But it's not blocking my 
GUI. I want to keep the user away from clicking around.  How can 
I block the processing of GUI events?

Interesting, the doc string for do-service in my 19-Nov-2005 copy 
says {Send request to a REBOL service and wait for response. Return 
result.}

I suppose you could remove the event-port from the wait-list temporarily, 
until you get a result or a timeout occurs. (how to specify a timeout... 
?)

yes how to specify a time-out..i have that to here in another issue.. 
not so easy actualy when not having threads..

do-service calls wait-service, which has a default timeout of 60 
seconds.

so all you should need to do to block the gui is remove the event 
port.

eg.
remove system/ports/wait-list system/view/event-port

do-service ...  ; <-- trap errors here so you don't block your gui 
forever
insert system/ports/wait-list system/view/event-port

Thansk, will try this.

I have the feeling that wild mouse-clicks be qued? Can I remove those 
too?

Hmmm... maybe CLEAR event-port ? Or just COPY it until it's empty 
before adding it back to wait-list.

I experimented quickly and this seems to work.

view layout [
	button "reset" [n: 0]
	button "read" [
		;remove find system/ports/wait-list system/view/event-port
		
		old-wake-event: get in system/view 'wake-event
		
		system/view/wake-event: func [port][
			while [pick port 1][] ; remove and ignore all queued events
			false
		]
		
		print n: n + 1
		probe length? read http://anton.wildit.net.au/rebol/index.html
		
		; clean queued events
		wait 0.0001
		
		system/view/wake-event: :old-wake-event
		
		;insert system/ports/wait-list system/view/event-port
	]
]

The READ + WAIT should be roughly equivalent to DO-SERVICE in your 
case.

(And you can see I commented out my first suggestion, it didn't seem 
to be enough.)

Mmm.. maybe it's good to keep the temporary removal of the event-port.
I did a little more experimenting and doc here:
http://anton.wildit.net.au/rebol/doc/clearing-queued-events.txt

Thx. I take a look at keep trying.

How can I avoid the console coming up, when using CALL?

I use async-call from Doc but it fails with: CreatProcess failed!

I try to launch a PDF by just providing the PDF filename.

Is there a native request-directory funciton available?