AddressOf it is of any use on Windows?

Under Windows7 I’m trying to use AddressOf as stated in Notes of the docs.
The docs example refers to the Mac platform but I’m supposing that the same can be done also on Windows.

The function passed to AddressOf it is a public one defined in a module and the first line of this function does contains:
#Pragma X86CallingConvention StdCall

All works as intended when the function it is called from the DLL synchronously with the application:
app calls DLL -> DLL calls the app function using the function pointer returned by AddressOf.

When the function gets called asynchronously by the DLL (as usual for a true callback) the application crashes and the error gets trapped by Windows.

The app function called does nothing special: a simple assignment of a property declared at the App level.

I know that Xojo isn’t thread safe and the internal thread model it is cooperative.
So, as for the conversation title, AddressOf it is of any use on Windows?

Best regards.

Yes. What you outlined above should work.

No Tim, it crashes…

Maybe I’m doing something wrong?

That’s what I’m suggesting.

Async or preemptively ?

Additionally, is it an instance method or a shared method?

Hi Norman and Joe,
thank you for your interest.

The method it is a global one defined in a module and gets called by an external DLL when something (totally unrelated to the app activities) happens.
The call can be considered async and preemptive i.e. I can’t predict when the method gets called.
The fault happens on both console and desktop applications.


As far as I know it only works with shared methods, not with instance methods and not with module methods.

Async should be OK.
Preemptively might be an issue.
Callbacks as module methods should be fine since their entry point won’t come & go like a instance vTable entry.
Instance methods could be a problem since the instance could go out of scope or be otherwise destroyed & then a callback tries to access the methods entry point in the vTable that no longer exists. That would be a problem.

Can we assume this behaviour common to all supported platform and not related to Windows only?
There is a way (I think not) to convert an preemptively event to an async one?

Best regards.

This is false. It works with module methods and shared methods.

[quote=75856:@Maurizio Rossi]Can we assume this behaviour common to all supported platform and not related to Windows only?
There is a way (I think not) to convert an preemptively event to an async one?

Best regards.[/quote]

Can you say what function you’re declaring to that you’re seeing this behavior? or is it a custom DLL that you’re declaring into?

It is a custom DLL that I use with some declares.

All it is working as expected but not this “async and preemptively” function.
The DLL does some custom communication with external devices.
In some circumstances some devices needs to report back some async events and in this cases the DLL calls a registered callback function i.e. a Xojo method.

So these events are async and preemptively because the DLL creates itself some threads for the communication task.


I don’t know if you can make it work from a preemptive thread. You could try adding the following pragmas to the top of the callback function:

  #Pragma DisableBackgroundTasks
  #Pragma StackOverflowChecking False

Also, keep the callback as simple as possible. Nothing that would allocate memory, no calls into the Xojo framework, etc.

At one time I had a plugin for preemptive threading. MBS added similar features. We both dropped it because of the severe limitations on what you could do and the unreliability even when you adhered to those limitations. But for my plugin at least those pragmas had to be at the top of any method called by the thread.

As a work around you might be able to create a callback function that uses Win32 to post a message to be processed by a window in your app. The callback would be called from a preemptive thread, but the message handler would execute normally on the main thread if you use PostMessage. Not sure if you could pull this off in Xojo or if you would have to write/compile a small library with the callback function in it.

As I recall Windows Functionality Suite has sample code and helper methods for setting up a window or control to receive and process messages, so that part can be done in Xojo.

Yeah, the preemptive thread in the DLL is probably the problem. Posting a message to the window should work around it.

There’d have to be a small library or plugin to deal with punting whatever callbacks are needed to a Xojo thread. Any running Xojo code must be on a Xojo thread and not a pre-emptive thread. Attempts to make Xojo code work on a pre-emptive thread may initially appear to work but will absolutely run into issues down the road.

Joe - would that be true even if the callback function does nothing but declare and call PostMessage?

I ask because even though I dropped the plugin, I never saw problems with preemptively threaded functions that called OS APIs but otherwise didn’t do anything in Real Studio / Xojo, including anything that could trigger memory allocation / deallocation. That seemed to be the one potentially useful thing you could do preemptively.