Plantage étrange à la fermeture doc basé sur un dot
9 réponses
natric
[Posted to microsoft.public.fr.word, copy sent to author]
Bonjour à tous,
J'ai un problème de plantage à la fermeture d'un document (essai.doc)
attaché à un modèle (base.dot). Pour vous expliquer ça, j'ai créer deux
fichiers minimum qui reproduisent le problème. En voici une description
:
- essai.doc est un document vide, simplement attaché à base.dot.
- base.dot contient juste une liste déroulante vide ds le document même
et un peu de code :
.dans ThisDocument :
Private Sub Document_Open()
DocOpenHelper
End Sub
Private Sub Document_Close()
'n'importe quel contenu
End Sub
.dans un module nommé Module1:
Function DocOpenHelper()
If ActiveDocument.Name = "base.dot" Then
MsgBox "Pas un doc"
End If
End Function
Voilà, avec ça, quand j'ouvre, puis ferme base.dot, tout est ok. Mais si
j'ouvre essai.doc, puis tente de le fermer, j'obtiens immédiatement et
de manière constante un crash de winword.exe (Word 97 SR2 sous Win2K Pro
FR SP4) avec l'erreur "L'instruction à '0x651ff21a' emploie l'adresse
mémoire '0x0000002c'. La mémoire ne peut pas être 'read'.
Si je supprime au moins un des private sub de ThisDocument OU supprime
la seule fonction de Module1 OU retire la liste déroulante de
l'interface, par magie, ça ne plante plus du tout.
Si je change le contenu de DocOpenHelper() par quelque chose de bidon
comme "x=1", ça marche aussi. Si par contre, je change par un truc plus
réduit qu'à l'origine mais accédant tout de même à quelque chose de Word
comme "MsgBox ActiveDocument.AttachedTemplate.Name", ça continue de
planter en sortie (jamais en entrée).
Alors, sachant que je ne peux pas me passer d'aucun des éléments
présents (events handlers, fct helper, combo-box), j'aimerais identifier
ce qui pose problème dans DocOpenHelper pour voir à contourner le
plantage.
Ce qui me perturbe est aussi qu'un code exécuté à l'ouverture génère un
plantage à la fermeture d'essai.doc, et ceci même si Document_Close()
est vide (vide pour réduire le cas au mini des minis qui continue de
planter).
Voilà ! Est-ce que ça vous inspire quelque chose ? Je peux envoyer ces
deux fichiers (un zip de 34Ko) à qui veut essayer sous Word 97 (sais pas
pour les autres versions) bien sûr.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Anacoluthe
Bonjour !
Vous confondez les événements d'ouverture et fermeture du modèle avec ceux d'ouverture et fermeture du document...... ;-)
Anacoluthe « Tout est difficile avant d'être simple. » - Thomas FULLER
'natric' nous a écrit ...
[Posted to microsoft.public.fr.word, copy sent to author]
Bonjour à tous,
J'ai un problème de plantage à la fermeture d'un document (essai.doc) attaché à un modèle (base.dot). Pour vous expliquer ça, j'ai créer deux fichiers minimum qui reproduisent le problème. En voici une description :
- essai.doc est un document vide, simplement attaché à base.dot.
- base.dot contient juste une liste déroulante vide ds le document même et un peu de code :
.dans ThisDocument :
Private Sub Document_Open() DocOpenHelper End Sub
Private Sub Document_Close() 'n'importe quel contenu End Sub
.dans un module nommé Module1:
Function DocOpenHelper() If ActiveDocument.Name = "base.dot" Then MsgBox "Pas un doc" End If End Function
Voilà, avec ça, quand j'ouvre, puis ferme base.dot, tout est ok. Mais si j'ouvre essai.doc, puis tente de le fermer, j'obtiens immédiatement et de manière constante un crash de winword.exe (Word 97 SR2 sous Win2K Pro FR SP4) avec l'erreur "L'instruction à '0x651ff21a' emploie l'adresse mémoire '0x0000002c'. La mémoire ne peut pas être 'read'.
Si je supprime au moins un des private sub de ThisDocument OU supprime la seule fonction de Module1 OU retire la liste déroulante de l'interface, par magie, ça ne plante plus du tout.
Si je change le contenu de DocOpenHelper() par quelque chose de bidon comme "x=1", ça marche aussi. Si par contre, je change par un truc plus réduit qu'à l'origine mais accédant tout de même à quelque chose de Word comme "MsgBox ActiveDocument.AttachedTemplate.Name", ça continue de planter en sortie (jamais en entrée).
Alors, sachant que je ne peux pas me passer d'aucun des éléments présents (events handlers, fct helper, combo-box), j'aimerais identifier ce qui pose problème dans DocOpenHelper pour voir à contourner le plantage.
Ce qui me perturbe est aussi qu'un code exécuté à l'ouverture génère un plantage à la fermeture d'essai.doc, et ceci même si Document_Close() est vide (vide pour réduire le cas au mini des minis qui continue de planter).
Voilà ! Est-ce que ça vous inspire quelque chose ? Je peux envoyer ces deux fichiers (un zip de 34Ko) à qui veut essayer sous Word 97 (sais pas pour les autres versions) bien sûr.
Arghhhh!
Bonjour !
Vous confondez les événements d'ouverture et fermeture du modèle
avec ceux d'ouverture et fermeture du document...... ;-)
Anacoluthe
« Tout est difficile avant d'être simple. »
- Thomas FULLER
'natric' nous a écrit ...
[Posted to microsoft.public.fr.word, copy sent to author]
Bonjour à tous,
J'ai un problème de plantage à la fermeture d'un document (essai.doc)
attaché à un modèle (base.dot). Pour vous expliquer ça, j'ai créer deux
fichiers minimum qui reproduisent le problème. En voici une description
:
- essai.doc est un document vide, simplement attaché à base.dot.
- base.dot contient juste une liste déroulante vide ds le document même
et un peu de code :
.dans ThisDocument :
Private Sub Document_Open()
DocOpenHelper
End Sub
Private Sub Document_Close()
'n'importe quel contenu
End Sub
.dans un module nommé Module1:
Function DocOpenHelper()
If ActiveDocument.Name = "base.dot" Then
MsgBox "Pas un doc"
End If
End Function
Voilà, avec ça, quand j'ouvre, puis ferme base.dot, tout est ok. Mais si
j'ouvre essai.doc, puis tente de le fermer, j'obtiens immédiatement et
de manière constante un crash de winword.exe (Word 97 SR2 sous Win2K Pro
FR SP4) avec l'erreur "L'instruction à '0x651ff21a' emploie l'adresse
mémoire '0x0000002c'. La mémoire ne peut pas être 'read'.
Si je supprime au moins un des private sub de ThisDocument OU supprime
la seule fonction de Module1 OU retire la liste déroulante de
l'interface, par magie, ça ne plante plus du tout.
Si je change le contenu de DocOpenHelper() par quelque chose de bidon
comme "x=1", ça marche aussi. Si par contre, je change par un truc plus
réduit qu'à l'origine mais accédant tout de même à quelque chose de Word
comme "MsgBox ActiveDocument.AttachedTemplate.Name", ça continue de
planter en sortie (jamais en entrée).
Alors, sachant que je ne peux pas me passer d'aucun des éléments
présents (events handlers, fct helper, combo-box), j'aimerais identifier
ce qui pose problème dans DocOpenHelper pour voir à contourner le
plantage.
Ce qui me perturbe est aussi qu'un code exécuté à l'ouverture génère un
plantage à la fermeture d'essai.doc, et ceci même si Document_Close()
est vide (vide pour réduire le cas au mini des minis qui continue de
planter).
Voilà ! Est-ce que ça vous inspire quelque chose ? Je peux envoyer ces
deux fichiers (un zip de 34Ko) à qui veut essayer sous Word 97 (sais pas
pour les autres versions) bien sûr.
Vous confondez les événements d'ouverture et fermeture du modèle avec ceux d'ouverture et fermeture du document...... ;-)
Anacoluthe « Tout est difficile avant d'être simple. » - Thomas FULLER
'natric' nous a écrit ...
[Posted to microsoft.public.fr.word, copy sent to author]
Bonjour à tous,
J'ai un problème de plantage à la fermeture d'un document (essai.doc) attaché à un modèle (base.dot). Pour vous expliquer ça, j'ai créer deux fichiers minimum qui reproduisent le problème. En voici une description :
- essai.doc est un document vide, simplement attaché à base.dot.
- base.dot contient juste une liste déroulante vide ds le document même et un peu de code :
.dans ThisDocument :
Private Sub Document_Open() DocOpenHelper End Sub
Private Sub Document_Close() 'n'importe quel contenu End Sub
.dans un module nommé Module1:
Function DocOpenHelper() If ActiveDocument.Name = "base.dot" Then MsgBox "Pas un doc" End If End Function
Voilà, avec ça, quand j'ouvre, puis ferme base.dot, tout est ok. Mais si j'ouvre essai.doc, puis tente de le fermer, j'obtiens immédiatement et de manière constante un crash de winword.exe (Word 97 SR2 sous Win2K Pro FR SP4) avec l'erreur "L'instruction à '0x651ff21a' emploie l'adresse mémoire '0x0000002c'. La mémoire ne peut pas être 'read'.
Si je supprime au moins un des private sub de ThisDocument OU supprime la seule fonction de Module1 OU retire la liste déroulante de l'interface, par magie, ça ne plante plus du tout.
Si je change le contenu de DocOpenHelper() par quelque chose de bidon comme "x=1", ça marche aussi. Si par contre, je change par un truc plus réduit qu'à l'origine mais accédant tout de même à quelque chose de Word comme "MsgBox ActiveDocument.AttachedTemplate.Name", ça continue de planter en sortie (jamais en entrée).
Alors, sachant que je ne peux pas me passer d'aucun des éléments présents (events handlers, fct helper, combo-box), j'aimerais identifier ce qui pose problème dans DocOpenHelper pour voir à contourner le plantage.
Ce qui me perturbe est aussi qu'un code exécuté à l'ouverture génère un plantage à la fermeture d'essai.doc, et ceci même si Document_Close() est vide (vide pour réduire le cas au mini des minis qui continue de planter).
Voilà ! Est-ce que ça vous inspire quelque chose ? Je peux envoyer ces deux fichiers (un zip de 34Ko) à qui veut essayer sous Word 97 (sais pas pour les autres versions) bien sûr.
Arghhhh!
natric
[Posted to microsoft.public.fr.word, copy sent to author]
In article <#, says...
Bonjour !
Vous confondez les événements d'ouverture et fermeture du modèle avec ceux d'ouverture et fermeture du document...... ;-)
Bon, faisons le point ;-) Soit, essai.doc attaché à base.dot avec Document_Open() et Document_Close() dans ThisDocument de base.dot (rien dans essai.doc).
Document_Open() s'exécute lorsqu'on ouvre base.dot ET lorsque l'on ouvre essai.dot.
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on ferme essai.dot.
Pour t'en convaincre, copies ça dans ThisDocument du modèle :
Private Sub Document_Open() MsgBox "Document_Open() du .dot" End Sub
Private Sub Document_Close() MsgBox "Document_Close() du .dot" End Sub
Et tu verras les deux messages à chaque fois (en ouvrant/fermant base.dot et essai.doc)
Voilà ! Pourquoi ce plantage en sortie d'essai.doc ? Le mystère reste entier.
Je réitère donc ma question : que faut-il changer dans DocOpenHelper() pour que ça ne plante pas ?
[Posted to microsoft.public.fr.word, copy sent to author]
In article <#wcwbnv0EHA.1196@TK2MSFTNGP15.phx.gbl>,
nopub_anacoluthe@Ouanadoo.fr says...
Bonjour !
Vous confondez les événements d'ouverture et fermeture du modèle
avec ceux d'ouverture et fermeture du document...... ;-)
Bon, faisons le point ;-) Soit, essai.doc attaché à base.dot avec
Document_Open() et Document_Close() dans ThisDocument de base.dot (rien
dans essai.doc).
Document_Open() s'exécute lorsqu'on ouvre base.dot ET lorsque l'on ouvre
essai.dot.
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on
ferme essai.dot.
Pour t'en convaincre, copies ça dans ThisDocument du modèle :
Private Sub Document_Open()
MsgBox "Document_Open() du .dot"
End Sub
Private Sub Document_Close()
MsgBox "Document_Close() du .dot"
End Sub
Et tu verras les deux messages à chaque fois (en ouvrant/fermant
base.dot et essai.doc)
Voilà ! Pourquoi ce plantage en sortie d'essai.doc ? Le mystère reste
entier.
Je réitère donc ma question : que faut-il changer dans DocOpenHelper()
pour que ça ne plante pas ?
[Posted to microsoft.public.fr.word, copy sent to author]
In article <#, says...
Bonjour !
Vous confondez les événements d'ouverture et fermeture du modèle avec ceux d'ouverture et fermeture du document...... ;-)
Bon, faisons le point ;-) Soit, essai.doc attaché à base.dot avec Document_Open() et Document_Close() dans ThisDocument de base.dot (rien dans essai.doc).
Document_Open() s'exécute lorsqu'on ouvre base.dot ET lorsque l'on ouvre essai.dot.
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on ferme essai.dot.
Pour t'en convaincre, copies ça dans ThisDocument du modèle :
Private Sub Document_Open() MsgBox "Document_Open() du .dot" End Sub
Private Sub Document_Close() MsgBox "Document_Close() du .dot" End Sub
Et tu verras les deux messages à chaque fois (en ouvrant/fermant base.dot et essai.doc)
Voilà ! Pourquoi ce plantage en sortie d'essai.doc ? Le mystère reste entier.
Je réitère donc ma question : que faut-il changer dans DocOpenHelper() pour que ça ne plante pas ?
natric
[Posted to microsoft.public.fr.word, copy sent to author]
In article , says...
Document_Open() s'exécute lorsqu'on ouvre base.dot ET lorsque l'on ouvre essai.dot.
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on ferme essai.dot.
Faute de frappe dans mon précédent post : lire essai.doc bien sûr, il n'y a pas d'essai.dot. Sorry
[Posted to microsoft.public.fr.word, copy sent to author]
In article <MPG.1c101a5d1f81abed98975a@news.free.fr>, natricity@free.fr
says...
Document_Open() s'exécute lorsqu'on ouvre base.dot ET lorsque l'on ouvre
essai.dot.
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on
ferme essai.dot.
Faute de frappe dans mon précédent post : lire essai.doc bien sûr, il
n'y a pas d'essai.dot. Sorry
[Posted to microsoft.public.fr.word, copy sent to author]
In article , says...
Document_Open() s'exécute lorsqu'on ouvre base.dot ET lorsque l'on ouvre essai.dot.
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on ferme essai.dot.
Faute de frappe dans mon précédent post : lire essai.doc bien sûr, il n'y a pas d'essai.dot. Sorry
Anacoluthe
Bonjour !
'natric' nous a écrit ...
Vous confondez les événements d'ouverture et fermeture du modèle avec ceux d'ouverture et fermeture du document...... ;-)
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on ferme essai.dot.
Ben oui, c'est ça le problème : Document_Close cause souvent des soucis s'il est placé dans le modèle. Le code est parfois lancé plusieurs fois avec des objets qui disparaissent, d'où plantage. Utilisez les événements Document dans le /document/ ou des événements Application (BeforeClose par exemple) ou des macros automatiques (AutoClose par exemple).
Anacoluthe « L'événement c'est comme la plomberie, une affaire de spécialiste. » - Daniel SCHNEIDERMANN
Bonjour !
'natric' nous a écrit ...
Vous confondez les événements d'ouverture et fermeture du modèle
avec ceux d'ouverture et fermeture du document...... ;-)
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on
ferme essai.dot.
Ben oui, c'est ça le problème : Document_Close cause souvent des
soucis s'il est placé dans le modèle. Le code est parfois lancé
plusieurs fois avec des objets qui disparaissent, d'où plantage.
Utilisez les événements Document dans le /document/ ou des événements
Application (BeforeClose par exemple) ou des macros automatiques
(AutoClose par exemple).
Anacoluthe
« L'événement c'est comme la plomberie,
une affaire de spécialiste. »
- Daniel SCHNEIDERMANN
Vous confondez les événements d'ouverture et fermeture du modèle avec ceux d'ouverture et fermeture du document...... ;-)
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on ferme essai.dot.
Ben oui, c'est ça le problème : Document_Close cause souvent des soucis s'il est placé dans le modèle. Le code est parfois lancé plusieurs fois avec des objets qui disparaissent, d'où plantage. Utilisez les événements Document dans le /document/ ou des événements Application (BeforeClose par exemple) ou des macros automatiques (AutoClose par exemple).
Anacoluthe « L'événement c'est comme la plomberie, une affaire de spécialiste. » - Daniel SCHNEIDERMANN
natric
[Posted to microsoft.public.fr.word, copy sent to author]
In article <exZAzt#, says...
Bonjour !
'natric' nous a écrit ...
Vous confondez les événements d'ouverture et fermeture du modèle avec ceux d'ouverture et fermeture du document...... ;-)
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on ferme essai.dot.
Ben oui, c'est ça le problème : Document_Close cause souvent des soucis s'il est placé dans le modèle. Le code est parfois lancé plusieurs fois avec des objets qui disparaissent, d'où plantage. Utilisez les événements Document dans le /document/ ou des événements Application (BeforeClose par exemple) ou des macros automatiques (AutoClose par exemple).
Ah, là y a de la pensée. Merci Anacoluthe. Alors, en trois points :
1) je trouve tout de même étrange que Word ne prenne pas ça en charge et plante bêtement (faudrait leur envoyer des codeurs Assembly et consorts pour es guider un peu les pôvres)
2) Utiliser ds le doc : hummm, pas top pour mon cas, mais ce serait un peu long (en gros, les macros doivent disparaitre des doc "livrés" au final ; c'est une contrainte)
3) Le AutoClose, non (cf. un autre fil que j'ai lançé récemment ds ce ng) car visible ds la liste user via ALT-F8.
4) BeforeClose : ça, ça me plaît. J'essaierai ça et viendrai dire le résultat ;-)
Have a good night
[Posted to microsoft.public.fr.word, copy sent to author]
In article <exZAzt#0EHA.3588@TK2MSFTNGP14.phx.gbl>,
nopub_anacoluthe@Ouanadoo.fr says...
Bonjour !
'natric' nous a écrit ...
Vous confondez les événements d'ouverture et fermeture du modèle
avec ceux d'ouverture et fermeture du document...... ;-)
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on
ferme essai.dot.
Ben oui, c'est ça le problème : Document_Close cause souvent des
soucis s'il est placé dans le modèle. Le code est parfois lancé
plusieurs fois avec des objets qui disparaissent, d'où plantage.
Utilisez les événements Document dans le /document/ ou des événements
Application (BeforeClose par exemple) ou des macros automatiques
(AutoClose par exemple).
Ah, là y a de la pensée. Merci Anacoluthe. Alors, en trois points :
1) je trouve tout de même étrange que Word ne prenne pas ça en charge et
plante bêtement (faudrait leur envoyer des codeurs Assembly et consorts
pour es guider un peu les pôvres)
2) Utiliser ds le doc : hummm, pas top pour mon cas, mais ce serait un
peu long (en gros, les macros doivent disparaitre des doc "livrés" au
final ; c'est une contrainte)
3) Le AutoClose, non (cf. un autre fil que j'ai lançé récemment ds ce
ng) car visible ds la liste user via ALT-F8.
4) BeforeClose : ça, ça me plaît. J'essaierai ça et viendrai dire le
résultat ;-)
[Posted to microsoft.public.fr.word, copy sent to author]
In article <exZAzt#, says...
Bonjour !
'natric' nous a écrit ...
Vous confondez les événements d'ouverture et fermeture du modèle avec ceux d'ouverture et fermeture du document...... ;-)
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on ferme essai.dot.
Ben oui, c'est ça le problème : Document_Close cause souvent des soucis s'il est placé dans le modèle. Le code est parfois lancé plusieurs fois avec des objets qui disparaissent, d'où plantage. Utilisez les événements Document dans le /document/ ou des événements Application (BeforeClose par exemple) ou des macros automatiques (AutoClose par exemple).
Ah, là y a de la pensée. Merci Anacoluthe. Alors, en trois points :
1) je trouve tout de même étrange que Word ne prenne pas ça en charge et plante bêtement (faudrait leur envoyer des codeurs Assembly et consorts pour es guider un peu les pôvres)
2) Utiliser ds le doc : hummm, pas top pour mon cas, mais ce serait un peu long (en gros, les macros doivent disparaitre des doc "livrés" au final ; c'est une contrainte)
3) Le AutoClose, non (cf. un autre fil que j'ai lançé récemment ds ce ng) car visible ds la liste user via ALT-F8.
4) BeforeClose : ça, ça me plaît. J'essaierai ça et viendrai dire le résultat ;-)
Have a good night
Jean-Guy Marcil
natric was telling us: natric nous racontait que :
[Posted to microsoft.public.fr.word, copy sent to author]
In article <exZAzt#, says...
Bonjour !
'natric' nous a écrit ...
Vous confondez les événements d'ouverture et fermeture du modèle avec ceux d'ouverture et fermeture du document...... ;-)
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on ferme essai.dot.
Ben oui, c'est ça le problème : Document_Close cause souvent des soucis s'il est placé dans le modèle. Le code est parfois lancé plusieurs fois avec des objets qui disparaissent, d'où plantage. Utilisez les événements Document dans le /document/ ou des événements Application (BeforeClose par exemple) ou des macros automatiques (AutoClose par exemple).
Ah, là y a de la pensée. Merci Anacoluthe. Alors, en trois points :
1) je trouve tout de même étrange que Word ne prenne pas ça en charge et plante bêtement (faudrait leur envoyer des codeurs Assembly et consorts pour es guider un peu les pôvres)
2) Utiliser ds le doc : hummm, pas top pour mon cas, mais ce serait un peu long (en gros, les macros doivent disparaitre des doc "livrés" au final ; c'est une contrainte)
3) Le AutoClose, non (cf. un autre fil que j'ai lançé récemment ds ce ng) car visible ds la liste user via ALT-F8.
4) BeforeClose : ça, ça me plaît. J'essaierai ça et viendrai dire le résultat ;-)
Mais c'est beaucoup de code pour rien, peut-être, Je trouve ça bizarre ce problème que tu as. Si tu veux, envoie-moi ton base.dot (celui que tu mentionnes dans ton premier message et qui faisais planté Word,) et je ferai des tests quand j'aurai 5 mnutes. Tu as bien dis Word 97, n'est-ce pas?
-- Salut! _______________________________________ Jean-Guy Marcil - Word MVP
Word MVP site: http://www.word.mvps.org
natric was telling us:
natric nous racontait que :
[Posted to microsoft.public.fr.word, copy sent to author]
In article <exZAzt#0EHA.3588@TK2MSFTNGP14.phx.gbl>,
nopub_anacoluthe@Ouanadoo.fr says...
Bonjour !
'natric' nous a écrit ...
Vous confondez les événements d'ouverture et fermeture du modèle
avec ceux d'ouverture et fermeture du document...... ;-)
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on
ferme essai.dot.
Ben oui, c'est ça le problème : Document_Close cause souvent des
soucis s'il est placé dans le modèle. Le code est parfois lancé
plusieurs fois avec des objets qui disparaissent, d'où plantage.
Utilisez les événements Document dans le /document/ ou des événements
Application (BeforeClose par exemple) ou des macros automatiques
(AutoClose par exemple).
Ah, là y a de la pensée. Merci Anacoluthe. Alors, en trois points :
1) je trouve tout de même étrange que Word ne prenne pas ça en charge
et plante bêtement (faudrait leur envoyer des codeurs Assembly et
consorts pour es guider un peu les pôvres)
2) Utiliser ds le doc : hummm, pas top pour mon cas, mais ce serait un
peu long (en gros, les macros doivent disparaitre des doc "livrés" au
final ; c'est une contrainte)
3) Le AutoClose, non (cf. un autre fil que j'ai lançé récemment ds ce
ng) car visible ds la liste user via ALT-F8.
4) BeforeClose : ça, ça me plaît. J'essaierai ça et viendrai dire le
résultat ;-)
Mais c'est beaucoup de code pour rien, peut-être, Je trouve ça bizarre ce
problème que tu as.
Si tu veux, envoie-moi ton base.dot (celui que tu mentionnes dans ton
premier message et qui faisais planté Word,) et je ferai des tests quand
j'aurai 5 mnutes.
Tu as bien dis Word 97, n'est-ce pas?
--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
jmarcilREMOVE@CAPSsympatico.caTHISTOO
Word MVP site: http://www.word.mvps.org
natric was telling us: natric nous racontait que :
[Posted to microsoft.public.fr.word, copy sent to author]
In article <exZAzt#, says...
Bonjour !
'natric' nous a écrit ...
Vous confondez les événements d'ouverture et fermeture du modèle avec ceux d'ouverture et fermeture du document...... ;-)
Document_Close() s'exécute lorsqu'on ferme base.dot ET lorsque l'on ferme essai.dot.
Ben oui, c'est ça le problème : Document_Close cause souvent des soucis s'il est placé dans le modèle. Le code est parfois lancé plusieurs fois avec des objets qui disparaissent, d'où plantage. Utilisez les événements Document dans le /document/ ou des événements Application (BeforeClose par exemple) ou des macros automatiques (AutoClose par exemple).
Ah, là y a de la pensée. Merci Anacoluthe. Alors, en trois points :
1) je trouve tout de même étrange que Word ne prenne pas ça en charge et plante bêtement (faudrait leur envoyer des codeurs Assembly et consorts pour es guider un peu les pôvres)
2) Utiliser ds le doc : hummm, pas top pour mon cas, mais ce serait un peu long (en gros, les macros doivent disparaitre des doc "livrés" au final ; c'est une contrainte)
3) Le AutoClose, non (cf. un autre fil que j'ai lançé récemment ds ce ng) car visible ds la liste user via ALT-F8.
4) BeforeClose : ça, ça me plaît. J'essaierai ça et viendrai dire le résultat ;-)
Mais c'est beaucoup de code pour rien, peut-être, Je trouve ça bizarre ce problème que tu as. Si tu veux, envoie-moi ton base.dot (celui que tu mentionnes dans ton premier message et qui faisais planté Word,) et je ferai des tests quand j'aurai 5 mnutes. Tu as bien dis Word 97, n'est-ce pas?
-- Salut! _______________________________________ Jean-Guy Marcil - Word MVP
Word MVP site: http://www.word.mvps.org
natric
[Posted to microsoft.public.fr.word, copy sent to author]
In article <ezqSco$, no- says...
Mais c'est beaucoup de code pour rien, peut-être, Je trouve ça bizarre ce problème que tu as. Si tu veux, envoie-moi ton base.dot (celui que tu mentionnes dans ton premier message et qui faisais planté Word,) et je ferai des tests quand j'aurai 5 mnutes. Tu as bien dis Word 97, n'est-ce pas?
Word 97 SR2 sous W2K Pro SP4 FR, oui. Je t'email ça juste après l'envoi de ce post. Merci de te pencher sur la bête à cinq pattes, Jean-Guy.
[Posted to microsoft.public.fr.word, copy sent to author]
In article <ezqSco$0EHA.4072@TK2MSFTNGP10.phx.gbl>, no-
spam@leaveme.alone says...
Mais c'est beaucoup de code pour rien, peut-être, Je trouve ça bizarre ce
problème que tu as.
Si tu veux, envoie-moi ton base.dot (celui que tu mentionnes dans ton
premier message et qui faisais planté Word,) et je ferai des tests quand
j'aurai 5 mnutes.
Tu as bien dis Word 97, n'est-ce pas?
Word 97 SR2 sous W2K Pro SP4 FR, oui. Je t'email ça juste après l'envoi
de ce post. Merci de te pencher sur la bête à cinq pattes, Jean-Guy.
[Posted to microsoft.public.fr.word, copy sent to author]
In article <ezqSco$, no- says...
Mais c'est beaucoup de code pour rien, peut-être, Je trouve ça bizarre ce problème que tu as. Si tu veux, envoie-moi ton base.dot (celui que tu mentionnes dans ton premier message et qui faisais planté Word,) et je ferai des tests quand j'aurai 5 mnutes. Tu as bien dis Word 97, n'est-ce pas?
Word 97 SR2 sous W2K Pro SP4 FR, oui. Je t'email ça juste après l'envoi de ce post. Merci de te pencher sur la bête à cinq pattes, Jean-Guy.
Jean-Guy Marcil
natric was telling us: natric nous racontait que :
[Posted to microsoft.public.fr.word, copy sent to author]
In article <ezqSco$, no- says...
Mais c'est beaucoup de code pour rien, peut-être, Je trouve ça bizarre ce problème que tu as. Si tu veux, envoie-moi ton base.dot (celui que tu mentionnes dans ton premier message et qui faisais planté Word,) et je ferai des tests quand j'aurai 5 mnutes. Tu as bien dis Word 97, n'est-ce pas?
Word 97 SR2 sous W2K Pro SP4 FR, oui. Je t'email ça juste après l'envoi de ce post. Merci de te pencher sur la bête à cinq pattes, Jean-Guy.
Bon, J'ai fait quelques tests de mon côté.
J'ai Word 97, mais sur Win 98. Je ne crois pas que la version de Windows ait à voir dans ce problème.
Mes résultats étaient quelque peu différents des tiens. J'ai créé un doc à partir de ton base.dot. Ce doc plantait tout le temps, quoique je fasse. La différence était au niveau de la combobox. Si je l'enlevais du doc, alors il plantait à la fermeture (m¸eme après un enregistrement). Sinon, si je gardais la combobox, mais faisais des changements dans le code VBA de base.dot, alors il plantait à l'ouverture, peut importe le changement (aucun changement donnait le même résultat).
AMHA, le problème se situe au niveau du combobox. Ces controles ActiveX sont très instables et apportent presque toujours des problèmes un jour ou l'autre dans les documents.
J'ai ouvert Word, créé un nouveau document, copié tout le code de ton base.dot en passant par le volet explorateur de projets dans l'éditeur de VBA et je l'ai enregistré en tant que modèle. Je n'ai pas mis de contrôle ActiveX. Alors là, aucun problème. Jamais. Le code lui-même ne cause pas de problème. Le fait que ton base.dot ait eu un ActiveX l'a rendu corrompu. J'ai enleveé le combobox de ton modèle base.dot et créé un nouveau document. Ce document plantait de la même façon que ton essai.doc. Comme tu vois, même si le contrôle ActiveX est supprimé, la corruption qu'il a causée reste là. Ce qui est bizarre, c'est que le base.dot lui-même n'exhibe pas ce comportement. Mais c'est la nature des contrôle ActiveX... des résultats bizarres. Je les évite comme la peste. Peu-être que quelqu'un s'y connaissant dasn les contôles ActiveX viendra nous éclairer?
Donc, il semble qu'il faille que tu remplaces le ComboBox par une autre astuce, champ MACROBUTTON, champ AutoTextList, bouton sur une barre d'outils, champ de formulaire, etc. Ou, tu peux re-créer ton modèle à partir d'un document vierge et espérer que cette fois-ci le contrôle AcxtiveX n'apportera pas de corruption.
En passant, si tu crée un document basé sur un modèle, puis tu déplaces le document ET le modèle. Alors quand tu ouvres le document, Word trouvera le modèle si:
1) Le modèle est dans le même dossier que le doc, 2) Le modèle est dans le dossier des modèles utilisateur, 3) Le modèle est dans le dossier des modèle de groupes, 4) Le modèle est dans le même dossier qu'à l'origine (Si différent de 1 à 3), 5) Le modèle est dans le dossier des modèles de Word par Défaut (ce dossier diffère selon la version de Word, Word 97 = Programe FilesMicrosoftModèles.... je crois).
Si plusieurs modèles portant le même nom se trouvent dans ces dossiers, Word prendra le premier qu'il trouve selon l'ordre que j'ai listé (Voir http://tinyurl.com/3stqx pour une discussion à ce sujet que j'ai eu avec un collègue MVP (en anglais). L'ordre n'est important seulement si un ordi comporte plusieures versions du mème modèle à différents endroits). Donc tu peux toujours envoyer un doument et son modèle et demander au récipiendaire de les placer dans le même dossier.
-- Salut! _______________________________________ Jean-Guy Marcil - Word MVP
Word MVP site: http://www.word.mvps.org
natric was telling us:
natric nous racontait que :
[Posted to microsoft.public.fr.word, copy sent to author]
In article <ezqSco$0EHA.4072@TK2MSFTNGP10.phx.gbl>, no-
spam@leaveme.alone says...
Mais c'est beaucoup de code pour rien, peut-être, Je trouve ça
bizarre ce problème que tu as.
Si tu veux, envoie-moi ton base.dot (celui que tu mentionnes dans ton
premier message et qui faisais planté Word,) et je ferai des tests
quand j'aurai 5 mnutes.
Tu as bien dis Word 97, n'est-ce pas?
Word 97 SR2 sous W2K Pro SP4 FR, oui. Je t'email ça juste après
l'envoi de ce post. Merci de te pencher sur la bête à cinq pattes,
Jean-Guy.
Bon, J'ai fait quelques tests de mon côté.
J'ai Word 97, mais sur Win 98. Je ne crois pas que la version de Windows ait
à voir dans ce problème.
Mes résultats étaient quelque peu différents des tiens.
J'ai créé un doc à partir de ton base.dot. Ce doc plantait tout le temps,
quoique je fasse. La différence était au niveau de la combobox. Si je
l'enlevais du doc, alors il plantait à la fermeture (m¸eme après un
enregistrement). Sinon, si je gardais la combobox, mais faisais des
changements dans le code VBA de base.dot, alors il plantait à l'ouverture,
peut importe le changement (aucun changement donnait le même résultat).
AMHA, le problème se situe au niveau du combobox. Ces controles ActiveX sont
très instables et apportent presque toujours des problèmes un jour ou
l'autre dans les documents.
J'ai ouvert Word, créé un nouveau document, copié tout le code de ton
base.dot en passant par le volet explorateur de projets dans l'éditeur de
VBA et je l'ai enregistré en tant que modèle. Je n'ai pas mis de contrôle
ActiveX. Alors là, aucun problème. Jamais. Le code lui-même ne cause pas de
problème. Le fait que ton base.dot ait eu un ActiveX l'a rendu corrompu.
J'ai enleveé le combobox de ton modèle base.dot et créé un nouveau document.
Ce document plantait de la même façon que ton essai.doc. Comme tu vois, même
si le contrôle ActiveX est supprimé, la corruption qu'il a causée reste là.
Ce qui est bizarre, c'est que le base.dot lui-même n'exhibe pas ce
comportement. Mais c'est la nature des contrôle ActiveX... des résultats
bizarres. Je les évite comme la peste. Peu-être que quelqu'un s'y
connaissant dasn les contôles ActiveX viendra nous éclairer?
Donc, il semble qu'il faille que tu remplaces le ComboBox par une autre
astuce, champ MACROBUTTON, champ AutoTextList, bouton sur une barre
d'outils, champ de formulaire, etc.
Ou, tu peux re-créer ton modèle à partir d'un document vierge et espérer
que cette fois-ci le contrôle AcxtiveX n'apportera pas de corruption.
En passant, si tu crée un document basé sur un modèle, puis tu déplaces le
document ET le modèle. Alors quand tu ouvres le document, Word trouvera le
modèle si:
1) Le modèle est dans le même dossier que le doc,
2) Le modèle est dans le dossier des modèles utilisateur,
3) Le modèle est dans le dossier des modèle de groupes,
4) Le modèle est dans le même dossier qu'à l'origine (Si différent de 1 à
3),
5) Le modèle est dans le dossier des modèles de Word par Défaut (ce dossier
diffère selon la version de Word, Word 97 = Programe
FilesMicrosoftModèles.... je crois).
Si plusieurs modèles portant le même nom se trouvent dans ces dossiers, Word
prendra le premier qu'il trouve selon l'ordre que j'ai listé (Voir
http://tinyurl.com/3stqx pour une discussion à ce sujet que j'ai eu avec un
collègue MVP (en anglais). L'ordre n'est important seulement si un ordi
comporte plusieures versions du mème modèle à différents endroits). Donc tu
peux toujours envoyer un doument et son modèle et demander au récipiendaire
de les placer dans le même dossier.
--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
jmarcilREMOVE@CAPSsympatico.caTHISTOO
Word MVP site: http://www.word.mvps.org
natric was telling us: natric nous racontait que :
[Posted to microsoft.public.fr.word, copy sent to author]
In article <ezqSco$, no- says...
Mais c'est beaucoup de code pour rien, peut-être, Je trouve ça bizarre ce problème que tu as. Si tu veux, envoie-moi ton base.dot (celui que tu mentionnes dans ton premier message et qui faisais planté Word,) et je ferai des tests quand j'aurai 5 mnutes. Tu as bien dis Word 97, n'est-ce pas?
Word 97 SR2 sous W2K Pro SP4 FR, oui. Je t'email ça juste après l'envoi de ce post. Merci de te pencher sur la bête à cinq pattes, Jean-Guy.
Bon, J'ai fait quelques tests de mon côté.
J'ai Word 97, mais sur Win 98. Je ne crois pas que la version de Windows ait à voir dans ce problème.
Mes résultats étaient quelque peu différents des tiens. J'ai créé un doc à partir de ton base.dot. Ce doc plantait tout le temps, quoique je fasse. La différence était au niveau de la combobox. Si je l'enlevais du doc, alors il plantait à la fermeture (m¸eme après un enregistrement). Sinon, si je gardais la combobox, mais faisais des changements dans le code VBA de base.dot, alors il plantait à l'ouverture, peut importe le changement (aucun changement donnait le même résultat).
AMHA, le problème se situe au niveau du combobox. Ces controles ActiveX sont très instables et apportent presque toujours des problèmes un jour ou l'autre dans les documents.
J'ai ouvert Word, créé un nouveau document, copié tout le code de ton base.dot en passant par le volet explorateur de projets dans l'éditeur de VBA et je l'ai enregistré en tant que modèle. Je n'ai pas mis de contrôle ActiveX. Alors là, aucun problème. Jamais. Le code lui-même ne cause pas de problème. Le fait que ton base.dot ait eu un ActiveX l'a rendu corrompu. J'ai enleveé le combobox de ton modèle base.dot et créé un nouveau document. Ce document plantait de la même façon que ton essai.doc. Comme tu vois, même si le contrôle ActiveX est supprimé, la corruption qu'il a causée reste là. Ce qui est bizarre, c'est que le base.dot lui-même n'exhibe pas ce comportement. Mais c'est la nature des contrôle ActiveX... des résultats bizarres. Je les évite comme la peste. Peu-être que quelqu'un s'y connaissant dasn les contôles ActiveX viendra nous éclairer?
Donc, il semble qu'il faille que tu remplaces le ComboBox par une autre astuce, champ MACROBUTTON, champ AutoTextList, bouton sur une barre d'outils, champ de formulaire, etc. Ou, tu peux re-créer ton modèle à partir d'un document vierge et espérer que cette fois-ci le contrôle AcxtiveX n'apportera pas de corruption.
En passant, si tu crée un document basé sur un modèle, puis tu déplaces le document ET le modèle. Alors quand tu ouvres le document, Word trouvera le modèle si:
1) Le modèle est dans le même dossier que le doc, 2) Le modèle est dans le dossier des modèles utilisateur, 3) Le modèle est dans le dossier des modèle de groupes, 4) Le modèle est dans le même dossier qu'à l'origine (Si différent de 1 à 3), 5) Le modèle est dans le dossier des modèles de Word par Défaut (ce dossier diffère selon la version de Word, Word 97 = Programe FilesMicrosoftModèles.... je crois).
Si plusieurs modèles portant le même nom se trouvent dans ces dossiers, Word prendra le premier qu'il trouve selon l'ordre que j'ai listé (Voir http://tinyurl.com/3stqx pour une discussion à ce sujet que j'ai eu avec un collègue MVP (en anglais). L'ordre n'est important seulement si un ordi comporte plusieures versions du mème modèle à différents endroits). Donc tu peux toujours envoyer un doument et son modèle et demander au récipiendaire de les placer dans le même dossier.
-- Salut! _______________________________________ Jean-Guy Marcil - Word MVP
Word MVP site: http://www.word.mvps.org
natric
[Posted to microsoft.public.fr.word, copy sent to author]
Bon ! Quoique tes résultats diffèrent des miens (moi plantages toujours à la fermeture), dans la mesure où tu mets le doigt sur un dysfonctionnement par corruption due à l'emploi d'un ActiveX, ça devient peu important que ça plante comme-ci ou comme-ça ;o) Glurps.
Bon, content que tu te sois penché sur le sujet. Je ne sais pas encore si je vais tenter la reconstruction du dot from scratch OU le contournement de l'emploi du combo (dont l'emploi ici est une sorte de MRU liste informée à l'ouverture du dot à partir d'un fichier ini).
Ca devient plus clair... Je viendrai dire ici ce que j'aurais fait une fois fait, histoire de finir proprement le fil.
Et pour Jean-Guy, hip hip hip...
[Posted to microsoft.public.fr.word, copy sent to author]
Bon ! Quoique tes résultats diffèrent des miens (moi plantages toujours
à la fermeture), dans la mesure où tu mets le doigt sur un
dysfonctionnement par corruption due à l'emploi d'un ActiveX, ça devient
peu important que ça plante comme-ci ou comme-ça ;o) Glurps.
Bon, content que tu te sois penché sur le sujet. Je ne sais pas encore
si je vais tenter la reconstruction du dot from scratch OU le
contournement de l'emploi du combo (dont l'emploi ici est une sorte de
MRU liste informée à l'ouverture du dot à partir d'un fichier ini).
Ca devient plus clair... Je viendrai dire ici ce que j'aurais fait une
fois fait, histoire de finir proprement le fil.
[Posted to microsoft.public.fr.word, copy sent to author]
Bon ! Quoique tes résultats diffèrent des miens (moi plantages toujours à la fermeture), dans la mesure où tu mets le doigt sur un dysfonctionnement par corruption due à l'emploi d'un ActiveX, ça devient peu important que ça plante comme-ci ou comme-ça ;o) Glurps.
Bon, content que tu te sois penché sur le sujet. Je ne sais pas encore si je vais tenter la reconstruction du dot from scratch OU le contournement de l'emploi du combo (dont l'emploi ici est une sorte de MRU liste informée à l'ouverture du dot à partir d'un fichier ini).
Ca devient plus clair... Je viendrai dire ici ce que j'aurais fait une fois fait, histoire de finir proprement le fil.
