[Fxruby-users] changing overall behavior - was (re: [Foxgui-users]making fox a superior toolkit)

[Recheis M. <Mei...@av...>]

hi lyle,

i have asked you several times about this(changing the behavior of a =
widget) but it seems that you have misunderstood me or i have =
misunderstood you, or both.

what about this "first chance callbacks" jeroen talks about (see his =
post below)?
i would like to know whether these can be used in FXRuby too.

you once said (in other words for you, if i got you right):=20
> fox widgets catch events react and then block them.
> so it is not possible to overwrite the default behavior for these =
events.

it seems possible to override the default behavior in C++. A possibility =
that arises from that: you could=20
override the default behavior of all widgets (for right mouse click, for =
instance)
this would be very useful to me. but it's not useful if i cannot pop up =
a menu on every widget (using right click).

hope you know what i am trying to say, and excuse for my bad english.
regards,
- Henon


jeroen wrote (on the Foxgui_users ML):
[snip]
> - giving the user a possibility to change the default behavior of =
widgets
> (this is very frustrating to ruby programmers, because we can simply
> overwrite behavior in base classes. but in fox, if i overwrite
> onLeftButtonPress in FXWindow to get the same behavior for any widget =
in
> the toolkit doesn't work with FXRuby. Don't know whether this is =
possible
> somehow in C++)

Most widgets bounce a "first chance callback" to their target (i.e. =
*your*
code), so that your own handler may override the normal widget =
translation.
You can do this without subclassing the C++ class so (and I have to =
defer
to Lyle here) if FXRuby allows for the handler to be caught you may =
actually
be able to do quite a bit of 'behaviour modification".

For example, if you press, move, release the left mouse button in some
widget then these messages are bounced of the widget's target first; if
the target's message handler returns 0, the translation of the messages
proceeds according to the widget's own internal logic.  However if the
target's handlers return 1 then the widget doesn't "see" these events
and your message handlers are basically in charge.

While you do need to be fairly familiar with the toolkit to use this
productively, it is certainly very nice to be able to do this as it
won't involve subclassing the widget (which, working form Ruby, you
are not able to do so easily).
[snip]