blindwig Posted July 7, 2005 Share Posted July 7, 2005 (edited) 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. Progress_Demo.zip Edited July 7, 2005 by blindwig My UDF Threads:Pseudo-Hash: Binary Trees, Flat TablesFiles: Filter by Attribute, Tree List, Recursive Find, Recursive Folders Size, exported to XMLArrays: Nested, Pull Common Elements, Display 2dSystem: Expand Environment Strings, List Drives, List USB DrivesMisc: Multi-Layer Progress Bars, Binary FlagsStrings: Find Char(s) in String, Find String in SetOther UDF Threads I Participated:Base64 Conversions Link to comment Share on other sites More sharing options...
FuryCell Posted July 9, 2005 Share Posted July 9, 2005 (edited) 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 July 9, 2005 by SolidSnake HKTunes:Softpedia | GoogleCodeLyricToy:Softpedia | GoogleCodeRCTunes:Softpedia | GoogleCodeMichtaToolsProgrammer n. - An ingenious device that turns caffeine into code. Link to comment Share on other sites More sharing options...
blindwig Posted July 9, 2005 Author Share Posted July 9, 2005 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?Progress_Demo.zip My UDF Threads:Pseudo-Hash: Binary Trees, Flat TablesFiles: Filter by Attribute, Tree List, Recursive Find, Recursive Folders Size, exported to XMLArrays: Nested, Pull Common Elements, Display 2dSystem: Expand Environment Strings, List Drives, List USB DrivesMisc: Multi-Layer Progress Bars, Binary FlagsStrings: Find Char(s) in String, Find String in SetOther UDF Threads I Participated:Base64 Conversions Link to comment Share on other sites More sharing options...
LxP Posted July 9, 2005 Share Posted July 9, 2005 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. Link to comment Share on other sites More sharing options...
blindwig Posted March 3, 2006 Author Share Posted March 3, 2006 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. My UDF Threads:Pseudo-Hash: Binary Trees, Flat TablesFiles: Filter by Attribute, Tree List, Recursive Find, Recursive Folders Size, exported to XMLArrays: Nested, Pull Common Elements, Display 2dSystem: Expand Environment Strings, List Drives, List USB DrivesMisc: Multi-Layer Progress Bars, Binary FlagsStrings: Find Char(s) in String, Find String in SetOther UDF Threads I Participated:Base64 Conversions Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now