Progressbar Handling
-
Ich schaffe es leider nicht eine nette Speicheranimation zu erstellen. Ziel ist es, dass der Benutzer (also ich), sieht wie beim drücken des Save-Buttons eine kleine Progressbar eingeblendet wird und sich füllt.
Hier meine Idee, die zwar eigentlich alles machen würde, aber visuell klappt es nicht, da die Bar nur einmal am Ende kurz aufflackert:
void ControlPanel::saveModel () { ui->ProgressBar->setVisible (true); writeConsole ("saving file: "); //saving for (int i=0; i<101; ++i) { ui->ProgressBar->setValue (i); QTest::qSleep (3); } ui->ProgressBar->setVisible (false); }
- Ja, mir ist klar, dass das Widget gesperrt ist, aber Threads zu implementieren wäre der Abschuss, weil viel zu kompliziert für das was ich haben möchte.
- Ja, ich weiss, dass das nichts macht außer mich warten zu lassen (ist nur ein Placebo), aber ja ich will ihn trotzdem
Das Problem ist, dass das Programm in die Schleife läuft lang bevor die visibility angeschlagen hat.
Ich würde mich brutal freuen, wenn mich da jemand aus meinem ersten naiven Ansatz retten könnte!!
-
Vielleicht solltest du deiner ProgressBar sagen wie groß sie ist? (setRange(0,100);) ?
Anmerkungen:
- es gibt auch show() - macht dasselbe wie setVisible(true) ist aber kürzer und "sprechender"
- es gibt nen Befehl die eventQueue jetzt abzuarbeiten (http://doc.qt.nokia.com/stable/qcoreapplication.html#processEvents) aber ich denke du wirst das garnicht brauchenAbgesehen davon dauert die ganze Choose eh nur 100*3 = 300ms ... vielleicht nimmst du da mal eher 15 statt 3
-
Hallo padreigh,
danke für die Tipps, aber...
padreigh schrieb:
Vielleicht solltest du deiner ProgressBar sagen wie groß sie ist? (setRange(0,100);) ?
Ist natürlich alles schon konfiguriert - nur dass ich dass im Designer gemacht habe (deswegen erbe ich ja auch alles von "ui").
- es gibt auch show() - macht dasselbe wie setVisible(true) ist aber kürzer und "sprechender"
In der Doku steht, dass die die beiden Befehle äquivalent wären... und es ändert sich auch nichts.
Abgesehen davon dauert die ganze Choose eh nur 100*3 = 300ms ... vielleicht nimmst du da mal eher 15 statt 3
Auch das habe natürlich schon gemacht, de facto hatte ich beim ersten mal Einschleifen gleich mal auf insgesamt über 2 Sekunden gesetzt gehabt... habe so herausgefunden, dass mein sweet-spot bzw. Akzeptanzbereich deutlich tiefer liegt was Latenz betrifft
Sonst noch eine Idee, oder muss ich an diese blöden Threads ran, was bei einem event-driven Aufbau mir aber extrem widerstrebt!?!
-
Ich habe aus Spaß mal probiert in jeder Schleifeniterration den show() Befehl auszuführen. Es ändert nichts, er zeigt mir immer erst die volle Bar an... sprich er scheint unabhängig von der Position in der Methode den Aufruf erst ganz am Ende zu machen
Gibt es eine Möglichkeit ihn zu zwingen eine Art drawWidgetUpdate oder irgend was... ?
WIe würdet ihr das lösen, wenn ihr eine visuelle Rückmeldung haben wollt?
-
gut, dass war jetzt alles in allem ein solo gastspiel, aber der vollständigkeit halber hier die antwort...
QTest::qSleep benutzen und alles ist schick! keine ahnung warum, aber jetzt funzts.
cheers
-
Brusik schrieb:
QTest::qSleep benutzen und alles ist schick!
Ich dachte du weisst was du tust
die Api hilft dir weiter:
http://doc.qt.nokia.com/latest/qtest.html#qSleep schrieb:
void QTest::qSleep ( int ms )
Sleeps for ms milliseconds, blocking execution of the test. qSleep() will not do any event processing and leave your test unresponsive. Network communication might time out while sleeping. Use qWait() to do non-blocking sleeping. ms must be greater than 0. Note: The qSleep() function calls either nanosleep() on unix or Sleep() on windows, so the accuracy of time spent in qSleep() depends on the operating system.void QTest::qWait ( int ms ) [static]
Waits for ms milliseconds. While waiting, events will be processed and your test will stay responsive to user interface events or network communication.Btw. das hätte so mE nichtmal kompilieren dürfen da qSleep eine Memberfunktion ist und du hast da garkeit QTest Member ... qWait ist static, da läufts