> I've moved my progress bar dialog out of the UI thread, and the main > thread dialogs still (undesirably) show up on bottom. I've added > SetWindowPos (with &wndTop), still broken. > Added BringWindowToTop(), still broken. Never called > ShowWindow(SW_SHOW) on the dialog for my UI thread, still broken.
Oh! > Then I removed the 'Create' call from the dialog window for my UI > thread... and now all of the main thread dialogs seem to show up on > top, as I want. Good! > So the problem seems to arise from the fact that I have a separate UI > thread which owns a CDialog box. If I take away that CDialog box from > the UI thread, then all works fine. Hmm, you're not really supposed to do that IIRC. MFC windowing system does a lot beneath your nose, and parts of that are thread-specific. > The reason that I put a CDialog in my other thread is because I need a > window to receive WM_COPYDATA messages from a separate application. I > need an hWnd for the SendMessage of the COPYDATASTRUCT. My original > design had the receipt of the WM_COPYDATA message in my main thread, > but it was causing problems with the other application so I moved it > to its own thread. > > So... I need an hWnd for receiving WM_COPYDATA messages, but when I > put that window in a separate thread it causes main application thread > dialogs to show up at the bottom z-order. > When I don't put that window in a separate thread, it causes problems > with the application that is sending me the WM_COPYDATAs. help! OK. Now I've got a nearly complete picture of what you're trying to do. So, here are my thoughts: 1. You don't specify what "problem" occurs when you move the window that is supposed to do the WM_COPYDATA stuff to your main thread. I can't think of any problem that gets fixed by moving the window into a second thread (in fact, I can only think of problems that arise when you do so, like you've observed.) 2. Here is the model I suggest for implementing the system: Handle the WM_COPYDATA message in your main (UI) thread. You don't need any special window for just that purpose; you could use any window that your app already creates (and there should at least be one such window, since your app is GUI-based) and handle the WM_COPYDATA message. But if you for whatever reason prefer a separate window, a CDialog is overkill! Simply create a CWnd window, and it should suffice the purpose of catching the WM_COPYDATA message. Let the handler of the WM_COPYDATA message create a new buffer using C++ operator new, and copy the original buffer's contents into that buffer. Then, it would signal an event object, to sign the worker thread of the arrival of the new data, and forget about the newly created buffer. From this point on, the buffer is owned by the worker thread. The worker thread sleeps on the event using WaitForSingleObject( ) (or maybe another function of the wait family) and when this function returns, the data has been received by the UI thread. Then the worker thread will do whatever it should do, and finally delete the data buffer (remember, the data is now owned by the worker thread.) This should be enough to implement the scenario you describe, and it will work. 3. If you have control on that other application, you might consider some other IPC method. WM_COPYDATA is among one of the most inefficient methods of IPC. The best one available to you is a memory mapped file, plus a named kernel object (like an event) in case you need signalling mechansim that SendMessage( ) simulates. ------------- Ehsan Akhgari Farda Technology (http://www.farda-tech.com/) List Owner: [EMAIL PROTECTED] [ Email: [EMAIL PROTECTED] ] [ WWW: http://www.beginthread.com/Ehsan ] Man is something that must be overcome: and therefore you will love your virtues,- for you will perish by them.- -Thus Spoke Zarathustra, F. W. Nietzsche _______________________________________________ msvc mailing list [EMAIL PROTECTED] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
