4 replies to this topic

[blindwig]

Some of my slower routines (like one that work on hundreds or thousands of files) I've started building in use of the built-in progress bar (using ProgressOn(), ProgressSet() and ProgressOff() ).
But as I write multi-level routines, I my formulas for calculating the progress for a single progress bar got way to complex and annoying to maintain. So I wanted to make something similiar - a multi-level progress bar, where each level of the routine can report to a different bar.

Like say you want to copy files from one drive to another. You could have 3 levels of progress bars, 1 for how many files to copy on the whole drive, 1 for how many files to copy in the current directory, and 1 bar for progress of copying the current file.

Anyway, have a look - I included the source and a demo program.

This UDF isn't finished, I still have plans for it, like:
I want to put a cancel button on the progress bar that would report back to the calling routine. But I'm not sure how to do this, because I don't know if the script that called it would be in Event or Poll mode.
I want to make the window adjust to the number of progress bars on it. Right now the size is static, and it holds about 4 bars. This shouldn't be hard to do, I just haven't taken the time to do it.
Add an option button to see a text log of all the progress so far, and maybe even an option to save this log. This would be a quick and easy way to add logging to all my routines.

Attached Files

•  Progress_Demo.zip   6.44KB   642 downloads

Edited by blindwig, 07 July 2005 - 06:55 AM.

[FuryCell]

Nice Job.
About adding a cancel button. You could just make the function return the handle to the cancel button or make a byref parameter for a variable to hold the handle to cancel button and leave it up to the programmer to check the state of the button.

Edited by SolidSnake, 09 July 2005 - 01:51 AM.

[blindwig]

OK, I added an option for a cancel button, just set $flags = 1 when first creating the progress box.
The Cancel button work in Message-Loop or On-Event modes. But it's really slow in message-loop mode - I assume because the GuiGetMsg() funciton sleeps when there is no message to return?
And another bug - in message-loop mode, when you close the window, it counts as a cancel, but not in on-event mode. What am I doing wrong?

Also, I want to add a flag to set the progress box to always-on-top. Anyone know how to the that? With GUISetState maybe?

Attached Files

•  Progress_Demo.zip   2.99KB   376 downloads

[LxP]

Also, I want to add a flag to set the progress box to always-on-top.  Anyone know how to the that?  With GUISetState maybe?

You can specify the $WS_EX_TOPMOST extended style when initially creating the window.

[blindwig]

I just wanted to comment here on the reason I wrote this and why it's so useful.

If you wrote a routine to use a progress bar (the built-in one) it might look like this:

Function MyFunction1()

  ProgressOn()

  Loop
    ProgressSet()
  EndLoop

  ProgressOff()

EndFunction

You might write several functions like this.

Later you might want to wrap these functions in a bigger function:

Function MasterFunction1()

  ProgressOn()

  MyFunction1()

  ProgressSet(33%)

  MyFunction2()

  ProgressSet(66%)

  MyFunction3()

  ProgressSet(100%)

  ProgressOff()

EndFunction

The problem here with using the built-in Progress Meter is that it doesn't nest like this. When the child functions run, their progress bar destroys the parent progress bar.

My Progress Bar UDF is designed to be nestable, because when you call it, it checks to see if a progress bar already exists. If not it will create one, but if one already exists it will automatically add another bar to the old one instead of just over-writing the old one.