PC SOFT

FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile

|
|
|
FR
Accueil → WINDEV 2024 → dialoguer entre 2 applications
dialoguer entre 2 applications
Débuté par sebastien.bonnet, 30 jan. 2006 16:50 - 7 réponses
#1
Posté le 30 janvier 2006 - 16:50
Bonjour,

Je souhaite dialoguer entre 2 applications windev installé sur le même pc. Quel est la meilleur méthode a utiliser. (J'ai pensé a une zone memoire partagée (j'ai vu ca dans une LST) mais peut être y a t'il mieux que cela ???)

Merci de vos suggestions.
#2
Posté le 30 janvier 2006 - 23:27
Bonjour,
Ca dépend. Est qu'il y a un dialogue entre les deux application ? Est-ce qu'il y a beaucoup d'informations à échanger ? Est-ce que les informations échangées ne sont que des signaux, ou ces informations sont-elles structurées ? Est-ce qu'une des applications peut-être déplacée sur un autre poste ? Est-ce que les deux application supporte le fait que l'autre soit arrêtée ?

Frédéric.
#3
Posté le 01 février 2006 - 14:41
L'informations entre les 2 applis est minime et les 2 applis ne seront jamais en reseau.
En fait, une des applis envoi une informations (une variable chaine) et l'autre appli doit lire cette information sans retourner de reponse.
#4
Posté le 01 février 2006 - 15:18
Sébastien a écrit :
L'informations entre les 2 applis est minime et les 2 applis ne seront jamais en reseau.
En fait, une des applis envoi une informations (une variable chaine) et l'autre appli doit lire cette information sans retourner de reponse.


à mon avis, un simple fichier.ini devrait suffire.
un petit timer dans l'appli qui doit lire pour mettre à jour.

--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com
#5
Posté le 01 février 2006 - 16:43
jackt81 a écrit :
Sébastien a écrit :
L'informations entre les 2 applis est minime et les 2 applis ne seront jamais en reseau.
En fait, une des applis envoi une informations (une variable chaine) et l'autre appli doit lire cette information sans retourner de reponse.


à mon avis, un simple fichier.ini devrait suffire.
un petit timer dans l'appli qui doit lire pour mettre à jour.

un fichier ini permettrait de stocker le handle des 2 applications. (ou
0 pour dire que l'application est fermé)
ensuite si le temps presque réel est requis utilise les messages windows
(appelé évènements entre autre)
Ca permet de synchroniser les applications sans problèmes et quasiment
en temps réel.

A++
Goof

PS : c'est de la théorie pure car je n'ai pas essayé entre 2
applications différentes. Par contre moi ça marche très bien entre un
thread de travail et la fenêtre de application
#6
Posté le 02 février 2006 - 09:40
J'ai déjà utilisé ce système et il n'y a aucun problème
PA est le premier programme
PB est le second programme

1° Méthode pour signaler l'évenement
//**********
Dans Initialisation de PA et PB :Demander à Windows un numéro unique de message

WM_NumMessage est un entier
WM_Message est une chaîne ASCIIZ sur 128 = ""
NumEvenement est un entier = 0

WM_Message = "ICI METTRE UNE PHRASE UNIQUE MAX 127 CHAR"
WM_NumMessage = AppelDLL32,"USER32.DLL","RegisterWindowMessageA",&WM_Message)
Evénement(<procedure>, "*.*", WM_NumMessage)
// Tester que WM_NumMessage>0

//**********
Dans la fin du projet
IF NumEvenement>0 THEN FinEvénement(NumEvenement)

// Entête de la procédure
PROCEDURE <procedure>(pNumMessage, pwParam, pwLParam)
........

2° PA veut envoyer un signal à PB
SendMessage(SysFenHandle(<Titre fenêtre B>), WM_NumMessage, wParam, wLParam)
wParam, wLParam sont deux entiers libres....

MAINTENANT POUR PASSER UNE CHAINE, IL Y A :
1° Le fichier INI, TEXTE, HYPERFILE....
2° Le file mapping un chouia plus complexe à mettre en oeuvre mais plus performant. Le principe c'est de reserver un zone du disque pour émuler une zone mémoire partagée 1/2 et en lecture 1/2 en écriture. L'avantage c'est qu'une fois l'information lue elle est automatiquement supprimée.

METHODE POUR CREER UN FILE MAPPING
lpFileName est une chaine asciiz sur 32 = <Nom d'un fichier unique>

// CREATION DU FICHIER PHYSIQUE
hFile est un entier = AppelDLL32("KERNEL32","CreateFileA",&lpFileName,0xC0000000,0x00000003,0x0,0x04,0x04000002,0x0)
if hFile = 0x0 then renvoyer Faux

// CREATION DU MAPPING SUR LE FICHIER
hFileMapping est un entier = 0x0
FileMap est une chaine asciiz sur 32 = <Nom du mapping>
hFileMapping = appeldll32("KERNEL32","CreateFileMappingA",hFile,0x00,0x04,0,1024,&FileMap)
if HFileMapping = 0x0 then renvoyer Faux

// CREATION DE LA VUE
Ptr est un entier = 0x0
Ptr = appeldll32("KERNEL32","MapViewOfFile",hFileMapping,0x000F001F,0,0,1024)
if Ptr = 0x0 then renvoyer faux

// LECTURE
cBuffer est une chaine asciiz sur 129 = "" // 128 + 0x00 terminal
transfert(&cBuffer, Ptr, 128) // Pas trop dur
// ECRITURE
transfert(Ptr,&cBuffer,128) // La on frise le délire ...

// DESTRUCTION DU FILE MAPPING
appeldll32("KERNEL32","UnmapViewOfFile",Ptr)
appeldll32("KERNEL32","CloseHandle",hFileMapping )
appeldll32("KERNEL32","CloseHandle",hFile)



Mais en tout cas je ne suis pas partisant du timer car trop de risque de perdre des données
En apparence, cela parrait compliqué, mais c'est plus rapide et plus souple...

Bon windev
#7
Posté le 02 février 2006 - 10:29
Philippe Pasquali a écrit :
J'ai déjà utilisé ce système et il n'y a aucun problème
PA est le premier programme
PB est le second programme

1° Méthode pour signaler l'évenement
//**********
Dans Initialisation de PA et PB :Demander à Windows un numéro unique de message

WM_NumMessage est un entier
WM_Message est une chaîne ASCIIZ sur 128 = ""
NumEvenement est un entier = 0

WM_Message = "ICI METTRE UNE PHRASE UNIQUE MAX 127 CHAR"
WM_NumMessage = AppelDLL32,"USER32.DLL","RegisterWindowMessageA",&WM_Message)
Evénement(<procedure>, "*.*", WM_NumMessage)
// Tester que WM_NumMessage>0

//**********
Dans la fin du projet
IF NumEvenement>0 THEN FinEvénement(NumEvenement)

// Entête de la procédure
PROCEDURE <procedure>(pNumMessage, pwParam, pwLParam)
.......

2° PA veut envoyer un signal à PB
SendMessage(SysFenHandle(<Titre fenêtre B>), WM_NumMessage, wParam, wLParam)
wParam, wLParam sont deux entiers libres....

MAINTENANT POUR PASSER UNE CHAINE, IL Y A :
1° Le fichier INI, TEXTE, HYPERFILE....
2° Le file mapping un chouia plus complexe à mettre en oeuvre mais plus performant. Le principe c'est de reserver un zone du disque pour émuler une zone mémoire partagée 1/2 et en lecture 1/2 en écriture. L'avantage c'est qu'une fois l'information lue elle est automatiquement supprimée.

METHODE POUR CREER UN FILE MAPPING
lpFileName est une chaine asciiz sur 32 = <Nom d'un fichier unique>

// CREATION DU FICHIER PHYSIQUE
hFile est un entier = AppelDLL32("KERNEL32","CreateFileA",&lpFileName,0xC0000000,0x00000003,0x0,0x04,0x04000002,0x0)
if hFile = 0x0 then renvoyer Faux

// CREATION DU MAPPING SUR LE FICHIER
hFileMapping est un entier = 0x0
FileMap est une chaine asciiz sur 32 = <Nom du mapping>
hFileMapping = appeldll32("KERNEL32","CreateFileMappingA",hFile,0x00,0x04,0,1024,&FileMap)
if HFileMapping = 0x0 then renvoyer Faux

// CREATION DE LA VUE
Ptr est un entier = 0x0
Ptr = appeldll32("KERNEL32","MapViewOfFile",hFileMapping,0x000F001F,0,0,1024)
if Ptr = 0x0 then renvoyer faux

// LECTURE
cBuffer est une chaine asciiz sur 129 = "" // 128 + 0x00 terminal
transfert(&cBuffer, Ptr, 128) // Pas trop dur
// ECRITURE
transfert(Ptr,&cBuffer,128) // La on frise le délire ...

// DESTRUCTION DU FILE MAPPING
appeldll32("KERNEL32","UnmapViewOfFile",Ptr)
appeldll32("KERNEL32","CloseHandle",hFileMapping )
appeldll32("KERNEL32","CloseHandle",hFile)



Mais en tout cas je ne suis pas partisant du timer car trop de risque de perdre des données
En apparence, cela parrait compliqué, mais c'est plus rapide et plus souple...

Bon windev



C'est vrais que les évènements permettent uniquement de passer des
numériques. Mais ça permet de lancer des traitements différents suivant
les valeurs récupéré.
Le message permet surtout une interactivitée direct entre les applications.
Perso moi je prend le WM_USER comme message (1024) qui n'est pas sensé
être utilisé par le framework ou un quelconque objet. ce qui évite aussi
l'appel aux API.

a++
Goof
#8
Posté le 03 février 2006 - 11:14
Je ferai une remarque supplémentaire concernant les "MessageWindows" :
Les messages sont stockés dans une pile en attendant leur traitement, et
lorsque la pile est pleine, les messages sont perdus !.....
Par exemple, sur une CPU un peu lente, avec un utilisateur impatient qui
"bouge sa souris" dans tout les sens ... ça créé mes centaines de messages
.... et certains se perdent (la souris "saute" d'un point à un autre de
l'écran lors du déplacement). Si tu as "Posté" un message à ce moment, il
peut être perdu.
Il faut donc rajouter une numérotation + un dialogue de "ré envoi" en cas de
perte de sequence dans la numérotation pour le recepteur.

Gérard.

"Philippe Pasquali" <philippe.pasquali@bopack.com> a écrit dans le message
de news: 43e1b6ab$1@news.pcsoft.fr...

J'ai déjà utilisé ce système et il n'y a aucun problème
PA est le premier programme
PB est le second programme

1° Méthode pour signaler l'évenement
//**********
Dans Initialisation de PA et PB :Demander à Windows un numéro unique de
message

WM_NumMessage est un entier
WM_Message est une chaîne ASCIIZ sur 128 = ""
NumEvenement est un entier = 0

WM_Message = "ICI METTRE UNE PHRASE UNIQUE MAX 127 CHAR"
WM_NumMessage =
AppelDLL32,"USER32.DLL","RegisterWindowMessageA",&WM_Message)
Evénement(<procedure>, "*.*", WM_NumMessage)
// Tester que WM_NumMessage>0

//**********
Dans la fin du projet
IF NumEvenement>0 THEN FinEvénement(NumEvenement)

// Entête de la procédure
PROCEDURE <procedure>(pNumMessage, pwParam, pwLParam)
.......

2° PA veut envoyer un signal à PB
SendMessage(SysFenHandle(<Titre fenêtre B>), WM_NumMessage, wParam,
wLParam)
wParam, wLParam sont deux entiers libres....

MAINTENANT POUR PASSER UNE CHAINE, IL Y A :
1° Le fichier INI, TEXTE, HYPERFILE....
2° Le file mapping un chouia plus complexe à mettre en oeuvre mais plus
performant. Le principe c'est de reserver un zone du disque pour émuler
une zone mémoire partagée 1/2 et en lecture 1/2 en écriture. L'avantage
c'est qu'une fois l'information lue elle est automatiquement supprimée.

METHODE POUR CREER UN FILE MAPPING
lpFileName est une chaine asciiz sur 32 = <Nom d'un fichier unique>

// CREATION DU FICHIER PHYSIQUE
hFile est un entier =
AppelDLL32("KERNEL32","CreateFileA",&lpFileName,0xC0000000,0x00000003,0x0,0x04,0x04000002,0x0)
if hFile = 0x0 then renvoyer Faux

// CREATION DU MAPPING SUR LE FICHIER
hFileMapping est un entier = 0x0
FileMap est une chaine asciiz sur 32 = <Nom du mapping>
hFileMapping =
appeldll32("KERNEL32","CreateFileMappingA",hFile,0x00,0x04,0,1024,&FileMap)
if HFileMapping = 0x0 then renvoyer Faux

// CREATION DE LA VUE
Ptr est un entier = 0x0
Ptr =
appeldll32("KERNEL32","MapViewOfFile",hFileMapping,0x000F001F,0,0,1024)
if Ptr = 0x0 then renvoyer faux

// LECTURE
cBuffer est une chaine asciiz sur 129 = "" // 128 + 0x00 terminal
transfert(&cBuffer, Ptr, 128) // Pas trop dur
// ECRITURE
transfert(Ptr,&cBuffer,128) // La on frise le délire ...

// DESTRUCTION DU FILE MAPPING
appeldll32("KERNEL32","UnmapViewOfFile",Ptr)
appeldll32("KERNEL32","CloseHandle",hFileMapping )
appeldll32("KERNEL32","CloseHandle",hFile)



Mais en tout cas je ne suis pas partisant du timer car trop de risque de
perdre des données
En apparence, cela parrait compliqué, mais c'est plus rapide et plus
souple...

Bon windev


→ Revenir à WINDEV 2024