Je suis à la recherche d'un bon tutorial sur la programmation de
composants COM/DCOM, en particulier sous Visual .NET.
Si l'un de vous avait un lien (en français ou en anglais), ça serait
cool.
Un bon bouquin pour même faire l'affaire. J'aimerai quand même éviter
d'acheter le gros pavé de 900 pages, super cher et où il y a 90% de
blabla ;)
Je suis à la recherche d'un bon tutorial sur la programmation de composants COM/DCOM, en particulier sous Visual .NET.
En ce qui concerne l'environnement .Net, la question va être vite réglée: vous pouvez utiliser mais non créer des composants COM avec les outils .Net.
Quel est votre objectif? Fabriquer des composants COM ou les utiliser?
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Patrick Brunet
Bonjour.
J'avais adoré le bouquin de David Chapell: Au coeur de COM et OLE, en Français chez Microsoft Press (environ 180p), pour sa présentation carrément lumineuse et progressive des principes de COM jusqu'aux interfaces standards à connaître. L'implémentation décrite était celle originelle, un µpoil plus complexe que celle des ATL, mais tellement plus propre et sans boîte noire !
Ceci pour bien comprendre la philosophie.
Pour le codage, j'en suis resté à Visual C++ 6, hélas avec les ATL. Le wizard fait tout tout seul, mais quand on essaie d'introduire des spécificités (mixer du DCOM multithread avec l'architecture doc/vue des MFC par exemple), c'est pas un cadeau pour comprendre où mettre les mains. Mais avec un peu de ruse c'est possible.
Hope It Helps.
PB
"Matthieu R." a écrit dans le message news:
Salut,
Je suis à la recherche d'un bon tutorial sur la programmation de composants COM/DCOM, en particulier sous Visual .NET. Si l'un de vous avait un lien (en français ou en anglais), ça serait cool.
Un bon bouquin pour même faire l'affaire. J'aimerai quand même éviter d'acheter le gros pavé de 900 pages, super cher et où il y a 90% de blabla ;)
D'avance, merci
Matt
Bonjour.
J'avais adoré le bouquin de David Chapell: Au coeur de COM et OLE, en
Français chez Microsoft Press (environ 180p), pour sa présentation carrément
lumineuse et progressive des principes de COM jusqu'aux interfaces standards
à connaître.
L'implémentation décrite était celle originelle, un µpoil plus complexe que
celle des ATL, mais tellement plus propre et sans boîte noire !
Ceci pour bien comprendre la philosophie.
Pour le codage, j'en suis resté à Visual C++ 6, hélas avec les ATL. Le
wizard fait tout tout seul, mais quand on essaie d'introduire des
spécificités (mixer du DCOM multithread avec l'architecture doc/vue des MFC
par exemple), c'est pas un cadeau pour comprendre où mettre les mains. Mais
avec un peu de ruse c'est possible.
Hope It Helps.
PB
"Matthieu R." <matthieu_rouget@yahoo.fr> a écrit dans le message news:
129ab702.0308131142.3c49b7f@posting.google.com...
Salut,
Je suis à la recherche d'un bon tutorial sur la programmation de
composants COM/DCOM, en particulier sous Visual .NET.
Si l'un de vous avait un lien (en français ou en anglais), ça serait
cool.
Un bon bouquin pour même faire l'affaire. J'aimerai quand même éviter
d'acheter le gros pavé de 900 pages, super cher et où il y a 90% de
blabla ;)
J'avais adoré le bouquin de David Chapell: Au coeur de COM et OLE, en Français chez Microsoft Press (environ 180p), pour sa présentation carrément lumineuse et progressive des principes de COM jusqu'aux interfaces standards à connaître. L'implémentation décrite était celle originelle, un µpoil plus complexe que celle des ATL, mais tellement plus propre et sans boîte noire !
Ceci pour bien comprendre la philosophie.
Pour le codage, j'en suis resté à Visual C++ 6, hélas avec les ATL. Le wizard fait tout tout seul, mais quand on essaie d'introduire des spécificités (mixer du DCOM multithread avec l'architecture doc/vue des MFC par exemple), c'est pas un cadeau pour comprendre où mettre les mains. Mais avec un peu de ruse c'est possible.
Hope It Helps.
PB
"Matthieu R." a écrit dans le message news:
Salut,
Je suis à la recherche d'un bon tutorial sur la programmation de composants COM/DCOM, en particulier sous Visual .NET. Si l'un de vous avait un lien (en français ou en anglais), ça serait cool.
Un bon bouquin pour même faire l'affaire. J'aimerai quand même éviter d'acheter le gros pavé de 900 pages, super cher et où il y a 90% de blabla ;)
D'avance, merci
Matt
Arnaud Debaene
Patrick Philippot wrote:
En ce qui concerne l'environnement .Net, la question va être vite réglée: vous pouvez utiliser mais non créer des composants COM avec les outils .Net.
Ah bon? Et tlbexp, ca sert à quoi selon toi ?
Arnaud
Patrick Philippot wrote:
En ce qui concerne l'environnement .Net, la question va être vite
réglée: vous pouvez utiliser mais non créer des composants COM avec
les outils .Net.
En ce qui concerne l'environnement .Net, la question va être vite réglée: vous pouvez utiliser mais non créer des composants COM avec les outils .Net.
Ah bon? Et tlbexp, ca sert à quoi selon toi ?
Arnaud
Patrick Philippot
Arnaud Debaene wrote:
Patrick Philippot wrote:
En ce qui concerne l'environnement .Net, la question va être vite réglée: vous pouvez utiliser mais non créer des composants COM avec les outils .Net.
Ah bon? Et tlbexp, ca sert à quoi selon toi ?
Eh bien, à faire voir un composant .Net comme un composant COM. Mais .Net ne produit pas *directement* des composants COM. Ce n'est pas sa vocation et Interop n'est là que pour faciliter la discussion entre les 2 mondes. Il faut un proxy (standard ou custom) entre le client et le composant .Net pour que le client croie avoir affaire à un composant COM. Même si Interop facilite énormément la vie, je ne vois pas l'intérêt d'utiliser l'environnement .Net pour fabriquer des composants COM dont la nature même les oppose à la philosophie .Net.
En fait, la nécessité d'Interop dans le sens .Net -> COM est essentiellement liée à l'absence d'un équivalent à COM+ / MTS qui puisse travailler nativement en .Net. Sinon, encore une fois, je ne vois pas vraiment l'intérêt d'aller ajouter une couche supplémentaire (CCW) entre le composant et le client alors que le problème de la création de composants COM est largement réglé par les outils standard. Le développeur aà le libre choix selon son expérience et ses besoins (VC++ ATL ou MFC, VB6, Delphi,...).
Donc j'insiste, si l'objectif est uniquement de fabriquer des composants COM, à mon humble avis, utiliser un outil .Net pour la production est une erreur. Si le besoin est d'utiliser des composants .Net existants depuis des clients COM ou bien de fabriquer des composants utilisables dans les 2 mondes, là bien sûr, c'est différent.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Arnaud Debaene wrote:
Patrick Philippot wrote:
En ce qui concerne l'environnement .Net, la question va être vite
réglée: vous pouvez utiliser mais non créer des composants COM avec
les outils .Net.
Ah bon? Et tlbexp, ca sert à quoi selon toi ?
Eh bien, à faire voir un composant .Net comme un composant COM. Mais
.Net ne produit pas *directement* des composants COM. Ce n'est pas sa
vocation et Interop n'est là que pour faciliter la discussion entre les
2 mondes. Il faut un proxy (standard ou custom) entre le client et le
composant .Net pour que le client croie avoir affaire à un composant
COM. Même si Interop facilite énormément la vie, je ne vois pas
l'intérêt d'utiliser l'environnement .Net pour fabriquer des composants
COM dont la nature même les oppose à la philosophie .Net.
En fait, la nécessité d'Interop dans le sens .Net -> COM est
essentiellement liée à l'absence d'un équivalent à COM+ / MTS qui puisse
travailler nativement en .Net. Sinon, encore une fois, je ne vois pas
vraiment l'intérêt d'aller ajouter une couche supplémentaire (CCW) entre
le composant et le client alors que le problème de la création de
composants COM est largement réglé par les outils standard. Le
développeur aà le libre choix selon son expérience et ses besoins (VC++
ATL ou MFC, VB6, Delphi,...).
Donc j'insiste, si l'objectif est uniquement de fabriquer des composants
COM, à mon humble avis, utiliser un outil .Net pour la production est
une erreur. Si le besoin est d'utiliser des composants .Net existants
depuis des clients COM ou bien de fabriquer des composants utilisables
dans les 2 mondes, là bien sûr, c'est différent.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
En ce qui concerne l'environnement .Net, la question va être vite réglée: vous pouvez utiliser mais non créer des composants COM avec les outils .Net.
Ah bon? Et tlbexp, ca sert à quoi selon toi ?
Eh bien, à faire voir un composant .Net comme un composant COM. Mais .Net ne produit pas *directement* des composants COM. Ce n'est pas sa vocation et Interop n'est là que pour faciliter la discussion entre les 2 mondes. Il faut un proxy (standard ou custom) entre le client et le composant .Net pour que le client croie avoir affaire à un composant COM. Même si Interop facilite énormément la vie, je ne vois pas l'intérêt d'utiliser l'environnement .Net pour fabriquer des composants COM dont la nature même les oppose à la philosophie .Net.
En fait, la nécessité d'Interop dans le sens .Net -> COM est essentiellement liée à l'absence d'un équivalent à COM+ / MTS qui puisse travailler nativement en .Net. Sinon, encore une fois, je ne vois pas vraiment l'intérêt d'aller ajouter une couche supplémentaire (CCW) entre le composant et le client alors que le problème de la création de composants COM est largement réglé par les outils standard. Le développeur aà le libre choix selon son expérience et ses besoins (VC++ ATL ou MFC, VB6, Delphi,...).
Donc j'insiste, si l'objectif est uniquement de fabriquer des composants COM, à mon humble avis, utiliser un outil .Net pour la production est une erreur. Si le besoin est d'utiliser des composants .Net existants depuis des clients COM ou bien de fabriquer des composants utilisables dans les 2 mondes, là bien sûr, c'est différent.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
matthieu_rouget
> Pour revenir au sujet...
COM nécessite un volume de documentation important. C'est la technologie qui veut ça. Même si ses principes sont simples, leur mise en oeuvre l'est moins et sa maîtrise prend un peu (euphémisme) de temps.
Sur le Web: http://www.microsoft.com/Com/ (autant commencer par le commencement - à partir de cette page, une foule de liens utiles)
Parmi les ouvrages classiques:
[... plein de bouquins intéressants ...]
Voilà, ça devrait suffire pour commencer.
Mon but est principalement de faire des composants COM avec Visual C++ et de pouvoir les utiliser aussi bien des dans applis C++ ou VB. J'ai parlé de .NET parce que j'utilise Visual .NET et je me disais qu'il y avait peut-être des outils spécifiques à cette version qui facilitaient la programmation de composants COM. Mon but n'était pas du tout de faire des composants COM en utilisant le framework .NET... Je pense que mon ignorance à propos de la technologie .NET à fait que mon message n'était pas clair.
Je pense que je trouverai mon compte dans les bouquins et les liens que vous tous m'avez donnés. J'y l'impression qu'il faut quand même un assez gros volume d'infos pour comprendre le fonctionnement de COM et qu'un simple tutorial ne suffira pas.
Et hop, au boulot !
En tout cas, merci.
Matt.
> Pour revenir au sujet...
COM nécessite un volume de documentation important. C'est la technologie
qui veut ça. Même si ses principes sont simples, leur mise en oeuvre
l'est moins et sa maîtrise prend un peu (euphémisme) de temps.
Sur le Web: http://www.microsoft.com/Com/ (autant commencer par le
commencement - à partir de cette page, une foule de liens utiles)
Parmi les ouvrages classiques:
[... plein de bouquins intéressants ...]
Voilà, ça devrait suffire pour commencer.
Mon but est principalement de faire des composants COM avec Visual C++
et de pouvoir les utiliser aussi bien des dans applis C++ ou VB.
J'ai parlé de .NET parce que j'utilise Visual .NET et je me disais
qu'il y avait peut-être des outils spécifiques à cette version qui
facilitaient la programmation de composants COM. Mon but n'était pas
du tout de faire des composants COM en utilisant le framework .NET...
Je pense que mon ignorance à propos de la technologie .NET à fait que
mon message n'était pas clair.
Je pense que je trouverai mon compte dans les bouquins et les liens
que vous tous m'avez donnés. J'y l'impression qu'il faut quand même un
assez gros volume d'infos pour comprendre le fonctionnement de COM et
qu'un simple tutorial ne suffira pas.
COM nécessite un volume de documentation important. C'est la technologie qui veut ça. Même si ses principes sont simples, leur mise en oeuvre l'est moins et sa maîtrise prend un peu (euphémisme) de temps.
Sur le Web: http://www.microsoft.com/Com/ (autant commencer par le commencement - à partir de cette page, une foule de liens utiles)
Parmi les ouvrages classiques:
[... plein de bouquins intéressants ...]
Voilà, ça devrait suffire pour commencer.
Mon but est principalement de faire des composants COM avec Visual C++ et de pouvoir les utiliser aussi bien des dans applis C++ ou VB. J'ai parlé de .NET parce que j'utilise Visual .NET et je me disais qu'il y avait peut-être des outils spécifiques à cette version qui facilitaient la programmation de composants COM. Mon but n'était pas du tout de faire des composants COM en utilisant le framework .NET... Je pense que mon ignorance à propos de la technologie .NET à fait que mon message n'était pas clair.
Je pense que je trouverai mon compte dans les bouquins et les liens que vous tous m'avez donnés. J'y l'impression qu'il faut quand même un assez gros volume d'infos pour comprendre le fonctionnement de COM et qu'un simple tutorial ne suffira pas.
Et hop, au boulot !
En tout cas, merci.
Matt.
Patrick Brunet
Bonjour.
"Patrick Philippot" a écrit dans le message news: bhle2s$1ecr$ <...>
VC++ + MFC Forte encapsulation pour certains types de contrôles (ActiveX Controls), maîtrise plus grande du code (code source MFC), code un peu plus perfomant MAIS Runtime MFC obligatoire (on ne peut pas linker les MFC en static dans ce cas) et code très "gras" + DLL de 900 K environ.
Si, je l'ai fait avec les MFC en static :-)
Mais c'est vrai que c'est le b...
Le gros problème est de faire cohabiter dans le même code une architecture doc/vue MFC et un serveur DCOM à base d'ATL. J'ai généré les deux séparément et j'ai dû hacker un peu pour incorporer le DCOM dans l'appli MFC. Typiquement, le plus dûr était de contourner l'initialisation OLE (mode appartment) qui vient avec les MFC. J'ai dû virer la AfxOleInit() et la remplacer par une version à moi qui fait un CoInitializeEx( NULL, COINIT_MULTITHREADED);
Ensuite il faut être très prudent puisque les MFC ne sont pas thread-safe, donc il faut bien gérer l'aiguillage au niveau de la partie DCOM, de toute manière il y a des contrôles dans les MFC qui empêchent les threads autres que le principal d'accéder directement aux classes de l'IHM. Donc il y a de la synchro de threads à prévoir. De toute manière, mon serveur fait de l'enregistrement temps réel des données, dans un buffer circulaire puis dans un fichier, et l'affichage est sous-prioritaire. Il y avait donc déjà plusieurs threads de prévus...
Mais donc ça marche et même bien.
Le but fondamental de la manip était que mon EXE soit effectivement lancé en tant que le serveur DCOM, ce qui m'interdisait de le doter d'antennes DCOM déportées dans une DLL (qui aurait alors été lancée sur un "surrogate"). Je devrai probablement remettre ça en question quand je voudrai permettre en option d'utiliser des antennes DCOM ou CORBA.
<...>
Pour info only. Cordialement,
Patrick "Zener" Brunet
Bonjour.
"Patrick Philippot" <patrick.philippot@mainsoft.xx> a écrit dans le message
news: bhle2s$1ecr$1@biggoron.nerim.net...
<...>
VC++ + MFC
Forte encapsulation pour certains types de contrôles (ActiveX Controls),
maîtrise plus grande du code (code source MFC), code un peu plus
perfomant
MAIS
Runtime MFC obligatoire (on ne peut pas linker les MFC en static dans ce
cas) et code très "gras" + DLL de 900 K environ.
Si, je l'ai fait avec les MFC en static :-)
Mais c'est vrai que c'est le b...
Le gros problème est de faire cohabiter dans le même code une architecture
doc/vue MFC et un serveur DCOM à base d'ATL. J'ai généré les deux séparément
et j'ai dû hacker un peu pour incorporer le DCOM dans l'appli MFC.
Typiquement, le plus dûr était de contourner l'initialisation OLE (mode
appartment) qui vient avec les MFC.
J'ai dû virer la AfxOleInit() et la remplacer par une version à moi qui fait
un
CoInitializeEx( NULL, COINIT_MULTITHREADED);
Ensuite il faut être très prudent puisque les MFC ne sont pas thread-safe,
donc il faut bien gérer l'aiguillage au niveau de la partie DCOM, de toute
manière il y a des contrôles dans les MFC qui empêchent les threads autres
que le principal d'accéder directement aux classes de l'IHM. Donc il y a de
la synchro de threads à prévoir. De toute manière, mon serveur fait de
l'enregistrement temps réel des données, dans un buffer circulaire puis dans
un fichier, et l'affichage est sous-prioritaire. Il y avait donc déjà
plusieurs threads de prévus...
Mais donc ça marche et même bien.
Le but fondamental de la manip était que mon EXE soit effectivement lancé en
tant que le serveur DCOM, ce qui m'interdisait de le doter d'antennes DCOM
déportées dans une DLL (qui aurait alors été lancée sur un "surrogate"). Je
devrai probablement remettre ça en question quand je voudrai permettre en
option d'utiliser des antennes DCOM ou CORBA.
"Patrick Philippot" a écrit dans le message news: bhle2s$1ecr$ <...>
VC++ + MFC Forte encapsulation pour certains types de contrôles (ActiveX Controls), maîtrise plus grande du code (code source MFC), code un peu plus perfomant MAIS Runtime MFC obligatoire (on ne peut pas linker les MFC en static dans ce cas) et code très "gras" + DLL de 900 K environ.
Si, je l'ai fait avec les MFC en static :-)
Mais c'est vrai que c'est le b...
Le gros problème est de faire cohabiter dans le même code une architecture doc/vue MFC et un serveur DCOM à base d'ATL. J'ai généré les deux séparément et j'ai dû hacker un peu pour incorporer le DCOM dans l'appli MFC. Typiquement, le plus dûr était de contourner l'initialisation OLE (mode appartment) qui vient avec les MFC. J'ai dû virer la AfxOleInit() et la remplacer par une version à moi qui fait un CoInitializeEx( NULL, COINIT_MULTITHREADED);
Ensuite il faut être très prudent puisque les MFC ne sont pas thread-safe, donc il faut bien gérer l'aiguillage au niveau de la partie DCOM, de toute manière il y a des contrôles dans les MFC qui empêchent les threads autres que le principal d'accéder directement aux classes de l'IHM. Donc il y a de la synchro de threads à prévoir. De toute manière, mon serveur fait de l'enregistrement temps réel des données, dans un buffer circulaire puis dans un fichier, et l'affichage est sous-prioritaire. Il y avait donc déjà plusieurs threads de prévus...
Mais donc ça marche et même bien.
Le but fondamental de la manip était que mon EXE soit effectivement lancé en tant que le serveur DCOM, ce qui m'interdisait de le doter d'antennes DCOM déportées dans une DLL (qui aurait alors été lancée sur un "surrogate"). Je devrai probablement remettre ça en question quand je voudrai permettre en option d'utiliser des antennes DCOM ou CORBA.
<...>
Pour info only. Cordialement,
Patrick "Zener" Brunet
Patrick Philippot
Patrick Brunet wrote:
Bonjour. Si, je l'ai fait avec les MFC en static :-)
Belle manip. Merci pour les détails. J'avais déjà lu quelque part que certains s'étaient lancés dans ce genre d'aventure...
En ce qui concerne la demande initiale, je crois qu'il vaut mieux s'en tenir à des conseils "orthodoxes".
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Patrick Brunet wrote:
Bonjour.
Si, je l'ai fait avec les MFC en static :-)
Belle manip. Merci pour les détails. J'avais déjà lu quelque part que
certains s'étaient lancés dans ce genre d'aventure...
En ce qui concerne la demande initiale, je crois qu'il vaut mieux s'en
tenir à des conseils "orthodoxes".
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
Bonjour. Si, je l'ai fait avec les MFC en static :-)
Belle manip. Merci pour les détails. J'avais déjà lu quelque part que certains s'étaient lancés dans ce genre d'aventure...
En ce qui concerne la demande initiale, je crois qu'il vaut mieux s'en tenir à des conseils "orthodoxes".
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Patrick Brunet
Bonjour !
"Patrick Philippot" a écrit dans le message news: bhqa5b$qsv$
Patrick Brunet wrote: > Bonjour. > Si, je l'ai fait avec les MFC en static :-)
Belle manip. Merci pour les détails. J'avais déjà lu quelque part que certains s'étaient lancés dans ce genre d'aventure...
En ce qui concerne la demande initiale, je crois qu'il vaut mieux s'en tenir à des conseils "orthodoxes".
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Ben justement, (cf mon objectif), n'est-il pas légitime de vouloir créer une appli doc/vue qui soit aussi un serveur DCOM ? Le problème, surtout avec l'implémentation ATL, c'est que c'est l'exécutable qui contient le CExeModule qui est lancé par le système, ce qui interdit de déporter l'antenne DCOM dans une DLL. D'une manière générale (et ça vaut aussi pour les MFC), je trouve que tout cela manque énormément de modularité et de souplesse. Sans compter les bugs que j'ai signalés lors de la version 4 et qui existent encore (voir le plantage qui a lieu à cause d'un bug dans le traitement des options de commande DDE) ! Navré, mais pour faire des applis à la cote, on est toujours un peu obligé de hacker :-{=8 Cordialement,
Zener
Bonjour !
"Patrick Philippot" <patrick.philippot@mainsoft.xx> a écrit dans le message
news: bhqa5b$qsv$1@biggoron.nerim.net...
Patrick Brunet wrote:
> Bonjour.
> Si, je l'ai fait avec les MFC en static :-)
Belle manip. Merci pour les détails. J'avais déjà lu quelque part que
certains s'étaient lancés dans ce genre d'aventure...
En ce qui concerne la demande initiale, je crois qu'il vaut mieux s'en
tenir à des conseils "orthodoxes".
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
Ben justement, (cf mon objectif), n'est-il pas légitime de vouloir créer une
appli doc/vue qui soit aussi un serveur DCOM ?
Le problème, surtout avec l'implémentation ATL, c'est que c'est l'exécutable
qui contient le CExeModule qui est lancé par le système, ce qui interdit de
déporter l'antenne DCOM dans une DLL.
D'une manière générale (et ça vaut aussi pour les MFC), je trouve que tout
cela manque énormément de modularité et de souplesse.
Sans compter les bugs que j'ai signalés lors de la version 4 et qui existent
encore (voir le plantage qui a lieu à cause d'un bug dans le traitement des
options de commande DDE) !
Navré, mais pour faire des applis à la cote, on est toujours un peu obligé
de hacker :-{=8
Cordialement,
"Patrick Philippot" a écrit dans le message news: bhqa5b$qsv$
Patrick Brunet wrote: > Bonjour. > Si, je l'ai fait avec les MFC en static :-)
Belle manip. Merci pour les détails. J'avais déjà lu quelque part que certains s'étaient lancés dans ce genre d'aventure...
En ce qui concerne la demande initiale, je crois qu'il vaut mieux s'en tenir à des conseils "orthodoxes".
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Ben justement, (cf mon objectif), n'est-il pas légitime de vouloir créer une appli doc/vue qui soit aussi un serveur DCOM ? Le problème, surtout avec l'implémentation ATL, c'est que c'est l'exécutable qui contient le CExeModule qui est lancé par le système, ce qui interdit de déporter l'antenne DCOM dans une DLL. D'une manière générale (et ça vaut aussi pour les MFC), je trouve que tout cela manque énormément de modularité et de souplesse. Sans compter les bugs que j'ai signalés lors de la version 4 et qui existent encore (voir le plantage qui a lieu à cause d'un bug dans le traitement des options de commande DDE) ! Navré, mais pour faire des applis à la cote, on est toujours un peu obligé de hacker :-{=8 Cordialement,
