Prog_Bar Frequently Asked Questions

Prog_Bar makes use of the Intuition, Gadtools, Graphics and Utility libraries so these will need to be opened by your program. This should not be too much of a problem since most programs will probably need these libraries opened anyway.

<Back to the Question List>

Yes, Prog_bar can easily be used to create a stand alone counter. Just switch on the bar's text display, set either the width or height (or both) to zero and update the bar as normal.

The only tricky bit is getting the co-ordinates right. The reason for this is that the co-ordinates you supply are for the invisible bar, not the text, and the actual text position is relative to the bar. The text will always remain a fixed distance away from the nearest edge of the bar, and will be centred with respect to it.

As an example, if you want your counter to start at a set point on the screen, no matter how its length changes, you would set the text to appear on the right of the bar, and the bar's horizontal position would need to be to the left of the desired counter position.

Likewise, if you want your counter to be centred horizontally on a particular point, you could set the text to appear above (or below) the invisible bar, and the bar's vertical position would then need to be slightly below (or above) the desired position. The horizontal position would depend on the width of the bar, even though the imagery is not visible.

<Back to the Question List>

No problem. The method used involves some visual trickery, but is not difficult. The example shown here was created by switching the foreground and background colours, and then setting the bar to grow to the left. The bar is full at the start, and then decreases in value, but since the background is the dominant colour it appears to grow.

<Back to the Question List>

As a progress bar is intended for use when the main program is performing some large task, it makes sense that the bar itself should not interfere with the main task. For this reason it is best to update the bar only as often as necessary to maintain a smooth expansion. These updates should be spread as evenly as possible throughout the duration of the main task.

You need to work out how often the bar's imagery will change. This figure is calculated as MAX (number of pixels, max value of counter) + 1 (the extra 1 is to allow for the completely empty bar). If you are not using the text display this formula can be simplified to number of pixels + 1

The number of pixels will be the overall width of the bar (or height, if it grows vertically), minus the number of pixels used for the border. A ridge border uses 8 pixels horizontally and 4 vertically, while a plain, recessed or raised border uses 4 horizontally and 2 vertically.

The maximum value of the counter will be either 100 (percentage counter) or the logical size of the bar.

For example, a horizontal bar which is 250 pixels long using a percentage display and a ridge border will need at least 243 ((250 - 8) + 1) updates for a smooth motion. However, if this bar was only 50 pixels wide it would still need at least 101 updates for the counter to operate smoothly.

Note that this is intended only as a guideline. Updating the bar less often will result in a jumpy motion, while more often will just slow down the main program with no visual improvement. However, getting as close to this figure as possible will result in the best overall performance.

<Back to the Question List>

Get the newest version from the downloads page. Versions before v1.04 used a structure which was not word aligned and this caused Prog_bar to crash on any 68000 based machine. I programmed Prog_Bar using a 68030 equipped A1200 which can quite happily deal with 16 bit accesses to odd addresses, so this problem did not appear during development.

Many thanks to Oliver Roberts who discovered, identified and reported this problem.

<Back to the Question List>

This problem is caused by the parameters to the Prog_bar functions being passed incorrectly by the compiler (perhaps correctly would be a better choice of word).

The function prototypes are defined incorrectly in the Prog_bar include file. Storm C then interprets this correctly and passes the wrong information to the library functions. Dice C and SAS/C work fine because they pass parameters as longword values, regardless of how they are defined.

The solution is to get the latest version of the header files from the downloads page, or to change the function prototypes so that all UWORDS become ULONGS (CARDINAL changes to LONGCARD in the Modula-2 header file).

<Back to the Question List>