Visual WebGui is a web application framwork and as such, it uses the Request/Response model.
In this model, only the Client can initiate a Request and only the server can return a Response to the Client's Request.
Until a Reponse is received on the Client, it will not respond to further user actions, nor will it update it's UI.
This proposes various implications for Requests that will take considerable amount of time to process on the Server, as the Client is left unresponsive and it's UI will not update.

Using HtmlBox, AspPageBox or Wrapped ASP.NET third party controls, you often want to update the UI of your Visual WebGui application from within these controls's code.
You should realize though that those control's internals are using a separate Request/Response pipeline to the server, not communicating through the Visual WebGui pipeline.
As a result, updates will only occur on the Visual WebGui server-side (the Client will not be immediately updated).
This will cause the update in the Client UI to occur only by the Response sent in accordance to the next Visual WebGui Client request (over the Visual WebGui pipeline).

This article will explain the processing and present various methods you can use to make sure the UI on the Client will update and be responsive as much as possible.

Let's take a look at what happens in terms of Request/Response and UI updates, while processing a single Click event on a Button where you have registered a Click event handler.

• The user clicks the Button on the client.
  
• The client issues a Request to the server, indicating a Click event was raised.
  
• The server processes the Request, recognizes it's a Click event and fires the server-side Click event handler - your server-side code.
  
• Your Click event handler code runs to completion, updating server-side any and all properties as indicated by the code.
  
• The server recognizes there are no more processing to be done and returns the Response back to the client.
  
• The client processes the Response and updates it's UI based on the results.
  

During the processing (step 4) the server-side queues all updates that need to be performed on your client UI, and when the response is returned to the client (step 5).
The response will include information on all the pending and required UI updates that have been queued since the last Response was returned to the client.

Looking at these steps, it becomes obvious that it is not until step 6 that the UI on the client actually gets updated. This means that any lengthy processing in any of the other steps will delay the UI updates until they have finished processing.

It should be known that as long as code is running on Visual WebGui application server-side, the Client will show the loading-icon (or loading message) and no direct action will be allowed on the page.

To imitate a Windows Forms application behaviour, and to keep the ASP.NET session alive for a Visual WebGui application, your application sends a so called Keep Connected Requests to the server on a regular basis. The default is to send this request every 2 minutes. See more on KeepConnectedInterval.

This type of request is sent automatically and asynchronously by the Visual WebGui client kernel code, meaning that although your server side is busy processing a request (in step 4 above), this type of request will still be sent to the server on a regular basis, as indicated by the web.config configuration setting. This request has the same effect as any other client request being sent from the client to the server, and when the server returns its response, the UI in your application will update with all the pendingupdates, leaving less to be updated when your "formal" request returns it's response.

Adding a Timer control to your form and registering a Tick event handler for it does indeed send a Request to the server every time the Tick event is raised, and as any other client request does, will update the UI within your Visual WebGui application with all the pendingUI updates when a Response is returned from the server. As with the KeepConnectedRequest above, this type of request is sent asynchronously and will be sent although your server-side is busy processing another "formal" request (step 4 above). Using Timer controls on a form is a very often used way of updating the UI of an application during a very lengthy server-side processing.

The Tick event does not have to contain any code for the UI updating to take place, but it does need to be registered and the timer must be actively raising the events for these updates to take place.

The Comet technology is yet another method of updating client UI during and through a lengthy server-side processing operations. This technology is outside of the scope of this article and you can find more information on the Comet article.

The scenarios below are by no means a complete list of the scenarios that you might face while developing a Visual WebGui application, rather they are just examples of the more typical ones that you might expect. Many of the scenarios are very similar to one another and do have similar possible solutions, but do arise from different needs.

You have a Click event handler registered to a control, and processing the eventhandler code takes considerable amount of time. Your event handler code starts by updating, say, a Label on your form indicating that your processing has started. Right after the user clicks your control, your Visual WebGui application will no longer respond to additional user actions, and the user does not see any indication that this process has started as he doesn't see your updated Label. Only when processing of the Click event handler has finished, your application's UI will update and start to respond to further user actions.

You have a Click event handler registered on a control, and processing the event handler will go through a considerable amount of data for processing and you want to report the progress to the user, while the processing is taking place, not only to let the user know that the application is still running, but also to indicate the status of the processing. Typical examples of what developers want to do here is to have a ProgressBar control and update it's progress on regular basis during the process. Another example would be to display an x out of y process indication.

You have a Report that you want to show in a ReportViewer control and processing the report takes a considerable amount of time. You want to notify the user that processing has started and when it is done, and the way you do it, say, is to update a text on a Lable (or an image on a PictureBox) indicating that processing is taking place. The notification does however not reach the client UI until either the processing of the report is finished and the report shows on your form, or when the next KeepConnectedRequest is automatically sent by the client core.

You have a Button and an HtmlBox and on the click of the Button, you set the HtmlBox.Url to some Url that requires considerable amount of time to load. After the user clicks the button, the application seems to hang, until the contents of the HtmlBox have been returned and the HtmlBox has been populated. You want to notify the user the processing has started and you do that by, say, updating the text on a Label control indicating the processing has started. The notification does however not reach the client UI until either the HtmlBox has been populated (the request has completed), or when the next KeepConnectedRequest is automatically sent by the client core.

You want to download a file, but before the download can start, the server-side needs to do some processing that require considerable amount of time (like PDF file generation, batch ZIPping etc.). If using an HtmlBox for the download, this is almost the same scenario as described above for the Html box. Using a Link.Open (or Link.Download) to initiate the download, the user will see little or no indication until the processing has completed and the actual download can start.

You have a WebForm (an aspx page) that you show within an AspPageBox on your form. Within the server-side code of the WebForm, you have the necessary references to update some aspects of the Visual WebGui application's UI (like the text on a Label on a Visual WebGui form), however, updating the property does not take place instantly, not until the next KeepConnectedRequest is automatically sent by the client core or another user action is performed, like clicking on a Button on your Visual WebGui application or refreshing the browser (F5).

You have an ASP.NET UserControl, or a third party ASP.NET control, that has been wrapped either by Gizmox or by the ASP.NET Integrated Wrapper. Within the server-side code of the control, you have the necessary references to update some aspects of the Visual WebGui application's UI (like the text on a Label on a Visual WebGui form), however, updating the property does not take place instantly, not until the next KeepConnectedRequest is automatically sent by the client core or another user action is performed, like clicking on a Button on your Visual WebGui application or refreshing the browser (F5).

The delay in UI updating for the first few scenarios above, is best explained by viewing the Typical event handler processing section above. The client needs to get a Response for it's Request before it will know what to update in it's UI, and until that request is received, no UI updates will occur. Of course the client needs to get a response to a particular request to be update some of it's UI and that is true for updating the contents of an HtmlBox for instance. In that case the necessary processing must have completed for the client to update the contents of the HtmlBox. For other controls in the client's UI, the client just needs to get a Response back for any client issued Request, and the response from that Request will include all the pendingUI updates that have accumulated since the last Response was received. Most, if not all, of the methods we use to make this type of UI updated reach the client do base it's solution on this fact. Among the solutions you can use, is using Timer controls, increase the frequency of KeepConnectedRequest request, using Comet technology etc.

For the ASP.NET webpart (WebForm and ASP.NET control) delayed UI updates, there is another reson for the delay. Those webparts communicate with it's own server-side code through a pipeline that is seperate from the Visual WebGui pipeline, so when the client side of those webparts issues a request to the server, the Response they get back is not a Visual WebGui response and does not include any of the Visual WebGui pending UI updates, and even if it did, the client core of those webparts would not know what to do with it. It might come as some kind of surprize that the UI does not update instantly in the Visual WebGui application, as there is indeed a client Request sent to the server and there is indeed a server Response received from the server, but as mentioned above, these communications occur through a different pipeline than the Visual WebGui pipeline, so although the ASP.NET webpart's UI does update, the Visual WebGui UI does not. The method used to make UI update instantly on Visual WebGui application is by "hooking" into those client side requests issued by the ASP.NET webpart and as a part of those requests, call the client side of the Visual WebGui application and have it raise client side event(s), which will then update the UI of the Visual WebGui application when a Response is received. This type of communication is in Visual WebGui called Client-Client communications, where the JavaScript client code of the ASP.NET webpart is calling the JavaScript client code on the Visual WebGui side and tell it to raise a Visual WebGui event or Request to the Visual WebGui server-side. Recalling what has been said above, the Response received for that Visual WebGui Request will include all pending UI updates for the Visual WebGui clientside, so your UI will update.

Every KeepConnectedRequest the Visual WebGui application automatically issues will get a response that includes all the pending UI updates, so for each such request sent, your UI will update. In cases where the requirements are not an instant update of the UI, then without any additional code you can increase the frequency of this Request by changing parameters in web.config. By default, this type of request is automatically sent every two minutes. Please be adviced that it is not a good idea to increase the frequency too much, as that might seriously affect the performance of your application.

Using a Timer is probably the most widely used method in this type of scenarios. Again, remember that any type of Visual WebGui request sent to the server will receive a response that includes all the pending UI updates for your client, so by having your Timer.Tick event fire on regular intervals, then all the pending UI updates will take place for each such event fired. When using this approach, you will need to add a Timer control to your Form/UserControl and register a Tick event handler for the Timer, as well as activating the timer so it will start firing. The server-side code that you place inside the Tick event handler is irrelevant in this context, and it can even be an empty codeblock. The purpose is simply to make the client side of your Visual WebGui application issue a Visual WebGui request, so all pending UI updates will be applied.

A very common mistake developers make when using a timer, is to activate the Timer, say, on a Button.Click and the Button.Click is performing a lengthy request right after it activated the Timer. To understand why this will not work, look at the Typical event handler processing section above and then understand that the Timer is a clientside "object" so for the Timer to start raising it's Tick event, the clientside must know it has been activated and for that to happen, the client must receive a Response from the server. In this scenario the client doesn't know yet, and the server-side goes on processing it's lengthy Click event handler and only on the next Response the client receives (KeepConnectedRequest, another Timer.Tick, etc), the clientside will know the timer has been activated and will start raising it's Tick events. By that time, your lengthy Click event processing might already be completed, so it's far too late. Therefore, the timer must already have been started before the client issues the Request that starts the lengthy processing, for this method to work.

To understand this method of approach, take a look at the Typical event handler processing section at the top of the article. Every control in Visual WebGui has a FireEvent method which is the event "dispatcher" when a request is issued from the clientside. This FireEvent method examines the event arguments and recognizes which clientside event is being raised and then fires the corresponding server-side events.

The idea is to override the FireEvent method of your control (a Button for instance), listening for a particlular type of event (a Click event for instance) and the first time it is fired we do not raise the corresponding server-side Click event right away. Instead we raise a flag that tells us that the event has fired once, then do the UI updates we want to take place before the lengthy processing starts, then we issue a client side request to raise the event again and return from the FireEvent.

Again, looking at the event handler processing, we effectively jump over step 4 of the process. When the client receives the Response, it will include our instructions to raise the event again, so another request is immediately sent from the client. In our FireEvent method we realize that the same event is now being fired the second time, so we know it's now a time to process our lengthy Click event handler, so we do.

This method does mean and extra roundtrip to the server, but it also gives our client a chance to update it's UI before the lengthy processing starts.

• An example updating Button.Text before lengthy processing starts
  

Using any of the ideas above to update the UI during lengthy processing, does just that, meaning it will update the UI during the lengthy processing. While the lengthy processing is taking place however, your application does not respond to other user actions, which in some cases is not acceptible.

The use of Link.Open and open a new Visual WebGui form in a new browser Tab/Window may help in such cases, as such a new browser Window/Tab will give you a new pipeline to the server, so when the lengthy processing is taking place in one, the other is still responsive. Some examples on this type of approach can be found in the Gateway article where it is used in the context of downloading.

Using Link.Open can also become handy when you want to notify the user that a lengthy processing is now starting. In the Gateway article there is a link in the Forum threads section where the developer wanted to download a PDF file, but before the actual download starts, the server must generate the PDF, a process that can take considerable amount of time. The developer wanted to inform the user that the PDF generation is taking place so the user wouldn't think the application was halted.

The solution was to use a seperate Form with an HtmlBox. The Form was opened using Link.Open and the form had some visual indication that the request was being processed. Then in the Load event of the form, the HtmlBox.Url was set to the download link. This has the effect that the user gets his indication that the lengthy generation process is being started, and then the process actually starts when the HtmlBox.Url is set.

If needed, you can combine these methods and add a Timer to that download Form. While the PDF file generation was taking place as a lengthy operation, you may want to report the progress of the operation by updating some indicators on that form. Having the Timer fire on regular basis will make sure those UI updates are reflected on the client's browser.

Yet another approach to make sure your application remains responsive while a lengthy operation is taking place, is to use Asynchronous loading or processing.

Please view our article onAsynchronous loading for more information on this approach.

As mentioned above, the goal here is to have the client side of the ASP.NET webpart call the client side of the Visual WebGui application and have it raise an event to the Visual WebGui server through it's pipeline, which will then make sure all the pending UI updates will be updated to the client. This is what we call Client-Client communication.

There are some good links methods in the AspPageBox page, especially the code sample on communicating with the hosting Visual WebGui application.

In this article we have discussed how Visual WebGui client and server communicate and why updating the server-side does not always reach the client immediately.

We have discussed two of the most common causes of such client UI update delays and then we have discussed some methods to work with this type of client/server communication and still have the UI update instantly or at least on a regular basis.