Depois de lançar o aplicativo Bloco de Notas do Windows 11 para PCs, a Microsoft agora detalhou seus recursos RichEdit em uma postagem no blog. O aplicativo Bloco de Notas do Windows 11 recebeu vários aprimoramentos de edição RichEdit.
Você pode ler todos os detalhes abaixo.
Adições ao RichEdit
O bloco de notas clássico tem dois recursos úteis que não foram implementados no RichEdit: detecção de final de linha (CR, LF, CRLF) e o modo “Mostrar caracteres de controle Unicode” (discutido a seguir). Durante anos, o Bloco de Notas não quebrou as linhas de convenção do Unix que terminavam com um LF (U+000A) em vez de um CRLF (U+000D U+000A). Eu costumava abrir o Dados de caracteres Unicode arquivos, que contêm linhas terminadas em LF, com o WordPad e salve-os para converter os LFs em CRLFs para que o Bloco de Notas os exiba corretamente. Para corrigir esse problema, o Bloco de Notas foi ainda melhor: ele verificou qual final de linha vinha primeiro e, em seguida, tornou essa linha final o padrão para o arquivo. Assim, um arquivo com linhas terminadas em LF permanece terminado em LF e exibido corretamente. Internamente, o RichEdit segue a liderança do Word e do Mac em terminar parágrafos com um CR e converter LF e CRLF em CR ao ler em um arquivo ou armazenar texto por meio de uma API como WM_SETTEXT ou ITextRange2::SetText2. Este ainda é o caso, mas você pode dizer ao RichEdit para reconhecer o tipo de terminação de linha em um arquivo e usar essa opção para salvar/copiar o arquivo enviando o EM_SETENDOFLINE mensagem com wparam = EC_ENDOFLINE_DETECTFROMCONTENT.
Mostrar o modo de caracteres de controle Unicode e emoji
O bloco de notas tem a opção “Mostrar caracteres de controle Unicode” em seu menu de contexto há muitos anos. Este modo exibe caracteres de controle de largura zero Bidi usando glifos distintos de “largura zero”. Isso é muito valioso, por exemplo, para revelar os códigos Bidi RLO (U+202E) e LRO (U+202D) que substituem as direcionalidades usuais de caracteres e às vezes são usados para falsificar arquivos para fins nefastos. Ele também exibe o marceneiro de largura zero (ZWJ—U+200D) com uma linha vertical de “largura zero” encimada por um x. Mas dentro das sequências de emoji ZWJ, como emojis de família, o modo não separa a sequência nos ZWJs e não revela os ZWJs pelo glifo ZWJ de largura zero. E o Bloco de Notas clássico não exibe sequências ZWJ e emojis em geral em cores.
No novo modo “Mostrar caracteres de controle Unicode” do Bloco de Notas, as sequências ZWJ são divididas nos ZWJs e os ZWJs são exibidos pelo glifo de largura zero ZWJ. Você pode navegar dentro da sequência ZWJ usando as teclas ← e → e digitar Alt+x para ver os códigos dos caracteres que compõem a sequência ZWJ. Isso permite que você descubra como uma sequência ZWJ é construída. Por exemplo, o novo modo exibe a sequência de emoji da família ZWJ?❤️?dada pelos códigos U+1F468 ZWJ U+2764 U+FE0F ZWJ U+1F469 como
Caixa de diálogo Localizar/Substituir suspensa
O Visual Studio Code tem uma caixa de diálogo Localizar/Substituir bacana que cai no canto superior direito da área de texto. Caso a caixa de diálogo se sobreponha ao texto inicial, o usuário pode arrastar o texto para baixo logo abaixo da parte inferior da caixa de diálogo. O novo Bloco de Notas imita esse comportamento. Foi um pouco complicado fazer com que o RichEdit fornecesse a funcionalidade associada. Na formatação rich text, as propriedades espaço antes e espaço do parágrafo são usadas para adicionar espaçamento entre os parágrafos. Como o RichEdit é um editor de texto rico, ele suporta essas propriedades e era natural implementar o espaço suspenso como “espaço de documento antes”. O valor de espaço antes é incluído na subida da primeira linha do documento. Os truques vieram ao lidar com a exclusão ou substituição da primeira linha e a rolagem da exibição corretamente com um valor diferente de zero de espaço de documento antes.
Melhorias na interface do usuário de texto simples
Decidimos combinar a interface do usuário do Visual-Studio para selecionar e não selecionar o caractere EOP no final de uma linha. Isso difere da interface do usuário do Word, que tende a selecionar automaticamente o caractere EOP se você navegar ao lado dele. Especificamente, em controles de texto simples, não permitimos que o mouse estenda a seleção para incluir o EOP em uma linha ou deixe Shift+End selecionar o EOP. Isso corresponde ao que é excluído se você pressionar a tecla Delete após selecionar o texto. Você ainda pode selecionar o caractere EOP usando Shift+→ e estendendo a seleção para a próxima linha. Além disso, se a quebra de linha estiver desativada, o acento circunflexo do ponto de inserção agora segue qualquer espaço que você inserir em vez de ignorar os espaços.
Alguns detalhes de implementação
O Bloco de Notas do Windows 11 usa uma janela para sua tela de edição e as janelas geralmente usam GDI para exibir texto e imagens. GDI não possui funções para exibir fontes coloridas em cores, enquanto DirectWrite faz. Para poder usar o DirectWrite para emojis coloridos e outros aprimoramentos, o novo Bloco de Notas cria um RichEDitD2DPT janela, que usa DirectWrite para texto e GDI para objetos OLE (o Bloco de Notas não insere objetos OLE).
A compilação RichEdit usada no Bloco de Notas vem das mesmas fontes que o RichEdit carregado com aplicativos do Microsoft 365, como Word, PowerPoint, Excel e OneNote. Não é o Windows RichEdit em msftedit.dll. Conseqüentemente, o Bloco de Notas possui as melhorias mais recentes do RichEdit.
Corrigimos bugs que não apareciam para controles de texto simples do RichEdit ao longo dos anos, em parte porque antes do Bloco de Notas, as instâncias de texto simples eram pequenas.
O bloco de notas usa o clássico RichEdit encadernação de fonte em vez da associação de fonte IProvideFontInfo usada em controles de texto XAML e em controles RichEdit que aparecem em aplicativos do Microsoft 365. O bloco de notas não deseja carregar as bibliotecas mso usadas no último, pois essas bibliotecas são bastante grandes. A ligação de fonte clássica foi aprimorada, mas precisa adicionar suporte para mais scripts.
Melhoramos o desempenho do RichEdit para arquivos ASCII grandes, como os de dumps principais. Um recurso que pode retardar a leitura em um arquivo grande é detecção de URL automático. Durante a leitura em texto simples, LF e CRLF são traduzidos para CR para uso interno e no processo o texto é verificado para a combinação “:/”. Se essa combinação não for encontrada e somente AURL_ENABLEURL estiver habilitado, a detecção de autoURL será ignorada.