Progress Indicator revealed
Some of our customers have been asking us about the ProgressIndicator that appears on Intraweb forms. It was added sometime ago but not fully functional. I've been working on it for the past couple of days trying to get it finished for the next release and we're very close. Just some bugs to iron out and some minor features to add. In this post I'll give you a general idea of what it is and why it came about.
[Disclaimer: this is work in progress, so some things might change from now to the time of release. I'm also interested in feedback]
We introduced our support for Ajax over a year ago, and we did this by providing events that you can call (and having worked with other frameworks, I'm still amazed at the simplicity of Ajax support in Intraweb...in terms of end-user that is). The reason we've called these events OnAsyncXXX is because Ajax calls can be made in two ways: synchronously and asynchronously. Async isn't really to distinguish it from the OnXXX events, but to indicate that the Http request made via XMLHttpRequest is an asynchronous call. This type of call prevents the page from locking up and other requests can be made and it's also the most flexible. However, it also introduces a problem.
I've always advocated that Ajax calls shouldn't be made in all cases. There are certain types of requests that make more sense with a full page submit (requests that refresh many controls on a page for example). At the same time the purpose of Ajax is to allow a more fluid interaction with the user. This implies that many of the calls made should be short-lived, not long running processes. However, there are many times where you have a complex page with a lot of data, and you do not want to use a full submit, for instance a long running query against a database. If there isn't a need to refresh the whole page, why cause a full submit?
Due to this scenario, where you need the best of both worlds, that is, the form "locking" effect that you get on a full submit and the reduced data interchange caused by an asynchronous callback, is where TIWProgressIndicator comes into play. It's a non-visual control that you link up to your form. Every asynchronous callback will now use this component to provide status information during a callback. Here's a screenshot of it in action
(Apologize for the bad contrast).
What is happening is that on the asynchronous call, the screen locks and some status information is displayed. The display is completely configurable, either by setting individual properties or using Css.
Here is the same form at design-time, as well as the object inspector showing the properties for the progress indicator control.
It doesn't end here though. If you look at the properties, there are three interesting one, actually there are 4 but one is public. This last one, is called DivTag and it allows you to specify what you want shown when the progress is called. This means that you can pretty much display whatever it is you want, completely overriding the default progress information. You also have two properties called PreScript and PostScript. These are Javascript code that will be called prior to the Ajax call and after the Ajax call. This allows you to hide your custom tags, show information, pretty much do anything you want. And all this is acomplished by setting the UserDefined property to True. By doing this, I've tried to make the progress indicator as flexible as possible and not restricting you to use what comes built in. Again, it's still not entirely finished and I'm open to comments and suggestions. But so far, this is what we have and you'll be able to play with it very soon.