Can WDF_UNCLICK_BUTTONS affect only WWT_PUSHXXX controls?

[adf88]

My question is about changing (in my eyes it would be a repairing) the behaviour of WDF_UNCLICK_BUTTONS window style.
For present this style has some inconstancies in implementation and enabling it leads to workarounds.

How it works today: when the WWT_PUSHXXX control is clicked then it's lowered and its owning window is marked with 7-tick timeout. After this timeout ALL controls that belong to window are raised up. This is the inconsistency - only WWT_PUSHXXX are automatically lowered and not only WWT_PUSHXXX are automatically raised.
The workaround that we must do when using WDF_UNCLICK_BUTTONS is setting lowered state of window controls in OnPaint handler, we can't set this onece for all the time. This is a very common case.

The only purpose of WWB_PUSHBUTTON mask (WWT_PUSHXXX types contains this mask) is described above.

Only WWT_PUSHXXX controls should be raised up after timeout elapse.
I made this change without repairing windows and it looks like only few of them (toolbar, company window) are broken (I tried to click on almost every button).

Are you (developers) interested in changing WDF_UNCLICK_BUTTONS style behaviour to unclick only WWT_PUSHXXX controls?
Should I provide a patch with this change and repaired existing windows?

PS. Additionally lowered state of WWT_PUSHXXX could be automatically toggled (not just lowering but raising too) when we dont use WDF_UNCLICK_BUTTONS.

[Alberth]

Changed it to the proposed behavior in r17175 yesterday due to problems like you describe in the message options window.

I would be interested in your repair patch.

Albert

[frosch]

Sorry for off-topic. But, adf88, were you referring to alberth's change from yesterday? Or is it a twist of fate that you are asking for something which was done yesterday

[Alberth]

PS. Additionally lowered state of WWT_PUSHXXX could be automatically toggled (not just lowering but raising too) when we dont use WDF_UNCLICK_BUTTONS.

Don't like that.
The current meaning of WDF_UNCLICK_BUTTONS is clear. For new functionality just create a new flag.

[adf88]

Sorry for off-topic. But, adf88, were you referring to alberth's change from yesterday? Or is it a twist of fate that you are asking for something which was done yesterday

Twist of fate, I didn't know about this change till now.

PS. Additionally lowered state of WWT_PUSHXXX could be automatically toggled (not just lowering but raising too) when we dont use WDF_UNCLICK_BUTTONS.

Don't like that.
The current meaning of WDF_UNCLICK_BUTTONS is clear. For new functionality just create a new flag.

Maybe we misunderstood. I'm talking about a case when we do not use WDF_UNCLICK_BUTTONS, the default behaviour. WWT_PUSHXXX are automatically lowered when clicked. Maybe they should be automatically raised when clicked again? Not just "automatically lowerable" but "automatically toggleable". It doesn't affect meaning or behaviour of WDF_UNCLICK_BUTTONS style.

[Alberth]

PS. Additionally lowered state of WWT_PUSHXXX could be automatically toggled (not just lowering but raising too) when we dont use WDF_UNCLICK_BUTTONS.

Don't like that.
The current meaning of WDF_UNCLICK_BUTTONS is clear. For new functionality just create a new flag.

Maybe we misunderstood. I'm talking about a case when we do not use WDF_UNCLICK_BUTTONS, the default behaviour. WWT_PUSHXXX are automatically lowered when clicked. Maybe they should be automatically raised when clicked again? Not just "automatically lowerable" but "automatically toggleable". It doesn't affect meaning or behaviour of WDF_UNCLICK_BUTTONS style.

Is there any use for this feature in current trunk?

I would still make a new flag. There is plenty of room in Window::desc_flags, and it makes the new behavior explicit.

[Alberth]

Update: in r17192 the scenario toolbar buttons got fixed, and in r17194 the depot sell buttons.

[Roujin]

Were the year buttons in the new game window also fixed? They were bugged in r17190.

[Alberth]

Were the year buttons in the new game window also fixed? They were bugged in r17190.

Fixed in r17205