Method `TVirtualTreeColumn.GetCaptionWidth` handles owner-drawn caption badly

[hermannoffen]

Method `TVirtualTreeColumn.GetCaptionWidth` handles owner-drawn caption badly

[joachimmarder]

Please respect our guidelines on the project homepage for submitting bugs. Please include your version of Virtual TreeView and attach a sample compiling project as ZIP to your report. If you already have a solution, please supply a patch file.

Since #925 was merged

Well, that was 5 years ago. Maybe the original contributor @lyynxx can comment on this?

[hermannoffen]

Pardon, I've been in a bit of a hurry, yesterday. The issue is easy reproducible in HeaderCustomDrawDemo's tab of Advanced.exe demo of current master (c3ddc11), as well as in the merge commit back then (2d4f75), when hoAutoResizeInclCaption is included in Header.Options property; see Virtual-TreeView-reproduce-issue-#1250.patch. Thus, the issue applies to all versions since 7.3.

This applied, if one holds ctrl-key and double-clicks the column headers' edges, the columns are resized badly:

• The first (index 0) and second (index 1) column each become way to wide, as the captions' widths aren't measured properly.
• The third (index 2) column does not apply a width for the caption's text, which is to be expected here – I guess – because there is no text set at all. Nonetheless, it would be nice to get control over the width being applied or not, e.g. by some event.

Unfortunately, I cannot provide a fix right now. I thought about delegating the text measurement to the already existing method TCustomVirtualStringTree.CalculateTextWidth, but did not find a proper way to call it from class TVirtualTreeColumns without casting its TBaseVirtualTreeView reference to TCustomVirtualStringTree.

[joachimmarder]

The first (index 0) and second (index 1) column each become way to wide, as the captions' widths aren't measured properly

For some reason I could not yet figure out, in TVirtualTreeColumn.GetCaptionWidth() the canvas' font size was very large. I need to debug why this is the case here. Based on the font's size, the width is calculated correctly.

it would be nice to get control over the width being applied or not, e.g. by some event.

Have you tried the OnAfterGetMaxColumnWidth event?

[hermannoffen]

The first (index 0) and second (index 1) column each become way to wide, as the captions' widths aren't measured properly

For some reason I could not yet figure out the canvas' font size was very large. I need to debug why this is the case here. Based on the font's size, the width is calculated correctly.

Yes. The values width is correct, based on the wrong value. Although, the way it's calculated duplicates a more sophisticated logic, elsewhere (see TVirtualTreeColumns.PaintHeader). This is quite uncommon for this project's code. Thus, the value may be equal in value, but logically it's not guaranteed to be the same.

it would be nice to get control over the width being applied or not, e.g. by some event.

Have you tried the OnAfterGetMaxColumnWidth event?

I am aware of the OnAfterGetMaxColumnWidth event. That's what I use ever since to include the column's header's width for the column. If TVirtualTreeColumn.GetCaptionWidth could call TCustomVirtualStringTree.CalculateTextWidth, then the events OnMeasureText… of method TCustomVirtualStringTree.DoTextMeasuring could be used to customize the calculation.

[joachimmarder]

The values width is correct, based on the wrong value.

I found the reason why the font size is so large: It was modified that way in THeaderOwnerDrawForm.HeaderCustomDrawTreeAdvancedHeaderDraw() to draw the world map, but the original font was not restored. This is now changed and the columns now resize OK in your repro steps above.

If TVirtualTreeColumn.GetCaptionWidth could call TCustomVirtualStringTree.CalculateTextWidth

Well it couldn't as, it exists only in the derived class for the Virtual String Tree. Also, the events you mentioned are for painting the client area of the virtual string tree, they can't recognize if some text is from the client area or the header, which by the way has its own Font property. This would be a breaking change, and I don't think it is a good idea to mix up the tree header and the derived class TCustomVirtualStringTree.