Si vous voulez un exemple avec ce fameux lanceur en C : allez voir ma source :
merci tout le monde : le lanceur en C c'était mon, idée...
Nix, toi tu le sais... Non, je blague tout le monde a pu y penser...
Bien, en tout cas ça montre que j'étais pas le seul à me prendre la tête sur ce sujet... Et oui, un lanceur en C semble la seule solution rapide... A+ tutti et bonne prog , DamienI votre bien dévoué
Ces erreurs sont normales, puisque ce projet utilise un controle non enregistré.
Le but de ce projet était justement de montrer qu'un controle pouvait être enregistré dynamiquement par le programme qui l'utilise. Et comme on ne peut pas exécuter un projet dont le contrôle n'est pas enregistré... il faut d'abord lancer l'exe, et là le contrôle s'enregistre, et on peut ouvrir le projet.
Slt, lorsque j'execute ton projet, j'obtient une suite d'erreurs :
1 - Convention d'appel de dll incorrecte, dans la fonction "registerserver"
hwnd=1292 path=c:windowssystemccrpprg6.ocx et unregister=false
err.number=49
2 - Erreur ( il n'y a marqué Que reeur dans la boite de dialogue)
dans la procédure form_load. i=101
3 - Erreur lors du chargement, dans la procédure form_load (de formprojet cette fois ci)
4 - Erreur de compilation : Membre de donnée introuvable
( du au non-chargement de ccrpprogressbar : pas de .value)
dans l'evenement du timer
Bon, j'éspère que cette erreur est seulement due à mon ordinateur.
Ps : je n'ai pas lancé l'exe avant l'emploi du projet, mais j'ai exécuté plusieurs fois le projet , toujours les memes erreurs.
Et bien voila, je peux peut etre apporter plus de précisions si on me le demande, en m'envoyant un message (etilegr)
moi pour un exe totalement utilisable, et pour reprendre l'idée de pitap0, je ferais comme ceci : un programme en C qui contient en ressources les runtimes vb plus le prog vb réalisé comme celui de KevinK, qui verifie si les runtimes sont enregistrées, decompacter le prog vb et s'autodetruire... bien sur on peux faire ca pour l'autodestruction...
mais la ya de vb + du c... si ca interesse quelqu'un je peux essayer de retrouver la source de ce petit prog en c qui se détruit des kon l'execute...
pekinio> JUSTEMENT lis tout le post, et plutot deux fois kune !!!
il parle de faire un exe en VB pour le programme + un exe en C (langage c) qui verifie d'abord l'existance des dlls, les extraits et les enregistres au besoin, et ensuite lance le prog vb... l'idée est tout a faitbonne, mais le pb c qu'il faut deux programmes.
PITAP> Comment tu veux que ton exe verifie l existence des dll et les extrait si pas exister si elles existent pas : ton prog pourra meme pas faire ca si elles sont pas la tes dlls...
Pffffffffffff décidement, faut vous l'expliquer en quelle langue, mierda !
Pour mercury:
On peut choisir le dossier d'installation des ocx, en le mettant dans le tableau des strings (mais c'est vrai que ça serait intéressatn de pourvoir utiliser les variables dans cette chaîne, comme &windir& ou &sysdir&, c'est une bonne idée pour la prochaine version
Quant à l'autre proposition, c'est pas mal mais l'enregistrement de contrôles c'est pas ça qui prend du temps (et pis surtout, je sais pas comment on vérifie qu'un composant est enregistré).
Par contre pour la prochaine version, je vais vérifier si le contrôle existe déjà où on veut le mettre, si oui, on ne l'extrait pas.
Merci pour les suggestions, continuez !
Pour se debarasser des runtimes le mieu est de faire un exe en c qui au lancement de l'appli verifie si les runtimes existes (si non : les extraire et les enregistrer) ensuite lancer l'appli (sela prend 2 fichier exe)
le plus simple étant tout de même de faire un setup avec par exemple MakeNSIS...
a+
Ah bon, je savais pas que c'était connu, tous les exe autonomes que j'ai trouvé sur ce site ne marchaient pas, désolé si j'ai ajouté un doublon.
Pour ce qui est des runtime, c'est sûr que c'est pas possible de s'en débarrasser, en tout cas par le biais de vb ))c:
Mais y'a un programme qui permet de lier des dll dans une fichier exe (PEBundle), je me dis donc que ça doit être faisable, en assembleur du moins. Malheureusement je n'ai pas les connaissances requises en asm !
et merci pour la bonne note [c:
Une petite suggestion pendant que j'y pense : il serait intéressant que les OCX et DLL du programme soient placés et enregistrés dans le dossier système de Windows.
A celà deux avantages :
1) L'utilisateur ne voit pas que différents OCX et/ou DLL sont associés au programme (pour une fois, un prog VB aura presque l'air allégé ;-)) ),
2) Si l'utilisateur fait un copier/coller de l'executable seul, même placé à un endroit différent, le programme marchera qu'en même.
Autre proposition, il faudrait un processus permettant de vérifier si les OCX et/ou DLL ont déjà été enregistrés ou pas (dans le cas où le programme a déjà été executé au moins une fois). S'ils ont déjà été enregistrés, ça n'est pas la peine de le refaire de nouveau. Le programme gagnera ainsi en rapidité, surtout si plusieurs OCX y sont associés.
Ok good moi sa a marcher sur ME en tk. Pour le .res, toi tu la fait en quoi, je sais que je peux l'ouvrir avec vc++, mais je sais pas si je fait des modif directement dans le .res ouvert avec vc++ si sa va marcher... En tk très bonne prog.
As-tu testé ce programme sur différent système d'exploitation ? Je pense notement à des système comme NT, 2000 et suivant pour lesquels, il est nécéssaire d'avoir des droits particulier pour installer un OCX ou un programme en général.
merci tout le monde : le lanceur en C c'était mon, idée...
Nix, toi tu le sais... Non, je blague tout le monde a pu y penser...
Bien, en tout cas ça montre que j'étais pas le seul à me prendre la tête sur ce sujet... Et oui, un lanceur en C semble la seule solution rapide... A+ tutti et bonne prog , DamienI votre bien dévoué
Le but de ce projet était justement de montrer qu'un controle pouvait être enregistré dynamiquement par le programme qui l'utilise. Et comme on ne peut pas exécuter un projet dont le contrôle n'est pas enregistré... il faut d'abord lancer l'exe, et là le contrôle s'enregistre, et on peut ouvrir le projet.
1 - Convention d'appel de dll incorrecte, dans la fonction "registerserver"
hwnd=1292 path=c:windowssystemccrpprg6.ocx et unregister=false
err.number=49
2 - Erreur ( il n'y a marqué Que reeur dans la boite de dialogue)
dans la procédure form_load. i=101
3 - Erreur lors du chargement, dans la procédure form_load (de formprojet cette fois ci)
4 - Erreur de compilation : Membre de donnée introuvable
( du au non-chargement de ccrpprogressbar : pas de .value)
dans l'evenement du timer
Bon, j'éspère que cette erreur est seulement due à mon ordinateur.
Ps : je n'ai pas lancé l'exe avant l'emploi du projet, mais j'ai exécuté plusieurs fois le projet , toujours les memes erreurs.
Et bien voila, je peux peut etre apporter plus de précisions si on me le demande, en m'envoyant un message (etilegr)
mais la ya de vb + du c... si ca interesse quelqu'un je peux essayer de retrouver la source de ce petit prog en c qui se détruit des kon l'execute...
il parle de faire un exe en VB pour le programme + un exe en C (langage c) qui verifie d'abord l'existance des dlls, les extraits et les enregistres au besoin, et ensuite lance le prog vb... l'idée est tout a faitbonne, mais le pb c qu'il faut deux programmes.