I am having problems with unhandled runtime exceptions (not in a try catch) that are being thrown from Modally shown windows on 64bit applications. The problem is that after the exception is thrown all other events on that window no longer fire. So if you have a close button with self.Close() then you cannot actually close the window and you’re forced to quit the application.
If you have access to the Window X close button then you can close the window and the app.unhandledexception event fires. Sheet windows obviously do not have this. On 32bit builds there is no problem the other control events keep on firing.
Other than putting try catch’s around all modal window events, how can i fix this problem. It appears to go back to all version of Xojo and 64bit builds.
Tested on Xojo 2019r1.1 with Windows and mac 32 and 64 bit builds going back to xojo 2016r3
I think this was fixed in 2019r2
Oh great! The version that adds 4,000 errors and 20,000+ deprecation warnings.
You know that you can suppress deprecation messages in R2, right? As for errors, I did not get any new error that was not there in 2019 R11.
The suppression of deprecation messages clears the pane and lets you deal with them only when you are good and ready. Not saying that 2019 R2 is exempt from issues however. Just that deprecations and only deprecations, are not as bad a problem as one might think at first. I converted one of my applications to R2. So far, so good. it was not such a big deal once I got over the admittedly overwhelming number of deprecations.
It sounds like a NSException to me, because the current thread gets killed, and then buttons become decoration only.
Tracking these down can be a royal PITA, they get logged, but the Console app is near useless now. Id added a Console function to App Wrapper (tools menu) to help try to dig out NSExceptions… Except that Im now finding that even with this, it appears not all NSExceptions get logged!
I am working to trying to capture NSExceptions using declares and native Xojo, I also have a feedback request for Xojo to do this for us.
Good luck, these are worse than crashes IMHO.
It’s not an nsexception, it is literally a nil pointer exception i created myself. The workaround, other than running 2019r2 is to put a try catch around all events and handle the exception there instead of relying on the app’s unhandled exception.
I do know NSExceptions are tricky, i have seen a few been raised and caught in mbs functions but that was years ago, and luckily not what Im having problems with here.