While working on wxruby-swig today, I added support for
EvtHandler#connect. This allows you to hook any event type and id range
to a method. Theoretically, this would allow you to work with event
types that are not yet supported by the wxruby(-swig) framework.
However, the event that gets passed to the ruby event handler may not be
very helpful. It can only be an event class that wxRuby already knows
about. If the event type is unknown (that is, if wxRuby hasn''t already
been coded to handle it), then the event object will be of type
Wx::Event, and only those few methods will be available.
So I''m not sure it''s really worth adding this feature to
wxruby. I''ll
leave it in wxruby-swig, in case it is useful for something. But I think
our effort is better spent actually adding support for new event types,
rather than adding connect support to the existing wxruby code.
This pointed out a weakness of the wxruby-swig event callback code: it
determined the event class to be used too early in the process. That
works for any call like evt_menu, where the class is known. I changed it
to figure out the class type within the callback, like the old wxruby
code did.
I have tagged the wxruby-swig tree (at rubyforge) as 0.0.17.
Kevin
