Dll ou Ocx en VB6

Le
Luigi
Bonjour à tous
Je mets un peu d'ordre dans toutes mes sources e j'en ai marre de
recompiler tous mes programmes lorsque je modifie un module de classe.
J'ai décidé donc de créer des librairies réentrantes mais je ne me
décide pas si employer des OCX ou des DLL.
Quelque spécialiste parmi vous pourrait m'expliquer la différence?
Rapidité, compatibilité, place mémoire, réantrance etc
Merci d'avance
Luigi
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
François Picalausa
Le #15390161
On Nov 1, 7:23 pm, Luigi
<snip>je ne me
décide pas si employer des OCX ou des DLL.
Quelque spécialiste parmi vous pourrait m'expliquer la différence?<sn ip>



Hello,

Les OCX sont des dll qui ont pour vocation de contenir des contrôles
utilisateur. Les autres DLL (COM) ont juste pour but d'offrir divers
services sous forme de composants réutilisables. Néanmoins, on peut
faire des ocx qui ne contiennent pas de contrôles utilisateurs et des
DLL qui en contiennent. Il n'y a fondamentalement aucune différence
entre les deux (excepté l'extension de fichier, et du fait qu'un
développeur attends d'un ocx de fournir des contrôles).

Bref, si tu veux packager un contrôle utilisateur, préfères un OCX.
Pour le reste emploie une DLL.

François
Luigi
Le #15390151
On 1 nov, 20:16, François Picalausa
On Nov 1, 7:23 pm, Luigi
> <snip>je ne me
> décide pas si employer des OCX ou des DLL.
> Quelque spécialiste parmi vous pourrait m'expliquer la différence?< snip>

Hello,

Les OCX sont des dll qui ont pour vocation de contenir des contrôles
utilisateur. Les autres DLL (COM) ont juste pour but d'offrir divers
services sous forme de composants réutilisables. Néanmoins, on peut
faire des ocx qui ne contiennent pas de contrôles utilisateurs et des
DLL qui en contiennent. Il n'y a fondamentalement aucune différence
entre les deux (excepté l'extension de fichier, et du fait qu'un
développeur attends d'un ocx de fournir des contrôles).

Bref, si tu veux packager un contrôle utilisateur, préfères un OCX.
Pour le reste emploie une DLL.

François



Merci François
Bien à toi
Luigi
Jacques93
Le #15390111
Bonjour François Picalausa,
François Picalausa a écrit :
On Nov 1, 7:23 pm, Luigi
<snip>je ne me
décide pas si employer des OCX ou des DLL.
Quelque spécialiste parmi vous pourrait m'expliquer la différence?<snip>



Hello,

Les OCX sont des dll qui ont pour vocation de contenir des contrôles
utilisateur.



Il est un peu tard, François, mais ne peut on pas avoir des ocx
invisibles (donc sans interfaces visibles comme winsock), et des dll
visibles qui permettent de déborder des Forms VB. A mon sens au départ
c'est totalement différant

Les autres DLL (COM) ont juste pour but d'offrir divers
services sous forme de composants réutilisables. Néanmoins, on peut
faire des ocx qui ne contiennent pas de contrôles utilisateurs et des
DLL qui en contiennent. Il n'y a fondamentalement aucune différence
entre les deux (excepté l'extension de fichier, et du fait qu'un
développeur attends d'un ocx de fournir des contrôles).

Bref, si tu veux packager un contrôle utilisateur, préfères un OCX.
Pour le reste emploie une DLL.



Si le contrôle n'a pas besoin d'interface, pourquoi ?

Et on peux très bien associer une Dll 'Hors Process', d'un Ocx 'In
Process' ;-)

--
Cordialement,

Jacques.
François Picalausa
Le #15390091
Hello,

On Nov 1, 11:04 pm, Jacques93 wrote:
Bonjour François Picalausa,
François Picalausa a écrit :

> On Nov 1, 7:23 pm, Luigi >> <snip>je ne me
>> décide pas si employer des OCX ou des DLL.
>> Quelque spécialiste parmi vous pourrait m'expliquer la différence? <snip>

> Hello,

> Les OCX sont des dll qui ont pour vocation de contenir des contrôles
> utilisateur.

Il est un peu tard, François, mais ne peut on pas avoir des ocx
invisibles (donc sans interfaces visibles comme winsock), et des dll
visibles qui permettent de déborder des Forms VB. A mon sens au départ
c'est totalement différant



- l'ocx est la dll qui package un usercontrol (contrôle utilisateur)..
et ne peut être invisible que comme "fichier invisible"
- un contrôle utilisateur peut être invisible au runtime, mais
néanmoins, ça restera un contrôle utilisateur (du moins, si on prend
pour définition de contrôle utilisateur un composant implémentant
l'interface IOleControl, c'est à dire un contrôle ActiveX, ce qui peut
être discuté)
- une dll a bien entendu le droit d'exposer des objets implémentant
IOleControl ou d'afficher des forms, si ça fait partie de ses
compétences. Mais si le but est juste de fournir un contrôle ActiveX,
la sémantique associée à une dll n'est pas forcément aussi appropri ée
que celle d'un ocx.

Cela étant, je le concède, le terme "vocation" était probablement trop
fort, dans la mesure où l'ocx ne se différencie pas d'une dll et ne
fournit pas de mécanisme permettant d'être plus approrié.


> Les autres DLL (COM) ont juste pour but d'offrir divers
> services sous forme de composants réutilisables. Néanmoins, on peut
> faire des ocx qui ne contiennent pas de contrôles utilisateurs et des
> DLL qui en contiennent. Il n'y a fondamentalement aucune différence
> entre les deux (excepté l'extension de fichier, et du fait qu'un
> développeur attends d'un ocx de fournir des contrôles).

> Bref, si tu veux packager un contrôle utilisateur, préfères un OC X.
> Pour le reste emploie une DLL.

Si le contrôle n'a pas besoin d'interface, pourquoi ?



Parce qu'il implémente IOleControl et que OCX tient lieu de OLE
Control Extension... probablement (naturellement, c'est discutable).

Cela étant, on peut compiler un "ocx" contenant un (ou plusieurs
d'ailleurs) contrôles active X (ou autre composants, d'ailleurs), puis
le désenregistrer, le renommer en dll, le réenregistrer, et continuer
avec cette "dll". De la même manière peut nommer des fichiers .inf
ou .cfg en .ini, ou des .xhtml en .xml. Il y a juste une perte de sens
qui n'empêche pas les applications de tourner ( si du moins elles
s'attendent à chercher un .ini plutôt qu'un .cfg)

Mais reste encore la question de "Pourquoi mon contrôle implémente-t-
il IOleControl s'il veut pas interagir avec l'utilisateur?" (ou
encore, pourquoi je dois avoir une form pour utiliser le contrôle
Winsock?). Je laisse à chaque concepteur de contrôle ActiveX sans
"interface" de répondre à la question ;-)

Et on peux très bien associer une Dll 'Hors Process', d'un Ocx 'In
Process' ;-)



On peut, tout du moins, associer un composant COM hors process avec un
autre composant COM in process, peu importe qu'il s'agisse d'un
contrôle ActiveX ou autre et peu importe le nom du fichier conteneur.
Néanmoins, si la dll fournissant le composant com hors process, qui
lui même utilise le contrôle activeX in processs, a pour seul but de
fournir un autre contrôle activeX, l'extension ocx serait probablement
appropriée. Mais ça, c'est une autre histoire!

François
Publicité
Poster une réponse
Anonyme