Discussion :

[chtimi_soft]

Bonjour à tous,

je suis appelé à faire migrer une grosse appli écrite en Access 2003/ Win XP vers Access 2010/ Win 7. Cette appli utilise mscal.ocx et owc11.dll

Je dois modifier l'appli pour se désengager de ces 2 références manquantes dans 2010. (l'appli fait 400 tables dans une dizaine de bases différentes, 300 formulaires et sous formulaires, 200 modules, +de 200 requêtes..)

L'appli a été développé par une personne qui a quitté la boite depuis un moment.

La solution de simplicité qui consiste à installer les 2 contrôles dans l'environnement 2010/Win 7 est bannie par la direction.

Pour tracer l'usage de mscal.ocx (qui n'offre qu'un seul controle : Calendar), c'était facile : j'ai fait une recherche texte sur "calendar" et j'ai identifié tout les formulaires qui font appel à ce contrôle pour le modifier par ce qui est préconisé par microsoft : Dtpicker

Par contre pour OWC11.dll je suis confronté à un autre problème: Cette dll embarque plusieurs dizaines de contrôles que je ne me vois pas faire une recherche un par un comme je l'ai fait pour "Calendar".

Si je m'abuse, ma question serait : comment tracer l'usage d'une dll dans le code source d'une application ACCESS (et d'une façon générale office) ?

Merci pour vos idées ou vos recommandations de piste à creuser si quelqu'un parmi vous a été confronté à un problème semblable.

[marot_r]

Une méthode pas 100% fiable consiste à supprimer la référence dans une copie de l'application initiale et de lancer la compilation.

Chaque fois que tu auras une erreur ce devrait être sur un élément de la librairie concernée.

Attention, il me semble que OWC11.dll sert aux tableaux croisés dynamiques de Access qui ne sont plus supportés à partir de Access 2010.

A+

[chtimi_soft]

Merci marot_r pour ta réponse.

Justement, c'est ce que j'ai commencé à faire.

Et je ne pense pas que c'est seulement les TCD qui sont en cause et je crois que ça va plus loin (il faut que je vérifie ce point).

Une méthode pas 100% fiable
A+

Mais pourquoi tu as des doutes sur la fiabilité ?

Moi j'ai des doutes . (point) parce que je ne suis pas expert Access

Est ce qu'il y aura des loups cachés quelques part ?

[marot_r]

Si la variable associée à la DLL ou l'OCX est définie dans le code comme as Object le compilateur ne détectera rien et c'est seulement a l'exécution que cela va casser.

Pour trouver ces cas tu peux faire une recherche sur CreateObject dans le code.

A+

[LedZeppII]

Bonjour,

J'ai créé une bdd pour rechercher dans une base de données Access tous les contrôles ActiveX des formulaires de cette base.
Si mon code en trouve ils seront listés dans la zone de liste du formulaire.
Nom du formulaire | Nom contrôle | Classe du contrôle

Le nom de la classe peut t'aider à trouver si c'est un objet OCW.
Par exemple OCW11.Spreadsheet.11

Mon code ouvre la base en lecture seule donc pas de risque d'endommager la base examinée.
Par précaution tu peux faire une copie de la base à examiner, et faire examiner cette copie par mon code.

J'espère qu'il n'y a pas trop de bugs dan mon code

A+

[marot_r]

Cool j'en aurai besoin quand nous migrerons vers Access 2013.

Merci LedZeppII :-).

A+