Mon app sert de serveur DDE (pour des images et du texte) pour des
documents Word ou autre.
Mon pb est que je peux fournir plus de 300 données différentes. Il
faut autant de contrôles source.
Je voudrais donc trouver un moyen d'intercepter le LinkRequest, pour :
1) lire le topic (qui est le nom du contrôle source dans un
fonctionnement standard).
2) le modifier pour le faire pointer sur un contrôle de mon choix.
Mon app sert de serveur DDE (pour des images et du texte) pour des
documents Word ou autre.
Mon pb est que je peux fournir plus de 300 données différentes. Il
faut autant de contrôles source.
Je voudrais donc trouver un moyen d'intercepter le LinkRequest, pour :
1) lire le topic (qui est le nom du contrôle source dans un
fonctionnement standard).
2) le modifier pour le faire pointer sur un contrôle de mon choix.
Mon app sert de serveur DDE (pour des images et du texte) pour des
documents Word ou autre.
Mon pb est que je peux fournir plus de 300 données différentes. Il
faut autant de contrôles source.
Je voudrais donc trouver un moyen d'intercepter le LinkRequest, pour :
1) lire le topic (qui est le nom du contrôle source dans un
fonctionnement standard).
2) le modifier pour le faire pointer sur un contrôle de mon choix.
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> Mon app sert de serveur DDE (pour des images et du texte) pour des
> documents Word ou autre.
>
> Mon pb est que je peux fournir plus de 300 données différentes. Il
> faut autant de contrôles source.
>
> Je voudrais donc trouver un moyen d'intercepter le LinkRequest, pour :
>
> 1) lire le topic (qui est le nom du contrôle source dans un
> fonctionnement standard).
> 2) le modifier pour le faire pointer sur un contrôle de mon choix.
Bonjour,
Comme toujours dès que l'on parle du "protocole de l'enfer", un
avant-propos s'impose: dans le cadre d'une amélioration de votre appli,
y a-t-il une raison absolument incontournable qui vous empêche
d'envisager un passage à Automation? C'est plus facile, c'est plus
fiable et ça permet d'envisager un design plus efficace, surtout dans
votre cas.
Sinon, il est facile de trouver des pages expliquant comment intercepter
des messages Windows par subclassing:
http://www.thescarms.com/vbasic/subclassform.asp
http://www.vbwm.com/art_2000/subclassing/0924/
Cependant, sauf erreur, VB utilise DDEML pour les opérations DDE et il
ne va pas être évident de vous intercaler dans le processus. Pour chaque
connexion, le destinataire des messages n'est pas une des fenêtres que
vous gérez mais une fenêtre invisible créée à cet effet par DDEML.
Et de toutes façons, AMHA, vous avez un problème de design à résoudre.
Automation vous permettrait de travailler avec des données structurées
(tableau, collection ou autre) et de répondre au client de manière
simple au travers de quelques méthodes adéquates qui iraient chercher la
bonne information là où elle se trouve, sans passer par un contrôle
séparé pour chaque donnée.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> Mon app sert de serveur DDE (pour des images et du texte) pour des
> documents Word ou autre.
>
> Mon pb est que je peux fournir plus de 300 données différentes. Il
> faut autant de contrôles source.
>
> Je voudrais donc trouver un moyen d'intercepter le LinkRequest, pour :
>
> 1) lire le topic (qui est le nom du contrôle source dans un
> fonctionnement standard).
> 2) le modifier pour le faire pointer sur un contrôle de mon choix.
Bonjour,
Comme toujours dès que l'on parle du "protocole de l'enfer", un
avant-propos s'impose: dans le cadre d'une amélioration de votre appli,
y a-t-il une raison absolument incontournable qui vous empêche
d'envisager un passage à Automation? C'est plus facile, c'est plus
fiable et ça permet d'envisager un design plus efficace, surtout dans
votre cas.
Sinon, il est facile de trouver des pages expliquant comment intercepter
des messages Windows par subclassing:
http://www.thescarms.com/vbasic/subclassform.asp
http://www.vbwm.com/art_2000/subclassing/0924/
Cependant, sauf erreur, VB utilise DDEML pour les opérations DDE et il
ne va pas être évident de vous intercaler dans le processus. Pour chaque
connexion, le destinataire des messages n'est pas une des fenêtres que
vous gérez mais une fenêtre invisible créée à cet effet par DDEML.
Et de toutes façons, AMHA, vous avez un problème de design à résoudre.
Automation vous permettrait de travailler avec des données structurées
(tableau, collection ou autre) et de répondre au client de manière
simple au travers de quelques méthodes adéquates qui iraient chercher la
bonne information là où elle se trouve, sans passer par un contrôle
séparé pour chaque donnée.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> Mon app sert de serveur DDE (pour des images et du texte) pour des
> documents Word ou autre.
>
> Mon pb est que je peux fournir plus de 300 données différentes. Il
> faut autant de contrôles source.
>
> Je voudrais donc trouver un moyen d'intercepter le LinkRequest, pour :
>
> 1) lire le topic (qui est le nom du contrôle source dans un
> fonctionnement standard).
> 2) le modifier pour le faire pointer sur un contrôle de mon choix.
Bonjour,
Comme toujours dès que l'on parle du "protocole de l'enfer", un
avant-propos s'impose: dans le cadre d'une amélioration de votre appli,
y a-t-il une raison absolument incontournable qui vous empêche
d'envisager un passage à Automation? C'est plus facile, c'est plus
fiable et ça permet d'envisager un design plus efficace, surtout dans
votre cas.
Sinon, il est facile de trouver des pages expliquant comment intercepter
des messages Windows par subclassing:
http://www.thescarms.com/vbasic/subclassform.asp
http://www.vbwm.com/art_2000/subclassing/0924/
Cependant, sauf erreur, VB utilise DDEML pour les opérations DDE et il
ne va pas être évident de vous intercaler dans le processus. Pour chaque
connexion, le destinataire des messages n'est pas une des fenêtres que
vous gérez mais une fenêtre invisible créée à cet effet par DDEML.
Et de toutes façons, AMHA, vous avez un problème de design à résoudre.
Automation vous permettrait de travailler avec des données structurées
(tableau, collection ou autre) et de répondre au client de manière
simple au travers de quelques méthodes adéquates qui iraient chercher la
bonne information là où elle se trouve, sans passer par un contrôle
séparé pour chaque donnée.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
J'apprécie le DDE (quand il marche, et ce n'est pas évident), car le
client final n'a qu'à "Coller Spécial" et tout va sans dire. Pour mes
clients, c'est le summum de la complexité et je ne peux pas
raisonnablement demander plus. C'est uniquement cette particularité
qui m'intéresse.
Je ne sais pas si on peut faire de même avec Automation.
Le savez-vous ? Si oui, alors je m'intéresse à Automation. Sans quoi
je suis condamné à utiliser le DDE, à moins qu'il existe d'autres
choses.
J'apprécie le DDE (quand il marche, et ce n'est pas évident), car le
client final n'a qu'à "Coller Spécial" et tout va sans dire. Pour mes
clients, c'est le summum de la complexité et je ne peux pas
raisonnablement demander plus. C'est uniquement cette particularité
qui m'intéresse.
Je ne sais pas si on peut faire de même avec Automation.
Le savez-vous ? Si oui, alors je m'intéresse à Automation. Sans quoi
je suis condamné à utiliser le DDE, à moins qu'il existe d'autres
choses.
J'apprécie le DDE (quand il marche, et ce n'est pas évident), car le
client final n'a qu'à "Coller Spécial" et tout va sans dire. Pour mes
clients, c'est le summum de la complexité et je ne peux pas
raisonnablement demander plus. C'est uniquement cette particularité
qui m'intéresse.
Je ne sais pas si on peut faire de même avec Automation.
Le savez-vous ? Si oui, alors je m'intéresse à Automation. Sans quoi
je suis condamné à utiliser le DDE, à moins qu'il existe d'autres
choses.
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> J'apprécie le DDE (quand il marche, et ce n'est pas évident), car le
> client final n'a qu'à "Coller Spécial" et tout va sans dire. Pour mes
> clients, c'est le summum de la complexité et je ne peux pas
> raisonnablement demander plus. C'est uniquement cette particularité
> qui m'intéresse.
>
> Je ne sais pas si on peut faire de même avec Automation.
> Le savez-vous ? Si oui, alors je m'intéresse à Automation. Sans quoi
> je suis condamné à utiliser le DDE, à moins qu'il existe d'autres
> choses.
DDE ne fait que du transfert de données (Dynamic Data Exchange). Ce que
vous en faites à l'arrivée est de votre ressort et ne dépend pas du
protocole. Si vous implémentez votre appli sous forme de serveur
Automation, les programmes clients n'auront qu'à instancier l'objet
Automation , appeler les méthodes adéquates et faire ce qu'ils veulent
avec les données retournées. Rien ne vous empêche d'ajouter une commande
au menu qui fait le travail de manière transparente pour l'utilisateur.
D'une manière générale, il n'y a rien qui soit possible en DDE et qui ne
le soit aussi via COM et Automation. Et vous pourrez en faire plus via
Automation. Je n'ai jamais trouvé une seule bonne raison technique pour
ne pas abandonner le DDE au profit de COM et Automation. Par contre, si
vous ne maîtrisez pas vous même le code des programmes clients qui
utilisent le DDE pour accéder aux données, il faudra probablement
ajouter quelques macros qui invoqueront le serveur Automation de manière
transparente au travers d'un menu custom. Rien de bien méchant. En
général, si l'appli cliente supporte DDE, elle supporte aussi la
création de macros.
En outre, vous n'aurez pas l'obligation d'avoir le serveur qui tourne
tout le temps comme en DDE. Si l'application serveur ne tourne pas au
moment de l'appel du client, COM se chargera de la réveiller. De plus,
sur un intranet, l'installation de l'application serveur sur une machine
distante est de type digito-nasale (comme dirait un de mes collègues
MVPs). Une fois que ça fonctionne en local, ça fontionnera en remote.
Pour créer un serveur Automation en VB, créer un projet de type ActiveX
EXE, voire ActiveX DLL si votre serveur n'a pas besoin de tourner en
stand-alone. C'est incroyablement simple et sans contrainte (bon, il
faut se faire une petite culture COM).
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> J'apprécie le DDE (quand il marche, et ce n'est pas évident), car le
> client final n'a qu'à "Coller Spécial" et tout va sans dire. Pour mes
> clients, c'est le summum de la complexité et je ne peux pas
> raisonnablement demander plus. C'est uniquement cette particularité
> qui m'intéresse.
>
> Je ne sais pas si on peut faire de même avec Automation.
> Le savez-vous ? Si oui, alors je m'intéresse à Automation. Sans quoi
> je suis condamné à utiliser le DDE, à moins qu'il existe d'autres
> choses.
DDE ne fait que du transfert de données (Dynamic Data Exchange). Ce que
vous en faites à l'arrivée est de votre ressort et ne dépend pas du
protocole. Si vous implémentez votre appli sous forme de serveur
Automation, les programmes clients n'auront qu'à instancier l'objet
Automation , appeler les méthodes adéquates et faire ce qu'ils veulent
avec les données retournées. Rien ne vous empêche d'ajouter une commande
au menu qui fait le travail de manière transparente pour l'utilisateur.
D'une manière générale, il n'y a rien qui soit possible en DDE et qui ne
le soit aussi via COM et Automation. Et vous pourrez en faire plus via
Automation. Je n'ai jamais trouvé une seule bonne raison technique pour
ne pas abandonner le DDE au profit de COM et Automation. Par contre, si
vous ne maîtrisez pas vous même le code des programmes clients qui
utilisent le DDE pour accéder aux données, il faudra probablement
ajouter quelques macros qui invoqueront le serveur Automation de manière
transparente au travers d'un menu custom. Rien de bien méchant. En
général, si l'appli cliente supporte DDE, elle supporte aussi la
création de macros.
En outre, vous n'aurez pas l'obligation d'avoir le serveur qui tourne
tout le temps comme en DDE. Si l'application serveur ne tourne pas au
moment de l'appel du client, COM se chargera de la réveiller. De plus,
sur un intranet, l'installation de l'application serveur sur une machine
distante est de type digito-nasale (comme dirait un de mes collègues
MVPs). Une fois que ça fonctionne en local, ça fontionnera en remote.
Pour créer un serveur Automation en VB, créer un projet de type ActiveX
EXE, voire ActiveX DLL si votre serveur n'a pas besoin de tourner en
stand-alone. C'est incroyablement simple et sans contrainte (bon, il
faut se faire une petite culture COM).
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> J'apprécie le DDE (quand il marche, et ce n'est pas évident), car le
> client final n'a qu'à "Coller Spécial" et tout va sans dire. Pour mes
> clients, c'est le summum de la complexité et je ne peux pas
> raisonnablement demander plus. C'est uniquement cette particularité
> qui m'intéresse.
>
> Je ne sais pas si on peut faire de même avec Automation.
> Le savez-vous ? Si oui, alors je m'intéresse à Automation. Sans quoi
> je suis condamné à utiliser le DDE, à moins qu'il existe d'autres
> choses.
DDE ne fait que du transfert de données (Dynamic Data Exchange). Ce que
vous en faites à l'arrivée est de votre ressort et ne dépend pas du
protocole. Si vous implémentez votre appli sous forme de serveur
Automation, les programmes clients n'auront qu'à instancier l'objet
Automation , appeler les méthodes adéquates et faire ce qu'ils veulent
avec les données retournées. Rien ne vous empêche d'ajouter une commande
au menu qui fait le travail de manière transparente pour l'utilisateur.
D'une manière générale, il n'y a rien qui soit possible en DDE et qui ne
le soit aussi via COM et Automation. Et vous pourrez en faire plus via
Automation. Je n'ai jamais trouvé une seule bonne raison technique pour
ne pas abandonner le DDE au profit de COM et Automation. Par contre, si
vous ne maîtrisez pas vous même le code des programmes clients qui
utilisent le DDE pour accéder aux données, il faudra probablement
ajouter quelques macros qui invoqueront le serveur Automation de manière
transparente au travers d'un menu custom. Rien de bien méchant. En
général, si l'appli cliente supporte DDE, elle supporte aussi la
création de macros.
En outre, vous n'aurez pas l'obligation d'avoir le serveur qui tourne
tout le temps comme en DDE. Si l'application serveur ne tourne pas au
moment de l'appel du client, COM se chargera de la réveiller. De plus,
sur un intranet, l'installation de l'application serveur sur une machine
distante est de type digito-nasale (comme dirait un de mes collègues
MVPs). Une fois que ça fonctionne en local, ça fontionnera en remote.
Pour créer un serveur Automation en VB, créer un projet de type ActiveX
EXE, voire ActiveX DLL si votre serveur n'a pas besoin de tourner en
stand-alone. C'est incroyablement simple et sans contrainte (bon, il
faut se faire une petite culture COM).
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Merci pour ces clarifications. Ce qui me manquait était de savoir
qu'il fallait créer un ActiveX exe.
Merci pour ces clarifications. Ce qui me manquait était de savoir
qu'il fallait créer un ActiveX exe.
Merci pour ces clarifications. Ce qui me manquait était de savoir
qu'il fallait créer un ActiveX exe.
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> Merci pour ces clarifications. Ce qui me manquait était de savoir
> qu'il fallait créer un ActiveX exe.
Bonjour,
Attention, comme je l'expliquai dans un autre thread, vous ne pouvez pas
"marshaller" une StdPicture. Vous êtes condamné à la DLL si vous
souhaitez utiliser StdPicture et IPicture pour transférer vos images. Ou
alors il faut tranférer un flux d'octets comme je l'ai expliqué.
Bon courage.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> Merci pour ces clarifications. Ce qui me manquait était de savoir
> qu'il fallait créer un ActiveX exe.
Bonjour,
Attention, comme je l'expliquai dans un autre thread, vous ne pouvez pas
"marshaller" une StdPicture. Vous êtes condamné à la DLL si vous
souhaitez utiliser StdPicture et IPicture pour transférer vos images. Ou
alors il faut tranférer un flux d'octets comme je l'ai expliqué.
Bon courage.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> Merci pour ces clarifications. Ce qui me manquait était de savoir
> qu'il fallait créer un ActiveX exe.
Bonjour,
Attention, comme je l'expliquai dans un autre thread, vous ne pouvez pas
"marshaller" une StdPicture. Vous êtes condamné à la DLL si vous
souhaitez utiliser StdPicture et IPicture pour transférer vos images. Ou
alors il faut tranférer un flux d'octets comme je l'ai expliqué.
Bon courage.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Or je n'arrive pas à copier une .Image dans un Byte(). Or il me
semble que quelque soit le protocole choisi (OLE ou DDE), il faudra
que j'y arrive.
Peut-être avez-vous des pistes pour faire cela ?
Or je n'arrive pas à copier une .Image dans un Byte(). Or il me
semble que quelque soit le protocole choisi (OLE ou DDE), il faudra
que j'y arrive.
Peut-être avez-vous des pistes pour faire cela ?
Or je n'arrive pas à copier une .Image dans un Byte(). Or il me
semble que quelque soit le protocole choisi (OLE ou DDE), il faudra
que j'y arrive.
Peut-être avez-vous des pistes pour faire cela ?
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> Or je n'arrive pas à copier une .Image dans un Byte(). Or il me
> semble que quelque soit le protocole choisi (OLE ou DDE), il faudra
> que j'y arrive.
>
> Peut-être avez-vous des pistes pour faire cela ?
Les exemples suivants démontrent à la fois la sauvegarde et la
restauration de l'image.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;180714
Cette méthode présente cependant l'inconvénient de passer par un fichier
temporaire intermédiaire.
http://www.vb-helper.com/howto_db_dib.html
Cette méthode travaille directement en mémoire. Ce code prévoit la
sauvegarde dans une database, il vous suffit d'enlever le code inutile.
Ou bien ceci (peut-être le plus simple):
http://www.mvps.org/emorcillo/vb6/multimedia/arrayfrompicture.shtml
http://www.mvps.org/emorcillo/vb6/multimedia/picturefromarray.shtml
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> Or je n'arrive pas à copier une .Image dans un Byte(). Or il me
> semble que quelque soit le protocole choisi (OLE ou DDE), il faudra
> que j'y arrive.
>
> Peut-être avez-vous des pistes pour faire cela ?
Les exemples suivants démontrent à la fois la sauvegarde et la
restauration de l'image.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;180714
Cette méthode présente cependant l'inconvénient de passer par un fichier
temporaire intermédiaire.
http://www.vb-helper.com/howto_db_dib.html
Cette méthode travaille directement en mémoire. Ce code prévoit la
sauvegarde dans une database, il vous suffit d'enlever le code inutile.
Ou bien ceci (peut-être le plus simple):
http://www.mvps.org/emorcillo/vb6/multimedia/arrayfrompicture.shtml
http://www.mvps.org/emorcillo/vb6/multimedia/picturefromarray.shtml
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Christian HUBERT-HUGOUD- Xtrem7 wrote:
> Or je n'arrive pas à copier une .Image dans un Byte(). Or il me
> semble que quelque soit le protocole choisi (OLE ou DDE), il faudra
> que j'y arrive.
>
> Peut-être avez-vous des pistes pour faire cela ?
Les exemples suivants démontrent à la fois la sauvegarde et la
restauration de l'image.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;180714
Cette méthode présente cependant l'inconvénient de passer par un fichier
temporaire intermédiaire.
http://www.vb-helper.com/howto_db_dib.html
Cette méthode travaille directement en mémoire. Ce code prévoit la
sauvegarde dans une database, il vous suffit d'enlever le code inutile.
Ou bien ceci (peut-être le plus simple):
http://www.mvps.org/emorcillo/vb6/multimedia/arrayfrompicture.shtml
http://www.mvps.org/emorcillo/vb6/multimedia/picturefromarray.shtml
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
J'ai tenté l'option en mémoire pure, avec OLE ; je dois être un peu
bourrin car il me plante un : Type utilisateur non défini sur la
ligne avec
IPersistStream
J'ai tenté l'option en mémoire pure, avec OLE ; je dois être un peu
bourrin car il me plante un : Type utilisateur non défini sur la
ligne avec
IPersistStream
J'ai tenté l'option en mémoire pure, avec OLE ; je dois être un peu
bourrin car il me plante un : Type utilisateur non défini sur la
ligne avec
IPersistStream
