VirtualTreeView - Wer hat die Weiterentwicklung übernommen

[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 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 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 von toms:

Das offizielle Support Forum ist so gut wie tot.

Ah, das erklärt einiges

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.