Dialog ghost left on window

28 Jun 2005 4:51 PM

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...

29 Jun 2005 6:07 AM

Steven Perry

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,

Steven Perry

Show quoteHide quote

"Developer" wrote:

> 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...
>
>
>

29 Jun 2005 5:04 PM

Developer

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.

Show quoteHide quote

"Steven Perry" <dotsperrynet@nospam.nospam> wrote in message
news:ED1991E6-3A09-4C6E-853A-41996C67A180@microsoft.com...
> 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,
>
> Steven Perry
>
>
> "Developer" wrote:
>
>> 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...
>>
>>
>>

30 Jun 2005 12:19 PM

Developer

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.

Show quoteHide quote

"Steven Perry" <dotsperrynet@nospam.nospam> wrote in message
news:ED1991E6-3A09-4C6E-853A-41996C67A180@microsoft.com...
> 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,
>
> Steven Perry
>
>
> "Developer" wrote:
>
>> 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...
>>
>>
>>