Einzelnen Beitrag anzeigen

madas

Registriert seit: 9. Aug 2007
207 Beiträge
 
#56

Re: VirtualTreeView - Wer hat die Weiterentwicklung übernomm

  Alt 20. Mär 2009, 11:39
Hallo,

wir hätten da auch noch ein paar Vorschläge für Änderungnen am VST:

1. betrifft das Scrollverhalten:

- alle Scroll-Optionen des VST stehen auf Standard
- keine fixedColumns

hat man nun Spalten, die links bzw. rechts nicht komplett zu sehen sind oder
klickt auf eine Spalte rechts oder links neben der Center-Spalte, dann wird die
eigentlich nun neu fokusierte Spalte einfach zentriert, obwohl die Optionen dafür nicht
eingestellt sind. Dieses Verhalten ist gerade bei VSTs lästig, die zur Eingabe von Daten verwendet
werden. In älteren Versionen trat dieses Verhalten nicht auf.

Daher würden wir darum bitten in der VirtualTree.pas bei der Funktion ScrollIntoView die Zeile 29188 wie folgt zu ändern:

von

if (Header.Columns.GetVisibleFixedWidth > 0) and (not Center) then nach

if (Header.Columns.GetVisibleFixedWidth > 0) or (not Center) then 2. betrifft das Bestimmen der optimalen Spaltenbreite:

- VST mit mehr als 20000 Knoten
- OnBeforeCellPaint Event ist fürs VST registriert
- eine Spalte mal größern oder kleiner ziehen

Zur Optimierung der Spaltenbreite dieser Spalte macht man ja nun oben im Header einen
Doppel-Klickt, da wo man auch die Spalte breiter zieht. Hat man das gemacht, kann man
sich erstmal in Ruhe einen Kaffee holen und warten bis die Spalten optimiert wurden.

Verursacht wird das ganze durch die Funktion
function TBaseVirtualTree.GetMaxColumnWidth .
Hier wird für jeden Node die Funktion
DoGetCellContentMargin(Run, Column) aufgerufen. Diese ruft DoBeforeCellPaint mit cpmGetContentMargin als Parameter auf.
Aber egal, ob man auf diesen Parameter im Event-Handler regiert
(d.h. sämtliche Aktionen in OnBeforeCellPaint auslässt, wenn CellPaintMode = cpmGetContentMargin) oder nicht,
dauert die Berechnung extrem lange.

Wir haben dann eine abgeleitete Komponente vom VST erstellt, wo wir die Berechnung selber machen.
Hier ein Code-Schnipsel:
Delphi-Quellcode:
    merkOnBeforeCellPaint := vst.OnBeforeCellPaint;
    try
      vst.OnBeforeCellPaint := nil;
      cWidth := vst.GetMaxColumnWidth(Column); // hier wird die Methode GetMaxColumnWidth von TBaseVirtualTree aufgerufen
    finally
      vst.OnBeforeCellPaint := merkOnBeforeCellPaint;
    end;
Wie man sieht wird vor der Berechnung der Event zwischen gespeichert und auf nil gesetzt und nach
der Berechnung wiederhergestellt. Mit dieser Ergänzung läuft das Berechnen der Spaltenbreite wieder so schnell,
wie früher. Auch die Anzeigen von der abgeleiteten Komponente und dem org. VST sind nach der jeweiligen Berechnung
identisch. Daher unsere Frage wofür wird die Funktion DoGetCellContentMargin überhaupt gebraucht und warum ist das
ganze so extrem langsam im org. VST? Es wäre nett wenn dieses Verhalten korrigiert wird.

Vielen Dank.

MfG

madas
  Mit Zitat antworten Zitat