in my application i need to create multiple instance of a dialog box. i dont have any idea of implimenting UI-Threads in this. can any one send some example code or can give reference to any site where i can get the solution of my problem.
I've discovered that as I keep dlg.Show()/dlg.Close(), about 150k of memory is eaten up each time, dwindling resources away time after time. If you have an application where this event dialog pops up regularly on certain user clicks, eventually the computer will crash. I've tried looking for the leak but with no success. Any ideas?
The one last problem i found was that while the thread dialog was running in the background and I pressed return - it would close and cause an assertion error. This is because the dlg.Close() command is not called, and the window terminates prematurely. However, there is a way to fix this --- catch the keyboard input before it is processed.
1. Add a "PreTranslateMessage" virtual function to the cWaitDlg.
I tried your cWaitDialog in a Dialog based Window. It does not work. As Chris Joyce said, it never ends. I put a TRACE at the functon cWaitDialog::Close(), it is called, but SetEvent() and CloseHandle() do not seem to end the Wait Dialog.
Please explain why is it so.
I tried calling cWaitDlg from the InitDialog of a modal dialog box. I call Show at the beginning and Close before the return TRUE. After the wait dialog is destroyed, my app is no longer the foreground application in Windows. This doesn't happen when I call it from a control within a CFormView class.
When I added this to my project I had a lot of trouble with various Access Violations and objects not being
deleted. IMHO, cWaitDialog doesn't wait for the cWaitDlgThread to exit after it sets the event. The fix for
this is as follows:
Place this line in cWaitDialog::Show() just before the call to ResumeThread():
If someone is curious, in my submission 'Shutting down workstations' there is a class named CEventDlg with
the same functionality. I was never let down by that old class so, if it is interesting, anyone can use it.
It is true that Jet does not support multi-threading,
however I managed to get it to work fine for me. See
"A class for worker threads - Dominik Filipp" in CodeGuru,
its just the ticket.
If you want total thread safety there is another route...
Create a new process (in own address space ) altogether, perhaps with a window that displays the
progress, then as you process the database write to a Memory-mapped file which is read by the parent process.
You can even send
messages between the two to communicate status'. (See MFC