Dialog ghost left on window

  • Thread starter Thread starter Developer
  • Start date Start date
D

Developer

Hello,

I have a Systems.Windows.Forms.Form-based window. When I bring up a dialog
to modify the window's view and click OK, the dialog goes away, except the
part of the dialog that overlaps the window remains visible until the window
repaints.

Is there a way to fix this? If there is a lot of processing in calculating
the new view, it is rather unattractive to have part of the dialog still
visible for several seconds.

I can do this:

dlg.ShowDialog();

if (System.Windows.Forms.DialogResult.OK == dlg.DialogResult) {
// call update on the ApplicationForm
// call a method on the dialog to change the view
dlg.SetNewView();
}

dlg.Dispose();

This is unsatisfying, since the user of the dialog has to make two
additional calls; I'd like for all the processing to take place in the
dialog class when the user clicks OK.

TIA for any ideas...
 
This is happening because your parent windows is not receiving a Paint
message. This will not happen until your process completes running. This is
a draw back of Single Threaded windows forms applications. Everything runs
on the UI thread.

The best way to get rid of this problem is to run your process on a
secondary thread. This will allow the Main windows to receive the necessary
Paint messages while your process is running.

Here is a reply from a posting I made a while back that helped me with this
exact same situation.

<<==
First, in your Button.Click event handler, for your 10 min routine, does it
wait in some OS function(like synchronize Device I/O function) or just stay
in a long processing loop? If your Button.Click event handler just fall in
a user mode long processing loop, I suggest you call Application.DoEvents()
method in each loop, this method will peek all the messages(including
WM_PAINT message) from current thread message queue, then process it. It
will give your application a responsive UI.

If your Button.Click event handler is waiting in OS function synchronize
operation such as Device I/O, I think we should use multithreading, just
place the long processing device I/O code in another worker thread. Then
our UI main thread will not be blocked, and we will have responsive UI. In
..Net, we can achieve this with asynchronize delegate, for more information,
please refer to Chris Sells' great article:
"Safe, Simple Multithreading in Windows Forms, Part 1"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/htm
l/winforms06112002.asp
==>
 
Thanks for the reply, Steven.

In my dialog's OnClosed handler, I'm doing this:
// This should invalidate the ApplicationForm...
this.Owner.Update();

// This should allow the ApplicationForm to tell its children to
update...
Application.DoEvents();

// Calc the new view and change the display...
SetNewView();

base.OnClosed(e);

Unfortunately, it doesn't work; the dialog is still left on the document
window.

I've started experimenting with the thread technique in the linked article,
but that hasn't worked yet, either.

C.
 
It seems that OnHandleDestroyed is the place to do the processing.
Validate the user's selection(s) in buttonAccept_Click. In
OnHandleDestroyed, if DialogResult == DialogResult.OK, change the view.
 
Back
Top