Programmatically Generating Events

[crjjrc]

On Mar 6, 11:41 am, va... at wxwidgets.org (Vadim Zeitlin) wrote:
> On Thu, 6 Mar 2008 07:20:26 -0800 (PST) crjjrc <crj... 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.

This method creates a bunch of functions that can be called
independent of interface.  This might be nice, but I still need to
update the interface if these functions get called.  I can't do the
update in these functions without superfluously setting the state of
the controls if these functions are also called on interface changes.

> 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.

This isn't the behavior I observe on GTK.  That is,

   wxCommandEvent fake_event(wxEVT_COMMAND_CHECKBOX_CLICKED,
ID_MYCHECK);
   fake_event.SetInt((int) true);
   frame->my_check->Command(fake_event);

does not check the the checkbox.

> 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?

I see.  I didn't realize I could just post the event to the widget
that "invoked" the event.  The widget's event handler will propagate
it accordingly.  I thought I had to call this on the event-parent
myself.

> 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.

The Command method as you describe above is very close to this idea
(though I don't see it working as you describe).  Either the event
takes on the state of the control, or the control takes on the state
of the event.  I wish I knew a more elegant and concise construct for
managing state, 'cuz this seems to be a common problem.

Thanks for your input.

- Chris