views:

497

answers:

3

Preface: I know this is an unusual/improper way to do this. I can do this with a "real" ShowDialog(), background worker/thread, and so on. I'm not looking for help doing it that way; I am trying to do specifically what I describe here, even if it is ugly. If this is impossible for X reason, please let me know though.


I have created a fancy progress dialog for some of our long running operations. I need to have this dialog shown on a new thread while having processing continue on the calling (UI in most cases) thread.

This has 3 real requirements:

  • Prevent user interaction with the calling form (similar to ShowDialog(this))
  • Keep the progress dialog above the main window (it can fall behind now)
  • Allow the main thread to continue processing

What I have looks like this (and works just fine so far, as far as running goes, except for those issues above):

Using ... ShowNewProgressDialogOnNewThread() ...
      Logic
      UpdateProgress() //static
      Logic
      UpdateProgress() //static, uses Invoke() to call dialog
      ...
End Using  // destroys the form, etc

I have tried a few ways to do this:

  • ShowDialog() on BackgroundWorker / Thread
  • Action.BeginInvoke() which calls a function
  • ProgressForm.BeginInvoke(... method that calls ShowDialog... )
  • Wrapping main form in a class that implements IWin32Window so it can be called cross-threaded and passed to ShowDialog() - this one failed somewhere later one, but at least causes ShowDialog() to not barf immediately.

Any clues or wisdom on how to make this work?

Solution (For Now)

  • The call to EnableWindow is what did what I was looking for.
  • I do not experience any crashes at all
  • Changed to use ManualResetEvent
  • I set TopMost, because I couldn't always guarantee the form would end up on top otherwise. Perhaps there is a better way.
  • My progress form is like a splash screen (no sizing, no toolbar, etc), perhaps that accounts for the lack of crashes (mentioned in answer)
  • Here is another thread on the EnableWindow topic (didn't reference for this fix, tho)
+1  A: 

I wrote a blog post on this topic a while ago (dealing with splash forms, but the idea is the same). The code is in C#, but I will try to convert it an post it here (coming...).

Fredrik Mörk
No need to convert, I speak both :) Reading it now...
Andrew Backer
This has a similar effect to what I am doing right now with an explicit thread (New Thread(AddressOf ...).SetApptState().Start()). The issue is that I have a window in the background that I need to prevent interaction with, like a real ShowDialog() would do. Currently I can click on the window in the BG and it will receive focus, placing the progress window in the background.
Andrew Backer
+1  A: 

I know it's a bit dirty but can't you just do the work in the dialog??

I mean something like

Dialog.MyShowDialog(callback);

and do all the work in callback as well as the UI update.

That way you'll retain the ShowDialog behaivour while allowing different code to be called.

Jorge Córdoba
I could, but that isn't what I want to do for this dialog.
Andrew Backer
And this is way easier in C# where I can use a lambduh and have the compiler do the hard work of hoisting the variables for me. But the target is vb devs on the team, including myself, so thats a no-go until 4.0.
Andrew Backer
+3  A: 

Getting the progress window consistently displayed on top of the (dead) form is the difficult requirement. This is normally handled by using the Form.Show(owner) overload. It causes trouble in your case, WF isn't going to appreciate the owner form belonging to another thread. That can be worked around by P/Invoking SetWindowLong() to set the owner.

But now a new problem emerges, the progress window goes belly-up as soon as it tries to send a message to its owner. Somewhat surprisingly, this problem kinda disappears when you use Invoke() instead of BeginInvoke() to update progress. Kinda, you can still trip the problem by moving the mouse over the border of the disabled owner. Realistically, you'll have to use TopMost to nail down the Z-order. More realistically, Windows just doesn't support what you are trying to do. You know the real fix, it is at the top of your question.

Here's some code to experiment with. It assumes you progress form is called dlgProgress:

Imports System.Threading

Public Class ShowProgress
  Implements IDisposable
  Private Delegate Sub UpdateProgressDelegate(ByVal pct As Integer)
  Private mOwnerHandle As IntPtr
  Private mOwnerRect As Rectangle
  Private mProgress As dlgProgress
  Private mInterlock As ManualResetEvent

  Public Sub New(ByVal owner As Form)
    Debug.Assert(owner.Created)
    mOwnerHandle = owner.Handle
    mOwnerRect = owner.Bounds
    mInterlock = New ManualResetEvent(False)
    Dim t As Thread = New Thread(AddressOf dlgStart)
    t.SetApartmentState(ApartmentState.STA)
    t.Start()
    mInterlock.WaitOne()
  End Sub

  Public Sub Dispose() Implements IDisposable.Dispose
    mProgress.BeginInvoke(New MethodInvoker(AddressOf dlgClose))
  End Sub

  Public Sub UpdateProgress(ByVal pct As Integer)
    mProgress.Invoke(New UpdateProgressDelegate(AddressOf dlgUpdate), pct)
  End Sub

  Private Sub dlgStart()
    mProgress = New dlgProgress
    mProgress.StartPosition = FormStartPosition.Manual
    mProgress.ShowInTaskbar = False
    AddHandler mProgress.Load, AddressOf dlgLoad
    AddHandler mProgress.FormClosing, AddressOf dlgClosing
    EnableWindow(mOwnerHandle, False)
    SetWindowLong(mProgress.Handle, -8, mOwnerHandle)
    Application.Run(mProgress)
  End Sub

  Private Sub dlgLoad(ByVal sender As Object, ByVal e As EventArgs)
    mProgress.Location = New Point( _
      mOwnerRect.Left + (mOwnerRect.Width - mProgress.Width) \ 2, _
      mOwnerRect.Top + (mOwnerRect.Height - mProgress.Height) \ 2)
    mInterlock.Set()
  End Sub

  Private Sub dlgUpdate(ByVal pct As Integer)
    mProgress.ProgressBar1.Value = pct
  End Sub

  Private Sub dlgClosing(ByVal sender As Object, ByVal e As FormClosingEventArgs)
    EnableWindow(mOwnerHandle, True)
  End Sub

  Private Sub dlgClose()
    mProgress.Close()
    mProgress = Nothing
  End Sub

  '--- P/Invoke
  Public Shared Function SetWindowLong(ByVal hWnd As IntPtr, ByVal nIndex As Integer, ByVal dwNewLong As IntPtr) As IntPtr
    If IntPtr.Size = 4 Then
      Return SetWindowLongPtr32(hWnd, nIndex, dwNewLong)
    Else
      Return SetWindowLongPtr64(hWnd, nIndex, dwNewLong)
    End If
  End Function

  Private Declare Function EnableWindow Lib "user32.dll" (ByVal hWnd As IntPtr, ByVal enabled As Boolean) As Boolean
  Private Declare Function SetWindowLongPtr32 Lib "user32.dll" Alias "SetWindowLongW" (ByVal hWnd As IntPtr, ByVal nIndex As Integer, ByVal dwNewLong As IntPtr) As IntPtr
  Private Declare Function SetWindowLongPtr64 Lib "user32.dll" Alias "SetWindowLongW" (ByVal hWnd As IntPtr, ByVal nIndex As Integer, ByVal dwNewLong As IntPtr) As IntPtr

End Class

Sample usage:

  Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    Using dlg As New ShowProgress(Me)
      For ix As Integer = 1 To 100
        dlg.UpdateProgress(ix)
        System.Threading.Thread.Sleep(50)
      Next
    End Using
  End Sub
Hans Passant
I take your username as a promise :) Seriously though, thanks for the details on why it doesn't really work. I figured I'd have a hard time of it, but it'd be easier for my consumers with existing code. Put all the hard stuff in one place, hopefully.
Andrew Backer
Heh.. I was looking at something else that mentioned calling "EnableWindow".. we'll see how that goes.
Andrew Backer
I got this to work well so far! It was the EnableDisable call that did it. I also changed over to using the ManualResetEvent, rather than a variable, I didn't even know about that one.
Andrew Backer