Secondary Message Loop vs Separate Input Thread

Question

I am talking about a Windows desktop application. I am looking to write a function such as SelectObject (for example) which blocks the caller till the user clicks on an object in the application's client area. Once the user has selected an object, the function returns a pointer to it.

One way to do this is to run a small message loop and filter out WM_MOUSE* while passing other messages back to the outer message loop. (CRectTracker does this I think.)

This could also be redesigned to run the caller in a separate thread of it's own. SelectObject will then use CreateEvent/SetEvent/ResetEvent to synchronize with the main thread which handles the mouse messages and returns control once the conditions satisfying object selection are met.

What are the pros and cons of each approach? Where can I find more information on such designs? What are the formal terms for such things?

Programmers who have closely observed or worked with AutoCAD may understand what I have so badly conveyed here.

Answer 1

I don't know of a term for it, but the kind of function you describe is one I'd call a modal function, in the same vein as a modal window. It sounds like you want something a little like TrackPopupMenu. I expect it works like you described, with a message loop that handles mouse and keyboard messages for the popup menu.

I think your thread idea will just get complicated for little benefit. The messages for the underlying window are still going to go to that window's thread, not your separate thread, and any painting you do on that window will have to occur in that window's thread as well.

Are you aware of SetCapture? I think it might be helpful in getting where you're trying to go. It allows you to funnel all mouse events to a single window, even while the mouse isn't over that window.

Answer 2

Modal has no sense in Win32. SelectObject is completely off-topic (GDI)