x:Diretiva de subclasses

Artigo
12/18/2024

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 x:Class, o x:Class fornecido é criado como uma classe intermediária e, em seguida, espera-se que sua classe derivada fornecida seja baseada em x:Class.

Uso de atributos 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`	Necessário. Especifica o nome CLR da classe parcial que conecta o XAML carregado e seu code-behind para esse XAML. Ver 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`	Necessário. Especifica o nome CLR da subclasse.

Dependências

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

Comentários

x:Subclass uso destina-se principalmente a idiomas que não oferecem 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 não será definido por uma implementação dos Serviços XAML .NET. Isso ocorre porque o comportamento dos Serviços XAML .NET não especifica o modelo de programação geral pelo qual a marcação XAML e o código de suporte estão conectados. As implementações de outros conceitos 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 compilação que habilitam alguns dos comportamentos ou componentes específicos que devem ser incluídos no ambiente de compilação. Dentro de uma estrutura, as ações de compilação 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 de 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 existe x:Class, causa um erro em tempo de compilação.

Criar classes derivadas que funcionam corretamente para o cenário x:Subclass é 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 conforme 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 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 através do atributo x:Class 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 à classe x:Class uma implementação; no entanto, este não é o cenário típico para usar x:Class e x:Subclass.

Partilhar via