L'éditeur exemple Java hérite d'une série de comportements par défaut de AbstractTextEditor. La structure d'édition gère plusieurs autres responsabilités personnalisables en remplaçant des méthodes dans AbstractTextEditor. Parcourez l'implémentation de cette classe et de ses sous-classes pour découvrir comment le comportement est personnalisé dans la structure.
Voici certaines fonctions utiles pouvant être configurées.
En général, les éditeurs de texte suivent les préférences utilisateur contrôlant la présentation et le comportement de l'éditeur. Dans la structure du texte, chaque instance d'éditeur possède un magasin de préférences permettant d'accéder aux préférences utilisateur. Ce magasin de préférences peut être configuré par l'éditeur ; vous pouvez également hériter des magasins déjà utilisés dans la structure.
Pour sa part, l'éditeur exemple Java hérite du magasin de préférences initialisé par TextEditor. Il s'agit du magasin défini par le plug-in d'éditeur du plan de travail.
protected void initializeEditor() { ... setPreferenceStore(EditorsPlugin.getDefault().getPreferenceStore()); }Les préférences de plug-in des éditeurs peuvent être modifiées dans les pages de préférences Général > Editeurs et Général > Editeurs > Editeurs de texte.
Si vous ne souhaitez pas utiliser les préférences de texte standard du plan de travail pour l'éditeur, il est possible de définir un magasin de préférences différent. Pour ce faire, remplacez initializeEditor et définissez votre propre magasin. Si vous utilisez un magasin personnalisé, vous devez également remplacer la méthode handlePreferenceStoreChanged() se lançant chaque fois qu'une préférence est mise à jour.
Les portées de liaisons de touches sont utiles pour définir un ordre de consultation pour les liaisons de touches. Le fait de disposer de liaisons de touches réduit les chances que risques que plusieurs plug-ins engendrent des conflits entre les séquences de touches. Par défaut, le plan de travail fonction dans une portée générique pour l'utilisation de fenêtres ou de boîtes de dialogue. Lorsqu'un éditeur de texte devient actif, il est chargé de la réinitialisation de la portée dans la portée de modification de texte afin que liaisons de touches spécifiques à l'éditeur soient actives.
Dans la structure de texte de la plate-forme, chaque instance de l'éditeur de texte possède un tableau associé de portées de liaisons de touches. Chaque instance est chargée de définir les portées correctes lorsqu'elle devient active. AbstractDecoratedTextEditor définit cette portée et se charge de la rendre active. La portée est affectée dans une méthode qui est appelée à partir du constructeur :
protected void initializeKeyBindingScopes() { setKeyBindingScopes(new String[] { "org.eclipse.ui.textEditorScope" }); }
L'argument de la méthode est un tableau d'ID qui ont été définis pour des contextes. Si vous souhaitez que l'éditeur définisse son propre contexte de liaisons de touches, vous pouvez remplacer cette méthode dans la classe de l'éditeur ou définir la portée de manière dynamique à l'aide de setKeybindingScopes.
Le contexte proprement dit doit être défini à l'aide de l'ID correspondant dans le point d'extension org.eclipse.ui.contexts. Voici la définition du contexte de modification du texte.
<extension point="org.eclipse.ui.contexts"> <context name="%context.editingText.name" description="%context.editingText.description" id="org.eclipse.ui.textEditorScope" parentId="org.eclipse.ui.contexts.window"> </context> ...
(Remarque : Nous utilisons les termes portée et contexte de manière interchangeable dans cette documentation. Les noms de méthode dans les classes de texte renvoient toujours aux contextes de liaisons de touches comme portées. Ces noms de méthode reflètent l'implémentation originale des contextes comme portées et utilisent l'ancienne terminologie.)