Bill Coan
MVP Microsoft Word
Mai 2003
S'applique à :
Microsoft® Word 2000 et
versions ultérieures
Résumé : Bill Coan, qui a reçu
le titre de MVP (Most Valuable Professional) pour
Microsoft Word, donne ici des informations sur la façon
de modifier le fonctionnement de Word. Pour ce faire, les
procédures d'événements d'application sont les
outils les plus efficaces et les plus flexibles, mais il
existe aussi d'autres méthodes. Bill commence donc par
exposer les méthodes les plus faciles, pour passer
ensuite aux procédures d'événements
d'application.
Sommaire
Introduction
Remplacer les routines
intégrées
Tirer parti des macros
« automatiques »
Créer des procédures
d'« événements de
document »
Découvrir l'efficacité des
procédures d'« événements
d'application »
Testez votre gestionnaire
d'événements
Des noms plus courts pour votre gestionnaire
d'événements et vos objets d'application
Événements d'applications pris en
charge par Word 2002 et versions ultérieures
Quelques exemples utiles de procédures
d'événements d'application
À
propos de l'auteur
Introduction
La chose la plus judicieuse que n'ait jamais faite
l'équipe de développement de
Microsoft® Word, c'est de reconnaître et
d'admettre ses propres limites (nous devrions tous être
aussi humbles).
Plutôt que de se considérer comme un gang de
dictateurs du logiciel, infaillibles, omniprésents et
omnipotents, l'équipe a reconnu depuis le début que
les utilisateurs avancés et les développeurs
indépendants pouvaient avoir leurs propres idées
sur le comportement de Word. C'est pourquoi, à chaque
nouvelle version de Word, l'équipe a offert aux
utilisateurs avancés et aux développeurs
indépendants de nouveaux moyens de modifier le
comportement de Word.
Dans cet article, nous commencerons par revoir
brièvement quelques-unes des techniques les plus
anciennes et les plus faciles pour modifier le comportement
de Word. Nous passerons ensuite aux techniques les plus
récentes et les plus prometteuses pour prendre le
contrôle de votre application de traitement de texte
favorite.
Remplacer les routines
intégrées
Pour modifier le comportement de Word, il est possible de
créer des macros qui s'exécuteront à la place
des routines intégrées de Word. Par exemple, Word
possède une routine qui s'appelle FilePrint et
qui s'exécute lorsque l'utilisateur sélectionne
l'option Imprimer dans le menu Fichier. Si l'on
crée une macro appelée FilePrint, Word
l'exécute à la place de la routine
intégrée (pour consulter la liste des routines
intégrées pouvant être remplacées par des
macros éponymes, dans le menu Outils, pointez sur
Macro puis cliquez sur Macros. Dans la
boîte de dialogue Macros, choisissez dans la
liste Macros disponibles dans : l'option
Commandes Word).
Tirer parti des
macros « automatiques »
Il existe un autre moyen de modifier le comportement de
Word : créer des macros
« automatiques » qui s'exécutent
automatiquement lorsque l'utilisateur crée un nouveau
document (ou bien ouvre un document existant) à partir
d'un modèle donné. Il est également possible
de créer des macros automatiques qui s'exécutent
automatiquement lorsque Word charge ou décharge un
modèle global. Le tableau suivant énumère les
macros automatiques prises en charge par Word et indique le
moment où Word les exécute.
| Macro automatique | S'exécute lorsque... |
| AutoNew | S'exécute, si elle existe, lorsqu'un
utilisateur crée un nouveau document à partir
du modèle contenant la macro (remarque : techniquement, ceci est
une capacité héritée qui, bien qu'elle
soit encore prise en charge et le sera certainement
encore longtemps, a été supplantée par
l'événement Document_New dont nous
parlerons plus loin dans cet article). |
| AutoOpen | S'exécute, si elle existe, lorsqu'un
utilisateur ouvre un document existant basé sur le
modèle contenant la macro (remarque : ceci est une
capacité héritée qui, bien qu'elle soit
encore prise en charge et le sera certainement encore
longtemps, a été supplantée par
l'événement Document_Open dont nous
parlerons plus loin dans cet article). |
| AutoClose | S'exécute, si elle existe, lorsqu'un
utilisateur ferme un document existant basé sur le
modèle contenant la macro (remarque : ceci est une
capacité héritée qui, bien qu'elle soit
encore prise en charge et le sera certainement encore
longtemps, a été supplantée par
l'événement Document_Close dont nous
parlerons plus loin dans cet article). |
| AutoExec | S'exécute, si elle existe, lorsque le
modèle contenant la macro est chargé
globalement (remarque :
Normal.dot est chargé globalement au
démarrage de Word. Les modèles stockés
dans le dossier Démarrage de Word ou d'Office sont
également chargés globalement au
démarrage de Word. De plus, il est possible de
charger globalement un modèle en cliquant, dans le
menu Outils, sur Modèles et
compléments, puis en cliquant sur
Ajouter ou en sélectionnant un modèle
dans la liste Modèles globaux et
compléments). |
| AutoExit | S'exécute, si elle existe, lorsque le
modèle contenant la macro a été
chargé globalement puis est ensuite
déchargé (tous les modèles chargés
globalement sont déchargés à la
fermeture de Word. De plus, il est possible de
décharger un modèle chargé globalement
en cliquant, dans le menu Outils, sur
Modèles et compléments, puis en
désélectionnant la case qui lui correspond
dans la liste Modèles globaux et
compléments). |
Créer des
procédures d'« événements de
document »
À partir de Word 97, la distinction entre les
documents et les modèles Word a commencé à
s'estomper, lorsque l'on a donné aux documents la
capacité de stocker des projets de code VBA (Visual
Basic for Applications). Le point le plus important dans
ce changement, c'est que désormais les documents et les
modèles avaient la capacité de stocker des
procédures d'« événements de
document », c'est-à-dire des procédures
qui s'exécutent automatiquement lorsque se produit un
événement qui affecte un document donné. Le
tableau suivant répertorie les procédures
d'événements prises en charge par Word depuis
Word 97 et indique le moment où Word les
exécute.
| Procédure d'événements
de document | S'exécute lorsque... |
| Document_New | S'exécute, si elle existe, lorsqu'un
utilisateur crée un nouveau document à partir
du modèle contenant la procédure (elle ne
s'exécute PAS lorsque l'utilisateur crée un
nouveau document à partir d'un document existant.
Il est donc sans intérêt de stocker une
procédure Document_New dans le projet de
code VBA d'un document. Il est préférable de
toujours stocker la procédure dans le projet de
code VBA d'un modèle). |
| Document_Open | S'exécute, si elle existe, lorsqu'un
utilisateur ouvre un document contenant la
procédure ou bien un document rattaché au
modèle contenant la procédure (remarque : si un document contient
une procédure Document_Open et que le
modèle rattaché au document contient
également une procédure Document_Open,
Word exécutera chacune d'entre elles, l'une
après l'autre. La procédure du modèle
est exécutée en premier, immédiatement
suivie par la procédure stockée dans le
document). |
| Document_Close | S'exécute, si elle existe, lorsqu'un
utilisateur ferme un document contenant la
procédure ou bien un document rattaché au
modèle contenant la procédure (remarque : si un document contient
une procédure Document_Close et que le
modèle rattaché au document contient
également une procédure
Document_Close, Word exécutera chacune
d'entre elles, l'une après l'autre. La
procédure du modèle est exécutée en
premier, immédiatement suivie par la
procédure stockée dans le document). |
Remarque : Lorsqu'un
utilisateur crée un nouveau document, ouvre ou ferme
un document existant, Word vérifie tout d'abord si le
modèle rattaché au document contient une
procédure pour cet événement. Si c'est le
cas, Word l'exécute. Ensuite, Word vérifie si le
document lui-même contient une procédure
correspondant à cet événement. Si c'est le
cas, Word l'exécute (si le modèle et le document
contiennent tous deux une procédure correspondant
à cet événement, Word les exécute
toutes les deux, l'une après l'autre. Si ni le
document ni le modèle ne contiennent de
procédure, Word réalise l'action de l'utilisateur
sans exécuter de procédure).
Important : Les
procédures d'événements présentent un
avantage par rapport aux macros automatiques : les
procédures d'événements stockées dans
les modèles peuvent coexister avec des procédures
stockées dans les documents. C'est-à-dire que si
un document et le modèle qui lui est rattaché
contiennent tous deux une procédure pour un
événement de document donné, Word
exécutera les deux procédures, en commençant
par celle du modèle. Cela n'est pas vrai pour les
macros automatiques. Si un document contient une macro
AutoOpen et que le modèle qui lui est
rattaché contient également une macro
AutoOpen, Word n'exécutera que celle
stockée dans le document.
Comment stocker des procédures
d'événements de document dans un projet VBA
Aucune préparation particulière n'est
nécessaire pour stocker une procédure
d'événements de document dans un projet de code
VBA. Au contraire, chaque projet de code VBA, qu'il
appartienne à un modèle ou à un document,
contient par défaut un module spécial (appelé
ThisDocument) spécifiquement conçu pour
stocker des procédures d'événements de
document. Voici comment stocker une procédure
d'événements de document dans un module de ce
type :
- Lancez Word et ouvrez le document ou le modèle
dans lequel vous souhaitez stocker la procédure (si
vous choisissez de stocker la procédure dans un
modèle, vous pouvez, si vous le souhaitez, créer
ou ouvrir un document basé sur le modèle
plutôt que d'ouvrir le modèle
lui-même).
- Appuyez sur Alt+F11 pour lancer Visual Basic
Editor.
-
Dans le volet de l'Explorateur de projets (en haut
et à gauche de l'écran), localisez le projet
VBA de votre document ou modèle.
Remarque : Pour
chaque document ouvert dans Word, vous trouverez un
projet correspondant au document en question et un
projet correspondant au modèle qui lui est
rattaché. Assurez-vous de bien choisir le projet
dans lequel vous souhaitez stocker la procédure
d'événements.
- Si vous apercevez un signe plus (+) à
gauche du nom du projet, cliquez dessus pour
développer l'arborescence du projet. Vous constaterez
que le projet contient une branche pour les objets
Microsoft Word appelée Microsoft Word Objets.
Si vous apercevez un signe plus à la racine de cette
branche, cliquez dessus pour la développer. Cela
permet d'afficher le module ThisDocument du
projet.
- Double-cliquez sur le module ThisDocument du
projet pour afficher le contenu du module dans le volet
Code (à droite de l'écran).
-
Dans la partie supérieure du volet Code,
cliquez sur la liste déroulante
(Général) et sélectionnez
Document. Puis, dans la liste déroulante
New, cliquez sur Close, puis sur New
et enfin sur Open. Cela créera une
procédure vide pour les événements
Document_Close, Document_New et
Document_Open. Entrez le code de chaque
procédure que vous souhaitez exécuter lorsque
se produit cet événement. Vous pouvez par
exemple entrer la ligne suivante (en y plaçant le
nom de l'événement de votre choix) ; elle
affichera une boîte de dialogue vous indiquant
l'événement qui s'est produit :
Msgbox "The
<event name here>
has just occurred."
- Dans le menu Fichier, cliquez sur
Enregistrer, puis sur Fermer et retourner à
Microsoft Word.
Découvrir
l'efficacité des procédures
d'« événements
d'application »
Word 97 a introduit les procédures
d'événements de document, mais aussi les
procédures d'événements d'application, autre
outil très intéressant mis à la disposition
des développeurs et des utilisateurs avancés pour
modifier le comportement de Word.
Comme les procédures d'événements de
document, les procédures d'événements
d'application s'exécutent automatiquement lorsque se
produit un événement donné. Jusque là,
les procédures d'événements d'application sont
aussi faciles à comprendre que les procédures
d'événements de document.
Mais lorsque l'on se penche davantage sur les
procédures d'événements d'application, on
découvre qu'elles ont des avantages mais aussi un petit
inconvénient. Leur avantage, c'est qu'elles offrent plus
de puissance et de flexibilité que les procédures
d'événements de document. Leur inconvénient,
c'est qu'elles demandent quelques préparatifs avant que
le projet de code VBA ne puisse en tirer parti. Mais en fin
de compte, elles sont un atout certain : les
opérations préalables nécessaires sont
négligeables par rapport aux gains d'efficacité et
de flexibilité réalisés.
Remarque : À
l'époque de Word 97, Word ne prenait en charge
que deux événements d'application. Il n'y avait
donc pas grand chose à perdre à ne pas les
utiliser. À chaque nouvelle version de Word
éditée depuis lors, le nombre
d'événements d'application pris en charge a
augmenté avec régularité. Par exemple,
Word 2002 SP-2 en prend 23 en charge. Il semble
logique de penser que Word 2003 fera encore mieux.
Donc si vous n'avez jamais utilisé les procédures
d'événements d'application jusqu'à
présent, c'est le moment idéal de vous y
intéresser.
Avant d'analyser les procédures
d'événements d'application en détail, revenons
un peu en arrière et essayons de répondre à
une question inhérente à notre présentation
sur les procédures d'événements de
document : « Pourquoi n'y a-t-il besoin
d'aucune préparation spéciale pour stocker une
procédure d'événements de document dans un
projet de code VBA ? »
Cela s'explique tout d'abord par le fait que Word sait
déjà où se trouvent les procédures
d'événements de document (si elles existent). Comme
nous le remarquions précédemment, ces
procédures se trouvent dans le module
ThisDocument du projet de code VBA du document ou du
modèle qui lui est rattaché.
Ensuite, chaque fois qu'un utilisateur crée un
nouveau document, ouvre ou ferme un document existant, Word
vérifie systématiquement s'il existe une
procédure d'événements correspondante. Inutile
donc de demander à Word le faire.
Apparemment, l'équipe de développement de Word a
estimé que les utilisateurs ne remarqueraient pas ou ne
seraient pas gênés par la très
légère temporisation causée par cette
vérification systématique de la présence de
procédures d'événements de document. Cela se
comprend, puisque cette temporisation est négligeable
par rapport au temps nécessaire pour accéder au
disque ou au réseau à chaque création,
ouverture ou fermeture de document.
Rien de tout ceci n'est applicable aux procédures
d'événements d'application. Tout d'abord, ces
procédures n'ont pas d'emplacement défini par
défaut, donc Word ne sait pas où aller les chercher
si vous ne le lui indiquez pas.
De plus, les événements d'application sont
très fréquents et se produisent alors que les
utilisateurs sont habitués à des réponses
très rapides. Il n'est donc pas intéressant que
Word recherche la présence de procédures
d'événements chaque fois que se produit un
événement, à moins qu'il y ait des raisons de
croire que ces procédures existent effectivement. Pour
résoudre ce problème, Word ne vérifie la
présence de procédures d'événements
d'application que lorsque vous le lui demandez.
Comment indiquer à Word l'endroit où vous avez
stocké vos procédures d'événements
d'application et lui demander de vérifier si elles
existent lorsque se produit un événement
d'application ? La réponse est assez simple en
théorie et presque autant en pratique. Voilà, selon
la théorie, tout ce qu'il vous faudra faire :
- Créer un module de classe « gestionnaire
d'événement » contenant les
procédures d'événements.
Remarque : Un module de classe décrit une
catégorie ou une « classe »
d'objets. Votre module de classe décrira une classe
d'objets appelés gestionnaires d'événements.
Vous créerez ensuite un objet appartenant à cette
classe (d'un point de vue technique, vous pourriez
créer deux ou trois objets de ce type, voire
davantage, mais vous n'en aurez certainement besoin que
d'un seul). La seule fonction d'un module de classe, c'est
d'indiquer à quoi ressemblera chaque membre de la
classe. C'est presque comme si vous créiez un
« moule » pour les gestionnaires
d'événements, de façon à pouvoir
créer ultérieurement autant de gestionnaires
d'événements que vous le souhaitez.
- Créer un objet gestionnaire d'événement
à partir de la description de votre module de classe
de gestionnaires d'événements.
Remarque : On dit
parfois des objets qu'ils sont les membres ou les
« instances » de la classe. Vous
pouvez, si vous le souhaitez, créer plusieurs
instances d'une classe. Chacune sera conforme à la
description contenue dans le module de classe pour cette
classe.
Si tout ceci vous semble énigmatique, ne vous
inquiétez pas. C'est sans doute simplement parce que la
terminologie est nouvelle pour vous. Dans les paragraphes qui
suivent, nous mettrons cette théorie en pratique et nous
nous arrêterons en chemin pour expliquer ce qui se
passe.
Important : Certains
des noms utilisés ci-dessous sont ridiculement longs,
mais j'espère qu'ils vous aideront à visualiser
comment sont gérés les événements
d'application. Je vous suggérerai plus tard des noms
plus courts, mais pour l'instant, essayez d'ignorer cet
inconvénient et d'accepter les noms
suggérés.
Comment stocker des procédures
d'événements d'application dans un projet VBA
Les procédures d'événements d'application
peuvent être stockées dans le projet de code VBA
d'un document, d'un modèle normal ou ou d'un modèle
global. Mais le plus courant est de les stocker dans un
modèle global car les événements d'application
sont eux-mêmes globaux, c'est-à-dire qu'ils
affectent tous les documents. Par conséquent, dans les
étapes qui suivent, nous supposerons que vous souhaitez
stocker vos procédures d'événements
d'application dans un modèle de complément
appelé EventHandlerAddin.dot.
Voici comment faire :
- Démarrez Word, créez un nouveau modèle
et enregistrez-le immédiatement sous le nom
EventHandlerAddin.dot. - Appuyez sur Alt+F11 pour lancer Visual Basic
Editor.
- Dans le volet de l'Explorateur de projets (en haut et
à gauche de l'écran), localisez le projet VBA de
EventHandlerAddin.dot.
Remarque : Pour
chaque document ouvert dans Word, vous trouverez un projet
correspondant au document en question et un projet
correspondant au modèle qui lui est rattaché.
Veillez à bien choisir le projet de
EventHandlerAddind.dot.
- Cliquez avec le bouton droit de la souris sur le
projet, sélectionnez le menu Insertion, puis
cliquez sur Module de classe. Dans le volet
Propriétés (en bas et à gauche de
l'écran), cliquez sur le champ Nom et donnez au
module de classe le nom
clsEventHandler. -
Dans le volet Code (à droite de l'écran),
entrez les informations suivantes :
...
'Declare that only an instance of Word can be assigned to this variable
'and also that the assigned instance should be notified to
'check inside the event handler for application event procedures.
Public WithEvents _
AppThatLooksInsideThisEventHandler _
As Word.Application
...
- Dans la partie supérieure du volet Code,
cliquez sur la liste déroulante Object et
sélectionnez
AppThatLooksInsideThisEventHandler. Dans la liste
déroulante Procédure, cliquez sur
DocumentBeforeClose, puis sur
DocumentBeforePrint et enfin sur
DocumentBeforeSave. Cela créera une
procédure vide pour chacun de ces
événements. Nous explorerons d'autres
événements plus tard.
-
Entrez le code que vous souhaitez exécuter lorsque
se produit cet événement dans chacune de ces
procédures. Dans cet exemple, entrons une boîte
de message simple qui affichera le nom de
l'événement d'application associé au
moment de l'exécution de la procédure. Par
exemple, le premier groupe d'instructions ci-dessous
s'applique à la procédure
d'événements DocumentBeforeClose, le
deuxième à la procédure
d'événements DocumentBeforePrint et le
troisième à DocumentBeforeSave :
Private Sub AppThatLooksInsideThisEventHandler_DocumentBeforeClose(ByVal Doc As Document, Cancel As Boolean)
MsgBox "Event: DocumentBeforeClose"
End Sub
Private Sub AppThatLooksInsideThisEventHandler_DocumentBeforePrint(ByVal Doc As Document, Cancel As Boolean)
MsgBox "Event: DocumentBeforePrint"
End Sub
Private Sub AppThatLooksInsideThisEventHandler_DocumentBeforeSave(ByVal Doc As Document, SaveAsUI As Boolean, Cancel As Boolean)
MsgBox "Event: DocumentBeforeSave"
End Sub
-
Dans le menu Fichier, cliquez sur
Enregistrer.
Marquons une pause pour revoir ce que nous avons
accompli jusqu'à présent.
Nous avons créé un module de classe
appelé clsEventHandler qui
décrit une classe d'objets gestionnaires
d'événements mais ne permet pas de créer
(ou d'instancier) cet objet. Les objets gestionnaires
d'événements seront créés
ultérieurement. Tout ce qui existe dans le module de
classe, c'est une description de ce à quoi
ressemblera chaque gestionnaire
d'événements.
Lorsqu'il est créé, un objet gestionnaire
d'événements comprend un objet d'application
Word avec des événements ainsi que des
procédures pour les événements
d'application suivants : DocumentBeforeClose,
DocumentBeforePrint et
DocumentBeforeSave.
Remarque : Dans
ce contexte, un « objet d'application
Word » est une structure de données en
mémoire reflétant toutes les
propriétés et les méthodes de
l'application Word ; « avec
événements » signifie que
l'instance de Word impliquée recevra l'instruction
de vérifier l'existence de procédures
d'événements au sein de l'objet gestionnaire
d'événements chaque fois que se produira un
événement d'application.
Pour résumer : jusqu'à présent,
nous avons uniquement défini l'objet gestionnaire
d'événements. Mais nous n'avons pas encore
créé d'objet. Nous y sommes presque,
venons-y :
- Cliquez avec le bouton droit de la souris sur le projet
de code, sélectionnez le menu Insertion, puis
cliquez sur Module. Dans le volet
Propriétés (en bas à gauche de
l'écran), cliquez dans le champ Nom et entrez
modHandleEvents.
-
Dans le volet Code (à droite de l'écran),
entrez les informations suivantes :
...
' declare type of object to be stored in the objEventHandler variable
Dim objEventHandler As clsEventHandler
Sub CreateEventHandler()
'create a new event handler object and assign it to objEventHandler
Set objEventHandler = New clsEventHandler
'Notify the current instance of Word to check for
'application event procedures
'inside the event handler object
Set objEventHandler.AppThatLooksInsideThisEventHandler = Word.Application
End Sub
Sub DestroyEventHandler()
'release the memory being used by the event handler object
Set objEventHandler = Nothing
End Sub
Sub AutoExec()
'whenever this template is loaded globally,
'automatically create an event handler
CreateEventHandler
End Sub
Sub AutoExit()
'whenever this template is unloaded,
'automatically destroy the event handler
DestroyEventHandler
End Sub
- Dans le menu Fichier, cliquez sur
Enregistrer, puis sur Fermer et retourner à
Microsoft Word.
- Fermez Word.
Marquons une nouvelle pause pour revoir ce que nous avons
réalisé.
Nous avons créé un module de code appelé
modHandleEvents et à
l'intérieur, nous avons déclaré que nous
travaillerions avec une variable appelée
objEventHandler de type clsEventHandler. Cette déclaration ne
crée pas d'objet, elle définit son type.
C'est-à-dire qu'elle indique à l'ordinateur le type
d'objet auquel la variable fait référence de
façon que le compilateur (et la fonction
IntelliSense® de Microsoft) nous aident à utiliser
la variable en accord avec la description de l'objet
stockée dans clsEventHandler.
Nous avons créé une sous-routine appelée
CreateEventHandler. Cette
sous-routine crée une nouvelle instance de la classe
appelée clsEventHandler et
l'affecte à objEventHandler . De plus,
cette sous-routine affecte l'instance de Word en cours à
la propriété AppThatLooksInsideThisEventHandler de
objEventHandler .
Nous avons créé également une sous-routine
appelée DestroyEventHandler.
Cette sous-routine détruit notre gestionnaire
d'événements en libérant la mémoire
allouée à objEventHandler .
Enfin, nous avons créé une macro AutoExec
qui s'exécutera automatiquement lorsque ce modèle
sera chargé globalement, ainsi qu'une macro
AutoExit qui s'exécutera automatiquement lorsque
ce modèle sera déchargé. La macro
AutoExec crée automatiquement un gestionnaire
d'événement. La macro AutoExit détruit
automatiquement un gestionnaire d'événement.
Notre gestionnaire d'événements existe
enfin ! Ou disons plutôt qu'il existera dès
que Word chargera notre modèle globalement et
exécutera la sous-routine CreateEventHandler.
Un autre événement se produira lorsque Word
exécutera la sous-routine CreateEventHandler : l'instance de
Word en cours sera affectée à la
propriété AppThatLooksInsideThisEventHandler de notre
gestionnaire d'événement. Par conséquent, Word
recevra l'instruction de vérifier l'existence de
procédures d'événements dans le gestionnaire
d'événements chaque fois que se produira un
événement d'application.
Pour certains événements
(DocumentBeforeClose, DocumentBeforePrint et
DocumentBeforeSave), Word trouvera une procédure
d'événements associée et l'exécutera.
Pour les autres, Word ne trouvera aucune procédure
d'événements associée et procèdera à
ses actions habituelles sans exécuter de
procédure.
Testez votre gestionnaire
d'événements
Le test de votre gestionnaire d'événements ne
vous demandera que quelques secondes. Pour le voir en action,
procédez ainsi :
- Démarrez Word.
- Dans le menu Outils, cliquez sur Modèles
et compléments, sur Ajouter, sur
EventHandlerAddin.dot, puis sur OK. Word
chargera ainsi le modèle de complément
globalement, exécutera donc la macro AutoExec
du complément, ce qui créera un objet
gestionnaire d'événements en mémoire (c'est
une longue chaîne d'événements, n'est-ce
pas ?, mais maintenant que vous la comprenez, elle
devrait vous sembler moins étrange et moins
intimidante).
- Essayez d'enregistrer, d'imprimer et de fermer des
documents. À chacune de ces actions, un message
apparaîtra, indiquant qu'un événement
d'application s'est produit et que Word a répondu en
exécutant l'une de vos procédures
d'événements d'application.
- Dans le menu Outils, cliquez sur Modèles
et compléments, désélectionnez la case
EventHandlerAddin.dot, puis cliquez sur OK.
Word déchargera le modèle de complément,
exécutera donc la macro AutoExit du
complément, ce qui détruira un objet gestionnaire
d'événements (autre chaîne
d'événements, familière maintenant).
- Essayez d'enregistrer, d'imprimer et de fermer des
documents. Désormais, aucun message n'apparaît
parce que Word ne vérifie pas la présence de
procédures d'événements d'application et,
quoi qu'il en soit, vos procédures
d'événements d'application ne sont plus en
mémoire.
Des noms plus courts pour votre gestionnaire
d'événements et vos objets d'application
Dans cet article, je vous ai suggéré de
créer un module de classe appelé clsEventHandler et de déclarer dans ce
module de classe une variable objet d'application Word
appelée AppThatLooksInsideThisEventHandler.
Je vous ai proposé ces noms pour vous aider à
visualiser ce qui se produit lorsque l'on crée un objet
gestionnaire d'événements et qu'on lui assigne une
instance de Word. Je suis toutefois le premier à
admettre que la clarté d'un nom dépend de celui qui
l'a créé.
Pour mes propres projets, je me contente parfaitement d'un
module de classe appelé clsEventHandler. Dans certains cas,
j'utilise clsAppEventHandler, pour
m'aider à me rappeler que mon gestionnaire
d'événements est conçu pour gérer
exclusivement les événements d'application. J'omets
parfois le préfixe cls et
j'appelle simplement le module de classe AppEventHandler.
Pour ce qui est de la variable objet d'application Word
dans le module de classe, mon nom favori est
EventSource . Ce nom fonctionne très bien
avec la fonction IntelliSense de VBA parce que plus tard,
dans le module de code normal dans lequel je crée un
objet gestionnaire d'événements (modHandleEvents), j'entre simplement un
point et la liste déroulante IntelliSense m'aide à
choisir une propriété EventSource pour le
gestionnaire d'événements. Voici le code qui en
résulte :
Dim objEventHandler As clsEventHandler
Sub CreateEventHandler()
Set objEventHandler = New clsEventHandler
Set objEventHandler.EventSource = Word.Application
End Sub
Lorsque vous continuerez à expérimenter les
procédures d'événements d'application, vous
souhaiterez probablement faire vos propres essais
jusqu'à ce que vous trouviez des noms qui vous
conviendront et qui vous aideront à visualiser le
déroulement des opérations.
Événements
d'application pris en charge par Word 2002 et versions
ultérieures
Comme nous l'avons souligné précédemment,
chaque nouvelle version de Word prend en charge davantage
d'événements d'application que la version
précédente. La liste ci-dessous correspond à
Microsoft Office 2002 avec
Service Pack 2. Pour connaître les
événements d'application que prend en charge votre
version de Word, consultez les événements
d'application dans l'Aide VBA.
| Procédure d'événements
d'application | S'exécute... |
| DocumentBeforeClose | Immédiatement avant la fermeture d'un
document. |
| DocumentBeforePrint | Avant l'impression d'un document ouvert. |
| DocumentBeforeSave | Avant l'enregistrement d'un document ouvert. |
| DocumentChange | Lorsqu'un nouveau document est créé,
lorsqu'un document existant est ouvert ou lorsqu'un
autre document devient le document actif. |
| DocumentOpen | Lorsqu'un document est ouvert. |
| EPostageInsert | Lorsqu'un utilisateur insère un
affranchissement électronique dans un
document. |
| EPostagePropertyDialog | Lorsqu'un utilisateur clique sur le bouton
Propriétés de l'affranchissement
électronique... (boîte de dialogue
Étiquettes et enveloppes) ou sur un bouton
de la barre d'outils Imprimer l'affranchissement
électronique. Cet événement permet
aux logiciels tiers d'intercepter et d'afficher leur
boîte de dialogue Propriétés. |
| MailMergeAfterMerge | Après que tous les enregistrements d'un
publipostage ont correctement fusionné. |
| MailMergeAfterRecordMerge | Après que chaque enregistrement de la source
de données a été correctement
fusionné dans un publipostage. |
| MailMergeBeforeMerge | Lorsqu'une fusion est exécutée avant la
fusion des enregistrements. |
| MailMergeBeforeRecordMerge | Lorsqu'une fusion est exécutée pour
chaque enregistrement d'une fusion. |
| MailMergeDataSourceLoad | Lorsqu'une source de données est chargée
pour un publipostage. |
| MailMergeDataSourceValidate | Lorsqu'un utilisateur vérifie les adresses en
cliquant sur Valider dans la boîte de
dialogue Destinataires du publipostage. |
| MailMergeWizardSendToCustom | Lorsque l'utilisateur clique sur le bouton
personnalisé à l'étape 6 de
l'Assistant Fusion et publipostage. |
| MailMergeWizardStateChange | Lorsque l'utilisateur passe d'une étape
spécifiée à une autre dans l'Assistant
Fusion et publipostage. |
| NewDocument | Lorsqu'un nouveau document est créé. |
| Quit | Lorsque l'utilisateur quitte Word. |
| WindowActivate | Lorsqu'une fenêtre de document est
activée. |
| WindowBeforeDoubleClick | Lorsque l'utilisateur double-clique dans la zone de
modification d'une fenêtre de document, avant
l'action induite par défaut par un double
clic. |
| WindowBeforeRightClick | Lorsque l'utilisateur clique avec le bouton droit
de la souris dans la zone de modification d'une
fenêtre de document, avant l'action induite par
défaut par un clic du bouton droit. |
| WindowDeactivate | Lorsqu'une fenêtre de document est
désactivée. |
| WindowSelectionChange | Lorsque la sélection change dans la
fenêtre de document active. |
| WindowSize | Lorsque la fenêtre de document est
redimensionnée ou déplacée. |
Quelques
exemples utiles de procédures d'événements
d'application
Le code présenté dans cet article n'a pas
d'autre utilité que d'apprendre comment définir des
procédures d'événements d'application dans
Word. Vous trouverez ci-dessous des liens vers des exemples
de procédures d'événements d'application plus
intéressants et plus utiles, créés par mes
soins et par mes collègues MVP :
How can I prevent users from editing the header of a
document in Word 2000 or higher? (
.gif)
.gif)
)
Writing application event procedures (
)
How to create global event procedures similar to AutoOpen,
AutoNew and AutoClose, without using Normal.dot (
)
Running a macro automatically when Word starts or
quits (
)
Intercepting events like Save and Print (
)
À propos de l'auteur
Bill Coan aide les entreprises à créer des
documents de meilleure qualité en moins de temps à
l'aide des modèles, des assistants, des compléments
et des macros Word. Il a également développé
les compléments DataPrompter et Boilerplate pour Word.
Vous pouvez visiter son site Web ou lui écrire à
l'adresse suivante : billcoan@wordsite.com.
Dernière
mise à jour le mercredi 16 juillet 2003
Pour en savoir plus