J'ai une utilisation qui pilote diff=E9rent mat=E9riel : carte
sp=E9cifique, port s=E9rie, =E9thernet, ...
pour s=E9parer le reste de l'application de cette partie sp=E9cifique,
j'ai =E9crit cette derniere dans des DLL qui font officent de plugin
pour l'application g=E9n=E9rale. une DLL pour ma carte sp=E9cifique, une
DLL pour le port s=E9rie, ...
- La DLL pilotant ma carte sp=E9cifique utilise le driver de celle-ci
qui utilise apparement COM.
- J'ai une autre DLL pour faire de l'OPC qui lui aussi utilise COM.
Le probleme est que lorsque j'utilise les 2 =E0 la fois, ca ne marche
pas parceque le driver de ma carte "monopolise" COM ou initialise
incorrectement COM, si bien que ma couche OPC, ne fonctionne pas. Si je
d=E9marre la DLL OPC en premier, ca marche mais lorsque vient le tour de
la DLL de ma carte de d=E9marrer ca plante lamentablement le PC :(
N'=E9tant pas super sp=E9cialiste en COM, y'aurait-il une issue =E0 mon pb
?
J'ai trouv=E9 une alternative =E0 mon pb mais qui me satisfait guere :
j'ai r=E9-=E9crit mes plugin DLL en plugin EXE avec serveur TCP
embarqu=E9, comme cela chaque process initialize COM comme il veut et sa
fonctionne. Mais c'est beaucoup plus souple et plus fiable de dialoguer
avec les fonctions d'une DLL qu'on a charg=E9 avec LoadLibrary plutot
que de faire toutes les transactions via serveur TCP.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Burel
Hello,
A mon sens, y'a seulement trois chose à savoir sur CoInitialize(NULL)
1 - Stocker le retour de cette fonction, et faire un Unitialize si et seulement si ce retour était S_OK. 2 - Ne jamais appeler cette fonction dans la DLLMAIN sur un PROCESS_ATTACH par exemple. ca peux créer des blocages imprévisibles sur des LoadLibrary par exemple. De manière générale, ne jamais appeller d'API dans un DLLMAIN. 3 - Appelez CoInitialize dans tous les THREAD qui se servent de COM.
VB
"PurL" wrote in message news: Bonjour,
J'ai une utilisation qui pilote différent matériel : carte spécifique, port série, éthernet, ... pour séparer le reste de l'application de cette partie spécifique, j'ai écrit cette derniere dans des DLL qui font officent de plugin pour l'application générale. une DLL pour ma carte spécifique, une DLL pour le port série, ...
- La DLL pilotant ma carte spécifique utilise le driver de celle-ci qui utilise apparement COM. - J'ai une autre DLL pour faire de l'OPC qui lui aussi utilise COM.
Le probleme est que lorsque j'utilise les 2 à la fois, ca ne marche pas parceque le driver de ma carte "monopolise" COM ou initialise incorrectement COM, si bien que ma couche OPC, ne fonctionne pas. Si je démarre la DLL OPC en premier, ca marche mais lorsque vient le tour de la DLL de ma carte de démarrer ca plante lamentablement le PC :(
N'étant pas super spécialiste en COM, y'aurait-il une issue à mon pb ?
J'ai trouvé une alternative à mon pb mais qui me satisfait guere : j'ai ré-écrit mes plugin DLL en plugin EXE avec serveur TCP embarqué, comme cela chaque process initialize COM comme il veut et sa fonctionne. Mais c'est beaucoup plus souple et plus fiable de dialoguer avec les fonctions d'une DLL qu'on a chargé avec LoadLibrary plutot que de faire toutes les transactions via serveur TCP.
Merci pour votre aide,
PurL
Hello,
A mon sens, y'a seulement trois chose à savoir sur CoInitialize(NULL)
1 - Stocker le retour de cette fonction, et faire un Unitialize si et
seulement si ce retour était S_OK.
2 - Ne jamais appeler cette fonction dans la DLLMAIN sur un PROCESS_ATTACH
par exemple. ca peux créer des blocages imprévisibles sur des LoadLibrary
par exemple. De manière générale, ne jamais appeller d'API dans un DLLMAIN.
3 - Appelez CoInitialize dans tous les THREAD qui se servent de COM.
VB
"PurL" <purl@neuf.fr> wrote in message
news:1143618500.101229.63090@z34g2000cwc.googlegroups.com...
Bonjour,
J'ai une utilisation qui pilote différent matériel : carte
spécifique, port série, éthernet, ...
pour séparer le reste de l'application de cette partie spécifique,
j'ai écrit cette derniere dans des DLL qui font officent de plugin
pour l'application générale. une DLL pour ma carte spécifique, une
DLL pour le port série, ...
- La DLL pilotant ma carte spécifique utilise le driver de celle-ci
qui utilise apparement COM.
- J'ai une autre DLL pour faire de l'OPC qui lui aussi utilise COM.
Le probleme est que lorsque j'utilise les 2 à la fois, ca ne marche
pas parceque le driver de ma carte "monopolise" COM ou initialise
incorrectement COM, si bien que ma couche OPC, ne fonctionne pas. Si je
démarre la DLL OPC en premier, ca marche mais lorsque vient le tour de
la DLL de ma carte de démarrer ca plante lamentablement le PC :(
N'étant pas super spécialiste en COM, y'aurait-il une issue à mon pb
?
J'ai trouvé une alternative à mon pb mais qui me satisfait guere :
j'ai ré-écrit mes plugin DLL en plugin EXE avec serveur TCP
embarqué, comme cela chaque process initialize COM comme il veut et sa
fonctionne. Mais c'est beaucoup plus souple et plus fiable de dialoguer
avec les fonctions d'une DLL qu'on a chargé avec LoadLibrary plutot
que de faire toutes les transactions via serveur TCP.
A mon sens, y'a seulement trois chose à savoir sur CoInitialize(NULL)
1 - Stocker le retour de cette fonction, et faire un Unitialize si et seulement si ce retour était S_OK. 2 - Ne jamais appeler cette fonction dans la DLLMAIN sur un PROCESS_ATTACH par exemple. ca peux créer des blocages imprévisibles sur des LoadLibrary par exemple. De manière générale, ne jamais appeller d'API dans un DLLMAIN. 3 - Appelez CoInitialize dans tous les THREAD qui se servent de COM.
VB
"PurL" wrote in message news: Bonjour,
J'ai une utilisation qui pilote différent matériel : carte spécifique, port série, éthernet, ... pour séparer le reste de l'application de cette partie spécifique, j'ai écrit cette derniere dans des DLL qui font officent de plugin pour l'application générale. une DLL pour ma carte spécifique, une DLL pour le port série, ...
- La DLL pilotant ma carte spécifique utilise le driver de celle-ci qui utilise apparement COM. - J'ai une autre DLL pour faire de l'OPC qui lui aussi utilise COM.
Le probleme est que lorsque j'utilise les 2 à la fois, ca ne marche pas parceque le driver de ma carte "monopolise" COM ou initialise incorrectement COM, si bien que ma couche OPC, ne fonctionne pas. Si je démarre la DLL OPC en premier, ca marche mais lorsque vient le tour de la DLL de ma carte de démarrer ca plante lamentablement le PC :(
N'étant pas super spécialiste en COM, y'aurait-il une issue à mon pb ?
J'ai trouvé une alternative à mon pb mais qui me satisfait guere : j'ai ré-écrit mes plugin DLL en plugin EXE avec serveur TCP embarqué, comme cela chaque process initialize COM comme il veut et sa fonctionne. Mais c'est beaucoup plus souple et plus fiable de dialoguer avec les fonctions d'une DLL qu'on a chargé avec LoadLibrary plutot que de faire toutes les transactions via serveur TCP.
