PC SOFT

GRUPOS DE DISCUSSÃO PROFISSIONAL
WINDEVWEBDEV e WINDEV Mobile

Inicio → WINDEV 2024 → WM_COPYTA (inter process communication)
WM_COPYTA (inter process communication)
Iniciado por Patrice TERRIER, out., 14 2019 11:52 AM - 2 respostas
Membro registado
150 mensagems
Popularité : +15 (15 votes)
Publicado em outubro, 14 2019 - 11:52 AM
J'utilise sans problème WM_COPYDATA pour communiquer entre un process 64-bit et un process 32-bit lorsque les 2 sont codés en code natif (C++ pour le 64-bit et PowerBASIC pour le 32-bit).
J'essaie de faire la même chose avec Windev (WD17) en mode 64-bit sans succès, alors que je çà marche avec en 32-bit.

Ma question est donc quelqu'un a-t-il déjà utilisé avec succès WM_COPYDATA avec WinDev en 64-bit et un process 32-bit, si oui comment ?

J'utilise la structure suivante dans le code Windev en 64-bit :
COPYDATASTRUCT is structure
dwData is int //Type C : DWORD
cbData is int //Type C : DWORD
lpData is system int //Type C : PVOID
//alignment is int
END

BBPDATA is structure
gdimageID is int
plugin is string ASCIIZ on MAX_PATH
nLevel is unsigned int
medialength is unsigned int
mediapos is unsigned int
END

lpData est le pointeur vers la structure BBDATA, dont je n'arrive pas à passer correctement l'adresse du membre
plugin is string ASCIIZ on MAX_PATH

Dois-je essayer avec un buffer au lieu d'une chaine ASCIIZ ?

--
Patrice Terrier
www.zapsolution.com
Membro registado
505 mensagems
Popularité : +18 (18 votes)
Publicado em outubro, 14 2019 - 1:07 PM
Bonjour Patrice,

Bravo pour ton travail que je suis de loin, mais avec curiosité et intérêt. :-)

Je te confirme que le type Chaîne ASCIIZ Sur XXX réserve exactement le nombre d'octets donné par XXX. C'est à dire que le caractère zéro "final" sera bien quelque part entre le 1er octet inclus et le XXXème octet inclus.
Tu peux toujours remplacer par Buffer sur XXX si tu veux.

Je crois que le problème vient de la structure COPYDATASTRUCT dont le membre dwData serait un pointeur selon la doc en lien ci-dessous.
Donc il faut le typer comme entier système.

https://docs.microsoft.com/fr-fr/windows/win32/api/winuser/ns-winuser-copydatastruct

typedef struct tagCOPYDATASTRUCT {
  ULONG_PTR dwData;
  DWORD     cbData;
  PVOID     lpData;
} COPYDATASTRUCT, *PCOPYDATASTRUCT;


--
Pour me contacter par courrier électronique, cliquez sur le lien ci-dessous (protection antispam): http://cerbermail.com/…
Mensagem modificada, outubro, 14 2019 - 1:19 PM
Membro registado
150 mensagems
Popularité : +15 (15 votes)
Publicado em outubro, 14 2019 - 2:21 PM
JBO

Merci pour la réponse.

En C++ 64-bit, sizeof(COPYDATASTRUCT) = 24 (alignement sur 8-bit), et la moité en 32-bit.
Dans mes test dwData doit bien rester un entier non signé sur 4 octets (DWORD).
Car pour des raisons de compatibilité seuls les 4 premiers octets sont significatifs (justement pour interfacer du code 64 avec du 32-bit).
WM_COPYDATA effectuant la conversion à la volée.

Au demeurant WM_COPYDATA encapsule l'API "memory mapped files" pour le passage des datas.
Ce qui me perturbe c'est que çà marche très bien avec du vrai code compilé natif.
Et je fais exactement la même chose dans mon code WinDev que dans mon code C++.

En dernier recours je peux essayer directement une "memory mapped file", mais je préfèrerai garder un code identique pour toutes mes applications quel que soit le langage utilisé.

--
Patrice Terrier
www.zapsolution.com