Xojo UI Crash When Calling C DLL with Async Callbacks on Windows

Targets Windows
1

Hello Xojo and C Developers,

I’m facing a challenging issue where my application crashes after invoking an asynchronous C function from Xojo. The C function is expected to perform an operation in a new thread and then call back to update the Xojo UI after a few seconds. However, approximately three seconds after clicking the button that triggers the operation, the entire program crashes.

Here’s a snippet of the C code handling the asynchronous operation:

typedef void (*SimpleCallback)(void);

void *thread_func(void *arg) {
    SimpleCallback callback = (SimpleCallback)arg;
    sleep(3); // Simulate some operation
    callback();
    return NULL;
}

int start_async_operation(SimpleCallback callback) {
    pthread_t thread;
    int result = pthread_create(&thread, NULL, thread_func, (void *)callback);
    if (result != 0) {
        return -1;
    }
    pthread_detach(thread);
    return 0;
}

And this is how I’m calling it from Xojo:

Declare Function start_async_operation Lib "Trxel.dll" (callback As Ptr) As Integer
Dim myCallbackDelegate As Ptr = AddressOf MyCallback
Dim result As Integer = start_async_operation(myCallbackDelegate)

Upon button press, start_async_operation is called with a delegate to MyCallback method. The program crashes without any exception or error message after a delay of about three seconds, which corresponds to the sleep duration in the C thread function.

Attached is the screenshot of my Xojo project where the DLL is being invoked.

I’ve attached a screenshot of my Xojo setup for reference.

image
image1455×832 51.7 KB

I suspect the issue may be related to thread safety or improper synchronization when calling back into the Xojo UI thread from C. Has anyone encountered a similar issue, or does anyone have insights on ensuring the callback updates the UI safely without causing a crash? Any suggestions or advice would be greatly appreciated.

Please note that I am a student on campus and currently cannot afford paid subscription plugins. Hope to find a way to solve this problem without using any paid plugins

Thank you for your time and help!

2

Unfortunately, Xojo’s concurrency support is very poor and you can’t call back to Xojo from a preemptive thread.

I think you might have to use the Xojo plugin SDK to trigger a Xojo timer that runs on the main thread and performs the callback.

Hopefully Christian or Björn will provide a better answer than me.

1 Like
3

Xojo has no support for running real threads.

All you can do in your callback is Read and write number properties, no strings no objects, etc. Since even reading or touching string or object will cause crash in Xojo’s linked list memory manager.

As Kevin correctly said then you can use timer to “Ask” the thread for data.

And of course thread cannot really ever be used directly to update UI of any kind.

1 Like
4

image
image1455×832 49.2 KB

Thank you for your suggestion. I must say that I have tried updating the UI using Timer and intermediate variables, but failed. As shown in the screenshot, even if there is no code in the MyCallback function, the entire program will still crash after 3 seconds

5

Thats because the signature of your callback is incorrect.

For example you made it a method on the instance, if that was correct then in the C code the first parameter for the C code to call would be pointer to the Window.

So you need either callback in a Module or if its on Window or Class instance then it has to be Shared method.

1 Like
6

Sorry, I don’t seem to understand how to operate. Could you please explain in detail or do you know where similar examples are available?

7

You can use DeclareCallBackMBS class in MBS Xojo Util Plugin to receive the callback and then forward it to Xojo in a safe way.

8

I have used this plugin before, but I found that a paid subscription is required in the end. But I am still a student and currently do not have the ability to pay

9

A method on a Window or a class has the anatomy when seen from point of view of C/C++:

MyMethod(REALobject* self)

While a method in a module or a Shared Method on a Window or object has the

anatomy when seen from point of view of C/C++:

MyMethod()

Obviously your C++ code does not fullfill the former to send in the self pointer of the window which is why you crash.

Which is why a callback like that needs to be Method in a Module or Shared Method on a Object or a Window.

10

You could try passing a ptr of a delegate pointing to a method in a module, which takes Ptr or Integer parameters and then stores values in global properties.
Then you can have a timer check regularly if the properties got set, so you know the callback arrived.

The method in the module must have background tasks, nil object checking and stack checking disabled via #pragma.

That could work.

1 Like
11

Thank you for your help. I will try it out

12

Thank you for your help. I will try to improve it

13

Ohhh, I have succeeded. Thank you very much for your help!!!

2 Likes