Programmatically Generating Events

Vadim Zeitlin vadim at wxwidgets.org
Thu Mar 6 09:41:05 PST 2008


On Thu, 6 Mar 2008 07:20:26 -0800 (PST) crjjrc <crjjrc at gmail.com> wrote:

c> It seemed the most succinct way to handle this was to actually
c> generate events for the controls as their state is changed

 Probably not. We don't currently provide any way to uniformly generate
events and it's often, if not always, easier to just extract your event
handling code in your own functions and call them yourself instead of
artificially synthesizing the events.

c> First, there's wxControl::Command(event).

 This one doesn't only generate the event but also changes the controls
state to conform to the information in the provided event object. I find it
rather suspicious and never really understood what was it for.

c> Second, there's ::wxPostEvent(handler, event).  This requires
c> knowledge of the parenting, as far as I can tell.

 This depends on who you want to send the event to... In any case, why is
this a problem -- if you have a window, you have its parent too, don't you?

c> handler->ProcessEvent(evt) is almost identical, but the former
c> asynchronously handles the event, while the latter does so
c> synchronously.  Is this right?

 Yes.

c> And one last question.  When I create a "fake" event, it seems I need
c> to both set the state of the control with Check(), SetSelection(),
c> etc., and call SetInt() on the event.  Is there some way I can get the
c> fake event to automatically assume the state of the control

 No. This could be a useful thing to be able to do though. OTOH it would
promote this entire artificial events generation idea and I'm not sure we
should do it.

 Regards,
VZ

-- 
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/





More information about the wx-users mailing list