I have a program running which continuously displays current time in a Tkinter window.
Occasionally the program hangs with Red "Close" button in the Tkinter window. Left-clicking the button gives a WINDOWS message "Python not responding" with the option "Try to restore the program".
Selecting this option initially says it can't restore, but after a second or so it does restore and Python continues from the current time and the messages clear.
It seems to me that if WINDOWS can fit the problem, it must have been originated BY WINDOWS.
Maybe it would be resolved by using Linux?
Any advice appreciated
Thanks
Astrikor
Please show the code. Could only guess without it.
Unfortunately the code is propriety, so can't be published.
Can anyone respond to my general query - if WINDOWS is offering to fix Python code is WINDOWS causing the error?
Astrikor
Without code it's impossible to answer.
(Aug-03-2021, 08:52 AM)Astrikor Wrote: [ -> ]Occasionally the program hangs with Red "Close" button in the Tkinter window.
This happens, if you block the main thread, but we can't say why your program is blocking the main thread.
(Aug-03-2021, 08:52 AM)Astrikor Wrote: [ -> ]I have a program running which continuously displays current time in a Tkinter window.
Occasionally the program hangs with Red "Close" button in the Tkinter window. Left-clicking the button gives a WINDOWS message "Python not responding" with the option "Try to restore the program".
Selecting this option initially says it can't restore, but after a second or so it does restore and Python continues from the current time and the messages clear.
It seems to me that if WINDOWS can fit the problem, it must have been originated BY WINDOWS.
Maybe it would be resolved by using Linux?
Any advice appreciated
Thanks
Astrikor
I seriously doubt it is Windows. Windows is responding to a failure of the Python interpreter to respond to messages. This represents a structural error in the program. You might not get the error on Linux, but that would be because Linux does not check for this condition, and Windows does. The bug will not be gone, it will just be undetected.
Do not confuse program errors detected with operating system failure. I once had someone tell me that "I never compile in Debug mode because I keep getting all kinds of 'Assertion failure' messages". I pointed out that each of those messages was reporting a bug in the program, and the correct thing was not to compile in Release mode (which eliminates tons of extra error-checking) but to use debug mode and fix the bugs, because they were likely to cause malfunctions. There is a malfunction in your program, and Windows detected it. I don't know what it might be, because I have not used Tkinter and don't know its details, but don't dismiss this as a "Windows bug". It is a bug in your program, and Windows goes through some extra effort to detect and report this kind of error.
You say because Windows can fi[x] the error, it must have been created by Windows. No. It means that Windows has done something to signal your program that it needs to recover, and that recovery is successful. It is not caused by Windows; Windows did not "fix" it. The Python interpreter probably fixed it, and it may have fixed it by restarting the program. So Windows didn't "fix" it. You really need to understand the role of the OS and the interpreter, and if I understood anything about Tkinter I might be able to suggest what has happened. Based on my experience in other Windows programming languages, it suggests that your program has gone off into a long-term loop and has not gone back to the Tkinter message pump, which is a programming error. You can't do that. It is bad practice. It has nothing to do with Windows, and the program will still be erroneous in Linux, MacOS, and on any embedded system you would run it on.
Many thanks supuflounder,
That's very helpful.
Astrikor
(Aug-03-2021, 10:38 AM)supuflounder Wrote: [ -> ]Windows has done something to signal your program that it needs to recover, and that recovery is successful. It is not caused by Windows; Windows did not "fix" it. The Python interpreter probably fixed it, and it may have fixed it by restarting the program
So that begs the question that if Windows has been monitoring the Python program and correction has been achieved by a keyboard action, is there any way that Python could do the same - is there any Python script/function which could replicate the Windows monitoring function but also
automatically restore the program without requiring a keyboard intervention?
Astrikor
Would it not be better to find the cause of the error and fix that, rather than patch the error during runtime?
Well yes of course. All the usual error trapping is in place and working fine, but how to find the location of an error which happens only rarely?
What are you doing to diagnose the issue? Is the application logging? Are there any patterns in the logs that you're noticing?