VirtualTreeView - Wer hat die Weiterentwicklung übernommen

[sh17]

Hallo R2009,

das Smiley am Ende meines Beitrages sollte dessen Ironie ausdrücken. Leider nicht angekommen.

Natürlich ist Doku wichtig und auch Beispiele, die man einfach versteht und nachvollziehen kann. Wie gesagt, bin ich auch bereit ein paar neue Demos beizusteuern.

Und auch wenn der Start mit VST schwer ist, verspreche ich Dir, das sich der Einsatz, sich da einzuarbeiten bezahlt macht. Ich weiß gar nicht, was ich ohne VST noch machen würde. Dieses universelle Teil hat bei uns sämtliche unnutzbaren Grids (DB-, String-,...) abgelöst.

Natürlich kenne auch ich nicht alle Tiefen des Vst, aber was ich brauch, das geht hervoragend.

Also bleib dran,

Sven

[Tyrael Y.]

Zitat:

Zitat von R2009

...
Solche Aussagen sin der erste Schritt zum Tod eines Tools oder hier des VST.
Es gibt keine fehlerfreie Software.

Vile Grüsse

Ich glaub nicht das VST sterben wird.
VST ist die einzige Delphi Komponente, die bei mir nach einer Installtion von Delphi sofort drauf muss.
Es gibt keinen Grid und keinen Treeview, das annähernd so gut ist.

Man kann damit mehr machen als die meisten im ersten Augenblick vermuten. Das Ding ist echt ne Eierlegendewollmilchsau...wer es nicht nutztn möchte, bitte schön.

Am Anfang als ich VST noch nicht kannte, hätte ich mir auhc mehr Doku gewünscht, um den Einstrieg zu erhalten. Aber seien wir mal ehrlich, das Ding ist kostenlos, was will ich mehr?

@R2009 Die Autoren von VST wird es denke ich nicht interessieren, ob du VST nutzen möchtest oder nicht, sie wollen für die immensen Leistungen, die sie in dieses Produkt gesteckt haben keine Vergütung haben und du meckerst, weil keine "ausreichende" Doku dabei ist. Eine Doku darüber wäre ein ganzes Buch, das Ding kann wie gesagt viel mehr als du denkst. Im ganzen Internet und auch hier im Forum sind ettliche Beispiele, ausserdem kann man hier auch fragen bei Problemen stellen.

Ach wenn es den Eindruck macht ich wolle dich zum nutzen des VST bekehren, mitnichten.
Wer Vorteile nicht nutzen möchte, der soll mal schön bei Stringgrid und Treeview bleiben, das passt schon.


Edit: Das wichtigste hab ich glatt vergessen.....
DANKE! an alle Entwickler von VST, natürlich einen besonderen Dank an den Vater des Ganzen, einen großen Dank an Mike Lischke.

[R2009]

Hi sh17,

eigentlich wollte ich dich (euch) ja nur dazu bringen das Ganze etwas durchsichtiger zu machen.
Vielleicht ist auch gut mal etwas nicht zu implementieren (man kann nicht alle Wünsche erfüllen).
Ich hatte auf jeden Fall, für ein zu renovierendes Tool, die Auswahl den VST zu nehmen oder ein
Eigenkonstrukt. Noch ist die endgültige Entscheidung nicht gefallen.
Ohne das Video von Daniel hätte ich nicht die Spur einer Chance gehabt.
Mit Video ging das so mit ach und krach. Ich bin nicht alleine meine Kollegen, alles professionelle
Informatiker ging das genauso.

Seht das als konstruktive Kritik. Macht etwas in Richtung Tutorial.
Vielleicht kann unsereins ja helfen. Wär nicht schlecht.

Viele Grüsse

[sh17]

Ich kenn jetzt das Video von Daniel nicht, aber es gibt ja schon mal ein paar verschiedene Möglichkeiten Daten anzeigen zulassen - und alle haben ihre Berechtigung. Manche sind komplizierter als andere

z.b. über .RootNodeCount := und OnInitNode
oder über .AddNode

Die Anzeige über Records und .GetNodeData oder direkt über Referenzen (Node.Index)

usw.

Kommt halt immer auf den Anwendungsfall an. Deinen kennen wir jetzt hier nicht.

Da es jetzt OT wird.

Wohin sollte ich den neue Demos schicken, falls gewünscht. Damit sie z.B. ins Setup kommen oder wohin auch immer.

[Daniel]

Nur kurz der Vollständigkeit halber: "Das Video von Daniel" ist eine Aufzeichnung des 2. Delphi-Stammtisches. Die Arbeit wurde von generic erledigt. Ihm gebührt der Dank. :-)

[madas]

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

Delphi-Quellcode:

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

nach

Delphi-Quellcode:

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

Delphi-Quellcode:

function TBaseVirtualTree.GetMaxColumnWidth

.
Hier wird für jeden Node die Funktion

Delphi-Quellcode:

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

[uligerhardt]

Zitat:

Zitat von Tegi

Wie gesagt, wenn ihr Wünsche habt, her damit ;-)

Sind Mantis und Forum auf soft-gems.net noch relevant? (Siehe http://support.soft-gems.net/forums/...pic.php?t=2239)

[Assertor]

Hi,

gibt es eigentlich eine Empfehlung was man statt toAutoSort nutzen kann? Ich hab in Anlehnung zu meinem Thread hier gerade ein Demo erstellt.

Das Problem hat nichts mit Datenbank & Co zu tun. Einfaches VST mit 2.500.000 Einträgen und ein OnCompareNode für Index-Nummer - das killt bei jeder RootNodeCount-Änderung die Performance.

Gibt es von den Entwicklern eine Empfehlung für eine schnelle "Einsortierung" neuer Nodes? Ich kann dazu im Moment nichts finden. Probiert habe ich InsertNode, AddChild mit amInsertBefore, amInsertAfter und auch testhalber ohne BeginUpdate/EndUpdate.

Prinzipiell ist die Performance ja super - 2,5 Mio Nodes sind in 1,2 Sekunden sortiert. Aber wenn die Anzahl der Nodes stetig zunimmt, wird jedesmal der ganze Tree neusortiert...

Ich stehe da heute auf dem Schlauch, liegt wohl am Frühlingsanfang :mrgreen:

Gruß Assertor

[Assertor]

Hi,

zu meinem vorherigen Post: Problem gelöst, Beschreibung im oben verlinkten Thread.

Gruß Assertor

[TUX_der_Pinguin]

Hmm ich weiß nicht ob es um einen Bug handelt oder sich das Verhalten geändert hat. Ich habe immer mal wieder die neuste
Version via Setup von VirtualTreeView installiert. Wie auch jetzt wieder (4.8.5) jedoch habe ich einen merkwürdigen Effekt.

In meiner Anwendung habe ich mehr Daten als angezeigt werden können, gehe ich jetzt durch die Daten (Pfeiltasten, Bild auf etc.)
wird zwar der Focus geändert, aber die Komponente scrollt nicht mehr mit. Also der cursor wandert aus dem Sichtbaren bereich,
normal wäre sobald man unten bzw. oben angelagt das dann automatisch der Gesamte bereich mit gescrollt wird.

Fehler gefunden, in den Properties steht TreeOptions.AutoOptions.toDisableAutoScrollOnFocus auf True anstatt auf False.