base access en exe

J'adore ce genre de débats !
:))

Il utilise d'ailleurs (va jeter un oeil dans les références...) le VBA
comme

bibliothèque principale ;)
Pour ton information, VB6 n'utilise pas du tout la même bibliothèque

qu'Access, même si le nom est identique.
VB6 : MSVBVM60.DLL (Microsoft Visual Basic Virtual Machine 6.0) qui se
trouve dans %WINDIR%SYSTEM32
Access : VBA332.DLL qui se trouve dans %Program Files%Fichiers
communsMicrosoft SharedVBA

La bibliothèque VBA se trouvant dans Microsoft Shared est partagée par
toutes les applications Office.
VB6 ne connait pas cette bibliothèque.
Il y a erreur dans ta connaissance ! Supprime cette bibliothèque, VB6
n'en
sera pas affecté.

Non non ! :)))
Je fais très bien la différence entre les bibliothèques !
Pas de soucis !
Ces informations seront cependant très importantes pour notre ami qui veut
faire des EXE.
Par contre, tu seras certainement d'accord avec moi, bon an mal an, on
retrouve, à quelques rares exceptions près, l'ensemble des modules, classes,
etc. de l'une comme de l'autre des bibliothèques, et surtout ! Le principe,
je veux dire, la structure du langage objet, les structures de procédures,
de tests, de boucles, d'énumérations, les déclarations, etc. etc. etc.
tout cela reste commun ! (même si la signature de certaines procédure
évènementielles peut varier légèrement)
C'est dans ce sens là que j'abordais le principe de "Il utilise ... le VBA
comme bibliothèque"

Rien ne t'empèche d'ajouter les bibliothèques Access, DAO, ADO, etc. etc.
DAO et ADO Ok ! Pas Access, cela impose la présence de celui-ci sur la

machine cible.
A n'utiliser qu'en cas de besoin d'Access et détection de sa présence au
préalable.
Je suis d'accord !

Mais rien ne t'empèche, dans ce cas, de mettre la bibliothèque Access !
J'en reste donc aux principes fondamentaux : tu peux avoir les même
bibliothèques dans un projet VB et dans un projet VBA

Maintenant, il est vrai que si tu as parfaitement compris le contexte
dans
lequel tu évolues, le passage d'Access à VB ne pose AUCUN problème, en ce
qui concerne le code.
A moitié d'accord. Transposer un code VBA Access en VB n'est pas chose

simple surtout si le code VBA est accompagné de multiples DoCmd, ce qui
est
le cas de toute manière. Et même si l'on connait parfaitement les 2
contextes, la mission est parfois très longue pour retranscrire en VB6 ce
qui est faisable par une seule commande en VBA. Je pense par exemple la
prorpiété Dirty d'un formulaire. Chose "chiante', si j'ose le dire, à
faire
en VB6.
Je partage ton point de vue.

Il faut dire que, dans la mesure du possible, j'essaie d'éviter d'utiliser
le DoCmd qui est très pratique, mais qui ressemble fortement à une
aberration du langage.
Par conséquent, j'ai plutôt tendance, dans mes programmes à faire du :

Dim f as Form
Set f=New form_MonForm
f.caption="Tralalère"
f.visible=True
...
Set f=nothing

et là, tu vois, la plupart des DoCmd disparaissent, et donc, la
transformation du Code VBA en code VB est hautement simplifiée.

Tu comprendras qu'un copier-coller ne pourrait suffir ;O)
Vu que même les applications sensées faire la migration génèrent souvent

plus de travail que de tout reprendre à 0, cela me parait assez évident.
Surtout si c'est développé comme cela ! (mouarf ! c'était une boutade pour
te charrier :) )

Ceci dit, Access reste un outil formidable aux capacités suprenantes.
Et malheureusement très mal connu de ses détracteurs.
Et bien, tu vois qu'on en trouve des points sur lesquels on est totalement

d'accord ;) (hi hi hi)

Maxence

Salut !

J'adore ce genre de débats !
:))

Quand ca reste courtois dans le pur respect de l'autre...

Non non ! :)))
Je fais très bien la différence entre les bibliothèques !
Pas de soucis !
Ces informations seront cependant très importantes pour notre ami qui veut
faire des EXE.
Par contre, tu seras certainement d'accord avec moi, bon an mal an, on
retrouve, à quelques rares exceptions près, l'ensemble des modules,
classes,

etc. de l'une comme de l'autre des bibliothèques, et surtout ! Le
principe,

je veux dire, la structure du langage objet, les structures de procédures,
de tests, de boucles, d'énumérations, les déclarations, etc. etc. etc.
tout cela reste commun ! (même si la signature de certaines procédure
évènementielles peut varier légèrement)
C'est dans ce sens là que j'abordais le principe de "Il utilise ... le VBA
comme bibliothèque"

Ok avec toi pour ce qui est des fondements de VB.
Le langage fondamental reste le même pour VB et VBA.
Mais il est inexact de dire qu'ils partagent les mêmes bibliothèques
comportant les définitions du langage.

Je suis d'accord !
Mais rien ne t'empèche, dans ce cas, de mettre la bibliothèque Access !
J'en reste donc aux principes fondamentaux : tu peux avoir les même
bibliothèques dans un projet VB et dans un projet VBA

La possibilité existe mais en tant que programmeur averti, je ne ferai
jamais cela sauf si l'on me met le couteau sous la gorge ;O)
Si l'application doit piloter Access, il va de soi que l'on peut référencer
la bilbiothèque. Mais en ce qui me concerne, je fais du late-binding, et
c'est à l'exécution que je traite les erreurs. Si Access est absent, on
traite l'erreur en conséquence, mais je ne trimbale pas les bibliothèques
d'Access. Déjà qu'il faut trimbaler celles de VB...

Je partage ton point de vue.
Il faut dire que, dans la mesure du possible, j'essaie d'éviter d'utiliser
le DoCmd qui est très pratique, mais qui ressemble fortement à une
aberration du langage.
Par conséquent, j'ai plutôt tendance, dans mes programmes à faire du :

Dim f as Form
Set f=New form_MonForm
f.caption="Tralalère"
f.visible=True
...
Set f=nothing

et là, tu vois, la plupart des DoCmd disparaissent, et donc, la
transformation du Code VBA en code VB est hautement simplifiée.

Je ne crois pas qu'il soit possible d'éviter la puissance de DoCmd. Et ton
exemple ne démontre aboslument pas le contraire.
Un formulaire en Access se pilote plus ou moins de la même manière qu'en VB.
Me.caption et Me.visible fonctionnent...

Le fait qu'un formulaire en VB ne peut être lié à une source de données, ca
change beaucoup de choses.
Les objets en Access sont intimement liès à leurs source de données. Va
dans l'explorateur d'objets et regarde toutes les possibilités de DoCmd.
Difficile de s'en passer ou alors, tu aimes réinventer la roue ou encore
mieux, tu penses d'amblée à une migration vers VB ;O)

Vu que même les applications sensées faire la migration génèrent souvent
plus de travail que de tout reprendre à 0, cela me parait assez évident.
Surtout si c'est développé comme cela ! (mouarf ! c'était une boutade pour
te charrier :) )

Les assistants de migration sont souvent efficaces pour de petits
développements pas trop compliqués. Dès lors que le code devient
conséquent, faut plus trop rêver. Microsoft est assez mauvais dans ses
assistants.
Et en plus il me charrie....

Et bien, tu vois qu'on en trouve des points sur lesquels on est totalement
d'accord ;) (hi hi hi)
De toute manière, nos avis se recoupent. Il n'y a pas vraiment d'opposition

dans ce que l'on dit.

Guy


----- Original Message -----
From: "Maxence HUBICHE [MVP Access]" <mh.webmaster@club-internet.fr>
Newsgroups: microsoft.public.fr.access
Sent: Sunday, January 23, 2005 1:59 PM
Subject: Re: base access en exe

J'adore ce genre de débats !
:))

Il utilise d'ailleurs (va jeter un oeil dans les références...) le VBA
comme

bibliothèque principale ;)
Pour ton information, VB6 n'utilise pas du tout la même bibliothèque

qu'Access, même si le nom est identique.
VB6 : MSVBVM60.DLL (Microsoft Visual Basic Virtual Machine 6.0) qui se
trouve dans %WINDIR%SYSTEM32
Access : VBA332.DLL qui se trouve dans %Program Files%Fichiers
communsMicrosoft SharedVBA

La bibliothèque VBA se trouvant dans Microsoft Shared est partagée par
toutes les applications Office.
VB6 ne connait pas cette bibliothèque.
Il y a erreur dans ta connaissance ! Supprime cette bibliothèque, VB6
n'en
sera pas affecté.

Non non ! :)))
Je fais très bien la différence entre les bibliothèques !
Pas de soucis !
Ces informations seront cependant très importantes pour notre ami qui veut
faire des EXE.
Par contre, tu seras certainement d'accord avec moi, bon an mal an, on
retrouve, à quelques rares exceptions près, l'ensemble des modules,
classes,

etc. de l'une comme de l'autre des bibliothèques, et surtout ! Le
principe,

je veux dire, la structure du langage objet, les structures de procédures,
de tests, de boucles, d'énumérations, les déclarations, etc. etc. etc.
tout cela reste commun ! (même si la signature de certaines procédure
évènementielles peut varier légèrement)
C'est dans ce sens là que j'abordais le principe de "Il utilise ... le VBA
comme bibliothèque"

Rien ne t'empèche d'ajouter les bibliothèques Access, DAO, ADO, etc.
etc.

DAO et ADO Ok ! Pas Access, cela impose la présence de celui-ci sur la
machine cible.
A n'utiliser qu'en cas de besoin d'Access et détection de sa présence au
préalable.
Je suis d'accord !

Mais rien ne t'empèche, dans ce cas, de mettre la bibliothèque Access !
J'en reste donc aux principes fondamentaux : tu peux avoir les même
bibliothèques dans un projet VB et dans un projet VBA

Maintenant, il est vrai que si tu as parfaitement compris le contexte
dans
lequel tu évolues, le passage d'Access à VB ne pose AUCUN problème, en
ce

qui concerne le code.
A moitié d'accord. Transposer un code VBA Access en VB n'est pas chose

simple surtout si le code VBA est accompagné de multiples DoCmd, ce qui
est
le cas de toute manière. Et même si l'on connait parfaitement les 2
contextes, la mission est parfois très longue pour retranscrire en VB6
ce

qui est faisable par une seule commande en VBA. Je pense par exemple la
prorpiété Dirty d'un formulaire. Chose "chiante', si j'ose le dire, à
faire
en VB6.
Je partage ton point de vue.

Il faut dire que, dans la mesure du possible, j'essaie d'éviter d'utiliser
le DoCmd qui est très pratique, mais qui ressemble fortement à une
aberration du langage.
Par conséquent, j'ai plutôt tendance, dans mes programmes à faire du :

Dim f as Form
Set f=New form_MonForm
f.caption="Tralalère"
f.visible=True
...
Set f=nothing

et là, tu vois, la plupart des DoCmd disparaissent, et donc, la
transformation du Code VBA en code VB est hautement simplifiée.

Tu comprendras qu'un copier-coller ne pourrait suffir ;O)
Vu que même les applications sensées faire la migration génèrent souvent

plus de travail que de tout reprendre à 0, cela me parait assez évident.
Surtout si c'est développé comme cela ! (mouarf ! c'était une boutade pour
te charrier :) )

Ceci dit, Access reste un outil formidable aux capacités suprenantes.
Et malheureusement très mal connu de ses détracteurs.
Et bien, tu vois qu'on en trouve des points sur lesquels on est totalement

d'accord ;) (hi hi hi)

Maxence


"Maxence HUBICHE [MVP Access]" <mh.webmaster@club-internet.fr> a écrit dans

le message de news:O3TljtUAFHA.3472@TK2MSFTNGP14.phx.gbl...

J'adore ce genre de débats !
:))

Il utilise d'ailleurs (va jeter un oeil dans les références...) le VBA
comme

bibliothèque principale ;)
Pour ton information, VB6 n'utilise pas du tout la même bibliothèque

qu'Access, même si le nom est identique.
VB6 : MSVBVM60.DLL (Microsoft Visual Basic Virtual Machine 6.0) qui se
trouve dans %WINDIR%SYSTEM32
Access : VBA332.DLL qui se trouve dans %Program Files%Fichiers
communsMicrosoft SharedVBA

La bibliothèque VBA se trouvant dans Microsoft Shared est partagée par
toutes les applications Office.
VB6 ne connait pas cette bibliothèque.
Il y a erreur dans ta connaissance ! Supprime cette bibliothèque, VB6
n'en
sera pas affecté.

Non non ! :)))
Je fais très bien la différence entre les bibliothèques !
Pas de soucis !
Ces informations seront cependant très importantes pour notre ami qui veut
faire des EXE.
Par contre, tu seras certainement d'accord avec moi, bon an mal an, on
retrouve, à quelques rares exceptions près, l'ensemble des modules,
classes,

etc. de l'une comme de l'autre des bibliothèques, et surtout ! Le
principe,

je veux dire, la structure du langage objet, les structures de procédures,
de tests, de boucles, d'énumérations, les déclarations, etc. etc. etc.
tout cela reste commun ! (même si la signature de certaines procédure
évènementielles peut varier légèrement)
C'est dans ce sens là que j'abordais le principe de "Il utilise ... le VBA
comme bibliothèque"

Rien ne t'empèche d'ajouter les bibliothèques Access, DAO, ADO, etc.
etc.

DAO et ADO Ok ! Pas Access, cela impose la présence de celui-ci sur la
machine cible.
A n'utiliser qu'en cas de besoin d'Access et détection de sa présence au
préalable.
Je suis d'accord !

Mais rien ne t'empèche, dans ce cas, de mettre la bibliothèque Access !
J'en reste donc aux principes fondamentaux : tu peux avoir les même
bibliothèques dans un projet VB et dans un projet VBA

Maintenant, il est vrai que si tu as parfaitement compris le contexte
dans
lequel tu évolues, le passage d'Access à VB ne pose AUCUN problème, en
ce

qui concerne le code.
A moitié d'accord. Transposer un code VBA Access en VB n'est pas chose

simple surtout si le code VBA est accompagné de multiples DoCmd, ce qui
est
le cas de toute manière. Et même si l'on connait parfaitement les 2
contextes, la mission est parfois très longue pour retranscrire en VB6
ce

qui est faisable par une seule commande en VBA. Je pense par exemple la
prorpiété Dirty d'un formulaire. Chose "chiante', si j'ose le dire, à
faire
en VB6.
Je partage ton point de vue.

Il faut dire que, dans la mesure du possible, j'essaie d'éviter d'utiliser
le DoCmd qui est très pratique, mais qui ressemble fortement à une
aberration du langage.
Par conséquent, j'ai plutôt tendance, dans mes programmes à faire du :

Dim f as Form
Set f=New form_MonForm
f.caption="Tralalère"
f.visible=True
...
Set f=nothing

et là, tu vois, la plupart des DoCmd disparaissent, et donc, la
transformation du Code VBA en code VB est hautement simplifiée.

Tu comprendras qu'un copier-coller ne pourrait suffir ;O)
Vu que même les applications sensées faire la migration génèrent souvent

plus de travail que de tout reprendre à 0, cela me parait assez évident.
Surtout si c'est développé comme cela ! (mouarf ! c'était une boutade pour
te charrier :) )

Ceci dit, Access reste un outil formidable aux capacités suprenantes.
Et malheureusement très mal connu de ses détracteurs.
Et bien, tu vois qu'on en trouve des points sur lesquels on est totalement

d'accord ;) (hi hi hi)

Maxence