wiki:wxTNG/Events

wxTNG: Events Handling

The event handling in wxTNG should satisfy the following criteria, in order of priority:

  1. Type-safety: it should be impossible to connect a handler with a wrong signature. E.g. this:
    void MyHandler(wxWindow *win, wxPaintEvent& event);
    
    EVT_SIZE(MyHandler)
    
    shouldn't compile because size event handler must take wxSizeEvent, not wxPaintEvent.
  2. Flexibility: it should be possible any kind of appropriate handler, not just members of wxEvtHandler-derived classes. E.g. free functions, such as in the example above, should be usable as event handlers. And so should be any callable object with the right signature (this should cover the case of boost::function<void, (wxWindow *, wxEvent&)> too. It should be also possible to connect functions compatible with the event even if there is no exact match, e.g. to connect a function taking just a wxEvent as a handler for wxCommandEvent and wxMouseEvent events.
  3. Pre- and post-event handlers: experience with the current code shows that it's often desirable to connect a handler to be executed after the default handler for an event. Currently this is impossible (especially considering that the default handling can take place inside the underlying low-level toolkit and not in wxWidgets itself at all) and requires ugly workaround using EVT_IDLE. For consistency we should also define separate pre-event handlers, even if this is already possible by defining a normal handler and calling event.Skip() in it -- but this is less explicit than it should be.
  4. Better control over event propagation: we probably should keep the command event propagation to the parent windows, this works well enough in 99% of cases. But we should provide better control over this (for all events). TODO: expand this.
  5. Reuse of existing code: if we can reuse Boost.Signals or another similar library, all the better, there is no need to reinvent the wheel. We do need to pay attention to efficiency (both speed and code size) though.
  6. Efficiency: it would be great to know if there are subscribers for a given event so that we could avoid generating it if there are none. This is especially important for idle events but could be useful for the other ones too.

If anybody has, or knows of, any (even prototype) code capable of doing the above, it would be great to know about it.

Last modified 5 years ago Last modified on 04/13/09 16:16:08