SetFocus failed with exception #168
Comments
|
Managed to reproduce this with a bit more detail. I thought at first the issue seems could be something I've changed in the logging, and it not liking stderr being passed as a file param to print_stack - but it doesn't make a lot of sense why this would be the case. But on further investigation it looks like in os.py:326, there's use of a wx.MessageDialog as dlg statement, which then calls dlg.ShowModal() `2025-02-19 18:32:08,520 Utils [INFO] call: openRace: "C:\Users\tim\OneDrive\Documents\2024-12-28-Test Event-r1-.cmn"
File "C:\Program Files\JetBrains\PyCharm Community Edition 2024.3.1.1\plugins\python-ce\helpers\pydev\pydevd.py", line 2270, in
File "C:\Program Files\JetBrains\PyCharm Community Edition 2024.3.1.1\plugins\python-ce\helpers\pydev\pydevd.py", line 2270, in
File "C:\Program Files\JetBrains\PyCharm Community Edition 2024.3.1.1\plugins\python-ce\helpers\pydev\pydevd.py", line 2270, in
File "C:\Program Files\JetBrains\PyCharm Community Edition 2024.3.1.1\plugins\python-ce\helpers\pydev\pydevd.py", line 2270, in |
|
Further - have had it fail in Fired from |
|
All of these errors appear to be in wxPython.
There are a lot of reports about this error (see here
<https://www.google.com/search?q=wxpython+%27SetFocus%27+failed+with+error+0x00000057+%28The+parameter+is+incorrect.%29&sca_esv=7833c6f0638101e1&sxsrf=AHTn8zqSbYHNZfKTf3G51opIj5zChJ82vA%3A1740007220119&ei=NGe2Z8r7BtOuptQPq5iwoQc&ved=0ahUKEwjK5YuC8NCLAxVTl4kEHSsMLHQQ4dUDCBA&uact=5&oq=wxpython+%27SetFocus%27+failed+with+error+0x00000057+%28The+parameter+is+incorrect.%29&gs_lp=Egxnd3Mtd2l6LXNlcnAiTnd4cHl0aG9uICdTZXRGb2N1cycgZmFpbGVkIHdpdGggZXJyb3IgMHgwMDAwMDA1NyAoVGhlIHBhcmFtZXRlciBpcyBpbmNvcnJlY3QuKUivEFDpBliJD3ABeACQAQCYAV6gAZMGqgECMTC4AQPIAQD4AQGYAgCgAgCYAwCIBgGSBwCgB4ka&sclient=gws-wiz-serp>
).
This seems to be a problem with wxwidgets (the underlying C library that is
wrapped by wxPython) where it calls SetFocus after the target window has
been deleted.
I don't think it can be fixed in CrossMgr code.
I noticed some discussions about whether the message is harmless and can be
ignored.
Some of the reports show that it is related to the Sash widget which is the
thing you drag to change the resizing in wx.SplitterWindow.
I'm not sure that getting rid of wx.SplitterWindow would eliminate the
problem, but it would be a major UI redesign.
Open to ideas.
…On Wed, Feb 19, 2025 at 2:45 AM Tim Rowe ***@***.***> wrote:
Further - have had it fail in self.EnableCellEditControl() of grid.py:41
from GetClientRect.
File "H:\dev\CrossMgr\MainWin.py", line 4564, in <module>
MainLoop()
File "H:\dev\CrossMgr\MainWin.py", line 4561, in MainLoop
app.MainLoop()
File "H:\dev\CrossMgr\env\lib\site-packages\wx\core.py", line 2262, in MainLoop
rv = wx.PyApp.MainLoop(self)
File "H:\dev\CrossMgr\MainWin.py", line 3344, in menuFileHistory
self.openRace( fileName )
File "H:\dev\CrossMgr\Utils.py", line 605, in new_f
return f( *args, **kwargs)
File "H:\dev\CrossMgr\MainWin.py", line 3276, in openRace
if not Utils.MessageOKCancel( self, '{}.\n\n{}:\n\n\t{}{}\n\n{}'.format(
File "H:\dev\CrossMgr\Utils.py", line 326, in MessageOKCancel
return dlg.ShowModal() == wx.ID_OK
File "H:\dev\CrossMgr\env\lib\site-packages\wx\core.py", line 3427, in <lambda>
lambda event: event.callable(*event.args, **event.kw) )
File "H:\dev\CrossMgr\env\lib\site-packages\wx\lib\mixins\grid.py", line 41, in __DoEnableEdit
self.EnableCellEditControl()
File "H:\dev\CrossMgr\LogPrintStackStderr.py", line 31, in DoLogRecord
traceback.print_stack( file=sys.stderr )
—
Reply to this email directly, view it on GitHub
<#168 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABGXKOHFFQT2M3E4HQKDNT2QQZBDAVCNFSM6AAAAABW3XVGVSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRXG44TENJYGY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
[image: tjsr]*tjsr* left a comment (esitarski/CrossMgr#168)
<#168 (comment)>
Further - have had it fail in self.EnableCellEditControl() of grid.py:41
from GetClientRect.
File "H:\dev\CrossMgr\MainWin.py", line 4564, in <module>
MainLoop()
File "H:\dev\CrossMgr\MainWin.py", line 4561, in MainLoop
app.MainLoop()
File "H:\dev\CrossMgr\env\lib\site-packages\wx\core.py", line 2262, in MainLoop
rv = wx.PyApp.MainLoop(self)
File "H:\dev\CrossMgr\MainWin.py", line 3344, in menuFileHistory
self.openRace( fileName )
File "H:\dev\CrossMgr\Utils.py", line 605, in new_f
return f( *args, **kwargs)
File "H:\dev\CrossMgr\MainWin.py", line 3276, in openRace
if not Utils.MessageOKCancel( self, '{}.\n\n{}:\n\n\t{}{}\n\n{}'.format(
File "H:\dev\CrossMgr\Utils.py", line 326, in MessageOKCancel
return dlg.ShowModal() == wx.ID_OK
File "H:\dev\CrossMgr\env\lib\site-packages\wx\core.py", line 3427, in <lambda>
lambda event: event.callable(*event.args, **event.kw) )
File "H:\dev\CrossMgr\env\lib\site-packages\wx\lib\mixins\grid.py", line 41, in __DoEnableEdit
self.EnableCellEditControl()
File "H:\dev\CrossMgr\LogPrintStackStderr.py", line 31, in DoLogRecord
traceback.print_stack( file=sys.stderr )
—
Reply to this email directly, view it on GitHub
<#168 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABGXKOHFFQT2M3E4HQKDNT2QQZBDAVCNFSM6AAAAABW3XVGVSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRXG44TENJYGY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Edward Sitarski
|
|
It both is an isn't harmless. While it doesn't appear to affect functionality, it means there's an underlying exception that comes from an event which isn't caught, which causes it to track later on that an unhandled exception occurred in an event handler thread so when it goes in to things like exit states, it knows about that so thinks the application or windows aren't being closed cleanly. It's not my top priority at the moment (much more a case of 'log these things when you encounter them, regardless of plan of action'), but I want to find a way of trapping exceptions that come from certain event handlers so we can at least prevent wxwidgets and the wx.App instance/event handler being in that state. As far as UI design - you and I need to sit down and have a talk about where you want to go with the project in general. I'd be much happier with a declarative approach to UI, and the current project has very little abstraction. However I haven't yet found from a brief search that there's any good declarative WX libraries, nor anything like a React Native implementation for it. |
|
Alright, I found (and fixed) this issue - it was a little bit in my code but is also present in existing code. When I say 'my code', in my branch I've refactored these classes so that those controls are in their own files and classes, and added a little bit of code to disable the controls when no race is active (ie, when it would just discard anything you enter but you don't know it's done that) - with a message that tells you why it's disabled. But for the most part it's still pretty similar, and affects both. What happens is that when you call things like Line 751 in 7949e59 wx.CallLater( 100, self.keypad.numEdit.SetFocus )
The state or event handle to these objects can go away in that time before the callback occurs, and it seems it can also happen when you try to set the focus on an object that's marked disabled. Anyway, it's a mix of things there - so in my reworked version I've wrapped the callback in a safe handler that catches the exception at the time any code is run so you can more easily debug it (same as I've done for all new menu item calls - they live in a wrapped handler that calls a lambda pointing to the method) - but it also has some guard checks in there that prevents it firing if the control is disabled. I've also changed it so that you now set the focus to the actual pane, and whenever that pane explicitly requests focus, it also sets the editor text field as the taking focus rather than just the background panel. - so any time something programmatically causes those tabs to grab focus, it will be on the text field, ready to accept data entry. I'll commit this to my fork when I get home this evening and then point you to the branch containing the fixes, and we can figure out what to do with a refactor to bring them together. Edit: A PR for a branch is here, but it is very much a WIP which needs squashing, cherry-picking and rebasing on main as it's on top of all other work right now. #170 |
Logging for future investigation - have seen multiple of these.
Could be due to local changes - maybe not. We'll find out but logging so we have something to track later.
The text was updated successfully, but these errors were encountered: