StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PODoes the managed main UI thread stay on the same (unmanaged) Operation System thread?
text
Body
copied!<p>I am creating a managed WPF UI front-end to a legacy Win32-application. The WPF front-end is the executable; as part of its startup routines I start the legacy app as a DLL in a second thread. Any UI-operation (including <code>CreateWindowsEx</code>, etc.) by the legacy app is invoked back on the main UI-thread.</p> <p>As part of the shutdown process of the app I want to clean up properly. Among other things, I want to call <code>DestroyWindow</code> on all unmanaged windows, so they can properly clean themselves up. Thus, during shutdown I use <code>EnumWindows</code> to try to find all my unmanaged windows. Then I call DestroyWindow one the list I generate. These run on the main UI-thread.</p> <p>After this background knowledge, on to my actual question:<br> In the enumeration procedure of EnumWindows, I have to check if one of the returned top-level windows is one of my unmanaged windows. I do this by calling <code>GetWindowThreadProcessId</code> to get the process id and thread id of the window's creator. I can compare the process id with <code>Process.GetCurrentProcess().Id</code> to check if my app created it.</p> <p>For additional security, I also want to see if my main UI-thread created the window. However, the returned thread id is the OS's ThreadId (which is different than the managed thread id). As explained in <a href="https://stackoverflow.com/questions/1279950/relationship-between-managedthreadid-and-operating-system-threadid">this question</a>, the CLR reserves the right to re-schedule the managed thread to different OS threads. Can I rely on the CLR to be "smart enough" to never do this for the main UI thread (due to thread-affinity of the UI)? Then I could call <code>GetCurrentThreadId</code> to get the main UI-thread's unmanaged thread id for comparison.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload