World: r3wp

here is how it works..... I had to stumble upon this within GLASS.


when you add a rate to a face, actually, the timer will trigger 30 
times a second, no matter what your rate is.

do event

will filter the events based on what your rates are set up.

because detect is part of the wake-event system, it gets all the 
events from the input stream, so you end up with all time events.

it was done this way so view can share the same time event among 
many faces, internally.

ok, I see.

It took me quite a while to figure out what I called "Time event 
madness"  ;-)

ok, the "do event" thing? when do I apply that?

that managed within the do-event of wake-events.


the fact that  detect is called, means do event was called.  whenever 
a detect returns false, it consumes the event and subfaces do not 
get their events (even time IIRC).

sorry...  "that managed within the do-event of wake-events"  should 
read

that's managed within view's port wake-event

IIRC the corrected time event is kept by engage, not detect.

exactly.

ok, I've added a delay handler, but it seems a bit wasteful to do 
it this way.

use engage not detect to trap the time event accordingly with the 
rate

and after changing the rate of a face you need to issue immedialty 
a SHOW on the face

hmm...

using detect slow down your app, avoid it if you can

detect should only be used to trap events to sub-faces.   as Steeve 
notes, engage is where you should really be handling the events.

I'm messing around in the detect function for the main window.

aaahhhh lots of "fun" isn't it   ;-P

you might be better of using an input even handler, its faster cause 
it proceeds at the very start of do events... before it starts looking 
at faces within panes.

seems that engage has no effect. so you are not supposed to be able 
to use engage and detect at the same time in the same face?

it depends what you return from detect.  if you return none, it consumes 
the event, if you return the event, then engage is called.

that's how its supposed to work, AFAIK.

I return the event, yet nothing happens. Oh, well, I've studied RebGUI 
code and it does the same thing as I do.

strange.

what are you trying to achieve?

I just want a delay before displaying a tool-tip anywhere in the 
window.

you do know that the window feel is replaced everytime it is viewed?

yes, I take care of that just fine. I've made plenty of modifications 
to the detect function for window already.

ok, just reminding you,  its bitten me in the arse a few times, even 
if I know about it  ;-)

yes, it's not easy, however everything is working as expected, except 
for time events and the use of engage.

its possible the window cannot have time events, no matter its rate. 
 try using a master face in which you put everything, using its feel 
instead.


the window is managed differently than other faces by view... it 
has its own events like resize and stuff, so I wouldn't be surprised 
that its time handling is different.

(I meant, support for time events in its engage)

yes - iirc window does handle time differently and you should always 
use a master face

Posted this in the OSX group, but it's private:


View bug: When getting a timer event in a DETECT feel, event/offset 
is 0x0 in OSX. In Win32 the event/offset during a timer event is 
correct. Can anyone confirm this under Linux?

f: make face [
	size: 200x200
	rate: 2
	offset: 100x100
	color: red
	feel: make system/view/window-feel [
		detect: func [face event] [
			print [event/type event/offset]
			event
		]
	]
]

view f

In View 2.7.7.4.2 in linux, the event/offset is set correctly when 
I mouse over the window.

This is a bit confusing.... I get 'move events on a click, where 
I should get 'down. This occurs inside an insert-event-func function.

yep.  rebol adds some move events when other events are generated. 
 you get them on mouse, window activation, and some others I don't 
remember.


its VERY annoying, though.  I think "do event" consumes some of them, 
but some go through and end-up within feel/engage anyways.

I've been battling these "stray" events for years.  :-(

I used to filter them in my own insert-event-func handlers

found a way to brute force it. not pretty, though...

IMO these 'unwanted' events are generated by the actual OS so I don't 
think we can do anything with this. But for example the 'move events 
on mouse click shouldn't hurt anything because the event/offset is 
still the same so your code should treat them as 'almost no-op'.

Cyphre, I didn't get the 'down event at all, which is what confused 
me.

really? Under WinXP if I do 'mouse click' I'm getting this sequence:
down 58x47
up 58x47
move 58x47

I'm not sure my setup was that simple (it's gone now).

I tested on this code:
insert-event-func f: func [f e][print [e/type e/offset] e]
view layout [box red]
remove-event-func :f

With the above code on Linux I see this:

move 77x78 ; Final move of mouse to a stop, then I wait a short time...
down 77x78 ; <- I click.
up 77x78 ; <- I release, and I wait...
move 77x79 ; I begin moving mouse again.

(That's using View 2.7.6.4.2)

Yes, so it looks windows is adding the 'move event after I release 
the button....seems like no big issue tome though.

If I remember correctly, Windows also inserts a 'move event before 
the 'down, doesn't it?

I don't see that behaviour on my system..only one additional 'move 
after 'up

Ok, probably my poor memory of it then.