Form Redrawing

[Michel]

How to force the redrawing of a Form?

 

[Jay B. Harlow [MVP - Outlook]]

Michel,
You can use either:
- Form.Invalidate optionally followed by Form.Update
- Form.Refresh
- Form.Update (if the form was already indirectly invalidated).

Refresh - does an Invalidate followed by Update.

Invalidate - invalidates a specific region of the Control (defaults to
entire client area) and causes a paint message to be sent to the control.

Update - causes the Paint event to occur immediately (Windows will normally
wait until there are no other messages for the window to process).

All three methods are inherited from Control, so you can use them with any
control.

Hope this helps
Jay

 

[Armin Zingler]

How to force the redrawing of a Form?

In addition to Jay's reply: This does work but pay attention when using
WinXP. The window/Form doesn't update after a few seconds even if you call
Refresh! Unfortunatelly, there's no way to force the update. The name for
this annoying "feature" in WinXP is called "ghost window". Search MSDN for
this term. On WinXP, you are now forced to execute Application.Doevents or
put the work in another thread. Both solutions may lead to a lot of more
work than in previous OSes.

 

[Jay B. Harlow [MVP - Outlook]]

Armin,
Curious, I am running WinXP and am using Refresh and it IS updating the
screen and I am not using DoEvents. ;-)

However I am not blocking the windows message queue, I'm in the middle of
dragging the mouse which is flooding the windows message queue with mouse
messages, not allowing the Paint message to be seen. Hence needing Refresh
over just invalidate. In other words threads & do events are not appropriate
in my case. I do use just invalidate in some other places as I do not need
to update the screen immediately...

Do you have a (more) specific link that you are referring to? The one I
found was titled "About Messages and Message Queues", I didn't realize that
XP used a ghost window when you app is hung (i.e. its blocking reading the
windows message queue).

Calling Doevents (or coming up for air as I sometimes say) was a good idea
even in previous versions of Windows. At the very least it allows you to
display a cancel button, so the user can cancel the operation.

Thanks for the additional info.

Jay

 

[Michel]

Thanks for your help,
I already use the refresh into the resize event,
but unfortunatly the mainmenu control on the form
is not redrawed on any case.
That means I need to refresh the control?
I'm trying to use the Me.resizeREdraw = true.
I obtain the good result but at the second resize.
I think the menu is redrawing before that I obtain the resize event
to late to give the right size of my Form?

I run in W2K.

 

[Armin Zingler]

Armin,
Curious, I am running WinXP and am using Refresh and it IS updating
the screen and I am not using DoEvents. ;-)

However I am not blocking the windows message queue, I'm in the
middle of dragging the mouse which is flooding the windows message
queue with mouse messages, not allowing the Paint message to be seen.
Hence needing Refresh over just invalidate. In other words threads &
do events are not appropriate in my case. I do use just invalidate in
some other places as I do not need to update the screen
immediately...

Do you have a (more) specific link that you are referring to?

Only the one...

The one
I found was titled "About Messages and Message Queues",

....you mention here.

I didn't
realize that XP used a ghost window when you app is hung (i.e. its
blocking reading the windows message queue).

Calling Doevents (or coming up for air as I sometimes say) was a good
idea even in previous versions of Windows. At the very least it
allows you to display a cancel button, so the user can cancel the
operation.

You are right, but in previous versions it was still up to me - at least for
internal apps and tools that don't need such a "responsive" UI. I figured it
out when upgrading an application from VB6 that processes a database and
shows the progress (the current database table) in a statusbar. I wondered
why it suddenly takes such a long time to process a single table. Later I
came across this XP "feature" and that only the display, not the application
freezes. Rather annoying. The developers of XP probably thought that they
can show this ghost window because the application doesn't process the
_input_, but they obviously forgot that there is still _output_. At least
there should be an option to turn it off.