For future reference, this is an exception, not a crash. A crash is when the software is killed by the OS for doing something wrong or the OS is buggy.
You’re going to have to go through the routine " App.mCargaVariablesGlobales" and try to understand what variables can be NIL, then understand why and write code to protect against it.
The easiest way to track the NOE, with a machine you can access is either run Xojo on that machine or use Remote Debugging over a local network to run your application on that machine.
What is important is to understand WHY it is happening, otherwise you may prevent the exception from being raised, but it can lead to further problems with your application.
Thanks @Sam_Rowlands . Your are right pointing the difference between a crash and an exception. My mistake.
What Is difficult for me to understand is why with the previous OSx version (BigSur)the Nil exception was manage in such different way from how the new OSx does, because nothing was canged except the OSx version.
I will try to follow what you suggest in the routine " App.mCargaVariablesGlobales "
Thanks again
I dealt with this too. The reason this happens is that Monterey fires events in a different order than previous versions. ie. open, opendocument, newdocument etc. This may causes the event or method where the exception occurs to be invoked before the code that instantiates a property. In my case the exception did not drop into the debugger making it much harder to track down. Try setting breakpoints in events that fire on launch. You may be surprised to see when they fire.
It’s possible that you’re blindly reading or writing to a location that now needs user permission or that is no longer writable. For instance, the /Application directory is read-only now. Folders within the user’s home directory require permission and you’ll get nil if the user declines. Recently Apple has even become more strict about where app preferences can be written. These are all things that your app will need to consider going forward and luckily also work on older versions of macOS.
@Greg_O Thanks for your advices… I had checked all the folders and the files that the application need to access and all permission are OK.
I notice that a Null value is returned when trying to read a table in a database, and the recordset returned is Null… and I notice that it returns a Null because the following error occurs when trying to run a SELECT: “Character Set ISO8859_1 is not installed”
Tables have fields with this kind of Character Set, but in the previous version of OSx (Big Sur) no error was reported with the same database and the same application.
So I imagine that if I install this Character Set my problem would be solved. But… I dont know how to do it…
Some could teach me what I have to do ?
Thanks a lot
Assuming you are just checking the read, write and execute bits and the owner and group, that’s not enough. Apple enforces a whole extra layer of protection on top of the file system permissions which I described above.
The fact that you’re getting a nil exception when reading a database may still very well be that your app is not allowed to access the file.
I suggest that you set a breakpoint after you create the folderitem and inspect the properties of that item to see if it’s truly readable and writable and if its parent directory is also readable and writable… according to the folderitem itself because that’s all that matters here.
Since 10.9 Apple has advised against manually reading and writing to the preferences folder, instead using the NSUserDefaults API. So they finally followed through with it.
@AlbertoD yes I do use Firebird. @Greg_O I am sure that the problem is not that I am not reading the database because wrong permisssions because before the Null error another SELECT query was invoqued and no error happened. That query do not include a field with a Character Set ISO 8859_1, that is included in the next SELECT, the one that generates the error and returns a Null recordset
So I am pretty sure that the error is the one I got when unning the SELECT in a database manager installed in the Mac and it is “character set is not installed.”.
As I said before, I beleive that the solution could be intallimg that character set but I dont know how to do it…
you have an app that worked with Firebird before upgrading to Monterey
you updated to Monterey and now your app fails
you are narrowing down the problem to a database problem with ISO 8859_1 character set
is that correct?
What I’m trying to say is that the change to Monterey is causing your Firebird installation to not be able to access the character set anymore. Maybe if you search on Firebird forums you can find a way to be able to fix your Firebird installation to access the character set in Monterey. It should be a permissions issue.
This is just an idea, I have no experience with Firebird. Just a quick search for “iso 8859_1 character not installed” hinted at a possible Firebird access problem that can’t get the intl part of the database. I hope you can find a fix soon, good luck.