I tested the other project by taking out the MBS and forcing it to go the other part.
it was ok both as arm only and as Universal (on M4 Tahoe without any Rosetta installed)
But I dont think it was really a valid test…. since:
a) We dont know what Xojo you used to compiled your app that failed.
b) if the user is dragging in a picture file then it will always go the MBS way in your code, so hard to know if that affects it.
In example project (and original application) MBS is only used if the use drag a folder or an application, but in this case the user drag a PNG picture that I have send it to him.
I have run into obscure bugs on macOS where some video/picture operations fail, depending on what GPU the user has. The ultimate cause seemed to be a GPU driver bug and there was no easy way to fix it. Perhaps ask about GPU ?
It does not… though
If Obj.PictureAvailable then
// Only gets here if you get Picture Object………. not if you get Picture File
Problem exists on these machines:
OS X Version 13.7.2 (Build 22H313)
Memory 32GB
Screen 1 resolution: 2560x1440 • 24 Bit
Model Identifier: iMac14,2
Processor Name: Quad-Core Intel Core i5
Processor Speed: 3,2 GHz
OS X Version 15.6.1 (Build 24G90)
Memory 16GB
Model Identifier: MacBookPro18,3
Model Number: Z15G0008QD/A
Chip: Apple M1 Pro
OS X Version 26.2 (Build 25C56)
Memory 24GB
Screen 1 resolution: 2560x1440 • 24 Bit
Screen 2 resolution: 2560x1440 • 24 Bit
Model Name: Mac mini
Model Identifier: Mac16,10
Model Number: MCYT4D/A
Chip: Apple M4
I ran on 24 Gb mini M4 on Tahoe
But of course not running same code as shown above. (and we dont know what Xojo you used)
The application was build with Xojo 2025r2.1
The test project (MBS and all) seems to work as designed on my iMac Pro with Sequoia. I have an M1 laptop with Tahoe, but haven’t gotten there yet.
But instead of obj.PictureAvailable, I would have done something like:
Var f as folderitem=obj.folderitem
Var p as picture=Picture.Open(f)
if p<>nil then //etc,etc
Edited
Good info - if you are seeing this on M-series GPUs, then it’s probably not a GPU related bug. The kind of bugs I’m thinking of would only be showing up on older Intel machines.
Another idea: could this be a locale issue? Data that should be parsed as “1.234” is being interpreted as “1234” or vice-versa due to comma vs. decimal point differences based on different language/locale settings.
No, I use the same language “German” “de_DE” as the customer.
Now I run my application in debug mode with Xojo 2025R3 on an old Mac Mini (Intel Core i5) with macOS 15.7.3 with Intel UHD Graphics 630 and I got the same error:
Run that test again and show us the properties of the picture that you’re trying to save.
It is a normal picture. All pictures that I have tested work on Apple (ARM) M-CPU, but not on Intel.
In the documentation is an example how to save a Picture to PNG.
' Save the image out to the file
ImageWell1.Image.Save(f, Picture.Formats.JPEG)
If I change my code to this, I got the same error.
Sub SaveUserPicture(MyPic as picture)
dim f as FolderItemif PictureFolder <> nil then
f = PictureFolder.Child(ArtikelID + “.png”)if MyPic <> nil And f <> Nil then
MyPic.Save(f, Picture.Formats.PNG) // Picture.SaveAsPNG) end if
else
MsgBox “PictureFolder not defined”
end if
End Sub
I want to see the properties of the picture object you see trying to save. Post a screenshot of its properties in the debugger.
Just to humor us, can you try this, and see if anything changes…
Sub SaveUserPicture(MyPic as picture)
dim f as FolderItem
dim cpy as picture
cpy = new picture(mypic.width,mypic.height)
cpy.graphics.drawpicture mypic,0,0,cpy.width,cpy.height,0,0,mypic.width,mypic.height
if PictureFolder <> nil then
f = PictureFolder.Child(ArtikelID + “.png”)
if MyPic <> nil And f <> Nil then
cpy.Save(f, Picture.Formats.PNG)
else
MsgBox “PictureFolder not defined”
end if
End Sub
I wonder if the Alpha channel is preventing it from saving. Perhaps Xojo doesn’t support this. In any case, the fix for this is what Jeff has just suggested: draw it into a new picture object and save that.
To lose the alpha channel, the new picture() needs to be picture (mypic.width,mypic.height,32)
If Xojo doesn’t support it, why it rund on Apple M CPU without any problem?
