Créer/utiliser ses propres librairies

[Domi2]

Bonjour à toutes et à tous,

J'ai fait un certain nombre de recherches, mais c'est un peu le néant, aussi je me permet de lancer à mon tour un petit sondage/débat sur ce sujet.

Créer et utiliser ses propres librairies sous Access

Il est donc possible de créer des fichiers (.mdb ou .mde) avec des fonctions ou procédures fréquemment utilisées et de les référencer dans les applications comme n'importe quelle librairie.

Je n'ai pas trouver de discussions traitant ce sujet, et je m'interroge. Cette possibilité est-elle si peu utilisée pour que personne n'en parle ?

Je serais très intéressé à avoir divers avis sur la question

Domi2

[Arkham46]

Envoyé par Domi2

Il est donc possible de créer des fichiers (.mdb ou .mde) avec des fonctions ou procédures fréquemment utilisées et de les référencer dans les applications comme n'importe quelle librairie.

Je n'ai pas trouver de discussions traitant ce sujet, et je m'interroge. Cette possibilité est-elle si peu utilisée pour que personne n'en parle ?

Effectivement peut-être que peu de gens utilisent leurs propres librairies...

L'astuce à connaître (que j'ai appris en lisant un message de Papy turbo ==> ici), c'est qu'il suffit de mettre ses librairies dans le même répertoire que l'application (c'est tout bête mais j'avais même pas essayé)
Une fois qu'on sait ça, on n'a plus à avoir peur des problèmes de référencement.

[Arkham46]

Ah oui et pis il faut regarder les différences entre :
- CodeDB et CurrentDB
- CodeProject et CurrentProject

Et je crois aussi faire attention aux fonctions de regroupement de domaine du style : DMax, DCount,...
Ces fonctions sont exécutés dans la base de données courante (CurrentDb).
Pour atteindre la base de données d'une librairie depuis son code, il faut faire un recordset sur CodeDB.

[Domi2]

Bonjour Arkham,

c'est qu'il suffit de mettre ses librairies dans le même répertoire que l'application

Ainsi que visiblement, d'autres composants... Voilà une discussion fort intéressante que j'avais manquée (ou je n'en avais pas saisi le grand intérêt sur le moment).

Merci.

Domi2

[Domi2]

Ah oui et pis il faut regarder les différences entre :
- CodeDB et CurrentDB
- CodeProject et CurrentProject

Oui, je n'avais pas pensé à ça. Utilisée dans CodeDB, cela peut faire une sérieuse différence avec une utilisation dans l'application proprement dit.

J'en prend bonne note.

Domi2

[Domi2]

Bonjour,

J'ai fait divers tests.

Et j'ai réussi à transférer la totalité de mes modules "génériques" dans un fichier .mdb externe, sans que cela n'altère le fonctionnement de l'application.

Au final, je pense que c'est une solution assez intéressante.

On a d'un côté une librairie avec toutes les fonctions et procédures régulièrement utilisées dans les applications.

Et dans l'application elle-même, uniquement les fonctions et procédures propres à celle-ci.

Cela me semble assez propre et offre certainement un gain pour la maintenance.

Me reste encore à tester la possibilité d'utiliser des modules de classe dans la librairie, mais pour moi, la question est résolue.

Merci.

Domi2

[francishop]

Bonjour,

Entendez-vous Papy Turbo qui chantonne :" Vous, Qui passez sans me voir, Sans même me dire bonsoir..."
http://access.developpez.com/faq/?pa...uvrFormAutrBDD
Un des Liens ou il nous le préconise depuis des années.
Enfin! On peut arrêter de dire "Merci Mamy Nova" Pour :"Merci Papy Turbo".

Cordialement.

[Papy Turbo]

Merci, francis, de rien surtout. Je reconnais que je ne fais ça que parce que je suis flemmard, et que je n'ai pas envie de réécrire 2 fois le même code !

Pour te répondre, Domi, ça fait effectivement plus de 10 ans que j'utilise et que j'améliore à chaque fois, une librairie qui est liée à toutes mes applications pro (dernière version : 9.02).

Pour aujourd'hui, je me contenterai de faire remarquer le lien actif dans ma signature : dans le cours 'débogage', serge et moi sommes, depuis Juillet, en train de construire l'ébauche d'une librairie qui va nous servir dans les 2 applications concernées, avec reconnection auto des tables, un objet 'application étendue', un journal d'erreurs...

À venir : comment modifier le code dans une librairie, en plein débogage (on peut modifier le code, mais pas l'enregistrer !), etc.

En tout cas, bon courage et plenty fun à tous les flemmards...

[Domi2]

Bonjour Papy Turbo,

Pour aujourd'hui, je me contenterai de faire remarquer le lien actif dans ma signature : dans le cours 'débogage', serge et moi sommes, depuis Juillet, en train de construire l'ébauche d'une librairie qui va nous servir dans les 2 applications concernées, avec reconnection auto des tables, un objet 'application étendue', un journal d'erreurs...

Oh, mais j'en ai pratiquement fait mon livre de chevet...

Je commence à découvrir les nombreuses possibilités offertes par les modules de classes, l'utilisation d'une librairie... Alors, je lis, j'essaie (beaucoup), j'améliore... et je recommence en mieux...

A vrai dire, tout cela me semblait horriblement complexe, mais ça va de mieux en mieux.. Les pièces du puzzle s'assemble gentimment dans mon esprit.

Domi2

[random]

Je suis assez surpris en ce qui concerne l’utilisation des bibliothèques

Il n’est pas nécessaire que celles-ci soient dans la même directory
Il suffit simplement d’ajouter la référence à la base contenant les bibliothèques que celle-ci se trouve ou non dans la même directory

Dés lors toutes le code même celui se rapportant à des formulaires ou états est disponible

Même chose pour excel (attention il faut renommer vba project sinon il est impossible de s’y retrouver)

[Papy Turbo]

Envoyé par random

Je suis assez surpris en ce qui concerne l’utilisation des bibliothèques

Il n’est pas nécessaire que celles-ci soient dans la même directory
Il suffit simplement d’ajouter la référence à la base contenant les bibliothèques que celle-ci se trouve ou non dans la même directory

Vrai.
C'est juste tellement plus simple de
- développer l'application, chez moi, dans un dossier C:\Sources\Client\Projet...
- puis de la déployer par une simple copie (aucun setup.exe) dans n'importe quel dossier, chez le client.
Donc, avantage au déploiement, du simple fait qu'Access rétablit toutes les références, après un déplacement, changement de nom de dossier..., si les composants (bibol, DLL, OLB...) sont dans le même dossier que l'appli.

Cette remarque concernait les problèmes de références à d'autres objets (DLL, OLB...) et, en particulier :
Comment je fais pour développer une application OLE, d'Access vers Excel, par exemple, alors que
- je dispose d'Office 2007
- mon client n'a qu'Office 2000
???
Réponse : je colle, dans mon dossier Source (là où je développe l'appli), une copie de Excel9.OLB. C'est à cet OLB que j'établis ma référence, ce qui me permet de n'avoir que des commandes Excel compatibles avec excel 2000.

P.S. : ça marche aussi bien avec les DLLs, comme celle d'Arham (voir son site) : MouseWheelNoReg.dll, que j'utilise maintenant partout (doit y en avoir au moins 5 à 10 copies sur mon disque !)
Aucun problème de déploiement, aucun problème de versions des DLLs : que celui qui n'a jamais écrasé une DLL récente avec une plus ancienne, dans System32, me jette le premier bug !

[random]

ok je comprends tes soucis que je n'ai pas

utilisateur isolé mes fichiers sont classés par nature et il n'est pas pensable de
mettre une copie des bibliothèques dans chaque répertoire

de plus je suis assuré de disposer en permanence des mêmes versions d'excel et d'access que moi