TreeNode.EndEdit gegen NodeLabelEditEventArgs.CancelEdit

Nun, auf der Oberfläche scheint der Aufruf von EndEdit(true) in der Tat dasselbe zu tun wie die Ausgabe von e.CancelEdit = true in einem AfterLabelEdit oder BeforeLabelEdit Event-Handler. Die beiden Ansätze sind jedoch nicht gleichwertig und werden nicht für den gleichen Zweck verwendet.

Am besten anhand eines Beispiels für das tatsächliche Verhalten demonstrieren:

Sie machen das gleiche, weil:

• Wenn Sie EndEdit(true) aufrufen, verlässt der Baumknoten den Bearbeitungsmodus und verwirft die Änderungen
• Wenn Sie e.CancelEdit = true während AfterLabelEdit ausstellen, verlässt der Baumknoten den Bearbeitungsmodus und verwirft Änderungen.

Aber sie sind nicht gleichwertig, weil:

• Wenn Sie nicht EndEdit(true) aufrufen, ändert sich der Bearbeitungsmodus für den Baumknoten nicht (offensichtlich),
• Wenn Sie e.CancelEdit = true während AfterLabelEdit nicht ausgeben, wird der Baumknoten immer noch den Bearbeitungsmodus verlassen (und Änderungen festschreiben),
• Wenn Sie e.CancelEdit = true während BeforeLabelEdit nicht ausgeben, wird der Baumknoten noch in den Bearbeitungsmodus versetzt.

Ein weiterer Unterschied ist, dass EndEdit() trigger AfterLabelEdit auslöst, aber AfterLabelEdit löst sich (glücklicherweise) nicht rekursiv aus.

Nun, normalerweise NodeLabelEditEventArgs. CancelEdit wird für die Validierung verwendet, dh um ungültige Änderungen an der Baumknotenbeschriftung zu verwerfen (während AfterLabelEdit ) oder um den Benutzer komplett daran zu hindern, die Beschriftungen einiger Knoten zu bearbeiten (während BeforeLabelEdit ). In beiden Fällen ist der Benutzer entweder bereits fertig oder hat noch nicht mit der Bearbeitung des Etiketts begonnen.

EndEdit () sollte verwendet werden erzwingen oder beenden Sie die Bearbeitung , während der Benutzer die Beschriftung noch bearbeitet . Das bedeutet natürlich, dass EndEdit(false) böse und falsch ist, da es eine möglicherweise vorzeitige Änderung festschreibt , bevor der Benutzer die Eingabe abgeschlossen hat und ohne seine Zustimmung. Also, ich habe es noch nie so genannt, eigentlich.

Das Aufrufen von EndEdit(true) zum Verwerfen der aktuellen Änderung kann nützlich sein, wenn etwas anderes unbedingt den Fokus gerade jetzt erfordert und Sie die unvollständige Bearbeitung nicht autocommit wann festlegen möchten Der Baumknoten verliert den Fokus. Die Arbeit des Benutzers auf diese Weise wegzuwerfen, ist jedoch immer noch unhöflich.

In den MFC-Tagen gab es eine legitime Verwendung für das EndEdit(true) -Äquivalent: Abbrechen der Bearbeitung, wenn der Benutzer die Taste ESC gedrückt hat. Ob Sie es glauben oder nicht, diese Funktion wurde zu diesem Zeitpunkt nicht standardmäßig in MFC unterstützt (und ist vielleicht auch heute nicht, habe ich nicht überprüft).

Aber heutzutage ist meiner Meinung nach nicht viel für EndEdit() übrig. Lass es besser in Frieden ruhen.