begin process at 2012 02 13 05:10:48
  Trouver un code source :
 
dans
 
Accueil > 

Code

 > 

OLE, DDE, Automation

 > LES DLLS SOUS VB6

LES DLLS SOUS VB6


 Information sur la source

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

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :OLE, DDE, Automation Classé sous :dll, activex, ole, tuto, exemple Niveau :Débutant Date de création :16/06/2005 Date de mise à jour :30/11/2005 13:13:37 Vu / téléchargé :25 569 / 2 731

Auteur : rt15

Ecrire un message privé
Commentaire sur cette source (39)
Ajouter un commentaire et/ou une note

 Description

Cliquez pour voir la capture en taille normale
A quoi servent les dlls ?
Les dlls servent généralement de fichiers de stockage de code compilé.
Ce code compilé devient accessible depuis n'importe quel exe.

L'avantage par rapport à utiliser des forms, modules et classes partagés dans plusieurs projets est que la mise à jour ce fait en recompilant la dll, et non en recompilant tous les exes.
Un autre intérêt peut survenir quand on fait une grosse appli: on peut compiler l'application par morceaux.

#### Création d'une dll:

Nouveau projet: "Dll ActiveX".
Mettre la propriété "Instancing" de la classe sur "GlobalMultiUse".
Cela permet d'utiliser les méthodes de cette classe depuis un exe.
Dans les propriétés du projet, dans l'onglet "Créer" cocher la case "Indentation automatique".
Cela permet à un programme d'installation de savoir s'il doit remplacer une dll déjà présente.
Renommé le projet et la classe, puis compilez la dll (Sans code !)
Dans les propriétés du projet, dans l'onglet "Composant" la case à cocher la case "Compatibilité binaire" est maintenant cochable: Cocher là !
Cela permet d'assurer la compatibilité au fil des recompilations de la dll, moyennant quelques précautions.
Il ne faut par exemple jamais supprimer une fonction, ou modifier ses paramètre (On ne peut même pas rajouter un paramètre optionel).

Pour employer les méthodes de la dll dans un exe, il faut référencer la dll.
Pour cela, dans le projet de l'exe, menu "Projet", puis "Références...".

#### Les dlls et la base de registre:

Pour fonctionner correctement, les dll ActiveX doivent être installées.
Autrement dit, il faut que des clés soient présentes dans la base de registre.
VB6 installe automatiquement la dll lors de la compilation.
Ces clés contiennent nottement le chemin d'accès de la dll.
En conséquence, une dll installée dans un répertoire ne fonctionne plus si on la déplace.
Et il est préférable de désinstaller la dll avant de la supprimer !
L'installation et la désinstallation peut ce faire via "Executer" ou le DOS.
Pour installer:
regsvr32 "CheminDeLaDll\NomDeLaDll.dll"
Pour désinstaller:
regsvr32 /U "CheminDeLaDll\NomDeLaDll.dll"

#### L'installation:

En ce qui concerne l'installation, l'empaqueteur de VB6 a mauvaise réputation.

On peut donc utiliser un autre utilitaire d'installation, par exemple Innosetup (Comment ça pas un exemple au hasard ?) :
http://www.progotop.com/dks/cours/TUTORIAL_Setup _VB6_InnoSetup_ISTools.pdf

Une autre méthode est basé sur des fichiers en langage de script, qui simule la base de registre.
Voici un lien vers un source qui automatise la création de ces fichers:
http://www.vbfrance.com/code.aspx?ID=2838 7

#### Le source:

Un exemple d'emplois de dll, ULTRA simple.

#### Remerciement:

DARKSIDIOUS
Qui à transcander le contenu de ce source par une remarque particulièrement pertinante !

Warny
Qui m'a expliqué comment faire des interfaces.


 Conclusion

N'oubliez pas de désinstaller la dll avant de supprimer mon source de votre disque !

 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip


 Historique

20 juin 2005 16:36:55 :
Beuh, j'ai juste changer 'le dll' en 'la dll'. Avant, je disait aussi tjs 'la source'.
20 juillet 2005 14:38:26 :
J'ai supprimé les batchs: avec les modification du source de l'exe, j'ai eu des prolèmes avec la référenciation de la dll... J'ai rajouté des boutons et un mode d'emplois (.txt). J'ai ajouter de nouvelles syntaxe d'appel que m'a donné . Je ne supporte plus les dlls VB. Désolé, mais vive Delphi !
29 juillet 2005 16:43:40 :
Une interface, copie presque conforme de celle de Warny. Une solution ultime, pour ceux qui sont au bord du suicide.
17 octobre 2005 10:01:58 :
Le source ne sert plus à rien suite à une excellente remarque de DARKSISIOUS.
27 octobre 2005 14:30:37 :
Le source n'a plus du tout le même but. De ne pas référencer, il est passer à référencé. Cela est dû à la case à cocher dont DARKSIDIOUS m'a appris l'existence.
30 novembre 2005 13:13:37 :
mots clés

 Sources du même auteur

Source avec Zip Source avec une capture APPLICATION CONSOLE
Source avec Zip Source avec une capture TRAITEMENT DES MESSAGES WINDOWS SOUS VB6
Source avec Zip Source avec une capture TIMER, SLEEP, CHRONOMÉTRAGE, VITESSE DU PROCESSEUR, A LA MIC...
Source avec Zip Source avec une capture FAITES GAFFE À DIR()
Source avec Zip Source avec une capture ECRAN DE VEILLE AQUARIUM.

 Sources de la même categorie

IMPORTATION DANS EXCEL DE DONNÉES D'UNE SOURCE AS400 (I5, IS... par Godzestla
Source avec Zip Source avec une capture Source .NET (Dotnet) EXCELDOTNET : PROGRAMMER EXCEL EN DOTNET SANS VBA NI VSTO par Patrice99
Source avec Zip Source avec une capture AJOUTEZ VOTRE COMPLÉMENT À VISUAL BASIC 6 SANS ÊTRE CONTRAIN... par VBsearch
Source avec Zip PILOTER ACROBAT READER DEPUIS EXCEL ET VBA par jpduf
Source avec Zip Source avec une capture INTERCEPTER DES APPELS DE METHODE (SURCHARGE DE VTABLE) par Renfield

 Sources en rapport avec celle ci

Source avec Zip Source avec une capture TROUVER LA CLASSID D'UNE DLL ACTIVEX par EBArtSoft
Source avec Zip Source avec une capture SURCHARGE D'OPERATEUR VB5/6 par EBArtSoft
Source avec Zip EXEMPLE POUR DÉBUTANTS (TABLE ASCII) par gt99
Source avec Zip ENREGISTREMENT FICHIERS ACTIVEX .OCX ET .DLL par mimiZanzan
Source avec Zip Source avec une capture INTERFACE POUR (UN)REGISTER DLL, OCX ET ACTIVEX EXE par vlhomme

Commentaires et avis

Commentaire de bouv le 16/06/2005 16:26:37

1°-La méthode CreateObject est "beaucoup" plus lente.
2°-Quand on fait une mise à jour de la dll, il faut la redistribuer, alors pourquoi ne pas redistribuer l'exe dont elle dépend en même temps.
3°-Comme dis dans le projet : attention les fonctions ne sont pas completez automatiquement. Cela peut prendre un certain temps lors de la programmation pour ne pas faire d'erreur.
4°-Je déconseille fortement les BATCH (question de virus et le code qu'il contient peut être appelé avec un simple Shell).

Enfin, bref vous aurez compris que je ne suis pas fan de cette méthode.

Commentaire de Patrice99 le 17/06/2005 09:25:49

La méthode avec createObject est appelée liaison tardive (à l'execution) par opposition à la liaison précoce ou anticipée (à la compilation). Pour info, tu n'as pas vraiment besoin de batch pour installer un ocx ou une dll activeX, tu peux le faire carrément depuis VB6 avec un Shell Regsvr32, voir : www.vbfrance.com/code.aspx?ID=17783
Personnellement, j'utilise systématiquement la liaison tardive pour que mes logiciels fonctionnent à coup sur partout. Mais je debogue souvent en liaison précoce, c'est plus pratique.

Commentaire de rt15 le 20/06/2005 16:35:27 administrateur CS

Salut BOUV,

Effectivement, la recompilation de l'exe règle le problème. Mais dans le cas de plusieurs applications référençant la même dll, tu recompiles et redistribus tous les exe ?

Pour ce qui est des batchs, du fait que pratiquement tout le monde puisse lire le source, je trouve que ce sont de très mauvais vecteurs de virus et autres trojans.

Je n'aime pas CreateObject, je ne l'utilise que parce que référencer pose des problèmes de mise à jour.


Salut Patrice99,

Effectivement aussi, on peut utiliser un shell.

Toutefois, l'utilisation de batchs peut parfois s'avérer utile, je pense.

Exemple:
shell "regsvr32 msvbvm60.dll"
VB ayant besoin de ce dll, il peut diffcilement l'installer.

Autre exemple:
shell "regsvr32 comctl32.ocx"
Si un contrôle de ce fichier se trouve sur une form, le prog risque de planter au moins la première fois.

Quoiqu'il en soit, il faudrait faire attention de ne pas installer un fichier de version anterieure à celle précédement installer sur le PC, sinon de beaux logiciel tout neuf risquent de planter. (Mais faire attention, c'est plus facile à dire qu'à faire...)

Commentaire de Patrice99 le 21/06/2005 08:36:45

>Autre exemple:
>shell "regsvr32 comctl32.ocx"
>Si un contrôle de ce fichier se trouve sur une form, le prog risque de planter au moins la première fois.

Pas du tout, il suffit de démarrer sur un module : main(), et de faire les vérifications et eventuellement les traitements appropriés, regarde ici :
www.vbfrance.com/code.aspx?ID=17783

>Quoiqu'il en soit, il faudrait faire attention de ne pas installer un fichier de version anterieure à celle précédement installer sur le PC, sinon de beaux logiciel tout neuf risquent de planter. (Mais faire attention, c'est plus facile à dire qu'à faire...)

Ce n'est pas si difficile, il suffit d'essayer d'instancier l'objet, et si cela fonctionne, alors il n'est pas besoin de le faire, et ainsi, cela peut fonctionner avec des dll ou ocx compatibles de facon ascendante, même avec des versions différentes.

Commentaire de rt15 le 23/06/2005 14:35:08 administrateur CS

Bien vu Patrice99!

Commentaire de Warny le 11/07/2005 11:17:18

CreateObject ne fait pas une liaison tardive !!!! Il permet seulement d'instancier la classe

si je fait
dim fso as scripting.filesystemobject
set fso = createobject("scripting.filesystemobject")
c'est une liaison précoce parce que j'indique le type de la classe et que le compilateur peut préparer tous les appels de fonctions

si je fait
dim fso as object
set fso = new scripting.filesystemobject
c'est une liaison tardive, parce que le programme doit vérifier le type à chaque appel d'une fonction

comme vous pouvez le voir, la liaison tardive n'est pas liée au createobject.
Si vous voulez utiliser des objets indiférenciés, utilisez au maximum des interfaces communes qu'implémentent ces objets.

Commentaire de Warny le 11/07/2005 11:25:41

A propos, la liaison précoce (early binding) permet d'accélerer la vitesse d'execution par 20 environ

Commentaire de rt15 le 12/07/2005 10:41:55 administrateur CS

Warny, merci pour tes explications, même si elle ne sont pas tout à fait claire pour moi.
Je vais essayer tes syntaxes et très probablement les inclures dans mon sources.

Si j'ai bien compris, la première ne devrait pas passer mon test, mais la deuxième si.

20 fois plus lente, mais 20 fois plus compatible!

Commentaire de Warny le 12/07/2005 10:47:23

En réalité pour être compatible il faut créer une dll vide de code avec les interfaces des objets (les déclarations des objets des fonctions sans implémentation) et les implémenter dans une autre dll (grâce au mot clef Implements).
Si MyClass implémente MyInterface je peut faire :

Dim MyObject as MyInterface
set MyObject = createObject("MyDll.MyClass")

Et magie, je peux utiliser une dll indiférenciée avec une liaison précoce.

Commentaire de rt15 le 12/07/2005 11:23:25 administrateur CS

Effectivement, j'en ai entendu parler.

Si je comprend ton bout de code, il me parait très intéressant.

A ce que j'ai compris, on peux recompiler la dll où les fonctions sont implémentée, mais pas la dll interface.

Mais peut on rajouter une fonction ?

Commentaire de Warny le 12/07/2005 11:32:01

Je suppose que si tu veux rajouter une fonction, c'est pour l'utiliser, non ? Dans ce cas tu mettras à jour ton programme, ton interface et ta classe.
Sinon, tu peux rajouter autant de fonctions privées que tu veux.

Commentaire de rt15 le 20/07/2005 14:35:44 administrateur CS

Les dlls, en général, je m'en sert dans plusieurs programmes.

J'ai récupéré un bout exemple d'interface, mais avec une seule dll et je ne parviens pas à y faire fonctionner.

Warny, tu saurais pas où je peux trouver un autre exemple, ou me fournir un peu plus d'explications ?

Merci d'avance.

Commentaire de Warny le 21/07/2005 09:43:26

Aïe j'ai pas d'exemple. Voilà comment il faut faire

Class toto

Function Test() as string
    'Doit être vide
End Function

Class Tutu
Implements Toto

Function Toto_Test() As string
    'définition de la fonction
End Function

Class Utilisation
Sub Main()
    Dim Objet as Toto
    Set Objet = createObject("myDll.Tutu")

    Objet.test
End sub

Commentaire de rt15 le 23/07/2005 10:58:50 administrateur CS

Je vais voir ce que je peux faire.

Bel arrachage de cheveux en perspective!

Merci quand même Warny!

Commentaire de rt15 le 29/07/2005 16:44:11 administrateur CS

Warny, nickel ce que tu m'as donné.

J'ai pratiquement pas eu de messages d'erreurs.

Je l'ai inclus dans le source.

Pour ce que j'ai vu de cette méthode, elle est un peu lourde (2 dlls).

(on peut aussi mettre les 2 classes dans l'exe, mais je ne suis pas parvenu à n'avoir qu'une dll et un exe)

Il faut définir une fois pour toute l'interface, puis on peut compiler la dll d'implémentation et l'exe comme on veut.

Probablement la meilleur méthode si:

On souhaite une dll rapide.
On connait d'avance les fonctions dont on aurat besoin.
On veut partager la dll tout en pouvant la recompiler.

De même, je pense qu'il vaut mieux référencer si:

On souhaite une dll rapide.
On connait d'avance les fonctions dont on aurat besoin.
La dll est utilisée par un seul exe.

Ou si:

La dll sera compilée une bonne fois pour toutes.

Et enfin, il vaux mieux utiliser du Dim ... As Object avec du Createobject si:

On veut pouvoir rajouter des fonctions à la dll.
La dll sera utilisée par de multiples applications sur de multiples PC en de multiples versions.
La vitesse n'est pas primordiale.

J'allais oublier ma méthode ultime, qui est, je crois, la meilleure dans tous les cas.

Je serai ravis d'être contredis !

Si quelqu'un connait une source mieux ou veut en faire une mieux, ça m'arrengerai bien de trouver un remplaçant sur ce sujet épineux et complexe.

Commentaire de DARKSIDIOUS le 12/10/2005 21:24:32 administrateur CS

Lol, que dire de plus que ce que je t'ai dit sur le forum : compiler des dll sans aucune compatibilité ou en compatibilité des projets, et tu t'étonne après qu'il faut tout recompiler...

Donc un conseil : lorsque tu fait des dll, coche la case "Compatibilité binaire" dans les options de ton projet, et tu verra que ca marche tout de suite bien mieux pour distribuer tes dll !

Et là, tu peux oublier tes références tardives ou autres fichier batch.

DarK Sidious

Commentaire de rt15 le 13/10/2005 09:54:16 administrateur CS

Aïe.

"Compatibilité binaire"

Connaisssais pas !

Désolé.

Bah je vais essayer.

C'est vrai que cette histoire de recompilation d'exe était bizarre. N'empèche, la case n'est pas cochée par défaut !!!!!

Je suis un fervant utilisateur des dlls, mais cette histoire de recompilation de l'exe m'avait dégouté de celles de VB6.

Commentaire de bouv le 13/10/2005 10:02:19

Je connaissais pas non plus la Compatibilité binaire.

Il semblerait effectivement que la solution se trouve là. :-)

Je m'en vais essayer !

Commentaire de rt15 le 13/10/2005 14:34:14 administrateur CS

Ce source ne sert plus à rrrrrrrriiiiiiiiiiieeeeeeeeeeeeeennnnnnnnnnnnnnnnnn.

Merci DARKSIDIOUS.

La case à cocher compatibilité binaire est dans l'onglet composant des propriétés du projet de la dll.

Je vous conseil vivement de la sélectionner.

Je suppose que cela permet de conserver les offsets des appels de fonctions constants (Le code doit donc être rangé de façon assez moche...).

Mais pourquoi qu'elle est pas coché par défaut ???????

Il faut que je remette ce source à jour, et là je suis comme un gland devant un terminal X (On peut rien en faire à part taper dessus).

Commentaire de DARKSIDIOUS le 13/10/2005 15:01:04 administrateur CS

Ben en fait, en mode sans compatibilité, VB ne conserve aucune référence à de prétendu ancienne version de la dll.
En mode compatibilité des projets, VB conserve une référence avec l'ancienne dll pour quelle puisse être utilisée plus facilement dans les projets qui l'exploite (sans devoir la référencer de nouveau donc), mais pas avec les exe qui l'utilise puisqu'il change le CLSID de la classe principale.
En mode compatibilité binaire, seule le contenu de la dll est modifié, le CLSID n'étant pas modifié, c'est comme si vous aviez exactement la même dll, mais avec des fonctionnalités en plus ou modifiées.

Un autre conseil : cochez l'incrémentation automatique du numéro de version pour savoir où vous en êtes dans les versions lors du déploiement de vos dll, cela évite de grande surprise (exemple : InnoSetup, mais je pense que les autres font de même) ne remplace pas les dll si elles possèdent un numéro de version égal à la dll déjà installé.

DarK Sidious

Commentaire de Warny le 13/10/2005 15:04:30

La méthode que j'ai proposée n'a pas du tout cette utilité. Elle permet d'avoir plusieurs classes avec la même interface (signature) qui peuvent être appelées et référencées indiférement.

Commentaire de DARKSIDIOUS le 13/10/2005 15:15:37 administrateur CS

Oui, c'est le principe "d'héritage" de vb6, c'est pratique, mais très peu utilisée j'ai l'impression (perso, j'utilise pas, et j'ai très rarement vu un code utilisant les implements !).

DarK Sidious

Commentaire de rt15 le 13/10/2005 15:28:40 administrateur CS

Warny,

C'est vrai que je vois plus trops l'intérêt de cette méthode. J'ai entendu dire qu'elle permet de faire passer des arguments de types différents de ceux qui étaient prévu ou je sais plus trops quoi. Mais elle est quand même très lourde à mettre en oeuvre.

DARKSIDIOUS,

En mode sans compatibilité, le CLSID est conservé, comme en mode compatibilité binaire.

Commentaire de DARKSIDIOUS le 13/10/2005 15:31:38 administrateur CS

Il me semble que non : l'ancien CLSID est conservé (pour l'ancienne dll), par contre, un nouveau CLSID est crée pour la nouvelle dll !

Donc je te raconte pas à quoi ressemble le registre lorsque tu compile une dizaine de fois des ActiveX avec une dizaine de classe publiques en mode sans compatibilité !

DarK Sidious

Commentaire de Warny le 13/10/2005 15:40:21

Darksidious -> la méthode est beaucoup plus utilisée que tu le penses. Les objets iads en sont une bonne preuve (ils sont programmés en C je sais... mais le principe y est)
La méthode sert surtout à faire des boites à outils, comme en vrai objet... (vive le .net)

RT15 -> en mode sans compatibilité tu perds bien le ClsID. Tout ajout d'une fonction publique à ta dll le fait perdre aussi d'ailleur.

Commentaire de DARKSIDIOUS le 13/10/2005 15:48:26 administrateur CS

Ah non, un ajout d'une fonction publique conserve la compatibilité (heureusement d'ailleurs, qui peut le plus peut le moins !), par contre, une suppression ou une modification dans le prototype d'une fonction publique existante, là oui, tu perds la compatibilité !

DarK Sidious

Commentaire de rt15 le 13/10/2005 16:07:23 administrateur CS

Je suis sur deux échanges houleux en même temps !

En mode sans compatibilité on ne perd pas le CLSID.

Je crois avoir passé suffisament de temps dans ma base de registre pour le savoir.

Commentaire de Patrice99 le 13/10/2005 16:30:52

Si on corrige des bugs ou si on ajoute des fonctions, il est intéressant de conserver la compatibilité binaire, car qui peut le plus peut le moins, effectivement. Par contre, si on décide de ne plus implémenter une fonction ou bien de changer la logique métier (par exemple la fonction "Operation" va faire autre chose maintenant), alors dans ce cas il ne faut pas conserver la compatibilité binaire, afin de s'assurer que personne n'utilise la dll à mauvais escient.

Commentaire de rt15 le 13/10/2005 16:39:02 administrateur CS

A mon avis, il vaut mieux faire comme Windows !

LoadLibrary n'était plus sastisfaisante.

Alors ils ont fait LoadLibraryEx qui prend des arguments différents.

Et transformer la routine LoadLibrary en un appel de loadlibraryEx en transmettant et complètant les arguments!

A mon avis, donc, il vaux mieux créer une nouvelle fonction que prendre des risques d'incompatibilité.

Commentaire de DARKSIDIOUS le 13/10/2005 17:02:18 administrateur CS

Je suis tout à fait d'accord avec toi rt15 : tu veux modifier complètement une fonction de ta dll pour qu'elle fasse des choses totalement différentes ? Alors pourquoi ne pas faire une fonction à part avec un nom différent ? Car si tu ne fait pas comme cà, tu es obligé d'abandonner la compatibilité, et là, tout tes clients sont hyper content : ils ne peuvent plus utiliser ta dll car l'appel à la fonction plante avec la nouvelle version de la dll.

Microsoft l'a bien compris en gardant les fonctions obsolètes tout de même opérationnelles depuis Windows 95 ! (ils vont quand même en supprimer pas mal pour le passage à Vista apparement).

DarK Sidious

Commentaire de rt15 le 17/10/2005 09:57:34 administrateur CS

Pardon, c'tait ici l'ERRATUM. Le CLSID change effectivement à chaque compilation (Comment j'ai fait pour pas le voir ?????) Désolé.

Je sais plus trops quoi faire de ce source...

Commentaire de Warny le 17/10/2005 10:00:00

Le mettre à jour et expliquer comment fonctionne la compilation de dll, éventuellement, expliquer comment upgrader une dll ou comment faire une boite à outil extensible.

Commentaire de rt15 le 17/10/2005 10:04:50 administrateur CS

Ouaich pour la compilation, mais je sais pas ce qu'est une boîte à outil...

Je vois pas ce que ta méthode fait de plus (deux dlls pour une dll d'interface ?).

Commentaire de Warny le 17/10/2005 10:12:30

Elle permet justement de faire une boite à outil.
Il s'agit principalement de la création de classe ayant la même interface (càd: implémentant la même classe).
si MyInterface est mon interface de base
et si :
   -MyClass1
   -MyClass2
sont deux classe implémentant MyInterface, tu peux appeler l'une ou l'autre indiféremment.
Par exemple faire un lecteur de fichier texte csv et un autre pour les champs à largeur fixes.

Commentaire de rt15 le 17/10/2005 18:39:38 administrateur CS

La seule différence entre ces deux logiciels serait la dll d'implémentation, c'est ça ?

Ou alors, est ce que l'implémentatons est choisie au moment de l'execution ?

Commentaire de Warny le 17/10/2005 18:41:39

L'implémentation serait choisi au moment de l'execution. Tout l'interêt est là.

Commentaire de rt15 le 17/10/2005 18:50:02 administrateur CS

OK, je vais faire ça aussi.

Commentaire de rt15 le 27/10/2005 14:47:28 administrateur CS

Voilou, c'est fait.
Si ça se voit pas encore, c'est encore la faute à la mise en cache.
Bah le source est maintenant proche du néant.
Par contre, je me suis appliqué sur la description !

Warny,
J'ai eu pas mal de problèmes pour l'interface...
En plus des bugs et autres messages d'erreur habituel, je crois que VB6 a refusé que la déclaration des implémentations diffères de celle des interfaces. J'avais mis aucun type dans l'interface, long dans une implémentation, et integer dans la dernière.
N'empèche, 3 classes, ça commence à faire beaucoup, même si on les regroupe.
Bilan, j'ai retiré l'exemple d'interface de mon source. C'est vrai que la surcharge des opérateurs peut être parfois bien pratique, mais là, c'est un peu lourd. Désolé.

Commentaire de cyrilp le 16/10/2006 20:08:00

Mouais...

Dans les règles de l'art du développement, il est préférable de ne jamais casser une interface. Par exemple, j'ai créé une classe "cTest" dans ma DLL ActiveX "DllTest.dll". Si je créé une fonction publique "TEST", une fois compilé, il ne faut plus supprimer cette fonction, ou modifier le type et le nombre de ses paramètres.

Une fois ces postulats respectés, il suffit de compiler en "compatibilité binaire" et il n'y aura plus jamais de problème et la liaison précoce peut être utilisée !!!

 Ajouter un commentaire


Discussions en rapport avec ce code source dans le forum

Point d'entrée d'une fonction introuvable dans une dll activex [ par Fizzo ] Bonjour à tous.J'ai créer une dll activex sous vb contenant des informations nécessaire à l'exécution d'un .exe vb lui aussi.Mais voilà, problème!Lors ActiveX.exe et ActiveX.dll [ par Philtous ] Salut à vous, J'aimerais savoir si c'est possible de me donner un exemple simple (facile à comprendre) d'un ActiveX.exe ou .dll en VB.Merci,Philippe Passage d'un tableau de byte à une fonction encapsulé dans un ACtiveX Dll [ par novik ] J'aimerai pouvoir passer un tableau de Byte a ma fonction (Activex Dll)lors de l'appel j'ai une erreur Type Mismatch.Or lorsque j'appelle cette foncti Détection d'OS ???? [ par Raf ] Bonjour,Je souhaiterai détecter grâce à une DLL (par exemple) le systéme d'exploitation d'un PC.En effet, si le PC tourne avec win 95/98 par exemple i Comment démarrer une DLL ActiveX avec un browser autre que IE? [ par Fr@nck ] Comment démarrer une DLL ActiveX avec un browser autre que IE?Merci de me répondre.Fr@nck Pb appel ActiveX DLL (ASP 0115) [ par Christo ] Bonjour ! J'ai un big pb. Pas de solution en vue :-( J'ai développé (sous VB6) une DLL. J'appelle celle-ci dans mes pages ASP avec le fameux "serv Dll non ActiveX en VB ? [ par Raptor ] Il parait qu'on peut créer des Dll non ActiveX en VB ????(un message ici => http://www.vbfrance.com/article.asp?Val=307) Si quelque'un sait, peut i DHTML [ par seb ] Quand j'ai fini mon projet en DHTML, toutes mes pages sonnt au format *.htm et les codes sont compilés en un *.dllQuand j'exécute avec IE, la form ne Pb creation de dll activex [ par stef_2001 ] Bonjour, je suis un presque nouveau venu dans VB...J'essaye de créer une dll active x. jusque, la pas de pb.C'est lorsque que je crée une Sub privée a


Nos sponsors


Sondage...

CalendriCode

Février 2012
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
272829    

Consulter la suite du CalendriCode

 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 2,870 sec (3)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales