Comportamento de novo ou alterado com adaptadores de Editor
Se você estiver atualizando o código que foi escrito em relação a versões anteriores do editor do núcleo Visual Studio e você planeja usar o adaptadores de Editor (ou correções) em vez de usar a nova API, você deve estar ciente das seguintes diferenças no comportamento dos adaptadores de editor em relação ao editor de núcleo do anterior.
Recursos
Usando SetSite()
Você deve chamar SetSite quando você criar os buffers de texto, modos de exibição de texto e windows de código antes de executar as operações sobre eles. No entanto, isso não é necessário se você usar o IVsEditorAdaptersFactoryService criá-las, porque os métodos de Create () deste serviço se chamam SetSite.
IVsCodeWindow e IVsTextView de hospedagem no seu próprio conteúdo.
Você pode hospedar ambos IVsCodeWindow e IVsTextView em seu próprio conteúdo usando o modo Win32 ou o modo do WPF. No entanto, você deve ter em mente que existem algumas diferenças nos dois modos.
Win32 e o WPF em versões do IVsCodeWindow
A janela de código do editor é derivada de WindowPane, que implementa o Win32 antigos IVsWindowPane interface, bem como o WPF novo IVsUIElementPane interface. Você pode usar o Microsoft#VisualStudio#Shell#Interop#IVsWindowPane#CreatePaneWindow método para criar um ambiente de hospedagem baseada no HWND, ou o Microsoft#VisualStudio#Shell#Interop#IVsUIElementPane#CreateUIElementPane método para criar um ambiente de hospedagem do WPF. O editor subjacente sempre usa o WPF, mas você pode criar o tipo de painel de janela que atenda às suas necessidades de hospedagem, se você estiver incorporando esse painel de janela diretamente no seu próprio conteúdo.
Win32 e o WPF em versões do IVsTextView
Você pode definir um IVsTextView para o modo de Win32 ou WPF.
Quando uma fábrica de editor cria um modo de exibição de texto, por padrão, ele é hospedado em um HWND, e GetWindowHandle retorna um HWND. Você não deve usar esse modo para incorporar o editor dentro de um controle do WPF.
Para definir um modo de exibição de texto para o modo do WPF, você deve chamar Initialize e passar na VIF_NO_HWND_SUPPORT como uma da inicialização sinalizadores na InitView parâmetro. Você pode obter o FrameworkElement chamando CreateUIElementPane.
Modo do WPF é diferente do modo do Win32 de duas maneiras. Primeiro, o modo de exibição de texto pode ser hospedado em um contexto do WPF. Você pode acessar o painel do WPF, a projeção de IVsTextView para IVsUIElementPane e chamando GetUIObject. Segundo, GetWindowHandle ainda retorna um HWND, mas este HWND pode ser usado apenas para verificar sua posição e definir o foco. Você não deve usar este HWND para responder a uma mensagem WM_PAINT, porque ele não afeta como o editor pinta a janela. Este HWND está presente apenas para facilitar a transição para o novo editor de código por meio de adaptadores. É altamente recomendável que você não deve usar VIF_NO_HWND_SUPPORT se o componente exigir um HWND trabalhar, devido às limitações no HWND retornado de GetWindowHandle , enquanto nesse modo.
Passando arrays como parâmetros no código nativo
Há muitos métodos no editor de legado API com parâmetros que incluem uma matriz e sua contagem. Exemplos são:
Se você estiver chamando esses métodos em código nativo, você deve passar apenas um elemento por vez. Se você passar em mais de um elemento, a chamada será rejeitada, devido a problemas com a implementação de interoperabilidade primária.
O problema é mais complexo com métodos como SetIgnoreMarkerTypes. Toda vez que este método é chamado, ele limpa a lista anterior de tipos de marcador ignorados, portanto, não é possível simplesmente chamar esse método três vezes com três tipos diferentes de marcador. A única solução é chamar este método somente em código gerenciado.
Threading
Você sempre deve chamar o adaptador de buffer do thread da interface do usuário. O adaptador de buffer é um objeto gerenciado, o que significa que a chamada para ela partir do código gerenciado serão ignorados COM o empacotamento e sua chamada não serão automaticamente controlada no thread da interface do usuário. Se você está chamando o adaptador de buffer de um segmento de plano de fundo, você deve usar Invoke ou um método semelhante.
Métodos de LockBuffer
Todos os métodos de LockBuffer() são preteridos. Exemplos são:
Confirmar eventos
Confirmar eventos não são suportados. Chamar um método que aconselha para esses eventos faz com que o método para retornar um código de falha.
IVsPreliminaryTextChangeCommitEvents
IVsFinalTextChangeCommitEvents
IVsUndoRedoClusterWithCommitEvents
TextEditorEvents
O TextEditorEvents não são acionados em Commit (). Em vez disso, eles acionam em cada alteração de texto.
Marcadores de texto
Você deve chamar Invalidate na IVsTextMarker objetos quando você removê-los. Nas versões anteriores, você precisava somente os marcadores de versão.
Números de linha
Para uma variedade de métodos em IVsTextView e IVsTextViewEx, números de linha correspondem aos números de linha buffer subjacente, números de linha não que o fator em estruturas de tópicos e de quebra, como em Visual Studio de 2008.
Os métodos afetados incluem o seguinte (a lista não é exaustiva):
Estrutura de tópicos
Clientes do IVsHiddenTextSession verá apenas as regiões de estrutura de tópicos que foram adicionadas usando AddHiddenRegionsou AddHiddenRegionsEx. Eles não verão regiões ad-hoc, porque eles não são adicionados por meio do editor de adaptadores. Da mesma forma, esses clientes não verá a estrutura de tópicos adicionados pelos idiomas (incluindo C# e C++) que estão usando o novo código de editor, em vez dos adaptadores de editor de regiões.
Alturas de linha
No editor de novo, as linhas de texto podem ter de alturas diferentes, dependendo do tamanho da fonte e transformações de linha possíveis que podem mover a linha em relação a outras linhas. A altura da linha retornada pelos métodos como GetLineHeight é a altura de uma linha usando o tamanho da fonte padrão com nenhum transformações da linha aplicadas. Nesta altura pode, ou pode não refletir a altura real de uma linha no modo de exibição.
Eventos e desfazer
No editor de novo, o modo de exibição continua a executar operações como, por exemplo, processamento e geração de eventos continuamente, mesmo quando um cluster de desfazer está aberto. Esse comportamento é diferente das exibições herdadas, o que não realizaram essas operações até depois do fechamento do cluster desfazer.
IntelliSense
- O UpdateTipWindow método irá falhar se você passar em uma classe que implementa um IVsTextTipWindow2 ou IVsMethodTipWindow3. Popups personalizados desenhados pelo proprietário do Win32 não são mais suportados.
SmartTags
Não há suporte do adaptador de marcas inteligentes criados com, IVsSmartTagData, IVsSmartTagTipWindow, e IVsSmartTagTipWindow2 interfaces.
DTE
IncrementalSearchnão foi implementada.
Métodos não implementados
Alguns métodos não foram implementados no adaptador de buffer de texto, adaptador de exibição de texto e adaptador de camada de texto.
Interface |
Não implementado |
---|---|
Reload(false)não foi implementada. |
|
SetSubjectFromPrimaryBufferé implementado nos adaptadores mas ignorados pela interface de usuário estrutura de tópicos. |
|
GetBannerAttré implementado nos adaptadores mas ignorados pela interface de usuário estrutura de tópicos. |