[VB6] Déplacement fichier TLBRésolu

Question

Salut
Je viens de me prendre la tête avec un fichier TLB.
Comme j'utilise ce fichier dans plusieurs applications, j'ai sorti le fichier du répertoire de l'application pour le déplacer dans le répertoire adéquat (comme Sheila), à savoir  %System32% (chose que j'aurai dû faire dès le début).
Après ce déplacement, retour dans une application + Projet/Référence pour redéclarer le TLB.
Là surprise, bien que je parcourre le disque et pointe le nouvel emplacement, VB6 n'en tiens pas compte et l'élément n'est pas 'coché' dans la liste. En fait, dans la liste, mon fichier est toujours référencé à l'ancien emplacement.

En fait, ces fichiers TLB (utilisé uniquement en mode développement) sont 'enregistrés' dans la base de registres (BdR).
Il m'a donc suffit de modifier le répertoire dans la BdR pour que VB6 en tienne compte.

La question :
Les fichiers TLB ne s'enregistrent pas avec RegSvr32 (normal).
Alors, comment font-ils pour se retrouver dans la BdR ? Je suppose que VB6 s'en occupe quand on lui montre pour la première fois.
C'est con, mais une fois enregistré, on n'a pas d'autre choix que de bidouiller manuellement la BdR (j'aime pas trop beaucoup ça). Une fois qu'on le sait, ça va, mais bon ... 
Une idée de l'outil à utiliser ?

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

cs_rt15 · Accepted Answer

salut,

Il me semblait avoir entendu parlé d'un utilitaire (de M$) qui le faisait (Genre regtypelib), mais je le retrouve pas.

Sinon, il y a ce snippet EBArtSoft qui nous pond toujours des trucs d'on ne sais ou...

fiko81 · Answer

Ce post m'interresse car j'ai eu les mêmes soucis pour des dll et OCX. Je m'explique : J'ai développé une application modulaire qui englobe 8 sous-produits. J'avais un répertoire rassemblant mes sources dans lequel j'avais distingué 3 sous-répertoires : - un pour les OCX (car ils sont commun à mes 8 modules) - un pour les DLL (Idem) - un pour les modules. (avec 8 sous-répertoires) Avec VB6, j'ai instancié ces références et composants en utilisant l'option parcourir de la fenêtre VB. Pour chacun des module, j'étais en mesure de les utiliser sans trop de soucis. Jusque là donc, pas de problème. Le premier problème que j'avais était qu'à chaque fois que j'avais à recompiler une DLL ou un OCX pour une raison ou pour une autre, VB6 était incapable de les reconnaitre sans que je repasse par l'explorateur. En fait, les codes de référencement (qui ressemblent à peu près à ça : 6B7E6392-850A-101B-AFC0-4210102A8DA7 par exemple) changent à chaque recompilation. J'ai trouvé comment contourner ce problème. En fait il suffit de récuperer ce code de réferencement et d'éditer avec un bloc note les .vdp de chacun des modules pour en changer les codes. Et là je n'avais plus besoin de re-charger les composants et références dans chacun de mes modules au lancement. (un petite routine vb est facile à développer pour réaliser cette modification automatiquement) La première conclusion que j'ai pu tirer de cette manipulation est que VB génère lui même ces codes et qu'il en a besoin pour son propre fonctionnement. Le deuxième problème que j'ai eu est plus délicat à expliquer. Quand j'ai eu à développer ces modules, j'ai fait appel à un prestataire de service en développement VB pour m'aider. Pour faciliter le développement, chancun travaillait sur un module mais comme je l'expliquais, quelques DLL, OCX ainsi que quelques modules de classe étaient en commun. La solution que nous avons adoptée était de mettre le code source sur le réseau et travailler sur le même support à partir de deux PC et donc deux licences VB. Voici donc le fameux souci : Sur mon PC, il arrivait que je sois obligé de modifier une DLL ou OCX. Je demandais donc au collègue de couper toutes ces fenêtres VB pour pouvoir compiler. Une fois la manip faite, je lançais la petite routine pour modifier le code de réferencement dans chacun de projet vb. Ensuite, chacun se remet à travailler sur son module : pour moi aucun problème VB ne me mettait aucun message d'erreur et je pouvais alors enchainer sur mon dev. Par contre, le collègue se retrouvais avec un message d'erreur lui indiquant qu'il n'arrivait pas à charger le composant que j'avais modifié. Encore plus fort, on était incapable de le charger directement par l'explorateur et ce même dans un nouveau projet vierge. Là je sèche. J'ai envie de dire que chacun de ces codes de référencement sont propre à une machine aussi... Tout cela à duré pendant la période où l'on travaillait à deux sur le dev. Enfin le dernier problème est que j'ai voulut changer de répertoire mes DLL et OCX et là c'est le drame. J'ai re-charger par l'explorateur sous VB tout mes composants et DLL. Je les retrouvais maintenant deux fois dans la liste et impossible de supprimer les doublons. Le pire dans tout ça est que une fois sur deux, VB m'affichait un message d'erreur me disant qu'il ne retrouve pas les DLL et OCX quand je chargeais une de mes modules pour travailler. Ce qui m'embète le plus dans tout ça c'est que la seule solution à ce problème à été de formater le PC et de repartir sur une nouvelle bdr. Jack : ma conclusion perso est que la bdr seule n'est pas la source de tes problèmes à mon avis vu les soucis que j'ai eu moi. Je pense que VB grignote quelque chose de son coté... La preuve : comment expliquer que vb affiche deux fois voir pour moi 7 fois le même composant (qui porte le même non et même version) alors qu'il est présent qu'une seule fois dans la bdr ? Voilà mes mesaventures. J'espère que j'ai été clair dans ce long discours et que quelqu'un me dise comment faire dans ces configurations. Fiko ;-) La reponse vous convient pensez > Accepter <

cs_Jack · Answer

Salut
Oui, VB6 n'est pas adapté au développement multipostes.
Pour les OCX et DLL, la précaustion à prendre est de bien les désenregistrer avant de les déplacer, puis de les réenregistrer sur leur nouveau répertoire, sinon, la BdR garde la trace de l'ancienne et ... c'est le bordel.
pour te faciliter la vie, utilise ce gadget qui insère un Register/UnRegister dans le click-doit sur les fichiers appropriés (je ne me souviens plus d'où il vient, désolé) : à mettre dans un fichier.REG puis double-cliquer dessus
REGEDIT4
;  This adds the ability to Right-Click on a .dll or .ocx
;  and get the Register / UnRegister options.
; ==========
; .DLL files
; ==========
[HKEY_CLASSES_ROOT\.dll]
"Content Type"="application/x-msdownload"
@="dllfile"
[HKEY_CLASSES_ROOT\dllfile]
@="Application Extension"
[HKEY_CLASSES_ROOT\dllfile\Shell\Register\command]
@="regsvr32.exe "%1""
[HKEY_CLASSES_ROOT\dllfile\Shell\UnRegister\command]
@="regsvr32.exe /u "%1""
; ==========
; .OCX files
; ==========
[HKEY_CLASSES_ROOT\.ocx]
@="ocxfile"
[HKEY_CLASSES_ROOT\ocxfile]
@="OCX"
[HKEY_CLASSES_ROOT\ocxfile\Shell\Register\command]
@="regsvr32.exe "%1""
[HKEY_CLASSES_ROOT\ocxfile\Shell\UnRegister\command]
@="regsvr32.exe /u "%1""
; End

Mais, c'est vrai que VB6 a des problèmes organisationnel, notamment pour les AddIn qu'il démonte difficilement.

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

cs_rt15 · Answer

A quelques secondes près je ne double postait pas...
L'utilistaire s'appel regtlib.

cs_rt15 · Answer

Bon bah triple post car j'ai survolé un peu vite le message de fiko81...

fiko81-> Pour ton premier problème, il faut juste cliquer une case à cocher !!!
Moi aussi je gallerais, et c'est Darksid qui m'a filer l'astuce.

cf la description de ce source.

Bon, j'arrête le flood.

cs_Jack · Answer

Merci rt15
Je n'avais pas pensé à aller fouiner du côté des snippets.

EBArtSoft nous sauvera tous !

[VB6] Déplacement fichier TLB

6 réponses

Votre réponse

Discussions similaires