I read the apple-robot analogy given here under fruit catching robots.
http://wiki.wxpython.org/self.Bind%20vs.%20self.button.Bind
I would like to check my understanding. Kindly let me know if my understanding is wrong.
wx.Bind is equivalent to keeping the basket on the ground. Here wx.Frame is the ground. whenever the apple falls on the ground, the robot inspects if the apple fell from the branch we are looking into, and puts it in the basket which is equivalent to calling the method functions defined in the derived class of wx.Frame.
wx.button.Bind is equivalent(as delineated on the wiki) to attaching the robot directly on the branch we are interested in. Thus the method functions gets directly called without propagating it to the parent class.
Best,
Pkri
pradeep k wrote:
I read the apple-robot analogy given here under fruit catching robots.
self.Bind vs. self.button.Bind - wxPyWiki
I would like to check my understanding. Kindly let me know if my understanding is wrong.
wx.Bind is equivalent to keeping the basket on the ground. Here wx.Frame is the ground. whenever the apple falls on the ground, the robot inspects if the apple fell from the branch we are looking into, and puts it in the basket which is equivalent to calling the method functions defined in the derived class of wx.Frame.
wx.button.Bind is equivalent(as delineated on the wiki) to attaching the robot directly on the branch we are interested in. Thus the method functions gets directly called without propagating it to the parent class.
That is correct, where "parent class" is about ownership, not inheritance. Use wx.Bind when you think you may want to continue passing the command up the hierarchy. Use wx.Button.Bind if you just want to act once on the command and that's it. Some may consider using the second form a cleaner way of thinking, even though for a single event response it doesn't affect the way the program operates.
Michael wrote:
Use wx.Bind when you think you may want to continue passing the command up the hierarchy.
Actually, that makes no difference. In either case, if you want the event to keep passing up the hierarchy, you need to call event.Skip().
Use wx.Button.Bind
...
Some may consider using the second form a cleaner way of thinking,...
Exactly, it seems cleaner to me, though, it will work either way. However, there are some events that won't propogate, so you need to call:
Widget.Bind()
so I just do that everywhere.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
In addition to what has already been said, I suggest to use very sparingly event.Skip(), i.e. when we know for certain that some other handling is to be performed (mainly with wx.TextCtrl). Otherwise we might get some unexpected results.
···
2008/7/31, Christopher Barker Chris.Barker@noaa.gov:
Use wx.Bind when you think you may want to continue passing the command up the hierarchy.
Michael wrote:
Actually, that makes no difference. In either case, if you want the event to keep passing up the hierarchy, you need to call event.Skip().
Use wx.Button.Bind
…
Some may consider using the second form a cleaner way of thinking,…
Exactly, it seems cleaner to me, though, it will work either way. However, there are some events that won’t propogate, so you need to call:
Widget.Bind()
so I just do that everywhere.
-Chris
–
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
raffaello wrote:
In addition to what has already been said, I suggest to use very sparingly event.Skip(), i.e. when we know for certain that some other handling is to be performed (mainly with wx.TextCtrl). Otherwise we might get some unexpected results.
Really? Personally I tend to think of it the other way: I shouldn't stop event handling unless I have an explicit reason too. It generally to me seems easier to identify when you want stop event handling, something specific to your application (and only not Skip'ing then) versus trying to figure out if there might be something else wxPython needs to do internally, to achieve the desired state (and only Skip'ing then).
Without a full understanding of everything wxPython does under the hood, I feel more comfortable only stopping the event flow when I specifically know I have handled everything. I think you are more likely to get unexpected results by assuming you know exactly when wxPython cares about events and only Skip'ing then. I know I have run into a few cases like this.
What are other people's thoughts?
- Mike
I met my mishaps with derived classes, when overriding methods of the parent class. Since I had written the original class myself, even if months before, it was relatively easy to find the bug. With code written by somebody else, it would have been a real nighmare.
Let us put the matter this way: when we meet an unexpected result, one of the tests is to comment out event.Skip().
···
2008/7/31, Mike Rooney mxr@qvii.com:
In addition to what has already been said, I suggest to use very sparingly event.Skip(), i.e. when we know for certain that some other handling is to be performed (mainly with wx.TextCtrl). Otherwise we might get some unexpected results.
raffaello wrote:
Really? Personally I tend to think of it the other way: I shouldn’t stop event handling unless I have an explicit reason too. It generally to me seems easier to identify when you want stop event handling, something specific to your application (and only not Skip’ing then) versus trying to figure out if there might be something else wxPython needs to do internally, to achieve the desired state (and only Skip’ing then).
Without a full understanding of everything wxPython does under the hood, I feel more comfortable only stopping the event flow when I specifically know I have handled everything. I think you are more likely to get unexpected results by assuming you know exactly when wxPython cares about events and only Skip’ing then. I know I have run into a few cases like this.
What are other people’s thoughts?
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
I’m with you on this one Mike,
I’ve been bitten far too often trying to capture an Event and not being able to, then digging through the code only to find I was capturing the Event elsewhere and had forgotten the Event.Skip().
···
On Thu, Jul 31, 2008 at 11:41 AM, Mike Rooney mxr@qvii.com wrote:
raffaello wrote:
In addition to what has already been said, I suggest to use very sparingly event.Skip(), i.e. when we know for certain that some other handling is to be performed (mainly with wx.TextCtrl). Otherwise we might get some unexpected results.
Really? Personally I tend to think of it the other way: I shouldn’t stop event handling unless I have an explicit reason too. It generally to me seems easier to identify when you want stop event handling, something specific to your application (and only not Skip’ing then) versus trying to figure out if there might be something else wxPython needs to do internally, to achieve the desired state (and only Skip’ing then).
Without a full understanding of everything wxPython does under the hood, I feel more comfortable only stopping the event flow when I specifically know I have handled everything. I think you are more likely to get unexpected results by assuming you know exactly when wxPython cares about events and only Skip’ing then. I know I have run into a few cases like this.
What are other people’s thoughts?
–
Stand Fast,
tjg. [Timothy Grant]
Interesting question. I agree with raffaello. I never call
Event.Skip() unless I know
there is something in the default handler that I need. This hasn't
caused me many
problems, and in the few cases when a Skip() has actually been needed, it has
been pretty obvious what the problem was. Perhaps if I were in the
habit of binding
the same event in more than one place, it would bite me, but that
isn't my coding
style. So for me, not Skipping works.
···
On Thu, Jul 31, 2008 at 3:42 PM, Timothy Grant <timothy.grant@gmail.com> wrote:
On Thu, Jul 31, 2008 at 11:41 AM, Mike Rooney <mxr@qvii.com> wrote:
raffaello wrote:
In addition to what has already been said, I suggest to use very
sparingly event.Skip(), i.e. when we know for certain that some other
handling is to be performed (mainly with wx.TextCtrl). Otherwise we might
get some unexpected results.
Really? Personally I tend to think of it the other way: I shouldn't stop
event handling unless I have an explicit reason too. It generally to me
seems easier to identify when you want stop event handling, something
specific to your application (and only not Skip'ing then) versus trying to
figure out if there might be something else wxPython needs to do internally,
to achieve the desired state (and only Skip'ing then).
Without a full understanding of everything wxPython does under the hood, I
feel more comfortable only stopping the event flow when I specifically know
I have handled everything. I think you are more likely to get unexpected
results by assuming you know exactly when wxPython cares about events and
only Skip'ing then. I know I have run into a few cases like this.
What are other people's thoughts?
- Mike
I'm with you on this one Mike,
I've been bitten far too often trying to capture an Event and not being able
to, then digging through the code only to find I was capturing the Event
elsewhere and had forgotten the Event.Skip().
--
Best Regards,
Michael Moriarity