Discussion :

[electroremy]

Bonjour,

j'ai un petit soucis avec VB5

j'ai un projet que je dévellope avec deux ordi différents (un fixe et un portable) visiblement chaque ordi a une version différente de comctl32.ocx et donc j'ai deux fichiers VBP pour chaque ordinateur

Voici le fichier VBP du PC portable (sous Seven 32 bits) :
Type=Exe
Object={5E9E78A0-531B-11CF-91F6-C2863C385E30}#1.0#0; MSFLXGRD.OCX
Object={6B7E6392-850A-101B-AFC0-4210102A8DA7}#1.2#0; comctl32.ocx
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\Windows\system32\stdole2.tlb#OLE Automation
Form=CiDess.frm
...

Voici le fichier VBP du PC fixe (sous Seven 64 bits) :
Type=Exe
Object={5E9E78A0-531B-11CF-91F6-C2863C385E30}#1.0#0; MSFLXGRD.OCX
Object={6B7E6392-850A-101B-AFC0-4210102A8DA7}#1.3#0; COMCTL32.OCX
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#C:\Windows\SysWOW64\stdole2.tlb#OLE Automation
Form=CiDess.frm
...

Je n'arrive pas à ouvrir le projet sur le PC fixe avec le fichier VBP du portable et vice versa

Là où c'est bizarre, c'est que les .exe marchent sur les deux PC quelque soit l'ordi avec lequel je l'ai généré...

Sauf que sur pas mal d'ordinateurs, le .exe généré avec le PC fixe ne marche pas

Evidemment j'ai essayé de joindre le COMCTL32.OCX avec le fichier .EXE mais sans succès

Comment me sortir de cette situation bancale ?

Merci

[electroremy]

Bonsoir,

je me suis rendu compte que j'avais uniquement besoin de cet OCX pour trois barres de progression

j'ai codé moi-même une barre de progression, plus jolie en plus, et me suis débarrassé de cet OCX

ce n'est pas la vraie solution mais le problème n'est plus là

A+

[unparia]

Bonjour

j'ai codé moi-même une barre de progression, plus jolie en plus, et me suis débarrassé de cet OCX

ce n'est pas la vraie solution mais le problème n'est plus là

Je ne sais pas ce que tu entends par "vraie solution", mais peux t'affirmer que la meilleure (des solutions) est de rester indépendant. La tienne en est une et je l'approuve sans hésitation.

[electroremy]

Je ne sais pas ce que tu entends par "vraie solution", mais peux t'affirmer que la meilleure (des solutions) est de rester indépendant. La tienne en est une et je l'approuve sans hésitation.

En effet, devoir utiliser un OCX ou une DLL juste pour un petit truc est dommageable.

Justement avec mon programme je distribue un bon paquet de DLL et je me demande si toutes sont nécessaires...

Avec VB5, où trouver la liste de tous les fichiers DLL, OCX et autres à joindre avec son application (dans le cas où l'utilisateur n'aurait aucun autre programme VB5 déjà installé sur sa machine) ?

Je ne fourni volontairement aucun "setup.exe". Mon programme est "portable", sous la forme d'un fichier zip à décompresser dans un répertoire contenant le fichier .exe et tout ce qui va avec. Ainsi mon programme peut être testé et utilisé sur un ordinateur sans "pourrir" les dossiers systèmes et la base de registre.

Ce choix est apprécié par mes utilisateurs.

En fait les gens en ont marre de "pourrir" leur système juste pour pouvoir essayer un soft avant de l'adopter. Dans le domaine de l'électronique (mon appli VB5, CiDess, est un logiciel de dessin de circuits imprimés) il existe de nombreux logiciels freeware, shareware, et aussi maintenant de plus en plus de montages électroniques nécessitant d'être raccordés à un ordinateur et d'utiliser un logiciel pour êtres initialisés.

Récemment j'ai acheté un analyseur de signal par Ethernet en kit ; juste pour mettre à jour le firmware de cet analyseur, et modifier une ligne de code dans le microcontrôleur pour le machin soit utilisable via ma box en DHCP, j'ai du télécharger et installer l'IDE Microchip au grand complet (grosse suite logicielle, une sorte de Visual Studio pour microcontrôleurs PIC). Cet IDE occupe plein de place sur le disque dur et a installé quantité de choses partout... certes j'ai quelques µC Microchip et peut être qu'un jour j'utiliserais cet IDE mais ça reste hypothétique...

A noter que mon appli VB5 est volontairement prévu pour tourner sur Windows 95 jusque les versions actuelles de windows (Seven, 8 et 10)

De même dans mon soft j'ai refait moi-même des boîtes de dialogue "imprimer" et "ouvrir fichier", ne serais-ce que pour pouvoir les traduire indépendamment de la langue installée sur l'OS sur lequel tourne mon programme. Si j'avais utilisé les dialogues standard du VB ces fenêtres seraient dans la langue de la version de windows installée.

Je développe également une autre appli sur VB.NET. Après un temps d'adaptation difficile aujourd'hui je trouve que VB.NET est beaucoup mieux que VB5. Avec VB.NET j'ai utilisé les dialogues de VB, et maintenant je veux que mon appli soit multilingue et là je suis coincé (à moins de forcer mon appli à n'utiliser que la même langue que la version de Windows sur laquelle il s’exécute)

A bientôt