World: r3wp

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.

but in both cases it shouldn't be a problem IMO. Those events just 
goes thru your handler without any real action and doesn't look like 
a performance hit at all.

By the way, the "no" real handling of rate in window detect  that 
Maxim let me understand why I was unable to slow down the "Splascreen" 
demo as it use the window feel, not a face feel.

...that Maxim point of ...

is there any known way to make rebol spontaneously quit? I've run 
into a case where it just quits, when I focus a field in the VID 
Extension Kit, but I have no clue what does it, although I can reproduce 
it every time.

under OSX a segfault is produced.

using the variable name 'Q  ...  honestly, it's happened to me.

nope, this one really just quits. I've reassigned Q, QUIT, UNVIEW, 
everything.

I remember I have seen that in some recursion/stack overflow cases 
but just guessing here.

some AGG blocks crash ... are you using AGG?

no AGG

are you using a popup?

Cyphre, it's possible there is some recursion problem.

Maxim, no a VIEW window

very strange. especially on a focus event.

this is one case of this 'feature':
a: does [if error? try [a][a]]

are you using 'WAIT [ ] manually somewhere?

maxim, not that I know of.

Cyphre, ok nice to know.

did you check ram use?

less than 10 megs. it happens very quickly.

Henrik, I bet you are calling FOCUS recursively or something like 
that.

it's possible

a print object statement can also cause the interpreter to bust its 
stack.

I think I figured it out... I have created a pane of faces manually 
where one is focused. Then I decide to remove that pane and build 
a new one, and then focus a new face in that new pane. But my focus 
calls unfocus first and wants to perform a focal-face on a face that 
doesn't belong anywhere => crash.

wants to perform a SHOW on a focal-face

Shouldn't this be catched by the GC?

IMO Looks more like a View(text related) bug.

well, the face that SHOW is trying to show remains in memory, possibly 
with a reference to a parent-face that no longer exists. what exactly 
makes SHOW go boom, I'm not sure.

fix is done by unfocusing before destroying the pane. interesting 
bug.