ListCollectionView.CancelEdit() unterstützt kein "CancelEdit" ?

Jedenfalls habe ich diesen Eindruck. Die Dokumentation zu dieser Methode sagt:

Ends the edit transaction, and if possible, restores the original value to the item.

Und unter "Remarks":

CancelEdit sets CurrentEditItem to null and causes the collection view to exit the edit state. If CanCancelEdit is true, CancelEdit also restores the original values of the edited object.

Daraus würde ich schließen, dass die Methode auch dann das Editieren beendet, wenn CanCancelEdit falsch ist. Sie kann dann nur nichts für das Wiederherstellen des editierten Objekts tun, das muss man selbst implementieren.

Das Folgende müsste also m.E. funktionieren:

if (!MyListCollectionView.CanCancelEdit)
{
	MyUndoMethod(mycurrentitem);
}
MyListCollectionView.CancelEdit();

Ich habe auch schon so ein Beispiel in der Dokumentation gesehen, kann es nur nicht wiederfinden. Tatsächlich bekomme ich aber eine Exception:

Fehlermeldung:
System.InvalidOperationException wurde nicht behandelt.
HResult=-2146233079
Message=CancelEdit wird für das aktuelle Bearbeitungselement nicht unterstützt.

Bevor ich mich in den Kampf mit dem Microsoft-Bugtracker begebe, frage ich lieber mal nach, ob ich da doch was missverstanden habe. Und ob hier eher ein Dokumentations- oder ein Programmfehler vorliegt.

Ich meine mich auch zu erinnern, dass die Methode früher mal so funktioniert hat, wie ich mir das vorstellen würde. Bloß finde ich das Beispiel nicht wieder, an dem ich das durchgespielt hatte.

dein snippet ruft so oder so

MyListCollectionView.CancelEdit();

auf.
Dabei soll man das nicht aufrufen, wenn

.CanCancelEdit

false ergibt.

Aber das sagt dir doch auch die Fehlermeldung.

dein snippet ruft so oder so

MyListCollectionView.CancelEdit();  

auf.
Dabei soll man das nicht aufrufen, wenn

.CanCancelEdit  

false ergibt.

Aber das sagt dir doch auch die Fehlermeldung.

Mein Punkt ist doch, dass die Dokumentation das so eben nicht sagt, sondern mindestens nahelegt, dass die Methode sehr wohl aufgerufen werden kann, dass eben nur die Wiederherstellung der alten Werte dann separat vorgenommen werden muss.

Die "Remarks" sagen eben gerade nicht dasselbe wie Du oben und deshalb widersprechen sich Dokumentation und Fehlermeldung.

Laut Reflector wird diese Exception geworfen, wenn das EditableObject null ist:

public void CancelEdit()
{
    if (this.IsAddingNew)
    {
        throw new InvalidOperationException(SR.Get("MemberNotAllowedDuringTransaction", new object[] { "CancelEdit", "AddNew" }));
    }
    base.VerifyRefreshNotDeferred();
    if (this._editItem != null)
    {
        IEditableObject obj2 = this._editItem as IEditableObject;
        this._editItem = null;
        if (obj2 == null)
        {
            throw new InvalidOperationException(SR.Get("CancelEditNotSupported"));
        }
        obj2.CancelEdit();
    }
}

Laut Reflector wird diese Exception geworfen, wenn das EditableObject null ist:

Oder wenn es sich um kein IEditableObject handelt.

Mein Punkt ist doch, dass die Dokumentation das so eben nicht sagt, sondern mindestens nahelegt, dass die Methode sehr wohl aufgerufen werden kann, dass eben nur die Wiederherstellung der alten Werte dann separat vorgenommen werden muss. Jo, da scheint die Doku ausnahmsweise nicht ganz exakt zu sein.

Im Zweifelsfall richte dich aber lieber nach der Exception 😉

Im Ernst: Diese bool CanXY()-Methoden, das ist auch bischen ein Pattern. Das kenne ich zB auch von TypeConverter.CanConvert(), von Stream.CanSeek(), und fällt mir evtl. noch mehr ein: Wenn son CanXY()-Dingens false returnt, dann probiert man besser nicht trotzdem.

Jo, da scheint die Doku ausnahmsweise nicht ganz exakt zu sein.

Im Zweifelsfall richte dich aber lieber nach der Exception 😉

Da wird mir kaum etwas anderes übrigbleiben. Ein fauler Trick funktioniert:

if (!MyListCollectionView.CanCancelEdit)
{
    MyUndoMethod(mycurrentitem);
    MyListCollectionView.CommitEdit();     // Die Werte sind ja wieder die alten.
}
else
{
    MyListCollectionView.CancelEdit();
}

Aber besser ist es wohl doch, IEditableObject zu implementieren, notfalls mit einer leeren BeginEdit-Methode.

Bleibt die Frage, ob ich die ungenaue Dokumentation monieren werde.

Laut Reflector wird diese Exception geworfen, wenn das EditableObject null ist:
Oder wenn es sich um kein IEditableObject handelt.

Da habe ich mich wohl etwas ungünstig ausgedrückt - ich meinte schon den Cast auf IEditableObject (auf null wird ja schon vorher explizit abgefragt).