TVirtualStringTree AutoFitColumns erste Spalte wird nicht angepasst

[Aviator]

Hallo TUX,

nachdem du das jetzt so sagst erinnere ich mich an etwas. Ich hatte mir mal die Funktion angeschaut wie der VST denn die Berechnung macht ab wann er den Text abschneiden soll. Und das kann er ja nur dann wissen, wenn er die Font Größe und die Breite des Textes auf dem entsprechenden Canvas kennt.

Dein Abwählen der Node hat intern ein Invalidate ausgelöst. Somit ist der Text auf dem Canvas neu gezeichnet worden und die Textbreite kann ermittelt werden. Der Tree weiß ja nicht, wie er auf deine internen Daten zugreifen soll.

Das manuelle Invalidate musst du aufrufen, da du, ohne das Wissen des Trees, die internen Daten veränderst. Würdest du das über einen Editor machen, dann wüsste er es und würde automatisch ein Invalidate veranlassen.

Also von daher ganz logisch!

[TUX_der_Pinguin]

Zitat von Aviator:

Hallo TUX,

nachdem du das jetzt so sagst erinnere ich mich an etwas. Ich hatte mir mal die Funktion angeschaut wie der VST denn die Berechnung macht ab wann er den Text abschneiden soll. Und das kann er ja nur dann wissen, wenn er die Font Größe und die Breite des Textes auf dem entsprechenden Canvas kennt.

Dein Abwählen der Node hat intern ein Invalidate ausgelöst. Somit ist der Text auf dem Canvas neu gezeichnet worden und die Textbreite kann ermittelt werden. Der Tree weiß ja nicht, wie er auf deine internen Daten zugreifen soll.

Das manuelle Invalidate musst du aufrufen, da du, ohne das Wissen des Trees, die internen Daten veränderst. Würdest du das über einen Editor machen, dann wüsste er es und würde automatisch ein Invalidate veranlassen.

Also von daher ganz logisch!

Im Grunde ist es logisch da gebe ich dir recht, nur müsste es dann nicht für alle Spalten NICHT funktionieren.

[Codehunter]

Die Spalte 0 ist insofern etwas besonderes weil dort der Baum, die Nodebuttons, Treelines usw. gezeichnet werden. Da wird intern beim VST sehr viel anders gemacht als bei anderen Spalten. Weil es nicht immer die Möglichkeit gab, die MainColumn zu verstellen, also in früheren VST-Versionen mal hartcodiert "0" war, möchte ich auch nicht ausschließen dass irgendwo noch so eine "harte Null" überlebt hat.

Zitat von TUX_der_Pinguin:

Weil die Zeile ja immer noch den Focus hat und ausgewählt ist wird wohl intern der Inhalt für die erste Spalte geändert so das bei der Berechnung der maximalen Breite keine Veränderung erkannt wird. Hebe ich die Auswahl vor dem Ändern auf klappt es und auch die erste Spalte wird korrekt geändert.

Das ist eher unwahrscheinlich. Der VST ändert eigentlich nicht den Textinhalt von Spalten. Der liest das eigentlich nur aus deinen externen Daten (wie gesagt bei mir immer Records) und pinselt es dann auf die Canvas. Da würde ich vielleicht mehr etwas in der Richtung OnChange vermuten, dass sich externe Dateninhalte bei der Fokussierung eines Node ändern. Mit dem Umweg über das Löschen und Resetten der Selection löst du übrigens OnChange "künstlich" noch einmal aus, das bitte bedenken.

Gerade weil der VST so ein Featuremonster ist, hat man eben auch 1001 Möglichkeiten, im Zusammenspiel mit der externen Logik Bugs einzubauen. Das Herumraten bringt eigentlich nicht sehr viel, man kann das wahrscheinlich nur am konkreten Code debuggen.

EDIT:

Zitat von Aviator:

Dein Abwählen der Node hat intern ein Invalidate ausgelöst. Somit ist der Text auf dem Canvas neu gezeichnet worden und die Textbreite kann ermittelt werden. Der Tree weiß ja nicht, wie er auf deine internen Daten zugreifen soll.

Das ist so nicht ganz richtig. Dann müsste der VST die einmal gezeichnete Textbreite intern puffern. Tut er aber nicht. Tatsächlich holt er sich per GetTextMetrics regelmäßig die tatsächlichen Textbreiten vom jeweiligen DeviceContext und berechnet auch jedesmal neu. Da dürfte es eigentlich gar keine Rolle spielen ob der Node focused ist oder nicht. Welcher Text für die Berechnung verwendet werden soll wird über den Event OnGetText gesteuert. Heißt: Wird GetMaxColumnWidth aufgerufen, dann holt sich VST über OnGetText den passenden String und kalkuliert über GetTextMetrics neu.

[TUX_der_Pinguin]

Zitat von Codehunter:

Die Spalte 0 ist insofern etwas besonderes weil dort der Baum, die Nodebuttons, Treelines usw. gezeichnet werden. Da wird intern beim VST sehr viel anders gemacht als bei anderen Spalten. Weil es nicht immer die Möglichkeit gab, die MainColumn zu verstellen, also in früheren VST-Versionen mal hartcodiert "0" war, möchte ich auch nicht ausschließen dass irgendwo noch so eine "harte Null" überlebt hat.

Das habe ich mir auch schon gedacht das die Spalte 0 doch noch etwas besonders ist und deshalb die Komponente sich anders verhält als bei den anderen Spalten.

Ich habe inzwischen eine Lösung gefunden wenn ich nach dem Ändern des Inhalt vstTable.InvalidateNode(Node); durchführe funktioniert die Berechnung und Anpassung aller Spalten in der Zeile.

[Aviator]

Zitat von Codehunter:

Zitat von TUX_der_Pinguin:

Weil die Zeile ja immer noch den Focus hat und ausgewählt ist wird wohl intern der Inhalt für die erste Spalte geändert so das bei der Berechnung der maximalen Breite keine Veränderung erkannt wird. Hebe ich die Auswahl vor dem Ändern auf klappt es und auch die erste Spalte wird korrekt geändert.

Das ist eher unwahrscheinlich. Der VST ändert eigentlich nicht den Textinhalt von Spalten. Der liest das eigentlich nur aus deinen externen Daten (wie gesagt bei mir immer Records) und pinselt es dann auf die Canvas.

Das ist falsch.
Der VirtualStringTree liest die Daten nicht selbst aus. Er kennt diese nicht einmal. Er reserviert lediglich den Speicher für dich, den du im OnGetNodeDataSize Event oder per Setzen der Property übergeben hast. Die Texte werden immer per OnGetText Event an den Tree weitergegeben. Du musst dem Tree sagen was er in die einzelnen "Cells" reinschreiben soll.

Deshalb ist es auch kein Problem eine Klasse dafür zu verwenden. Das was dann nämlich in NodeData gespeichert wird, ist nur eine Referenz auf die Klasseninstanz. Und die ist (wenn ich mich richtig erinnere) immer 4 Byte (Win32) und 8 Byte (Win64) groß (was nebenbei bemerkt schon der Standardwert der NodeDataSize Property bei Win32 ist).

Wenn man dann zu der Klasse noch eine TObjectList mitführt, dann braucht man auch das OnFreeNode Event nicht mehr zu nutzen. Denn die Daten und die Anzahl der Nodes kommen immer aus der TObjectList. Und die Instanzen die darin gespeichert sind, die werden sowieso von dir verwaltet.

[Codehunter]

Haste vollkommen recht. Siehe mein Edit oben. Hat sich jetzt zeitlich nur überschnitten.

[Aviator]

Zitat von Codehunter:

Haste vollkommen recht. Siehe mein Edit oben. Hat sich jetzt zeitlich nur überschnitten.

Zitat von Codehunter:

EDIT:

Zitat von Aviator:

Dein Abwählen der Node hat intern ein Invalidate ausgelöst. Somit ist der Text auf dem Canvas neu gezeichnet worden und die Textbreite kann ermittelt werden. Der Tree weiß ja nicht, wie er auf deine internen Daten zugreifen soll.

Das ist so nicht ganz richtig. Dann müsste der VST die einmal gezeichnete Textbreite intern puffern. Tut er aber nicht. Tatsächlich holt er sich per GetTextMetrics regelmäßig die tatsächlichen Textbreiten vom jeweiligen DeviceContext und berechnet auch jedesmal neu. Da dürfte es eigentlich gar keine Rolle spielen ob der Node focused ist oder nicht. Welcher Text für die Berechnung verwendet werden soll wird über den Event OnGetText gesteuert. Heißt: Wird GetMaxColumnWidth aufgerufen, dann holt sich VST über OnGetText den passenden String und kalkuliert über GetTextMetrics neu.

Hmm. Von Puffern hatte ich ja auch nichts geschrieben, oder?
Es ist so, dass bei jeder Änderung des Trees, die die Oberfläche betrifft, ein Invalidate des entsprechenden Bereiches ausgelöst wird. Bei ihm wurde das gemacht, weil er die FocusedNode Property gesetzt hat und somit die "Focused Umrandung" (keine Ahnung wie ich das besser beschreiben soll, diese gepunktete Linie die angibt, dass die Node den Focus hat) auf eine andere Node bzw. auf keine Node neu gezeichnet wurde. Hierdurch wurde dann auch gleich wieder das Berechnen der Spaltenbreite ausgelöst.

Die vorherige Spaltenbreite bzw. die Breite der einzelnen Inhalte muss der Tree ja auch nicht kennen. Er durchläuft lediglich die Nodes und holt sich per GetText Event den Inhalt. Die Breite dieses Textes wird dann Canvas bezogen errechnet. Der größte Wert wird dann als Spaltenbreite übernommen. Dazu kommt dann noch TextMargins + NodeLevel(Node) * Indent usw.

[Codehunter]

Ich denke der gedankliche Fehler hierbei ist, dass der gezeichnete Cell-Content in irgendeiner Weise Auswirkung auf das Ergebnis von GetMaxColumnWidth hätte. Dem ist aber IMHO nicht so. Vielmehr sind gerade solche Dinge wie FocusBorder (das gepunktete Dingens) von ihrem Platzbedarf her von vornherein sozusagen reserviert (teilweise über VST-Properties konfigurierbar). Das einzige wo sich hier die MainColumn von anderen unterscheidet ist der dynamische Teil mit den Indents. Also Node expanded oder nicht, mit Childnodes oder nicht, mit NodeButton oder nicht usw.

Deshalb bin ich auch der Ansicht, dass ein InvalidateNode keine Auswirkungen auf das Ergebnis von GetMaxColumnWidth haben dürfte. Es sei denn, man würde eventgesteuert die externen Daten zwischendurch verändern. Was ja, wie bereits geschrieben, nur anhand des konkreten Projektes nachvollziehbar ist und nicht allein anhand des VST-Codes den wir alle haben.

[Codehunter]

Zitat von Aviator:

Deshalb ist es auch kein Problem eine Klasse dafür zu verwenden. Das was dann nämlich in NodeData gespeichert wird, ist nur eine Referenz auf die Klasseninstanz. Und die ist (wenn ich mich richtig erinnere) immer 4 Byte (Win32) und 8 Byte (Win64) groß (was nebenbei bemerkt schon der Standardwert der NodeDataSize Property bei Win32 ist).

Daran habe ich mich ja auch gar nicht gestört sondern an der Art und Weise wie das hier konkret umgesetzt wurde. Ich denke, da werden im Grunde Memleaks produziert. Denn besagter Zeiger muss ja auch irgendwo hin zeigen. Hier sah es so aus als wäre das zunächst ein Zeiger auf einen Zeiger (also 2x4 bzw. 2x8 Byte) und würde dann durch einen Zeiger auf eine Klasseninstanz überschrieben.