Event table execution order

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Event table execution order

Andreas Falkenhahn
Hi,

could somebody explain to me why I have to invert the event order when manually
connecting them using Connect()? Consider the following event table:

BEGIN_EVENT_TABLE(MyFrame, wxFrame)  
    EVT_RADIOBOX(RadioPage_Radio, MyFrame::OnRadioBox)
    EVT_RADIOBOX(wxID_ANY, MyFrame::OnCheckOrRadioBox)  
END_EVENT_TABLE()

The MyFrame::OnRadioBox() consumes the event, i.e. doesn't skip it, so that
OnCheckOrRadioBox() is not called in case the user hits the wxRadioBox with
the id RadioPage_Radio.

Now when I rewrite this event table to use Connect() instead, I'd assume that
it has to look like the following:

Connect(RadioPage_Radio, wxEVT_COMMAND_RADIOBOX_SELECTED, wxCommandEventHandler(MyFrame::OnRadioBox));
Connect(wxID_ANY, wxEVT_COMMAND_RADIOBOX_SELECTED, wxCommandEventHandler(MyFrame::OnCheckOrRadioBox));  

However, it doesn't. With the code above, OnCheckOrRadioBox() will now be called
even if the user clicks the wxRadioBox with the id RadioPage_Radio. In order
to achieve the same behaviour as with the event table, I have to change the
order and do a:

Connect(wxID_ANY, wxEVT_COMMAND_RADIOBOX_SELECTED, wxCommandEventHandler(MyFrame::OnCheckOrRadioBox));
Connect(RadioPage_Radio, wxEVT_COMMAND_RADIOBOX_SELECTED, wxCommandEventHandler(MyFrame::OnRadioBox));
 
Then it will work exactly as with the event table above. But I don't understand
why this is and thus would be glad if somebody could provide some explanation
on this. Thanks!

--
Best regards,
 Andreas Falkenhahn                          mailto:[hidden email]

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: Event table execution order

Vadim Zeitlin-4
On Fri, 22 Nov 2013 18:46:39 +0100 Andreas Falkenhahn wrote:

AF> could somebody explain to me why I have to invert the event order when manually
AF> connecting them using Connect()?

 The information from the event table macros is stored in a fixed size
array and is looked up from the beginning. The handlers connected using
Connect() or Bind() are stored in a linked list and the new ones are
appended in the front of it. Now I don't know if it's an implementation
detail or a guarantee of the API. When in doubt, I'd rather avoid relying
on any particular order and just have a single OnRadioBox() handler and
check the value of the ID inside it.

 Regards,
VZ

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

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Event table execution order

Andreas Falkenhahn
On 23.11.2013 at 00:53 Vadim Zeitlin wrote:

> On Fri, 22 Nov 2013 18:46:39 +0100 Andreas Falkenhahn wrote:

AF>> could somebody explain to me why I have to invert the event order when manually
AF>> connecting them using Connect()?

>  The information from the event table macros is stored in a fixed size
> array and is looked up from the beginning. The handlers connected using
> Connect() or Bind() are stored in a linked list and the new ones are
> appended in the front of it. Now I don't know if it's an implementation
> detail or a guarantee of the API. When in doubt, I'd rather avoid relying
> on any particular order and just have a single OnRadioBox() handler and
> check the value of the ID inside it.

Ok. By the way, the code was once again taken from official wxWidgets
example code which AFAICS was actually written by you :) At least the
header says so:

/////////////////////////////////////////////////////////////////////////////
// Program:     wxWidgets Widgets Sample
// Name:        radiobox.cpp
// Purpose:     Part of the widgets sample showing wxRadioBox
// Author:      Vadim Zeitlin
// Created:     15.04.01
// Id:          $Id: radiobox.cpp,v 1.17 2005/08/28 08:54:54 MBN Exp $
// Copyright:   (c) 2001 Vadim Zeitlin
// License:     wxWindows license
/////////////////////////////////////////////////////////////////////////////

So if there's no guarantee on the callback execution order in event tables
this sample code should probably be changed as it depends on OnRadioBox() being
called before OnCheckOrRadioBox().

--
Best regards,
 Andreas Falkenhahn                            mailto:[hidden email]

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[2]: Event table execution order

Vadim Zeitlin-4
On Sat, 23 Nov 2013 12:08:40 +0100 Andreas Falkenhahn wrote:

AF> On 23.11.2013 at 00:53 Vadim Zeitlin wrote:
AF>
AF> > On Fri, 22 Nov 2013 18:46:39 +0100 Andreas Falkenhahn wrote:
AF>
AF> AF>> could somebody explain to me why I have to invert the event order when manually
AF> AF>> connecting them using Connect()?
AF>
AF> >  The information from the event table macros is stored in a fixed size
AF> > array and is looked up from the beginning. The handlers connected using
AF> > Connect() or Bind() are stored in a linked list and the new ones are
AF> > appended in the front of it. Now I don't know if it's an implementation
AF> > detail or a guarantee of the API. When in doubt, I'd rather avoid relying
AF> > on any particular order and just have a single OnRadioBox() handler and
AF> > check the value of the ID inside it.
AF>
AF> Ok. By the way, the code was once again taken from official wxWidgets
AF> example code which AFAICS was actually written by you :)

 Hmm, yes. The code probably came into existence by copying another of the
files in samples/widgets as they all react to check/radio boxes presses in
about the same way, and then nobody bothered to adapt it to the specific
case of this page where the main control is a radio box too.

 I won't change this code now because it's not that obvious to do it, and
it does work correctly with the current implementation. But I'm still
unsure whether we should document the current behaviour, and thus promise
not to change it in the future, or not...

 Regards,
VZ

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

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: Event table execution order

Stefan Csomor
Hi

>AF> AF>> could somebody explain to me why I have to invert the event
>order when manually
>AF> AF>> connecting them using Connect()?
>AF>
>AF> >  The information from the event table macros is stored in a fixed
>size
>AF> > array and is looked up from the beginning. The handlers connected
>using
>AF> > Connect() or Bind() are stored in a linked list and the new ones are
>AF> > appended in the front of it. Now I don't know if it's an
>implementation
>AF> > detail or a guarantee of the API. W

> I won't change this code now because it's not that obvious to do it, and
>it does work correctly with the current implementation. But I'm still
>unsure whether we should document the current behaviour, and thus promise
>not to change it in the future, or not...

Im not sure whether I misunderstand your doubts, but Connect IMHO must
follow a documented contract, to me using Connect was always like pushing
the handler onto the stack, so that an event handler pushed later will be
used first. I also thought that I had read that long time ago somewhere in
the docs.

Best,

Stefan

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: Event table execution order

Andreas Falkenhahn
On 24.11.2013 at 09:10 Stefan Csomor wrote:

>> I won't change this code now because it's not that obvious to do it, and
>>it does work correctly with the current implementation. But I'm still
>>unsure whether we should document the current behaviour, and thus promise
>>not to change it in the future, or not...

> Im not sure whether I misunderstand your doubts, but Connect IMHO must
> follow a documented contract

+1

--
Best regards,
 Andreas Falkenhahn                            mailto:[hidden email]

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[4]: Event table execution order

Vadim Zeitlin-4
In reply to this post by Stefan Csomor
On Sun, 24 Nov 2013 08:10:43 +0000 Stefan Csomor wrote:

SC> Im not sure whether I misunderstand your doubts, but Connect IMHO must
SC> follow a documented contract, to me using Connect was always like pushing
SC> the handler onto the stack, so that an event handler pushed later will be
SC> used first.

 Yes, this does make sense, but the problem is that it's almost exactly the
converse of how the static tables work.

SC> I also thought that I had read that long time ago somewhere in the
SC> docs.

 I couldn't find this anywhere so I've just documented this in r75285.

 Thanks for chiming in,
VZ

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

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Event table execution order

Robin Dunn
In reply to this post by Vadim Zeitlin-4
Vadim Zeitlin wrote:

> On Fri, 22 Nov 2013 18:46:39 +0100 Andreas Falkenhahn wrote:
>
> AF>  could somebody explain to me why I have to invert the event order when manually
> AF>  connecting them using Connect()?
>
>   The information from the event table macros is stored in a fixed size
> array and is looked up from the beginning. The handlers connected using
> Connect() or Bind() are stored in a linked list and the new ones are
> appended in the front of it. Now I don't know if it's an implementation
> detail or a guarantee of the API. When in doubt, I'd rather avoid relying
> on any particular order and just have a single OnRadioBox() handler and
> check the value of the ID inside it.

I think the order is important for other language bindings, at least for
wxPython, and that we should probably make it official.  I've explained
it this way in the past:  In a class hierarchy it is possible for both
the base class and derived classes to want to bind the same events, and
just like overloading virtual methods the programmers will expect the
event bindings in the derived class to take precedence.  Since the
constructor for the base class is executed first followed by the code
for the derived classes (usually, dynamic languages are more flexible)
then it fits the programmer's expectations for the order that the event
bindings are searched to be that those that are bound/connected later
are found first.


--
Robin Dunn
Software Craftsman
http://wxPython.org

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[2]: Event table execution order

Vadim Zeitlin-4
On Mon, 23 Dec 2013 20:28:16 -0800 Robin Dunn wrote:

RD> Vadim Zeitlin wrote:
RD> > On Fri, 22 Nov 2013 18:46:39 +0100 Andreas Falkenhahn wrote:
RD> >
RD> > AF>  could somebody explain to me why I have to invert the event order when manually
RD> > AF>  connecting them using Connect()?
RD> >
RD> >   The information from the event table macros is stored in a fixed size
RD> > array and is looked up from the beginning. The handlers connected using
RD> > Connect() or Bind() are stored in a linked list and the new ones are
RD> > appended in the front of it. Now I don't know if it's an implementation
RD> > detail or a guarantee of the API. When in doubt, I'd rather avoid relying
RD> > on any particular order and just have a single OnRadioBox() handler and
RD> > check the value of the ID inside it.
RD>
RD> I think the order is important for other language bindings, at least for
RD> wxPython, and that we should probably make it official.  I've explained
RD> it this way in the past:  In a class hierarchy it is possible for both
RD> the base class and derived classes to want to bind the same events, and
RD> just like overloading virtual methods the programmers will expect the
RD> event bindings in the derived class to take precedence.  Since the
RD> constructor for the base class is executed first followed by the code
RD> for the derived classes (usually, dynamic languages are more flexible)
RD> then it fits the programmer's expectations for the order that the event
RD> bindings are searched to be that those that are bound/connected later
RD> are found first.

 Yes, this makes a lot of sense. And, luckily, I've actually already
documented this behaviour in r75285, so it just confirms that this was the
right thing to do.

 Thanks,
VZ

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

attachment0 (203 bytes) Download Attachment