Programmatically Generating Events

crjjrc crjjrc at gmail.com
Thu Mar 6 07:20:26 PST 2008


Hi.  I'm a little confused on how to best tackle an event-handling
problem.  My application reads in an XML configuration file that sets
various options that users can normally set by manipulating controls.
It seemed the most succinct way to handle this was to actually
generate events for the controls as their state is changed so that the
same code that handles user interaction with the controls can handle
the configuration setup.

Since the config file is manipulating the controls programmatically, I
need to generate the events myself.  There seem to be several ways to
do this, and I don't understand the differences very well.

First, there's wxControl::Command(event).  This seems to be a good way
of generating the events, since I need no prior knowledge of how the
controls are event-parented.  The control itself will pass the event
where it needs to go to.  Is the event generated and handled
immediately for this method?  This method seems to be the one I want,
but it cannot be used with menus since they don't derive from
wxControl.  Is there a better alternative for triggering menu events?

Second, there's ::wxPostEvent(handler, event).  This requires
knowledge of the parenting, as far as I can tell.  handler-
>ProcessEvent(evt) is almost identical, but the former asynchronously
handles the event, while the latter does so synchronously.  Is this
right?  This seems to be able to handle menu events.

And one last question.  When I create a "fake" event, it seems I need
to both set the state of the control with Check(), SetSelection(),
etc., and call SetInt() on the event.  Is there some way I can get the
fake event to automatically assume the state of the control, i.e., so
that I don't have to call SetInt() and duplicate the effort of
reflecting the control's state?  Furthermore, SetInt() seems to be a
catchall for representing the selection in a wxChoice control,
checkedness for a checkbox, and selection in a radio box, and I'm
concerned that this very underspecified method may change the way it
maps the integer to selection/check/etc.

I'm aware of the UpdateUI events that could allow me to not have to
set the state of the controls directly, but I don't really want the
update code running periodically.  Also, accelerators don't get
reenabled for menu items that are ready to be enabled.  The items are
not enabled until the update events are triggered for the menu, which
is either on the display of the menu or on a call to
wxWindow::UpdateWindowUI().  Having to call UpdateWindowUI() seems to
defeat the purpose of automatic updating, so I'd rather avoid doing
this.

If you're able to clear up or comment on any of questions above, I'd
be grateful.

- Chris






More information about the wx-users mailing list