Xojo/MBS: Trying to import to the Photos library

Xojo
1

For the Mac version of a longstanding project, which downloads image files, I am desiring to add the option of seamlessly depositing them in the Photos Library. The linked example simply imports a local file of the user’s choosing.

This project works perfectly on my M1 Mac (current Tahoe beta), but on neither of my Intel machines (15.6.1.)

This puzzled Christian, who saw no issue at his end, though he did not explicitly say that he ran “my” project.

For me, on Intel the changeCompletionHandler reports success, but in the debugger, with breakpoints and logging in the change block, it appears as if the change block does not fire at all. Again, all appears as expected when I debug on the M1.

On my daily driver iMac Pro, I had had the Photos library on an external drive. I have returned it to the main SSD, and even subsequently repaired the library. This did not help.

I am here instead of TOF because I know there is a lot of talent here. I’m just running the risk that Thorsten will tell me all about Java. :slight_smile:

The example project is available at here, at my website. I will appreciate and acknowledge any help. And if it DOES work for you on Intel, that will really blow my mind. :slight_smile:

Edit: This project is on Xojo 2025r2.1, and requires the 25.4 MBS plugins. Christian did fix a crashing bug for me. But that still leaves silent failure on Intel.

2

Thanks for the help, Christian. For the curious, adding this to the change block method will allow the project to work properly on Intel.

#Pragma StackOverflowChecking false
#Pragma BackgroundTasks false

3

How odd THAT would matter

3 Likes
4

Christian supposed that we were throwing a stackoverflowexception on Intel.

5

So ignoring masks the problem but doesnt fix it ?

2 Likes
6

To me proposed solution feels wrong, I think stack overflow exception should be unrecoverable. Correct solution would be to figure out the cause and maybe increase the stack size, if code is recursive.

3 Likes
7

Whatever exactly is going on, without the Pragmas the change block method is just skipped on Intel. There is no crash.

Whether this is a plugin issue or a Xojo one, I have no idea.

Edit: it is worth noting that the change block runs in a macOS (i.e, non-Xojo) thread.

8

The change block runs on a non-Xojo thread. I’m just going to guess that running it, on Intel, makes the Xojo framework throw a fit and a false positive here. I’m sticking to that till someone sets me straight. :slight_smile:

1 Like
9

Xojo are not going to fix it, I had a feedback for it, but they closed it.

I was complaining that more and more of Apple’s API uses blocks and this makes it harder to stick with Xojo while supporting newer versions of the macOS.

Blocks are awesome in Swift.

3 Likes
10

This is something like the stack checking function looking up the stack size for the thread, but since it doesn’t find it in some table, the stack size is always zero and you always get an exception raised there, that you can’t catch.

this issue hasn’t been fixed for 10+ years, so just use the pragma.

2 Likes
11

I could show them this, but I know from experience that they won’t touch a ticket where plugins are involved.

1 Like
12

Hi Sam, i don‘t find info about Blocks in Swift, do you mean Closures?

13

Not sure what that manifests itself as in Swift

14

In Swift, yeah they’re called Closures in Objective-C they’re called blocks.