As always I am concerned about updating UIs. It seems I’ve been generating exceptions during WebListBox updates.
I wanted to make sure that I understood the sequences of events that are safe.
In this example I am implementing a command processor that shells out a command at a time to the System.
The shell executes in async mode and when the command completes I want to add the resulting line of text from the command to be added to a listbox on my web page.
I’m not sure that the timer on the App is necessary or if I can eliminate it.
I’m not sure if I need a queue property on the webpage (to queue result strings) that is serviced by a timer on the web page.
Enable a single shot timer
In the timer event tell the shell to execute a command in async mode
When the Command Completed event is received iterate through the sessions and tell the currentPage to update its listbox via it’s updateListBox method.
Enable the single shot timer again and the whole process repeats.
Since this is web, none of the thread/UI update issues apply. (Besides, you’re not using any threads.) I don’t see any reason for a timer. Send the first command to the shell. When it finishes, update the weblistbox and start the next command. That can all be done from the shell’s DataAvailable or Completed events.
I was under the impression that each session of a web application ran in it’s own thread.
I thought that if the updatelistbox method took a long time then the main app would be blocked and become unresponsive.
If I try to do another update while the first update is still in progress then that would really confuse things…
What you really want for this is a queue for each Session. The queue has items which might typically be (action, parameter list) pairs. From outside the Session, queue up the actions. On WebPages have a recurring WebTimer. Perhaps it fires every 2 seconds or so. It’s action is to call some method in Session that processes some items in the queue. Doing this will help you avoid problems with web session contexts, and should keep your web UI pretty responsive. You might even implement some advanced logic like when you add an action to the queue, scan the queue and eliminate redundant actions. Think of a progress bar. If it’s going to be updated 100 times in the next few seconds, maybe remove most of those pending updates.
The sessions themselves don’t run in their own threads. It’s the requests from the browser that do. So if a user clicks a button in your app, a message is sent to the server and a thread is spun up to handle that request. When the request is complete, and data is sent back to the browser, the thread dies.
The real question is: What is the shell process in response to? Is it in response to user interaction? Or are you running a background process and trying to update the user (all users?) with the results? In other words, is the user getting an active response to his interaction with your page, or is he sitting there passively getting the results of some process?
If you’re responding to some event, then the code in that event is threaded for you by the framework. If you have a background process, then it’s up to you to thread it such that it doesn’t block the app. And if you are running in a thread, there shouldn’t be a problem updating the UI, provided you fetch the appropriate session and set the context.
Hi Tim. This seems really overly complicated. All this is doing is processing shell commands that are put in a database from another process. The results are then placed on a listbox with formatting according to their status.
The idea is to do everything as async as possible without threads.
I had one version with no timers or queues and did everything in the shell complete event.
However that caused a lot of exceptions and the app died. So back to the drawing board to make sure I was doing things correctly.
