QB64.org Forum
Active Forums => Programs => Topic started by: Parkland on April 17, 2020, 12:39:16 am
-
I attached a program with code for drawing progress bars, for those of us than may want such a thing, without much complication.
Updated to fix font location on bar.
-
Nice!
-
Wow! There are many variations! Good work!
-
Excellent work. That code has been added to my toolbox folder. Thank you for sharing.
-
It looks great but how would such a thing work without us being able to use callback procedures?
For example, my program loads 20 model files into an array. To get the progress of the load diplayed i'd either have to report the update at the end of each model load (to then update the screen display would require redrawing everything and calling _display (long winded and CPU/GPU heavy)) or build a bit into the model loader that updates the progress variable (but this would once again require all the redrawing/_display call). I've played around trying to get progress bars functional in a few programs in the past but with making them modular no real success dur to the callback issue (think we need multi threading support for that).
I may be wrong in my assumptions though so im happy to be proved wrong, but still this is some great programming.
Unseen
-
@Unseen: Well this takes me back. I used to use progress bars, when chip speeds were much lower. My function measured the number of bytes (binary read" in each file I was loading, and then tracked the progress, accordingly. It especially made a difference in my custom made zip/unzip application.
Pete
A priest, and rabbi, and a minister walk into a progress bar...
-
Thanks for doing this, I will be studying it as a possible basis of a force graphic for a project of mine. Very timely that you've done this, and great work.
-
It looks great but how would such a thing work without us being able to use callback procedures?
For example, my program loads 20 model files into an array. To get the progress of the load diplayed i'd either have to report the update at the end of each model load (to then update the screen display would require redrawing everything and calling _display (long winded and CPU/GPU heavy)) or build a bit into the model loader that updates the progress variable (but this would once again require all the redrawing/_display call). I've played around trying to get progress bars functional in a few programs in the past but with making them modular no real success dur to the callback issue (think we need multi threading support for that).
I may be wrong in my assumptions though so im happy to be proved wrong, but still this is some great programming.
Unseen
Could you not just use timer to update progress bars?
That's what one of my programs does, updates progress bars every 0.25 seconds.
-
Could you not just use timer to update progress bars?
Not if you wanted to keep actual track of how much data youve loaded, if one model where in ASCII format and another one binary the time taken for each to load would be massively diferent. An ON TIMER event that could check how much data has been loaded vs the total would be cool but i've no idea how that'd be done.
@Pete
in each file I was loading, and then tracked the progress, accordingly
so thats basically a call back procedure, you reported how much data had been loaded whilst still loading it...i'd love to see a demo of it in action...
Unseen
-
In my file transfer program, I'm using this very progress bar code, and it updates every 0.25 seconds, there are variables that track the file length and how many bytes are transferred so far and make the percentage for the progress bar.
I would share it but the program is massive, as it does disk and network transfers and has a 1000 place queue so 99% of the code is irrelevant.
-
@Parkland
I find it cool!
and it is ok also in Kubuntu 16.04 see here
[ This attachment cannot be displayed inline in 'Print Page' view ]
@Unseen Machine
about
For example, my program loads 20 model files into an array. To get the progress of the load diplayed i'd either have to report the update at the end of each model load (to then update the screen display would require redrawing everything and calling _display (long winded and CPU/GPU heavy)) or build a bit into the model loader that updates the progress variable (but this would once again require all the redrawing/_display call)./quote]
my two cents
the issue can be said in this way:
how to show the progression of bar during the loading of a list of files showing also the progression of loading of the single file without increasing hugely on CPU for continuose redrawing of bar....
1. you can use 2 progression bars as many installers do one for list of file and one for single file on loading
So you must redraw one at a time ( :-) I'm just joking with this last affermition)
2. you can split the total lenght of progression bar into the number of files , so for each file you have the same graphic space (unity of graphic) and then you can split the graphic unity of file on loading for its weight in Kb or byte.... and use this last unity of weight to advance the progression bar
3. you can use pmap (brought by Fellippe / Ashish into QB64 from Java) to have a realistic progression of progress bar
about
I've played around trying to get progress bars functional in a few programs in the past but with making them modular no real success dur to the callback issue (think we need multi threading support for that)[
modular vs OOP : i think that you're professional coder so your habit is more often to use OOP (C, C++, Java) than modular model.
But with a SHARED variable the data pass from a module to another (if you don't like the parameters). It lasts to activate this module ... and TIMER does it in no flexible way, so it lasts a CALL into the load routine.
In OOP while you load the file the object of progression bar adjourns itself.... but this always uses CPU and RAM and Time.
In the same manner a Multithread is a good fiction made sharing CPU RAM and Time among more applications.
Also the OOP suffer of this: sometimes when my son load Minecraft with so many mods the Forge stucks with its progression bar.
Thanks to read
-
Nice, but never shows... 100% !
-
I just messed around with it, if I change the variable to 100, it shows 100%.
However I did find a mistake in the program; the text positioning calculation isn't right, I will try to fix it
-
Updated the code ; Fixed the issue with the text not printing in the proper spot.
As for the "never reaching 100%" issue, if I call the routine and type "100" instead of X, it works
-
Just to throw a monkey wrench into this toolbox, I thought I would add in my comments on Progress bars from my experiences using them (Mostly text).
I use this Calculation for the Progress bars:
Progress = Int(Value * BarLength) \ High
This should be easy to understand, but for further explinations:
Lets assume we are using a Counter variable from 1 to 6080
"Value" would be the Counter, "High" would be 6080, and BarLength is the length you want the bar to be.
For instance, lets say I want to have a bar that is 64 characters long. I would use: Progress=Int(Value*64)\High
This would create a bar that is 64 characters long. Works in graphics modes too. I hope this is helpful/informative.
Omg it's [banned user]!!! :-O