Est-il possible de faire communiquer 2 ou plusieurs applis Windev, lancées
depuis
deux exécutables différents ? et même des applis développées avec des
versions de
Windev défférentes (notamment 8 et 7.5, voire 5.5) ???
Mon objectif serait de pouvoir appeler des fonctions/procédures d'une appli
depuis
une autre, et inversement, de pouvoir utiliser certaines fenêtres de l'appli
secondaire,
ou mieux de pouvoir "intégrer" des fenêtres d'une autre appli en les gérant
comme si
elles faisaient partie de l'appli principale, tout en laissant la
possibilité à l'autre appli
de les commander aussi... et tout ceci sans intégrer au niveau code toutes
les fenêtres,
procédures, tout le code... de l'autre appli.
Merci d'avance pour les réponses nombreuses ( enfin j'espère ;-) )
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
Stéphane
Bonjour,
Une réponse à froid : mettre dans une bibliothèque (WDL) spécifique toutes les fenêtres qui seront communes au 2 applis puis faire un ChargeWDL dans tes applis. Par contre pour les procédures globales, à première vue je dirais que c'est impossible puisque le code est lié au projet et non pas à une fenêtre.
Ami Calmant Stéphane
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.701 / Virus Database: 458 - Release Date: 07/06/2004
Bonjour,
Une réponse à froid : mettre dans une bibliothèque (WDL) spécifique toutes
les fenêtres qui seront communes au 2 applis puis faire un ChargeWDL dans
tes applis. Par contre pour les procédures globales, à première vue je
dirais que c'est impossible puisque le code est lié au projet et non pas à
une fenêtre.
Ami Calmant
Stéphane
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.701 / Virus Database: 458 - Release Date: 07/06/2004
Une réponse à froid : mettre dans une bibliothèque (WDL) spécifique toutes les fenêtres qui seront communes au 2 applis puis faire un ChargeWDL dans tes applis. Par contre pour les procédures globales, à première vue je dirais que c'est impossible puisque le code est lié au projet et non pas à une fenêtre.
Ami Calmant Stéphane
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.701 / Virus Database: 458 - Release Date: 07/06/2004
Gégé
idbat wrote:
Bonjour à tous,
Est-il possible de faire communiquer 2 ou plusieurs applis Windev, lancées depuis deux exécutables différents ? et même des applis développées avec des versions de Windev défférentes (notamment 8 et 7.5, voire 5.5) ???
Regarde sur WindevAsso (oups y'a eu un coup de vent : Wind'Asso) Michel Fagès a concocté la classe Sharemem et en a même fait un composant
idbat wrote:
Bonjour à tous,
Est-il possible de faire communiquer 2 ou plusieurs applis Windev, lancées
depuis
deux exécutables différents ? et même des applis développées avec des
versions de
Windev défférentes (notamment 8 et 7.5, voire 5.5) ???
Regarde sur WindevAsso (oups y'a eu un coup de vent : Wind'Asso)
Michel Fagès a concocté la classe Sharemem et en a même fait un composant
Est-il possible de faire communiquer 2 ou plusieurs applis Windev, lancées depuis deux exécutables différents ? et même des applis développées avec des versions de Windev défférentes (notamment 8 et 7.5, voire 5.5) ???
Regarde sur WindevAsso (oups y'a eu un coup de vent : Wind'Asso) Michel Fagès a concocté la classe Sharemem et en a même fait un composant
Manu
> Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques : ce que tu me propose c'est de regrouper tout ce qui est partageable entre mes applis dans une, ou plusieurs, bibliothèque(s). Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne feront
que
partager des bouts de codes, qui ne pourront pas interragir entre eux.
OUI.
C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A ne sera pas utilisable (visible et manipulable) par mon appli B (je parle de la même instance de ma fenêtre )?
dans ce cas il faut utiliser la classe ShareMem dispo sur l'asso ou sur le site de wdscript.
-- Emmanuel
> Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques :
ce que tu me propose c'est de regrouper tout ce qui est partageable entre
mes applis dans une, ou plusieurs, bibliothèque(s).
Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne feront
que
partager
des bouts de codes, qui ne pourront pas interragir entre eux.
OUI.
C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A
ne sera pas utilisable (visible et manipulable) par mon appli B (je parle
de la
même instance de ma fenêtre )?
dans ce cas il faut utiliser la classe ShareMem dispo sur l'asso ou sur le
site de wdscript.
> Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques : ce que tu me propose c'est de regrouper tout ce qui est partageable entre mes applis dans une, ou plusieurs, bibliothèque(s). Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne feront
que
partager des bouts de codes, qui ne pourront pas interragir entre eux.
OUI.
C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A ne sera pas utilisable (visible et manipulable) par mon appli B (je parle de la même instance de ma fenêtre )?
dans ce cas il faut utiliser la classe ShareMem dispo sur l'asso ou sur le site de wdscript.
-- Emmanuel
idbat
"Stéphane" a écrit dans le message de news:40c702bd$0$13824$
Bonjour,
Une réponse à froid : mettre dans une bibliothèque (WDL) spécifique toutes les fenêtres qui seront communes au 2 applis puis faire un ChargeWDL dans tes applis. Par contre pour les procédures globales, à première vue je dirais que c'est impossible puisque le code est lié au projet et non pas à une fenêtre.
Ami Calmant Stéphane
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.701 / Virus Database: 458 - Release Date: 07/06/2004
Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques : ce que tu me propose c'est de regrouper tout ce qui est partageable entre mes applis dans une, ou plusieurs, bibliothèque(s). Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne feront que partager des bouts de codes, qui ne pourront pas interragir entre eux. C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A ne sera pas utilisable (visible et manipulable) par mon appli B (je parle de la même instance de ma fenêtre )? Je me trompe ?
Dans ce cas là, c'est pas ce que je veut faire, mais merci quand même ;-)
Yannick.
"Stéphane" <stephane.miqueu@free.fr> a écrit dans le message de
news:40c702bd$0$13824$626a14ce@news.free.fr...
Bonjour,
Une réponse à froid : mettre dans une bibliothèque (WDL) spécifique toutes
les fenêtres qui seront communes au 2 applis puis faire un ChargeWDL dans
tes applis. Par contre pour les procédures globales, à première vue je
dirais que c'est impossible puisque le code est lié au projet et non pas à
une fenêtre.
Ami Calmant
Stéphane
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.701 / Virus Database: 458 - Release Date: 07/06/2004
Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques :
ce que tu me propose c'est de regrouper tout ce qui est partageable entre
mes applis dans une, ou plusieurs, bibliothèque(s).
Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne feront que
partager
des bouts de codes, qui ne pourront pas interragir entre eux.
C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A
ne sera pas utilisable (visible et manipulable) par mon appli B (je parle
de la
même instance de ma fenêtre )?
Je me trompe ?
Dans ce cas là, c'est pas ce que je veut faire, mais merci quand même ;-)
"Stéphane" a écrit dans le message de news:40c702bd$0$13824$
Bonjour,
Une réponse à froid : mettre dans une bibliothèque (WDL) spécifique toutes les fenêtres qui seront communes au 2 applis puis faire un ChargeWDL dans tes applis. Par contre pour les procédures globales, à première vue je dirais que c'est impossible puisque le code est lié au projet et non pas à une fenêtre.
Ami Calmant Stéphane
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.701 / Virus Database: 458 - Release Date: 07/06/2004
Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques : ce que tu me propose c'est de regrouper tout ce qui est partageable entre mes applis dans une, ou plusieurs, bibliothèque(s). Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne feront que partager des bouts de codes, qui ne pourront pas interragir entre eux. C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A ne sera pas utilisable (visible et manipulable) par mon appli B (je parle de la même instance de ma fenêtre )? Je me trompe ?
Dans ce cas là, c'est pas ce que je veut faire, mais merci quand même ;-)
Yannick.
farplus
Bonjour,
Pour ce qui est de chargeDll = les procédures globales suivent; par contre pas de mélange entre possibles entre versions. la classe Sharemem est client/serveur dans le même contexte;
Pour ce qui est du pb ou de l'idée de l'initiateur du post, je pense que cela doit être possible, en faisant à la fois recours à des composants, un serveur, des fonctions comme PostMessage SendMessage, le recours à OuvreFille, LanceAppli etc. , ce qui risque d'être très cher en heures de développement; si les besoins de communication sont réduits, un simple recours au presse-papier (soit windows soit windev) peut s'avérer intéressant.
A+
Manu a présenté l'énoncé suivant :
Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques : ce que tu me propose c'est de regrouper tout ce qui est partageable entre mes applis dans une, ou plusieurs, bibliothèque(s). Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne feront que partager des bouts de codes, qui ne pourront pas interragir entre eux.
OUI.
C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A ne sera pas utilisable (visible et manipulable) par mon appli B (je parle de la même instance de ma fenêtre )?
dans ce cas il faut utiliser la classe ShareMem dispo sur l'asso ou sur le site de wdscript.
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Bonjour,
Pour ce qui est de chargeDll = les procédures globales suivent;
par contre pas de mélange entre possibles entre versions.
la classe Sharemem est client/serveur dans le même contexte;
Pour ce qui est du pb ou de l'idée de l'initiateur du post, je pense
que cela doit être possible, en faisant à la fois recours à des
composants, un serveur, des fonctions comme PostMessage SendMessage, le
recours à OuvreFille, LanceAppli etc. , ce qui risque d'être très cher
en heures de développement;
si les besoins de communication sont réduits, un simple recours au
presse-papier (soit windows soit windev) peut s'avérer intéressant.
A+
Manu a présenté l'énoncé suivant :
Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques :
ce que tu me propose c'est de regrouper tout ce qui est partageable entre
mes applis dans une, ou plusieurs, bibliothèque(s).
Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne feront que
partager
des bouts de codes, qui ne pourront pas interragir entre eux.
OUI.
C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A
ne sera pas utilisable (visible et manipulable) par mon appli B (je parle
de la
même instance de ma fenêtre )?
dans ce cas il faut utiliser la classe ShareMem dispo sur l'asso ou sur le
site de wdscript.
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
Pour ce qui est de chargeDll = les procédures globales suivent; par contre pas de mélange entre possibles entre versions. la classe Sharemem est client/serveur dans le même contexte;
Pour ce qui est du pb ou de l'idée de l'initiateur du post, je pense que cela doit être possible, en faisant à la fois recours à des composants, un serveur, des fonctions comme PostMessage SendMessage, le recours à OuvreFille, LanceAppli etc. , ce qui risque d'être très cher en heures de développement; si les besoins de communication sont réduits, un simple recours au presse-papier (soit windows soit windev) peut s'avérer intéressant.
A+
Manu a présenté l'énoncé suivant :
Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques : ce que tu me propose c'est de regrouper tout ce qui est partageable entre mes applis dans une, ou plusieurs, bibliothèque(s). Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne feront que partager des bouts de codes, qui ne pourront pas interragir entre eux.
OUI.
C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A ne sera pas utilisable (visible et manipulable) par mon appli B (je parle de la même instance de ma fenêtre )?
dans ce cas il faut utiliser la classe ShareMem dispo sur l'asso ou sur le site de wdscript.
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
idbat
ReMerci à vous pour votre aide, mais il me semble que ce "Sharemem" ne fait que partager des données de types chaînes de caractères ? Moi je désire partager des fenêtres, des boutons... en considérant que ces éléments pourront êtres vus et maniables par deux, ou plusieurs, applis simultanément.
ReMerci à vous pour votre aide,
mais il me semble que ce "Sharemem" ne fait que partager
des données de types chaînes de caractères ?
Moi je désire partager des fenêtres, des boutons... en considérant que ces
éléments pourront êtres
vus et maniables par deux, ou plusieurs, applis simultanément.
ReMerci à vous pour votre aide, mais il me semble que ce "Sharemem" ne fait que partager des données de types chaînes de caractères ? Moi je désire partager des fenêtres, des boutons... en considérant que ces éléments pourront êtres vus et maniables par deux, ou plusieurs, applis simultanément.
idbat
Bonjour,
Merci à ceux qui m'ont fait avancer. J'ai regardé "Saheremem" et ça ne semble pas être vraiment adapté à mon besoin : je ne désire pas trop faire de changements (de gros changements qui prennent du temps) dans mon appli secondaire qui fonctionne parfaitement chez des clients suceptibles d'acquérir l'appli en cours de développement. Je veux réellement piloter une appli depuis une autre et inversement, pas seulement envoyer des infos simples (nombre, chaînes de car.,...).
En attendant une réponse de pcsoft (ou que leur ligne téléphonique ne soit plus surbookée), nous avons réfléchi sur la question, et pensé que cette communication directe n'est pas si nécessaire que ça et nous avons trouvé une autre solution.
Mais si vous avez une solution "simple", je suis toujours preneur.
Yannick.
"farplus" a écrit dans le message de news:
Bonjour,
Pour ce qui est de chargeDll = les procédures globales suivent; par contre pas de mélange entre possibles entre versions. la classe Sharemem est client/serveur dans le même contexte;
Pour ce qui est du pb ou de l'idée de l'initiateur du post, je pense que cela doit être possible, en faisant à la fois recours à des composants, un serveur, des fonctions comme PostMessage SendMessage, le recours à OuvreFille, LanceAppli etc. , ce qui risque d'être très cher en heures de développement; si les besoins de communication sont réduits, un simple recours au presse-papier (soit windows soit windev) peut s'avérer intéressant.
A+
Manu a présenté l'énoncé suivant : >> Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques
:
>> ce que tu me propose c'est de regrouper tout ce qui est partageable
entre
>> mes applis dans une, ou plusieurs, bibliothèque(s). >> Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne
feront que
>> partager >> des bouts de codes, qui ne pourront pas interragir entre eux. > > OUI. > >> C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A >> ne sera pas utilisable (visible et manipulable) par mon appli B (je
parle
>> de la >> même instance de ma fenêtre )? > > dans ce cas il faut utiliser la classe ShareMem dispo sur l'asso ou sur
le
> site de wdscript.
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Bonjour,
Merci à ceux qui m'ont fait avancer.
J'ai regardé "Saheremem" et ça ne semble pas être vraiment adapté à mon
besoin :
je ne désire pas trop faire de changements (de gros changements qui prennent
du temps) dans
mon appli secondaire qui fonctionne parfaitement chez des clients
suceptibles d'acquérir l'appli
en cours de développement.
Je veux réellement piloter une appli depuis une autre et inversement, pas
seulement envoyer des infos
simples (nombre, chaînes de car.,...).
En attendant une réponse de pcsoft (ou que leur ligne téléphonique ne soit
plus surbookée), nous avons
réfléchi sur la question, et pensé que cette communication directe n'est pas
si nécessaire que ça et nous avons
trouvé une autre solution.
Mais si vous avez une solution "simple", je suis toujours preneur.
Yannick.
"farplus" <farplus@free.fr> a écrit dans le message de
news:mn.4c087d46dd3405c0.9677@free.fr...
Bonjour,
Pour ce qui est de chargeDll = les procédures globales suivent;
par contre pas de mélange entre possibles entre versions.
la classe Sharemem est client/serveur dans le même contexte;
Pour ce qui est du pb ou de l'idée de l'initiateur du post, je pense
que cela doit être possible, en faisant à la fois recours à des
composants, un serveur, des fonctions comme PostMessage SendMessage, le
recours à OuvreFille, LanceAppli etc. , ce qui risque d'être très cher
en heures de développement;
si les besoins de communication sont réduits, un simple recours au
presse-papier (soit windows soit windev) peut s'avérer intéressant.
A+
Manu a présenté l'énoncé suivant :
>> Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques
:
>> ce que tu me propose c'est de regrouper tout ce qui est partageable
entre
>> mes applis dans une, ou plusieurs, bibliothèque(s).
>> Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne
feront que
>> partager
>> des bouts de codes, qui ne pourront pas interragir entre eux.
>
> OUI.
>
>> C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A
>> ne sera pas utilisable (visible et manipulable) par mon appli B (je
parle
>> de la
>> même instance de ma fenêtre )?
>
> dans ce cas il faut utiliser la classe ShareMem dispo sur l'asso ou sur
le
> site de wdscript.
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
Merci à ceux qui m'ont fait avancer. J'ai regardé "Saheremem" et ça ne semble pas être vraiment adapté à mon besoin : je ne désire pas trop faire de changements (de gros changements qui prennent du temps) dans mon appli secondaire qui fonctionne parfaitement chez des clients suceptibles d'acquérir l'appli en cours de développement. Je veux réellement piloter une appli depuis une autre et inversement, pas seulement envoyer des infos simples (nombre, chaînes de car.,...).
En attendant une réponse de pcsoft (ou que leur ligne téléphonique ne soit plus surbookée), nous avons réfléchi sur la question, et pensé que cette communication directe n'est pas si nécessaire que ça et nous avons trouvé une autre solution.
Mais si vous avez une solution "simple", je suis toujours preneur.
Yannick.
"farplus" a écrit dans le message de news:
Bonjour,
Pour ce qui est de chargeDll = les procédures globales suivent; par contre pas de mélange entre possibles entre versions. la classe Sharemem est client/serveur dans le même contexte;
Pour ce qui est du pb ou de l'idée de l'initiateur du post, je pense que cela doit être possible, en faisant à la fois recours à des composants, un serveur, des fonctions comme PostMessage SendMessage, le recours à OuvreFille, LanceAppli etc. , ce qui risque d'être très cher en heures de développement; si les besoins de communication sont réduits, un simple recours au presse-papier (soit windows soit windev) peut s'avérer intéressant.
A+
Manu a présenté l'énoncé suivant : >> Merci pour l'aide, mais j'ai une question à propos de ces bibliothèques
:
>> ce que tu me propose c'est de regrouper tout ce qui est partageable
entre
>> mes applis dans une, ou plusieurs, bibliothèque(s). >> Mais, dans ce cas là, mes applis ne communiqueront pas : elles ne
feront que
>> partager >> des bouts de codes, qui ne pourront pas interragir entre eux. > > OUI. > >> C'est à dire qu'une fenêtre de ma bibliothèque ouverte par une appli A >> ne sera pas utilisable (visible et manipulable) par mon appli B (je
parle
>> de la >> même instance de ma fenêtre )? > > dans ce cas il faut utiliser la classe ShareMem dispo sur l'asso ou sur
le
> site de wdscript.
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Antoine
idbat wrote:
Bonjour à tous,
Est-il possible de faire communiquer 2 ou plusieurs applis Windev, lancées depuis deux exécutables différents ? et même des applis développées avec des versions de Windev défférentes (notamment 8 et 7.5, voire 5.5) ???
Mon objectif serait de pouvoir appeler des fonctions/procédures d'une appli depuis une autre, et inversement, de pouvoir utiliser certaines fenêtres de l'appli secondaire, ou mieux de pouvoir "intégrer" des fenêtres d'une autre appli en les gérant comme si elles faisaient partie de l'appli principale, tout en laissant la possibilité à l'autre appli de les commander aussi... et tout ceci sans intégrer au niveau code toutes les fenêtres, procédures, tout le code... de l'autre appli.
Merci d'avance pour les réponses nombreuses ( enfin j'espère ;-) )
Yannick.
Je pense que la seule bonne méthode est d'utiliser des application WinDev compilés avec la meme version de WinDev (la 8). Ainsi, l'utilisation de composants et de messages socket te permettra d'obtenir le traitement que tu recherches. Toute autre méthode est à banir.
Antoine
idbat wrote:
Bonjour à tous,
Est-il possible de faire communiquer 2 ou plusieurs applis Windev,
lancées depuis
deux exécutables différents ? et même des applis développées avec des
versions de
Windev défférentes (notamment 8 et 7.5, voire 5.5) ???
Mon objectif serait de pouvoir appeler des fonctions/procédures d'une
appli depuis
une autre, et inversement, de pouvoir utiliser certaines fenêtres de
l'appli secondaire,
ou mieux de pouvoir "intégrer" des fenêtres d'une autre appli en les
gérant comme si
elles faisaient partie de l'appli principale, tout en laissant la
possibilité à l'autre appli
de les commander aussi... et tout ceci sans intégrer au niveau code
toutes les fenêtres,
procédures, tout le code... de l'autre appli.
Merci d'avance pour les réponses nombreuses ( enfin j'espère ;-) )
Yannick.
Je pense que la seule bonne méthode est d'utiliser des application WinDev
compilés avec la meme version de WinDev (la 8). Ainsi, l'utilisation de
composants et de messages socket te permettra d'obtenir le traitement que tu
recherches. Toute autre méthode est à banir.
Est-il possible de faire communiquer 2 ou plusieurs applis Windev, lancées depuis deux exécutables différents ? et même des applis développées avec des versions de Windev défférentes (notamment 8 et 7.5, voire 5.5) ???
Mon objectif serait de pouvoir appeler des fonctions/procédures d'une appli depuis une autre, et inversement, de pouvoir utiliser certaines fenêtres de l'appli secondaire, ou mieux de pouvoir "intégrer" des fenêtres d'une autre appli en les gérant comme si elles faisaient partie de l'appli principale, tout en laissant la possibilité à l'autre appli de les commander aussi... et tout ceci sans intégrer au niveau code toutes les fenêtres, procédures, tout le code... de l'autre appli.
Merci d'avance pour les réponses nombreuses ( enfin j'espère ;-) )
Yannick.
Je pense que la seule bonne méthode est d'utiliser des application WinDev compilés avec la meme version de WinDev (la 8). Ainsi, l'utilisation de composants et de messages socket te permettra d'obtenir le traitement que tu recherches. Toute autre méthode est à banir.
