🔒 Locked

[MFC] Manupulating a CWnd in another thread

Started by Stoffel May 13, 2002 at 12:29 PM 7 replies 2.3k views

Original Post

May 13, 2002 at 12:29 PM

We''ve had the question come up a couple of times on "how to manipulate an object in the thread that didn''t create it", and the general answer is, "you can''t". The reason for this is that MFC keeps its CWnd map in thread-local storage. However, I was reading Blaszczak''s "Professional MFC w/ VC6.0" this weekend and came across this passage: "...you can''t create C++ objects to resemble Windowsobjects in one thread and then use the C++ object in another. The reason for this is that MFC manages both the permanent map and the temporary map in storage that''s local to each thread. If you need to do this kind of thing, you should first make sure your design is really as sane as you think it should be--do many threads really need to be playing with a single window? If you''re sure that''s the way to go, you must pass the handle to the window from one thread to another and Attach() it in both threads separately." So it appears it is possible, though possibly ill-advised (I tend to agree with that, at least). I haven''t researched this personally, but I thought I''d just throw that out on a Monday morning. =)

declspec

May 13, 2002 at 12:59 PM

hell ya it can be done.

you can make CWnds for windows that arnt even in your app. ive done it.

I wanted to make an app that would push key strokes at a dumb terminal emulator..

so stop how would you go bout this. well the way i use lifted a page from Spy++. i let you drag an icon to a window. then i got the hwnd to that window. note its not even in my app. its anyones window. then i constructed a CWnd object round the hwnd. now you got all of CWnds functionality. i sent keyboard messages via CWnd:

ostmessage.

note that this is phat i didnt need that but i dint know it at the time. you can just use the APIs postmessage after you have the hwnd.

though i never got the border to draw around the target window. i tried and tried. if anyone knows how Spy++ draws forces target windows to draw borders while the cursors over it i would be appreciative. i finally passed it by as cosmetic as i was getting good hwnds from targeting.

also this was the poormans way. hooks and subclassing can do aggressive things.

Stoffel

May 13, 2002 at 3:46 PM

I would guess that it gets the window''s area, and draws the stencil on a new window just over the target window.

declspec

May 13, 2002 at 4:02 PM

actually you know at the time i didnt know how to draw outside my apps window but ive since learned. hadnt thought bout it since that time long ago. so it was kind of static sealed up knowledge. so i opened spy++ just now and its clearly just drawn over. all this time i thought it was messing with the window border.
thanks

Shannon Barber

May 13, 2002 at 4:53 PM

As far as multiple threads updating a window - if you do the ''drop controls on a form'' thing, some controls could have streaming data being sent to them from other threads. Like a video window, or a strip chart. Also a seperate thread could render the scene for an editing tool. It could blit/flip in the client area seperately from the code the paints the GUI, there-by avoiding the freezing the occurs with MFC OnIdle rendering, or message-based render updates. This occurs when the user clicks on a menu item or the title-bar.

I think the primary reason most apps don''t do mutli-thread GUI is beacuse they''re based off of the old Win16 model which didn''t thread. The VCL suffers from this in a couple of areas (sockets come to mind), and MFC as well - like the TLS kluge in question.

Imagine how much more intuitive the MFC progress bar would be, if you could directly & easily update it from a seperate thread.

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

[Look for information | GDNet Start Here | GDNet Search Tool | GDNet FAQ | MSDN RTF[L] | SGI STL Docs | STFW | Asking Smart Questions ]

[Free C++ Libraries | Boost | ACE | Loki | MTL | Blitz++ | wxWindows]

Shamelessly ripped from Oluseyi

Stoffel

May 13, 2002 at 6:21 PM

That''s what I was saying. Apparently you can. ctrl.Attach (hProgressControl) should work in the worker thread. Need to test this myself.

daerid

May 13, 2002 at 7:24 PM

I''ve got that book right here

heh.

As far as I recall, Attach() just attaches the hWnd variable to the CWnd derived c++ object.

Shannon Barber

May 13, 2002 at 9:08 PM

Well, I''d love to test it, but VC7 just f@#%&* me.
When I open up the toolbox, all it list is "pointer" with a weird icon, so I can''t add a progress bar to the dialog...
I see everyday how VMs & exceptions make programs so much more robust...

JonStelly

May 13, 2002 at 9:08 PM

There are two other static member functions, FromHandle() and FromHandlePermanent(). Look into those two functions, each have their own uses when passing MFC objects between threads. The basic rule is, if you need to pass MFC objects that wrap system handles, pass the handles. All MFC classes that represent GDI objects etc... have FromHandle(), FromHandlePermanent() or Attach() functions.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.