Active X versus dll

Version imprimable

24/04/2008, 11h33
maz

Active X versus dll

Bonjour je travaille actuellement sur un projet de logiciel pour commande d'instruments de laboratoire. Notre objectif est de fournir un ensemble de commande et fonctionnalités interchangeable avec différents instruments et différentes manipulations. Les premières idées tendent vers la création d'une dll appelant d'autre dll spécifiques aux instruments concernés.
L'autre idée est la création d'un objet COM (je ne suis pas trés familier avec ceci). Je voudrai savoir l'avantage et les inconvénients d'utiliser une dll comparer avec un Acive X ou objet COM (si j'ai bien compris c'est à peu prés la même chose). D'autre part est ce qu'il facile de porter des fonctions d'une dll vers un active X, selon quoi on peut commencer à travailler sur les fonctions de notre dll et on verra aprés pour l'active X ...
Pour faire un active X ou objet COM quel logiciel est le plus adéquat (je travaille avec visual studio 2005).

Merci d'avance
24/04/2008, 16h39
ram-0000

Mon avis (et je n'engage que moi):

DLL, c'est une "techno" plus facile à maitriser.
COM/Active X, c'est un peu plus touchy comme techno (attention, je n'ai pas dit insurmontable).

COM/ActiveX (en fait DCOM) supporte la notion d'object réparti sur le réseau (je ne sais pas si cela à un sens pour ce que tu veux faire). C'est à dire que tu peux avoir une appli sur une machine qui appelle un object DCOM instancié sur une autre machine.

L'interfaçage avec d'autre appli sera probablement plus portable/facile avec un ActiveX qu'avec une DLL. ActiveX, c'est prévu pour beaucoup d'applis.

Attention avec la DLL, si tu fais du C++, tu auras la "décoration" de tes noms de fonction en plus. Cette décoration n'est pas standardisés. Donc une DLL C++ complilée par un environnement Borland ne fonctionnera pas avec un programme compilé avec un environnement Microsoft

Mon avis à 0,01€
24/04/2008, 17h52
Médinoc

Note: Un objet COM, c'est tout simplement une DLL particulière.

L'avantage, c'est qu'une fois que la DLL respecte le standard COM, elle peut être appelée facilement depuis tout un lot de langages de manière "orientée objet".

Donc, s'il s'agit d'exporter des classes et non de simples fonctions, je conseille de faire une DLL COM.
25/04/2008, 13h08
nicroman

En fait... c'est un peu plus compliqué...

Une DLL c'est un stockage d'objets/fonctions pré-linkées...

Un objet COM est simplement un objet qui suit la règle de base de COM "Héritage (et implémentation) de IUnknown (AddRef, Release, QueryInterface)". On peu très bien faire des objets COM sans DLL.

Ensuite, reste à savoir si on veut utiliser les fonctions "avancées": CoCreateInstance et autres....
Pour celà, il existe plusieurs méthodes:
- Enregistrement au runtime des classes
- Enregistrement d'un serveur contenu dans une DLL (registry)
etc...
25/04/2008, 14h08
maz

OK je vous remercie tous pour ces précisions...
Dernière question quelqu'un a t'il un adresse de documentation concernant l'implementation d'un objet COM ou encore une example "template". MErci encore
25/04/2008, 17h59
Médinoc
Le problème, c'est qu'il y a pas mal de façons différentes d'en faire.
Même en C++ natif, il y a diverses bibliothèques:
- Notamment l'Active Template Library (ATL) de Microsoft.
- Les récentes versions de Visual supportent l'Attributed Programming, qui est plus ou moins un ATL compact.
Sans compter les autres langages, comme ceux dédiés au Framework .Net : Toute classe .Net peut être rendue visible depuis COM...

Voilà une implémentation d'un objet COM (pas très utile, une seule interface, mais suffisante...)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
class MyCOMObject : public IUnknown
{
    ULONG       m_uRefCount;
    IUnknown* m_pOuter;
 
public:
    inlien MyCOMObject(void) : m_uRefCount(0), m_pOuter(0) {}
    inlien MyCOMObject(IUnknown* pOuter) : m_uRefCount(0), m_pOuter(pOuter) {}
 
    /** @group IUnknown implementation */
    virtual STDAPI LONG      AddRef(void);
    virtual STDAPI LONG      Release(void);
    virtual STDAPI HRESULT     QueryInterface(REFIID riid, LPVOID* ppOut);
protected:
    virtual void CreateThis();
    virtual void DeleteThis();
};

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
void MyCOMObject::CreateThis()
{
    if (m_pOuter)
        m_pOuter->AddRef();
}
 
void MyCOMObject::DeleteThis()
{
    IUnknown* pOuter  m_pOuter;
    delete this;
    if (pOuter)
        pOuter->Release();
}
 
ULONG MyCOMObject::AddRef(void)
{
    ULONG ret = (ULONG) InterlockedIncrement((LONG*)&m_uRefCount);
    if (ret == 1)
        CreateThis();  // this doesn't need to be thread-safe, because this is the first reference on the object !!!
}
LONG MyCOMObject::Release(void)
{
    ULONG ret = (ULONG) InterlockedDecrement((LONG*)&m_uRefCount);
    if (ret == 0)
        DeleteThis(); // same as above, this is the last reference, no need to protect
}
HRESULT MyCOMObject::QueryInterface(REFIID riid, LPVOID* ppvOut)
{
    if (riid == IID_IUnknown) {
        *ppvOut = this;
        AddRef();
        return S_OK;
    } else
        return E_NOINTERFACE;
}

28/04/2008, 13h54
GeMyNy

Un autre avis :

- maintenance du code plus facile avec COM et activeX (si les interfaces ne sont pas modifiées pas besoin de recompiler les bouts de code utilisant les interfaces).
- l'appel d'un objet/service COM se révèle plus lent en exécution que l'utilisation d'objets présents dans une dll, et encore plus avec les activeX (utilisant des interfaces COM Automation plus gourmandes en ressources mais plus ouvertes pour une réutilisation dans d'autres langages).
Mais pour l'utilisation que tu comptes en faire, COM/activeX me semble un bon choix. Attention, l'apprentissage de l'utilisation de COM n'est pas trivial !