Coco le composant recompilé

Malheureusement.... Les ocx sont référencés par une clef dans la base
registre (voir .vbp et un .frm incluant l'ocx dans la clause object) et
cette clef change lorsque l'on modifie l'interface du composant (ou que l'on
oublie de cocher compatibilité binaire dans les propriétés).

Toutefois, il suffit d'insérer le nouvel ocx dans un projet bidon, de tout
enregistrer, d'ouvrir le vbp avec notepad et de relever la nouvelle
clef.Puis vous reprenez votre projet réel et, toujours avec notepad, vous
remplacez les anciennes clefs par la nouvelle dans .vbp et dans tous les
.frm concernés. et voilà.

A titre indicatif, et pour éviter ce genre de désagréments sur des ocx
utilitaires (et donc en constante évolution), j'essaye au maximum de piloter
mes propres "COCO" avec des méthodes du type : mamethode ( byval Action as
ListedesActions, optional p1="", optional p2="", etc...) comme cela lorsque
je veux rajouter une fonction, je rajoute le mot clef correspondant dans
l'enum de ListeDesActions et cela ne modifie pas l'interface. Attention !
Pas de optional truc=null dans un composant (ni ailleurs de toutes
façons...).

Salut,

Essaye de compiler ton OCX en mode compatibilité binaire.

--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/

myname wrote:

Bonjour,

soit Coco mon composant ActiveX.

Je le compile en OCX (version 1).

Je l'intégre dans un autre projet Pépé.

Je modifie l'interface de Coco.

Je le recompile en OCX (version 2).

Lorsque je ré-ouvre Pépé, il me dit qu'il ne trouve plus Coco.

Ca ne me surprend pas trop.

Par contre, pour prendre en compte la nouvelle version,
je me trouve obligé de supprimer à la main Coco (V1) de toutes
mes feuilles, pour placer un Coco (V2) avec le même nom...

Rassurez-moi: il y a plus simple pour Coco soit un gentil Coco à son
Pépé ?

Merci d'avance !