Dialog 'hang' after C procedure called.
-
I have completed this dialog window reading in filenames and a progress bar to indicate progress. A timer is used to update the progress bar. However, when I called a C procedure that is computationally intensive, all the edit boxes and menu went blank. The worst thing was that the progress bar was not incrementing. Do take note that the program is running fine except for these side effects. The processed output was tested to be correct. Before I include the C procedure, testing was done to make sure the dialog windows work well with the progress bar etc. Please advise if the computationally intensive C procedure resulted in this issue. If yes, how do I overcome it. searcher08
-
I have completed this dialog window reading in filenames and a progress bar to indicate progress. A timer is used to update the progress bar. However, when I called a C procedure that is computationally intensive, all the edit boxes and menu went blank. The worst thing was that the progress bar was not incrementing. Do take note that the program is running fine except for these side effects. The processed output was tested to be correct. Before I include the C procedure, testing was done to make sure the dialog windows work well with the progress bar etc. Please advise if the computationally intensive C procedure resulted in this issue. If yes, how do I overcome it. searcher08
Your app needs to be multithreaded, so the UI updates while your code is taking up lots of CPU. Otherwise, the paint messages are not handled, and your window is not drawn.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Your app needs to be multithreaded, so the UI updates while your code is taking up lots of CPU. Otherwise, the paint messages are not handled, and your window is not drawn.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Can I look your code! May be I can make it better! and then sent it to you. ---++Xu Shanghua
-
Can I look your code! May be I can make it better! and then sent it to you. ---++Xu Shanghua
You send a thread to Mr Christian Graus :rolleyes: you can answer directly to sender question:)
WhiteSky
-
I have completed this dialog window reading in filenames and a progress bar to indicate progress. A timer is used to update the progress bar. However, when I called a C procedure that is computationally intensive, all the edit boxes and menu went blank. The worst thing was that the progress bar was not incrementing. Do take note that the program is running fine except for these side effects. The processed output was tested to be correct. Before I include the C procedure, testing was done to make sure the dialog windows work well with the progress bar etc. Please advise if the computationally intensive C procedure resulted in this issue. If yes, how do I overcome it. searcher08
Calling a function like this periodically (but not too often) during your computations should help:
// DoMessagePump - Allow windows message processing to occur int DoMessagePump() { BOOL bCompleteFlag=FALSE; MSG msg; BOOL bDoingBackgroundProcessing=TRUE; Sleep(1); while (::PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { if (msg.message == WM_QUIT) { bDoingBackgroundProcessing=FALSE; ::PostQuitMessage(0); break; } if (!AfxGetApp()->PreTranslateMessage(&msg)) { ::TranslateMessage(&msg); ::DispatchMessage(&msg); } } AfxGetApp()->OnIdle(0); // updates user interface AfxGetApp()->OnIdle(1); // frees temporary objects if (bDoingBackgroundProcessing == FALSE) return -1; if (bCompleteFlag == TRUE) return -1; return 0; }This code implements basic message passing (the Windows GUI is based on a cooperative multitasking approach, so your code has to "cooperate" LOL). Christian is of course correct - The best way to do this is put your code into a different thread, but that sometimes adds a layer of complexity you don't always need. Beware the calls to AfxGetApp()->OnIdle() - MFC needs this to "breathe" but it can result in lots of overhead in your computation. The more often you call DoMessagePump() the better the GUI response will be, but the longer your computation will take. -
Your app needs to be multithreaded, so the UI updates while your code is taking up lots of CPU. Otherwise, the paint messages are not handled, and your window is not drawn.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
I have not done multi-threading before but looking at the reference books and online tutorial, they are all related to classes or objects. I am only calling a C procedure with a parameter in it. The function needs to be in this form. Do I have to convert my C-procedure to this format? Mine is of the format void decode(char *). UINT MyThreadProc( LPVOID pParam ) // taken from MSDN { CMyObject* pObject = (CMyObject*)pParam; if (pObject == NULL || !pObject->IsKindOf(RUNTIME_CLASS(CMyObject))) return 1; // if pObject is not valid // do something with 'pObject' return 0; // thread completed successfully } Next will be to begin the thread: pNewObject = new CMyObject; AfxBeginThread(MyThreadProc, pNewObject); Where do I put my C-procedure in the above code? How do I know that the thread has ended? Thank you. searcher08
-
I have not done multi-threading before but looking at the reference books and online tutorial, they are all related to classes or objects. I am only calling a C procedure with a parameter in it. The function needs to be in this form. Do I have to convert my C-procedure to this format? Mine is of the format void decode(char *). UINT MyThreadProc( LPVOID pParam ) // taken from MSDN { CMyObject* pObject = (CMyObject*)pParam; if (pObject == NULL || !pObject->IsKindOf(RUNTIME_CLASS(CMyObject))) return 1; // if pObject is not valid // do something with 'pObject' return 0; // thread completed successfully } Next will be to begin the thread: pNewObject = new CMyObject; AfxBeginThread(MyThreadProc, pNewObject); Where do I put my C-procedure in the above code? How do I know that the thread has ended? Thank you. searcher08
Any function that starts with Afx is part of MFC. You can write threaded code without using MFC, and therefore without this format.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Calling a function like this periodically (but not too often) during your computations should help:
// DoMessagePump - Allow windows message processing to occur int DoMessagePump() { BOOL bCompleteFlag=FALSE; MSG msg; BOOL bDoingBackgroundProcessing=TRUE; Sleep(1); while (::PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { if (msg.message == WM_QUIT) { bDoingBackgroundProcessing=FALSE; ::PostQuitMessage(0); break; } if (!AfxGetApp()->PreTranslateMessage(&msg)) { ::TranslateMessage(&msg); ::DispatchMessage(&msg); } } AfxGetApp()->OnIdle(0); // updates user interface AfxGetApp()->OnIdle(1); // frees temporary objects if (bDoingBackgroundProcessing == FALSE) return -1; if (bCompleteFlag == TRUE) return -1; return 0; }This code implements basic message passing (the Windows GUI is based on a cooperative multitasking approach, so your code has to "cooperate" LOL). Christian is of course correct - The best way to do this is put your code into a different thread, but that sometimes adds a layer of complexity you don't always need. Beware the calls to AfxGetApp()->OnIdle() - MFC needs this to "breathe" but it can result in lots of overhead in your computation. The more often you call DoMessagePump() the better the GUI response will be, but the longer your computation will take.I would like to use your method instead of creating another thread. However, the computation procedures are in C and not in C++. I am afraid that the above function may not work in the C code as they are all in MFC. I am calling an extern C procedure from a C++ GUI code. Thanks. searcher08