Inconsistent flicker of a static control

[jj2007]

I have a series of controls created as follows:

Code Select Expand

invoke CreateWindowEx, 0, chr$("static"), NULL,
  WS_CHILD or WS_VISIBLE or SS_LEFTNOWORDWRAP or SS_NOTIFY or SS_NOPREFIX or SS_SUNKEN,
  -1, -1, 1, 1, hWnd, ctCtrls, wcx.hInstance, NULL

They all get updated once per second.

Often, at least one of them flickers. I tried  or WS_CLIPSIBLINGS and  or WS_CLIPCHILDREN, no effect.
Often, after a while the flicker stops.

Has anybody stumbled over something similar?

[fearless]

Could try setting wc.style to 0 when creating the main window (Invoke RegisterClassEx, addr wc) and WS_CLIPCHILDREN style for main dialog resource.

[HSE]

Hi JJ!

WS_CHILD or WS_VISIBLE or SS_CENTER it's what I use for static.

Need You SS_NOTIFY? Perhaps triggers a event. Make a test removing that.

[jj2007]

Thanks, fearless & HSE - both very good suggestions. I tried them but the problem persists :(

[TouEnMasm]

Search the old forum for flickering,there is a lot of samples and a less number of solutions.
How is created the control isn't an enough information,there is need of more code to get an idea of
what happen in the WM_PAINT message.

[TouEnMasm]

This sample give various results on differents versions of Windows.
Frequency and time needed by the WM_PAINT message is the key.
http://www.masmforum.com/archive2005/flick.zip

[jj2007]

This sample .. flick.zip

Merci, Yves. Chris Hobbs suggests double buffering, but that won't help with a simple static control.
The other hint, duration of wm_paint, looks more promising. Will keep you posted 8)

[dedndave]

possibly not a double-buffering issue, anyways

there is an objectionable flicker caused by the OS continually re-drawing the background, then the foreground
you can overcome this by disabling the background updates and drawing the background and foreground together

[jj2007]

there is an objectionable flicker caused by the OS continually re-drawing the background, then the foreground
you can overcome this by disabling the background updates and drawing the background and foreground together

how would you do that?
it's a static control; in its subclass, I get the WM_ERASEBKGND once, but afterwards it continues flickering...

[Adamanteus]

That's maybe not ordinary decision, but could depends on map file of program - so, is need to rebuild in etalon Microsoft's environment.

[jj2007]

I managed to isolate the problem, attached a plain Masm32 source+exe.
It updates the display once every 200ms, showing the current GetTickCount.
By default, it shows in the console the WM_SETTEXT message, as it arrives in the subclass proc.

By pressing h, you can stop that display - and it starts flickering.
Press s to show the message in the console - and it stops flickering.

So flickering of the static control depends on whether some text is shown in the console window or not. IMHO that doesn't make any sense, dear friends in Richmond

Interesting also that the phenomenon is present only on Win7-64. Both XP and 8.1 show NO flicker.

[HSE]

Hi JJ!

In Win7-32bit it's the same, but flickering become irrelevant if You intercept WM_CTLCOLORSTATIC, and a little better  if You also intercept WM_GETICON, in WndProc.

Why that messages? I don't know. But remember: it's not a bug, just has features you need to understand (Hutch)

Regards. HSE
 

[jj2007]

flickering become irrelevant if You intercept WM_CTLCOLORSTATIC

Thanks. What exactly did you try? For me, only HOLLOW_BRUSH eliminates the flicker :(

Code Select Expand

  CASE WM_CTLCOLORSTATIC
  invoke GetStockObject, HOLLOW_BRUSH
return eax

[HSE]

I think console also is flickering at same rate.

Perhaps your friends from Richmond have problems with the icon, because none is in the taskbar (and are trying again and again?).

[jj2007]

Perhaps your friends from Richmond have problems with the icon, because none is in the taskbar (and are trying again and again?).

Muchas gracias :icon14:

Interesting: WM_GETICON is indeed being sent (three times), but it can't be the culprit because afterwards the flicker continues but the message stops.

Anyway, I am designing a workaround now, will let you know tomorrow.