INCLURE LES DLL ET LES OCX DANS VOS PROGRAMMES (SAUF VB6FR.DLL)
cs_gagou9
Messages postés
126
Date d'inscription
vendredi 19 septembre 2003
Statut
Membre
Dernière intervention
20 novembre 2007
-
22 juin 2005 à 14:56
cs_rt15 Messages postés 3874 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 7 novembre 2014 - 18 févr. 2012 à 11:34
cs_rt15 Messages postés 3874 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 7 novembre 2014 - 18 févr. 2012 à 11:34
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/32238-inclure-les-dll-et-les-ocx-dans-vos-programmes-sauf-vb6fr-dll
https://codes-sources.commentcamarche.net/source/32238-inclure-les-dll-et-les-ocx-dans-vos-programmes-sauf-vb6fr-dll
18 févr. 2012 à 11:34
(Ouch, ça me rajeuni pas ce topic)
Je ne suis pas sur de comprendre la question. Il n'y a pas besoin de clé.
Globalement, il met les .ocx nécessaires en ressources du programme. Au lancement du programme, il extrait les .ocx, les copie dans system32 et fait un regsvr32 pour les registrer.
Mais il est généralement plus propre et plus simple de passer par un setup, généré via InnoSetup par exemple.
http://www.vbfrance.com/tutoriaux/INSTALLATION-AVEC-INNOSETUP_590.aspx
Il faut faire cependant bien attention à préciser à InnoSetup tous les fichiers nécessaires, avec enregistrement ou non (regserver) suivant le type de dll.
Pour tout programme, il faut msvbvm60.dll (Avec regserver) et vb6fr.dll (Sans regserver). Les autres dépendances classiques (comcat, ole32...) devraient être présentes.
18 févr. 2012 à 08:52
comment fonctionne-t-il ?
salut et remerciements anticipés. Babu
19 avril 2006 à 00:43
19 avril 2006 à 00:34
OvO est un utilisateur s'étant appliqué a développer ce commentaire.
21 sept. 2005 à 12:55
Je te remet mon lien qu'est un peu perdu dans tous les messages.
http://www.vbfrance.com/tutorial.aspx?ID=240
Sinon, c'est sympa les écoles d'ingé d'info: j'y ai pas encore vu un PC ! Y a que des terminaux connectés à des serveurs Unix et Windows.
Plus de restrictions que ça, tu meurs.
Et le langage le plus utilisé semble être le C... sous Unix!!!!!!
19 sept. 2005 à 07:35
18 sept. 2005 à 20:28
Nous avons un différend
Maître Capello
18 sept. 2005 à 19:03
On dit donc:
Un différend : En français
Un <> : en VB...
Bonne prog
++
17 sept. 2005 à 18:02
!!!!
loool
17 sept. 2005 à 15:31
:-)
Jack, embrouilleur depuis 1959
15 sept. 2005 à 21:49
BruNews>>Oui c'est bien clair.
15 sept. 2005 à 11:24
15 sept. 2005 à 11:22
15 sept. 2005 à 11:19
Chuis encore là !
Bouv, notre problème était plutot de savoir s'il fallait absolument que le dossier du .exe soit le dossier courant au démarrage pour que les dlls de ce dossier soient correctement chargées.
15 sept. 2005 à 11:14
Au fait, comment ça se fait que des fois t'est marqué admin et des fois pas ?
Je signale que je rentre en école d'ingé d'info le 19.
C'est loin de chez moi et je ne prend pas de PC... Je ne sais pas qu'en c'est que je vais revenir sur ce site. Alors à plus !
15 sept. 2005 à 11:10
App.Path prend toujours la valeur du dossier qui contient l'exe ;
CurDir prend la valeur du dossier qui contient l'exe si on lance l'exe directement ou la valeur du dossier qui contient le raccourci si on lance l'exe depuis un raccourci.
Je pense que c'est également valable pour les DLL.
15 sept. 2005 à 11:06
Il est clair que 'loaded' n'a aucun rapport avec la currentDirectory.
15 sept. 2005 à 10:57
Autrement dit, au démarrage de l'application, le dossier courant peut être n'importe quoi!
Pour cela, il faut par exemple executer l'application depuis le DOS. Dans ce cas, le dossier courant au lancement de l'application est le dossier courant du DOS. (echo %CD%, si le prompt est modifié).
On peut aussi modifier le dossier de démarrage dans un .lnk.
Dans les propriété, il y a le chemin de l'exe, et "démarrer dans : ". Démarrer dans spécifie le dossier courant de démarrage de l'application.
Mais The directory from which the application loaded, je pense que c'est le dossier ou se trouve le .exe. C'est du moins ce que confirme mes tests.
15 sept. 2005 à 10:49
"dossier où l'application a démarré" et "dossier ou le .exe a été chargé"
Je n'arrive pas à voir la différence.
15 sept. 2005 à 10:41
Il semblerait que j'ai raison.
J'ai fait des essais depuis VB6, avec ce code:
Private Declare Function InitCpuSpeed Lib "EX_Time.dll" Alias "EXtmr_InitCpuSpeed" (ByVal lpEX As String) As Long
Private Declare Function GetCpuSpeed Lib "EX_Time.dll" Alias "EXtmr_GetCpuSpeed" (nBuffer As Long, ByVal lpEX As String) As Long
Private Sub Form_Load()
Dim intBuffer As Long
Call InitCpuSpeed("allo")
Call GetCpuSpeed(intBuffer, "allo")
MsgBox CurDir
MsgBox intBuffer
End Sub
J'ai ensuite appelé l'exe depuis un batch et aussi depuis un raccourcis où j'ai modifier "Démarrer dans :"
Je me suis bien sûr assurer qu'aucune EX_Time.dll ne se trouvait dans un autre emplacement que le dossier de l'exe, et que celui-ci n'était pas mentionné dans les variables d'environement.
The directory from which the application loaded.
C'est pas le dossier où l'application a démarrée.
C'est le dossier ou le .exe a été chargé !
Conclusion, si on place les dlls dans le même dossier que l'exe, on se fiche complètement du dossier courant.
Si tu ne me crois pas, fait un test !!!
J'ai essayer de débugger LoadLibrary, mais je n'ai pas le niveau...
Mais pleures pas: si tu veux me trouver des anneries que j'ai écrites tu devrais en trouver plein dans mon tuto !
Gagou9,
Le source de Philipe Heiz quand même assez facilement utilisable.
Voici le lien vers mon tuto:
http://www.vbfrance.com/tutorial.aspx?ID=240
12 sept. 2005 à 16:55
The directory from which the application loaded.
C'est pas le dossier de l'exe ?????? EXACT.
Si les DLLs (API bien entendu) ne sont pas dans un dossier de l'algo de recherche de LoadLibrary, il est clair qu'il sera impossible de les charger.
12 sept. 2005 à 16:45
12 sept. 2005 à 16:44
Si un exe et ses dlls se trouvent dans c:\PROG, tu dis que si l'exe est démarré dans C:\, le programme ne parviendra pas a charger ses dlls, c'est bien ça ?
12 sept. 2005 à 16:35
C'est pas le dossier de l'exe ??????
12 sept. 2005 à 16:32
12 sept. 2005 à 16:24
Windows 2000/NT, Windows Me/98/95: The SafeDllSearchMode value does not exist.
If SafeDllSearchMode is 1 (the default), the search order is as follows:
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
Windows Me/98/95: This directory does not exist.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable.
If SafeDllSearchMode is 0, the search order is as follows:
The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
Windows Me/98/95: This directory does not exist.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable.
Windows XP: The default value of HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode is 0 (the current directory is searched before the system and Windows directories).
The first directory searched is the one directory containing the image file used to create the calling process (for more information, see the CreateProcess function). Doing this allows private dynamic-link library (DLL) files associated with a process to be found without adding the process's installed directory to the PATH environment variable.
The search path can be altered using the SetDllDirectory function. This solution is recommended instead of using SetCurrentDirectory or hard-coding the full path to the DLL.
12 sept. 2005 à 16:19
Evidement si tu as lu l'algo, je dois me tromper.
Cependant, je vais essayer quand même, car il me semble avoir déjà essayé...
(Je suis dans un cybercafé...)
12 sept. 2005 à 15:20
12 sept. 2005 à 15:01
Okay, je vais essayer de faire un tuto pour la rédaction manuelle.
Je posterai ici son URL.
Mais ça rédaction vat me rapppeler de mauvais souvenirs...
BruNews,
Resalut si tu te souviens de moi.
Je te taquine encore.
Tu as écris:
Pas besoin qu'une dll soit dans sysDir mais dans dossier du exe vb est suffisant, il suffit d'assurer la currentDirectory sur dossier exe par un appel SetCurrentDirectory dès le lancement du prog.
Mouais...
Je suis pas sûr que le dossier de l'exe est besoin d'être courant pour que windows trouve les dlls. Je vérifierai !
9 sept. 2005 à 19:04
ça m'interresse le tuto pour rediger manuellement !!!
ça fait longtemps que j'ai pas travaillé cette source, mais si je peux l'amelioré, autant la faire !!!!
emrci
Gagou9
5 sept. 2005 à 15:55
J'ai fait des essais concluant avec une dll à moi sur un PC où la base de regisre était bloquée.
Il faut un .Manifest pour l'exe et un de plus pour chaque fichier partagé.
Le prog du lien de mon précédent message évalue mal les dépendances des exe, par contre il rédige bien les manifest.
On peut rajouter manuellement les dll et ocx qu'il a oublié.
Par contre, il faut que celles ci soient installés au moment de la génération des manifest.
Au pire, on peut rédiger les fichiers manuellement.
Mais pour cela, il faut récupérer les CLSID manuellement dans la base de registre, ce qui peut être fastidieu.
Si tu veux, je peut te mailler un exemple. Ou alors je peut faire un tuto sur une rédaction manuelle...
1 sept. 2005 à 19:45
j'avasi deja essayé avec des fichiers .Manifest, mais ça n'avait pas fonctioné (c'et moi qui devait etre nul !!)
si tu sais comment faire precisement, previent moi !!
cette source n'est utile que pour les petits programmes, et de toute facon msvbvm60.dll est preseznte sur la plupart des OS !
voila merci
Gagou9
1 sept. 2005 à 19:35
http://www.vbfrance.com/code.aspx?ID=28387
Pas besoin d'avoir de droit: pas besoin de modifier le registre.
Pas non plus de problèmes de version !
Si ça ne marchait pas que sur XP, ce serait fantastique...
(Des essais sur 2000 ont été concluant)
Par contre difficulté d'installer msvbvm60.dll avec ça...
5 août 2005 à 11:53
au contraire, cette source n'est que l'amelioration d'une autre !
rien de plus! et elle necessite encore d'autres ameliorations !
voila voila !!
A la revoyure !
Gagou9
5 août 2005 à 02:25
3 juil. 2005 à 10:59
celui quue tu mez montre la c'est celui dont je me suis tiré !
lui il enregistre les ocx dans le repertoire actuel, et ça je trouve ça nul !
voila!
allez a+
Gagou9
3 juil. 2005 à 05:51
http://www.vbfrance.com/code.aspx?id=29078
L'inovation ca a du bon, non?
29 juin 2005 à 22:06
ben voila j'ai ajouté un commentaire qui dit bien qu'il faut demarrer par sub main() donc vu que la form ne se charge pas avant d'avoir les ocx, ben pas de bug !!
euh sinon pour la version je fai comment ? car je veux bien moi mais je debute et pi pas connai pa tout !!
merci
gagou9
29 juin 2005 à 20:19
Pour commencer, ce code sert a transporter un ou deux ptits ocx pour faciliter le transport de petits executable n'etant pas destine a etre installe! Et non a contenir toutes les librairie d'une grosse appli!
Il peut aussi si vous utilisez VB6 (US qui ne necessite pas VB6FR.DLL) servir a faire un installateur pour de plus grosse appli a condition que msvbm60.dll soit installe sur la machine ce qui est le cas a partir de Win2000 ou XP.
Mais je ne vois pas ce que le probleme de droits vient faire ici!
si l'utilisateur n'a pas les droits pour un RegServ32, il ne les a pas non plus via un installateur!!!
Sinon pour le probleme de systemDir ou de app.path bah c simple si c'est un ocx que vous avez code vous meme app.path convient tres bien sinon si c'est un composant succeptible d'etre installe sur d'autres machines genre winsock.ocx, il est preferable d'utiliser le rep systeme (mais en faisant une verification de la verion!!)
Donc en resume ce code est tres utile pour qui saura comprendre son utilite ;)
bonne prog a tous @+
24 juin 2005 à 21:11
Les sources de ce type pululle sur vbfrance...
@+
24 juin 2005 à 09:52
Si on parle de DLL sans préciser, c'est toujours de DLL API.
24 juin 2005 à 09:46
>certains utilisateurs n'ont pas le droit d'installer des logiciels.
Oui. J'en ai trop souvent fait l'expérience
>Me gourré-je ?
On ne pas me gour'je ? ;o)
24 juin 2005 à 09:36
24 juin 2005 à 09:03
24 juin 2005 à 08:54
Si ton appli affiche un message qui est traduit dans cette dll, je crois bien que ton appli sera bloquée si cette dll est absente
Par ailleurs, pour un programme déjà compilé, tu sera bien obligé de copier les dll api dans le répertoire système de Windows, et de toute façon, il me semble que le app.path n'est pas utilisable pour les declare, de sorte qu'il ne reste qu'une seule solution (hormis l'api LoadLibrary ?) pour éviter les chemins en dur : le répertoire système.
Enfin, tout programme d'installation requiert aussi un minimum de droit : certains utilisateurs n'ont pas le droit d'installer des logiciels.
Me gourré-je ?
23 juin 2005 à 20:03
Faux> vb6fr.dll ne sert strictement a rien puisqu'il n'y absolument aucun code dedans mais uniquement la traduction française des messages d'erreur, msvbvm60.dll seul fera l'affaire.
Faux> il est inutile dans le cas present de copier les ocx & dll dans le repertoire systeme car sur un poste convenablement configuré pour un usage proffesionnel les repertoire systeme sont protegé l'utilisation de app.path est plus logique
Pour conclure, celui qui veux inclure les dll et ocx dans son appli aura plus d'avantage a utiliser un VRAI logiciel d'installation plutot que d'ajouter tout ça dans tout ces exe ce qui ne ferait que grossir miserablement l'application. Les ocx et dll ne sont il pas la justement pour alleger et partager le code ?
23 juin 2005 à 18:59
23 juin 2005 à 15:51
Enfin pour la derniere remarque, il sera effectivement necessaire de réenregistrer l'ocx si le répertoire à changé, sinon ce n'est pas plus genant que cela (si on suppose que l'ocx n'est pas partagé par plusieurs applications, mais dans ce cas, il ne faut enregistrer l'ocx que s'il ne l'est pas déjà sur le poste)
23 juin 2005 à 14:37
23 juin 2005 à 14:36
J'ai dejà vu des CD-ROM où les mecs mettent VB6FR.dll à la racine du CD-ROM (avec l'exe) pour que leur prog d'installation fait maison puisse se lancer. Et cela fonctionne...
De plus, quand par exemple on lance un projet alors qu'il manque un OCX ou une DLL sur le poste, VB nous indique qu'il manque le composant avec en info le repertoire du projet. Donc "A MON AVIS" quand un prog VB6 ne trouve pas le composant qu'il cherche dans la base de registre, il scan le dossier de l'exe.
Sinon c'est mystère et boulle de gomme.
23 juin 2005 à 14:05
23 juin 2005 à 13:38
Oui, oui, je sais... c'est le problème des "private jokes" un peu trop "private" ;o)
Au sujet des OCX et DLL, dans un confus souvenir, il me semble que si le fichier dll et/ou ocx est dans le même répertoire que l'exécutable, il n'est pas nécessaire de l'enregistrer. Quelqu'un peut il le confirmer ?
++
Moustachu
23 juin 2005 à 12:49
23 juin 2005 à 12:00
Encore faut-il avoir les droits... me tromp'je ?
++
Moustachu
23 juin 2005 à 08:40
Faux ! on peut très bien démarrer sur le main(), enregistrer les ocx le cas échéant, puis lancer une form contenant des ocx :
www.vbfrance.com/code.aspx?ID=17783
23 juin 2005 à 07:20
22 juin 2005 à 19:48
22 juin 2005 à 18:55
Pour avoir les ocx faut demarrer l'appli et pour demarrer l'appli il faut avoir les ocx !
Aller zou dans le fourbi vbfrance...
22 juin 2005 à 18:28
En effet, Ret = GetSystemDirectory(repsysteme, 255) renvoie dan Ret la longueur de la chaine récupérée dans repsysteme, qui elle contient 255 caractères, c'est la raison pour laquelle ensuite, tu ne prends que les Ret caractères de cette chaine avec la fonction Left.
Pour ce qui est de la source, oui, ça peut être pratique pour les DLL de référence, mais pas pour les OCX :
En effet, si, dans ton appli, tu te sers ce l'OCX qui est stockée dans on fichier de ressources, l'EXE refusera de se lancer puisqu'il a besoin de cet OCX qui n'existe pas encore.
Ton application fonctionnerait, mais il faut lui laisser le role d'installateur d'OCX pour une autre application.
De plus, après avoir extrait ton OCX, il faut impérativement l'enregistrer dans la base de registre (avec RegSvr32 par exemple) : il existe des sources qui savent le faire.
De toute façon, cette application d'installation étant quand même basée sur du VB, il faudra quand même faire une installation propre (avec l'empaquettage) une première fois pour mettre en place les fichiers références de VB.
22 juin 2005 à 14:56
Euh j'ai un peu commenté la source, mais vu que ça fait seulement 4 ou 5 mois que je fais du VB j'ai bien peur qu'il y ai des commentaires faux, dites le moi svp !!
(je pense en particulier a :
repsysteme = Space(255) ' creer un espace reservé
Ret = GetSystemDirectory(repsysteme, 255) 'stocke dans ret le repertoire, avec des espaces en bout de string
repsysteme = Left$(repsysteme, Ret) 'enleve les espaces qui servent a rien et stoque le rep dans repsysteme
)
A+
Gagou9