Compartilhar via

Diretiva x:Subclass

  • Artigo

Modifica o comportamento da compilação de marcação XAML quando x:Class também é fornecido. Em vez de criar uma classe parcial baseada em x:Class, a x:Class fornecida é criada como uma classe intermediária e, em seguida, espera-se que sua classe derivada fornecida seja baseada em 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 (.) separará namespace e classname.
classname Necessário. Especifica o nome CLR da classe parcial que conecta o XAML carregado e seu code-behind para esse XAML. Consulte Comentários.
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 (.) separará subclassNamespace e subclassName.
subclassName Necessário. Especifica o nome CLR da subclasse.

Dependências

diretiva x:Class também deve ser fornecido no mesmo objeto e esse objeto deve ser o elemento raiz da produção XAML.

Observações

x:Subclass uso destina-se principalmente a idiomas que não dão suporte a declarações de classe parciais.

A classe usada como 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 x:Subclass é indefinido por uma implementação dos Serviços XAML do .NET. 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. Implementações de conceitos adicionais relacionados a x:Class e x:Subclass 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 code-behind baseado em CLR. Cada estrutura pode ter suas próprias ações de build que habilitam alguns dos comportamentos ou componentes específicos que devem ser incluídos no ambiente de build. Em uma estrutura, as ações de build também podem variar com base na linguagem CLR específica que é usada para o code-behind.

Notas de uso do WPF

x:Subclass pode estar em uma raiz de página ou na raiz Application na definição do aplicativo, que já tem x:Class. Declarar x:Subclass em qualquer elemento diferente de uma página ou raiz do aplicativo ou especificá-lo onde não há x:Class, causa um erro em tempo de compilação.

A criação de classes derivadas que funcionam corretamente para o cenário de x:Subclass é bastante complexa. Talvez seja necessário examinar os arquivos intermediários (os arquivos .g produzidos na pasta obj do 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 determinados constructos 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, conforme criado 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 x:Class e x:Subclass, não é necessário fornecer nenhuma implementação para a classe referenciada por x:Class. Você só precisa dar um nome por meio do atributo x:Class para que o compilador tenha algumas diretrizes para a classe que ele cria nos arquivos intermediários (o compilador não seleciona um nome padrão nesse caso). Você pode dar uma implementação à classe x:Class; no entanto, esse não é o cenário típico para usar x:Class e x:Subclass.

Consulte também