I have a program I sell, it is compiled in RS2011r3, Carbon, 32-bit. Thousands of people use it, and many use it in the newer macOS - 10.12, 10.13 etc. All is fine.
I have a user that recently tried to use it on his 10.12 machine and it doesn’t do well. I diagnosed the issue and found that the graphics included in my project aren’t “loading” when the code asks it to BUT ONLY ON HIS SYSTEM. These are regular PNG files, and the code looks like this:
Dim P As Picture
P = player_play // a PNG file included in the project
Canva1.Backdrop = P // In his computer, P is Nil, because player_play is Nil
But on my 10.12 computer - and evidently all my other clients - everything isn’t Nil and all is fine. player_play.png is a 32x32 graphic at 16 million colors, it’s extremely normal.
I sent my client a basic project compiled, with only the graphics included and code to display it in a Canvas. I compiled one for Carbon/Intel, and the other for Cocoa (which is beta in RS2011r3). On his system, the Cocoa build displays the graphics (thus not Nil) but the Carbon one does not. (Again, all this works on my 10.12 computer.)
Why would his particular computer have this problem? Is there anything I can suggest to him?
Offhand, no obvious reason springs to mind.
(If it had been the other way around, and Carbon worked but Cocoa didn’t, I might have been tempted to say that what you think is a PNG file might actually be a PICT file with the wrong extension.)
How I address issues like this is to change things until I see any difference at all.
Since you and they are amenable to that (many developers and/or customers never consider it!) …copy the image and export it as a GIF
Delete the PNG from your project and drag in the GIF
Build a version for carbon and send it.
Does that work?
If so, does the PNG use alpha channels or other ‘more advanced’ features?
I am guessing that Carbon and Cocoa use different system API for loading images (could be a Xojo thing or it could be an Apple thing).
If it only happens for this one customer on one machine, then I’d suggest doing a clean install of his OS as something is broken. Make sure to use Time Machine to backup first, I am finding that customers are getting used to re-installing their macOS.
There are about 3 different ways to open an image that I know of (via API) and if you factor in Carbon, Cocoa32 and Cocoa64, that’s at least 9 ways and which one could be broken.
Going forwards you need to get your application Cocoa 64 ASAP, Apple have already started telling end users that non-Cocoa64 apps are slowing down their computers (no love that’s your crappy OS updates slowing down people’s computers).
Before suggesting something so drastic, how about we find out if there is something different about this machine. A lot has changed since those days ( in RS/Xojo as well as the OS).
My first instinct is to see if the guy will send you a System Information profile. Dont publish it until the machine serial number has been removed though. Its a plist file so its pretty easy to find. There are two, one as xml with the key serial_number and one as text with a key IOPlatformSerialNumber.
Anyway that file might tell us what we need to know.
(I’d be happy to look at the file and see if anything jumps out at me if you want to send it to me privately)
Are you sure it’s 10.12? I had something similar happen with 10.13.4 beta - resource pictures were mysteriously replaced with garbage data - I wonder if your user might have upgraded?
Thanks Greg, I’ll do that. And just to clarify to people:
I wrote this on March 31st so it’s not a April Fools thing =)
Carbon works fully and completely on the latest macOS, any fallout from the deprecation warning hasn’t occurred yet. It is also irrelevant to this issue because it’s just a simple task of loading a simple PNG file (the way RS does it internally).
Important: it’s this guy vs. tens of thousands of my other customers. He’s the definition of an Outlier, so we aren’t looking for fundamental issues relating to the app itself.
The troubleshooting with a GIF is interesting, but what would that really tell me? I certainly am not going to replace all my graphics with low-res GIF’s. That’s the point of using PNG’s -the compatibility factor. PNG’s are meant to be compatible.
My graphics are definitely PNG, I’m a leading world expert on file formats =) I even hex dump my files to check when necessary.
We already know the PNG’s aren’t getting loaded. If we find our GIF’s load, there’s no news in that.
And back to “why Carbon?” I’ll skip any details, I don’t have to defend it, but my apps will have 64-bit Cocoa versions shortly. I was waiting for Xojo to actually “release” 64-bit and give it some some breakdown time before I bothered. That only was recently. I’ve been in the REAL game for too long and I’ve learned my lessons.)
Hrm. So I’ve looked at the sample project and I don’t see anything specifically wrong there and at the System Information report and certainly don’t see what I expected (which was that the system drive had been formatted as case-sensitive.
Since you have a current license, you really ought to build your sample app, as-is, using 2017r3 and send it off to the customer and see if that fixes the problem. I’d hate to be chasing down a problem that no longer exists.
Thanks Greg. (I was thinking the same - the case thing). I also suspected permission issues, but he tried the app in various locations and got the same behavior.
I’ll try a Xojo compile - but the Cocoa compile in RS2011r3 (the sample app, not the large app in question) works for him, so a Xojo compile by definition is Cocoa so we already know it’ll work.
Still, it will be just trivia for him, since the large app in question is months away from being built in Xojo. But he’ll have to accept it - the app works for thousands of others. I was just looking for a solution for his sake. He’s a longtime customer, but it’s hard to contest the “all my other apps work fine” objection.
You probably did check this but maybe that customer has his system formatted with CaseSensitive. Make sure the filename you load has the exact same filename (case sensitive).
I ones bumped my head on this.
At last report the customer is getting really angry at my company (me). We’ll see if he comes to his senses or just gives up. There’s a number things we can try. If there’s anything I’ve learned over the decades (thanks in part to the REAL/Xojo guys), it’s to ignore the blame game and just be a problem solver.
Greg, I would like to know (if possible) what API RS2011r3 used to load these resources/graphics - full color 32x32 PNG’s. Perhaps I can call it directly and see if I get an error code that helps (since the app is obviously silently failing).
There are people whose configuration is so strange or so corrupted, nothing you can try will magically fix the mud bath your poor app is supposed to execute in.
However, it is indeed possible to load the picture manually. The pictures dragged into the project are in the Resources bundle subfolder. Since Tim Parnell’s excellent TPSF does not work in RS2011, you will have to use App.Executablefile as starting point.
For instance :
[code] dim f as FolderItem = App.ExecutableFile.Parent.Parent.Child(“Resources”).Child(“group_edit.png”)
if f <> nil and f.exists then
dim p as picture = picture.open(f)
self.backdrop = p
end if[/code]
You can wrap all that into a method to make it simpler. I do hope your customer’s machine from hell won’t ruin that either.
It is even possible to store the pictures in constants as encoded Base 64 and use them directly from inside the code, without any loading from disk.
At one point, though, you got to question the logic in doing extraordinary things for one customer. Unless of course he is an excellent customer.
