Node aus Treeview löschen

[macDoe]

Moin...

Ich bastel ziemlich intensiv mit den TTreevies rum.
Tricky litte Bastards...
Halt so Webshopkram.

Nun möchte ich eine Treeview gern mit größtmöglicher Bequemlichkeit für den User ausstatte.
Es geht darum einen einzelnen Node aus einer Tree Hierachie zu löschen ohne seine Childs zu killen.

Weil kleine Videos mehr als Worte sagen einfach mal anschauen :

http://macs3d.com/downloads/TreeTerror/TreeTerror.html

Vielleicht fällt ja wem was dazu ein :)

es grüßt
der Frank

---------------------------------------------------------------
There is nothing like 127.0.0.1

[Sir Rufo]

Ohne das Video angesehen zu haben ist die Vorgehensweise doch recht simpel:

Alle Children bekommen einen neuen Parent und dann kann der Eintrag entfernt werden.

[macDoe]

War wohl nicht so eine gute Idee so etwas simples hier zu fragen.
Da musste ja so eine Antwort kommen.

Ich hätte auch fragen können wie Ich einen Fusionsreaktor baue.
Theoretisch weiß Ich auch wie es geht nur praktisch gibts da noch so ein kleines 20 Mio Grad Celsius Problem. ;)

[Sir Rufo]

Hast ja recht ... so, ich habe mir gerade mal deinen Source angesehen, bzgl. der internen Verwaltung der Items und da fällt mir doch sofort auf:

Ich komme gar nicht auf deinen Rechner und kann mir das gar nicht ansehen. Also kann es bei so einer generellen Frage auch nur eine generelle Antwort geben.

Was hast du erwartet? Das wir uns irgendeine Struktur ausdenken und uns nachher anhören "nee, das ist bei mir ganz anders!" :roll:

[pelzig]

Wie bekommen meine Kinder einen neuen Vater, ohne mich zu sofort töten zu müssen?

Ich übergebe dem Stiefvater das Sorgerecht :thumb:

Danach kann ich gekillt werden :oops:

Möglicherweise habe ich die Frage aber komplett falsch verstanden.

MfG

[macDoe]

Die Nummer ist doch nicht so einfach wie sie aussieht, was? :-D

Die Sache mit dem Stiefvater ist prima, aber WIE?

Es gibt leider keine remove Methode wie in c++ für einen node. Auch clone() fällt flach.
Das muss man manuell lösen.

Also, wie teile Ich dem Knoten der dem Gelöschten folgt mit das er einen anderen Parent hat?
Das Property node.parent ist nun mal readonly.

Meiner Meinung nach muss ich den Baum eben am dem Knoten nach dem Gelöschten updaten.
Ich nutze sowas schon um meine Sortorder wieder gerade zu ziehen nachdem ich knoten mit Drag&Drop verschiebe.

Ich wollte hier nichts weiter als nen Anstoß ob es nicht eine einfachere Methode gibt als den Rebuild.
Offensichtlich nicht..

Muss Ich es wohl selber machen. Wenns fertig ist poste Ich es...vielleicht. :stupid:

gruß
Frank

was vergessen...
Sir Rufus, alter Haudegen.... Ich wollte Dir nicht auf die Füsse treten. Also nich sauer sein.
Aber mal ernsthaft was willst du in meiner Source sehen oder anders gefragt was musst du sehen um die Problemstellung zu verstehen?

[Uwe Raabe]

Zitat:

Zitat von macDoe (Beitrag 1281896)

Die Nummer ist doch nicht so einfach wie sie aussieht, was? :-D

Sie ist vielmehr sowas von einfach: Zum Verschieben von Nodes gibt es die Methode

Delphi-Quellcode:

MoveTo

und zum Löschen eines Node bietet sich

Delphi-Quellcode:

DeleteNode

an. Allerdings kann ich auch nicht deinen Code sehen und bin somit ebenso auf Vermutungen angewiesen, wo überhaupt dein Problem liegt, wie die anderen hier auch.

[Sir Rufo]

Ich weiß ja nicht mit welchem Kraut du dich da verngügst, scheint aber recht starkes Zeug zu sein.

Wenn wir alle von der VCL sprechen, dann läuft man einfach über die Kinder des zu löschenden Eintrags und führt für jedes Kind die Methode VCL.ComCtrls.TTreeNode.MoveTo aus.

Delphi-Quellcode:

procedure SaveChildren( ANode : TTreeNode );
var
  LChild : TTreeNode;
begin
  while ANode.HasChildren do
  begin
    LChild := ANode.getFirstChild;
    LChild.MoveTo( ANode, naInsert );
  end;
end;

[macDoe]

Würds Du nicht glauben was Ich rauche :shock:

Genau das meinte Ich...ein kleiner Anstoß. Schicken Dank!
Manchmal hat man halt nen Brett vorm Kopp.

Nach dem Durchlauf sollte der Node ja ohne Children sein und dann kann man Delete anwenden.
Weil Delete und DeleteNode() löschen automatisch alle Subnodes mit weg..aber das weiß ja jeder... :wink:

Ich wollt nicht so gern mit Move arbeiten weil das nen Bug hat was die Stateimages betrifft
und weil da kein AddObject() möglich ist. Aber das ist das kleinere Übel.
Die Objektstruktur zu updaten ist einfach.

Ich test das mal aus und rapportiere mich dann

Gruß
Frank

[Sir Rufo]

Und genau das meinte ich. Wenn du das MoveTo nicht verwenden kannst/willst, warum sagst du das nicht gleich und lässt uns hier im Nebel rumstochern.

Warum muss man jede kleine Information dir mühsam aus der Nase ziehen? :roll:

[himitsu]

Zitat:

Zitat von macDoe (Beitrag 1281899)

Ich wollt nicht so gern mit Move arbeiten weil das nen Bug hat was die Stateimages betrifft
und weil da kein AddObject() möglich ist. Aber das ist das kleinere Übel.

Warum wurde das nicht gleich erwähnt?
AddObject: TTreeNodes.AddNode :stuid: (der Parent wird damit auch gleich verschoben)

Nja, das Video war auch ein bissl lang, denn ich dachte es geht nur um das Löschen und wie es vorher dort reinkommt, ist dabei doch egal.
Aber wenn dieses Verschieben (Move) nicht geht, wie hast du dann das andere Verschieben (siehe Video) gemacht und warum wird es hierfür nicht einfach verwendet?

Und wenn das kaputt ist, dann hast du doch bestimmt auch einen Bugreport erstellt?

[macDoe]

Sooo..

habs mal rumprobiert.
Das klappt wie erwartet. Das Problem sind nur die Daten die als Objekt an dem Knoten kleben.
Ich muss danach alle Objects updaten also muss ich eh noch mal durch iterieren.

Daher mache Ich es doch so das Ich mir quasi den Tree ab dem Node der gelöscht wird neu aufbaue.
Das klappt dann auch mit meiner Methode von AddObject().
Dann muss ich nur einen parent updaten und die Objektdaten der folgenden Knoten.
Das ist etwas langsamer, aber seis drum. Dafür muss ich nix Neues mehr basteln.
Die Logik für die Navigation und Update eines TreeView hab ich ja schon fertig.

Aber hat Spaß gemacht die Fummelei. Nochmal schiggn Dank für den Input :)

es grüßt..
der Frank


@ Himitsu :
Weil es ums löschen ging/geht. Move() löscht ja nix, es verschiebt nur.
Den Node der weg soll muss ich danach ja mit Delete entfernen - also auch manuell.
Auch AddNode() ist ok ,aber es nützt mir nichts weil meine Objektdaten nach allen Aktionen,
also nach verschieben, umbenennen, löschen, etc.. sowieso ein Update bekommen müssen.
Ich hätte vllt etwas mehr auf die angehängte Datenstruktur hinweisen sollen :stupid:

[Dejan Vu]

Äh, Moment: Du verschiebst nen Knoten mit MoveTo und anschließend ist das Data-Zeugs weg?

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1281976)

Äh, Moment: Du verschiebst nen Knoten mit MoveTo und anschließend ist das Data-Zeugs weg?

Ja, er will ja nichts darüber erzählen, wie er die Verbindung zwischen den Nodes und seinen Daten hat ... aber du kannst ja mal ganz lange Finger machen und das aus dem Riechorgan herauskitzeln ... ;)

[macDoe]

Ähem...
Die Daten sind nich wech... surprise, surprise :stupid:

Das Einzige was ich tun muss ist eigentlich das eine relevate Datenfeld,
nämlich meine ParentID, beim verschieben zu beackern. Um den Rest kümmert Move() sich selbst.
Danach muss ich nur noch die State Images updaten - et voilá, c'est ca..

Tja... Kaum macht man(n) es richtig schon klappt das...hab ich mal irgendwo gelesen..

Das ganze Problem ist der Parentkey in meinen Daten. Der muss korretk sein.
Der Tree organisiert sich selbst wenn drin rumwerkelt aber das kann Ich nicht alles übernehmen.
Es darf nicht vorkommen das meine Keys durcheinanderfliegen.

So klappt das jedenfalls :

Delphi-Quellcode:

procedure  TObjSearchtree.SaveChildren( ANode : TTreeNode );
var
  LChild  : TTreeNode;
  pParent : TTreeNode;
  pKey    : String;
begin
  // Save the possible parents ID
  pKey := '0';
  pParent := ANode.Parent;
  if pParent <> NIL then
  begin
    pKey:= PNodeRec(pParent.Data)^.FPKey;
  end;

  while ANode.HasChildren do
  begin
    LChild := ANode.getFirstChild;
    PNodeRec(LChild.Data)^.FMother := pKey;
    LChild.MoveTo( ANode, naInsert );
  end;
  ANode.Delete;
end;

Zur Datenstruktur..
Es gibt einen Record den Ich halt per Pointer dran klemme. Janz einfach.
Ich brauche die Daten für den Shop und weil es viele, viele verschiedene Suchbäume geben kann
die geladen und gespeichert werden können müssen die eben, mit allen Daten dran, in der DB abgelegt werden.
Schaut so aus:

Delphi-Quellcode:

  AddObject(nil, pName, RecPtr).StateIndex := cFlatUnChecked; // root  
  AddObject(aNode, pName, RecPtr).StateIndex := cFlatUnChecked; // child

Und dann klemmt das dran..

Delphi-Quellcode:

  // Dataset for Searchtree entries
  type
    // Pointer to recordset
    PNodeRec = ^TNodeRec;
    TNodeRec = record
    // SAGE specific
    FMandant            : integer;
    FHauptartikelgruppe : string;
    FArtikelgruppe      : string;
    FVaterartikelgruppe : string;
    // Common
    FTreeNode   : TTreeNode;
    FName       : string;
    FTreeNo     : string;
    FPKey       : string;
    FMother     : string;
    FSortOrder  : integer;
    FLevel      : integer;
    FImage      : string;
    FCustGroups : string;
    FTimestamp  : integer;
    FChecked    : integer;
    FCategoriesTemplate : string;  // def = categorie_listing.html
    FListing_template   : string;  // def = product_listing_v1.html
    FProductsSorting    : string;  // def = p.products_price
    FProductsSorting2   : string;  // def = ASC
    FCategories_icon    : string;  // def = blank.png (transparent image)
    FCategoriesIcon_w   : integer; // def = size of blank image
    FCategoriesIcon_h   : integer; // def = size of blank image


  end;
  // array of Treenodes for sorting purpose
  TDyamicNodeArray = array of TNodeRec;

[Dejan Vu]

Da haben wir es wieder: View vs. Model

[macDoe]

Stimmt, da haben wir es wieder...

so einen Zeitgenossen dessen Posts weder hilfreich noch geistreich sind.
Aber die gibts ja überall.

[Uwe Raabe]

Was Dejan Vu in kurzen Worten uns hier mitteilt, ist ein Hinweis darauf, daß man zwischen Daten-Ansicht und Daten-Modell unterscheiden muss bzw. in diesem Fall die Konsistenz der beiden gewährleisten muss. Bei einem gut strukturierten View-Model-Ansatz geschieht das allerdings mehr oder weniger automatisch.

Insofern ist dieser Post sowohl geist- als auch hilfreich, wenn man z.B. die Begriffe in dieser Kombination mal an Google weiterreicht.

[Sir Rufo]

Es ist schon seltsam, da antwortet man in der gleichen Art wie gefragt wird (abstrakt) und dann wird sich auch noch beschwert.

Hier etwas Lesestoff zum einem TreeViewItemViewModel (ist nicht Delphi, aber anwendbar)
http://www.codeproject.com/Articles/...g-the-ViewMode

[Dejan Vu]

Zitat:

Zitat von macDoe (Beitrag 1282011)

Stimmt, da haben wir es wieder...

so einen Zeitgenossen dessen Posts weder hilfreich noch geistreich sind.
Aber die gibts ja überall.

Lese und lerne.