Salut !

J'ai remarqué que si une personne n'avait pas VB6, il n'était pas possible d'exécuter un soft fabrication maison. Pour tout dire, je fais l'empaquetage par un autre soft que celui de VB.

Ma question est donc : t-on le droit de fournir les DLL manquantes (sans risque d'enfreindre la loi) ou l'empaquetage de VB aurait-il mis les DLL nécessaires au soft pour qu'il fonctionne chez l'autre correctement.

Si je l'utilise pas, c'est parce que ça bug (DLL manquantes) mais il peut continuer quand même) et je n'ai pas réussi à ne faire qu'un fichier EXE (il fait un fichier CAB...). Ce qui est bizarre c'est que j'ai installé le pack 5 (je crois) mise à jour sur le site. Là je me demande encore si j'ai bien fait la mise à jour car un CHM qui ne plantait pas, plante maintenant lol

Ah la la ! C'est dur dur d'être débutant j'vous l'dis moi :)
Merci pour votre aide.

Salut MicProg
Le problème est double :
- Pour faire fonctionner une application compilée en EXE sur un poste ne possèdant pas VB6, il faut installer le fichier VB6FR.DLL dans le répertoire System32 de Windows
- Si ton projet comporte des ajouts de controles issus de fichiers de type OCX (comme les RichTextBox, les WinSockets ...), il faudra que tu importes aussi chacun de ces fichiers, que tu les places dans le répertoire System32, et que tu les enregistres dans la base de registres (*)

Autre solution : utiliser l'empaquettage fourni avec VB6 : Il te créera les fichier de Setup et CAB nécessaires à l'installation, et là plus de problème !

Pour enregistrer les OCX dans la base de registres, ouvre une fenêtre DOS et tape :
RegSvr32 Chemin_et_nom_fichier.OCX

Vala
Jack

Salut Jack,

merci pour ta réponse.

Seul point que je n'ai pas compris, c'est l'enregistrement des OCX. L'emaquetage de VB ne le fait pas tout seul ?

Dans ce cas, comment le faire automatiquement pour que l'utilisateur n'est pas à le faire ?

Je pense à tout hasard dans un fichier .bat non ?
Encore merci :)
Je vais commencer par réparer l'empaquetage de VB.