But as I said it is complicated and has severe limitations. Cannot run anything at all from Xojo there in the green zone. (Especially not anything that creates object, releases object or references or de-referencs)
I don’t know of a way to do async processing in C# or C++ that would have any awareness of a Xojo structure that it could update.
Have you considered using a Xojo worker and having it return some sort of struct you could decode, or have it just write a bunch of key/value pairs to a text file you could read? It would be ugly / fragile but if I properly understand what you want to do, I think that might fit the bill.
Gather the info from the UI into some sort of structure or formatted text
Pass it to the worker
Get the changed info back at some later point when the worker is done and the main thread is ready / needs to deal with it.
Put the returned info into the UI
Obviously you have the extra overhead of (dis)assembling this data passing structure but one could probably make it somewhat generic (name of control, key/value pairs for desired info).
If you want to have the async task examine the UI and make changes to it, I don’t see how you’d do it safely and without epic amounts of reverse engineering unless Xojo exposes an API for an external process to walk through the Xojo object graph AND make changes to it. Which I’m guessing they do not.
Yeah I dont think a worker will work here because of the required access to the UI
Serializing the entire UI to send to a worker just wont be feasible and still has the issue of it NOT being synchronous like async await
I need a way to punt a method call into the main thread synchronously - Timer.CallLater can “sort of” do this but the issue is I get the returned value AFTER I need it
Which is where something like async await would be nice since that will run an async task, possibly on the main thread, and wait until that has completed
But Xojo doesnt have async await so I’m trying to figure out how I might fake that - with or without a plugin or lord knows what else
Not totally clear what you’re trying to do (“… as some will be in Xojoscripts and some not…”), but as a strawman:
In the thread, call a local proxy function for the one you want to call on main
In the proxy, set parameters on the thread class (or, if we want to be really generic, serialize parameters into some structure… this is where what you’re doing isn’t clear to me as far as how generic this needs to be – example would be helpful)
Append a flag, indicator or pointer referring to the thing you want to call in an array on the main thread (again, this could be simple for a single call case, or super generic if you need it to work with anything). You’ll also need a reference to the calling thread here, as well
Call pause on the thread → context switches while stopped in the proxy function
On main, you’ll need a timer to examine the array of call references and dispatch the function you want (again, could be a single thing or something more involved to handle the generic case… examples?)
In the function on main, if you need to return something, use the reference to the calling thread to write it to a proxy variable there (there are other ways to manage this, of course)
Resume the calling thread(s) at the end of the timer run (and clear the dispatch array)
Thread resumes in the local proxy function. Grab the value “returned” from main and return it from the proxy function. From the thread’s perspective, the function on main has been called synchronously.
Yeah this is a lot like what a future would do ( in C# its compiler magic that takes it and turns it in to a finite state machine that blocks the original call into the code until the function called returns)
Let me see if my little example demonstrates my conundrum well enough and then I’ll post it