Greg,
I can confirm your words.
Sending events to the browser from different threads CAN cause problems like javascript errors or inconsistent results.
The best way I have found it is to generate a timer event in the browser, just like in a desktop app, and sending data to the client from the action event of the timer.
This is very similar, if not identical, to what must be done in an desktop application.
Desktop or Web, if you write in the same way for sure you are on the safe side.
I posted a UML sequence diagram on updating UIs. (From a shell event, but theoretically it should work for threads).
Would any one care to tell me that it is correct and that I’m not confused?
If it is wrong please say so.
After rereading both conversations, I would recommend this approach. Have a WebTimer poll the app for results.
From the docs:
Up to now I have had no problems doing this way.
In the WebPage insert a WebTimer programmed in ModeSingle with the shortest period i.e.1.
When required, usually after the user has generated an event on a WebControl, starts the background thread for the long or asyncronous operation.
When the background thread has something to notify to the user the thread starts the WebTimer with the Reset() method.
In the WebTimer.Action() event do what it is required to update the WebPage.
This does not generates polling and works like in a desktop app.
Updating the WebPage in WebTimer.Action() guarantees the correct sequence of data sent to the browser with a predictable result and no javascript errors.
Be careful to notify only a single event: if the background task has more than one event to reports you must arrange what it is required to coordinate the above descripted sequence of operations.