Diretiva x:Subclass
Modifica o comportamento de compilação de marcação XAML quando x:Class
também é fornecido. Em vez de criar uma classe parcial baseada em , a fornecida é criada como uma classe intermediária e, em seguida, espera-se que sua classe derivada fornecida x:Class
seja baseada em .x:Class
x:Class
Uso do Atributo XAML
<object x:Class="namespace.classname" x:Subclass="subclassNamespace.subclassName">
...
</object>
Valores XAML
Valor | Descrição |
---|---|
namespace |
Opcional. Especifica um namespace CLR que contém classname . Se namespace for especificado, um ponto (.) separa namespace e classname . |
classname |
Obrigatório. Especifica o nome CLR da classe parcial que conecta o XAML carregado e seu code-behind para esse XAML. Consulte Observações. |
subclassNamespace |
Opcional. Pode ser diferente de namespace se cada namespace puder resolver o outro. Especifica um namespace CLR que contém subclassName . Se subclassName for especificado, um ponto (.) separa subclassNamespace e subclassName . |
subclassName |
Obrigatório. Especifica o nome CLR da subclasse. |
Dependências
x:Class Directive também deve ser fornecida no mesmo objeto, e esse objeto deve ser o elemento raiz da produção XAML.
Comentários
x:Subclass
O uso destina-se principalmente a idiomas que não oferecem suporte a declarações de classe parciais.
A classe usada como o x:Subclass
não pode ser uma classe aninhada e x:Subclass
deve se referir ao objeto raiz conforme explicado na seção "Dependências".
Caso contrário, o significado conceitual de será indefinido por uma implementação do x:Subclass
.NET XAML Services. Isso ocorre porque o comportamento dos Serviços XAML do .NET não especifica o modelo de programação geral pelo qual a marcação XAML e o código de backup estão conectados. As implementações de outros conceitos relacionados a x:Class
e são executadas por estruturas específicas que usam modelos de programação ou modelos de aplicativo para definir como conectar marcação XAML, marcação compilada e x:Subclass
code-behind baseado em CLR. Cada estrutura pode ter suas próprias ações de compilação que habilitam alguns dos comportamentos ou componentes específicos que devem ser incluídos no ambiente de compilação. Em uma estrutura, as ações de compilação também podem variar com base na linguagem CLR específica usada para o code-behind.
Notas de uso do WPF
x:Subclass
pode estar em uma raiz de página ou na raiz na Application definição do aplicativo, que já tem x:Class
. Declarar x:Subclass
em qualquer elemento que não seja uma página ou raiz de aplicativo, ou especificá-lo onde não x:Class
existe, causa um erro em tempo de compilação.
Criar classes derivadas que funcionam corretamente para o x:Subclass
cenário é bastante complexo. Talvez seja necessário examinar os arquivos intermediários (os arquivos .g produzidos na pasta obj do seu projeto por compilação de marcação, com nomes que incorporam os nomes de arquivo .xaml). Esses arquivos intermediários podem ajudá-lo a determinar a origem de certas construções de programação nas classes parciais unidas no aplicativo compilado.
Os manipuladores de eventos na classe derivada devem ser internal override
(Friend Overrides
no Microsoft Visual Basic) para substituir os stubs para os manipuladores como criados na classe intermediária durante a compilação. Caso contrário, as implementações de classe derivada ocultam (sombra) a implementação de classe intermediária e os manipuladores de classe intermediária não são invocados.
Quando você define ambos x:Class
e x:Subclass
, você não precisa fornecer nenhuma implementação para a classe que é referenciada por x:Class
. Você só precisa dar a ele um nome através do x:Class
atributo para que o compilador tenha alguma orientação para a classe que ele cria nos arquivos intermediários (o compilador não seleciona um nome padrão neste caso). Você pode dar à x:Class
classe uma implementação, no entanto, esse não é o cenário típico para usar ambos x:Class
e x:Subclass
.
Confira também
.NET Desktop feedback