• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 413
  • Last Modified:

MDI with a User Interface Thread

I have a MDI project with several Documents and Views.
I would like to add to the project a CwinThread class (User Interface Thread).
I want this class to have its own message queue (since it different thread),
But the GUI's thread frame should be and behave like regular CMDIChildwns.
How it can be done?
0
yoavm
Asked:
yoavm
1 Solution
 
milenvkCommented:
I think there is no way to do that. If you want to achieve that from your separate user interface thread you have to send WM_MDICREATE to the MDI client window, which, however, is created by the main thread and thus it just does not work, i.e. the MDI client window is created in the main thread and cannot produce new MDI windows to another thread. This simply blocks your way to do what you want. But there sure are other solutions to your problem. Can you specify why you need the separate thread? Then maybe some different solution will pop up here :-)
0
 
piano_boxerCommented:
You can get around the problem of sending WM_MDICREATE to the MDI client window for creation of the new MDI child window, by calling CreateMDIWindow in the child UI thread. I order to do this, you need to completly write your own code to create the frame and view.

The above is no problem, but here comes the trouble: MFC maintains a thread local map of HWND -> CWnd. If you create a new frame and view in another thread than the main, MFC will ASSERT a lot of places because HWND maps to the wrong CWnd object (a temp one).

I have found a solution to this, and it seems to work ok, but I need to tweek the creation of the child frame a little bit more before posting the solution here.
0
 
yoavmAuthor Commented:
to the  piano_boxer:

I would like very much to get this solution.

Thanks,
yoavm
0
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

 
piano_boxerCommented:
Nearly done!
Works great now, I just need to insert code to correctly shutdown the child UI thread(s) when closing the mainframe, and make the UI child thread init function support a user supplied CMultiDocTemplate instead of the hardcoded values i use for testing.
0
 
piano_boxerCommented:
Well.....
At this point I have to say that there is really no reason for creating each view in its own thread. Executing blocking function (Fx: Sleep(10000)), will block the whole MDI user interface anyway. (I suspected that).

I tried to create a toolbar in the context of the child thread, and press a button on it to start executing the blocking function. The function is executed correctly in the context of the child thread BUT still blocks the UI :-(
---
Leave your e-mail here and I'll send the source-code to you (Its really to long to post here).
0
 
BridgeCommented:
Can I have the source as well;
Bridge@quantec.ltd.uk
0
 
yoavmAuthor Commented:
Hi,

My email:  yoavm@ndsoft.com

Thanks.
0
 
yoavmAuthor Commented:
Hi,

My email:  yoavm@ndsoft.com

Thanks.
0
 
mikeblasCommented:
The architecture you suggest is a waste of time. MDI windows are child windows, and will necessarily communicate with their parent window using sent messages. Those sent messages force context switches between the sending thread and the receiving thread, with the sending thread blocking until the receiving thread handles the message.

That's inefficient--you won't get the full multithreading you expect on the thread that owns the child window.

You're _far_ better off with a solution like the MTMDI Sample presents: let the main thread of your application handle the MDI frame window--and even the view. Then, create a child window of the view on a new UI thread.  This creates an extra window, which is also a child--but that child isn't directly involved in the MDI scheme and therefore won't so frequently block on UI messages all the time.  Furhter, it doesn't require any workarounds and results in far simpler and smaller code.

B ekiM


0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now