[SOLVED] Treeview: full-width background coloring of nodes ... easy?

[d7_2_laz]

Test #1 (proof of concept):
My own test project attached (dark mode files inside, decideable via checkbox for next restart).
Such drastically shortened and compacted code would now be possible, compared with the original cloning of the whole DoPaintNode procedure! Fantastic!

Test #2 (regressions?):
I recompiled a major app which extensively uses AdvancedCustomDrawItem with you recent patch version / 'main', treeview.inc.
With one small exception i saw none irregularities. The exception: exactly the question of yesterday evening: 'half-line' drawn hot-track indication does now appear full-lined. Solution would be easy to do (the small change mentioned) - but better of course to take the opportunity to upgrade to the much more effective solution.
Might this affect others? Rather unlikely - who does such crazy things.
Note, i can only test on Windows (10, 64bit).

Test #3 / last one (within a NPP plugin DLL, which i know to be very sensible in the redraw area):
No irregularities could be noticed ...

Edit: sorry, there was a little mistake inside the attachment. Just replaced it. - See image

[d7_2_laz]

omg, not my day. Again a little correction (concerns the selected node when 'half-line' painting is choosen). I'd missed that in a hurry.

[wp]

Yeah, looks good.

I wrote another demo which I intend to put into the Lazarus examples folder. Find it in the attachment. Writing this demo I found some more small glitches, and I also saw that the DoPaint procedure changes the brush after the user event as well - this makes it impossible to draw an background image or a background gradient in the entire treeview image. The modifications are in the attached zip, along with the demo which now contains separate event handlers for each drawing task, and I hope that this way it becomes clearer what needs to be done to achieve a specific effect.

[d7_2_laz]

Wow ... those changes and demo are miles of progress ahead, and the demo a Must for the examples folder   
Full support from my side!

I'll try to apply those handlers - from a user's app side perspective - to my own demo soon (as use case), for to see how far i can achieve.

[wp]

Committed to Lazarus/main. Since it contains a lot of changes and due to the pending release of v4.0 I will not back-port it to the fixes branch; this means that you'll have to wait for v5.0 to have it in a release.

[zeljko]

Yeah, looks good.

I wrote another demo which I intend to put into the Lazarus examples folder. Find it in the attachment. Writing this demo I found some more small glitches, and I also saw that the DoPaint procedure changes the brush after the user event as well - this makes it impossible to draw an background image or a background gradient in the entire treeview image. The modifications are in the attached zip, along with the demo which now contains separate event handlers for each drawing task, and I hope that this way it becomes clearer what needs to be done to achieve a specific effect.

Looks nice, please commit it to the examples, it'll help me a lot for gtk3 implementation.

[d7_2_laz]

Committed to Lazarus/main ....... wait for v5.0 to have it in a release.

wp, thank you!
No problem, in so far it relates to DoPaint resp. DoPaintNode, i'll apply to earlier versions manually.

I just updated my own use-case demo for here to get rid of the cdPostPaint (for some special mixed cases earlier it had been a bit tricky for me to find out when, in cdPostErase, DefaultDraw has to be false and when true).
Added also an TLMEraseBkgnd handler for to smarten the app start in dark mode.

[zeljko]

Committed to Lazarus/main. Since it contains a lot of changes and due to the pending release of v4.0 I will not back-port it to the fixes branch; this means that you'll have to wait for v5.0 to have it in a release.

Thanks, tested with gtk3 and it seem that everything works ok except for last option (disabled first node), but themes aren't implemented yet in gtk3 so could be related.

[wp]

@zeljko: Added another sample with rounded rectangles for the nodes, but here something seems to be wrong with the RoundRect procedure in gtk3 (shifted horizontally), the other widgetsets are fine.

[d7_2_laz]

@wp: had integrated the patch into Lazarus 3.8 successfully for three major apps, saving by that tons of, before, annoyingly cloned code lines. That's a pleasure to see and a great improvement!

During that i'd noticed that for the combination: RowSelect - HotTrack - Themed an "HideSelection := False" won't work.
It can easily be seen using treeview_demo_2.zip as from Fec. 07 above.
It's a bit a pity, as a lost indication of a selected node/row could be certainly inconvenient for some use contexts.

So my question: does anyone know more about if for RowSelect with HotTrack using [tvoThemedDraw] it should be possible to suppress HideSelection?
Should HideSelection False be able to play together with tvoThemedDraw?

Maybe that's rather a separate dedicated topic apart from the customdraw logics.

[d7_2_laz]

If the opinion should be: HideSelection:=False should be able to play together with tvoThemedDraw of rowselected nodes,
then tnis could be a test to play and test with:
referring to the commit about DoPaint/DoPaintNode Lazarus/main:

Code: Pascal  [Select][+][-]

1. procedure TCustomTreeView.DoPaint;
2. ......
3.   Include(FStates, tvsPainting);
4.   try
5.     if Focused then
6.       Include(FStates,tvoFocusedPainting)
7.  
8.     else                                               // == Test add
9.     if ((Selected <> nil) And Not HideSelection) then  // == Test add
10.       Include(FStates,tvoFocusedPainting)              // == Test add
11.  
12.     else
13.       Exclude(FStates,tvoFocusedPainting);
14. ......

[wp]

This always has been twisting my mind. In particular the inverted logic of HideSelection...

I am attaching a project in a Delphi and Lazarus version. There are checkboxes to toggle the RowSelect, HotTrack and HideSelection properties (HotTrack has been hard-wired to true in the Lazarus version, since the Delphi tree cannot be unthemed).

The observation that I make in Delphi:

• Toggling "HideSelection" between true and false toggles the visibility of the selected node, no matter what RowSelect and HotTrack are. The selection rectangle is gray.
• With HideSelection=false (i.e. show the selection when the tree is not focused) does not change the appearance of the selected node --> RowSelect does not work in Delphi
• Having HotTrack=true and moving the mouse over the nodes always shows the bright blue hottracked color, no matter whether HideSelection is on or off, or the tree is focused or not.

In the Lazarus version I see (without your patch from the previous post):

• Toggling "HideSelection", once the tree is no longer focused, never displays the selected node, no matter what RowSelect and HotTrack are. This is a bug.
• With HideSelection=false (i.e. show the selection when the tree is not focused) the gray selection rectangle is seen (correct), but only when RowSelect is false (--> bug). When HideSelection is true, no selection is displayed (see /1/).
• Having HotTrack=true and moving the mouse over the nodes shows the bright blue hottracked color when the tree is focused, and the gray hottracked color when the tree is not focused. I think this behaviour is more consistent than Delphi's blue selection even in the non-focused case.

After application of your patch, I see

• Toggling "HideSelection", once the tree is no longer focused, always displays the selection, as gray when HideSelection=true (there should be no selectionat all), or bright bordered blue when HideSelection= false (as if the tree were focused). Both are wrong.
• With HideSelection=false, RowSelect=true displays the full width selection (correct) (but no selection at all once HideSelection = true -- see /1/).
  
• HotTrack = true -- no change

Doing the same with Laz 3.8 we have

• Toggling "HideSelection" with tree unfocused always displays the selection, as gray. Gray is correct, but the selection should disappear when HideSelection becomes true.
• RowSelect=true always shows the full width selection (correct), bright bordered blue when the tree is focused (correct), gray when the tree is not selected (correct, but only when HideSelection=false -- see /1/).
• HotTrack=true - looks correct considering that the underlining used in Laz 3.8 applies only to the width of the caption and thus makes the choice of RowSelect ineffective.

So, there's still a lot to do (well, at least also the old version and Delphi have problems, too)...

[d7_2_laz]

Thanks wp - i share most of your observations, so only a few remarks:

3.8 with patch:
About 1, "Toggling 'HideSelection'": "but the selection should disappear when HideSelection becomes true":
at that point (checkbox clicked) there will be only a "flag" set that comes into effect at next draw. -> TreeView1.Invalidate;
About 2: RowSelect OFF:
             HideSelection true:
               difference between gray (not focused) and lightblue indication (focused). For me ok resp. not a problem
             HideSelection false 
               same color when focused or unfocused, ok
         RowSelect ON -> no different colors for focused or unfocused states (i had not intended such)
         
'main' with patch:
       RowSelect ON: behaves same as in 3.8/patched
       RowSelect OFF, HideSelection false or true: behaves same as in 3.8/patched

In sum: (only about themeddraw here):
- No different behaviour 3.8 and 'main' regarding Non-RowSelected items (i think. All other would be a regression and bad).
- There is (without patch) a difference between RowSelect and Not-RowSelect regarding 'HideSelction'.
  In so far as with RowSelect and HideSelecton OFF a selection marker completely stays disappearing. That was the reason for my thought.  With the patch this indication is preserved.
- But the indication for unfocused selected nodes has no different color here than for focused nodes
-> yes, i'm fully aware and had not intended to trigger even this  complex area. Because i think it's better to have any reference to a selected node than none at all.  A matter of taste maybe.
For such reasons i normally use the un-themed way (customdraw).

I'd thought it could be a little goodie to spend the themeddraw a simple possibility to keep a selection when unfocused, but probably it's better not to step further here, as apparently more complications come up.

[d7_2_laz]

Just an idea (appears to work. - About: RowSelect, HideSelection OFF,  a different color than selection color wanted):

Code: Pascal  [Select][+][-]

1.   procedure DrawSpecialBackground(IsSelected, IsHot: Boolean; ARect: TRect);
2. ..............
3.     if tvoThemedDraw in Options then
4.     begin
5.       if (tvoFocusedPainting in FStates) then
6.       begin
7.  
8. // Test - lines added:
9.         if (IsSelected And ((Not Focused) And (Not HideSelection))) then
10.           //Details := ThemeServices.GetElementDetails(ttItemSelectedNotFocus)  // Doesn't generate a recognizable color yet
11.           Details := ThemeServices.GetElementDetails(ttItemHot)   // Only for to see if it would work. It does!
12.         else
13.  // end Test
14.  
15.         if IsSelected then
16.           Details := ThemeServices.GetElementDetails(ttItemSelected)
17.         else
18.         if IsHot then
19.           Details := ThemeServices.GetElementDetails(ttItemHot);
20.         ThemeServices.DrawElement(Canvas.Handle, Details, ARect, nil);

Only a poc.
Sadly, 'ttItemSelectedNotFocus' wouldn't return a good color. - Maybe an approach.

[d7_2_laz]

About the test change above and 'ttItemSelectedNotFocus' i had not been quite precise.
- With bright theme if would seem ok: it would look like unfocused items with RowSelect OFF: gray.
- With dark theme the color delivered is hard to recognize.
Just checked if one could influence via metadarkstyle: uwin32widgetsetdark.pas, 'DrawTreeView'-> yes - but this is surely offtopic here. So basically one cuuld sue 'ttItemSelectedNotFocus'.
(There had been already a conversation about, see:)
https://github.com/zamtmn/metadarkstyle/issues/32