I have a small custom dialog (see attached sample code) that works just
fine by itself. However, when I display it from within my application,
it just freezes up - I can't click any of the buttons, nor can I close
the window by clicking on the close button in the upper left-hand corner
of the title bar. In fact, the only way I can close the program is to
either close the terminal that launched it, or kill it via Force Quit!
(Also, when I try to move the dialog, it does this really weird thing of
(seemingly?) multiplying itself - see screenshot below.)
I found this old thread
<https://groups.google.com/d/msg/wxpython-users/n8IqiQT6rvY/X_QxXOshHFIJ> in
the archives, and yes, my application involves matplotlib as well. But I
am not sure what the implications are for my problem. Robin said that "I
dealt with that simply by having my wx.App and main frame classes in a
module that does not import any matplotlib modules", but in my case, I
do need matplotlib for my main frame already, so this does not seem like
it is an option.
Can anybody help?
For some reason matplotlib is having the canvas capture the mouse, so all clicks and other mouse events, no matter where they are happening are being directed back to the canvas, not to the dialog or any other window.
Changing your handler to be something like this helps:
the archives, and yes, my application involves matplotlib as well. But I
am not sure what the implications are for my problem. Robin said that "I
dealt with that simply by having my wx.App and main frame classes in a
module that does not import any matplotlib modules", but in my case, I
do need matplotlib for my main frame already, so this does not seem like
it is an option.
Can anybody help?
For some reason matplotlib is having the canvas capture the mouse, so
all clicks and other mouse events, no matter where they are happening
are being directed back to the canvas, not to the dialog or any other
window.
Changing your handler to be something like this helps:
def on_click(self, event=None):
restore = False
if self.canvas.HasCapture():
restore = True
self.canvas.ReleaseMouse()
dialog = HideRepairDialog(None, -1, "TEST")
result = dialog.ShowModal()
if result == wx.ID_YES:
print "Repair!"
elif result == wx.ID_NO:
print "Error!"
elif result == wx.ID_CANCEL:
print "Cancel!"
dialog.Destroy()
if restore:
self.canvas.CaptureMouse()
WOW, thank you so much, Robin!!! This totally solved it!
This looks like a bug to be fixed in MPL.
Funny how I've never happened on it -- I've never brought up dialogs as the
result of a mouse click, but you'd think the canvas capturing the mouse
would be an issue in other places.....
I suspect it captures the mouse so that that someone can click on the
canvas, drag the mouse outside teh canvas, and keep track of the mouse
motion. But when I've needed to do that, I''ve captured the mouse on
EVT_LEFT_DOWN, and released it on EVT_LEFT_UP, rather than keeping it
captured.
Would releasing it on EVT_KILL_FOCUS work?
Anyway, could you please post to matplotlib-dev, and/or file a bug on the
MPL bug tracker?
Hopefully someone can take a look -- sorry I dont have more time right now
to do it.
-Chris
···
On Thu, Apr 10, 2014 at 10:29 PM, Ingrid <happyplate09@gmail.com> wrote:
Huge thanks to everybody who helped me with this!
Ingrid
Am Donnerstag, 10. April 2014 17:38:35 UTC-7 schrieb Robin Dunn:
Ingrid wrote:
> Hi,
>
> I have a small custom dialog (see attached sample code) that works just
> fine by itself. However, when I display it from within my application,
> it just freezes up - I can't click any of the buttons, nor can I close
> the window by clicking on the close button in the upper left-hand
corner
> of the title bar. In fact, the only way I can close the program is to
> either close the terminal that launched it, or kill it via Force Quit!
> (Also, when I try to move the dialog, it does this really weird thing
of
> (seemingly?) multiplying itself - see screenshot below.)
>
> I found this old thread
> <https://groups.google.com/d/msg/wxpython-users/
n8IqiQT6rvY/X_QxXOshHFIJ> in
> the archives, and yes, my application involves matplotlib as well. But
I
> am not sure what the implications are for my problem. Robin said that
"I
> dealt with that simply by having my wx.App and main frame classes in a
> module that does not import any matplotlib modules", but in my case, I
> do need matplotlib for my main frame already, so this does not seem
like
> it is an option.
>
> Can anybody help?
For some reason matplotlib is having the canvas capture the mouse, so
all clicks and other mouse events, no matter where they are happening
are being directed back to the canvas, not to the dialog or any other
window.
Changing your handler to be something like this helps:
--
You received this message because you are subscribed to the Google Groups
"wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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
WOW, thank you so much, Robin!!! This totally solved it!
This looks like a bug to be fixed in MPL.
Funny how I've never happened on it -- I've never brought up dialogs as
the result of a mouse click, but you'd think the canvas capturing the
mouse would be an issue in other places.....
I suspect it captures the mouse so that that someone can click on the
canvas, drag the mouse outside teh canvas, and keep track of the mouse
motion. But when I've needed to do that, I''ve captured the mouse on
EVT_LEFT_DOWN, and released it on EVT_LEFT_UP, rather than keeping it
captured.
I haven't looked in the MPL code for a while but after thinking about it a bit more it makes sense. I suspect that they are doing the same thing as you mentioned, and that the MPL "button_press"event" is being sent on EVT_LEFT_DOWN so they still have the mouse captured. If the dialog is instead shown via wx.CallAfter from EVT_LEFT_UP (or MPL's equivalent event) then that will probably also resolve the problem. (using CallAfter is so it gives MPL a chance to release the mouse normally.)
···
On Thu, Apr 10, 2014 at 10:29 PM, Ingrid <happyplate09@gmail.com > <mailto:happyplate09@gmail.com>> wrote: