Really need a way to process events!

[hakermania]

QApplication::processEvents() or QApplication::processEvents(QEventLoop::AllEvents) doesn't seem to work at all with me for an unknown reason.
I have a void function that executes some commands and another one that updates the progressbar while the commands are executed, which can take a little time to execute. So the code looks like:

//void function that executes the commands:
update_bar("Executing command one",0);
system("command1");
update_bar("Executing command two",25);
system("command2");
..
..
update_bar("Done",100);

//void function that executes the commands:
update_bar("Executing command one",0);
system("command1");
update_bar("Executing command two",25);
system("command2");
..
..
update_bar("Done",100);

To copy to clipboard, switch view to plain text mode 

the update_bar function is:

void update_bar(QString txt, int value){
    ui->progressBar->setValue(value);
    ui->progressBar->setFormat(txt);
    QApplication::processEvents(QEventLoop::AllEvents);
}

void update_bar(QString txt, int value){
    ui->progressBar->setValue(value);
    ui->progressBar->setFormat(txt);
    QApplication::processEvents(QEventLoop::AllEvents);
}

To copy to clipboard, switch view to plain text mode 

Unfortunately, while I am setting the value and the format of the progressbar 5 times (at 0,25,50,75 and at 100%), when calling the update_bar function, the progressbar only updates at 50 and 100%, skipping the 0,25 and 75% and their texts..


QApplication::processEvents is the second time that makes me dizzy on how it works...

Is there anything available that is more efficient, or do you have to suggest an other way of using this function so as to update?

[franz]

QCoreApplication:rocessEvents() is nasty. I wouldn't use it for anything (ran into odd issues too often because of it). There are some approaches you could take, but the best is probably to use QProcess with some signal/slot magic. Instead of waiting for the process to finish, the events will be processed. You would get a sort of state machine

// connect this slot to QProcess::finished(...)
void MyClass:nextSystemCall()
{
    switch (m_state) {
        ...
        // execute some call depending on state
    }
    emit progressChanged(progress);
}

// connect this slot to QProcess::finished(...)
void MyClass:nextSystemCall()
{
    switch (m_state) {
        ...
        // execute some call depending on state
    }
    emit progressChanged(progress);
}

To copy to clipboard, switch view to plain text mode 

You could consider checking the result values of the executed processes as well.

This whole approach will rid you of the need to call processEvents(). Disable certain parts of your GUI if you have to.

In addition, your functions just shouldn't take so long that you need to call processEvents(). Besides that, if processEvents() is called in a slot, you might get in ugly trouble with timing and recurring events, but that's another story.

[SixDegrees]

One problem here: your system() call is going to spawn a new shell process every time it is called. This could be fiddling with your timing.

What happens if you replace the system() call with a call to sleep(5) or something similar?