Stop ShowDialog from removing focus from the parent form

Question

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:

1. disable the window effect which makes it look like it has lost the focus (blocking Window messages maybe?)
2. 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.

Answer 1

Friend NotInheritable Class Win32
  Public Const WM_NCACTIVATE = &H86
  Public Const WM_SDLG_ACTIVATE = &H8000

  <DllImport("user32.dll")> Public Shared Function GetForegroundWindow() As IntPtr
  End Function

  <DllImport("user32.dll", SetLastError:=True, CharSet:=CharSet.Auto)> _
  Public Shared Function SendMessage(ByVal hWnd As IntPtr, ByVal Msg As UInteger, ByVal wParam As IntPtr, ByVal lParam As IntPtr) As IntPtr
  End Function
End Class

To stop the main form appearing to lose the focus when in the dialog - in the main form: -

Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)

    Select Case m.Msg
        Case Win32.WM_NCACTIVATE
            Dim m2 As New System.Windows.Forms.Message()
            m2.HWnd = m.HWnd
            m2.Msg = m.Msg
            m2.LParam = m.LParam

            Dim fgwh = Win32.GetForegroundWindow()

            m2.WParam = If(fgwh = Handle, 1, 0) 'title bar state - TRUE for active
            m.Result = 1 'TRUE to do default processing, FALSE to block
            MyBase.WndProc(m2)
            Exit Sub

        Case Win32.WM_SDLG_ACTIVATE
            Dim m2 As New System.Windows.Forms.Message()
            m2.HWnd = m.HWnd
            m2.Msg = Win32.WM_NCACTIVATE
            m2.LParam = m.LParam

            Dim fgwh = Win32.GetForegroundWindow()

            If m.WParam = 0 Then
                m2.WParam = If(fgwh = Handle, 1, 0) 'title bar state - TRUE for active
            Else
                m2.WParam = 1
            End If

            m.Result = 1 'TRUE to do default processing, FALSE to block
            MyBase.WndProc(m2)
            Exit Sub


    End Select

    MyBase.WndProc(m)
End Sub

And in the sub-form: -

Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
    If m.Msg = Win32.WM_NCACTIVATE Then

        Dim fgwh = Win32.GetForegroundWindow()
        Dim wParam As IntPtr
        If fgwh = Me.Handle OrElse fgwh = MainForm.Instance.Handle Then
            wParam = 1
        Else
            wParam = 0
        End If

        Win32.SendMessage(MainForm.Instance.Handle, Win32.WM_SDLG_ACTIVATE, wParam, m.LParam)
    End If

    MyBase.WndProc(m)
End Sub

To stop the main form being deactivated and to get , in the dialog form class: -

Protected Overrides ReadOnly Property ShowWithoutActivation As Boolean
    Get
        Return True
    End Get
End Property

Answer 2

Thanks for the chuckle. It sounds pretty impressive. You may end up regretting the consequences of all this hacking down the line, but I'm not above giving you credit for the fearless attempt to make this work :) I'm assuming you have good reason for doing it that way or you are too far down the road to change it, but it does strike me as odd that you would go through so much trouble to force the UI into being multi-threaded rather than just wrapping business logic into some asynchronous methods. If all the business logic was asynchronous, all the forms could be in one thread. However, be that as it may, my only suggestion to add to what you said would be to ask if showing the form with Show instead of ShowDialog causes the same problem. If Show doesn't have the problem, you could implement your own ShowDialog synchronous method that blocks the thread until the user closes the form. Inside the method it could show itself, then sit in a loop while the form was visible doing a sleep and a doevents and I think that would have the same affect. It makes me cringe a little to suggest it, though.