We’re told that threads cannot communicate with the main app but can threads communicate with each other?
threads can access properties, even those from main thread or globals.
Or what kind of communication do you need?
I would considder creatng a class and have a referece to the object accessable focr all threads.
FWIW multiple threads (and apps) can access a multi-user SQLite database as a means of communication of data of any size.
I’m creating a thread to print to a PDF but sometimes calculations will have be performed, called from the print thread. If the calculations need to be a thread also, I’d rather not create some huge thread that involves everything my app does
threads can call global functions and methods in your app and those methods / functions will run in that threads context
Just to clarify this: A thread must not access a GUI element. It can otherwise communicate fully with the app, while you should be aware that as Norman said method calls from a thread will inherit the thread context.
For these tasks, thread has the new UserInterfaceUpdate event.
Thanks Ulrich. My calculations write to a database rather than the user interface so I should be good to go . . . Anyone disagree?
Not me. Also not David if you read his reply 
Nope. As long as you don’t touch a UI element (this means even a property of control) you’re good to go.
Desktop threads cannot access the UI.
But that is not true of Web threads, which can access the UI, and communicate with each other.
You could start the print thread from the one that computes, when it is completed.
Or you could set a flag, a boolean property, when calculation is complete, and have a timer check every second or so that it is set to true, to start printing.
Still, creating a singleton object for the communication between treads is my best option and in line with the OOP principle.
Does cannot access a property of a UI element include containers?
Depends on what you’re accessing in the container. If it’s a property defined by you you’re okay. If it’s a property of a UI control then no.
The way I get around this in classic API is using a variant of the Task Thread which fires a timer (if you recall, timer.action event fires ONLY on the main thread) and then I can pass whatever information back to the UI.
In the API 2 there’s a new event on threads called UserInterfaceUpdate that is doing the same thing for you but it’s built-in. Frankly, one of the better enhancements in API 2.
I recommend having a message queue class.
The queue will contain messages that a thread or timer (main thread) can access to send a message or d-queue a message.
[quote=475247:@Bob Keeney]Depends on what you’re accessing in the container. If it’s a property defined by you you’re okay. If it’s a property of a UI control then no.
The way I get around this in classic API is using a variant of the Task Thread which fires a timer (if you recall, timer.action event fires ONLY on the main thread) and then I can pass whatever information back to the UI.
In the API 2 there’s a new event on threads called UserInterfaceUpdate that is doing the same thing for you but it’s built-in. Frankly, one of the better enhancements in API 2.[/quote]
The question was posted in the Web channel. What you describe is for Desktop.
Web threads can access the UI.
Here is a small project demonstrating how WebThreads access directly a Web project UI.
For web projects, the UI access is not a big problem.
But you may need a WebSessionContext object for session access.
Indeed. Session is not accessible in some cases.
For instance, no session in server side Timers, as opposed to WebTimers (what you get as default).
Or no session in HandleURL.