在没有调试器的情况下运行时，ProgressBar会卡住

Question

I'm working on a Visual C++ application, and part of this depackitises a file, sinjce this can take a while I implemented a progress bar to reflect the progress of the depackitisation.

This works fine when running with the debugger, however when I run without the debugger or from the .exe file, the progress bar consistantly gets stuck at halfway (although the program completes its function fine), and then jumps to 100%.

Through some printing of the value of the progress bar I have discovered that the value IS getting set properly, but for some reason this is not being reflected visually.

The code for the progress bar update is

while (mpeg.GetProgress() < 99){
            Console::Write(this->progressBar->Value);
            this->progressBar->Value = mpeg.GetProgress();
            this->progressBar->Update();
            Sleep(100);
        }

This is done in the programs main thread. The sleep stops it from updating too quickly as otherwise this is impossible to follow in the console.

The function which needs tracking is mpeg.Depackitise(), this is run in a seperate thread so that the progress bar can continually be updated, the code concerning the 'progress' variable is :

double Mpeg::GetProgress() {
return Mpeg::progress;
}

void Mpeg::SetProgress(double prog) {
Mpeg::progress = prog;
}

The follwing code is in a for loop that goes through the entire file packet by packet. The 'packet' variable is the current packet and 'packet_count' is the total number of packets in the file, this is all done in the seperate mpeg.Depackitise() thread.

        double Percent = 0.0;

    Percent = ((double)packet / (double)packet_count);
    SetProgress(Percent * 100);

If anyone can suggest some solutions to try it would be highly appreciated, this has been annoying me for a while now. Some suggestions I found online said that use of uninitialised variables could cause differences between running with/without debug, however I can't find any relevant variables that are uninitialised.

Answer 1

You must never, ever, ever block the UI thread.

You're doing extensive calculations in the main thread of your application, which means its not available to answer the message pump and to draw/update drawings of controls on the screen.

You should look into multithreading and message passing as the solution to your question. Start a thread, do the time-consuming work there, use a callback to update the progress bar of the main thread (and beware of directly accessing the UI from anything other than the main thread!).