Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Référence

15 réponses
Avatar
sunburn
Bonjour,
comment puis-je, à l'ouverture de mon classeur, vérifier et cocher les
références manquante ?
sinon, mon classuer plante (jutilise la référence de Word) ??

Je vous remercie.
YANN

10 réponses

1 2
Avatar
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/

sunburn a écrit :
Bonjour,
comment puis-je, à l'ouverture de mon classeur, vérifier et cocher les
références manquante ?
sinon, mon classuer plante (jutilise la référence de Word) ??

Je vous remercie.
YANN


Avatar
MichDenis
Bonjour Frédéric,

J'ai une nette préférence pour la méthode "addfromGUID"
car elle sera valide peu importe la version de Word
installée sur l'ordinateur où le fichier s'ouvrira. Ce n'est
pas vrai pour la méthode "AddFromFile"

L'autre solution est de modifier la "liaison précoce" en
"liaison tardive" au niveau de la déclaration des variables

Au lieu d'utiliser
Dim Wd as Word.Application
set Wd = createobject("Word.Application")

ou encore :
Dim Wd As New Word.Application

On utilise seulement :
Dim Wd As Object






"FS" a écrit dans le message de groupe de discussion :

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/

sunburn a écrit :
Bonjour,
comment puis-je, à l'ouverture de mon classeur, vérifier et cocher les
références manquante ?
sinon, mon classuer plante (jutilise la référence de Word) ??

Je vous remercie.
YANN


Avatar
FS
Salut Denis,

Ces précisions et suggestions aideront certainement "sunburn" à régler
son problème. Il a maintenant amplement le choix.
J'ai déduit de sa question qu'il avait volontairement écarté
l'utilisation d'une liaison tardive, mais j'ai peut-être eu tort ?
Juste une précision. Lorsque tu écris

> Au lieu d'utiliser
> Dim Wd as Word.Application
> set Wd = createobject("Word.Application")

tu utilises dans le même "mouvement" liaison précoce (Dim Wd as
Word.Application) et liaison tardive (set Wd =
createobject("Word.Application")).
Repris tel que, ton code provoque une erreur si la référence à Word
n'est pas cochée.

Les techniques "non ambigües" de déclaration sont plutôt :

'==========liaison précoce (la référence à Word est cochée)
Dim Wd as Word.Application 'déclaration
Set Wd=New Word.Application 'initialisation

ou (en une seule opération déclaration + initialisation)
Dim Wd as New Word.Application

'==========ou liaison tardive (pas de référence cochée)
Dim Wd as Object (ou As Variant)
Set Wd=CreateObject("Word.Application")


Cordialement,

FS
--
Frédéric SIGONNEAU
Modules et modèles pour Excel :
http://frederic.sigonneau.free.fr/

MichDenis a écrit :
Bonjour Frédéric,

J'ai une nette préférence pour la méthode "addfromGUID"
car elle sera valide peu importe la version de Word
installée sur l'ordinateur où le fichier s'ouvrira. Ce n'est
pas vrai pour la méthode "AddFromFile"

L'autre solution est de modifier la "liaison précoce" en
"liaison tardive" au niveau de la déclaration des variables

Au lieu d'utiliser
Dim Wd as Word.Application
set Wd = createobject("Word.Application")

ou encore :
Dim Wd As New Word.Application

On utilise seulement :
Dim Wd As Object






"FS" a écrit dans le message de groupe de discussion :

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


Avatar
MichDenis
Bonjour Frédéric,

D'abord cette procédure fonctionne bien lorsque
la référence "Microsoft Word" est non cochée et
ça c'est une "liaison tardive"
'------------------------------
Sub test()
Dim Wd As Object
Set Wd = CreateObject("Word.Application")
Wd.Visible = True
Wd.Quit
End Sub
'------------------------------

Concernant la liaison précoce :

Lorsque la bibliothèque Word est chargée, ce code
fonctionne très bien ! Je crois qu'il y a eu méprise
quant à la façon dont je me suis exprimé.
'-------------------------------
Sub test1()
Dim Wd As Word.Application
Set Wd = CreateObject("Word.Application")
Wd.Visible = True
Wd.Quit
End Sub
'-------------------------------

Une autre façon de créer une liaison précoce
'-------------------------------
Sub test2()
Dim Wd As New Word.Application
Wd.Visible = True
Wd.Quit
End Sub
'-------------------------------

Selon les lectures faites, la différence entre une liaison précoce
ou tardive est au niveau de la déclaration de la variable. Lorsque
l'on déclare de façon non équivoque dans le type de variable la
bibliothèque à laquelle appartient un objet, on est alors en présence
d'une liaison précoce. En l'absence de cette spécification, on
assigne au type de l'objet "object" puisque la bibliothèque
n'est pas présente au moment de la compilation.

De les 2 procédures de "liaison précoce" présentées : "test1" et "test2",
je préfère "Test1" car je peux décider de "créer l'objet" au moment
opportun n'importe dans le code d'une procédure. J'ai ce que les
programmeurs aiment bien, le "contrôle" du moment de sa création.

Pour créer l'objet "Word" lui-même, que ce soit pas l'usage du mot "New"
ou par l'usage de "Vba.Interaction.CreateObject()" ou en plus couramment
(createobject) je n'y vois pas grand différence si ce n'est que le moment
ou l'objet est créé.

J'ajouterai ceci :
Lorsque l'on déclare une variable comme :
Dim Rg As Range
le nom de la bibliothèque auquel appartient la bibliothèque est non
obligatoire car l'objet appartient à une bibliothèque déjà déclarée,
mais elle est sous-entendu...Pour Excel, c'est l'équivalent à :
Dim Rg As Excel.Range
C'est ce que je disais plutôt, la référence à la bibliothèque est
présente dans la déclaration de l'objet lui-même, sinon, on se
retrouverait dans la même position avec
dim Rg As Object ou Dim Rg As Variant.






"FS" a écrit dans le message de groupe de discussion :
#LRfT2$
Salut Denis,

Ces précisions et suggestions aideront certainement "sunburn" à régler
son problème. Il a maintenant amplement le choix.
J'ai déduit de sa question qu'il avait volontairement écarté
l'utilisation d'une liaison tardive, mais j'ai peut-être eu tort ?
Juste une précision. Lorsque tu écris

> Au lieu d'utiliser
> Dim Wd as Word.Application
> set Wd = createobject("Word.Application")

tu utilises dans le même "mouvement" liaison précoce (Dim Wd as
Word.Application) et liaison tardive (set Wd createobject("Word.Application")).
Repris tel que, ton code provoque une erreur si la référence à Word
n'est pas cochée.

Les techniques "non ambigües" de déclaration sont plutôt :

'==========liaison précoce (la référence à Word est cochée)
Dim Wd as Word.Application 'déclaration
Set Wd=New Word.Application 'initialisation

ou (en une seule opération déclaration + initialisation)
Dim Wd as New Word.Application

'==========ou liaison tardive (pas de référence cochée)
Dim Wd as Object (ou As Variant)
Set Wd=CreateObject("Word.Application")


Cordialement,

FS
--
Frédéric SIGONNEAU
Modules et modèles pour Excel :
http://frederic.sigonneau.free.fr/

MichDenis a écrit :
Bonjour Frédéric,

J'ai une nette préférence pour la méthode "addfromGUID"
car elle sera valide peu importe la version de Word
installée sur l'ordinateur où le fichier s'ouvrira. Ce n'est
pas vrai pour la méthode "AddFromFile"

L'autre solution est de modifier la "liaison précoce" en
"liaison tardive" au niveau de la déclaration des variables

Au lieu d'utiliser
Dim Wd as Word.Application
set Wd = createobject("Word.Application")

ou encore :
Dim Wd As New Word.Application

On utilise seulement :
Dim Wd As Object






"FS" a écrit dans le message de groupe de discussion :

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


Avatar
FS
Re Denis,

Je vois que tu persistes et signes :-)

> Lorsque la bibliothèque Word est chargée, ce code
> fonctionne très bien ! Je crois qu'il y a eu méprise
> quant à la façon dont je me suis exprimé.
> '-------------------------------
> Sub test1()
> Dim Wd As Word.Application
> Set Wd = CreateObject("Word.Application")
> Wd.Visible = True
> Wd.Quit
> End Sub
> '-------------------------------

Je n'ai pas dit qu'il ne fonctionnait pas (je me cite) :

> Repris tel que, ton code provoque une erreur si la référence à Word
> n'est pas cochée.

Ce qui revient exactement à ce que tu rappelles :

> Lorsque la bibliothèque Word est chargée, ce code
> fonctionne très bien !

Mais
J'ai dit, et je redis, que ce code mélange liaison précoce (pour
déclarer la variable) et liaison tardive (pour l'initialiser). Ce qui
revient à dire qu'en réalité la liaison précoce ne sert à rien
puisqu'elle n'ai pas utilisée pour créer l'objet Word (ce qui est quand
même le but du jeu ! :)

Bon, j'arrête là sur ce sujet si tu veux bien.
Bonne soirée (AM pour toi je suppose) et
cordialement

FS
--
Frédéric SIGONNEAU
Modules et modèles pour Excel :
http://frederic.sigonneau.free.fr/

MichDenis a écrit :
Bonjour Frédéric,

D'abord cette procédure fonctionne bien lorsque
la référence "Microsoft Word" est non cochée et
ça c'est une "liaison tardive"
'------------------------------
Sub test()
Dim Wd As Object
Set Wd = CreateObject("Word.Application")
Wd.Visible = True
Wd.Quit
End Sub
'------------------------------

Concernant la liaison précoce :

Lorsque la bibliothèque Word est chargée, ce code
fonctionne très bien ! Je crois qu'il y a eu méprise
quant à la façon dont je me suis exprimé.
'-------------------------------
Sub test1()
Dim Wd As Word.Application
Set Wd = CreateObject("Word.Application")
Wd.Visible = True
Wd.Quit
End Sub
'-------------------------------

Une autre façon de créer une liaison précoce
'-------------------------------
Sub test2()
Dim Wd As New Word.Application
Wd.Visible = True
Wd.Quit
End Sub
'-------------------------------

Selon les lectures faites, la différence entre une liaison précoce
ou tardive est au niveau de la déclaration de la variable. Lorsque
l'on déclare de façon non équivoque dans le type de variable la
bibliothèque à laquelle appartient un objet, on est alors en présence
d'une liaison précoce. En l'absence de cette spécification, on
assigne au type de l'objet "object" puisque la bibliothèque
n'est pas présente au moment de la compilation.

De les 2 procédures de "liaison précoce" présentées : "test1" et "test2",
je préfère "Test1" car je peux décider de "créer l'objet" au moment
opportun n'importe dans le code d'une procédure. J'ai ce que les
programmeurs aiment bien, le "contrôle" du moment de sa création.

Pour créer l'objet "Word" lui-même, que ce soit pas l'usage du mot "New"
ou par l'usage de "Vba.Interaction.CreateObject()" ou en plus couramment
(createobject) je n'y vois pas grand différence si ce n'est que le moment
ou l'objet est créé.

J'ajouterai ceci :
Lorsque l'on déclare une variable comme :
Dim Rg As Range
le nom de la bibliothèque auquel appartient la bibliothèque est non
obligatoire car l'objet appartient à une bibliothèque déjà déclarée,
mais elle est sous-entendu...Pour Excel, c'est l'équivalent à :
Dim Rg As Excel.Range
C'est ce que je disais plutôt, la référence à la bibliothèque est
présente dans la déclaration de l'objet lui-même, sinon, on se
retrouverait dans la même position avec
dim Rg As Object ou Dim Rg As Variant.






"FS" a écrit dans le message de groupe de discussion :
#LRfT2$
Salut Denis,

Ces précisions et suggestions aideront certainement "sunburn" à régler
son problème. Il a maintenant amplement le choix.
J'ai déduit de sa question qu'il avait volontairement écarté
l'utilisation d'une liaison tardive, mais j'ai peut-être eu tort ?
Juste une précision. Lorsque tu écris

> Au lieu d'utiliser
> Dim Wd as Word.Application
> set Wd = createobject("Word.Application")

tu utilises dans le même "mouvement" liaison précoce (Dim Wd as
Word.Application) et liaison tardive (set Wd > createobject("Word.Application")).
Repris tel que, ton code provoque une erreur si la référence à Word
n'est pas cochée.

Les techniques "non ambigües" de déclaration sont plutôt :

'==========liaison précoce (la référence à Word est cochée)
Dim Wd as Word.Application 'déclaration
Set Wd=New Word.Application 'initialisation

ou (en une seule opération déclaration + initialisation)
Dim Wd as New Word.Application

'==========ou liaison tardive (pas de référence cochée)
Dim Wd as Object (ou As Variant)
Set Wd=CreateObject("Word.Application")


Cordialement,

FS


Avatar
FS
Bon OK, continuons cette intéressante discussion.
Le mélange que tu utilises a donc un nom 'Dual interface' (Double
interface ?).
Il n'en reste pas moins un "mélange".
L'intérêt de la liaison tardive c'est qu'elle permet de se passer d'une
référence à la bibliothèque qui contient l'objet invoqué. La 'Dual
interface' n'a pas cet intérêt puisque la bibliothèque doit être
référencée pour que la variable puisse être déclarée typée.

Donc, intérêt du truc ???
D'ailleurs ton lien envoie sur une page datée de juin 2000 : on ne peut
pas dire que le concept ait fait des vagues !
:)

FS
--
Frédéric SIGONNEAU
Modules et modèles pour Excel :
http://frederic.sigonneau.free.fr/

MichDenis a écrit :
http://kandkconsulting.tripod.com/VB/Tutorials/vb_binding_tutorial.htm






Avatar
MichDenis
| L'intérêt de la liaison tardive
*** Il me semble que l'on était d'accord sur le fond
à quoi bon revenir sur cette partie de la question

| ton lien envoie sur une page datée de juin 2000 :
| on ne peut pas dire que le concept ait fait des vagues !
*** Je dirais que le concept n'est pas nouveau et que je
n'ai rien inventé en écrivant mes propos. Certains
"stigma" prennent du temps à s'effacer de la mémoire !

L'article utilise plusieurs termes : " IUnknown" , "QueryInterface"
"DispatchID", "ProgID", "Dual interface" ... en tentant d'expliquer
comment la compilation est effectué lorsqu'une variable est typée.
En d'autres mots, comment Excel procède pour aller chercher dans
la base de registre de Windows l'information qu'il a besoin pour
l'exécution de la compilation du code et dans un deuxième temps
pourquoi la déclaration d'une variable typée permet une exécution
du code plus rapide.
Pour m'être intéressé à la chose, c'est quelque chose de très complexe
qui n'a à mon avis jamais été traité dans un bouquin dédié à Excel. Je
m'en voudrais d'attribuer aux expressions cités plus haut des significations
inappropriées.

Je me permets de copier ici une réponse de "Chip Pearson" faisait
à une question sur le sujet. D'ailleurs, dit-il, il ne se définit pas
comme expert sur le sujet, mais cela illustre bien un langage qui
n'est pas souvent utilisé sur ce forum. ;-)

======================================= I am certainly no expert on the topic, and you can probably
expect corrections and clarifications to my reply from either
Stephen or Rob, but here goes....

COM objects (ActiveX, OLE, Automation, whatever the most recent
"term of art" happens to be -- they are all at a high level
essentially the same, internal plumbing varies) support an
"interface" called IUnknown. They also support their own specific
interfaces (something like IExcel for the Excel application).

When you declare something As Excel.Application and use the New
keyword, you are telling the compiler to go through the specific
IExcel (or whatever it is called) interface to the Excel
Application object. Because you've referenced this in the VBA
Tools>References settings, the compiler can read the typelib
file, and "bind" or "resolve" or "figure out" how to talk to
Excel.Application. Because this is done at compile time, not run
time, execution is much faster.

When you declare something As Object and use CreateObject, VBA
has no idea what "object" you're dealing with. An "Object" can
be anything from you own simple class module to an entire Excel
Application. In this case, the compiler emits code to go through
the IUnknown interface, specifically a method called
QueryInterface (QI). The QI method returns, more or less, an
array of pointers to all the other interfaces supported by the
object. Once those interface pointers are known, VBA then goes
through IDispatch (this is where I get lost) to read those
interfaces to determine the specific property or method to
actually call (via a pointer). It does this by reading what is
called the VTable of the interface. (VTable is short for "virtual
function table" which describes the names, types, and addresses
of the properties and methods of the interface). All of this
takes a great deal of system overhead and makes your code execute
very substantially slower.

Here is where I get a bit lost. I believe that using "early
binding" bypasses the QI step, but still requires the overhead of
the IDispatch interface. That is a restriction of VB. Other
languages like C++ can bypass IDispatch completely and go
directly to the specific property or method function address.
You'll have to wait for a ruling from Stephen or Rob on that
assertion, though. I'm getting out of my world with that level.

In summary, in "early binding" the compiler can figure out much
of how to call methods and properties. With "late binding" the
generic interfaces talk to one another, figure things out, and
get it to work. "Late binding" is very slow, but more flexible.

I VERY strongly recommend "Advanced Visual Basic 6" by Matthew
Curland (ISBN 0-201-70712-8) for a very detailed and remarkably
clear and readable explanation of all this and much more. It is
the best $40 you'll spend if you're really interested in this
sort of thing. Curland is/was one of the developers at MS of the
VB platform, and a frequent contributor down the hall in the VB
newsgroups. Don't let the stupid picture on the cover fool you.
It is a great technical book.

--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
========================================================================== De: "Dana DeLouis" 08:54
Objet: Re: Early and Late Binding - Excel 2000
====================================================================
Avatar
FS
> | L'intérêt de la liaison tardive


> *** Il me semble que l'on était d'accord sur le fond
> à quoi bon revenir sur cette partie de la question

Je n'en suis pas si sûr :(
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.
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
--
Frédéric SIGONNEAU
Modules et modèles pour Excel :
http://frederic.sigonneau.free.fr/

MichDenis a écrit :
| L'intérêt de la liaison tardive
*** Il me semble que l'on était d'accord sur le fond
à quoi bon revenir sur cette partie de la question

| ton lien envoie sur une page datée de juin 2000 :
| on ne peut pas dire que le concept ait fait des vagues !
*** Je dirais que le concept n'est pas nouveau et que je
n'ai rien inventé en écrivant mes propos. Certains
"stigma" prennent du temps à s'effacer de la mémoire !

L'article utilise plusieurs termes : " IUnknown" , "QueryInterface"
"DispatchID", "ProgID", "Dual interface" ... en tentant d'expliquer
comment la compilation est effectué lorsqu'une variable est typée.
En d'autres mots, comment Excel procède pour aller chercher dans
la base de registre de Windows l'information qu'il a besoin pour
l'exécution de la compilation du code et dans un deuxième temps
pourquoi la déclaration d'une variable typée permet une exécution
du code plus rapide.
Pour m'être intéressé à la chose, c'est quelque chose de très complexe
qui n'a à mon avis jamais été traité dans un bouquin dédié à Excel. Je
m'en voudrais d'attribuer aux expressions cités plus haut des significations
inappropriées.

Je me permets de copier ici une réponse de "Chip Pearson" faisait
à une question sur le sujet. D'ailleurs, dit-il, il ne se définit pas
comme expert sur le sujet, mais cela illustre bien un langage qui
n'est pas souvent utilisé sur ce forum. ;-)

======================================= > I am certainly no expert on the topic, and you can probably
expect corrections and clarifications to my reply from either
Stephen or Rob, but here goes....

COM objects (ActiveX, OLE, Automation, whatever the most recent
"term of art" happens to be -- they are all at a high level
essentially the same, internal plumbing varies) support an
"interface" called IUnknown. They also support their own specific
interfaces (something like IExcel for the Excel application).

When you declare something As Excel.Application and use the New
keyword, you are telling the compiler to go through the specific
IExcel (or whatever it is called) interface to the Excel
Application object. Because you've referenced this in the VBA
Tools>References settings, the compiler can read the typelib
file, and "bind" or "resolve" or "figure out" how to talk to
Excel.Application. Because this is done at compile time, not run
time, execution is much faster.

When you declare something As Object and use CreateObject, VBA
has no idea what "object" you're dealing with. An "Object" can
be anything from you own simple class module to an entire Excel
Application. In this case, the compiler emits code to go through
the IUnknown interface, specifically a method called
QueryInterface (QI). The QI method returns, more or less, an
array of pointers to all the other interfaces supported by the
object. Once those interface pointers are known, VBA then goes
through IDispatch (this is where I get lost) to read those
interfaces to determine the specific property or method to
actually call (via a pointer). It does this by reading what is
called the VTable of the interface. (VTable is short for "virtual
function table" which describes the names, types, and addresses
of the properties and methods of the interface). All of this
takes a great deal of system overhead and makes your code execute
very substantially slower.

Here is where I get a bit lost. I believe that using "early
binding" bypasses the QI step, but still requires the overhead of
the IDispatch interface. That is a restriction of VB. Other
languages like C++ can bypass IDispatch completely and go
directly to the specific property or method function address.
You'll have to wait for a ruling from Stephen or Rob on that
assertion, though. I'm getting out of my world with that level.

In summary, in "early binding" the compiler can figure out much
of how to call methods and properties. With "late binding" the
generic interfaces talk to one another, figure things out, and
get it to work. "Late binding" is very slow, but more flexible.

I VERY strongly recommend "Advanced Visual Basic 6" by Matthew
Curland (ISBN 0-201-70712-8) for a very detailed and remarkably
clear and readable explanation of all this and much more. It is
the best $40 you'll spend if you're really interested in this
sort of thing. Curland is/was one of the developers at MS of the
VB platform, and a frequent contributor down the hall in the VB
newsgroups. Don't let the stupid picture on the cover fool you.
It is a great technical book.

--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
========================================================================== > De: "Dana DeLouis" 08:54
Objet: Re: Early and Late Binding - Excel 2000
=================================================================== >




Avatar
MichDenis
| 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
--
Frédéric SIGONNEAU
Modules et modèles pour Excel :
http://frederic.sigonneau.free.fr/

MichDenis a écrit :
| L'intérêt de la liaison tardive
*** Il me semble que l'on était d'accord sur le fond
à quoi bon revenir sur cette partie de la question

| ton lien envoie sur une page datée de juin 2000 :
| on ne peut pas dire que le concept ait fait des vagues !
*** Je dirais que le concept n'est pas nouveau et que je
n'ai rien inventé en écrivant mes propos. Certains
"stigma" prennent du temps à s'effacer de la mémoire !

L'article utilise plusieurs termes : " IUnknown" , "QueryInterface"
"DispatchID", "ProgID", "Dual interface" ... en tentant d'expliquer
comment la compilation est effectué lorsqu'une variable est typée.
En d'autres mots, comment Excel procède pour aller chercher dans
la base de registre de Windows l'information qu'il a besoin pour
l'exécution de la compilation du code et dans un deuxième temps
pourquoi la déclaration d'une variable typée permet une exécution
du code plus rapide.
Pour m'être intéressé à la chose, c'est quelque chose de très complexe
qui n'a à mon avis jamais été traité dans un bouquin dédié à Excel. Je
m'en voudrais d'attribuer aux expressions cités plus haut des significations
inappropriées.

Je me permets de copier ici une réponse de "Chip Pearson" faisait
à une question sur le sujet. D'ailleurs, dit-il, il ne se définit pas
comme expert sur le sujet, mais cela illustre bien un langage qui
n'est pas souvent utilisé sur ce forum. ;-)

======================================= > I am certainly no expert on the topic, and you can probably
expect corrections and clarifications to my reply from either
Stephen or Rob, but here goes....

COM objects (ActiveX, OLE, Automation, whatever the most recent
"term of art" happens to be -- they are all at a high level
essentially the same, internal plumbing varies) support an
"interface" called IUnknown. They also support their own specific
interfaces (something like IExcel for the Excel application).

When you declare something As Excel.Application and use the New
keyword, you are telling the compiler to go through the specific
IExcel (or whatever it is called) interface to the Excel
Application object. Because you've referenced this in the VBA
Tools>References settings, the compiler can read the typelib
file, and "bind" or "resolve" or "figure out" how to talk to
Excel.Application. Because this is done at compile time, not run
time, execution is much faster.

When you declare something As Object and use CreateObject, VBA
has no idea what "object" you're dealing with. An "Object" can
be anything from you own simple class module to an entire Excel
Application. In this case, the compiler emits code to go through
the IUnknown interface, specifically a method called
QueryInterface (QI). The QI method returns, more or less, an
array of pointers to all the other interfaces supported by the
object. Once those interface pointers are known, VBA then goes
through IDispatch (this is where I get lost) to read those
interfaces to determine the specific property or method to
actually call (via a pointer). It does this by reading what is
called the VTable of the interface. (VTable is short for "virtual
function table" which describes the names, types, and addresses
of the properties and methods of the interface). All of this
takes a great deal of system overhead and makes your code execute
very substantially slower.

Here is where I get a bit lost. I believe that using "early
binding" bypasses the QI step, but still requires the overhead of
the IDispatch interface. That is a restriction of VB. Other
languages like C++ can bypass IDispatch completely and go
directly to the specific property or method function address.
You'll have to wait for a ruling from Stephen or Rob on that
assertion, though. I'm getting out of my world with that level.

In summary, in "early binding" the compiler can figure out much
of how to call methods and properties. With "late binding" the
generic interfaces talk to one another, figure things out, and
get it to work. "Late binding" is very slow, but more flexible.

I VERY strongly recommend "Advanced Visual Basic 6" by Matthew
Curland (ISBN 0-201-70712-8) for a very detailed and remarkably
clear and readable explanation of all this and much more. It is
the best $40 you'll spend if you're really interested in this
sort of thing. Curland is/was one of the developers at MS of the
VB platform, and a frequent contributor down the hall in the VB
newsgroups. Don't let the stupid picture on the cover fool you.
It is a great technical book.

--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
========================================================================== > De: "Dana DeLouis" 08:54
Objet: Re: Early and Late Binding - Excel 2000
=================================================================== >




1 2