Paradox Community
Search:

 Welcome |  What is Paradox |  Paradox Folk |  Paradox Solutions |
 Interactive Paradox |  Paradox Programming |  Internet/Intranet Development |
 Support Options |  Classified Ads |  Wish List |  Submissions 


Paradox Programming Articles  |  Beyond Help Articles  |  Tips & Tricks Articles  


Roll Your Own Progress Bar With ObjectPAL
© 2003 Arthur van Lokhorst

Users are very fond of a progress bar. It assures them that their computer is still working, and in any case is not hanging. It further has the advantage that the user has an impression of the remaining time a job takes, and he can leave his computer and still tell, from a distance, that it is continuing to do the job on hand. Programmers on the other hand are sometimes skeptical of a progress bar, because of the extra time a progress bar supposedly takes.

As for processing time, I do not think that is an issue, relative to the size of the job on hand. I found the following processing times for the following for .. endfor loops of different size, with sleep called in each loop (to allow the user a Control-Break interrupt):

Number of
Iterations
Processing Time
Native Windows Control
Processing Time
Self Rolled Progress Bar
10,000 0' 0" 0' 2"
100,000 0' 6" 0' 7"
1,000,000 0' 59" 1' 0"
2,000,000 1' 58" 2' 2"
5,000,000 4' 55" 5' 13"

So it seems to me that the extra time a progress bar takes, is acceptable, relevant to the time any job would take during a loop of the given size. But it must be programmed properly (using the MOD-function). Therefore, I think that on many jobs a programmer should take into consideration to run a progress bar. If loaded as a modal dialog, users can be denied access to other Paradox tasks as well. The alternative is, of course, not to use a progress bar at all and write a message to the status bar, to indicate the progress made.

I am not very satisfied with the look and feel of the progress bar that comes as native Windows control. So I devised my own, which is what the accompanying form is all about. The progress bar itself is a text area within a group box. The box has a fixed size, i.e.: the size of the box is not changed at runtime. But the text area is. As the job progresses, the size of the text area increases, and displays the percentage completion as well. Just for fun, the progress bar changes color every time it is run.

The progress bar comes in two varieties. The most elaborate is a stand alone form, which is juggled in the air, and can be called from any other form; besides the text area that serves as progress bar it contains another text area, to display a message if needed. That form is simply called ProgressBar.fsl and is created at runtime in your working directory when you run the accompanying form.

The other progress bar is part of the accompanying form. It is a text area within a box. That box can be copied and pasted to any other from, where its methods can be called by your code.

Both varieties are controlled by three methods, to be called by your code:

SetProgressBar() to invoke the progress bar (the method is optional: it is already invoked at runtime from the open-event);

StepIt(percent completion) to show the percentage of completion; and

KillProgessbar() to dismiss the progress bar (i.e. have it blend in with the page).

Only the StepIt-method takes a value (a long integer or number, passed by value from the calling method). The StepIt-method itself uses the percent completion as a decimal number, e.g.: 0.1 for 10%). For an illustration of how these methods are invoked, see the pushButton-event. For clarification how they work see the var-section and the methods on the text area called txtProgress.

What the form demonstrates is:
  • how to program the native windows control;
  • how to roll and handle your own (and the form comes with a custom made progress bar that any user is free to cut and paste to his own form);
  • how to program a progress bar, so that it does not consume too much time during large jobs (using the MOD-function);
  • it offers an easy way to measure how much extra time it takes to run a progress bar;
  • the form further demonstrates how to design another form at runtime (using the design tools);
  • how to randomize (using the RAND-function)
  • how to manipulate a UI object at runtime (set color and size);
  • how to position a form on screen ;
  • how to play sound;
  • and how to list your source code to file;
  • finally, the form has a build-in color scheme of the 18 most important available color constants (displayed by name, against a background of the relevant color).
The accompanying form contains a lot of code, but most of that is used to run that form and set you up. The progress bar itself is run by calling just three methods (described above).

Have fun.


Discussion of this article


 Feedback |  Paradox Day |  Who Uses Paradox |  I Use Paradox |  Downloads 


 The information provided on this Web site is not in any way sponsored or endorsed by Corel Corporation.
 Paradox is a registered trademark of Corel Corporation.


 Modified: 19 Jul 2003
 Terms of Use / Legal Disclaimer


 Copyright © 2001- 2003 Paradox Community. All rights reserved. 
 Company and product names are trademarks or registered trademarks of their respective companies. 
 Authors hold the copyrights to their own works. Please contact the author of any article for details.