Occasionally I run into this: the app crashes after quitting on Windows only, brings up the “This application has stopped working” window after all the windows of my app have disappeared. Works fine on Mac.
When I put a break point somewhere in a Close event, and try to see what triggers the crash, and step through the close process, then Xojo freezes before the process is complete, sometimes crashing itself and bringing up the same “this application has stopped working” window.
Well I write the apps in Xojo on my Mac. Then I copy the project and resources to my Toshiba laptop and work within the Xojo IDE on Windows to tweak my code for that OS.
It has to do with different timings for object destructors on Windows versus Mac. Just as objects are created in a different order, they are also destroyed in a different order, so sometimes at both startup and shutdown a call to an object works on Mac and doesn’t on Windows (and I assume vice versa would also be true though I’ve never run into that because of the way I work).
In other words, my app was crashing because it was trying to get data from an object that was already destroyed. A couple of lines of workaround code fixed it.
Without quoting a particular reply, I believe a comment should be taken as addressing the original question… which was my intention. Even though the OP seemed to have fixed his issue by rearranging his code, his symptoms matched exactly the BEX issue which has recently been fixed so I wanted to mention that he should look into that possibility too.
Have the same issue. Stepping thru and looking at what exists as app closes, there doesn’t seem to be anything that should be causing this - windows, threads, menubars, etc are all gone. The MDIWindow has handle ‘0’ and I’m not using it. There are 2 floating windows created at ‘open’ and nothing happens in their ‘close’ events except the MainWindow checks to see if it was closed and issues ‘quit’ if app wasn’t already quitting.
I have cleaned up my code quite a bit trying to suss this out, but am at a loss at this point.
Are you using Declares ? Make sure they are using the right Windows APIs to Xojo data type conversion. If you have the wrong type somewhere, you can have random crashes like this.
Declare Function QueryDosDeviceW Lib “Kernel32” ( name as Ptr, target as Ptr, bufChars as Integer ) as Integer
This is part of some code to more quickly sort thru the COM ports on Win. (App is ported over from RealBasic version - it’s pretty old.) Looks like that QueryDosDeviceW should return DWORD which maps to UInt32 on your ref doc. (?)
I tried changing to UInt32 but no luck. I will look and see if there’s better way to deal with COM ports though - that method has given me some trouble sporadically.
Declare Function QueryDosDeviceW Lib “Kernel32” ( name as WString, target as Ptr, bufChars as UInt32 ) as Uint32
If you can, temporarily run a bypass on this QueryDosDeviceW call and see if it crashes.
If it doesn’t crash when you bypass this, you know this is the problem.
If that is the case, check how you allocate your lpTargetPath and make sure its the right length, not running over the end and wiping out some memory which could cause the crash.