My application is working on Windows and Macs (including my 2 year old MacBook Pro). However, the users of brand new Macs are having problems running the same code that works on slightly older Macs. Is there some hardware change that Apple has instituted in the newest MacBook’s which cause Xojo to behave slightly differently? Related to this, when will there be a new release of Xojo which may address.
My application reads a registration file to authorize the user. And the new Macs are either not reading this little text file properly, or garbling the contents somehow - and cause the program think it has no registration and die. I am planning to try to get access to one of these machines and install Xojo and my source code to see if I can isolate the issue.
I presume that probably it has to do with the path your registration file is saved and that some OS update may have decided you have not the rights to access directly now It’s always good idea to use the “regular” or authorized folders designated by the OS to save this kind of files (those availables even if the user has the lower rights to deal with files or access determined paths at the filesystem level).
It would be good having some piece of code or “idea” about how your app saves the file (its contents), because of your mention about the os “messing” the file contents (text content? binary?).
I don’t think it has to do with the new hardware (or changes in the hardware) made by Apple except if your licensing scheme takes some piece of it as a reference (you can see how GuancheID deals with this, so it gets a unique ID reference for the Hardware an app is working on).
If you’re using GuancheMOS for your licensing scheme, please get in touch with me and I probably can help you further!
I’ll add a second for “App Translocation”, but it would be really helpful if you provided macOS versions for working versus non-working and what version of Xojo you are using to compile.
Emile… this is one of many reasons it is not reccomended to place any data file in the same folder as your app… When translocation kicks in (Not an ElCap feature), the actual application is moved by the OS for security reasons. Therefore the running app is no longer in the same folder, therefore when the app goes to look for the datafile that is supposed to be in the same folder, it isn’t anymore… because the APP moved, but nothing else in that folder did…(or should)
so you have
myFolder/myAPP.app
myFolder/mydata.txt
but when it runs (if translocated)
you end up with something more like this
[someplaceelse]/myAPP.app
myFolder/mydata.txt
the running app would be looking for [someplaceelse]/mydata.txt and it won’t be there
And just to add information for future readers, read-only files that should stay with the app should go inside the apps resources folder in the bundle. Anything that needs write permission that you dont want the user to explicitly deal with, goes in the Application Support folder. The structure there can be anything you like, but being a good developer means using either your bundle identifier or CompanyName/AppName.
Thank you everyone. I really appreciate the help. I am under pressure to solve this and have no idea what is happening.
When my app starts, it looks within a “Settings” folder in the same location as the app, and then reads a registration file with some encoded information. I did read above and learn that the OS may move the app. However, this works fine on my 2016 MacBook Pro running the newest Mac OS 10.14.6. So its not a problem with the OS directly - its the OS on new hardware. When this same code is copied to a brand new Mac, then it gives an error - either a crash (an exception) or more often that the license file only allows 0 items to be processed - which suggests it might be garbling the license file which has that info encoded. But if its copied back to an older Mac, it works fine.
The code was written originally in 2003 in Real Basic, and updated heavily over the next 5 years - with just minor changes from time to time since then. There are many things I would do differently if I were to re-write it now.
If it does not find a license file, it will indeed run in DEMO mode but not allow saves. Which is not what is happening. It looks like its finding a license file but not reading that file improperly and saying that the user has no permissions.
This registration file has the user name, company name, expiration date, and number instances encoded. Its a series of about 10 different methods applied one after the other - something I wish I had not made so complicated now. One of the operations is to use bit-wise AND and XOR’s. And scrambling the order, and adding random stuff. So one possibility is that one of those functions behaves differently in XOJO on the new Mac for some reason - as far fetched as that sounds.
The app code itself is thousands of pages, so not practical to upload. Even the encode/decode software is probably 40 pages or more. I have asked to have access to one of these machines, and want to install Xojo and my code, and then I can run it in debug mode.
Just because it “works” on one and not another doesn’t mean this isn’t the issue… Follow the proper guidelines as stated above, and THEN come back if the issue still exists. If you continue to work under a non-prescibed scenario, then we can no longer provide any more insight.
Where can I find information on the recommended way of doing this (reading a specific file on startup)? It seems impossible to prescribe a specific directory otherwise. I suppose I could force the user to manually find the license file, and then store that directory information … but where would I store it, so when the program fires up next time I can find it?
