Hi guys, I’ve encountered a really odd issue, which i’ve also posted at SO:
http://stackoverflow.com/questions/24275376/difference-between-raising-exception-and-automatically-causing-an-exception
Can any enlightened member share their knowledge?
Do you really think we ought to be forced to bring up StackOverflow to view your problem? If you’re asking a question of this mailing list, don’t you think you could ask your question on this list?
···
On Jun 19, 2014, at 5:54 PM, Jay Cheah jay.cheah@astc-design.com wrote:
Hi guys, I’ve encountered a really odd issue, which i’ve also posted at SO:
http://stackoverflow.com/questions/24275376/difference-between-raising-exception-and-automatically-causing-an-exception
Can any enlightened member share their knowledge?
–
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
Here is my question:
Currently using the wxPython framework and my code looks like this:
Event bind:
self.frequency_grid.Bind(wx.grid.EVT_GRID_CELL_CHANGE, self.on_cell_changed)
Function that handles changed cells:
def on_cell_changed(self, event):
self.current_grid = event.GetEventObject()
try:
new_value= self.get_cell_value()
if new_value < 0:
raise AttributeError
#allow the cell to update
except AttributeError:
event.Veto()
wx.MessageBox(_("Positive values only."), "", wx.OK|wx.ICON_WARNING)
except:
wx.MessageBox(_("Invalid value for cell."), "", wx.OK|wx.ICON_WARNING)
event.Veto()
The function get_cell_value() reads the value from the current cell and converts it to an integer simply by using int(). If the user enters a character like ‘a’ into the cell, obviously this function fails and the exception is raised. In this case the messagebox comes out telling the user the cell has an invalid value. This is what I call the automatically caused exception.
In the case of negative values, I manually raise an AttributeError (just wanted to see something different from ValueError which is what happens when user inputs characters). In this case however, the wxPython sends the EVT_GRID_CELL_CHANGE event twice, so there must be something different about manually raised exceptions.
I’ve separately raised a ticket about the duplicated events at http://trac.wxwidgets.org/ticket/16333 but just trying to understand how the first scenario doesn’t make wxPython send 2 events compared to the second scenario.
Someone posited that maybe Veto was causing the double events, but if I remove the wx.MessageBox call, the events are not repeated.
···
On Friday, June 20, 2014 4:55:44 PM UTC+9:30, Tim Roberts wrote:
On Jun 19, 2014, at 5:54 PM, Jay Cheah jay....@astc-design.com wrote:
Hi guys, I’ve encountered a really odd issue, which i’ve also posted at SO:
http://stackoverflow.com/questions/24275376/difference-between-raising-exception-and-automatically-causing-an-exception
Can any enlightened member share their knowledge?
Do you really think we ought to be forced to bring up StackOverflow to view your problem? If you’re asking a question of this mailing list, don’t you think you could ask your question on this list?
–
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
1 - Are you sure that's what's happening? Myself, I'd sprinkle print()
statements all over...
2 - If that actually _is_ what's happening, it may be because vetoing the
change event (and therefore changing the cell's value back) itself causes a
change event. I'm a bit unclear on the mechanics, but that would be my
first guess.
3 - I'm not sure it matters, but why does Veto come first under
AttributeError and last in the general except? Probably unimportant, but
consistency can be a virtue.
···
On Sun, Jun 22, 2014 at 7:16 PM, Jay Cheah <jay.cheah@astc-design.com> wrote:
In this case however, the wxPython sends the EVT_GRID_CELL_CHANGE event
twice
-
I have tried it with print() statements all over, but I cleaned them up when I posted the question. A print() at the very start def on_cell_changed(self, event) will print 2x if the messagebox() is called from the manually raised exception block(), if even if messagebox() is called from an if statement that checks whether the number is negative. However, if the messagebox() is triggered from the ValueError exception (i.e. generated from get_cell_value()) then, it will only print() once.
-
A veto() without calling the messagebox() does not cause that print() statement to happen 2x. At any rate, if the messagebox() indeed does cause a problem with the event being generated twice, then why does the last exception block NOT cause the event to generated twice vs the first exception block?
-
I’ve tried it with different ordering of the Veto() as well, i.e before or after the messagebox(). Had the same thought as you, but it doesn’t make a difference to what happens unfortunately.
If anyone wants to try the problem, you can easily find similar code at the wx Demo under Simple wx.Grid demo (first one under Core Windows/Controls:Grid), to which I’ve recorded the steps at wxTrac has been migrated to GitHub Issues - wxWidgets. You can see the events being reported at the output frame of the wx Demo as well.
···
On Monday, June 23, 2014 12:22:15 PM UTC+9:30, Marc wrote:
On Sun, Jun 22, 2014 at 7:16 PM, Jay Cheah jay....@astc-design.com wrote:
In this case however, the wxPython sends the EVT_GRID_CELL_CHANGE event twice
1 - Are you sure that’s what’s happening? Myself, I’d sprinkle print() statements all over…
2 - If that actually is what’s happening, it may be because vetoing the change event (and therefore changing the cell’s value back) itself causes a change event. I’m a bit unclear on the mechanics, but that would be my first guess.
3 - I’m not sure it matters, but why does Veto come first under AttributeError and last in the general except? Probably unimportant, but consistency can be a virtue.
On a side note, my reply to you was unnecessarily snarky. I did not need to be so snide. I apologize.
···
On Jun 22, 2014, at 7:16 PM, Jay Cheah jay.cheah@astc-design.com wrote:
Hi Tim,
Here is my question:
–
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
I am far from being an expert at message handling internals, but the fact that it seems to happen only when you raise a MessageBox makes me wonder: Is it possible that one instance of the event is coming from the app’s MainLoop and another is coming from the MessageBox’s own event processing loop (being a modal dialog box)? I don’t know why the MessageBox would even see the event to process it (unless, as was suggested elsewhere, the Veto actually generated a new event). Would a stack trace at the start of the event handler show you which event loop was propagating the event?
Hi Rufus,
After a bit more tracing, I found that creating the MessageBox causes the EVT_GRID_CELL_CHANGING event to occur, which then leads to the EVT_GRID_CELL_CHANGED event to occur, which is why I saw duplicated events. It’s a nested _CHANGED event, probably the focus switch to the MessageBox causes the grid control to generate the event.
The reason why I did not see duplicated events during the entry of a character was because a Veto() was called in the event handler for the EVT_GRID_CELL_CHANGING if an int() conversion was invalid because my handler for that event gets the grid input and tries to convert it.
In conclusion, there is no difference in Python exception handling, but however, a better wxPython demo code should be implemented to prevent the duplicated message box during the demo and show other users how to better use the grid mechanism, as even the default demo code has nested events coming out.
···
On Tuesday, June 24, 2014 2:36:14 AM UTC+9:30, Rufus wrote:
I am far from being an expert at message handling internals, but the fact that it seems to happen only when you raise a MessageBox makes me wonder: Is it possible that one instance of the event is coming from the app’s MainLoop and another is coming from the MessageBox’s own event processing loop (being a modal dialog box)? I don’t know why the MessageBox would even see the event to process it (unless, as was suggested elsewhere, the Veto actually generated a new event). Would a stack trace at the start of the event handler show you which event loop was propagating the event?