Comportement nouveau ou modifié avec les adaptateurs d'éditeur
Si vous mettez à jour le code écrit par rapport à les versions antérieures de l'éditeur principal de Visual Studio, et que vous prévoyez d'utiliser les adaptateurs d'éditeur (ou des cales) au lieu d'utiliser la nouvelle API, vous devez connaître les différences suivantes dans le comportement des adaptateurs d'éditeur par rapport à l'éditeur principal précédent.
Fonctionnalités
À l'aide de SetSite()
Vous devez appeler SetSite lorsque vous les mémoires tampons de texte, des affichages de texte, des fenêtres de code de CoCreate avant d'exécuter toutes les autres opérations sur elles. Toutefois, cela n'est pas nécessaire si vous utilisez IVsEditorAdaptersFactoryService à créer, parce que les méthodes de Create() de ce service et appellent SetSite.
hébergement IVsCodeWindow et IVsTextView dans votre propre contenu
Vous pouvez héberger IVsCodeWindow et IVsTextView dans votre propre contenu en utilisant le mode Win32 ou le mode WPF. Toutefois, vous ne devez pas oublier qu'il existe quelques différences dans les deux modes.
À l'aide de Win32 et des versions WPF pour IVsCodeWindow
La fenêtre de code de l'éditeur est dérivée d' WindowPane, qui implémente l'interface ancienne Win32 IVsWindowPane ainsi que la nouvelle interface WPF IVsUIElementPane . Vous pouvez utiliser la méthode d' Microsoft#VisualStudio#Shell#Interop#IVsWindowPane#CreatePaneWindow pour créer un environnement d'hébergement basé sur HWND, ou la méthode d' Microsoft#VisualStudio#Shell#Interop#IVsUIElementPane#CreateUIElementPane pour créer un environnement d'hébergement WPF. L'éditeur sous-jacent utilise toujours WPF, mais vous pouvez créer le genre de volet de la fenêtre qui répond à vos besoins d'hébergement si vous incorporez ce volet de la fenêtre directement dans votre propre contenu.
À l'aide de Win32 et des versions WPF IVsTextView
Vous pouvez définir IVsTextView en mode Win32 ou en mode WPF.
Lorsqu'une fabrique d'éditeur crée un affichage de texte, la valeur par défaut est hébergée dans un HWND, et retourne d' GetWindowHandle un HWND. Vous ne devez pas utiliser ce mode pour incorporer l'éditeur à l'intérieur d'un contrôle WPF.
Pour définir un affichage de texte en mode WPF, vous devez appeler l' Initialize et passez VIF_NO_HWND_SUPPORT en tant que des balises d'initialisation dans le paramètre d' InitView . vous pouvez obtenir FrameworkElement en appelant CreateUIElementPane.
Le mode WPF diffère du mode Win32 de deux façons. Tout d'abord, l'affichage de texte peut être hébergé dans un contexte WPF. Vous pouvez accéder au volet WPF en effectuant le IVsTextView à IVsUIElementPane et en appelant GetUIObject. Ensuite, GetWindowHandle retourne toujours un HWND, mais celui-ci peut être utilisé pour activer uniquement sa position et le focus d'ensemble sur celui-ci. Vous ne devez pas utiliser ce HWND pour répondre à un message de WM_PAINT, car elle n'affecte pas comment l'éditeur peint la fenêtre. Celui-ci est présent pour faciliter uniquement la transition vers un nouveau code d'éditeur au moyen de les adaptateurs. Il est vivement recommandé de ne devez pas utiliser VIF_NO_HWND_SUPPORT si votre composant requiert un HWND de fonctionner, en raison de les limites du HWND retourné d' GetWindowHandle tandis que dans ce mode.
Passage de tableaux en tant que paramètres en code natif
Il existe de nombreuses méthodes dans l'API héritée d'éditeur qui ont des paramètres qui incluent un tableau et son nombre. les exemples sont :
Si vous appelez ces méthodes en code natif, vous devez passer dans un seul élément à la fois. Si vous passez plusieurs éléments, l'appel sera rejeté, en raison de les problèmes liés à l'implémentation d'interopérabilité primaire.
Le problème est plus complexe avec des méthodes telles que SetIgnoreMarkerTypes. Chaque fois que cette méthode est appelée, elle efface la liste précédente des types de marqueur ignorés, il n'est pas possible simplement à appeler cette méthode trois fois avec trois types de marqueur différents. Le seul remède consiste à appeler cette méthode uniquement dans le code managé.
Threads
Vous devez toujours appeler l'adaptateur de mémoire tampon du thread d'interface utilisateur. L'adaptateur de mémoire tampon est un objet managé, ce qui signifie que l'appeler à partir de le code managé sautera marshaling COM et votre appel ne sera pas automatiquement marshalé au thread d'interface utilisateur. si vous appelez l'adaptateur de mémoire tampon d'un thread d'arrière-plan, vous devez utiliser Invoke ou une méthode semblable.
méthodes de LockBuffer
Toutes les méthodes de LockBuffer() sont déconseillées. les exemples sont :
événements de validation
Les événements de validation ne sont pas pris en charge. Appeler une méthode qui recommandé pour ces événements fait pour retourner la méthode code d'échec.
IVsPreliminaryTextChangeCommitEvents
IVsFinalTextChangeCommitEvents
IVsUndoRedoClusterWithCommitEvents
TextEditorEvents
TextEditorEvents ne les déclenchent plus sur Commit(). À la place ils déclenchent à chaque modification de texte.
marqueurs de texte
Vous devez appeler Invalidate sur les objets d' IVsTextMarker lorsque vous les supprimer. Dans les versions antérieures, vous nécessaire récupérer seulement le.
Numéros de ligne
Pour diverses méthodes sur IVsTextView et IVsTextViewEx, les numéros de ligne correspondent aux numéros de ligne sous-jacents de mémoire tampon, et non les numéros de ligne qui mettent en œuvre en mode Plan et le retour automatique à la ligne, comme dans Visual Studio 2008.
Méthodes affectées incluent les éléments suivants (la liste n'est pas exhaustive) :
Mode Plan
Les clients d' IVsHiddenTextSession ne verront qu'ces régions en mode Plan qui ont été ajoutés à l'aide de l' AddHiddenRegionsou l' AddHiddenRegionsEx. Ils ne percevront pas les régions ad hoc, car ils ne sont pas ajoutés via les adaptateurs d'éditeur. De même, les clients ne percevront pas les régions en mode Plan ajoutées par les langages c# (y compris et C++) qui utilisent un nouveau code d'éditeur plutôt que les adaptateurs d'éditeur.
hauteurs de ligne
Dans le nouvel éditeur, les lignes de texte peuvent avoir des hauteurs, en fonction de la taille de police et les transformations possibles de ligne qui peuvent déplacer la ligne par rapport à d'autres lignes. La hauteur de ligne retournée par les méthodes telles que GetLineHeight est la hauteur d'une ligne à l'aide de la taille de police par défaut sans transformations de ligne appliquées. Cette hauteur peut ou ne pas refléter la hauteur réelle d'une ligne dans la vue.
Utilisation des et annulation
Dans le nouvel éditeur, la vue continue à exécuter des opérations telles que le rendu et de déclencher des événements de façon continue, même lorsqu'un cluster d'annulation est ouvert. Ce comportement est différent de celui des vues héritées, qui n'ont pas exécuté opérations après la fermeture du cluster d'annulation.
IntelliSense
- La méthode d' UpdateTipWindow échouera si vous passez une classe qui n'implémente pas IVsTextTipWindow2 ou IVsMethodTipWindow3. Les messages owner-drawn personnalisés Win32 ne sont plus pris en charge.
SmartTags
Il n'existe aucune prise en charge d'adaptateur des balises actives créées avec, d' IVsSmartTagData, d' IVsSmartTagTipWindow, et les interfaces d' IVsSmartTagTipWindow2 .
DTE
IncrementalSearch n'est pas implémenté.
Méthodes implémentées
Certaines méthodes n'ont pas été implémentées sur l'adaptateur de mémoire tampon de texte, l'adaptateur de vue de texte, et l'adaptateur de couche de texte.
Interface |
non implémenté |
|---|---|
Reload(false) n'est pas implémenté. |
|
l'SetSubjectFromPrimaryBuffer est implémenté dans les adaptateurs mais ignorée par l'interface utilisateur du mode plan. |
|
GetBannerAttr est implémenté dans les adaptateurs mais ignorée par l'interface utilisateur du mode plan. |