WM_CHANGEUISTATE

[Attila Kovacs 617]

As the *UISTATE messages are poorly implemented in the VCL, actually it's just a :

 

procedure TWinControl.WndProc(var Message: TMessage);
.
  if Message.Msg = WM_UPDATEUISTATE then
    Invalidate; // Ensure control is repainted

without storing and checking against the actual UI state, nor checking the wparam if it's only a UIS_INITIALIZE,

 

raises the question:

 

For what the heck is this Invalidate there?

Because it causes a bunch of flickering on pressing the "alt"-key or on calling InsertControl().

What regression will I have if I'm overriding this message in my common TForm like:

 

procedure ChangeUIState(var Message: TMessage); message WM_CHANGEUISTATE;

procedure TCForm.ChangeUIState(var Message: TMessage);
begin
  // do nothing
end;

 

except a faster GUI, no flickering, smoother form-parenting!?

 

 

 

 

[KodeZwerg 54]

You might loose ability that parts are repainted correct.

 

Like pressing alt-key and no underline/shortcut is drawn.

 

Untested, just a guess by reading Msdn.

[Attila Kovacs 617]

@KodeZwerg Hmm, now that you say, I think there is an option somewhere in windows where you can tell if the accelerator keys are by default drawn or only on pressing the alt-key. Maybe. I don't know. Because they are drawn by me all the time (on buttons etc..) and the menus are just working fine without the Invalidate.

So I can't find the regressions, otherwise I could debug and implement a proper handling by storing the form's UI state and call Invalidate if needed.

Thx.

Edited February 25, 2021 by Attila Kovacs

[Attila Kovacs 617]

Okay, there is no more such setting in W10, but I found something interesting:

	There seems to be a problem with THEMES support in Delphi, in which
	TButton, TCheckBox, TRadioButton and TStaticText standard controls
	vanish in VISTA when the ALT key is pressed. (only TStaticText vanishes in XP).
	If the OS is set to default, pressing the ALT key in XP and Vista has the
	behavior of displaying the underline under the accelerator keys.
	The mentioned controls vanish the first time ALT is pressed. They can be
	restored by repainting the control in code. Once restored, they are not
	affected by subsequent ALT key presses -- unless a pagecontrol on the form
	changes to a new tabsheet, then all affected controls, both on the tabsheet
	and on the form, will vanish on next ALT press. Due to the pagecontrol issue
	there is no way to set a flag to do the repaint op only once. In MDI applications,
	an ALT key press has the same affect on all child forms at the same time
	** End quote **************

 

Looks like it's all because of those bugs in XP and Vista.

Now how would it be possible to keep the backward compatibility but not calling Invalidate on > Vista and not checking the OS version in a WndProc?

 

Edited February 25, 2021 by Attila Kovacs

[KodeZwerg 54]

How about check OS version at initialization to create a boolean that be used in handler?

Silly work around just to answer 🙂

 

(SysUtils.Win32MajorVersion is what I would use)

 

(TOSVersion.Major sorry I am sleepy)

Edited February 26, 2021 by KodeZwerg

[Attila Kovacs 617]

@KodeZwerg Not bad at all!  I'm too tired 😉

 

[c0d3r 17]

I saw the code in Delphi 10.4.2, but I don't see any forms flickering in Window 10.

Edited February 26, 2021 by c0d3r

[Lars Fosdal 1730]

/off-topic, but 10.3 and prior versions used to flicker like hell when AD pushed its policy settings.

Fortunately, this has improved with the later versions.