TTreeView — harmful change of the expand sign type

metadarkstyle/src/uwin32widgetsetdark.pas

Line 619 in 9af2e15

ExpandSignType:= tvestPlusMinus;

Please, do not change the style of the expand sign. If the type of the expand sign is changed in the package, it will affect all existing TTreeView controls in the designer, and thus, it will not be possible to keep e.g. tvestTheme in the application created in the Dark Lazarus.

This problem exists for a while, the package affects not only expand sign but e.g. some colors of the controls and probably other properties. The designer changes those properties and spoil the forms settings. That's why currently I'm using original Lazarus to develop windowed applications and dark Lazarus for non-windowed programs.

Please, try not to explicitly chenge the component properties, so the designer will not change anything without the user knowledge. I suspect that it will be hard or even impossible, so the best solution here is just to exclude the designer window from the theming process, as I sugested in the #1 issue.

Please allow me some additional remarks, as i see it from a purely application code perspective:

With dark theme it was the first time that i decided intentionally to not use the tvestPlusMinus, because i feel the angles do look better with a dark theme (matter of taste).
Imo there's absolutely no reason or need to predefine any ExpandSignType within the uwin32widgetsetdark
Maybe plusminus had been choosen because the tvestTheme does not allow to set any ExpandSignColor (won't have any effect, it's rendered by theme).
The colors via tvestTheme are not good imo: collapsed node signs appear darker than expanded nodes (a kind of 'disabled') and are hard to identify
See image

Which would result in an app as of (unsatisfying):

With the predefinition, anyway it's possible to set another ExpandSignType. But not during a creation phase!
It would need to be done afterwards (after FormCreate, or after a treeview component had been created).
I found tvestAngleBracket to look good, but with a color lighter than SysColor[COLOR_GRAYTEXT].
With that one it might look hard to identify. Eg. with selections when using RowSelect, or doing some special custom drawing.
The contrast with a row’s background color might not been good enough.
See image

I found it good to read when using ExpandSignType tvestAngleBracket and ExpandSignColor $00DDDDDD.
See image

Which would result in an app as of (better):

---- Conclusion in short: ----
I'd vote not to predefine a ExpandSignType. And for ExpandSignColor, define a color lighter than COLOR_GRAYTEXT. Or allow a scheme’s custom setting for the ExpandSignColor.

Please, do not change the style of the expand sign.

As far as I understand, the original part of the question has been solved and the symbol no longer changes in the designer. It may make sense to add the replace symbol option or leave it as is in the theme settings file?

in d683e27 added
TreeViewExpandSignOverride:=true; TreeViewExpandSignValue:=tvestArrow;
you can now control the override of the symbol in the theme config

it remains to decide what to do with the selection colors. let's go beyond Colors[]?

The colors are of course a matter of taste resp. of invividual interests in readability
(mine was specifically driven by the custom painting for the selected and hovered tree nodes, as of the imaages above).

So it's probably a candidate for customization, and so i think too that a setting in udarkstyleschemes
analoguosly to DrawControl.CustomDrawScrollbars could be a good place. Maybe something like
DefaultDark.DrawControl.CustomTreeViewExpandSignColor:=RGBToColor(.... ? ?
(That's what you mean with "beyond Colors[]" ?)

Of course. type tvestTheme wouldn't allow - afaics by nature - to override the color; one must be aware of