World: r3wp

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.

Maxim, do you know how the iterated faces function is used in View? 
I'm stuck in a situation where the index is sometimes returned as 
none.

never mind, I think I got it.

You can't do event-transparent faces. I figured out a huge hack (simulating 
DO EVENT) which was not quite able to go the whole way. :-(

your transparent face can throw back the events to the underllying 
faces, you just have to locate them with the offset of the events, 
i used this trick several times

Can I see a demo of your technique, Steeve?

I wanted transparent events along with transparent regions of a face 
(eg. a face with rounded corners, the events should pass through 
the corner regions, but the rest should land on the face).
It just couldn't be done properly - see my file
http://anton.wildit.net.au/rebol/gui/transparent-events.r

even in R3 Carl use the same trick

Try click on the button at the left and drag to the right.

I want to see code. (But got to go - I'll check back later.)

(My stuff all relates to R2, by the way.)

(and not at all to R3)

Hmm Anton, you can't do like that, you must hack the global event 
handler with insert-event-function

Hmm what you are trying to do anton is tricky, i never did that, 
i always had the transparent area covering the whole unerlying faces.
It was much simple than your use case.

I don't use VID styles as underlying faces but my owns to discard 
the default dispatch of events (no feel object).

But in your case, you'll have to translate all move events comming 
from the global handler into OVER, AWAY events depending of the sub-face.
Lot of work...

Yes, what I tried was a definitive solution. But after working on 
it for a very long time, I found it can't be done completely. (At 
least, I am 99% certain.)

well, it allowed you to build skewed windows, which isn't a small 
feat within windows   :-)

Well, yes, but it still wasn't a complete solution.

Is there a delay with view when working with internal values?


For example if I change the offset of a scroll-panel after showing 
it it reverts to the changed value but if I put a wait of .1 the 
offset viewed remains as expected and does not show the new value.

Am I making sense?

the wait is after show but before the offset value is changed...

the function SHOW, pushes a new show event in the events stack,but 
is not dispatched until your program enter in a wait loop.
So it's normal.

Thanks steeve. I thought I was loosing it..again.

It's the main difference between procedural programming and event-driven 
programming.

When you develop event-driven applications, you must use a different 
flow in your code

Don't exactly get that but I will keep it mind, thanks.

Eheh, you have no choice, when you are programming a visual interface 
with Rebol, it's an event-driven flow