Event redirection within face hierachies
[1/4] from: james:mustard at: 20-Jun-2004 12:15
Hi all, been reading / googling about the event datatype and its elusive
innards ;)
Does anyone (Cyphre?) know if there are plans to let us modify the
insides of events during event trapping? Thinking of things such as
offset redirection and action manipulation here (eg a click somewhere
elicits an alt-click elsewhere)
I have looked at the 'fake' event comments etc from the dev list but on
the whole all it seems we can do is trap and playback.
In the ideal rebol gui world this is what I expect should work:
As an example - a mapping application displaying aerial photographs.
This application uses overlays over the map data for visual cues for the
pilot.
There is a contour overlay and a weather overlay
The pilot needs to be able to view both and plot a course onto a
separate course plan.
This requires the following rebol face structure (ideally)
Main application face
subfaces for:
map
plan screen (acts as a point to point line drawing surface)
contour overlay
weather overlay
control overlay (contains various buttons / scrollbars to handle map
movement, visible layers etc)
As the control overlay is the topmost (active) window it is receiving
the events. If these events are not triggering a subcontrol located on
the control face then these event need to be propagated downwards to the
plan screen for final input to be analysed and acted upon. If the pilot
clicks in the control overlay this plots a point on the map - clicking
and holding the mouse down will draw a dynamic line which will get
placed once an up event is received.
Is this possible now? Am I missing something? Remember that the
control overlay face has to do pre-processing of events to determine if
a control needs to be pressed or if the event should be redirected to
the plan face..
Regards,
James.
[2/4] from: carl:cybercraft at: 20-Jun-2004 19:35
Not sure quite what you mean, but does DETECT do what you want? From here...
http://www.rebol.com/how-to/feel.html#sect6.
6. The Detect Feel
The DETECT function is similar to ENGAGE, but has the ability
to intercept events for all of its subfaces. DETECT can be used
to process special events such as keyboard input, timers, or
mouse events.
The DETECT function works as an event filter. When an event
occurs, DETECT can decide how to handle the event. When it is
done, the function can allow the event to continue to lower
level faces, or stop it immediately.
I think that how-to is the best docs on FEEL RT has made available so far, so probably
of a lot of use to you if you haven't already seen them.
-- Carl Read
[3/4] from: james::mustard::co::nz at: 20-Jun-2004 23:11
Thanks Carl & Brett for your feedback :)
The scenario i mentioned was just an example - I should have been a
little more explicit in the details :)
Inside the detect function I would like write access to the following
(currently these are read only):
detect: func [face event][
event/offset: new-xy-pair
event/face: new-top-level-face
;rface: my-remote-face-which-wants-this-event-for-subface-processing
rface/feel/detect rface event
]
The following code will fail with path unknown etc. As will
event/1,event/2 etc assignment.
As Volker / Cyphre etc have mentioned it would be nice if we could
actually modify these events on the fly - its a very rebol sort of idea ;)
Regards,
James.
Carl Read wrote:
[4/4] from: antonr:lexicon at: 21-Jun-2004 1:18
Try out this simple redirection:
view layout [
b: button "hello"
button "there" feel [
engage: func [face action event][
b/feel/engage b event/type event
]
]
]
And here is a little doc I made (and will put on my rebsite later):
Event datatype breakdown:
event/1 event/type
event/2 event/key
event/3 event/offset
event/4 event/time
event/5 event/shift
event/6 event/control
event/7 event/face
event/8 event/double-click
You can spoof or emulate an event! by creating a
block and putting the relevent data in the correct
positions, eg.
my-event: reduce ['down none 20x20 now/time/precise none none face none]
Most view functions won't know the difference because
they don't check to see if it's really an event datatype.
Here's a way that should respond to both the "indexed"
access method (ie. event/3) and the "named select" access method
ie. (event/offset):
event: reduce [none none 30x30 none none none none none 'offset 30x30]
This block has all the 8 values in the first 8 positions, and following
that, a name/value pair [offset 30x30].
If a function expecting an event! gets the above block instead,
it may get the offset through the path:
event/3
or via the path:
event/offset
Anton.