je dois concevoir une appli communiquant avec un serveur au travers
de DDE "Dynamic Data Exchange" (pas le choix, c'est imposé par le
detenteur du serveur, bref)
Or, sur la msdn, j'ai lu que ce n'etait plus supporté !!! Pire encore,
Microsoft invite le developpeur à maintenir l'appli sous VB6 !!!
Quelqu'un connait un moyen d'utiliser DDe sous .Net ?
je dois concevoir une appli communiquant avec un serveur au travers
de DDE "Dynamic Data Exchange" (pas le choix, c'est imposé par le
detenteur du serveur, bref)
Or, sur la msdn, j'ai lu que ce n'etait plus supporté !!! Pire encore,
Microsoft invite le developpeur à maintenir l'appli sous VB6 !!!
Quelqu'un connait un moyen d'utiliser DDe sous .Net ?
je dois concevoir une appli communiquant avec un serveur au travers
de DDE "Dynamic Data Exchange" (pas le choix, c'est imposé par le
detenteur du serveur, bref)
Or, sur la msdn, j'ai lu que ce n'etait plus supporté !!! Pire encore,
Microsoft invite le developpeur à maintenir l'appli sous VB6 !!!
Quelqu'un connait un moyen d'utiliser DDe sous .Net ?
Saulot wrote:
> je dois concevoir une appli communiquant avec un serveur au travers
> de DDE "Dynamic Data Exchange" (pas le choix, c'est imposé par le
> detenteur du serveur, bref)
>
> Or, sur la msdn, j'ai lu que ce n'etait plus supporté !!! Pire encore,
> Microsoft invite le developpeur à maintenir l'appli sous VB6 !!!
>
> Quelqu'un connait un moyen d'utiliser DDe sous .Net ?
Bonjour,
La meilleure solution consisterait bien sûr à convaincre le détenteur du
serveur d'abandonner cette technologie (le protocole de l'enfer) qui est
devenue obsolète dès l'apparition de COM/DCOM et de Automation. Il
faudrait quand même lui faire savoir qu'il devra de toutes façons faire
cette démarche un jour ou l'autre et que les dévelopepments forcés sur
DDE seront perdus. Donc nous sommes d'accord, ce n'est pas un bon
investissement mais comme vous dîtes, bref...
Vous pouvez toujours accéder à DDEML en faisant les Declare adéquats.
Par exemple pour la fonction DdeInitialize
Declare Function DdeInitialize Lib "user32" Alias "DdeInitializeA"
(ByRef pidInst As Integer, ByVal pfnCallback As Integer, ByVal afCmd As
Integer, ByVal ulRes As Integer) As Short
Pour les autres Declare, entrez la fonction recherchée sur cette page:
http://custom.programming-in.net/
Toutefois, le DDE, ce ne sont en fait que des messages de fenêtre à
fenêtre (ce qui est d'ailleurs ridicule pour un protocole de
communication de process à process - tout faux dès le départ celui-là).
Donc vous pouvez décider de traiter vous même ces messages. Exemple à
télécharger ici:
http://www.ozemail.com.au/~markhurd/vbnetdde.zip
Dire que c'est simple serait exagéré mais bon, c'est ce que faisaient
les développeurs qui n'utilisaient pas DDEML.
Bon courage.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Saulot wrote:
> je dois concevoir une appli communiquant avec un serveur au travers
> de DDE "Dynamic Data Exchange" (pas le choix, c'est imposé par le
> detenteur du serveur, bref)
>
> Or, sur la msdn, j'ai lu que ce n'etait plus supporté !!! Pire encore,
> Microsoft invite le developpeur à maintenir l'appli sous VB6 !!!
>
> Quelqu'un connait un moyen d'utiliser DDe sous .Net ?
Bonjour,
La meilleure solution consisterait bien sûr à convaincre le détenteur du
serveur d'abandonner cette technologie (le protocole de l'enfer) qui est
devenue obsolète dès l'apparition de COM/DCOM et de Automation. Il
faudrait quand même lui faire savoir qu'il devra de toutes façons faire
cette démarche un jour ou l'autre et que les dévelopepments forcés sur
DDE seront perdus. Donc nous sommes d'accord, ce n'est pas un bon
investissement mais comme vous dîtes, bref...
Vous pouvez toujours accéder à DDEML en faisant les Declare adéquats.
Par exemple pour la fonction DdeInitialize
Declare Function DdeInitialize Lib "user32" Alias "DdeInitializeA"
(ByRef pidInst As Integer, ByVal pfnCallback As Integer, ByVal afCmd As
Integer, ByVal ulRes As Integer) As Short
Pour les autres Declare, entrez la fonction recherchée sur cette page:
http://custom.programming-in.net/
Toutefois, le DDE, ce ne sont en fait que des messages de fenêtre à
fenêtre (ce qui est d'ailleurs ridicule pour un protocole de
communication de process à process - tout faux dès le départ celui-là).
Donc vous pouvez décider de traiter vous même ces messages. Exemple à
télécharger ici:
http://www.ozemail.com.au/~markhurd/vbnetdde.zip
Dire que c'est simple serait exagéré mais bon, c'est ce que faisaient
les développeurs qui n'utilisaient pas DDEML.
Bon courage.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Saulot wrote:
> je dois concevoir une appli communiquant avec un serveur au travers
> de DDE "Dynamic Data Exchange" (pas le choix, c'est imposé par le
> detenteur du serveur, bref)
>
> Or, sur la msdn, j'ai lu que ce n'etait plus supporté !!! Pire encore,
> Microsoft invite le developpeur à maintenir l'appli sous VB6 !!!
>
> Quelqu'un connait un moyen d'utiliser DDe sous .Net ?
Bonjour,
La meilleure solution consisterait bien sûr à convaincre le détenteur du
serveur d'abandonner cette technologie (le protocole de l'enfer) qui est
devenue obsolète dès l'apparition de COM/DCOM et de Automation. Il
faudrait quand même lui faire savoir qu'il devra de toutes façons faire
cette démarche un jour ou l'autre et que les dévelopepments forcés sur
DDE seront perdus. Donc nous sommes d'accord, ce n'est pas un bon
investissement mais comme vous dîtes, bref...
Vous pouvez toujours accéder à DDEML en faisant les Declare adéquats.
Par exemple pour la fonction DdeInitialize
Declare Function DdeInitialize Lib "user32" Alias "DdeInitializeA"
(ByRef pidInst As Integer, ByVal pfnCallback As Integer, ByVal afCmd As
Integer, ByVal ulRes As Integer) As Short
Pour les autres Declare, entrez la fonction recherchée sur cette page:
http://custom.programming-in.net/
Toutefois, le DDE, ce ne sont en fait que des messages de fenêtre à
fenêtre (ce qui est d'ailleurs ridicule pour un protocole de
communication de process à process - tout faux dès le départ celui-là).
Donc vous pouvez décider de traiter vous même ces messages. Exemple à
télécharger ici:
http://www.ozemail.com.au/~markhurd/vbnetdde.zip
Dire que c'est simple serait exagéré mais bon, c'est ce que faisaient
les développeurs qui n'utilisaient pas DDEML.
Bon courage.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
"Le protocole de l'enfer" ?
Ca laisse presager des bonnes heures de franches rigolades ^^...
Quoi qu'il en soit, je me voit mal aller dire à ces gentils monsieurs
de Bloomberg de changer tout leur systeme.
"Le protocole de l'enfer" ?
Ca laisse presager des bonnes heures de franches rigolades ^^...
Quoi qu'il en soit, je me voit mal aller dire à ces gentils monsieurs
de Bloomberg de changer tout leur systeme.
"Le protocole de l'enfer" ?
Ca laisse presager des bonnes heures de franches rigolades ^^...
Quoi qu'il en soit, je me voit mal aller dire à ces gentils monsieurs
de Bloomberg de changer tout leur systeme.
Saulot wrote:
> "Le protocole de l'enfer" ?
> Ca laisse presager des bonnes heures de franches rigolades ^^...
J'ai supposé que vous aviez déjà pratiqué un peu... Sinon, il faut
regarder d'une part la doc sur les messages DDE pour comprendre comment
ça fonctionne et d'autre part le doc DDEML.
http://www.angelfire.com/biz/rhaminisys/ddeinfo.html
La manipulation directe des messages étant assez fastidieuse, Microsoft
a créé à l'époque une DLL d'encapsulation (DDEML) qui expose les
fonctionnalités équivalentes sous forme d'APIs. Mais comme les messages
DDE ne peuvent s'adresser qu'à des fenêtres, cette bibliothèque crée de
manière transparente des fenêtres invisibles dans votre application. On
mesure déjà l'efficacité du système.
Le **gros** problème avec DDE, contrairement au COM, c'est qu'il n'y a
pas d'instanciation automatique. Si un client réclame une conversation
DDE avec un serveur qui ne tourne pas, rien ne se passe. Via DDEML, vous
aurez juste un timeout. En fait, l'initialisation se fait en envoyant un
message Windows en broadcast à toutes les applis qui sont en train de
tourner. S'il y en a une qui se reconnaît, elle répond et le client
considère que c'est la bonne. D'un point de vue sécurité, sur un réseau,
on ne peut pas faire pire. Si aucune ne se reconnaît, le client ne peut
rien faire.
Une fois franchie cette épreuve, les échanges commencent. Le bon
fonctionnement du protocole dépend uniquement de la qualité de
l'implémentation côté client et serveur. En fait, si vous n'utilisez pas
DDEML, Windows ne fournit aucun code: il n'y a que la doc décrivant les
messages. Point final. C'est juste une "spécification" (j'ose à peine
utiliser le mot). L'analyse doit donc être particulièrement blindée car
si vous oubliez le moindre cas de figure (et croyez moi, il y a beaucoup
de cas tordus possibles), l'application se plantera plus souvent que de
raison.
Au niveau des déconnexions intempestives, même problème. Le client peut
se retrouver "déconnecté" de manière abrupte en plein milieu d'une
transaction sans aucun avertissement. Très difficile de recoller les
morceaux après coup.
> Quoi qu'il en soit, je me voit mal aller dire à ces gentils monsieurs
> de Bloomberg de changer tout leur systeme.
S'agissant de transactions financières, il est *extrêmement* surprenant
que Bloomberg utilise encore cette technique. Moins fiable, on ne peut
pas. Mais ils ont certainement de bonnes raisons...
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Saulot wrote:
> "Le protocole de l'enfer" ?
> Ca laisse presager des bonnes heures de franches rigolades ^^...
J'ai supposé que vous aviez déjà pratiqué un peu... Sinon, il faut
regarder d'une part la doc sur les messages DDE pour comprendre comment
ça fonctionne et d'autre part le doc DDEML.
http://www.angelfire.com/biz/rhaminisys/ddeinfo.html
La manipulation directe des messages étant assez fastidieuse, Microsoft
a créé à l'époque une DLL d'encapsulation (DDEML) qui expose les
fonctionnalités équivalentes sous forme d'APIs. Mais comme les messages
DDE ne peuvent s'adresser qu'à des fenêtres, cette bibliothèque crée de
manière transparente des fenêtres invisibles dans votre application. On
mesure déjà l'efficacité du système.
Le **gros** problème avec DDE, contrairement au COM, c'est qu'il n'y a
pas d'instanciation automatique. Si un client réclame une conversation
DDE avec un serveur qui ne tourne pas, rien ne se passe. Via DDEML, vous
aurez juste un timeout. En fait, l'initialisation se fait en envoyant un
message Windows en broadcast à toutes les applis qui sont en train de
tourner. S'il y en a une qui se reconnaît, elle répond et le client
considère que c'est la bonne. D'un point de vue sécurité, sur un réseau,
on ne peut pas faire pire. Si aucune ne se reconnaît, le client ne peut
rien faire.
Une fois franchie cette épreuve, les échanges commencent. Le bon
fonctionnement du protocole dépend uniquement de la qualité de
l'implémentation côté client et serveur. En fait, si vous n'utilisez pas
DDEML, Windows ne fournit aucun code: il n'y a que la doc décrivant les
messages. Point final. C'est juste une "spécification" (j'ose à peine
utiliser le mot). L'analyse doit donc être particulièrement blindée car
si vous oubliez le moindre cas de figure (et croyez moi, il y a beaucoup
de cas tordus possibles), l'application se plantera plus souvent que de
raison.
Au niveau des déconnexions intempestives, même problème. Le client peut
se retrouver "déconnecté" de manière abrupte en plein milieu d'une
transaction sans aucun avertissement. Très difficile de recoller les
morceaux après coup.
> Quoi qu'il en soit, je me voit mal aller dire à ces gentils monsieurs
> de Bloomberg de changer tout leur systeme.
S'agissant de transactions financières, il est *extrêmement* surprenant
que Bloomberg utilise encore cette technique. Moins fiable, on ne peut
pas. Mais ils ont certainement de bonnes raisons...
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Saulot wrote:
> "Le protocole de l'enfer" ?
> Ca laisse presager des bonnes heures de franches rigolades ^^...
J'ai supposé que vous aviez déjà pratiqué un peu... Sinon, il faut
regarder d'une part la doc sur les messages DDE pour comprendre comment
ça fonctionne et d'autre part le doc DDEML.
http://www.angelfire.com/biz/rhaminisys/ddeinfo.html
La manipulation directe des messages étant assez fastidieuse, Microsoft
a créé à l'époque une DLL d'encapsulation (DDEML) qui expose les
fonctionnalités équivalentes sous forme d'APIs. Mais comme les messages
DDE ne peuvent s'adresser qu'à des fenêtres, cette bibliothèque crée de
manière transparente des fenêtres invisibles dans votre application. On
mesure déjà l'efficacité du système.
Le **gros** problème avec DDE, contrairement au COM, c'est qu'il n'y a
pas d'instanciation automatique. Si un client réclame une conversation
DDE avec un serveur qui ne tourne pas, rien ne se passe. Via DDEML, vous
aurez juste un timeout. En fait, l'initialisation se fait en envoyant un
message Windows en broadcast à toutes les applis qui sont en train de
tourner. S'il y en a une qui se reconnaît, elle répond et le client
considère que c'est la bonne. D'un point de vue sécurité, sur un réseau,
on ne peut pas faire pire. Si aucune ne se reconnaît, le client ne peut
rien faire.
Une fois franchie cette épreuve, les échanges commencent. Le bon
fonctionnement du protocole dépend uniquement de la qualité de
l'implémentation côté client et serveur. En fait, si vous n'utilisez pas
DDEML, Windows ne fournit aucun code: il n'y a que la doc décrivant les
messages. Point final. C'est juste une "spécification" (j'ose à peine
utiliser le mot). L'analyse doit donc être particulièrement blindée car
si vous oubliez le moindre cas de figure (et croyez moi, il y a beaucoup
de cas tordus possibles), l'application se plantera plus souvent que de
raison.
Au niveau des déconnexions intempestives, même problème. Le client peut
se retrouver "déconnecté" de manière abrupte en plein milieu d'une
transaction sans aucun avertissement. Très difficile de recoller les
morceaux après coup.
> Quoi qu'il en soit, je me voit mal aller dire à ces gentils monsieurs
> de Bloomberg de changer tout leur systeme.
S'agissant de transactions financières, il est *extrêmement* surprenant
que Bloomberg utilise encore cette technique. Moins fiable, on ne peut
pas. Mais ils ont certainement de bonnes raisons...
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
