I made a super simple ticket with one line of code:
me.AddRowAt(1, "test")
in the Open event of a popupmenu. This crashes for me for the current version of Xojo and the latest beta under Ventura and even High Sierra.
The crash does not happen for Xojo. Can anyone else reproduce the crash? The bug is easy to work around. But it’s so odd that Xojo doesn’t get the crash.
No crash here either (just nothing gets added and the popup menu stays empty). Daylight saving time starts here like in Germany, so it’s not related.
On Mac OS 13.2.1.
As it seems isolated to her machines, maybe plugins installed are the different part of the equation if other people running Xojo 2022r3 using German/Berlin locale in a Ventura machine can’t trigger it.
I also recommend to try again using a newer version (specially some latest beta) and see if it still happens because from 2022r3 to today many things changed, including some Ventura focused fixes and some locale operations (as string compare) fixes.
On this M1 Air it never reaches the break point, and when enabling “Crash on NSException” the application crashes with the same report as @Beatrix_Willius
Correct. This seems to be a manifestion of an old issue, in which a macOS Cocoa exception no longer kills the app, instead the Xojo method or function just exits early, which is very confusing. This is described here: Crash an application on NSException
Edit: Credit to @Sam_Rowlands who beat me to it by figuring this out, over on the Issues website.
I can reproduce it with this code:
#If TargetMacOS
const FoundationLib = "Foundation"
Declare Function standardUserDefaults Lib FoundationLib Selector "standardUserDefaults"(NSUserDefaultsClass As Ptr) As Ptr
Declare Function NSClassFromString Lib FoundationLib(ClassName As CFStringRef) As Ptr
Static standardUserDefaultsPtr As Ptr = standardUserDefaults(NSClassFromString("NSUserDefaults"))
Declare Sub setBool Lib FoundationLib Selector "setBool:forKey:"(NSUserDefaults As Ptr, value As Boolean, Key As CFStringRef)
setBool(standardUserDefaultsPtr, True, "NSApplicationCrashOnExceptions")
#EndIf
System.Debuglog("Foo")
me.AddRowAt(1, "blabla")
System.Debuglog("Bar")
break
Agree, it was being masked by the change in NSApplicationCrashOnExceptions behavior.
@Beatrix_Willius : I’m guessing that because you are using a generic bundle identifier (com.mycompany.test) you accidentally had set NSApplicationCrashOnExceptions to True, perhaps in another test app using this same Bundle ID?