TVirtualStringTree AutoFitColumns erste Spalte wird nicht angepasst

**TUX_der_Pinguin**

NACHTRAG:

Um wieder auf das eigentliche Problem zurück zu kommen: GetMaxColumnWidth arbeitet ja intern mit Canvas.TextWidth. Wenn man da jetzt dummerweise nicht den String sondern eine getypcastete Referenz auf den String rein wirft, erhält man recht gern den Effekt, dass TextWidth immer identische Werte ausspuckt. Würde also theoretisch das Problem erklären.

Ja aber warum nur bei der ersten Spalte und nicht bei allen, das finde ich ja das total merkwürdige an der Sache.

Jetzt habe mich mal für Spaß die Option vstTable.Header.MainColumn auf 1 gesetzt und siehe da es funktioniert, die erste und auch die zweite Spalte werden angepasst. So bald aber MainColumn wieder auf 0 oder -1 steht klappt es nicht.

**TUX_der_Pinguin**

Ok, ich verstehe es zwar nicht so ganz aber ich glaube ich habe die Ursache gefunden. 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.

zusammenfalten · markieren

Delphi-Quellcode:

			procedure TForm2.Button1Click(Sender: TObject);

var

  Node: PVirtualNode;

  Data: PMyDataSet;

begin

  ShowMessage(IntToStr(vstTable.GetMaxColumnWidth(0, False)));  //62px

  ShowMessage(IntToStr(vstTable.GetMaxColumnWidth(1, False)));  //77px

  vstTable.BeginUpdate;

  Node := vstTable.FocusedNode;

  vstTable.ClearSelection; //Auswahl aufheben

  if Assigned(Node) then

  begin

    Data := vstTable.GetNodeData(Node);

    if Assigned(Data) then

    begin

      Data.Name := Data.Name + 'xyz 12345';

      Data.Desc := Data.Desc + 'xyz 12345';

    end;

  end;

  vstTable.EndUpdate;

  vstTable.FocusedNode := Node;  //Zeile wieder auswählen

  vstTable.Selected[Node] := True; //und markieren

  ShowMessage(IntToStr(vstTable.GetMaxColumnWidth(0, False))); //106px

  ShowMessage(IntToStr(vstTable.GetMaxColumnWidth(1, False))); //127px  

  vstTable.Header.AutoFitColumns(False, smaAllColumns);  

end;

**TUX_der_Pinguin**

Nachtrag:

An Stelle davon die Auswahl aufzuheben und wieder zu setzen kann man auch per vstTable.InvalidateNode(Node); den einzelnen Knoten aktualisieren und dann klappt auch wieder die Berechnung. Trotz alle dem scheint mir das Verhalten etwas merkwürdig zu sein, aber gut mit dieser Lösung kann ich arbeiten.

Vielen Dank bei allen Beteiligten, wünsche euch noch einen schönen Tag

**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.

**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.