Compartilhar via

Diretiva x:Subclass

  • Artigo

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:Classx: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