> C ) On déclare le type de la variable :
| Ton code en 'Dual interface' annule l'intérêt de la liaison tardive
| puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
Ce que tu proposais en début de ce fil sur la liaison tardive,
je suis totalement en accord avec ton propos !
======================= > liaison tardive (pas de référence cochée)
Dim Wd as Object (ou As Variant)
Set Wd=CreateObject("Word.Application")
======================= >
De conclure comme le fait ton dernier message :
J'avoue là ne rien y comprendre!
======================== > puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
======================== >
Pour moi, c'est simple :
Liaison précoce -> dans la déclaration de la variable, le type de
la variable est spécifique et permet à Excel de
compiler le projet. Elle identifie la bibliothèque
et la classe de l'objet
Dim Wd As Word.Application
Wd -> la variable
Word -> la bibliothèque
Application -> Classe de l'objet
On peut le faire de 3 façons différentes :
A ) On crée l'instance dans la déclaration de la variable elle-même
Dim Wd As New Word.Application
B ) On déclarer le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, on crée la nouvelle instance en utilisant le mot New
Set Wd = New Word.Application
C ) On déclare le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, au moment désiré :
Set Wd = CreateObject("Word.Application")
Si on s'entend pour dire qu'un liaison précoce doit permettre
une déclaration de variable typée pour permettre une compilation
efficace du projet, je ne vois pas en quoi, l'une des présentations
( A, B, C ) devraient être exclues. Maintenant, laquelle est plus
efficace, ça c'est un autre débat. La littérature tend à préférer
l'ordre suivant : B, A, C. Perso, je n'ai pas les compétences pour
débattre des dires de Chip Pearson et de saisir toutes les nuances
de chaque approche. Dommage qu'il n'y ait pas quelques grosses
têtes versées sur ces processus internes de la mécanique d'Excel,
voire de la programmation, pour nous apporter un peu de lumière.
Chip Pearson, pour ce que je comprends de son article, rappelle le
fonctionnement "interne" et les avantages/inconvénients de chaque
méthode. Mais n'évoque pas la 'troisième voie' que tu as faite tienne..
Bon allez, sur ce, bonne nuit (pour moi).
FS
> C ) On déclare le type de la variable :
| Ton code en 'Dual interface' annule l'intérêt de la liaison tardive
| puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
Ce que tu proposais en début de ce fil sur la liaison tardive,
je suis totalement en accord avec ton propos !
======================= > liaison tardive (pas de référence cochée)
Dim Wd as Object (ou As Variant)
Set Wd=CreateObject("Word.Application")
======================= >
De conclure comme le fait ton dernier message :
J'avoue là ne rien y comprendre!
======================== > puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
======================== >
Pour moi, c'est simple :
Liaison précoce -> dans la déclaration de la variable, le type de
la variable est spécifique et permet à Excel de
compiler le projet. Elle identifie la bibliothèque
et la classe de l'objet
Dim Wd As Word.Application
Wd -> la variable
Word -> la bibliothèque
Application -> Classe de l'objet
On peut le faire de 3 façons différentes :
A ) On crée l'instance dans la déclaration de la variable elle-même
Dim Wd As New Word.Application
B ) On déclarer le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, on crée la nouvelle instance en utilisant le mot New
Set Wd = New Word.Application
C ) On déclare le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, au moment désiré :
Set Wd = CreateObject("Word.Application")
Si on s'entend pour dire qu'un liaison précoce doit permettre
une déclaration de variable typée pour permettre une compilation
efficace du projet, je ne vois pas en quoi, l'une des présentations
( A, B, C ) devraient être exclues. Maintenant, laquelle est plus
efficace, ça c'est un autre débat. La littérature tend à préférer
l'ordre suivant : B, A, C. Perso, je n'ai pas les compétences pour
débattre des dires de Chip Pearson et de saisir toutes les nuances
de chaque approche. Dommage qu'il n'y ait pas quelques grosses
têtes versées sur ces processus internes de la mécanique d'Excel,
voire de la programmation, pour nous apporter un peu de lumière.
Chip Pearson, pour ce que je comprends de son article, rappelle le
fonctionnement "interne" et les avantages/inconvénients de chaque
méthode. Mais n'évoque pas la 'troisième voie' que tu as faite tienne..
Bon allez, sur ce, bonne nuit (pour moi).
FS
> C ) On déclare le type de la variable :
| Ton code en 'Dual interface' annule l'intérêt de la liaison tardive
| puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
Ce que tu proposais en début de ce fil sur la liaison tardive,
je suis totalement en accord avec ton propos !
======================= > liaison tardive (pas de référence cochée)
Dim Wd as Object (ou As Variant)
Set Wd=CreateObject("Word.Application")
======================= >
De conclure comme le fait ton dernier message :
J'avoue là ne rien y comprendre!
======================== > puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
======================== >
Pour moi, c'est simple :
Liaison précoce -> dans la déclaration de la variable, le type de
la variable est spécifique et permet à Excel de
compiler le projet. Elle identifie la bibliothèque
et la classe de l'objet
Dim Wd As Word.Application
Wd -> la variable
Word -> la bibliothèque
Application -> Classe de l'objet
On peut le faire de 3 façons différentes :
A ) On crée l'instance dans la déclaration de la variable elle-même
Dim Wd As New Word.Application
B ) On déclarer le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, on crée la nouvelle instance en utilisant le mot New
Set Wd = New Word.Application
C ) On déclare le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, au moment désiré :
Set Wd = CreateObject("Word.Application")
Si on s'entend pour dire qu'un liaison précoce doit permettre
une déclaration de variable typée pour permettre une compilation
efficace du projet, je ne vois pas en quoi, l'une des présentations
( A, B, C ) devraient être exclues. Maintenant, laquelle est plus
efficace, ça c'est un autre débat. La littérature tend à préférer
l'ordre suivant : B, A, C. Perso, je n'ai pas les compétences pour
débattre des dires de Chip Pearson et de saisir toutes les nuances
de chaque approche. Dommage qu'il n'y ait pas quelques grosses
têtes versées sur ces processus internes de la mécanique d'Excel,
voire de la programmation, pour nous apporter un peu de lumière.
Chip Pearson, pour ce que je comprends de son article, rappelle le
fonctionnement "interne" et les avantages/inconvénients de chaque
méthode. Mais n'évoque pas la 'troisième voie' que tu as faite tienne..
Bon allez, sur ce, bonne nuit (pour moi).
FS
C ) On déclare le type de la variable :
| Ton code en 'Dual interface' annule l'intérêt de la liaison tardive
| puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
Ce que tu proposais en début de ce fil sur la liaison tardive,
je suis totalement en accord avec ton propos !
======================= > liaison tardive (pas de référence cochée)
Dim Wd as Object (ou As Variant)
Set Wd=CreateObject("Word.Application")
======================= >
De conclure comme le fait ton dernier message :
J'avoue là ne rien y comprendre!
======================== > puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
======================== >
Pour moi, c'est simple :
Liaison précoce -> dans la déclaration de la variable, le type de
la variable est spécifique et permet à Excel de
compiler le projet. Elle identifie la bibliothèque
et la classe de l'objet
Dim Wd As Word.Application
Wd -> la variable
Word -> la bibliothèque
Application -> Classe de l'objet
On peut le faire de 3 façons différentes :
A ) On crée l'instance dans la déclaration de la variable elle-même
Dim Wd As New Word.Application
B ) On déclarer le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, on crée la nouvelle instance en utilisant le mot New
Set Wd = New Word.Application
C ) On déclare le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, au moment désiré :
Set Wd = CreateObject("Word.Application")
Si on s'entend pour dire qu'un liaison précoce doit permettre
une déclaration de variable typée pour permettre une compilation
efficace du projet, je ne vois pas en quoi, l'une des présentations
( A, B, C ) devraient être exclues. Maintenant, laquelle est plus
efficace, ça c'est un autre débat. La littérature tend à préférer
l'ordre suivant : B, A, C. Perso, je n'ai pas les compétences pour
débattre des dires de Chip Pearson et de saisir toutes les nuances
de chaque approche. Dommage qu'il n'y ait pas quelques grosses
têtes versées sur ces processus internes de la mécanique d'Excel,
voire de la programmation, pour nous apporter un peu de lumière.
Chip Pearson, pour ce que je comprends de son article, rappelle le
fonctionnement "interne" et les avantages/inconvénients de chaque
méthode. Mais n'évoque pas la 'troisième voie' que tu as faite tienne..
Bon allez, sur ce, bonne nuit (pour moi).
FS
C ) On déclare le type de la variable :
| Ton code en 'Dual interface' annule l'intérêt de la liaison tardive
| puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
Ce que tu proposais en début de ce fil sur la liaison tardive,
je suis totalement en accord avec ton propos !
======================= > liaison tardive (pas de référence cochée)
Dim Wd as Object (ou As Variant)
Set Wd=CreateObject("Word.Application")
======================= >
De conclure comme le fait ton dernier message :
J'avoue là ne rien y comprendre!
======================== > puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
======================== >
Pour moi, c'est simple :
Liaison précoce -> dans la déclaration de la variable, le type de
la variable est spécifique et permet à Excel de
compiler le projet. Elle identifie la bibliothèque
et la classe de l'objet
Dim Wd As Word.Application
Wd -> la variable
Word -> la bibliothèque
Application -> Classe de l'objet
On peut le faire de 3 façons différentes :
A ) On crée l'instance dans la déclaration de la variable elle-même
Dim Wd As New Word.Application
B ) On déclarer le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, on crée la nouvelle instance en utilisant le mot New
Set Wd = New Word.Application
C ) On déclare le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, au moment désiré :
Set Wd = CreateObject("Word.Application")
Si on s'entend pour dire qu'un liaison précoce doit permettre
une déclaration de variable typée pour permettre une compilation
efficace du projet, je ne vois pas en quoi, l'une des présentations
( A, B, C ) devraient être exclues. Maintenant, laquelle est plus
efficace, ça c'est un autre débat. La littérature tend à préférer
l'ordre suivant : B, A, C. Perso, je n'ai pas les compétences pour
débattre des dires de Chip Pearson et de saisir toutes les nuances
de chaque approche. Dommage qu'il n'y ait pas quelques grosses
têtes versées sur ces processus internes de la mécanique d'Excel,
voire de la programmation, pour nous apporter un peu de lumière.
Chip Pearson, pour ce que je comprends de son article, rappelle le
fonctionnement "interne" et les avantages/inconvénients de chaque
méthode. Mais n'évoque pas la 'troisième voie' que tu as faite tienne..
Bon allez, sur ce, bonne nuit (pour moi).
FS
C ) On déclare le type de la variable :
| Ton code en 'Dual interface' annule l'intérêt de la liaison tardive
| puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
Ce que tu proposais en début de ce fil sur la liaison tardive,
je suis totalement en accord avec ton propos !
======================= > liaison tardive (pas de référence cochée)
Dim Wd as Object (ou As Variant)
Set Wd=CreateObject("Word.Application")
======================= >
De conclure comme le fait ton dernier message :
J'avoue là ne rien y comprendre!
======================== > puisqu'il nécessite une référence à la bibliothèque nécessaire à la
| déclaration de la variable objet.
======================== >
Pour moi, c'est simple :
Liaison précoce -> dans la déclaration de la variable, le type de
la variable est spécifique et permet à Excel de
compiler le projet. Elle identifie la bibliothèque
et la classe de l'objet
Dim Wd As Word.Application
Wd -> la variable
Word -> la bibliothèque
Application -> Classe de l'objet
On peut le faire de 3 façons différentes :
A ) On crée l'instance dans la déclaration de la variable elle-même
Dim Wd As New Word.Application
B ) On déclarer le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, on crée la nouvelle instance en utilisant le mot New
Set Wd = New Word.Application
C ) On déclare le type de la variable :
Dim Wd As Word.Application
Et dans la procédure, au moment désiré :
Set Wd = CreateObject("Word.Application")
Si on s'entend pour dire qu'un liaison précoce doit permettre
une déclaration de variable typée pour permettre une compilation
efficace du projet, je ne vois pas en quoi, l'une des présentations
( A, B, C ) devraient être exclues. Maintenant, laquelle est plus
efficace, ça c'est un autre débat. La littérature tend à préférer
l'ordre suivant : B, A, C. Perso, je n'ai pas les compétences pour
débattre des dires de Chip Pearson et de saisir toutes les nuances
de chaque approche. Dommage qu'il n'y ait pas quelques grosses
têtes versées sur ces processus internes de la mécanique d'Excel,
voire de la programmation, pour nous apporter un peu de lumière.
Chip Pearson, pour ce que je comprends de son article, rappelle le
fonctionnement "interne" et les avantages/inconvénients de chaque
méthode. Mais n'évoque pas la 'troisième voie' que tu as faite tienne..
Bon allez, sur ce, bonne nuit (pour moi).
FS
J'ai créé ce classeur : http://cjoint.com/?iDx7XdZ0Ea
Il s'agit de faire exécuter 5 boucles où la tâche consiste
à créer une instance de Word et d'Access pour les fermer
aussitôt. J'ai fait rouler à quelques reprises, et les résultats
ne sont pas très convaincants.
De toute façon, il ne faut (fallait) pas s'attendre à une grande différence
en temps d'exécution. La rapidité des processeurs des ordinateurs
de l'époque avec ceux d'aujourd'hui n'a plus rien de comparable!
"FS" a écrit dans le message de groupe de discussion :C ) On déclare le type de la variable :
> Dim Wd As Word.Application
> Et dans la procédure, au moment désiré :
> Set Wd = CreateObject("Word.Application")
et
> Si on s'entend pour dire qu'un liaison précoce doit permettre
> une déclaration de variable typée pour permettre une compilation
> efficace du projet, je ne vois pas en quoi, l'une des présentations
> ( A, B, C ) devraient être exclues.
Denis,
En C) tu déclares d'une manière et tu initialises d'une autre. Ça
compile sans erreur, bien sûr, mais pour moi ce n'est plus une liaison
précoce.
Les différences se retrouvent en principe à l'exécution. La liaison
précoce donne un code plus rapide à l'exécution que la liaison tardive.
J'ai essayé de mesurer les écarts de performances entre les 2 + 1 mais
sur la seule création d'une instance de Word, ce n'est pas très
significatif. Si ça te tente :
'=============(dans un module ordinaire)
Private Declare Function GetTickCount Lib "kernel32" () As Long
Sub LiaisonPrecoce()
Dim Duree, Wd As Word.Application
Duree = GetTickCount
Set Wd = New Word.Application
Wd.documents.Add
Wd.Visible = True
Duree = GetTickCount - Duree
MsgBox "Temps d'exécution :" & Duree & " ms"
End Sub
Sub LiaisonTardive()
Dim Duree, Wd As Object
Duree = GetTickCount
Set Wd = CreateObject("Word.application")
Wd.documents.Add
Wd.Visible = True
Duree = GetTickCount - Duree
MsgBox "Temps d'exécution :" & Duree & " ms"
End Sub
Sub LiaisonDuelle()
Dim Duree, Wd As Word.Application
Duree = GetTickCount
Set Wd = CreateObject("Word.application")
Wd.documents.Add
Wd.Visible = True
Duree = GetTickCount - Duree
MsgBox "Temps d'exécution :" & Duree & " ms"
End Sub
'====================================== >
FS
J'ai créé ce classeur : http://cjoint.com/?iDx7XdZ0Ea
Il s'agit de faire exécuter 5 boucles où la tâche consiste
à créer une instance de Word et d'Access pour les fermer
aussitôt. J'ai fait rouler à quelques reprises, et les résultats
ne sont pas très convaincants.
De toute façon, il ne faut (fallait) pas s'attendre à une grande différence
en temps d'exécution. La rapidité des processeurs des ordinateurs
de l'époque avec ceux d'aujourd'hui n'a plus rien de comparable!
"FS" <fs@news.group> a écrit dans le message de groupe de discussion :
eYKoplLKKHA.4376@TK2MSFTNGP03.phx.gbl...
C ) On déclare le type de la variable :
> Dim Wd As Word.Application
> Et dans la procédure, au moment désiré :
> Set Wd = CreateObject("Word.Application")
et
> Si on s'entend pour dire qu'un liaison précoce doit permettre
> une déclaration de variable typée pour permettre une compilation
> efficace du projet, je ne vois pas en quoi, l'une des présentations
> ( A, B, C ) devraient être exclues.
Denis,
En C) tu déclares d'une manière et tu initialises d'une autre. Ça
compile sans erreur, bien sûr, mais pour moi ce n'est plus une liaison
précoce.
Les différences se retrouvent en principe à l'exécution. La liaison
précoce donne un code plus rapide à l'exécution que la liaison tardive.
J'ai essayé de mesurer les écarts de performances entre les 2 + 1 mais
sur la seule création d'une instance de Word, ce n'est pas très
significatif. Si ça te tente :
'=============(dans un module ordinaire)
Private Declare Function GetTickCount Lib "kernel32" () As Long
Sub LiaisonPrecoce()
Dim Duree, Wd As Word.Application
Duree = GetTickCount
Set Wd = New Word.Application
Wd.documents.Add
Wd.Visible = True
Duree = GetTickCount - Duree
MsgBox "Temps d'exécution :" & Duree & " ms"
End Sub
Sub LiaisonTardive()
Dim Duree, Wd As Object
Duree = GetTickCount
Set Wd = CreateObject("Word.application")
Wd.documents.Add
Wd.Visible = True
Duree = GetTickCount - Duree
MsgBox "Temps d'exécution :" & Duree & " ms"
End Sub
Sub LiaisonDuelle()
Dim Duree, Wd As Word.Application
Duree = GetTickCount
Set Wd = CreateObject("Word.application")
Wd.documents.Add
Wd.Visible = True
Duree = GetTickCount - Duree
MsgBox "Temps d'exécution :" & Duree & " ms"
End Sub
'====================================== >
FS
J'ai créé ce classeur : http://cjoint.com/?iDx7XdZ0Ea
Il s'agit de faire exécuter 5 boucles où la tâche consiste
à créer une instance de Word et d'Access pour les fermer
aussitôt. J'ai fait rouler à quelques reprises, et les résultats
ne sont pas très convaincants.
De toute façon, il ne faut (fallait) pas s'attendre à une grande différence
en temps d'exécution. La rapidité des processeurs des ordinateurs
de l'époque avec ceux d'aujourd'hui n'a plus rien de comparable!
"FS" a écrit dans le message de groupe de discussion :C ) On déclare le type de la variable :
> Dim Wd As Word.Application
> Et dans la procédure, au moment désiré :
> Set Wd = CreateObject("Word.Application")
et
> Si on s'entend pour dire qu'un liaison précoce doit permettre
> une déclaration de variable typée pour permettre une compilation
> efficace du projet, je ne vois pas en quoi, l'une des présentations
> ( A, B, C ) devraient être exclues.
Denis,
En C) tu déclares d'une manière et tu initialises d'une autre. Ça
compile sans erreur, bien sûr, mais pour moi ce n'est plus une liaison
précoce.
Les différences se retrouvent en principe à l'exécution. La liaison
précoce donne un code plus rapide à l'exécution que la liaison tardive.
J'ai essayé de mesurer les écarts de performances entre les 2 + 1 mais
sur la seule création d'une instance de Word, ce n'est pas très
significatif. Si ça te tente :
'=============(dans un module ordinaire)
Private Declare Function GetTickCount Lib "kernel32" () As Long
Sub LiaisonPrecoce()
Dim Duree, Wd As Word.Application
Duree = GetTickCount
Set Wd = New Word.Application
Wd.documents.Add
Wd.Visible = True
Duree = GetTickCount - Duree
MsgBox "Temps d'exécution :" & Duree & " ms"
End Sub
Sub LiaisonTardive()
Dim Duree, Wd As Object
Duree = GetTickCount
Set Wd = CreateObject("Word.application")
Wd.documents.Add
Wd.Visible = True
Duree = GetTickCount - Duree
MsgBox "Temps d'exécution :" & Duree & " ms"
End Sub
Sub LiaisonDuelle()
Dim Duree, Wd As Word.Application
Duree = GetTickCount
Set Wd = CreateObject("Word.application")
Wd.documents.Add
Wd.Visible = True
Duree = GetTickCount - Duree
MsgBox "Temps d'exécution :" & Duree & " ms"
End Sub
'====================================== >
FS
Bonjour,
Tu peux utiliser ce genre de code, dans le Workbook_Open de ton classeur
pour vérifier si la référence à Word est active et l'activer si elle ne
l'est pas :
'===================== > Sub VerifWordRef()
Dim Refs As Object
Set Refs = ThisWorkbook.VBProject.References
On Error Resume Next
' Refs.addfromGUID "{00020905-0000-0000-C000-000000000046}", 8, 3
'ou
Refs.AddFromFile _
"C:Program FilesMicrosoft OfficeOFFICE11MSWORD.OLB"
On Error GoTo 0
End Sub
'===================== >
Toutefois, si ton code doit tourner dans des environnements différents,
il faudra faire attention à des détails importants :
- si tu préfères utiliser le GUID : les paramètres Major (8 ici) et
Minor (3) pourront sans doute être différents
- si tu préfères le fichier : le chemin d'accès sera différent selon les
versions d'Office (il faudra le tester au cas par cas et adapter le chemin).
Cette dernière solution est cependant sans doute plus facile à mettre en
oeuvre, les versions d'office étant facile à récupérer en VBA.
FS
--
Frédéric SIGONNEAU
Modules et modèles pour Excel :
http://frederic.sigonneau.free.fr/
Bonjour,
Tu peux utiliser ce genre de code, dans le Workbook_Open de ton classeur
pour vérifier si la référence à Word est active et l'activer si elle ne
l'est pas :
'===================== > Sub VerifWordRef()
Dim Refs As Object
Set Refs = ThisWorkbook.VBProject.References
On Error Resume Next
' Refs.addfromGUID "{00020905-0000-0000-C000-000000000046}", 8, 3
'ou
Refs.AddFromFile _
"C:Program FilesMicrosoft OfficeOFFICE11MSWORD.OLB"
On Error GoTo 0
End Sub
'===================== >
Toutefois, si ton code doit tourner dans des environnements différents,
il faudra faire attention à des détails importants :
- si tu préfères utiliser le GUID : les paramètres Major (8 ici) et
Minor (3) pourront sans doute être différents
- si tu préfères le fichier : le chemin d'accès sera différent selon les
versions d'Office (il faudra le tester au cas par cas et adapter le chemin).
Cette dernière solution est cependant sans doute plus facile à mettre en
oeuvre, les versions d'office étant facile à récupérer en VBA.
FS
--
Frédéric SIGONNEAU
Modules et modèles pour Excel :
http://frederic.sigonneau.free.fr/
Bonjour,
Tu peux utiliser ce genre de code, dans le Workbook_Open de ton classeur
pour vérifier si la référence à Word est active et l'activer si elle ne
l'est pas :
'===================== > Sub VerifWordRef()
Dim Refs As Object
Set Refs = ThisWorkbook.VBProject.References
On Error Resume Next
' Refs.addfromGUID "{00020905-0000-0000-C000-000000000046}", 8, 3
'ou
Refs.AddFromFile _
"C:Program FilesMicrosoft OfficeOFFICE11MSWORD.OLB"
On Error GoTo 0
End Sub
'===================== >
Toutefois, si ton code doit tourner dans des environnements différents,
il faudra faire attention à des détails importants :
- si tu préfères utiliser le GUID : les paramètres Major (8 ici) et
Minor (3) pourront sans doute être différents
- si tu préfères le fichier : le chemin d'accès sera différent selon les
versions d'Office (il faudra le tester au cas par cas et adapter le chemin).
Cette dernière solution est cependant sans doute plus facile à mettre en
oeuvre, les versions d'office étant facile à récupérer en VBA.
FS
--
Frédéric SIGONNEAU
Modules et modèles pour Excel :
http://frederic.sigonneau.free.fr/
