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.