Avec plusieurs jours de retard, je tenais à rectifier une méprise
au sujet de "Late Binding vs Early binding"
| Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence
| à la librairie des objets de Word _doit_ être cochée pour que le code compile
| sans erreur.
Voici un extrait d'un des derniers bouquins publiés sur Excel :
(Excellent mais pas nécessairement pour débutant...
Je ne sais pas si la traduction française existe !)
'-----------------------
Professional Excel Development: The Definitive Guide to
Developing Applications Using Microsoft® Excel and VBA®
By Stephen Bullen, Rob Bovey, John Green
Publisher: Addison Wesley Professional
Pub Date: February 01, 2005
ISBN: 0-321-26250-6
Pages: 936
'-----------------------
( Au chapitre III )
Dim objConnection As Object
' It doesn't matter how you create the object, it's still
' late bound due to the As Object variable declaration.
Set objConnection = New ADODB.Connection
Set objConnection = CreateObject("ADODB.Connection")
Le simple fait de déclarer une variable AS OBJECT est suffisant pour que cette déclaration
soit considérée comme "Late Binding".
Et pourquoii ? Tout simplement parce que "Late Binding" vs "Early Binding" fait référence
au moment où la procédure identifie l'objet (ses méthodes et propriétés) concerné
et où il se situe dans la base de registre.
Lorsqu'un objet n'est pas spécifiquement "typé" dans la déclaration de la variable,
l'objet est nécessairement identifié "at the run time" et c'est le fondement même de
cette expression "Late Binding" . Dans le cas contraire, lorsque l'objet est
bien "typé", la location de l'objet dans la base de registre, l'identification de
l'objet ainsi que les méthodes et les propriétés de cet objet utilisées dans la
procédure sont faits au moment de la compilation : "Early binding"
Le code soumis par PMO requiert que la référence soit présente pour l'exécution
du code mais cela n'a rien à voir avec la définition du
paradigme "Late vs Early Binding"
Voilà !
Salutations!
"michdenis" <michdenis@hotmail.com> a écrit dans le message de news: ...
Bonjour,
Je m'étais contenté de lire les lignes de déclaration des variables, et,
c'est vrai qu'une telle ligne de code cause problème si on croit effectuer
une liaison prococe :
Set AppWord = New Word.Application
;-)
Salutations!
"Ange Ounis" <nospam@nospam> a écrit dans le message de news: Ocuhj5L%23FHA.2640@tk2msftngp13.phx.gbl...
Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence
à la librairie des objets de Word _doit_ être cochée pour que le code compile
sans erreur.
C'est facile à vérifier :)
Si la référence à la librairie de Word n'est pas cochée, l'instruction
New Word.Application
de la 2ème procédure provoque l'erreur 'type défini par l'utilisateur non
défini', erreur qui ne se produit plus dès que la librairie est cochée...
Les 2 procédures proposées par PMO utilisent donc toutes les 2 des liaisons
précoces. Pour une liaison dite tardive, sans référence à la librairie d'objets
de Word, il faut utiliser soit GetObject (si on suppose que Word est déjà
ouvert) soit CreateObject (pour créer une nouvelle instance de Word).
----------
Ange Ounis
----------
michdenis a écrit :
> Bonjour Ange Ounis,
>
> | La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais
> | plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As
> | Word.Application) et non typée (Dim AppWord As Object).
>
> Le commentaire de PMO est exact.
>
> Dim AppWord As Word.Application
> Ce type de déclaration requiert le chargement de la référence à
> "Microsoft Word x.x object librairy" avant l'exécution du code.
>
> Lors de la compilation, Excel a déjà identifié l'activex et où il est situé dans
> la base de registre. À l'exécution, le code est plus rapide car la "recherche"
> est déjà faite. De là, l'expression "Liaison précode"
>
> Dim AppWord As Object
> - Ne requiert pas le chargement de la référence
> -Lors de la compilation... excel n'est pas en mesure de savoir de quel
> activex il s'agit et de le localiser... c'est ce qu'il va faire à l'exécution
> du code ... d'où l'expression : "Liaison tardive" et un temps d'exécution
> un peu plus lent.
>
>
> Salutations!
>
>
> "Ange Ounis" <nospam@nospam> a écrit dans le message de news: %23xwIZEE%23FHA.4012@TK2MSFTNGP10.phx.gbl...
> Ah, OK.
> Cependant, ce n'est pas, à ma connaissance, la définition habituelle de ces termes.
> La liaison précoce est celle qui s'effectue à la compilation du code alors que
> la liaison tardive s'effectue à l'exécution du code.
> Même si la "compilation" de VBA n'en est pas vraiment une, les liaisons précoces
> et tardives sont bien effectuées selon la définition habituelle, pour ce que
> j'en sais.
> La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais
> plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As
> Word.Application) et non typée (Dim AppWord As Object).
>
> ----------
> Ange Ounis
> ----------
>
> PMO a écrit :
>
>>Bonjour,
>>
>>1) J'entends par Liaison PRECOCE
>>- Déclaration des variables AVEC spécification
>> du type du composant ActiveX soit:
>> Dim DocWord As Word.Document
>> Dim AppWord As Word.Application
>>VBA reconnaît l'intention et optimise le code compilé
>>
>>2) J'entends par Liaison TARDIVE
>>- Déclaration des variables SANS spécification soit:
>> Dim DocWord As Object
>> Dim AppWord As Object
>>Ce n'est qu'à l'exécution que VBA interprètera l'intention
>>
>>Cordialement.
>
>
>
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
PMO
Bonjour Michel Denis et Ange Ounis,
En fait, je me suis trompé dans la procédure ouvreWord_TARDIVE et tout le monde a raison sauf moi. Il faut lire:
'********** Sub ouvreWord_TARDIVE() Dim DocWord As Object 'Word.Document Dim AppWord As Object 'Word.Application Dim Chemin_prog As String '°°° Correction d'erreur PMO °°° Set AppWord = CreateObject("Word.Application") 'bonne instruction 'Set AppWord = New Word.Application 'et non celle-ci '°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° Chemin_prog = ActiveWorkbook.Path & "" AppWord.ShowMe AppWord.Visible = True Set DocWord = AppWord.Documents.Open _ (Chemin_prog & "tableau.doc", ReadOnly:=True) End Sub '**********
Je vous prie de m'excuser d'avoir causé tant de tracas. J'ai rejoins le clan de ceux qui ont raison, du moins je l'espère Cordialement. -- PMO Patrick Morange
Bonjour Ange Ounis, PMO,
Avec plusieurs jours de retard, je tenais à rectifier une méprise au sujet de "Late Binding vs Early binding"
| Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence | à la librairie des objets de Word _doit_ être cochée pour que le code compile | sans erreur.
Voici un extrait d'un des derniers bouquins publiés sur Excel : (Excellent mais pas nécessairement pour débutant... Je ne sais pas si la traduction française existe !) '----------------------- Professional Excel Development: The Definitive Guide to Developing Applications Using Microsoft® Excel and VBA® By Stephen Bullen, Rob Bovey, John Green
Publisher: Addison Wesley Professional Pub Date: February 01, 2005 ISBN: 0-321-26250-6 Pages: 936 '-----------------------
( Au chapitre III )
Dim objConnection As Object
' It doesn't matter how you create the object, it's still ' late bound due to the As Object variable declaration. Set objConnection = New ADODB.Connection Set objConnection = CreateObject("ADODB.Connection")
Le simple fait de déclarer une variable AS OBJECT est suffisant pour que cette déclaration soit considérée comme "Late Binding".
Et pourquoii ? Tout simplement parce que "Late Binding" vs "Early Binding" fait référence au moment où la procédure identifie l'objet (ses méthodes et propriétés) concerné et où il se situe dans la base de registre.
Lorsqu'un objet n'est pas spécifiquement "typé" dans la déclaration de la variable, l'objet est nécessairement identifié "at the run time" et c'est le fondement même de cette expression "Late Binding" . Dans le cas contraire, lorsque l'objet est bien "typé", la location de l'objet dans la base de registre, l'identification de l'objet ainsi que les méthodes et les propriétés de cet objet utilisées dans la procédure sont faits au moment de la compilation : "Early binding"
Le code soumis par PMO requiert que la référence soit présente pour l'exécution du code mais cela n'a rien à voir avec la définition du paradigme "Late vs Early Binding"
Voilà !
Salutations!
"michdenis" a écrit dans le message de news: ... Bonjour,
Je m'étais contenté de lire les lignes de déclaration des variables, et, c'est vrai qu'une telle ligne de code cause problème si on croit effectuer une liaison prococe : Set AppWord = New Word.Application
;-)
Salutations!
"Ange Ounis" a écrit dans le message de news: Ocuhj5L% Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence à la librairie des objets de Word _doit_ être cochée pour que le code compile sans erreur. C'est facile à vérifier :) Si la référence à la librairie de Word n'est pas cochée, l'instruction New Word.Application de la 2ème procédure provoque l'erreur 'type défini par l'utilisateur non défini', erreur qui ne se produit plus dès que la librairie est cochée...
Les 2 procédures proposées par PMO utilisent donc toutes les 2 des liaisons précoces. Pour une liaison dite tardive, sans référence à la librairie d'objets de Word, il faut utiliser soit GetObject (si on suppose que Word est déjà ouvert) soit CreateObject (pour créer une nouvelle instance de Word).
---------- Ange Ounis ----------
Bonjour Ange Ounis,
| La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais | plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As | Word.Application) et non typée (Dim AppWord As Object).
Le commentaire de PMO est exact.
Dim AppWord As Word.Application Ce type de déclaration requiert le chargement de la référence à "Microsoft Word x.x object librairy" avant l'exécution du code.
Lors de la compilation, Excel a déjà identifié l'activex et où il est situé dans la base de registre. À l'exécution, le code est plus rapide car la "recherche" est déjà faite. De là, l'expression "Liaison précode"
Dim AppWord As Object - Ne requiert pas le chargement de la référence -Lors de la compilation... excel n'est pas en mesure de savoir de quel activex il s'agit et de le localiser... c'est ce qu'il va faire à l'exécution du code ... d'où l'expression : "Liaison tardive" et un temps d'exécution un peu plus lent.
Salutations!
"Ange Ounis" a écrit dans le message de news: %23xwIZEE% Ah, OK. Cependant, ce n'est pas, à ma connaissance, la définition habituelle de ces termes. La liaison précoce est celle qui s'effectue à la compilation du code alors que la liaison tardive s'effectue à l'exécution du code. Même si la "compilation" de VBA n'en est pas vraiment une, les liaisons précoces et tardives sont bien effectuées selon la définition habituelle, pour ce que j'en sais. La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As Word.Application) et non typée (Dim AppWord As Object).
---------- Ange Ounis ----------
Bonjour,
1) J'entends par Liaison PRECOCE - Déclaration des variables AVEC spécification du type du composant ActiveX soit: Dim DocWord As Word.Document Dim AppWord As Word.Application VBA reconnaît l'intention et optimise le code compilé
2) J'entends par Liaison TARDIVE - Déclaration des variables SANS spécification soit: Dim DocWord As Object Dim AppWord As Object Ce n'est qu'à l'exécution que VBA interprètera l'intention
Cordialement.
Bonjour Michel Denis et Ange Ounis,
En fait, je me suis trompé dans la procédure ouvreWord_TARDIVE
et tout le monde a raison sauf moi.
Il faut lire:
'**********
Sub ouvreWord_TARDIVE()
Dim DocWord As Object 'Word.Document
Dim AppWord As Object 'Word.Application
Dim Chemin_prog As String
'°°° Correction d'erreur PMO °°°
Set AppWord = CreateObject("Word.Application") 'bonne instruction
'Set AppWord = New Word.Application 'et non celle-ci
'°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Chemin_prog = ActiveWorkbook.Path & ""
AppWord.ShowMe
AppWord.Visible = True
Set DocWord = AppWord.Documents.Open _
(Chemin_prog & "tableau.doc", ReadOnly:=True)
End Sub
'**********
Je vous prie de m'excuser d'avoir causé tant de tracas.
J'ai rejoins le clan de ceux qui ont raison, du moins je l'espère
Cordialement.
--
PMO
Patrick Morange
Bonjour Ange Ounis, PMO,
Avec plusieurs jours de retard, je tenais à rectifier une méprise
au sujet de "Late Binding vs Early binding"
| Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence
| à la librairie des objets de Word _doit_ être cochée pour que le code compile
| sans erreur.
Voici un extrait d'un des derniers bouquins publiés sur Excel :
(Excellent mais pas nécessairement pour débutant...
Je ne sais pas si la traduction française existe !)
'-----------------------
Professional Excel Development: The Definitive Guide to
Developing Applications Using Microsoft® Excel and VBA®
By Stephen Bullen, Rob Bovey, John Green
Publisher: Addison Wesley Professional
Pub Date: February 01, 2005
ISBN: 0-321-26250-6
Pages: 936
'-----------------------
( Au chapitre III )
Dim objConnection As Object
' It doesn't matter how you create the object, it's still
' late bound due to the As Object variable declaration.
Set objConnection = New ADODB.Connection
Set objConnection = CreateObject("ADODB.Connection")
Le simple fait de déclarer une variable AS OBJECT est suffisant pour que cette déclaration
soit considérée comme "Late Binding".
Et pourquoii ? Tout simplement parce que "Late Binding" vs "Early Binding" fait référence
au moment où la procédure identifie l'objet (ses méthodes et propriétés) concerné
et où il se situe dans la base de registre.
Lorsqu'un objet n'est pas spécifiquement "typé" dans la déclaration de la variable,
l'objet est nécessairement identifié "at the run time" et c'est le fondement même de
cette expression "Late Binding" . Dans le cas contraire, lorsque l'objet est
bien "typé", la location de l'objet dans la base de registre, l'identification de
l'objet ainsi que les méthodes et les propriétés de cet objet utilisées dans la
procédure sont faits au moment de la compilation : "Early binding"
Le code soumis par PMO requiert que la référence soit présente pour l'exécution
du code mais cela n'a rien à voir avec la définition du
paradigme "Late vs Early Binding"
Voilà !
Salutations!
"michdenis" <michdenis@hotmail.com> a écrit dans le message de news: ...
Bonjour,
Je m'étais contenté de lire les lignes de déclaration des variables, et,
c'est vrai qu'une telle ligne de code cause problème si on croit effectuer
une liaison prococe :
Set AppWord = New Word.Application
;-)
Salutations!
"Ange Ounis" <nospam@nospam> a écrit dans le message de news: Ocuhj5L%23FHA.2640@tk2msftngp13.phx.gbl...
Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence
à la librairie des objets de Word _doit_ être cochée pour que le code compile
sans erreur.
C'est facile à vérifier :)
Si la référence à la librairie de Word n'est pas cochée, l'instruction
New Word.Application
de la 2ème procédure provoque l'erreur 'type défini par l'utilisateur non
défini', erreur qui ne se produit plus dès que la librairie est cochée...
Les 2 procédures proposées par PMO utilisent donc toutes les 2 des liaisons
précoces. Pour une liaison dite tardive, sans référence à la librairie d'objets
de Word, il faut utiliser soit GetObject (si on suppose que Word est déjà
ouvert) soit CreateObject (pour créer une nouvelle instance de Word).
----------
Ange Ounis
----------
Bonjour Ange Ounis,
| La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais
| plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As
| Word.Application) et non typée (Dim AppWord As Object).
Le commentaire de PMO est exact.
Dim AppWord As Word.Application
Ce type de déclaration requiert le chargement de la référence à
"Microsoft Word x.x object librairy" avant l'exécution du code.
Lors de la compilation, Excel a déjà identifié l'activex et où il est situé dans
la base de registre. À l'exécution, le code est plus rapide car la "recherche"
est déjà faite. De là, l'expression "Liaison précode"
Dim AppWord As Object
- Ne requiert pas le chargement de la référence
-Lors de la compilation... excel n'est pas en mesure de savoir de quel
activex il s'agit et de le localiser... c'est ce qu'il va faire à l'exécution
du code ... d'où l'expression : "Liaison tardive" et un temps d'exécution
un peu plus lent.
Salutations!
"Ange Ounis" <nospam@nospam> a écrit dans le message de news: %23xwIZEE%23FHA.4012@TK2MSFTNGP10.phx.gbl...
Ah, OK.
Cependant, ce n'est pas, à ma connaissance, la définition habituelle de ces termes.
La liaison précoce est celle qui s'effectue à la compilation du code alors que
la liaison tardive s'effectue à l'exécution du code.
Même si la "compilation" de VBA n'en est pas vraiment une, les liaisons précoces
et tardives sont bien effectuées selon la définition habituelle, pour ce que
j'en sais.
La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais
plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As
Word.Application) et non typée (Dim AppWord As Object).
----------
Ange Ounis
----------
Bonjour,
1) J'entends par Liaison PRECOCE
- Déclaration des variables AVEC spécification
du type du composant ActiveX soit:
Dim DocWord As Word.Document
Dim AppWord As Word.Application
VBA reconnaît l'intention et optimise le code compilé
2) J'entends par Liaison TARDIVE
- Déclaration des variables SANS spécification soit:
Dim DocWord As Object
Dim AppWord As Object
Ce n'est qu'à l'exécution que VBA interprètera l'intention
En fait, je me suis trompé dans la procédure ouvreWord_TARDIVE et tout le monde a raison sauf moi. Il faut lire:
'********** Sub ouvreWord_TARDIVE() Dim DocWord As Object 'Word.Document Dim AppWord As Object 'Word.Application Dim Chemin_prog As String '°°° Correction d'erreur PMO °°° Set AppWord = CreateObject("Word.Application") 'bonne instruction 'Set AppWord = New Word.Application 'et non celle-ci '°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° Chemin_prog = ActiveWorkbook.Path & "" AppWord.ShowMe AppWord.Visible = True Set DocWord = AppWord.Documents.Open _ (Chemin_prog & "tableau.doc", ReadOnly:=True) End Sub '**********
Je vous prie de m'excuser d'avoir causé tant de tracas. J'ai rejoins le clan de ceux qui ont raison, du moins je l'espère Cordialement. -- PMO Patrick Morange
Bonjour Ange Ounis, PMO,
Avec plusieurs jours de retard, je tenais à rectifier une méprise au sujet de "Late Binding vs Early binding"
| Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence | à la librairie des objets de Word _doit_ être cochée pour que le code compile | sans erreur.
Voici un extrait d'un des derniers bouquins publiés sur Excel : (Excellent mais pas nécessairement pour débutant... Je ne sais pas si la traduction française existe !) '----------------------- Professional Excel Development: The Definitive Guide to Developing Applications Using Microsoft® Excel and VBA® By Stephen Bullen, Rob Bovey, John Green
Publisher: Addison Wesley Professional Pub Date: February 01, 2005 ISBN: 0-321-26250-6 Pages: 936 '-----------------------
( Au chapitre III )
Dim objConnection As Object
' It doesn't matter how you create the object, it's still ' late bound due to the As Object variable declaration. Set objConnection = New ADODB.Connection Set objConnection = CreateObject("ADODB.Connection")
Le simple fait de déclarer une variable AS OBJECT est suffisant pour que cette déclaration soit considérée comme "Late Binding".
Et pourquoii ? Tout simplement parce que "Late Binding" vs "Early Binding" fait référence au moment où la procédure identifie l'objet (ses méthodes et propriétés) concerné et où il se situe dans la base de registre.
Lorsqu'un objet n'est pas spécifiquement "typé" dans la déclaration de la variable, l'objet est nécessairement identifié "at the run time" et c'est le fondement même de cette expression "Late Binding" . Dans le cas contraire, lorsque l'objet est bien "typé", la location de l'objet dans la base de registre, l'identification de l'objet ainsi que les méthodes et les propriétés de cet objet utilisées dans la procédure sont faits au moment de la compilation : "Early binding"
Le code soumis par PMO requiert que la référence soit présente pour l'exécution du code mais cela n'a rien à voir avec la définition du paradigme "Late vs Early Binding"
Voilà !
Salutations!
"michdenis" a écrit dans le message de news: ... Bonjour,
Je m'étais contenté de lire les lignes de déclaration des variables, et, c'est vrai qu'une telle ligne de code cause problème si on croit effectuer une liaison prococe : Set AppWord = New Word.Application
;-)
Salutations!
"Ange Ounis" a écrit dans le message de news: Ocuhj5L% Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence à la librairie des objets de Word _doit_ être cochée pour que le code compile sans erreur. C'est facile à vérifier :) Si la référence à la librairie de Word n'est pas cochée, l'instruction New Word.Application de la 2ème procédure provoque l'erreur 'type défini par l'utilisateur non défini', erreur qui ne se produit plus dès que la librairie est cochée...
Les 2 procédures proposées par PMO utilisent donc toutes les 2 des liaisons précoces. Pour une liaison dite tardive, sans référence à la librairie d'objets de Word, il faut utiliser soit GetObject (si on suppose que Word est déjà ouvert) soit CreateObject (pour créer une nouvelle instance de Word).
---------- Ange Ounis ----------
Bonjour Ange Ounis,
| La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais | plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As | Word.Application) et non typée (Dim AppWord As Object).
Le commentaire de PMO est exact.
Dim AppWord As Word.Application Ce type de déclaration requiert le chargement de la référence à "Microsoft Word x.x object librairy" avant l'exécution du code.
Lors de la compilation, Excel a déjà identifié l'activex et où il est situé dans la base de registre. À l'exécution, le code est plus rapide car la "recherche" est déjà faite. De là, l'expression "Liaison précode"
Dim AppWord As Object - Ne requiert pas le chargement de la référence -Lors de la compilation... excel n'est pas en mesure de savoir de quel activex il s'agit et de le localiser... c'est ce qu'il va faire à l'exécution du code ... d'où l'expression : "Liaison tardive" et un temps d'exécution un peu plus lent.
Salutations!
"Ange Ounis" a écrit dans le message de news: %23xwIZEE% Ah, OK. Cependant, ce n'est pas, à ma connaissance, la définition habituelle de ces termes. La liaison précoce est celle qui s'effectue à la compilation du code alors que la liaison tardive s'effectue à l'exécution du code. Même si la "compilation" de VBA n'en est pas vraiment une, les liaisons précoces et tardives sont bien effectuées selon la définition habituelle, pour ce que j'en sais. La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As Word.Application) et non typée (Dim AppWord As Object).
---------- Ange Ounis ----------
Bonjour,
1) J'entends par Liaison PRECOCE - Déclaration des variables AVEC spécification du type du composant ActiveX soit: Dim DocWord As Word.Document Dim AppWord As Word.Application VBA reconnaît l'intention et optimise le code compilé
2) J'entends par Liaison TARDIVE - Déclaration des variables SANS spécification soit: Dim DocWord As Object Dim AppWord As Object Ce n'est qu'à l'exécution que VBA interprètera l'intention
Cordialement.
Michel Gaboly
Bonjour,
Aucun problème ;-))
La raison pour laquelle j'ai défini W comme Object et non comme Word.Ap plication, dans le fichier sur CJoint, est que ma version d'Excel (2004, pour Mac) fait un caprice :
Avec Word.Application, j'obtenais hier le message "Erreur de compilation Type défini par l'utilisateur non défini." alors qu'il me semblait qu'avant-hier cela marchait directement.
J'étais obligé d'aller cocher manuellement dans les références "M icrosoft Word 11.0 Object Library".
Le plus curieux, c'est pour cela que je parle de caprice est qu'après a voir exécuté le code une fois, il était possible de décocher la référence sans conséquence.
En fait c'est comme si la référence ayant été cochée, "quelque chose" a été chargé en mémoire, qui reste disponible tant qu'on ne quittte pas Excel. C'est un comportement que j'ai déjà renco ntré dans d'autres circonstances.
Bonjour Michel Denis et Ange Ounis,
En fait, je me suis trompé dans la procédure ouvreWord_TARDIVE et tout le monde a raison sauf moi. Il faut lire:
'********** Sub ouvreWord_TARDIVE() Dim DocWord As Object 'Word.Document Dim AppWord As Object 'Word.Application Dim Chemin_prog As String '°°° Correction d'erreur PMO °°° Set AppWord = CreateObject("Word.Application") 'bonne instruction 'Set AppWord = New Word.Application 'et non celle-ci '°°°°°°°°°°°°°°°°°°°°°°° °°°°°°°° Chemin_prog = ActiveWorkbook.Path & "" AppWord.ShowMe AppWord.Visible = True Set DocWord = AppWord.Documents.Open _ (Chemin_prog & "tableau.doc", ReadOnly:=True) End Sub '**********
Je vous prie de m'excuser d'avoir causé tant de tracas. J'ai rejoins le clan de ceux qui ont raison, du moins je l'espère Cordialement.
-- Cordialement,
Michel Gaboly www.gaboly.com
Bonjour,
Aucun problème ;-))
La raison pour laquelle j'ai défini W comme Object et non comme Word.Ap plication, dans le fichier sur CJoint, est que ma
version d'Excel (2004, pour Mac) fait un caprice :
Avec Word.Application, j'obtenais hier le message "Erreur de compilation Type défini par l'utilisateur non défini."
alors qu'il me semblait qu'avant-hier cela marchait directement.
J'étais obligé d'aller cocher manuellement dans les références "M icrosoft Word 11.0 Object Library".
Le plus curieux, c'est pour cela que je parle de caprice est qu'après a voir exécuté le code une fois, il était possible
de décocher la référence sans conséquence.
En fait c'est comme si la référence ayant été cochée, "quelque chose" a été chargé en mémoire, qui reste disponible tant
qu'on ne quittte pas Excel. C'est un comportement que j'ai déjà renco ntré dans d'autres circonstances.
Bonjour Michel Denis et Ange Ounis,
En fait, je me suis trompé dans la procédure ouvreWord_TARDIVE
et tout le monde a raison sauf moi.
Il faut lire:
'**********
Sub ouvreWord_TARDIVE()
Dim DocWord As Object 'Word.Document
Dim AppWord As Object 'Word.Application
Dim Chemin_prog As String
'°°° Correction d'erreur PMO °°°
Set AppWord = CreateObject("Word.Application") 'bonne instruction
'Set AppWord = New Word.Application 'et non celle-ci
'°°°°°°°°°°°°°°°°°°°°°°° °°°°°°°°
Chemin_prog = ActiveWorkbook.Path & ""
AppWord.ShowMe
AppWord.Visible = True
Set DocWord = AppWord.Documents.Open _
(Chemin_prog & "tableau.doc", ReadOnly:=True)
End Sub
'**********
Je vous prie de m'excuser d'avoir causé tant de tracas.
J'ai rejoins le clan de ceux qui ont raison, du moins je l'espère
Cordialement.
La raison pour laquelle j'ai défini W comme Object et non comme Word.Ap plication, dans le fichier sur CJoint, est que ma version d'Excel (2004, pour Mac) fait un caprice :
Avec Word.Application, j'obtenais hier le message "Erreur de compilation Type défini par l'utilisateur non défini." alors qu'il me semblait qu'avant-hier cela marchait directement.
J'étais obligé d'aller cocher manuellement dans les références "M icrosoft Word 11.0 Object Library".
Le plus curieux, c'est pour cela que je parle de caprice est qu'après a voir exécuté le code une fois, il était possible de décocher la référence sans conséquence.
En fait c'est comme si la référence ayant été cochée, "quelque chose" a été chargé en mémoire, qui reste disponible tant qu'on ne quittte pas Excel. C'est un comportement que j'ai déjà renco ntré dans d'autres circonstances.
Bonjour Michel Denis et Ange Ounis,
En fait, je me suis trompé dans la procédure ouvreWord_TARDIVE et tout le monde a raison sauf moi. Il faut lire:
'********** Sub ouvreWord_TARDIVE() Dim DocWord As Object 'Word.Document Dim AppWord As Object 'Word.Application Dim Chemin_prog As String '°°° Correction d'erreur PMO °°° Set AppWord = CreateObject("Word.Application") 'bonne instruction 'Set AppWord = New Word.Application 'et non celle-ci '°°°°°°°°°°°°°°°°°°°°°°° °°°°°°°° Chemin_prog = ActiveWorkbook.Path & "" AppWord.ShowMe AppWord.Visible = True Set DocWord = AppWord.Documents.Open _ (Chemin_prog & "tableau.doc", ReadOnly:=True) End Sub '**********
Je vous prie de m'excuser d'avoir causé tant de tracas. J'ai rejoins le clan de ceux qui ont raison, du moins je l'espère Cordialement.
-- Cordialement,
Michel Gaboly www.gaboly.com
michdenis
Bonjour PMO,
Mon commentaire était à l'effet de distinguer le paradigme "relation précoce vs relation tardive" et d'autre part la création d'un objet. Dans la littérature pour le moins sérieuse (voir message précédent) une relation précoce ou tardive n'est pas liée à la façon de créer un objet, mais à la manière dont on "TYPE" une variable dans à la ligne de déclaration en début de procédure : Dim AppWord As Object -> liaison tardive Dim AppWord As Word.Application -> Liaison précoce
Je conçois que la création de l'objet fait de cette manière Set AppWord = New Word.Application requiert la présence de la référence au projet.... mais cela n'en fait pas moins une liaison précoce
On peut tergiverser longtemps sur la meilleure façon de créer un objet, mais il ne faut pas pour autant mélanger les concepts.
Loin de moi, l'idée de déterminer qui avait raison...J'ai tenu à faire cette distinction parce qu'il est courant de se mêler les pinceaux et d'associer (de définir) la présence ou l'absence de la référence à une relation précoce ou tardive... et c'est une conception erronée de ce qu'est le paradigme "Early binding vs Late Binding"
Ce commentaire est venu sur le tard à la lecture de ce bout de code déjà cité dans mon message précédent et émanant d'éminence grise dans le domaine : '------------------------------ ' It doesn't matter how you create the object, it's still ' late bound due to the As Object variable declaration. Set objConnection = New ADODB.Connection Set objConnection = CreateObject("ADODB.Connection") '------------------------------
Voilà !
Salutations!
"PMO" <patrickPOINTmorangeAROBASElapostePOINTnet> a écrit dans le message de news:
Bonjour Michel Denis et Ange Ounis,
En fait, je me suis trompé dans la procédure ouvreWord_TARDIVE et tout le monde a raison sauf moi. Il faut lire:
'********** Sub ouvreWord_TARDIVE() Dim DocWord As Object 'Word.Document Dim AppWord As Object 'Word.Application Dim Chemin_prog As String '°°° Correction d'erreur PMO °°° Set AppWord = CreateObject("Word.Application") 'bonne instruction 'Set AppWord = New Word.Application 'et non celle-ci '°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° Chemin_prog = ActiveWorkbook.Path & "" AppWord.ShowMe AppWord.Visible = True Set DocWord = AppWord.Documents.Open _ (Chemin_prog & "tableau.doc", ReadOnly:=True) End Sub '**********
Je vous prie de m'excuser d'avoir causé tant de tracas. J'ai rejoins le clan de ceux qui ont raison, du moins je l'espère Cordialement. -- PMO Patrick Morange
Bonjour Ange Ounis, PMO,
Avec plusieurs jours de retard, je tenais à rectifier une méprise au sujet de "Late Binding vs Early binding"
| Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence | à la librairie des objets de Word _doit_ être cochée pour que le code compile | sans erreur.
Voici un extrait d'un des derniers bouquins publiés sur Excel : (Excellent mais pas nécessairement pour débutant... Je ne sais pas si la traduction française existe !) '----------------------- Professional Excel Development: The Definitive Guide to Developing Applications Using Microsoft® Excel and VBA® By Stephen Bullen, Rob Bovey, John Green
Publisher: Addison Wesley Professional Pub Date: February 01, 2005 ISBN: 0-321-26250-6 Pages: 936 '-----------------------
( Au chapitre III )
Dim objConnection As Object
' It doesn't matter how you create the object, it's still ' late bound due to the As Object variable declaration. Set objConnection = New ADODB.Connection Set objConnection = CreateObject("ADODB.Connection")
Le simple fait de déclarer une variable AS OBJECT est suffisant pour que cette déclaration soit considérée comme "Late Binding".
Et pourquoii ? Tout simplement parce que "Late Binding" vs "Early Binding" fait référence au moment où la procédure identifie l'objet (ses méthodes et propriétés) concerné et où il se situe dans la base de registre.
Lorsqu'un objet n'est pas spécifiquement "typé" dans la déclaration de la variable, l'objet est nécessairement identifié "at the run time" et c'est le fondement même de cette expression "Late Binding" . Dans le cas contraire, lorsque l'objet est bien "typé", la location de l'objet dans la base de registre, l'identification de l'objet ainsi que les méthodes et les propriétés de cet objet utilisées dans la procédure sont faits au moment de la compilation : "Early binding"
Le code soumis par PMO requiert que la référence soit présente pour l'exécution du code mais cela n'a rien à voir avec la définition du paradigme "Late vs Early Binding"
Voilà !
Salutations!
"michdenis" a écrit dans le message de news: ... Bonjour,
Je m'étais contenté de lire les lignes de déclaration des variables, et, c'est vrai qu'une telle ligne de code cause problème si on croit effectuer une liaison prococe : Set AppWord = New Word.Application
;-)
Salutations!
"Ange Ounis" a écrit dans le message de news: Ocuhj5L% Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence à la librairie des objets de Word _doit_ être cochée pour que le code compile sans erreur. C'est facile à vérifier :) Si la référence à la librairie de Word n'est pas cochée, l'instruction New Word.Application de la 2ème procédure provoque l'erreur 'type défini par l'utilisateur non défini', erreur qui ne se produit plus dès que la librairie est cochée...
Les 2 procédures proposées par PMO utilisent donc toutes les 2 des liaisons précoces. Pour une liaison dite tardive, sans référence à la librairie d'objets de Word, il faut utiliser soit GetObject (si on suppose que Word est déjà ouvert) soit CreateObject (pour créer une nouvelle instance de Word).
---------- Ange Ounis ----------
Bonjour Ange Ounis,
| La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais | plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As | Word.Application) et non typée (Dim AppWord As Object).
Le commentaire de PMO est exact.
Dim AppWord As Word.Application Ce type de déclaration requiert le chargement de la référence à "Microsoft Word x.x object librairy" avant l'exécution du code.
Lors de la compilation, Excel a déjà identifié l'activex et où il est situé dans la base de registre. À l'exécution, le code est plus rapide car la "recherche" est déjà faite. De là, l'expression "Liaison précode"
Dim AppWord As Object - Ne requiert pas le chargement de la référence -Lors de la compilation... excel n'est pas en mesure de savoir de quel activex il s'agit et de le localiser... c'est ce qu'il va faire à l'exécution du code ... d'où l'expression : "Liaison tardive" et un temps d'exécution un peu plus lent.
Salutations!
"Ange Ounis" a écrit dans le message de news: %23xwIZEE% Ah, OK. Cependant, ce n'est pas, à ma connaissance, la définition habituelle de ces termes. La liaison précoce est celle qui s'effectue à la compilation du code alors que la liaison tardive s'effectue à l'exécution du code. Même si la "compilation" de VBA n'en est pas vraiment une, les liaisons précoces et tardives sont bien effectuées selon la définition habituelle, pour ce que j'en sais. La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As Word.Application) et non typée (Dim AppWord As Object).
---------- Ange Ounis ----------
Bonjour,
1) J'entends par Liaison PRECOCE - Déclaration des variables AVEC spécification du type du composant ActiveX soit: Dim DocWord As Word.Document Dim AppWord As Word.Application VBA reconnaît l'intention et optimise le code compilé
2) J'entends par Liaison TARDIVE - Déclaration des variables SANS spécification soit: Dim DocWord As Object Dim AppWord As Object Ce n'est qu'à l'exécution que VBA interprètera l'intention
Cordialement.
Bonjour PMO,
Mon commentaire était à l'effet de distinguer le paradigme
"relation précoce vs relation tardive" et d'autre part la création
d'un objet.
Dans la littérature pour le moins sérieuse (voir message précédent)
une relation précoce ou tardive n'est pas liée à la façon de créer
un objet, mais à la manière dont on "TYPE" une variable dans
à la ligne de déclaration en début de procédure :
Dim AppWord As Object -> liaison tardive
Dim AppWord As Word.Application -> Liaison précoce
Je conçois que la création de l'objet fait de cette manière
Set AppWord = New Word.Application
requiert la présence de la référence au projet.... mais cela n'en
fait pas moins une liaison précoce
On peut tergiverser longtemps sur la meilleure façon de créer un objet, mais
il ne faut pas pour autant mélanger les concepts.
Loin de moi, l'idée de déterminer qui avait raison...J'ai tenu à faire cette
distinction parce qu'il est courant de se mêler les pinceaux
et d'associer (de définir) la présence ou l'absence de la référence à une relation
précoce ou tardive... et c'est une conception erronée de ce qu'est le paradigme
"Early binding vs Late Binding"
Ce commentaire est venu sur le tard à la lecture de ce bout de code déjà cité dans mon
message précédent et émanant d'éminence grise dans le domaine :
'------------------------------
' It doesn't matter how you create the object, it's still
' late bound due to the As Object variable declaration.
Set objConnection = New ADODB.Connection
Set objConnection = CreateObject("ADODB.Connection")
'------------------------------
Voilà !
Salutations!
"PMO" <patrickPOINTmorangeAROBASElapostePOINTnet> a écrit dans le message de news:
D59C679B-6A96-48DD-8F06-52A54417996B@microsoft.com...
Bonjour Michel Denis et Ange Ounis,
En fait, je me suis trompé dans la procédure ouvreWord_TARDIVE
et tout le monde a raison sauf moi.
Il faut lire:
'**********
Sub ouvreWord_TARDIVE()
Dim DocWord As Object 'Word.Document
Dim AppWord As Object 'Word.Application
Dim Chemin_prog As String
'°°° Correction d'erreur PMO °°°
Set AppWord = CreateObject("Word.Application") 'bonne instruction
'Set AppWord = New Word.Application 'et non celle-ci
'°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Chemin_prog = ActiveWorkbook.Path & ""
AppWord.ShowMe
AppWord.Visible = True
Set DocWord = AppWord.Documents.Open _
(Chemin_prog & "tableau.doc", ReadOnly:=True)
End Sub
'**********
Je vous prie de m'excuser d'avoir causé tant de tracas.
J'ai rejoins le clan de ceux qui ont raison, du moins je l'espère
Cordialement.
--
PMO
Patrick Morange
Bonjour Ange Ounis, PMO,
Avec plusieurs jours de retard, je tenais à rectifier une méprise
au sujet de "Late Binding vs Early binding"
| Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence
| à la librairie des objets de Word _doit_ être cochée pour que le code compile
| sans erreur.
Voici un extrait d'un des derniers bouquins publiés sur Excel :
(Excellent mais pas nécessairement pour débutant...
Je ne sais pas si la traduction française existe !)
'-----------------------
Professional Excel Development: The Definitive Guide to
Developing Applications Using Microsoft® Excel and VBA®
By Stephen Bullen, Rob Bovey, John Green
Publisher: Addison Wesley Professional
Pub Date: February 01, 2005
ISBN: 0-321-26250-6
Pages: 936
'-----------------------
( Au chapitre III )
Dim objConnection As Object
' It doesn't matter how you create the object, it's still
' late bound due to the As Object variable declaration.
Set objConnection = New ADODB.Connection
Set objConnection = CreateObject("ADODB.Connection")
Le simple fait de déclarer une variable AS OBJECT est suffisant pour que cette déclaration
soit considérée comme "Late Binding".
Et pourquoii ? Tout simplement parce que "Late Binding" vs "Early Binding" fait référence
au moment où la procédure identifie l'objet (ses méthodes et propriétés) concerné
et où il se situe dans la base de registre.
Lorsqu'un objet n'est pas spécifiquement "typé" dans la déclaration de la variable,
l'objet est nécessairement identifié "at the run time" et c'est le fondement même de
cette expression "Late Binding" . Dans le cas contraire, lorsque l'objet est
bien "typé", la location de l'objet dans la base de registre, l'identification de
l'objet ainsi que les méthodes et les propriétés de cet objet utilisées dans la
procédure sont faits au moment de la compilation : "Early binding"
Le code soumis par PMO requiert que la référence soit présente pour l'exécution
du code mais cela n'a rien à voir avec la définition du
paradigme "Late vs Early Binding"
Voilà !
Salutations!
"michdenis" <michdenis@hotmail.com> a écrit dans le message de news: ...
Bonjour,
Je m'étais contenté de lire les lignes de déclaration des variables, et,
c'est vrai qu'une telle ligne de code cause problème si on croit effectuer
une liaison prococe :
Set AppWord = New Word.Application
;-)
Salutations!
"Ange Ounis" <nospam@nospam> a écrit dans le message de news: Ocuhj5L%23FHA.2640@tk2msftngp13.phx.gbl...
Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence
à la librairie des objets de Word _doit_ être cochée pour que le code compile
sans erreur.
C'est facile à vérifier :)
Si la référence à la librairie de Word n'est pas cochée, l'instruction
New Word.Application
de la 2ème procédure provoque l'erreur 'type défini par l'utilisateur non
défini', erreur qui ne se produit plus dès que la librairie est cochée...
Les 2 procédures proposées par PMO utilisent donc toutes les 2 des liaisons
précoces. Pour une liaison dite tardive, sans référence à la librairie d'objets
de Word, il faut utiliser soit GetObject (si on suppose que Word est déjà
ouvert) soit CreateObject (pour créer une nouvelle instance de Word).
----------
Ange Ounis
----------
Bonjour Ange Ounis,
| La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais
| plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As
| Word.Application) et non typée (Dim AppWord As Object).
Le commentaire de PMO est exact.
Dim AppWord As Word.Application
Ce type de déclaration requiert le chargement de la référence à
"Microsoft Word x.x object librairy" avant l'exécution du code.
Lors de la compilation, Excel a déjà identifié l'activex et où il est situé dans
la base de registre. À l'exécution, le code est plus rapide car la "recherche"
est déjà faite. De là, l'expression "Liaison précode"
Dim AppWord As Object
- Ne requiert pas le chargement de la référence
-Lors de la compilation... excel n'est pas en mesure de savoir de quel
activex il s'agit et de le localiser... c'est ce qu'il va faire à l'exécution
du code ... d'où l'expression : "Liaison tardive" et un temps d'exécution
un peu plus lent.
Salutations!
"Ange Ounis" <nospam@nospam> a écrit dans le message de news: %23xwIZEE%23FHA.4012@TK2MSFTNGP10.phx.gbl...
Ah, OK.
Cependant, ce n'est pas, à ma connaissance, la définition habituelle de ces termes.
La liaison précoce est celle qui s'effectue à la compilation du code alors que
la liaison tardive s'effectue à l'exécution du code.
Même si la "compilation" de VBA n'en est pas vraiment une, les liaisons précoces
et tardives sont bien effectuées selon la définition habituelle, pour ce que
j'en sais.
La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais
plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As
Word.Application) et non typée (Dim AppWord As Object).
----------
Ange Ounis
----------
Bonjour,
1) J'entends par Liaison PRECOCE
- Déclaration des variables AVEC spécification
du type du composant ActiveX soit:
Dim DocWord As Word.Document
Dim AppWord As Word.Application
VBA reconnaît l'intention et optimise le code compilé
2) J'entends par Liaison TARDIVE
- Déclaration des variables SANS spécification soit:
Dim DocWord As Object
Dim AppWord As Object
Ce n'est qu'à l'exécution que VBA interprètera l'intention
Mon commentaire était à l'effet de distinguer le paradigme "relation précoce vs relation tardive" et d'autre part la création d'un objet. Dans la littérature pour le moins sérieuse (voir message précédent) une relation précoce ou tardive n'est pas liée à la façon de créer un objet, mais à la manière dont on "TYPE" une variable dans à la ligne de déclaration en début de procédure : Dim AppWord As Object -> liaison tardive Dim AppWord As Word.Application -> Liaison précoce
Je conçois que la création de l'objet fait de cette manière Set AppWord = New Word.Application requiert la présence de la référence au projet.... mais cela n'en fait pas moins une liaison précoce
On peut tergiverser longtemps sur la meilleure façon de créer un objet, mais il ne faut pas pour autant mélanger les concepts.
Loin de moi, l'idée de déterminer qui avait raison...J'ai tenu à faire cette distinction parce qu'il est courant de se mêler les pinceaux et d'associer (de définir) la présence ou l'absence de la référence à une relation précoce ou tardive... et c'est une conception erronée de ce qu'est le paradigme "Early binding vs Late Binding"
Ce commentaire est venu sur le tard à la lecture de ce bout de code déjà cité dans mon message précédent et émanant d'éminence grise dans le domaine : '------------------------------ ' It doesn't matter how you create the object, it's still ' late bound due to the As Object variable declaration. Set objConnection = New ADODB.Connection Set objConnection = CreateObject("ADODB.Connection") '------------------------------
Voilà !
Salutations!
"PMO" <patrickPOINTmorangeAROBASElapostePOINTnet> a écrit dans le message de news:
Bonjour Michel Denis et Ange Ounis,
En fait, je me suis trompé dans la procédure ouvreWord_TARDIVE et tout le monde a raison sauf moi. Il faut lire:
'********** Sub ouvreWord_TARDIVE() Dim DocWord As Object 'Word.Document Dim AppWord As Object 'Word.Application Dim Chemin_prog As String '°°° Correction d'erreur PMO °°° Set AppWord = CreateObject("Word.Application") 'bonne instruction 'Set AppWord = New Word.Application 'et non celle-ci '°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° Chemin_prog = ActiveWorkbook.Path & "" AppWord.ShowMe AppWord.Visible = True Set DocWord = AppWord.Documents.Open _ (Chemin_prog & "tableau.doc", ReadOnly:=True) End Sub '**********
Je vous prie de m'excuser d'avoir causé tant de tracas. J'ai rejoins le clan de ceux qui ont raison, du moins je l'espère Cordialement. -- PMO Patrick Morange
Bonjour Ange Ounis, PMO,
Avec plusieurs jours de retard, je tenais à rectifier une méprise au sujet de "Late Binding vs Early binding"
| Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence | à la librairie des objets de Word _doit_ être cochée pour que le code compile | sans erreur.
Voici un extrait d'un des derniers bouquins publiés sur Excel : (Excellent mais pas nécessairement pour débutant... Je ne sais pas si la traduction française existe !) '----------------------- Professional Excel Development: The Definitive Guide to Developing Applications Using Microsoft® Excel and VBA® By Stephen Bullen, Rob Bovey, John Green
Publisher: Addison Wesley Professional Pub Date: February 01, 2005 ISBN: 0-321-26250-6 Pages: 936 '-----------------------
( Au chapitre III )
Dim objConnection As Object
' It doesn't matter how you create the object, it's still ' late bound due to the As Object variable declaration. Set objConnection = New ADODB.Connection Set objConnection = CreateObject("ADODB.Connection")
Le simple fait de déclarer une variable AS OBJECT est suffisant pour que cette déclaration soit considérée comme "Late Binding".
Et pourquoii ? Tout simplement parce que "Late Binding" vs "Early Binding" fait référence au moment où la procédure identifie l'objet (ses méthodes et propriétés) concerné et où il se situe dans la base de registre.
Lorsqu'un objet n'est pas spécifiquement "typé" dans la déclaration de la variable, l'objet est nécessairement identifié "at the run time" et c'est le fondement même de cette expression "Late Binding" . Dans le cas contraire, lorsque l'objet est bien "typé", la location de l'objet dans la base de registre, l'identification de l'objet ainsi que les méthodes et les propriétés de cet objet utilisées dans la procédure sont faits au moment de la compilation : "Early binding"
Le code soumis par PMO requiert que la référence soit présente pour l'exécution du code mais cela n'a rien à voir avec la définition du paradigme "Late vs Early Binding"
Voilà !
Salutations!
"michdenis" a écrit dans le message de news: ... Bonjour,
Je m'étais contenté de lire les lignes de déclaration des variables, et, c'est vrai qu'une telle ligne de code cause problème si on croit effectuer une liaison prococe : Set AppWord = New Word.Application
;-)
Salutations!
"Ange Ounis" a écrit dans le message de news: Ocuhj5L% Je suis désolé d'insister mais dans les 2 exemples proposés par PMO la référence à la librairie des objets de Word _doit_ être cochée pour que le code compile sans erreur. C'est facile à vérifier :) Si la référence à la librairie de Word n'est pas cochée, l'instruction New Word.Application de la 2ème procédure provoque l'erreur 'type défini par l'utilisateur non défini', erreur qui ne se produit plus dès que la librairie est cochée...
Les 2 procédures proposées par PMO utilisent donc toutes les 2 des liaisons précoces. Pour une liaison dite tardive, sans référence à la librairie d'objets de Word, il faut utiliser soit GetObject (si on suppose que Word est déjà ouvert) soit CreateObject (pour créer une nouvelle instance de Word).
---------- Ange Ounis ----------
Bonjour Ange Ounis,
| La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais | plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As | Word.Application) et non typée (Dim AppWord As Object).
Le commentaire de PMO est exact.
Dim AppWord As Word.Application Ce type de déclaration requiert le chargement de la référence à "Microsoft Word x.x object librairy" avant l'exécution du code.
Lors de la compilation, Excel a déjà identifié l'activex et où il est situé dans la base de registre. À l'exécution, le code est plus rapide car la "recherche" est déjà faite. De là, l'expression "Liaison précode"
Dim AppWord As Object - Ne requiert pas le chargement de la référence -Lors de la compilation... excel n'est pas en mesure de savoir de quel activex il s'agit et de le localiser... c'est ce qu'il va faire à l'exécution du code ... d'où l'expression : "Liaison tardive" et un temps d'exécution un peu plus lent.
Salutations!
"Ange Ounis" a écrit dans le message de news: %23xwIZEE% Ah, OK. Cependant, ce n'est pas, à ma connaissance, la définition habituelle de ces termes. La liaison précoce est celle qui s'effectue à la compilation du code alors que la liaison tardive s'effectue à l'exécution du code. Même si la "compilation" de VBA n'en est pas vraiment une, les liaisons précoces et tardives sont bien effectuées selon la définition habituelle, pour ce que j'en sais. La distinction que tu fais, AMHA, ne différencie pas 2 types de liaisons, mais plutôt 2 méthodes de déclaration des variables objet : typée (Dim AppWord As Word.Application) et non typée (Dim AppWord As Object).
---------- Ange Ounis ----------
Bonjour,
1) J'entends par Liaison PRECOCE - Déclaration des variables AVEC spécification du type du composant ActiveX soit: Dim DocWord As Word.Document Dim AppWord As Word.Application VBA reconnaît l'intention et optimise le code compilé
2) J'entends par Liaison TARDIVE - Déclaration des variables SANS spécification soit: Dim DocWord As Object Dim AppWord As Object Ce n'est qu'à l'exécution que VBA interprètera l'intention
