Direttiva x:Subclass

  • Articolo

Modifica il comportamento di compilazione del markup XAML quando x:Class viene fornito anche . Anziché creare una classe parziale basata su x:Class, l'oggetto fornito x:Class viene creato come classe intermedia e quindi si prevede che la classe derivata fornita sia basata su x:Class.

Uso della sintassi XAML per gli attributi

<object x:Class="namespace.classname" x:Subclass="subclassNamespace.subclassName">
   ...
</object>

Valori XAML

Valore Descrizione
namespace (Facoltativo). Specifica uno spazio dei nomi CLR che contiene classname. Se namespace viene specificato, un punto (.) separa namespace e classname.
classname Obbligatorio. Specifica il nome CLR della classe parziale che connette il codice XAML caricato e il code-behind per quel codice XAML. Vedere la sezione Osservazioni.
subclassNamespace (Facoltativo). Può essere diverso da namespace se ogni spazio dei nomi può risolvere l'altro. Specifica uno spazio dei nomi CLR che contiene subclassName. Se subclassName viene specificato, un punto (.) separa subclassNamespace e subclassName.
subclassName Obbligatorio. Specifica il nome CLR della sottoclasse.

Dipendenze

La direttiva x:Class deve essere fornita anche sullo stesso oggetto e tale oggetto deve essere l'elemento radice dell'ambiente di produzione XAML.

Osservazioni

x:Subclass l'utilizzo è destinato principalmente a linguaggi che non supportano dichiarazioni di classi parziali.

La classe usata come x:Subclass non può essere una classe annidata e x:Subclass deve fare riferimento all'oggetto radice come illustrato nella sezione "Dipendenze".

In caso contrario, il significato concettuale di x:Subclass non è definito da un'implementazione di servizi XAML .NET. Ciò è dovuto al fatto che il comportamento dei servizi XAML .NET non specifica il modello di programmazione complessivo in base al quale il markup XAML e il codice di backup sono connessi. Le implementazioni di altri concetti correlati a x:Class e x:Subclass vengono eseguite da framework specifici che usano modelli di programmazione o modelli di applicazione per definire come connettere markup XAML, markup compilato e code-behind basato su CLR. Ogni framework può avere azioni di compilazione specifiche che consentono alcuni dei comportamenti o componenti specifici che devono essere inclusi nell'ambiente di compilazione. All'interno di un framework, le azioni di compilazione possono variare anche in base al linguaggio CLR specifico usato per il code-behind.

Note sull'utilizzo di WPF

x:Subclass può trovarsi in una radice di pagina o nella Application radice nella definizione dell'applicazione, che ha x:Classgià . Dichiarando x:Subclass in qualsiasi elemento diverso da una pagina o da una radice dell'applicazione o specificandolo dove non x:Class esiste, viene generato un errore in fase di compilazione.

La creazione di classi derivate che funzionano correttamente per lo x:Subclass scenario è piuttosto complessa. Potrebbe essere necessario esaminare i file intermedi (i file con estensione g prodotti nella cartella obj del progetto tramite compilazione di markup, con nomi che incorporano i nomi dei file con estensione xaml). Questi file intermedi consentono di determinare l'origine di determinati costrutti di programmazione nelle classi parziali unite in join nell'applicazione compilata.

I gestori eventi nella classe derivata devono essere internal override (Friend Overrides in Microsoft Visual Basic) per eseguire l'override degli stub per i gestori creati nella classe intermedia durante la compilazione. In caso contrario, le implementazioni della classe derivata nascondono (shadow) l'implementazione della classe intermedia e i gestori della classe intermedia non vengono richiamati.

Quando si definiscono sia x:Class che x:Subclass, non è necessario fornire alcuna implementazione per la classe a cui fa x:Classriferimento . È sufficiente assegnare un nome tramite l'attributo x:Class in modo che il compilatore disponga di alcune linee guida per la classe creata nei file intermedi (in questo caso il compilatore non seleziona un nome predefinito). È possibile assegnare alla x:Class classe un'implementazione; tuttavia, questo non è lo scenario tipico per l'uso di sia x:Class che x:Subclass.

Vedi anche