World: r3wp

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).

Nevermind, maybe it works after all.

there is no way that I know of to do code after the do events processes 
it, a part from adding oprations in the wake event.  and the detect 
is the first part of that process, the inset event handlers are part 
of the detect phase, as I discovered yesterday.

now I need something else: making a face completely event transparent.

event transparent?

like face/feel: none

I tried that without success.

I will try it again though, just to see if I did something wrong.

Nope, it doesn't work.

the problem, is that some init blocks of some faces might create 
the feel on the fly, so for best effect, append the face/feel: none 
 to the init block.

the window feel, for example is recreated anytime you unview/show 
window.

Well, I've already looked at the feel block for the face after the 
layout is created and shown and it still says none!. If it works 
correctly, it should be possible to click with the mouse through 
that face, shouldn't it?

yes.

I create dynamic faces all the time, which are basically neutralized 
by face/feel none.

if the face is the last one in the window pane, that shouldn't have 
any effect on feel being none, should it?

I'm just trying to create a simple floating rectangle.

no, you are saying the window event does not receive mouse events, 
for example, if the rectangle is within the window?

If I hover it above a text field, I can type text in the field, but 
I can't click on the field to mark up text with the mouse.

do you a small example you can post ?

view layout [at 0x0 field at 0x0 box with [feel: none]]

strange... you've got me puzzeled!!

I'm am sensing a few minutes of lost time ahead  ;-)

well, it seems that the do event handling really is not great.  I've 
tried all I know and it really looks like:

 if a face from a diffrent branch is over another face, it blocks 
 all events to underlying faces.  only child faces can pass events 
 to their parents... this is pretty evil.


You could use Anton's do event simulator lib, and hack it so it allows 
this.  :-(   you'd have to remember that a  face has required/handled 
the event (in its detect) and stop looking amongst further pane branches.

I think I'll do something else, which is pretty clumsy, but I think 
it can work.

Thanks for the help.

Its also possible that Anton, Gabriele or Cyphre have found a trick. 
 I'd be interesed to know in any case, cause this could be a problem 
for me in the future too.

yes, even this fix is rather expensive. one face for each side instead 
of one, but maybe it will speed up redrawing big faces a bit.