Asp Forum - LockWindowUpdate - microsoft.public.vb.general.discussion

mm

3/24/2012 12:07:00 AM

Hello everyone,

I see that there are few issues to discuss lately in the newsgroup, so I
propose a subject.

A couple of weeks ago I needed to lock a window update while performing some
intensive drawing tasks, I didn't want to display to the user all the
process, but just the final result.

I know that you can set some controls visible property to false while
performing the changes to acomplish that, but that's not always the case.

There's is an API, as you most likely know about: LockWindowUpdate, that
locks the drawing of a particular window until you finish what you are
doing, and after that frees the window to be drawn with the final result.

The usage is very simple:

' *******
Declare Function LockWindowUpdate Lib "user32" Alias _
"LockWindowUpdate" (ByVal hwndLock As Long) As Long
' *******
LockWindowUpdate hWnd
'do your complex things on the window (usually a form)
LockWindowUpdate 0
' *******

It can lock only one window at a time.
Here it's on the msdn:
http://msdn.microsoft.com/en-us/library/dd145034%28v=vs....
A guy (Raymond Chen), absolutely discourages the use of LockWindowUpdate to
freeze windows and instructs to use WM_SETREDRAW:
http://blogs.msdn.com/b/oldnewthing/archive/2007/02/22/17...

' *******
Declare Function SendMessage Lib "user32" Alias "SendMessageA" _
(ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, _
lParam As Any) As Long
Const WM_SETREDRAW As Long = &HB&
' *******

SendMessage hWnd, WM_SETREDRAW , False, 0&

'do your complex things on the window (usually a form)

SendMessage hWnd, WM_SETREDRAW , True, 0&
' *******

My first note:
After setting WM_SETREDRAW to True it doesn't automatically update the
window, so you need to call RedrawWindow:

' *******
Declare Function RedrawWindow Lib "user32" (ByVal hwnd As Long, _
lprcUpdate As Any, ByVal hrgnUpdate As Long, ByVal fuRedraw _
As Long) As Long

Const RDW_ALLCHILDREN = &H80
Const RDW_ERASE = &H4
Const RDW_ERASENOW = &H200
Const RDW_FRAME = &H400
Const RDW_INTERNALPAINT = &H2
Const RDW_INVALIDATE = &H1
Const RDW_NOCHILDREN = &H40
Const RDW_NOERASE = &H20
Const RDW_NOFRAME = &H800
Const RDW_NOINTERNALPAINT = &H10
Const RDW_UPDATENOW = &H100
Const RDW_VALIDATE = &H8
' *******

SendMessage hWnd, WM_SETREDRAW , False, 0&

'do your complex things on the window (usually a form)

SendMessage hWnd, WM_SETREDRAW , True, 0&
RedrawWindow hWnd, ByVal 0&, 0&, RDW_INVALIDATE Or RDW_ALLCHILDREN
' *******

The problem with WM_SETREDRAW is that the window becomes "as ghost" while
WM_SETREDRAW is set to False, it does not automatically dissapear fro the
screen but you can click through it, the mouse cursor becomes the one of the
window that is behind (for example a text field could change the
mousepointer), and if the window that is behind responds to the mouse over
it, you'll see that painted on the screen (for example a tooltip).
So WM_SETREDRAW doesn't do a good job, and it's not an option.

Aside from dogmatics thing about not using LockWindowUpdate, there are some
problems with it:

1) It does not allow nestled calls.
If you (or a component) call to LockWindowUpdate hWnd more than once, the
first call to LockWindowUpdate 0 will unlock the window, so the user could
see some flicker in such a case.

2) Only one window in the entire system can be locked at a time. That's not
neccesarily a problem but it could be in some special case.

3) The main problem is that the other windows flicker when you call
LockWindowUpdate 0.

4) Can't be in peace with Mr. Chen.

So, what is the "perfect" way to lock the update of a window?

I tried several things, and at last I had to use LockWindowUpdate, but I'm
not very comfortable with that, mainly because of issues 1) and 3).

72 Answers

unknown

3/24/2012 3:06:00 AM

Eduardo wrote:
> 'do your complex things on the window (usually a form)

unknown

3/24/2012 3:08:00 AM

Eduardo wrote:
> 'do your complex things on the window (usually a form)

Rather than using WM_SETREDRAW for the entire form, use it for the
control(s) that you are updating. If you are drawing on the form itself, try
using a PictureBox instead.

mm

3/24/2012 5:25:00 AM

"Farnsworth" <nospam@nospam.com> escribió en el mensaje
news:jkjdrv$9hv$1@speranza.aioe.org...
> Eduardo wrote:
>> 'do your complex things on the window (usually a form)
>
> Rather than using WM_SETREDRAW for the entire form, use it for the
> control(s) that you are updating. If you are drawing on the form itself,
> try using a PictureBox instead.

I'm talking about a generic routine like LockWindowUpdate.

Sometimes there are many things that you do, that can affect unknown
controls or child windows, and also the form itself.

Mayayana

3/24/2012 2:15:00 PM

I use LockWindowUpdate and have no problems
with flickering. I'm aware of the WM_SETREDRAW
recommendation. I haven't looked at this issue for
a long time, but if I recall correctly, WM_SETREDRAW
is using LockWindowUpdate anyway, but didn't work
as well. Since I'm using LockWindowUpdate for a
fraction of a second (I find that it needs to stay under
about 250ms if one is to avoid a visible freeze or flash),
and two programs can't have the active window at the
same time, I don't see the logic of Raymond Chen's
position. He's implying that the system needs to oversee
and portion out calls to LockWindowUpdate, but I just
can't think of a scenario where that's relevant. A program
calling LockWindowUpdate could crash at that moment, but
so what? It seems that at worst another program couldn't
call LockWindowUpdate until the frozen program is closed --
which is hardly an issue.

I'm curious about the issue of other windows flickering.
Other program windows, or other of your own windows,
or other control windows within the same window?
I haven't seen anything like that. I call LockWindowUpdate
on the parent window, with AutoRedraw set to False.
(I think I remember a reason for that, but I can't recall it
offhand now. :)

mm

3/24/2012 8:05:00 PM

"Mayayana" <mayayana@invalid.nospam> escribió en el mensaje
news:jkkh6n$kap$1@dont-email.me...

> [...] I don't see the logic of Raymond Chen's
> position. He's implying that the system needs to oversee
> and portion out calls to LockWindowUpdate, but I just
> can't think of a scenario where that's relevant. A program
> calling LockWindowUpdate could crash at that moment, but
> so what? It seems that at worst another program couldn't
> call LockWindowUpdate until the frozen program is closed --
> which is hardly an issue.

I think I read that any new call to LockWindowUpdate whatever_hWnd will
unlock the previously locked window.

I mean:

LockWindowUpdate X
LockWindowUpdate Y
LockWindowUpdate 0

is the same that

LockWindowUpdate X
LockWindowUpdate 0
LockWindowUpdate Y
LockWindowUpdate 0

> I'm curious about the issue of other windows flickering.
> Other program windows, or other of your own windows,
> or other control windows within the same window?
> I haven't seen anything like that.

Other programs, the explorer, the IDE.
It's not a lot of flicker, but a clear flicker (you don't need to look for
something imperceptible, it's visible).

And I'm not the only one saying that, I read other guys on forums saying the
same.

BTW, on XP.

> I call LockWindowUpdate
> on the parent window, with AutoRedraw set to False.
> (I think I remember a reason for that, but I can't recall it
> offhand now. :)

Mayayana

3/24/2012 11:25:00 PM

| Other programs, the explorer, the IDE.
| It's not a lot of flicker, but a clear flicker (you don't need to look for
| something imperceptible, it's visible).
|
| And I'm not the only one saying that, I read other guys on forums saying
the
| same.
|
| BTW, on XP.
|

I'm mainly on XP and I don't see that. I don't
know why.

mm

3/25/2012 12:24:00 AM

"Mayayana" <mayayana@invalid.nospam> escribió en el mensaje
news:jklhec$b0q$1@dont-email.me...

> I'm mainly on XP and I don't see that. I don't
> know why.

Mmmm, I'm testing, and with a simple test program I don't see the other
windows to flicker, but with a real world program that I have, I see the
flicker on the other windows. I don't know, may be it happens when the form
has some controls, like toolbars, I don't know, but if I comment the
LockWindowUpdate lines the other windows's flicker is gone.

Other people telling the same:

http://www.vbforums.com/archive/index.php/t-... (the last post)

http://stackoverflow.com/questions/1550752/how-can-i-stop-window-rendering-and-la...
"First of all thanks. But in our case it have to be defined under mmc
interfaces... I tried LockUpdateWindow, and it worked, but somehow it made
other windows to flicker :) "

http://www.delphigroups.info/2/ca/2... (the last post)

mm

3/25/2012 12:42:00 AM

"Eduardo" <mm@mm.com> escribió en el mensaje
news:jkl9c7$k6c$1@speranza.aioe.org...

> I think I read that any new call to LockWindowUpdate whatever_hWnd will
> unlock the previously locked window.

Wrong

> I mean:
>
> LockWindowUpdate X
> LockWindowUpdate Y
> LockWindowUpdate 0
>
> is the same that
>
> LockWindowUpdate X
> LockWindowUpdate 0
> LockWindowUpdate Y
> LockWindowUpdate 0

What I'm checking that actually happens is:

LockWindowUpdate X
LockWindowUpdate Y ' this call is ignored
LockWindowUpdate 0

mm

3/25/2012 1:09:00 AM

"Mayayana" <mayayana@invalid.nospam> escribió en el mensaje
news:jklpq8$oeg$1@dont-email.me...
>
> | Other people telling the same:
> |
> | http://www.vbforums.com/archive/index.php/t-... (the last post)
> |
> |
> http://stackoverflow.com/questions/1550752/how-can-i-stop-window-rendering-and-la...
> | "First of all thanks. But in our case it have to be defined under mmc
> | interfaces... I tried LockUpdateWindow, and it worked, but somehow it
> made
> | other windows to flicker :) "
> |
> | http://www.delphigroups.info/2/ca/2... (the last post)
> |
> |
> The first case I'd dismiss because it's a WB control. That's
> really IE, and IE is tied into the system. The last case clearly
> says that flickering is only a problem when the form is resized,
> requiring a repaint of screen area outside the window. I'm
> guessing that's probably what makes the difference. In my
> case I lock a form while an RTB on the form does syntax
> highlighting of its content. I try to stay under 250 ms, and
> nothing else on the screen is likely to be in motion. Also, since
> only the RTB is actually changing, the outside areas of the
> form don't need repainting. I can't detect even a slight wisp
> of motion in other windows when the unlock happens.

Then may be because I apply a new Region to the form window, so the shape of
the form changes.

mm

3/25/2012 1:18:00 AM

"Eduardo" <mm@mm.com> escribió en el mensaje
news:jklr7m$smv$1@speranza.aioe.org...

> Then may be because I apply a new Region to the form window, so the shape
> of the form changes.

Yes, I think that this must be the cause of the flicker, applying or
changing the region of the form at the time that the windows is locked.

microsoft.public.vb.general.discussion

LockWindowUpdate

mm

unknown

unknown

mm

Mayayana

mm

Mayayana

mm

mm

mm

mm

x Login to ForumsZone