@crocodile
I moved your post to a more relevant topic, since this has nothing to do with typed properties or the experimental build.
Modeless menus allow new
script threads (a.k.a. quasi-threads, pseudo-threads) to run without freezing the menu, because the menu gets input from dispatched window messages, like a GUI, instead of by polling (repeatedly calling
GetMessage to "intercept" keyboard messages). It has nothing to do with real/OS-level threads which are the cause of the problems RegisterSyncCallback was designed to solve.
The limitation is not with callbacks, but with AutoHotkey itself being unable to execute script code safely on any thread that isn't the program's main thread. RegisterSyncCallback works around this by sending a message to the main thread so that it will execute the script function. It would not matter how many threads we create, whether it's for showing modal menus, performing file operations, hooking the keyboard, or whatever; the callback won't be called on one of those threads, and if it was,
it's still the wrong thread for executing script code.
Now that I have put a
little thought into what built-in support would actually look like, I wonder if there even needs to be an option or function for it. Script code cannot execute safely on any thread but the main thread, and checking which thread the callback is executing
probably wouldn't affect performance, so perhaps it can just automatically synchronize with the main thread.
RegisterSyncCallback passes the function object and parameters in a window message, and blindly executes any function that it receives in a message. This is not ideal. If AutoHotkey had an internal mechanism for queueing threads, as I described above, it could be trivial to implement securely. Given that I already plan to work on the queueing mechanism, I intend to do that first, as I said.