How to show progress bar using streaming feature in win32?

In my application I have a simple module, I will read files for some process that will take a few seconds. I was thinking about displaying a progress bar (using a workflow) while files are in progress. I created a thread (code shown below) and also I designed a progress dialog. I used the MyThreadFunction below to display the progress bar, but it just shows only once and disappears, I'm not sure how to get it to work. I tried my best to be inspired by the fact that I'm new to the thread. Please help me with these friends.

reading files
void ReadMyFiles()
{

   for(int i = 0; i < fileCount ; fileCount++)
    {   
    CWinThread* myThread = AfxBeginThread((AFX_THREADPROC)MyThreadFunction,NULL);
    tempState = *(checkState + index);
    if(tempCheckState == NOCHECKBOX)
    {
        //my operations
    }
    else//CHECKED or UNCHECKED
    {
        //myoperation
    }
    myThread->PostThreadMessage(WM_QUIT,NULL,NULL);
    }
}

thread functions
UINT MyThreadFunction(LPARAM lparam)
{
    HWND dialogWnd = CreateWindowEx(0,WC_DIALOG,L"Proccessing...",WS_OVERLAPPEDWINDOW|WS_VISIBLE,
                    600,300,280,120,NULL,NULL,NULL,NULL);
    HWND pBarWnd =  CreateWindowEx(NULL,PROGRESS_CLASS,NULL,WS_CHILD|WS_VISIBLE|PBS_MARQUEE,40,20,200,20,
                            dialogWnd,(HMENU)IDD_PROGRESS,NULL,NULL);

    MSG msg;

    PostMessage( pBarWnd, PBM_SETRANGE, 0, MAKELPARAM( 0, 100 ) );
    PostMessage(pBarWnd,PBM_SETPOS,0,0);
    while(PeekMessage(&msg,NULL,NULL,NULL,PM_NOREMOVE))
    {
        if(msg.message == WM_QUIT)
        {
            DestroyWindow(dialogWnd);
            return 1;
        }
        AfxGetThread()->PumpMessage();
        Sleep(40);
    }
    return 1;


}

      

+2


a source to share


1 answer


Turn it around and put the locking behavior on a worker thread.

This is a common mistake, but it really is NOT worth creating multiple GUI threads in the same process.



Window messages are sent to thread queues: - This means that at some point a child or popup will try to communicate with a locked window on another thread. Even if it is something the user does unexpectedly, like trying to resize or just move the popup. Which means both windows are blocked again with a long process to complete.

+1


a source







All Articles