|Client, server and Ajax events - WebUI Studio|
|Tuesday, 04 January 2011|
Page 2 of 3
Client side control
A progress bar sounds like a simple idea but notice that it has to communicate with some other process to show how something is progressing. It is often a server process, e.g. saving or loading a file, but it could also be a client side process, a long calculation say. Clearly the "difficult" part of dealing with a progress bar is implementing the mechanism that causes it to update.
Let's start as simply as possible. In Indeterminate mode the progress bar simply runs an animation of the "slider" moving up and down the bar. The animation is controlled by the Interval property which give the number of milliseconds between each animation step. In Indeterminate mode this is the only functional property we have to set.
Make sure that you have set Interval to 100 and Mode to Indeterminate.
To make things as simple as possible we will control the ProgressBar using just two buttons. Place two WebButtons on the form and set the first's Text property to Start and the second's to Stop.
The key idea here is that of Client Side Events. All of the Intersoft ASP .NET components support not only the usual Server Side Events that make ASP so different to every other approach to building web apps but they also support Client Side Events.
A Server Side Event generally causes a round trip to occur with the event data sent back to the page at the server. In this case the event handler is usually written in C# (or VB) and is contained in the code behind for the web page. Any changes due to the event handler are rendered as HTML and the whole lot sent back to the client.
At this point you might want to point out that client side events are the norm for non-ASP.NET web applications. This is indeed true but they are not usually part of an ASP.NET application and the Intersoft controls provide an easy and consistent way of mixing the usual ASP .NET server side approach with client side events. It's very clever and very simple.
Now let's see it in action.
var progBar = ISGetObject('ProgressBar1');
So to start the animation off all we need to do is call DoStep and to stop it we call Finish - notice that there is no need to call Start although for reasons to be explained this is usual.
If you now run the web page you will see the progress Bar animate when you click the Start button and stop when you click the Stop button. Notice that all of this is controlled by the client side code - no round trip or server processing is involved.
At this point you might be wondering what the Start method is for - after all you don't need it to start the animation off as DoStep does that. The answer is that the Start and Stop methods trigger events that signal the state of the ProgressBar to other interested parties.
What is really interesting is that there is a client side event and a server side event corresponding to the ProgressBar Finish.
This is flexible but once again we have the basic problem of the cost of a full round trip postback.
The obvious solution is to use an Ajax-like method and Intersoft components have a really clever and very versatile approach to Ajax-style postbacks called FlyPostBack which provides a server side handling mechanism that doesn't involve a full postback and is much more flexible.
Let's look in more detail at the three ways of handling events.
|Last Updated ( Wednesday, 02 February 2011 )|