Frage

Was würde eine TreeView zu kollabieren, andere als einen Aufruf der .Collapse () -Methode auf einem TreeNode oder .CollapseAll () -Methode des TreeView?

In einer Anwendung, die ich entwickeln würde, werde die TreeView einfach nicht richtig verhalten. Das TreeView hält nur zwei Ebenen. Wenn ein Kind eines Elternknotens Auswahl, alle anderen Knoten sofort kollabieren. Allerdings gibt es keine .Collapse () oder .CollapseAll () -Methode ruft in meinem Code auch immer!

Alle Eigenschaften des TreeView sind die Standardwerte mit Ausnahme der .LabelEdit Eigenschaft links, die auf true gesetzt ist. Das TreeView hat einige Codes innerhalb des Ereignisses AfterLabelEdit zugeordnet für eine einfache Validierung / MessageBox Routine.

Ich habe versucht:

  • Anspannen des BeforeCollapse Fall die TreeView und die Erhöhung der e.CancelAction Flagge.

  • manuell erweitern alle Knoten innerhalb der TreeView der Afterselect Veranstaltung. (Dies funktioniert wie ein experimentieren, aber ich weiß nicht beabsichtigen, nicht zulassen Knoten Zusammenbruch
    insgesamt!)

An vielen Stellen im Code, ich bin Iterieren durch die TreeView, Knoten für Knoten, die Eigenschaften zu überprüfen. Es treten jedoch keine Ergänzungen oder Streichungen von Knoten. Die einzigen TreeNode Eigenschaften, die geändert werden, wenn die Benutzer Auswahlen machen sind .ImageIndex und .SelectedImageIndex.

Anders als die beiden oben genannten Lösungen, ich habe keine Ahnung, was kann diesen Fehler verursachen. Auch wenn keine Lösungen realisiert werden können, könnte jemand eine Idee über die richtige Art und Weise haben über Trapping den Zusammenbruch zu gehen? (Ich habe versucht, einen Haltepunkt in der BeforeCollapse Ereignis einstellen, aber es nicht ausgelöst, wenn der Benutzer explizit den Knoten über die Maus oder die Tastatur zusammenbricht.)


UPDATE:

Das Problem ist aufgrund chaging die .SelectedImageIndex Eigenschaft auf jedem TreeNode. Eine Änderung dieser Eigenschaft bewirkt, dass alle anderen Knoten kollabieren.

habe ich versucht, den .SelectedImageIndex modifizierende Code mit .BeginUpdate Umgebung () und .EndUpdate () ruft ohne Erfolg.

Wie kann das vermieden werden?

War es hilfreich?

Lösung

Dies ist ein Nebeneffekt der Art und Weise nativen Fenster in Windows arbeiten. Viele der Fenster-Optionen werden von Stil-Flags im CreateWindowEx () Aufruf angegeben. Grundlegende Dinge, wie das, was die Grenze sieht aus wie in einem Formular. Welche Ansicht sollte ein Listview haben. Ob ein TreeView sollte Kontrollkästchen angezeigt werden soll.

Diese Arten als Eigenschaften einer Kontrolle ausgesetzt. Aber es gibt ein Problem. Ändern einer solchen Eigenschaft erfordert das Fenster von Grund auf neu erstellt werden, so dass neue Stil-Flags in der CreateWindowEx () Aufruf angegeben werden. Das hat Nebenwirkungen, wird das Fenster komplett neu erstellt, so dass es alle vorherigen Zustand verliert.

Windows Forms hat einen ziemlich guten Job diese glatt aussehen zu lassen, die Wiederherstellung des vorherigen Zustands, nachdem das Fenster neu zu erstellen. Aber es gibt es hier und da Undichtigkeiten. Und ein paar geradezu Bugs. Ein Leck in TreeView ist der genaue Zustand von dem Knoten zusammengebrochen ist und welche nicht. Die Verfolgung dieser ist einfach nicht praktikabel.

Diagnostizieren dies durch die Handle-Eigenschaft des TreeView in einem Überwachungsfenster setzen. Wenn Sie es ändern sehen, haben Sie die Eigenschaft gefunden. Die Liste der Stil-Flags ist verfügbar hier, Sie können sich wahrscheinlich ihre Namen ihrer entsprechenden Eigenschaft zuzuordnen.

Vielleicht ist es klar, dass es keine große Abhilfe für dieses Problem ist, anders als die Vermeidung dieser Eigenschaft zu ändern. Probleme wie das ist, was gezeugt WPF.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top