DLL - DÉBUTANT PAR ICI ! ! !
GuilleW
Messages postés
118
Date d'inscription
vendredi 18 avril 2003
Statut
Membre
Dernière intervention
28 décembre 2006
-
18 avril 2005 à 15:56
cs_ABF Messages postés 227 Date d'inscription samedi 21 mai 2005 Statut Membre Dernière intervention 26 avril 2012 - 22 mai 2008 à 12:46
cs_ABF Messages postés 227 Date d'inscription samedi 21 mai 2005 Statut Membre Dernière intervention 26 avril 2012 - 22 mai 2008 à 12:46
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/30828-dll-debutant-par-ici
https://codes-sources.commentcamarche.net/source/30828-dll-debutant-par-ici
22 mai 2008 à 12:46
Pas mal sinon ;)
++
25 mai 2006 à 17:00
14 nov. 2005 à 16:39
alors merci à tous pour les encouragements! Je post peu car j'y mais uniquement mes découvertes en cours d'aprentissage. Mais je penssais tout de même que c'était claire : andrebernard !
:p
bon courage à nous tous dans notre appretissage ( ba oui, suis comme vous, moi aussi j'suis débutant ! )
bye
11 nov. 2005 à 08:22
Alors la, je suis liquide.
Je savais que j'etait un debutant, mais la je viens de me rendre compte grace à ce code que je suis carrement une "BURNE".
En effet le code a moins de 10 ligne, et je tiens à remercier GuilleW qui a essayé de faire ce que tres tres peu de developpeur font, donner un code réduit au strict minimum.
Le seul bemol est le manque de commentaires sur les lignes importantes.
Eh oui je sais y'en a que 2/3 mais, moi je suis ce que l'on appelle vraiment un debutant de chez debutant.
Car qd on est autodidacte meme dans ce cas, il n'est pas toujours facile de comprendre les mecanismes et grand principes de l'utilisation de DLL.
Bref, malgres toute votre aide je n'ai rien compris.
Ce que j'aimerais faire, c'est utiliser une DLL faite en PureBasic dans VB6.
Les DLL sont elles toutes égales lorsq'elle sont créées par des programmes differents ????
Car celle que j'ai créé en PureBasic aussi simple que celle de GuilleW ne marche pas avec vb.
En effet, apres Qbasic et vb6 depuis peu, je viens de decouvrir la puissance de ce language qui reuni simplicité et performance.
Et avec lui, appeller une dll c'est hyper simple (comme tout d'ailleurs).
Donc si quelqu'un pouvait tendre la main à un infirme de la programmation, je lui serais reconnaissant pendant au moins trois vies.
Merci à tous pour avoir eu la gentillesse de me lire.
13 juil. 2005 à 15:01
19 juin 2005 à 22:50
28 mai 2005 à 23:47
28 mai 2005 à 02:15
http://ZoneZeus.free.fr
il s'agit d'un petit prog qui list les mangas traduit par la zeus team (pour ceux qui connaissent) : et oui en gros féneant et attendant toujours la traduction des nouveaux mangas, j'ai creer un prog qui lit le codes sources de leurs pages web et donc qui me renseigne de la sorties des mangas.
Toutes mes excuses, loin de moi l'idée de faire de la pub ( :p ) mais il y a surtout à dispo la source en VB de chaques version. En tant que debutant qui demandait comment créer une dll, voici où j'en suis arrivé. Bref encore une fois, Merci :)
Bye les gens !
GuilleW
27 mai 2005 à 00:08
5 mai 2005 à 17:52
- il y a une légère perte de temps puisque tu appelles une fonction externe (donc lancement de la dll, appel de la fonction, mise en place des variables nécessaires dans la pile mémoire et les registres puis nettoyage après l'appel par le programme ou la dll selon la convention d'appel)
- il existe 3 conventions d'appel (géré lors de la compilation de la dll). Celà gère justement la pile mémoire et le renvoi des variables sur la pile, sa création et son nettoyage (stdcall obligatoire pour appeller une dll dans vb)
- pas de gestion des pointeurs en vb ni des structures en tant qu'arguments donc il faut parfois trouver des astuces ou compliquer la liste des arguments...
il faut donc mettre çà en balance avec les gains principaux:
- l'éventuel gain en rapidité dans le cas de certaines utilisations précises
- modularité
- réutilisabilité (intérêt principal)
par exemple, si tu fais de gros accès à des fichiers ou des calculs complexes, le C est plus adapté que VB.
Si tu crée un programme de calcul scientifique, une dll n'est intéressante que si tu compte la réutiliser ailleurs sinon tu perds du temps inutilement
autre cas particulier, tu peux créer une dll inteface compilée en stdcall qui appelle une dll compilée en cdecl permettant d'accéder à des fonctions contenues dans une dll que vb ne peut pas appeller directement.
Pour en savoir plus il faut se plonger dedans car là je résume, chaque cas est particulier...
5 mai 2005 à 14:54
Library signifie bibliothèque et non librairie (qui se dit book shop) :)
5 mai 2005 à 14:28
et pour les inconvénients?
5 mai 2005 à 12:36
Pour la réponse 2 j'ajouterais que çà permet aussi de réduire la taille des executables puisque les fonctions communes à plusieurs programmes sont à part dans la ou les dll. Cà permet aussi de créer des fonctions (en C/C++ notamment) beaucoup plus rapides que VB qui peuvent ensuite etre appelées dans VB ou éventuellement dans un autre langage.
3 mai 2005 à 17:58
1 - Non, il n'est pas possible de faire une dll qui ne nécessite pas de regsvr32 en VB6, c'est ce qui en fait une faiblesse par rapport à vc++.
2 - L'avantage d'une dll par rapport à un module n'est pas dans la rapidité, mais principalement dans la réutilisation et dans la séparation des projets . Ainsi, lorsqu'on modifie par exemple la fonction de cryptage, pour faire accepter un autre type de cryptage, changer une boite de dialogue d'options de cryptage, etc..., il suffit de recompiler la dll avec comme option une compatibilité avec les versions précédentes, et de la mettre à jour pour ne pas avoir de problème .Ainsi, les dlls utilisées par windows se trouvent en un unique exemplaire (dans windows\system généralement), et une mise à jour de l'une (pour tenir compte de nouvelles fonctionnalités ou de bugs par exemple) se répercute automatiquement dans tous les prog. l'utilisant. Plus facile que d'avoir à compiler un énorme projet qui incluerait plusieurs modules. On sépare ainsi bien le logiciel des fonctionnalités annexes nécessaires (connexion à internet, utilisation de tel matériel, lecture de tel type de fichier, etc)..
VOili voilou ...
3 mai 2005 à 15:14
Je ne suis pas trés fort en Dll.
J'utilise plutot des "linked files" ou fichiers partagés.
Ce sont des modules ouverts par plusieurs projects.
M'evitant ainsi de copier coller un bout de code.
Alors j'aimerais qu'on m'explique les avantages inconvenients
d'utiliser des dll plutot que des linked files,
au niveau rapidité, simplicité, execution etc...
Merci
29 avril 2005 à 18:07
Ce qui revient au même que le fait de copier-coller le fichier dll.
29 avril 2005 à 11:30
Maintenant, expert à vous de nous dire si faire apelle à une dll est plus rapide que de faire des modules !
Merci.
28 avril 2005 à 22:00
Question bête : si une dll ne contient que des fonctions, pourquoi ne pas utiliser un module ou une classe intégrés à l'exe ?
Quel est l'intêret de la dll ?
26 avril 2005 à 11:09
Ton programme est clair mais je n'ai jamais fait de DLL sous VB.
Toutes les dll que j'ai faites sont en C et je n'ai pas besoin d'appeler regsrv32 pour m'en servir.
Pouvez vous me dire comment accéder cette dll sans l'enregistrer, c'est juste pour comprendre.
pour info mes dll ecrites en C sous VC++, compilées en C (pas C++) je les déclare de cette façon:
Declare Function Toto Lib "maDLL.dll" Alias "_Toto@4" (valeur As Long) As Long
et je peux utiliser la fonction Toto directement dans le code.
D'où ma question.
PS: DLL=Dynamic Link Library (bibliothèque de liens dynamique) pas de doute, c'est une fille ;)
25 avril 2005 à 11:23
22 avril 2005 à 02:30
C'est tout ! ! ! Et puis y'a personne pour me coriger dans ma tete lorsque je pense " une " :p
Enfin, merci pour votre mobilisation ça m'aide pas mal dans mon développement !
GuilleW
21 avril 2005 à 14:57
21 avril 2005 à 14:51
tbbuim:
A ce propos, DLL=Dynamic Link Library
>"librairie de liens dynamiques", une librairie donc UNE dll.. :) (pourquoi un?)
20 avril 2005 à 17:21
19 avril 2005 à 22:34
http://www.codeproject.com/dll/XDllPt1.asp
tu vas te régaler ... ++ bonne continuation ;)
19 avril 2005 à 19:31
Facile le travail des enregistrements...
Petite suggestion, sur un exe standard en mode main,
tu te creés une petite gestion par un fichier bat pour l enregistrement dll & ocx et une fois inscrite, lancement del'exe.
@+ Nisand-Systems
19 avril 2005 à 14:49
Pour GuilleW : je te dis que la méthode shell/regsvr32 que tu donnes fonctionne bien. C'est juste que la majorité des programmeurs aiment se tourner la tete et mettre le code complet pour éviter d'avoir à passer par un programme externe qui n'existera peut etre plus (ou pas avec le meme nom) dans les prochaines versions de windows.
Le problème est qu'un regsvr32 dans ton programme fonctionnera, mais si tu mets la dll en référence du programme, il ne pourra pas se lancer tant que le regsvr32 n'a pas été fait ... Il pourra donc pas autofaire le regsvr32. La solution est sinon de faire un loader : le programme lancé exécute un regsvr32, puis lance un autre exe. L'autre exe est le code principal, qui enfin sera lancé avec les dll référencées correctement.
Il faut quand meme savoir que la majorité des programmes d'installation (meme tous) sont capable d'enregistrer une dll... Voila pourquoi il est souvent préférable d'avoir un programme d'instal, et pas un bete exe dans un bete zip... enfin avec vb en tout cas ...
19 avril 2005 à 13:47
Donc justement lors d'un deploiement, si la personne l'install dans un dossier X, je connais juste le chemin relatif de la dll par rapport à mon .exe , comment faire ?
pourquoi IL font toujours des code super compliquer au lieu de faire juste un :
shell "regsvr32 /s ./DOssier_dll/Nom_de_la_DLL.dll"
voilà, si vous pouvez me donner la source necessaire à cette action :p
Merki :)
19 avril 2005 à 12:04
Mais reellement pas pratique du tout lors d'un deploiement a part bien sur l'interet que porte la dll dans l'application.
19 avril 2005 à 08:47
C'est vrai qu'ici, il peut utiliser une référence, et s'il regsvr32 son dll dans le chemin de l'application, alors ca fonctionnera. Mais il ne pourra pas regsvrer dans l'application, puisque au début, si elle trouve pas la référence, elle se lancera pas.
Ensuite, l'interêt du createobject est qu'il permet d'ajouter dynamiquement des dll. Par exemple, il peut ainsi gérer un nombre quelconque de plugins, il suffit de les copier dedans...
19 avril 2005 à 00:47
Merci, beaucoups pour votre aide !
18 avril 2005 à 20:20
Je vais voir le code.
JRB
18 avril 2005 à 17:23
Pas besoin de creer un CreateObject pour manipuler la dll meme sur exe deployé.
Le createobject est plus lent.
@+
Nisand-Systems
18 avril 2005 à 16:40
Pour vb, une dll (enfin du type com32, celle que tu utilise) est un objet, une "classe". Par exemple, pour une dll dont le nom de projet sera montexte, ce sera la classe montexte.
Lorsque tu ajoute une référence, il recherche la dll associée dans la base de registre. Cela nécessite d'avoir enregistré la dll (le célèbre regsvr32) afin que celle-ci ajoute dans la base de registre l'information : youhou, c'est moi, pour des infos sur montexte, c'est par ici.
Ta méthode nécessite de créer ce lien dans la base de registre dynamiquement. Mais alors, tu ne "voit" pas les objets que tu manipules puisqu'ils sont plus dans les références ...
Il faut utiliser quelques astuces ... :
En fait, la technique serait celle la :
Pendant tout ton développement, tu utilises ta méthode.
Mais tu fais bien attention a avoir un objet lié à la dll, même si c'est juste pour des méthodes.
Par exemple : dim truc as new montexte
truc.ecristexte("ahahah")
Etc ...
Ainsi, tu gardes les informations fournies par la référence.
A la fin, tu supprimes la référence, et tu rajoute à la place du dim plus haut :
dim truc as object
set truc = createobject("montexte")
Comme ca, il ira chercher dynamiquement l'information dans la base de registre... Il te reste plus qu'à ajouter avant le "createobject" une procédure qui enregistre (regsvr) la dll dans le répertoire. C'est par exemple faisable avec l'option /s (silent) de regsvr32...
Un exemple ici :
dim truc as object
shell "regsvr32 /s montexte.dll"
set truc=createobject("montexte")
Voila..
On peut faire ensuite un peu plus élégant, avec de l'héritage pour que la dll transmette la liste des objets (classes, ici montexte) qu'elle contient, il suffit qu'elle ait une méthode fixe...
Plus d'infos sur le premier programme que j'ai fait qui gérait ca ... :
http://www.vbfrance.com/code.aspx?ID=6010
Voila ...
Mon dernier prog gérant ca est directxperience, sur http://membres.lycos.fr/vnsoftware/
Tchaou
18 avril 2005 à 16:39
18 avril 2005 à 15:56
GuilleW