UN EXE RÉELLEMENT AUTONOME
106
Messages postés
39
Date d'inscription
jeudi 17 janvier 2002
Statut
Membre
Dernière intervention
14 janvier 2008
-
20 mars 2002 à 08:44
cs_DamienI Messages postés 17 Date d'inscription vendredi 1 mars 2002 Statut Membre Dernière intervention 10 janvier 2003 - 27 juin 2002 à 10:02
cs_DamienI Messages postés 17 Date d'inscription vendredi 1 mars 2002 Statut Membre Dernière intervention 10 janvier 2003 - 27 juin 2002 à 10:02
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/2864-un-exe-reellement-autonome
https://codes-sources.commentcamarche.net/source/2864-un-exe-reellement-autonome
27 juin 2002 à 10:02
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é
2 mai 2002 à 16:13
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.
30 avril 2002 à 20:02
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)
21 mars 2002 à 07:01
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...
21 mars 2002 à 06:56
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.
21 mars 2002 à 00:00
Pffffffffffff décidement, faut vous l'expliquer en quelle langue, mierda !
20 mars 2002 à 13:55
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 !
20 mars 2002 à 13:51
le plus simple étant tout de même de faire un setup avec par exemple MakeNSIS...
a+
20 mars 2002 à 13:47
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:
20 mars 2002 à 13:47
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.
Voilà, je ne pense avoir rien oublié.
@+
Mercury
20 mars 2002 à 13:26
Mais bon, une bonne note simpose qu'en même ;-)
20 mars 2002 à 10:52
J'ai testé ce prog sous XP et ça marche. Le fichier .res je l'ai fait tout simplement avec l'éditeur de ressources de VB
20 mars 2002 à 09:35
20 mars 2002 à 08:44