Flüssige Anzeige bei ProgressBarGadget

[Joel]

Hallo,

Wie schaffen es eigentlich Manche Programme bei Zb. einer Reparierung der Registry, die Progressbar immer in der gleichen Geschwindigkeit schnell laufen zu lassen und schaffen es, das der Prozess dann immer fertig ist, wenn die Progressbar bei 100% ist. Also wenn z.B. ein Programm die Registry untersucht, weiß es ja nicht, ob da genau 100 Fehlerhafte Schlüssel sind die es geheben muss, und somit bei jedem Schlüssel eine Status weiter macht oder ob es 300.000 Fehlerhafte Schlüssel sind.

Mein Frage, wie schaffen die Programmierer bei Installationen, Oder anderen Sachen die Statusanzeige immer so Flüssig und genau verlaufen zu lassen.

[STARGÅTE]

du musst die Gesammt Zeit vorher abschätzen / hochrechnen, je genauer dest do besser.

dann kannst du auch eine Aussagen darüber treffen wie viel schritte / Schleife oder Sekunde weiten gerückt werden müssen.

das das SAU schwer ist, sieht man an WIN selber, wenn man sich die Kopierbalken anguckt, wo es dann auch mal sein kann das er von 4restmin auf 5 springt ^^, das liegt daran das Datein unterschiedlich groß sind, und verschiedene Dinge gemacht werden.

beoi der Reg. ist es ja relativ einfach hoch zu rechnen weil da ja eh fast alles gleich ist...

[Vermilion]

Bei Vista brauch er manchmal bestimmt eine Minute bis er die Zeit für Daten weniger als einen GigaByte kalkuliert hat, und dann fängt er erst an zu kopieren oder verschieben.

[PMV]

Naja, sau schwer ist jetzt was übertrieben, denn perfekte Zeitangabe ...
das glaub ich nicht.

Beim kopieren, löschen und verschieben von Dateien sieht man ja, wie
perfekt die Zeitangabe ist. Es wird wohl einfach die Anzahl der Dateien
genommen, eventuell auch die Gesamtdatenmenge, und dann einfach hoch
gerechnet. Es sind also nichts weiter als Prognosen wie beim
Wetter.

Reparieren der Registry ... was bedeutet das eigentlich?
Wie viel einträge existieren lässt sich sicher zu Programmstart ermitteln.
Somist muss man einfach nur schauen, wie viele hab ich in welcher Zeit
geschaft und wie viele kommen noch.

Und erlich gesagt ... der Kosten/ Nutzenfaktor wäre hier auch viel zu
gering, wenn es mehr als nur eine einfache Prognose wäre.

MFG PMV

[Joel]

Ok, gute Idee,

Bei Programmstart lasse ich das Programm den PC einfach in 3 Stufen einteilen

1. Stufe: Pentium 3 Win. 98 (sehr langsam)

2. Stufe: Core 2 Duo Win XP (schnell)

3. Stufe: Core 2 Duo Win. Vista (spezialstufe )

Und dann mach ich einfach 3 Zeitabschätzungen

Aber ob ich wirlich den aufwand beitreibe, weiß ich nicht.

Bei Install Shield Z.B. sieht man ja, das da keiner Lust hat das Abzuschätzen, da war das schon 5 mal bei 100% bis da mal "Dateien werden kopiert" steht und dann nochmal 3 mal bis 100% und dann kommt erst Fertigstellen.

[ts-soft]

Du teilst alles in Happen, für Dateien hab ich hier mal ein Beispiel
ausgearbeitet, mußte mal suchen.
Bei Registrierung unterteilste z.B. nach Hauptschlüsseln o. ä. und gibts jedem
Abschnitt einen Prozentwert. Die Geschwindigkeit des PCs ist dabei
unwichtig.
Über eine globale Variable erfährt das Timer-Callback, wieweit der
Fortschritt sein soll.

Ist eigentlich nicht so besonders Aufwendig. Ein bissel Tricksen, damit der
Anwender immer das Gefühl hat, es passiert noch was und gut ist

[rolaf]

Also ich würde das schon am Code festmachen wenn ich einen solchen Laufbalken benutze. Es gibt nichts schlimmeres als ein solchen Balken der zuende gelaufen ist und das Progie braucht aber noch ein paar Minuten. Da trommeln viele nervös auf der Tastatur rum und denken an Absturz.

Zu irgendeinen Zeitpunkt muß es doch absehbar sein wie viele (meist Schleifen) noch zu bearbeiten sind um den Balken zu steuern?

[Riacon]

das kann man doch hochrechnen. hat man nach einer sec. 1% der arbeit erledigt, braucht man für den rest noch 99 sec.. bei der zweiten sec. macht man eine neue hochrechnung, usw.. am anfang "springen" die schätzungen noch etwas, werden dann aber immer genauer