"Type défini par l'utilisateur non défini" == bug bizarre

Question

Violent Ken

 


Salut à tous, j'ai un problème un peu bizarre dans mon projet... 


Tout d'abord, je vous décrit l'achitecture de mon projet. Il est composé de :
- un projet principal qui contient lui même 8 sous-projets (qui sont tous des OCX)
- deux projets secondaires qui contiennent eux aussi 4 ou 5 sous-projets chacun (ces sous-projets sont les même OCX et une DLL)


Tout çà est inclus dans un seul projet *.vbg (projet groupe).




En fait, j'ai formaté mon disque dur et j'ai récupéré le dossier de mon projet tel qu'il était précédemment sur mon ancienne partition.


Donc je me retrouve avec les même fichiers que ceux qui étaient sur mon ancienne parition. La différence avec mon ancienne partition, c'est que les fichiers OCX ne sont pas enregistrés comme ils l'étaient avant. Donc j'ai recompilé tous mes projets OCX et DLL et je les ai enregistrés (les OCX et la DLL) à l'aide de regsv32.


Voilà pour le contexte. Maintenant le problème :




Donc je lance mon fichier *.vbg et toutes les form, classes, modules et usercontrol de tous les sous projet s'ouvrent normalement. Je recompile tous les projets : pas de problème, çà marche au poil.


Mais voilà que je ferme VB6 et que je le relance. Je lance avec F5 (sans avoir compilé après la réouverture du logiciel) et j'ai un bug ==> "Type défini par l'utilisateur non défini".
Le bug arrive sur cette ligne (sur ItemElement) :
Private Sub HW_MouseDown(Button As Integer, Shift As Integer, x As Single, _
    y As Single, Item As ItemElement)


HW est un usercontrol perso (c'est un des 8 sous-projets, il est appelé HewViewer_OCX), et ItemElement est un objet défini par une classe contenue dans cet UserControl.
De manière plus générale, ce sont tous les objets passés en paramètres et qui sont définis dans les sous-projets qui ne sont pas "reconnus".


Pour éviter ce bug, deux parades  :
- soit je fait HewViewer_OCX.ItemElement (et je dois faire de même pour des centaines d'autres lignes de code, je dois préciser "d'où provient l'objet" avec NOM_PROJET_OCX.Objet)
- soit je compile après avoir ouvert VB6, et ensuite plus de bug quand je lance avec F5 !!


 



Donc je dois, à chaque fois que j'ouvre VB6, compiler mon projet principal pour que je puisse ensuite l'exécuter dans l'IDE avec F5.




La dernière fois que j'avais changer de place mon dossier de mon projet, j'avais eu le même soucis, mais je me rappelle plus du tout comment j'avais fait pour le résoudre...


J'ai néanmoins une piste : quand j'ouvre VB6 et que je compile un des sous projets, la compilation échoue (LINK : fatal error LNK1104: cannot open file [path de l'ocx]). L'erreur est due à la compatibilité binaire si j'ai bien compris...


 


BREF, je sais pas quoi faire ! Si quelqu'un à eu le courage de lire ce pavé et que ce quelqu'un a une piste pour m'aider, un ENORME MERCI d'avance ;)


@+



Hex Editor VB

cs_casy · Answer

C'est surrement du au fait que les signatures de tes ocx sont enregistrées dans les fichiers projet et sources des projets utilisant ces ocx.

Le problème est que, si tu n'a pas choisi la bonne option, à chaque compilation de ton ocx, sa signature change. La compilation l'enregistre automatiquement dans la base, mais la mise à jours normalement n'est pas faite dans les projets utilisant cet ocx. Il faudrait pour cela que tu supprime les instances dans ces projets et que tu rajoute de nouvelle instances àprès cahque compilation.

Si tu vas dans les propriétés du projet de tes ocx, onglet compilation je crois, tu as les options de compilation. Je crois que c'est là que ça se gere. Par contre je ne sais pas qu'elle option il faut prendre.

Le but est que le composant ocx ne change pas de signature à chaqe compilation, il doit toujours conserver la même signature.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

violent_ken · Answer

Violent Ken

Oui, c'est de la compatibilité binaire dont tu parles, non ?
Pas de soucis de ce côté là, elle est bien activée.

Donc le problème ne vient pas du fait que je n'ai pas coché l'option.

Une fois que le bug sera réglé (vu que çà m'était déjà arrivé), je n'aurais plus aucun soucis lors, avant et après la compilation de n'importe lequel des (sous) projets.

Le bug surgit quand je change les dossiers de place, donc il doit y avoir une histoire de paths des OCX avec la compatibilité binaire, mais je vois pas de problèmes dans mes options -___-

@+



Hex Editor VB

cs_casy · Answer

Oui évidement si tu change les dossiers de place ça ne peut plus marcher. Leur de l'enregistrement de l'ocx dans la base de registre, son chemin d'installation (là ou il se trouve au moment de l'enregistrement) est enregistrer dans la abse de registre pour qu'il soit accessible, notament pour les futurs projets de VB.

Evidement si tu le change de répertoire après enregistrement, les oinformations d'enregistrement dansla base sont fausse et VB est incapable de le retrouver.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

violent_ken · Answer

Violent Ken
Certes, et c'est pour çà que je recompile et que je réenregistre (via regsvr32) mes OCX (donc nouveau CLSID) juste après le changement de dossier.
@+

Hex Editor VB

cs_casy · Answer

Oui mais justement il faudrait que tu conserve le même CLSID (signature) à chaque nouvelle compil sinon il va falloir que tu recharge chaque tes ocx dans tes projets, c'est pas viable.

Nota : normalement, tu n'sa pas besoin de réenregistrer après la compil, ça devrait etre automatiquement fait à la fin de la compli.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

violent_ken · Answer

Violent Ken

Pardon, je n'ai pas été complet :en changeant de dossier
- j'ai recompilé mes OCX (==> nouveau CLSID)
- je les ai enregistré (regsvr32 OCX.ocx -s)
- j'ai modifié les références aux OCX dans les projets (j'ai mis les nouveaux CLSID valides à la place des anciens, édition des *.vbp à la main).

Si je ne fait pas cette manip complète, les OCX refusent tout simplement de se charger.

@+







Hex Editor VB

Renfield · Answer

petit conseil méthodo.

conserves la version n-1 de ton ocx (ou dll, même combat)
utilises la pour la compatibilité binaire. (perso; j'utilises un folder nommé 'Compatibility'...)

compiles ailleurs ton ocx ; sans que le RegSvr32 ne soit automatisé...
une fois compilé, tu écrases celui qui se trouvait dans compatibility.

en t'assurant que ce dernier soit toujours bien registré.

pratique, la compatibilité binaire a un prix...
tu va voir croitre les version de te ocx dans la base de registres, qui va se retrouver presque 'polluée' par tes classes, dans leurs multiples versions.

Renfield
Admin CodeS-SourceS- MVP Visual Basic

Renfield · Answer

- j'ai recompilé mes OCX (==> nouveau CLSID)

oui, si pas de compatibilité binaire...
c'est bien le but ^^

la compatibilité des projets va s'assurer que les interfaces collent, et va changer de CLSID : les deux dll sont compatibles, du fait qu'elles fournissent des objets ayant la même interface (je ne parle pas de COM), mais deux version de ta dll ne sont pas liées..

la compatibilité binaire va conserver le CLSID... ou générer une version n+1 si n"cessaire, marquant tout soigneusement dans la registry : elle fait le lien entre deux versions de ton ocx.

(pas sûr d'avoir été clair ^^)

Renfield
Admin CodeS-SourceS- MVP Visual Basic

violent_ken · Answer

Violent Ken

Oui on est d'accord, le CLSID change si il n'y a pas de compatibilité binaire.

Voilà ce que j'ai fait :
1) j'ai changé le dossier
2) j'ai viré toutes les compatibilités binaires vu que le path était érroné
3) j'ai recompilé tous les OCX (==> nouveau CLSID pour chaque OCX)
4) j'ai remis la compatibilité binaire vers les nouveaux OCX avec le bon path
5) j'ai édité les *.vbp en mettant les nouveaux CLSID à la place des anciens
6) quand je recompile mes OCX, les CLSID ne changent plus puisque j'ai remis la compatibilité binaire

Donc au final, je n'ai généré qu'une seule fois des nouveaux CLSID (puisque j'ai remis la compatibilité binaire après).
Mais alors pourquoi cette méthode ne fonctionne t-elle pas ?

@+



Hex Editor VB

violent_ken · Answer

Violent Ken
Hum....

En fait, mon projet principal (*.vbg) contenait entre autres :
- les sous projets *.vbp des OCX
- les références aux CLSID de ces OCX

Il n'est pas nécessaire d'inclure les projets des OCX, si les OCX sont inclus... Ayant viré les projets OCX (j'ai gardé que les références aux CLSID des OCX), le problème a disparu...

C'était un peu stupide de ma part de surcharger mes projets comme çà... et apparement j'avais créé plusieurs conflits -__-

Donc à priori le problème est réglé. Et pour le dossier "Compatibility", c'est une bonne idée... je note^^

MERCI pour votre aide... MERCI.
@+

Hex Editor VB

"Type défini par l'utilisateur non défini" ==> bug bizarre

10 réponses

Votre réponse

Discussions similaires