World: r3wp

hmm... it's actually only the sequence of events that needs altering. 
as far as I can tell that function only fires one event at a time 
from the event queue.

but the detect and engage function are the same original event.  
engage is sent to see who really wants it and then it is sent the 
engage

ooops   "detect  is sent ..."

but the detect and engage don't originate from the same face?

basically, the detect goes from window, thru all children up to the 
face which generated the even, in order for you to trap the event 
in a parent face.

at that point, the event will not be sent to the child face (if you 
decide to capture it)

so if you need to "consume" an event (for hotkeys for example)  the 
window can detect it and it wont reach the child field.

so the detect is causing the engage to happen?

if parent face captures it , it will allow the engege to happen.

darn...  if = if no

to me it sounds like there is no way to switch them around.

I'm getting Reicharteritis

I'm a little thick on the event system. So I ask many dumb questions. 
:-)

it makes no sense to switch them around, detect basically serves 
to know where to send the events to.

Ok, from the event queue it doesn't make sense, I guess. But from 
what I'm trying to do, I need to do something to a local face _before_ 
something else happens globally.

this whole system is what the do event call in wake-events is for.

ok, in that case you can insert an event handler, which will be run 
before the default one.

there you can trap the events exactly like the wake-event, and do 
what you want before the default event handling happens.

basically, if you return none, the event is consumed and not sent 
to view's default wake-event

if you return the event itself, the next input handler in the chain 
will be fired.

(next event handler being view's default wake-event)

hmm.. basically what I have for detect is sitting now in the window-feel. 
So I could move it out into a separate function and use INSERT-EVENT-FUNC 
on it?

give me a minute, I'll make you an explicit example in rebol code, 
from some source I have here  :-)

it actually takes less text to code it than to explain it.   ;-)

ok, I'll go make a cup of chocolate :-)

rebol []

ctx: context [
	coord: none
	handler: insert-event-func [
		; disable half of the window's events
		if event/offset/x > (event/face/size/x / 2) [
			probe event/offset
			event
		]
	]
]


window: view layout [button "ok"]

note: 

-if returns none when it doesn't match, so that is returned from 
the handler.

-I put the handler within a ctx, just to allow for local vars within 
handler (which I don't use, but figured I'd demonstrate, for all 
to see)

I remind myself, how complicated those few lines would be to implement 
in .net and I continue to say that rebol is still conceptually, if 
not in capacity, better than most solutions out there.

I'm not sure it explains much, as you keep talking about consuming 
events. From what I gather from system/view/screen-face/feel, the 
event functions are just stacked in there and invoked using 'detect, 
which to me appears to be the same as the window-feel.

I.e. they would still be invoked in the reverse order of what I need.

when you run the above, half of the windows events are consumed by 
the new event handler, since we return none on the left side of the 
window.

yes, I can see that.

you could instead trigger a function here, (if proper conditions 
are met) and return event all the time.

so your windows/feel/on-something would happen before it does its 
normal event handling

That's exactly the opposite of what I want. It already does that. 
:-)

but here, if the trigger is met, you can call the do event yourself 
and THEN call your function   :-)  by returning none, the normal 
view handler will then ignore the event (since you've already handled 
it)

I really think I need this painted on a big card board sign, because 
I don't get it. Would the original detect first need to be blocked, 
then the engage would run and then we run the detect again?

working on an exact example  :-D

somehow I can't seem to get the resize events in my window... that 
is strange.

I just realized I had a slightly skewed view of the event ordering, 
but in essence the above still holds.

darn, 8 years of view and I still discover some little tricks and 
details  ;-)

ok for your specific need, the easiest is to hack the wake-event. 
 the insert-event-handler event chain is triggered by of  "do event" 
 handling

hacking the wake-event function?

giving you an example.

rebol []


view*: system/view
; code taken with [probe second get in system/view 'wake-event]
view*/wake-event: func [port ] bind [
    event: pick port 1
    if none? event [

        if debug [print "Event port awoke, but no event was present."]
        return false
    ]
    either pop-face [

        if in pop-face/feel 'pop-detect [event: pop-face/feel/pop-detect 
        pop-face event]
        do event
        found? all [
            pop-face <> pick pop-list length? pop-list
            (pop-face: pick pop-list length? pop-list true)
        ]
    ] [
        do event
        ; OUR HACK >>
        if event/type = 'resize [
        	event/face/feel/after-resize event/face event
        ]
        ; <<
        empty? screen-face/pane
    ]
] in view* 'self

window: view/new/options layout [bt: button "ok" ] [resize]

window/feel: make window/feel [
	after-resize: func [face event ][
		;probe event/type
		;probe "AFTER RESIZE"
		if event/type = 'resize [
			bt/offset/x: face/size/x / 2 - (bt/size/x / 2)
			show bt
		]
		event
	]
]
do-events

note that the actual wake event code comes from the rebol itself, 
you get its code by using:

probe second get in system/view 'wake-event

the change is included between ; OUR HACK >>   <<

does that work for you?

I integrate the scrollwheel within this hack, allowing all faces 
to have an on-scroll  feel.

I'll have to test this later. Thanks. Bedtime now.

happy to help :-)

I've looked at the solution for a bit, and I don't think it's flexible 
enough.


I would rather leave the event handling system untouched and then 
in the window-feel specify that we need to do something after the 
engage. Then there would be another event handler, which handles 
events generated by the original 'detect. Is it possible to generate 
events inside the detect, that can be handled by the window-feel 
after the engage?


The problem would otherwise be that the event needs to be handled 
in every single engage function (dozens).