WPF Sentinel-Objekte und wie für einen internen Typen überprüfen

Question

Wie einige von euch entdeckt zu haben, um eine neue Funktion (?) Erschien WPF 4, wobei die Daten Bindungsmodul Ihre benutzerdefinierte Steuer Instanzen der Klasse passieren können MS.Internal.NamedObject mit dem Namen " {DisconnectedItem} “in das Datacontext - anstelle des Datenelements Code erwartet (dies geschieht, wenn ein Templat Kontrolle durch seine Items getrennt ist). Diese werden Sentinel-Objekte bezeichnet.

In vorhandenen Code, kann dies zu falschen Ausnahmen führen, wo der Code für sie nicht vorbereitet ist. Diese kann durch die Datenbindung Subsystem verschlungen werden, oder sie können Schaden anrichten. Halten Sie ein Auge auf Ihrer Debug-Konsole.

Wie auch immer, ich gelernt, über das auf dieses MSDN Forum . Und es gibt einen Beitrag von Sam Bent, die a href <= "http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/36aec363-9e33-45bd-81f0-1325a735cc45/#611fccf2-737f- 4309-a793-4001488b23aa“rel = "noreferrer"> erklärt alles . Gehen Sie lesen es jetzt, Sie das wissen wollen . Das Wesentliche ist, dass diese Ereignisse sollten nie gefeuert haben (das ist der Fehler), so:

  

Ignorieren Sie das Datacontextchanged Ereignis, wenn   die Datacontext ist ein Sentinel-Objekt.

So, so will ich meine Datacontext überprüfen. Aber wie? Bedenken Sie:

public bool IsSentinelObject(object dataContext)
{
    return (dataContext is MS.Internal.NamedObject);
}

erraten, was passiert? Es kompiliert nicht, weil MS.Internal.NamedObject intern ist, und mir nicht zugänglich. Natürlich kann ich es so hacken:

public bool IsSentinelObject(object dataContext)
{
    return dataContext.GetType().FullName == "MS.Internal.NamedObject"
           || dataContext.ToString() == "{DisconnectedObject}";
}

(oder etwas, das funktioniert). Ich habe folgte auch Sams Vorschlag das Objekt für den späteren Gebrauch auf Gleichheit prüft zwischenzuspeichern (es ist ein Singleton).

Natürlich bedeutet dies, ich habe kein Problem, nicht wirklich. Aber ich bin neugierig, und dieser Eintrag wird sicher sein, einige Nutzer profitieren, so lohnt es sich zu fragen sowieso:

Gibt es eine Möglichkeit ich genau die gegen den inneren NamedObject Typen überprüfen, ohne auf String-Vergleiche zurückgreifen?

Answer 1

Dieses?

var disconnectedItem = typeof(System.Windows.Data.BindingExpressionBase)
    .GetField("DisconnectedItem", BindingFlags.Static | BindingFlags.NonPublic)
    .GetValue(null);

Answer 2

In .NET 4.5 können Sie jetzt vergleichen gegen BindingOperations.DisconnectedSource .