Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

INCLURE LES DLL ET LES OCX DANS VOS PROGRAMMES (SAUF VB6FR.DLL)


Information sur la source

Catégorie :Divers Niveau : Débutant Date de création : 22/06/2005 Date de mise à jour : 29/06/2005 22:04:20 Vu / téléchargé: 8 099 / 1 024

Note :
4 / 10 - par 1 personne
4,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

Commentaire sur cette source (58)
Ajouter un commentaire et/ou une note

Description

C'est une source de Draluorg que j'ai amélioré (http://www.vbfrance.com/code.aspx?id=29078)
car la sienne extrayait dans le repertoire de l'application, alors que la mienne extrait dans le repertoire systeme de windows.
 

Source

  • 'code du module :
  • Private Declare Function GetSystemDirectory Lib "kernel32" Alias "GetSystemDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As Long
  • Dim repsysteme As String 'variable qui sert a stoquer le sysdir
  • Option Explicit
  • Dim b1() As Byte
  • Dim b2() As Byte
  • Sub Main() 'Attention, il est nécessaire de mettre _
  • dans les options du projet qu'il faut demarrer par Sub Main()
  • 'fonction de recup du system directory
  • Dim Ret As Long
  • 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
  • 'fin de la fonction
  • Extrait ' on extrait les ocx ou dll sur le disk et on les enregistre
  • DoEvents
  • Form1.Show ' on lance le form "de demarrage"
  • End Sub
  • Sub Extrait() 'fonction pour extraire les ocx sur le disk (dans le repertoire systeme)
  • Dim cc1, cc2
  • cc2 = repsysteme & "\dialogg.ocx"
  • cc1 = repsysteme & "\Basics.ocx"
  • b1 = LoadResData(101, "CUSTOM") ' contient basics.ocx (reyXP_Basic.ocx)
  • If FileExist("" & cc1) Then GoTo 2 ' si le fichier existe deja on pass
  • Open cc1 For Binary As #1 ' on extrait l'ocx
  • Put #1, , b1
  • Close #1
  • DoEvents
  • 2
  • If FileExist("" & cc2) Then GoTo Fin ' si le fichier existe deja on pass
  • b2 = LoadResData(102, "CUSTOM") ' contient dialogg.ocx (ComDlg32.ocx)
  • Open cc2 For Binary As #1 'on extrait l' ocx
  • Put #1, , b2
  • DoEvents
  • Close #1
  • DoEvents
  • Shell "regsvr32 /s basics.ocx" 'et la on enregistre les dll
  • Shell "regsvr32 /s dialogg.ocx" 'le /s met regsvr32 en mode silentieux
  • Fin:
  • DoEvents
  • End Sub
  • 'fonction pour verifier l'existance d'un fichier
  • Private Function FileExist(file As String) As Boolean
  • Dim L As Long
  • On Error GoTo FExErr
  • L = FileLen(file)
  • FileExist = True
  • Exit Function
  • FExErr: FileExist = False
  • Exit Function
  • End Function
'code du module :
Private Declare Function GetSystemDirectory Lib "kernel32" Alias "GetSystemDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As Long
Dim repsysteme As String 'variable qui sert a stoquer le sysdir

Option Explicit
Dim b1() As Byte
Dim b2() As Byte

Sub Main()  'Attention, il est nécessaire de mettre _
dans les options du projet qu'il faut demarrer par Sub Main()
    'fonction de recup du system directory
    Dim Ret As Long
    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
    'fin de la fonction
Extrait ' on extrait les ocx ou dll sur le disk et on les enregistre
DoEvents
Form1.Show ' on lance le form "de demarrage"
End Sub

Sub Extrait() 'fonction pour extraire les ocx sur le disk (dans le repertoire systeme)
    Dim cc1, cc2
        cc2 = repsysteme & "\dialogg.ocx"
        cc1 = repsysteme & "\Basics.ocx"
        b1 = LoadResData(101, "CUSTOM") ' contient basics.ocx (reyXP_Basic.ocx)

If FileExist("" & cc1) Then GoTo 2 ' si le fichier existe deja on pass

    Open cc1 For Binary As #1 ' on extrait l'ocx
        Put #1, , b1
    Close #1
    DoEvents
2
If FileExist("" & cc2) Then GoTo Fin ' si le fichier existe deja on pass

b2 = LoadResData(102, "CUSTOM") ' contient dialogg.ocx (ComDlg32.ocx)

    Open cc2 For Binary As #1 'on extrait l' ocx
        Put #1, , b2
        DoEvents
    Close #1

DoEvents
    Shell "regsvr32 /s basics.ocx"  'et la on enregistre les dll
    Shell "regsvr32 /s dialogg.ocx"   'le /s met regsvr32 en mode silentieux
Fin:
DoEvents
End Sub

'fonction pour verifier l'existance d'un fichier
Private Function FileExist(file As String) As Boolean
Dim L As Long
    On Error GoTo FExErr
        L = FileLen(file)
            FileExist = True
        Exit Function
FExErr: FileExist = False
Exit Function
End Function

Conclusion

Merci a Draluorg qui a inventé cette source !!
 

Fichier Zip

Pour les "Membres Club", vous pouvez télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip

Historique

29 juin 2005 22:04:20 :
J'avais oublié de preciser pour les lents (lol) que il faut demarrer le projet par sub main() !!

Commentaires et avis

signaler à un administrateur
Commentaire de gagou9 le 22/06/2005 14:56:45

oups ya des fautes d'orthographe !!
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

signaler à un administrateur
Commentaire de jack le 22/06/2005 18:28:43 administrateur CS

Salut
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.

signaler à un administrateur
Commentaire de EBArtSoft le 22/06/2005 18:55:40 administrateur CS

Encore une fois le serpent qui se mord la queue !
Pour avoir les ocx faut demarrer l'appli et pour demarrer l'appli il faut avoir les ocx !

Aller zou dans le fourbi vbfrance...

signaler à un administrateur
Commentaire de BruNews le 22/06/2005 19:48:08 administrateur CS

Allez patience EB, reste plus que le dossier Windows et le sujet sera épuisé.

signaler à un administrateur
Commentaire de bouv le 23/06/2005 07:20:26

Rien de tel qu'une installation en bonne et due forme...

signaler à un administrateur
Commentaire de Patrice99 le 23/06/2005 08:40:28

> pour demarrer l'appli il faut avoir les ocx !

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

signaler à un administrateur
Commentaire de moustachu le 23/06/2005 12:00:06

>enregistrer les ocx
Encore faut-il avoir les droits... me tromp'je ?

++
Moustachu

signaler à un administrateur
Commentaire de Patrice99 le 23/06/2005 12:49:39

Oui ! cela requiert les droits Administrateur sur le poste de travail, sinon regsvr32 renvoi l'erreur n°0x8002801c (au fait on dit : "me trompé-je" et on prononce "me trompè-je")

signaler à un administrateur
Commentaire de moustachu le 23/06/2005 13:38:53

>(au fait on dit : "me trompé-je" et on prononce "me trompè-je")
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

signaler à un administrateur
Commentaire de Patrice99 le 23/06/2005 14:05:10

En VB6 c'est faux, cela ne marchera jamais ; en VB .Net, cela devrait marcher en théorie, mais en pratique j'ai été obliger de faire un .exe.config

signaler à un administrateur
Commentaire de bouv le 23/06/2005 14:36:25

Désolé de contredire, mais il me semble que Moustachu a raison.

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.

signaler à un administrateur
Commentaire de bouv le 23/06/2005 14:37:26

Cela dit il n'est pas bon d'enregistrer des DLL et OCX à tout va dans n'importe quel dossier !

signaler à un administrateur
Commentaire de Patrice99 le 23/06/2005 15:51:04

Les dll ActiveX doivent toujours être enregistrées, les dll de type API doivent toujours etre dans le repertoire système de Windows, je suis sur d'avoir déjà tout essayé pour VB6. Pour VB7, j'ai parlé trop vite : en fait le fichier .exe.config ne sert ici que pour déplacer les dll dans un sous-dossier de l'application.
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)

signaler à un administrateur
Commentaire de jack le 23/06/2005 18:59:07 administrateur CS

On peut aussi dire et écrire "me gourre-je ?"

signaler à un administrateur
Commentaire de EBArtSoft le 23/06/2005 20:03:15 administrateur CS

Faux> les dll peuvent etre n'importe ou du moment que le declare specifie le chemin ou bien que la dll est dans le dossier de l'appli (cf: loadlibrary utilisé par la vm vb).

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 ?

signaler à un administrateur
Commentaire de Patrice99 le 24/06/2005 08:54:58

> vb6fr.dll ne sert strictement a rien
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 ?

signaler à un administrateur
Commentaire de BruNews le 24/06/2005 09:03:10 administrateur CS

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.

signaler à un administrateur
Commentaire de Patrice99 le 24/06/2005 09:36:19

Ok, c'est plus clair maintenant, mais dépendre du répertoire courant, c'est pas le top quand même !

signaler à un administrateur
Commentaire de moustachu le 24/06/2005 09:46:16

Whaouu... quel niveau !! Pour mon expérience perso, il m'est arrivé de faire tourner une appli grace aux dlls présentes dans le répertoire de l'exécutable, mais c'était par erreur. En revanche, cela ne fonctionne pas toujours, certaines dll doivent être enregistrées pour fonctionner.

>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)

signaler à un administrateur
Commentaire de BruNews le 24/06/2005 09:52:55 administrateur CS

Bien entendu qu'un ActiveX doir être enregistré.
Si on parle de DLL sans préciser, c'est toujours de DLL API.

signaler à un administrateur
Commentaire de EBArtSoft le 24/06/2005 21:11:38 administrateur CS

Puisqu'il faut du concret... voila de quoi oublier definitivement vb6fr.dll http://www.vbfrance.fr/code.aspx?id=20160

Les sources de ce type pululle sur vbfrance...

@+

signaler à un administrateur
Commentaire de draluorg le 29/06/2005 20:19:33

Salut a tous,

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 @+

signaler à un administrateur
Commentaire de gagou9 le 29/06/2005 22:06:23

yo !
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

signaler à un administrateur
Commentaire de SuperPit37 le 03/07/2005 05:51:04

Déjas vu et en mieux !
http://www.vbfrance.com/code.aspx?id=29078
L'inovation ca a du bon, non?

signaler à un administrateur
Commentaire de gagou9 le 03/07/2005 10:59:14

en mieux ?
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

signaler à un administrateur
Commentaire de SuperPit37 le 05/08/2005 02:25:05

ah c sur c'est révolutionnaire ce que tu a fait vraiment tu ai trés fort qu'elle inovation enfin bref...

signaler à un administrateur
Commentaire de gagou9 le 05/08/2005 11:53:07

hé, est-ce que j'ai dit UNE fois que c'etait revolutionnaire ??
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

signaler à un administrateur
Commentaire de rt15 le 01/09/2005 19:35:22

Pour XP, on peut mettre des fichiers .Manifest qui remplace l'installation dans la base de registre:

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...

signaler à un administrateur
Commentaire de gagou9 le 01/09/2005 19:45:38

Salu!
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

signaler à un administrateur
Commentaire de rt15 le 05/09/2005 15:55:29

Salut Gagou9

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...

signaler à un administrateur
Commentaire de gagou9 le 09/09/2005 19:04:38

Salut !!
ç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

signaler à un administrateur
Commentaire de rt15 le 12/09/2005 15:01:29

Gagou9,

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 !

signaler à un administrateur
Commentaire de BruNews le 12/09/2005 15:20:34 administrateur CS

C'est tout à fait certain, regarde l'algo de recherche d'un module dans MSDN sur LoadLibrary.

signaler à un administrateur
Commentaire de rt15 le 12/09/2005 16:19:06

J'ai pas la MSDN...

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é...)

signaler à un administrateur
Commentaire de BruNews le 12/09/2005 16:24:41 administrateur CS

If no file name extension is specified in the lpFileName parameter, the default library extension .dll is appended. However, the file name string can include a trailing point character (.) to indicate that the module name has no extension. When no path is specified, the function searches for loaded modules whose base name matches the base name of the module to be loaded. If the name matches, the load succeeds. Otherwise, the function searches for the file. The search order used depends on the setting of the HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode value.

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.

signaler à un administrateur
Commentaire de BruNews le 12/09/2005 16:32:52 administrateur CS

rt15 > Bonjour le DELPHIste, je viens seulement de retrouver nos derniers échanges sur une de tes précédentes sources.

signaler à un administrateur
Commentaire de rt15 le 12/09/2005 16:35:42

The directory from which the application loaded.

C'est pas le dossier de l'exe ??????

signaler à un administrateur
Commentaire de rt15 le 12/09/2005 16:44:19

Ou alors on s'est mal compris...

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 ?

signaler à un administrateur
Commentaire de BruNews le 12/09/2005 16:45:19 administrateur CS

exact

signaler à un administrateur
Commentaire de BruNews le 12/09/2005 16:55:11 administrateur CS

dur dur les messages qui ne sont pas dans l'ordre:

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.

signaler à un administrateur
Commentaire de rt15 le 15/09/2005 10:41:56

Désolé BruNews,

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

signaler à un administrateur
Commentaire de BruNews le 15/09/2005 10:49:02 administrateur CS

Là c'est 'mal' jouer avec les mots:
"dossier où l'application a démarré" et "dossier ou le .exe a été chargé"
Je n'arrive pas à voir la différence.

signaler à un administrateur
Commentaire de rt15 le 15/09/2005 10:57:00

Tu sais que l'on peut démarrer une application dans un dossier.

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.

signaler à un administrateur
Commentaire de BruNews le 15/09/2005 11:06:42 administrateur CS

Bien entendu, c'est la différence entre currentDirectory et emplacement physique.
Il est clair que 'loaded' n'a aucun rapport avec la currentDirectory.

signaler à un administrateur
Commentaire de bouv le 15/09/2005 11:10:59

BruNews et RT15>> Je crois qu'il y a une erreur de compréhension entre vous. Je crois que ce qu'essai d'expliquer RT15 c'est que :

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.


signaler à un administrateur
Commentaire de rt15 le 15/09/2005 11:14:56

Donc on est d'accord que si les dlls sont dans le dossier contenant le .exe, elles seront chargés quel que soit le dossier courant.

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 !

signaler à un administrateur
Commentaire de rt15 le 15/09/2005 11:19:20

Oups encore mauvais aordre des message...

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.

signaler à un administrateur
Commentaire de BruNews le 15/09/2005 11:22:26 administrateur CS

BOUV > App.Path est obtenu par GetModuleFilename avec 0 en 1er param donc c'est toujours l'emplacement physique. CurDir vu son nom est bien sur la currentDirectory. J'espère bien que tout cela est évident pour tout le monde.

signaler à un administrateur
Commentaire de BruNews le 15/09/2005 11:24:53 administrateur CS

Mais non pas besoin, c'est écrit dans la description de l'algo de recherche de Loadlibrary, emplacement physique (loaded) est dans les 2 cas possibles donc à tout coup c'est bon.

signaler à un administrateur
Commentaire de bouv le 15/09/2005 21:49:14

Ok j'ai pigé votre différent...

BruNews>>Oui c'est bien clair.

signaler à un administrateur
Commentaire de jack le 17/09/2005 15:31:24 administrateur CS

... votre différend, avec un D
:-)
Jack, embrouilleur depuis 1959

signaler à un administrateur
Commentaire de gagou9 le 17/09/2005 18:02:49

hé bé dit donc ma chere source a l'aire de devenir un vrai forum
!!!!


loool

signaler à un administrateur
Commentaire de bouv le 18/09/2005 19:03:04

Jack>>Merci pour la correction, j'aurais jamais dit que cela s'écrivait avec un D.

On dit donc:

Un différend : En français
Un <> : en VB...

Bonne prog
++

signaler à un administrateur
Commentaire de jack le 18/09/2005 20:28:42 administrateur CS

Le chiffre est différent
Nous avons un différend

Maître Capello

signaler à un administrateur
Commentaire de bouv le 19/09/2005 07:35:52

Oui j'avais bien compris, c'était juste pour plaisanter.

signaler à un administrateur
Commentaire de rt15 le 21/09/2005 12:55:31

Gagou9,

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!!!!!!

signaler à un administrateur
Commentaire de pausezero le 19/04/2006 00:34:48

Me demande >>> A quoi bon programmer en Vb si notre application peut s'avérer inutilisable par l'utilisateur s'il n'a pas les dll et les ocx nécessaires a son fonctionnement... Autrement dit, si on veut que notre application soit applicable, il faudrais que l'utilisateur ait acheté VB. Donc, les applications Vb seraient-elle déstinées uniquement aux développeurs ?
OvO est un utilisateur s'étant appliqué a développer ce commentaire.

signaler à un administrateur
Commentaire de BruNews le 19/04/2006 00:43:52 administrateur CS

Un prog VB ne se distribue qu'avec un setup complet qui installera les runtimes VB sinon bien entendu qu'un prog VB ne tournera pas seul, c'est la différence entre le natif(C/C++ et ASM par exemple) et l'interprété (VB et .NET). Dans un cas l'exe contient toute sa logique et ne fait appel qu'aux fonctions du système pour l'affichage et trucs de ce genre et dans l'autre le code est à chaque tour traduit dans une virtual machine avant redirection vers les composants système.

Ajouter un commentaire



Nos sponsors

Sondage...

CalendriCode

Janvier 2009
LMMJVSD
   1234
567891011
12131415161718
19202122232425
262728293031 

Consulter la suite du CalendriCode

Côté IT