I have a series of controls created as follows:
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?
Could try setting wc.style to 0 when creating the main window (Invoke RegisterClassEx, addr wc) and WS_CLIPCHILDREN style for main dialog resource.
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.
Thanks, fearless & HSE - both very good suggestions. I tried them but the problem persists :(
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.
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
Quote from: ToutEnMasm on April 04, 2016, 05:37:42 PM
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)
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
Quote from: dedndave on April 11, 2016, 03:10:52 AMthere 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...
That's maybe not ordinary decision, but could depends on map file of program - so, is need to rebuild in etalon Microsoft's environment.
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 :eusa_boohoo:
Interesting also that the phenomenon is present only on Win7-64. Both XP and 8.1 show NO flicker.
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
Quote from: HSE on April 12, 2016, 05:46:42 AMflickering become irrelevant if You intercept WM_CTLCOLORSTATIC
Thanks. What exactly did you try? For me, only HOLLOW_BRUSH eliminates the flicker :(
CASE WM_CTLCOLORSTATIC
invoke GetStockObject, HOLLOW_BRUSH
return eax
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?).
Quote from: HSE on April 12, 2016, 09:07:46 AMPerhaps 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.
For those who are still running Windows 7-64, attached a jewel: After years of scientific research, the author is proud to announce the discovery of a new feature: static controls may flicker or not flicker, depending on the so far undocumented SS_NOFLICKER style.
Attached the source and two executables.
Congratulations :t