Node aus Treeview löschen

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