I’m working on a multithreaded TDI UI (using C1 DockingTabs if you are interested). So far, I’ve managed to get each window to open in a separate thread and to use the SetParent Win32 API to put it inside the appropriate tab. I’ve also managed to get modal dialogs to show within the tab as well and not block the other tabs from working (by adding a handler on the Shown event on the dialog form to call SetParent again – some fiddling involved with turning on and off TopLevel on the form within the tab, but it works).
Now, what is happening which is a little annoying is that the dialog is opening, which removes focus from the TDI parent form and then focus is immediately being put back. If I call SetParent before showing it, I just get an exception because you can’t have a modal dialog on a form which has a parent. I’ve managed to get around the window animation slide/fade in and out by giving it a size of 0,0 until it is inside the tab, but I can’t work out how to stop the focus flicking off and back on the main parent form.
I imagine that there are 2 possible approaches:
- disable the window effect which makes it look like it has lost the focus (blocking Window messages maybe?)
- actually really stopping it losing the focus
I appreciate that this is a bit of an unusual query, so really glad for any help!
EDIT:
To clarify the point in the exercise – I’ve got a tabbed based UI where each tab is effectively independent. I have had a complaint from the end users that each time something calls ShowDialog, it blocks the entire app instead of just that one tab. The only way that I can see to get around that (short of multi-process like Google Chrome), is to give each tab a separate UI thread and load the dialog inside the tab so that users can still access other tabs. I’ve managed to remove some of the hackiness to some degree and to fix most of the problems now (just been playing some more). I’ve actually managed to fix the question that I asked by blocking the WM_NCACTIVATE message on the main form, although that is a bit messy since now it never shows as deactivated. I guess I’ll have to detect whether the activated form is a dialog child of this one to decide whether to activate or not. I’ve also got some flickering to try to resolve, but it is looking a lot better. I would post code, but there are 3 forms involved so short of uploading the project it would be a bit messy. I’ll see if I can reduce it if anyone is curious?
I’m currently just playing with it as a proof of concept – if I get this working then I need to retrofit it to my existing application, which is where the real fun starts! I have got a framework for controlling the TDI aspects though, so it should be reasonably straightforward from that respect. The real nightmare is going to be auditing the entire thing to work out possible synchronisation issues across the different threads since there are some shared resources that aren’t inherently thread safe.
To stop the main form appearing to lose the focus when in the dialog – in the main form: –
And in the sub-form: –
To stop the main form being deactivated and to get , in the dialog form class: –