VirtualTreeView - Wer hat die Weiterentwicklung übernommen

[sh17]

Was für die Zukunft.

Die Möglichkeit, für die Selected Row (langt für multiselect = false) in den einzelnen Cellen Controls einblenden zu können, die den Inhalt der Zelle zum bearbeiten freigeben. So könnte man für eine ganze Zeile z.B. Frame mit Editfelder usw. einblenden. Oder auch Buttons (wofür es ja bereits eine Variante gibt).

Damit liesen sich besser bedienbare Umsetzungen erzeugen.

//Edit
Footer++

[anse]

Zitat:

Zitat von sh17

Die Möglichkeit, für die Selected Row (langt für multiselect = false) in den einzelnen Cellen Controls einblenden zu können, die den Inhalt der Zelle zum bearbeiten freigeben.

Geht ja prinzipiell jetzt schon über OnCreateEditor mit dem IVTEditLink Parameter. Darüber habe ich in HeidiSQL verschiedene Controls eingebunden, z.B. eine Combobox, ein Date-Picker, ein TEdit mit Button und eine TCheckBoxList. Oder meinst du bereits vor OnCreateEditor, also während die Zelle sich noch gar nicht im Edit-Mode befindet?

Footer +1

[sh17]

Zitat:

Zitat von anse

Oder meinst du bereits vor OnCreateEditor, also während die Zelle sich noch gar nicht im Edit-Mode befindet?

Genau, mein ich. Geht besonders schön mit WPF und Styles. Hätte ich aber gern für Win32 und VST ;-)
Quasi ein OnDrawSelectedNode, wo man auf ein Control verzweigt oder was weiß ich, wie man das lösen könnte.

//Edit hab mal ein Bild angehängt, woch wir das mit Buttons machen. Ist aber eher ein Hack.

[sh17]

Wer entwickelt eigentlich VirtualTreeview für FreePascal? Ist der Code komplett abgehängt?

[R2009]

Hallo Entwickler des VST,

ich habe den Eindruck, dass der VST langsam aber sicher zur eierlegenden Wollmilchsau wird.
Habt ihr (Frage an die Entwickler) das alles eigentlich noch im Griff?

Symptome für beginnendes Chaos:
Mal sind die Demos und die Hilfen im Installationspackage drin mal nicht.
Für die Nutzung dieses "Monstrums" muss (oder sollte) man ein Video von gut einer Stunde ansehen.

Mir ist das Ding zu kompliziert, ich nutze es nicht.

Grüsse an alle!
Ps: Jetzt könnt ihr über mich herfallen. Ist aber meine Meinung.

[sh17]

Zitat:

Zitat von R2009

ich habe den Eindruck, dass der VST langsam aber sicher zur eierlegenden Wollmilchsau wird.

richtig

Zitat:

Zitat von R2009

Habt ihr (Frage an die Entwickler) das alles eigentlich noch im Griff?

sicher, stabiler gehts nicht

Zitat:

Zitat von R2009

Mal sind die Demos und die Hilfen im Installationspackage drin mal nicht.

alter hut, braucht eh keiner

Zitat:

Zitat von R2009

Für die Nutzung dieses "Monstrums" muss (oder sollte) man ein Video von gut einer Stunde ansehen.

konzept verstehen, quellen angucken, üben,üben,üben

Zitat:

Zitat von R2009

Ps: Jetzt könnt ihr über mich herfallen. Ist aber meine Meinung.

hiermit getan
:cheers:

[hoika]

Hallo,

ich muss R2009 mal rechtgeben.
Mit Tutorial ist es leicht, einfache Sachen zu machen,
und wenn es erst mal das Ersetzen des TTreeView ist.

Kompliziertere Sachen sind schwer zu lernen.

Ein paar Extended-Tutorials wären gut.

Bin gerade dabei ;)


Heiko

[sh17]

och, ich würde mich da durchaus bereit erklären, mal ein paar meiner Hauptanwendungsprinzipien in form einer demo beizusteuern. Allerdings sollten die offiziell irgendwo untergebracht werden (bei softgems). Irgendwo in einem Thread möchte ich die nicht verbuddeln. Da ist mir die Zeit zu schade. oder vielleicht auch bei codeproject.com, aber so schriftfest bin ich der englischen Sprache nicht.

[hoika]

Hallo,

softgems meinte ich auhc.

Bsp:
Wie bekomme ich 1 einzige Titel-Spalte farbig ?

Wäre sowas wie faq 2.

Wir könnten ja nen Thread aufmachen zum Sammeln.


Heiko

[R2009]

Hallo sh17,

deine Antwort ist aber nicht sehr konstruktiv!
Gerade bei einem solchen Konstrukt sind die Demos existentiell wichtig. Vor
2 Wochen lag da noch eine Version ohne Demos. (Wieso ist das dann ein alter Hut?)
Was soll der sarkastische Satz üben üben üben?
Ich will eben nicht endlos üben sondern das Ding nutzen.
Mit dieser Einstellung hast du mich noch mehr davon überzeugt das Teil nicht zu nutzen.

Noch eine Bemerkung zur Stabilität:
Wir hatten einen Praktikanten der schrieb ein Tool. Nachdem er fertig war wurde er gefragt wo die Doku zu dem Teil sei.
Antwort: Brauch ich nicht mein Programm ist stabil und hat keine Fehler.
Solche Aussagen sin der erste Schritt zum Tod eines Tools oder hier des VST.
Es gibt keine fehlerfreie Software.

Vile Grüsse

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

[Tegi]

@Madas
Benutzt du die aktuelle Version?
Das Autofitting war seit etwa 4.6.x, wenn ich mich recht erinnere langsam, da die Implementierung dummerweise nach dem ersten DoGetCellContentMargin versehentlich mittels WM_SETREDRAW das Zeichnen wieder erlaubte. Das habe ich aber in der 4.8.0 oder 4.8.1 gefixt.
Sowohl in synthetischen Tests, wie auch in Real-World-Applikationen ist die Leistung dadurch deutlich gestiegen.

Ansonsten arbeite ich inzwischen in der Freizeit, so mir welche bleibt :-), an einem Footer. Den Vista-Code habe ich bereits überarbeitet; wenn der Footer fertig ist, kommt das mit.

[OG Karotte]

Zitat:

Zitat von Tegi

Ansonsten arbeite ich inzwischen in der Freizeit, so mir welche bleibt :-), an einem Footer. Den Vista-Code habe ich bereits überarbeitet; wenn der Footer fertig ist, kommt das mit.

Super :thumb:

[sh17]

Zitat:

Zitat von Tegi

Ansonsten arbeite ich inzwischen in der Freizeit, so mir welche bleibt :-), an einem Footer. Den Vista-Code habe ich bereits überarbeitet; wenn der Footer fertig ist, kommt das mit.

Schön ;-)

Schon irgend eine Meinung, wo man ggf. neue Demos unterbringen könnte?

[madas]

Zitat:

Zitat von Tegi

@Madas
Benutzt du die aktuelle Version?
Das Autofitting war seit etwa 4.6.x, wenn ich mich recht erinnere langsam, da die Implementierung dummerweise nach dem ersten DoGetCellContentMargin versehentlich mittels WM_SETREDRAW das Zeichnen wieder erlaubte. Das habe ich aber in der 4.8.0 oder 4.8.1 gefixt.
Sowohl in synthetischen Tests, wie auch in Real-World-Applikationen ist die Leistung dadurch deutlich gestiegen.

Also wir haben es mit der 4.7.0 und 4.8.5 getestet gehabt. Und da war es extrem langsam.
WM_SETREDRAW wird in der VirtualTree.pas genau dreimal aufgerufen. In unserer aktuellen Version (4.7.0)
und in der 4.8.5 passiert dies genau so oft und an den gleichen Stellen. Einzige Änderung die an den
Stellen hinzukam ist (FUpdateCount = 0). Was aber keine Auswirkung hat.

Damit Ihr das Ganze auch mal nachvollziehen könnt, ist im Anhang ein kleines Testprojekt mit "nur" 10000 Knoten (Zeit für Resize wird gestoppt). Ist onBeforeCellPaint als Event registriert dann dauert das Optimieren einer Spalte (unter WinXp) knapp 8s . Ohne onBeforeCellPaint nur 300ms.

Das Projekt wurde unter D2009 erstellt und die Version vom VST ist 4.8.5 .

[pertzschc]

Zitat:

Zitat von madas

Damit Ihr das Ganze auch mal nachvollziehen könnt, ist im Anhang ein kleines Testprojekt mit "nur" 10000 Knoten (Zeit für Resize wird gestoppt). Ist onBeforeCellPaint als Event registriert dann dauert das Optimieren einer Spalte (unter WinXp) knapp 8s . Ohne onBeforeCellPaint nur 300ms.

Ich habe mir den Quellcode des Beispieles mal angeschaut und folgende Frage zu meinem Verständnis:

Delphi-Quellcode:

procedure TForm1.VirtualStringTree1BeforeCellPaint(Sender: TBaseVirtualTree;
  TargetCanvas: TCanvas; Node: PVirtualNode; Column: TColumnIndex;
  CellPaintMode: TVTCellPaintMode; CellRect: TRect; var ContentRect: TRect);
var
  CachedShadowColor: TColor;
begin
  if (CellPaintMode = cpmPaint) then
  begin
    CachedShadowColor := TargetCanvas.Brush.Color;
    try
      if (Odd(Node.Index)) then
      begin
        TargetCanvas.Brush.Color := RGB(225, 225, 225);
        TargetCanvas.FillRect(CellRect);
      end;
    finally
      TargetCanvas.Brush.Color := CachedShadowColor;
    end;
  end;
  inherited;
end;

das wird von Euch nur dazu benutzt, um jede 2. Zeile anders einzufärben?

Wir machen das in einem anderen Event:

Delphi-Quellcode:

procedure TForm1.VST_HostListBeforeItemErase(Sender: TBaseVirtualTree;
  TargetCanvas: TCanvas; Node: PVirtualNode; ItemRect: TRect;
  var ItemColor: TColor; var EraseAction: TItemEraseAction);
begin
  if Odd(Node.Index) then begin
    ItemColor := col_VST_Line2; // auch TColor($F4F2F2);
  end
  else begin
    ItemColor := col_VST_Line1;
  end;
  EraseAction := eaColor;
end;

und haben derartige Probleme mit Version 4.7.0 noch nicht beobachtet.

Gruß,
Christoph

[madas]

Naja wozu sollte OnBeforeCellPaint denn deiner Meinung nach sonst zuständig sein, wenn nicht zum anpassen
vom bestimmten Sachen vor dem Zeichnen?

Btw: Du kannst die komplette Procedure auch leer lassen, bis auf das "inherited;". Selbst dann dauert
es ewig.

Wie gesagt bei den Versionen vor 4.6.x lief das Ganze ja auch noch ohne Probleme. Jetzt nicht mehr.

[pertzschc]

Zitat:

Zitat von madas

Naja wozu sollte OnBeforeCellPaint denn deiner Meinung nach sonst zuständig sein, wenn nicht zum anpassen
vom bestimmten Sachen vor dem Zeichnen?

Schau mal dazu in die VTV-Doku, Stichwort: Paint cycles and stages.

Zitat:

Zitat von madas

Btw: Du kannst die komplette Procedure auch leer lassen, bis auf das "inherited;". Selbst dann dauert
es ewig.

Auch hierzu gibt es in der Doku eine mögliche Erklärung:

Zitat:

before cell paint:
This paint stage is the first of the cell specific stages used to customize a single cell of a node and is called several times per node, depending on the number of columns. If no columns are used then it is called once.

Gruß,
Christoph

[madas]

Zitat:

Zitat von pertzschc

Zitat:

Zitat von madas

Naja wozu sollte OnBeforeCellPaint denn deiner Meinung nach sonst zuständig sein, wenn nicht zum anpassen
vom bestimmten Sachen vor dem Zeichnen?

Schau mal dazu in die VTV-Doku, Stichwort: Paint cycles and stages.

Zitat:

Zitat von madas

Btw: Du kannst die komplette Procedure auch leer lassen, bis auf das "inherited;". Selbst dann dauert
es ewig.

Auch hierzu gibt es in der Doku eine mögliche Erklärung:

Zitat:

before cell paint:
This paint stage is the first of the cell specific stages used to customize a single cell of a node and is called several times per node, depending on the number of columns. If no columns are used then it is called once.

Gruß,
Christoph

Ist ja alles schön und gut. Und es sei mal dahin gestellt, ob unsere Anpassungen an richtiger Stelle gemacht werden oder nicht (Dieser Event wird nicht nur dafür benutzt, um jede gerade bzw. ungerade Zeile anders einzufärben, sondern auch einzelnen Zellen eine bestimmte Farbe zu geben. Und da scheint mir (uns) dies der richtige Event dafür zu sein).
Trotzdem kann es meiner Meinung nach nicht sein, dass ein registrierter Event, dessen Eventhandler praktisch nichts macht, die Performance so in den Keller
zieht.

Aber vielleicht habe ich da auch einen Denkfehler. :gruebel:

[pertzschc]

Zitat:

Zitat von madas

Trotzdem kann es meiner Meinung nach nicht sein, dass ein registrierter Event, dessen Eventhandler praktisch nichts macht, die Performance so in den Keller zieht. Aber vielleicht habe ich da auch einen Denkfehler. :gruebel:

Lass uns doch nochmal nachfragen: warum rufst Du in der procedure eigentlich inherited; auf? Habe das bei den Beispielen hier im Forum noch nicht gesehen und selber auch noch nie so programmiert.

Gruß,
Christoph

[madas]

Zitat:

Zitat von pertzschc

Zitat:

Zitat von madas

Trotzdem kann es meiner Meinung nach nicht sein, dass ein registrierter Event, dessen Eventhandler praktisch nichts macht, die Performance so in den Keller zieht. Aber vielleicht habe ich da auch einen Denkfehler. :gruebel:

Lass uns doch nochmal nachfragen: warum rufst Du in der procedure eigentlich inherited; auf? Habe das bei den Beispielen hier im Forum noch nicht gesehen und selber auch noch nie so programmiert.

Gruß,
Christoph

Das ist noch ein Überbleibsel von unserer abgeleiteten Komponente. Wenn man nur ein normales VST benutzt, dann braucht das dort nicht hin. Aber selbst beim leeren Eventhandler dauert die Optimierung nun mal lange.

@pertzschc: Du scheinst ja das Beispiel runtergeladen zu haben. Dann leere doch Spaßes halber das OnBeforeCellPaint (kommentiere alles aus). Setze den RootNodeCount auf 100000. Dann siehst du was wir meinen.

[Roaster]

Hi,

habe jetzt VST auf die Version 4.8.5 upgedated und seither ein kleines Problem (Endlosschleife) in der Funktion TBaseVirtualTree.GetVisibleParent. Wie mir im Vergleich zu der vorherigen Version von VST (4.7.0) aufgefallen ist, gabe es dort auch einiges an Änderungen:

Alt:

Delphi-Quellcode:

function TBaseVirtualTree.GetVisibleParent(Node: PVirtualNode): PVirtualNode;

// Returns the first (nearest) parent node of Node which is visible.
// This method is one of the seldom cases where the hidden root node could be returned.

begin
  Assert(Assigned(Node), 'Node must not be nil.');

  Result := Node;
  while Result <> FRoot do
  begin
    // FRoot is always expanded hence the loop will safely stop there if no other node is expanded
    repeat
      Result := Result.Parent;
    until vsExpanded in Result.States;

    if (Result = FRoot) or FullyVisible[Result] then
      Break;

    // if there is still a collapsed parent node then advance to it and repeat the entire loop
    while (Result <> FRoot) and (vsExpanded in Result.Parent.States) do
      Result := Result.Parent;
  end;
end;

Neu:

Delphi-Quellcode:

function TBaseVirtualTree.GetVisibleParent(Node: PVirtualNode): PVirtualNode;

// Returns the first (nearest) parent node of Node which is visible.
// This method is one of the seldom cases where the hidden root node could be returned.

begin
  Assert(Assigned(Node), 'Node must not be nil.');

  Result := Node;
  while (Result <> FRoot) and not FullyVisible[Result] do
    Result := Result.Parent;
end;

Mein Coding ist unverändert:

Delphi-Quellcode:

  if (not oNodeData.IsFolder) and (oNodeData.FolderType <> ftyRoot) then
    repeat
      // Step back to get parent
      Result := treeAccounts.GetVisibleParent(Result);
      if Result = nil then
        Break;
      oNodeData := treeAccounts.GetNodeData(Result);
    until (oNodeData.IsFolder) or (oNodeData.FolderType = ftyRoot);

Wobei seit der Version 4.8.5. die Funktion GetVisibleParent() immer wieder den gleichen Node zurückliefert, mit dem ich eingestigen bin. D.h. das Coding niemals mehr auf die Abbruch-Bedingung trifft, da es sich immer um den gleichen (Quell-Node) dreht.

Der Aufbau meines Tree ist sehr einfach: zuerst ein Root-Node und als Child lediglich ein einziger Knoten. Mit diesem Knoten steige ich in die o.g. Schleife ein und ermittle mir zuerst dessen Node-Daten um anschließend dessen Parent zu finden, was eigentlich der Root Knoten sein sollte.

Wie gesagt drehe ich mich in diesem Coding im Kreis, was auf jedenfall auf die Änderungen im Source zu 4.8.5. zurückzuführen ist. Evtl. sogar schon früher, nur meine bisherige VST Version war halt 4.7.0.

[mirage228]

Was mir gerade unangenehm aufgefallen ist, ist die überarbeitete CheckImageKind Property ckSystemDefault. Sie funktioniert schliechtweg nicht.
Früher war es ja so, dass bei aktiven Themes immer die Theme-Aware Check-Images gezeichnet wurde (auch trotz der Standardeinstellung ckLigtGray), mit der Änderung 175 vom 20.02 wurde diese neue Eigenschaft eingeführt.

Das Problem dabei ist das bei ckSystemDefault nichts gezeichnet wird (also gar keine Checkbox -- und man bestehende Trees auf diese Eigenschaft umändern müsste, Kompatibilität zu brechen ist zwar nicht schön, aber das geht noch...).
Das liegt daran, dass in PainTree wohl gar kein CheckImage gezeichnet, wenn in der internen FCheckImages Liste nichts drin ist. Das war früher kein Problem, da der Standard ja ckLightGray war und erst in PainCheckImage (was ja dann aufgerufen wurde) dann nach der ThemeAware Einstellung geschaut (oder ob man selbst die CheckImages zeichnet) und dann evtl. doch die System-Standard-Images zu zeichnen (wie es ja beabsichtigt war).

Da das Problem ja bereits im offiziellen Support-Forum angeprochen, aber darauf noch nicht reagiert wurde, hoffe ich mal, dass die "neuen" Entwickler hier mal reinschauen und ggf. das Verhalten überarbeiten :-)

Viele Grüße

[Roaster]

Zitat:

Zitat von mirage228

Da das Problem ja bereits im offiziellen Support-Forum angeprochen, aber darauf noch nicht reagiert wurde, hoffe ich mal, dass die "neuen" Entwickler hier mal reinschauen und ggf. das Verhalten überarbeiten :-)

Wo bitte ist denn das offizielle Support Forum? Die Newsgroup auf Delphi-Gems?

[toms]

Zitat:

Zitat von Roaster

Wo bitte ist denn das offizielle Support Forum? Die Newsgroup auf Delphi-Gems?

Das offizielle Support Forum ist so gut wie tot. Lang lebe die DP!

[Roaster]

Zitat:

Das offizielle Support Forum ist so gut wie tot. Lang lebe die DP!

Ja, das dachte ich mir auch. Wenn man Glück hat, dann kann man dort vielleicht noch Spam-Mails lesen, aber das war's dann schon.

[mirage228]

Zitat:

Zitat von toms

Das offizielle Support Forum ist so gut wie tot.

Ah, das erklärt einiges :mrgreen:

Mein temporärer Fix sah übrigens so aus:

Delphi-Quellcode:

// procedure PaintCheckImage
(FCheckImageKind = ckSystemDefault)

// wird wieder zu: (wie es vorher auch war)
(FCheckImageKind <> ckCustom)

Damit ist wieder alles wie früher... Wer das also schnell bei sich beheben will, bis eine offizielle Lösung da ist, kann das so tun :)

Viele Grüße

[Tegi]

Neben der Arbeit am Footer plane ich nun eine Zwischenversion, die die genannten Probleme - soweit möglich - behebt. Der aktuelle Stand befindet sich im Anhang.

Zusätzlich neu sind "Hidden Nodes". Damit können Nodes individuell ein- und ausgeblendet werden, was bei einem Tree, der als Grid dargestellt wird u.U. ganz interessant und hilfreich sein kann.

Ich hoffe, ich finde hier ein paar Tester ;-)

[anse]

Hidden Nodes? Gibts doch schon über Nodes.States [vsVisible] - wenn man diese Eigenschaft subtrahiert, wird die Node ausgeblendet. Unschön dabei nur, daß der vertikale Scrollbalken sich nicht ändert, aber das kann man mit einem Workaround lösen:

Delphi-Quellcode:

VT.RootNode.TotalHeight := 0;
Node := VT.GetFirst;
while Assigned(Node) do begin
  if vsVisible in Node.States then
    Inc(VT.RootNode.TotalHeight, Node.TotalHeight);
  Node := Node.NextSibling;
end;
VT.UpdateVerticalScrollBar(True);

Mal eine andere Frage: Es gibt ja die Header.Columns[].Checkbox Eigenschaft. Aber Checkboxen für einzelne (mehrere Zellen pro Node) bekomme ich damit nicht hin. Für die Maincolumn geht das wohl über die TreeOptions.MiscOptions.[toCheckSupport], aber nicht für andere Zellen? Wenn nein, wofür ist dann die Columns.Checkbox Eigenschaft?

[anse]

Multi-Checkboxen sind also gemeint, so wie hier zu sehen: http://www.soft-gems.net/images/stor...-shots/DOM.png
Oder:

Code:

Column1  Col2 Col3
+- Node  [ ]  [x]
+- Node  [x]  [ ]

In keinem der verfügbaren Demos ist dafür ein Beispiel enthalten, daher zweifle ich schon daran daß es geht.

[anse]

Oh... das hier

Delphi-Quellcode:

VT.Header.Options := VT.Header.Options + [hoShowImages];
VT.Header.Columns[x].Checkbox := True;

... zeigt eine Checkbox in der Header-Zeile an. Also hat VT wohl leider keinen Multi-Checkbox-Support für Nodes. Seltsam außerdem daß die Header-Checkbox nur bei hoShowImages angezeigt wird.