[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 408
  • 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
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
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

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

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