Opened 13 years ago
Closed 13 years ago
#1425 closed defect (fixed)
error in python _core.py from wxNVIZ
Reported by: | cmbarton | Owned by: | annakrat |
---|---|---|---|
Priority: | minor | Milestone: | 7.0.0 |
Component: | wxGUI | Version: | svn-trunk |
Keywords: | mouse, wxNVIZ | Cc: | annakrat |
CPU: | Unspecified | Platform: | MacOSX |
Description
The following code raises an error when a mouse click is registered in wxNVIZ
Create folder... /usr/local/tcltk_active/lib/... make links to the ActiveTcl framework binaries libtcl.dylib -> /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl libtcl8.5.dylib -> /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl libtclstub8.5.a -> /Library/Frameworks/Tcl.framework/Versions/8.5/libtclstub8.5.a libtk.dylib -> /Library/Frameworks/Tk.framework/Versions/8.5/Tk libtk8.5.dylib -> /Library/Frameworks/Tk.framework/Versions/8.5/Tk libtkstub8.5.a -> /Library/Frameworks/Tk.framework/Versions/8.5/libtkstub8.5.a Then configure grass with: --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers / Library/Frameworks/Tk.framework/Headers /Library/Frameworks/ Tk.framework/PrivateHeaders" --with-tcltk-libs=/usr/local/tcltk_active/ lib
The error is
Traceback (most recent call last): File "/Users/Shared/grass_dev/grass70_dev/dist.i386-apple- darwin10.8.0/etc/gui/wxpython/gui_modules/nviz_mapdisp.py", line 341, in OnMouseAction self.OnLeftUp(event) File "/Users/Shared/grass_dev/grass70_dev/dist.i386-apple- darwin10.8.0/etc/gui/wxpython/gui_modules/nviz_mapdisp.py", line 475, in OnLeftUp self.ReleaseMouse() File "/Users/Shared/grass_dev/grass70_dev/macosx/dist/GRAS S-7.0.app/Contents/MacOS/etc/python/wx/_core.py", line 9744, in ReleaseMouse return _core_.Window_ReleaseMouse(*args, **kwargs) wx._core . PyAssertionError : C++ assertion "GetCapture() == this" failed at /BUILD /wxPython-src-2.8.12.0/src/common/wincmn.cpp(2536) in ReleaseMouse(): attempt to release mouse, but this window hasn't captured it
Change History (15)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Hi Michael,
how can I reproduce this error? I'm not sure I understand the problem but try to remove the first line in GLWindow.OnLeftUp:
self.ReleaseMouse()
or use:
if self.HasCapture(): self.ReleaseMouse()
Does it help?
Anna
comment:3 by , 13 years ago
self.ReleaseMouse() calls code in _core.py that bombs
I'll try the new code shortly.
comment:4 by , 13 years ago
Unfortunately I'm still getting the same error. The error might be somewhat bogus, because it is not clear that any functionality is affected. Maybe the offending line can simply be commented out.
comment:5 by , 13 years ago
Some testing results.
self.ReleaseMouse() is needed in order to be able to place a north arrow or scale bar with the mouse. Why is this? I inserted a self.HasCapture() command to test whether or not the window is somehow capturing the mouse, but it is not.
The ReleaseMouse() command is to release the mouse following the CaptureMouse(). But I cannot see that the CaptureMouse() command has been issued anywhere. This is why ReleaseMouse() raises an error in the OnLeftUp mouse button handler.
What is not at all clear is what ReleaseMouse() is doing to make the north arrow and scalebar placement possible. Any thoughts on this?
Michael
comment:6 by , 13 years ago
Owner: | changed from | to
---|---|
Priority: | normal → minor |
Status: | new → assigned |
Hi,
I don't understand a few things. Is this some new problem or you just haven't noticed it?
Then, when exactly does the error appear? Any time you click on the map in 3D view?
You really need to call ReleaseMouse for placing a north arrow? That would be strange, capturing and releasing mouse shouldn't be necessary in this case. And in BufferedWindow (class for 2D view) there is no such thing and it works properly.
This seems to be some problem with Mac again because everything works fine for me. So I suggest to remove it or to add CaptureMouse
comment:7 by , 13 years ago
This has been around ever since you added direct mouse control to wxNVIZ, but since it is minor, I haven't mentioned it. If I comment out ReleaseMouse (or even put it into a try clause) you can no longer place arrows and scale bars with the mouse and the cursor does not change to a crosshair. All other mouse functions work fine.
I'll try doing a CaptureMouse followed by a ReleaseMouse and see if this solves the problem.
comment:8 by , 13 years ago
First a question:
Why is ReleaseMouse() in OnLeftUp in the first place?
Now here is what I've found with additional testing.
If ReleaseMouse() is called in OnLeftUp, it correctly raises an error since no CaptureMouse() command was called. To some extent, the error is just noise and the behavior should not be affected. So perhaps the verbose error message should simply be supressed. Perhaps Glynn or Martin can address this since it it is called from _core.py.
If ReleaseMouse() is removed from OnLeftUp or CaptureMouse() is called first or ReleaseMouse() is put inside a try clause or even an if HasMouse() clause, there are some problems in placing arrows and scale bars with the mouse--at least on the Mac.
If you click on the 'place arrow' button, for example, and click on the 3D display, the cursor reverts to a pointer and does not place the arrow. However, if you click on the 'place arrow' button, THEN click on the title bar of the 3D display window to make it active, the cursor changes to a cross and you can place the arrow--one time only, as the cursor then reverts to a pointer. To place the arrow again, you must reclick the 'place arrow' button and again click on the window title bar. Same thing happens when you try to place a scale bar.
So here is my synopsis:
ReleaseMouse is not really needed
BUT it is accidentally fixing a problem with decoration placement that should be fixed some other way. For example, the cursor should stay in arrow-placing mode until the 'place arrow' button is clicked a second time. But the OnLeftUp handler is canceling this mode. There needs to be a 'switch' variable set when in decoration placement mode that is only turned off by clicking the placement button (or perhaps by leaving the appearances window).
The fact that this mode is NOT switching off in Linux is as much of a fluke as the fact that the ReleaseMouse() command is keeping it from switching off on the Mac--probably by raising an error and preventing some of the other commands from completing.
On a somewhat related note, why doesn't the scale bar placement work like the arrow placement? There is no reason to have multiple scale bars on an image that I can think of.
comment:9 by , 13 years ago
Platform: | Unspecified → MacOSX |
---|
Hi,
if I understand it correctly adding Raise could help (line 3998):
... if event.GetInt(): self.mapWindow.parent.Raise() ...
try it without calling ReleaseMouse please (I think it should be removed).
Switching off the 'placing arrow mode' is intention. I think it's better to switch it off than to let the user do it. But I can change it, of course. Maybe someone else could tell us his opinion.
Multiple scalebars can be useful to show that the scale is varying (I think, Helena once mentioned it)
follow-up: 11 comment:10 by , 13 years ago
Line 3998 of what module? nviz_mapdisp.py only goes to 2009 and this doesn't seem to make sense in _core.py.
comment:11 by , 13 years ago
Replying to cmbarton:
Line 3998 of what module? nviz_mapdisp.py only goes to 2009 and this doesn't seem to make sense in _core.py.
sorry, nviz_tools.py
comment:13 by , 13 years ago
Cc: | added |
---|
Replying to cmbarton:
nviz_tools.py only goes up to line 3446.
I meant GRASS7. Changes haven't been backported to G65 yet.
comment:14 by , 13 years ago
Thanks. That fixed it. I see you've already added the window raise command. I deleted the ReleaseMouse() command and committed.
comment:15 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Replying to cmbarton:
I had to correct the code I put in the original report.