[(V)C++] Progress bar weet het altijd precies

[cobratbq]

In al die programmatjes zie je tijdens installatie en zware functies altijd zo'n balkje lopen die precies weet hoever het programma is. Hoe doen ze dat?
Doen ze dat gewoon met "resultpunten" of zit daar een rekensommetje achter?
Graag kleine voorbeeldjes erbij als iemand een idee heeft. Ik ben nog niet zo handig met C++.

code:

//wat functies
progressbar.position(10);
//nog wat functies
progressbar.position(20);

[Verwijderd]

Op donderdag 02 mei 2002 21:58 schreef cobratbq het volgende:
In al die programmatjes zie je tijdens installatie en zware functies altijd zo'n balkje lopen die precies weet hoever het programma is. Hoe doen ze dat?
Doen ze dat gewoon met "resultpunten" of zit daar een rekensommetje achter?

Dat gaat natuurlijk niet zomaar automagisch he, je moet gewoon zelf je zware berekening opsplitsen in een aantal stukken, en tussendoor dus telkens de positie van de progress bar updaten.

[cobratbq]

Dacht ik al.
Tnx

[mulder]

Ligt er maar net aan, soms zul je zelf 'resultpunten' moeten instellen, meestal heb je een tellertje. Als je bijvoorbeeld een aantal records moet updaten. Ik neem dan het liefst het percentage. (Dit omdat ik bv een keer een table van 100.000 records moest converteren, en dat trekt de integer .value van een VB progressbar niet)

[curry684]

Op donderdag 02 mei 2002 21:58 schreef cobratbq het volgende:
In al die programmatjes zie je tijdens installatie en zware functies altijd zo'n balkje lopen die precies weet hoever het programma is. Hoe doen ze dat?
Doen ze dat gewoon met "resultpunten" of zit daar een rekensommetje achter?
Graag kleine voorbeeldjes erbij als iemand een idee heeft. Ik ben nog niet zo handig met C++.

code:

//wat functies
progressbar.position(10);
//nog wat functies
progressbar.position(20);

Zowel on- als off-topic: heb je ooit zelf Windows geinstalleerd? Zo ja dan heb je toch ervaring met progress bars die 2 uur doen over de eerste 50% en 30 seconden over de tweede helft, en ik heb zelfs 'overflowing' progress bars gezien die gezellig overnieuw begonnen en daarna bij 130% pas klaar waren.

Dus ja, er gelden in principe result-punten. Bij InstallShield scripts e.d. moet je ze over het algemeen zelfs met de hand aangeven. Uitzondering is natuurlijk als je vantevoren weet dat je bijvoorbeeld 1900 mails gaat inlezen of 1200 bestandjes kopieren, dan kun je het wel vantevoren berekenen.

[Soultaker]

Op vrijdag 03 mei 2002 01:33 schreef curry684 het volgende:
Zowel on- als off-topic: heb je ooit zelf Windows geinstalleerd? Zo ja dan heb je toch ervaring met progress bars die 2 uur doen over de eerste 50% en 30 seconden over de tweede helft

Vervelender is die Windows hardwaredetectie in Windows 98 (e.a.), die de even lang doet over de laatste 5% als de eerste 95% ofzo. Doen dan geen progress bar.

ik heb zelfs 'overflowing' progress bars gezien die gezellig overnieuw begonnen en daarna bij 130% pas klaar waren.

Het toppunt vind ik wel de FreeBSD installatietools die het percentage van de geschatte totaaltijd weergeven bij het installeren en downloaden van packages, waardoor de progressbar halverwege dus achteruit kan lopen als de downloadsnelheid omlaag blijkt te gaan.

In theorie is het niet fout natuurlijk, maar gevoelsmatig klopt het niet: "Je was toch voor 50% klaar?! Waarom nu dan niet meer?!!!".

[tomato]

Ik kan mij nog wel iets herinneren van vroeger () van mijzelf.

Bijvoorbeeld een algoritme dat iets met een list doet en daarbij heel de originele list langs moet lopen. Dus je update de progressbar lekker lineair met de huidige positie in de list, maar daarbij houd je geen rekening dat het rekenwerk per listitem wel eens af- of (erger nog) op zou kunnen lopen (exponentieel bijvoorbeeld ).

Dan krijg je ook van die leuke progress indicators dit heel vrolijk beginnen, langzaam inzakken en over de laatste 10% tig keer zo lang doen als over de eerste 10%

[Soultaker]

Dat doet me opeens denken aan 't Internet Explorer progressbalkje rechtsonder in 't scherm. Dat ding begint altijd met een voorgeprogrammeerde snelheid te lopen en na een zeker aantal seconden begint 'ie opnieuw. Dat ding geeft dus helemaal geen informatie.

Ik neem mijn opmerking over dat FreeBSD ding terug; deze is zinlozer.

[brammetje]

Op vrijdag 03 mei 2002 03:11 schreef Soultaker het volgende:
Dat doet me opeens denken aan 't Internet Explorer progressbalkje rechtsonder in 't scherm. Dat ding begint altijd met een voorgeprogrammeerde snelheid te lopen en na een zeker aantal seconden begint 'ie opnieuw. Dat ding geeft dus helemaal geen informatie.

Ik neem mijn opmerking over dat FreeBSD ding terug; deze is zinlozer.

ik weet niet precies wat tie doet, maar ik denk dat hij eerst een keer loopt om een connectie te maken, dan teruggaat en dan loopt om de pagina binnen te halen.. Heel zinloos is tie dus niet

[tomato]

brammetje: ik weet niet precies wat tie doet, maar ik denk dat hij eerst een keer loopt om een connectie te maken, dan teruggaat en dan loopt om de pagina binnen te halen.. Heel zinloos is tie dus niet

Kun je een filmpje uploaden, ik gebruik Mozilla hier, dus zie het niet voor me

[cobratbq]

Tenzij het dus een programma is die niet te variabel is kan ik beter die berekeningen gebruiken. Dan weet ik genoeg.
Tnx

[curry684]

Op vrijdag 03 mei 2002 04:11 schreef brammetje het volgende:
ik weet niet precies wat tie doet, maar ik denk dat hij eerst een keer loopt om een connectie te maken, dan teruggaat en dan loopt om de pagina binnen te halen.. Heel zinloos is tie dus niet

Op al deze dingen kun je bij WinINet geen absolute statusreports krijgen, alleen globale tussenstanden die ook in de statusbar getoond worden (Connecting to site xxx en zo). Ze gokken daar dus welzeker maar wat aan

Waar overigens nog steeds niet echt 100% iets mis mee is zolang het ding niet overflowd (wat ie niet doet), gezien het feit dat het pure lopen van het balkje voor iedereen hier voldoende feedback is dat het ding iig nog bezig is.

[bloody]

bij installatie van mozilla onder linux loopt de progress bar ook uit z'n voegen (levert allemaal gtk errors op )

edit:
shit of was het "jedit" ipv mozilla...

[Soultaker]

Op vrijdag 03 mei 2002 04:11 schreef brammetje het volgende:
ik weet niet precies wat tie doet, maar ik denk dat hij eerst een keer loopt om een connectie te maken, dan teruggaat en dan loopt om de pagina binnen te halen.. Heel zinloos is tie dus niet

Nee hoor, hij begint op 0% en loopt op een vaste snelheid vol. Wanneer 'ie halverwege een HTTP response ontvangt met daarin een content-length, dan gaat 'ie het 'echte' percentage weergeven. Als 'ie geen content-length ontvangt (omdat 'ie geen verbinding kan maken bijvoorbeeld) loopt 'ie gewoon door totdat de connectie afgebroken wordt of 'ie de 100% bereikt heeft, waarna 'ie gewoon opnieuw begint.

En voor een screenshot; zet de volgende plaatjes achter elkaar:

code:

 [........]

 [X.......]

 [XX......]

 [XXX.....]

 [XXXX....]

 [XXXXX...]

 [XXXXXX..]

 [XXXXXXX.]

 [XXXXXXXX]

 [........]
 
 [X.......]

 etc.

[cobratbq]

Nog een vraag er achteraan (als er nog iemand kijkt in deze topic )

Soms krijg ik het idee dat er programma's bij zijn die alleen al langzamer lopen omdat er een Progress Bar bijgehouden moet worden, kan dat?
Of ben ik nou aan het dromen en duurt het gewoon lang.

[Orphix]

Op vrijdag 03 mei 2002 23:53 schreef cobratbq het volgende:
Nog een vraag er achteraan (als er nog iemand kijkt in deze topic )

Soms krijg ik het idee dat er programma's bij zijn die alleen al langzamer lopen omdat er een Progress Bar bijgehouden moet worden, kan dat?
Of ben ik nou aan het dromen en duurt het gewoon lang.

ik denk dat het gewoon lang duurt

die enkele increment om de zoveel tijd en zelfs het re-painten stellen niks voor bij de daadwerkelijke acties die het moet doen. (bijvoorbeeld kopieeren). ... theoretisch gezien wordt het natuurlijk altijd langzamer.

[.oisyn]

Op vrijdag 03 mei 2002 23:53 schreef cobratbq het volgende:
Nog een vraag er achteraan (als er nog iemand kijkt in deze topic )

Soms krijg ik het idee dat er programma's bij zijn die alleen al langzamer lopen omdat er een Progress Bar bijgehouden moet worden, kan dat?
Of ben ik nou aan het dromen en duurt het gewoon lang.

misschien zit er wel een hele ingewikkelde berekening achter om het aantal procenten te berekenen, waardoor ie zo langzaam is

[Verwijderd]

berekening is vrij simpel ..

als je X processen hebt (bv: tijdens een install ofzo), moet je iedere process een percentage geven.. .

je laat ieder process z'n eigen 1-100% genereren.... en dat scale je terug naar 1 hoofdpercentage

bv :
process 1 neemt van het geheel bv: 15% in beslag...
dan wordt process 1 dus (1-100%)*15%
process 2 neemt van het geheel bv: 60% in beslag...
dan wordt process 2 dus (1-100%)*60%
process 3 neemt van het geheel bv: 25% in beslag...
dan wordt process 3 dus (1-100%)*25%

process 1 + 2 + 3 = 100%. . en klaar is kees