migration VC6 ver VS2017

Version imprimable

13/05/2020, 11h15
sybe30

migration VC6 ver VS2017
Bonjour,

Je dois faire la migration pour un soft écrit en VC6 vers une version plus actuelle (vs2017). J'ai déjà essayé quelques plâtres mais là je coince depuis quelques jours et je n'ai pas d'idée. J'ai donc besoin de vous car je suis coincé.

Ce soft utilise les MFC et j'ai actuellement un problème dans une boite de dialogue (CFileDialog) pour choisir un fichier. Le fonctionnement nominal que je comprends (pas de doc et pas l'auteur d'origine) c'est qu'un thread tourne en fond qui connait notre format de fichier propriétaire, la boite de dialogue lui adresse une requête quand on (simple) clic sur un fichier ce qui a pour effet que ce thread de fond verifie 2 ou 3 trucs dans le fichier. La requête est faite via un système de messagerie pour que l'IHM reste pas figé. A la fin des vérification un système plus ou moins compliqué fait que le thread de fond doit dire à l'IHM que la vérification est terminée. Ceci doit se faire par un message avec un PostMessage. En pas à pas j'arrive bien jusqu'au PostMessage sans erreur.
Code:

1 2 3 4 5 if (::PostMessage(hLocalWnd, WM_PROXY_RESPONSE, static_cast<WPARAM>(NULL), reinterpret_cast<LPARAM>(pCopyHint)) != 0) { delete pCopyHint, pCopyHint = NULL; }
Mais personne ne réceptionne le message !

J'ai cherché sur le NET et j'ai trouvé 2 trucs que je n'ai pas pu confirmer ou infirmer.
- Depuis une certaine version (VIStA) certaines méthodes ne sont plus appelées (CFileDialog::OnInitDialog par exemple). Je confirme juste qu'effectivement je ne passe pas dans ma méthode surchargée. Mais je n'ai pas trouvé de work around sur ce sujet. Donc certaines choses ne sont pas faites dans le code.
- Il paraîtrait que dans le cadre de certains xx.DoModal() les user messages ne sont pas propagés.
Ces 2 items pourraient expliquer bien des choses mais je sais pas quoi en faire.

Je ne suis pas développeur Windows est j'ai jamais fais de MFC (un peu de WIN32 historiquement et maintenant C#).

J'ai besoin de vous aussi bien pour solutionner le problème si vous avez rencontré ces problèmes que pour m'aider à investiguer si vous avez des réflexes, des outils géniaux sur ce framework.

Merci
15/05/2020, 09h27
Médinoc

Je ne connais pas assez les filedialogs pour aider (encore moins les filedialogs customisées), mais l'extrait de code posé est désastreux: Si le PostMessage() a réussi, le destinataire va recevoir un pointeur qui n'est plus valide!
15/05/2020, 16h23
sybe30

Bonjour Médinoc,

Ne soyons pas si catégorique. Oui le code est désastreux et tu n'as vu qu'une seule ligne !!! je te garantie que tout est de ce niveau.
Bref je n'ai pas le temps de réécrire il s'agissait au début de se donner juste les moyens de recompiler avec un outil du 21eme siecle.

Désastreux peut etre mais vous (clients) vous l'achetez ! donc mon patron veut tout faire au minimum comme baucoups d'autres patron.
Bref inutile de philosopher ici et bienvenu dans la vrai vie ....

En revanche même si c'est c'est moche, hideux, desastreux, etc ... le pointeur peut être valide.
Dans mes souvenirs d'école sous windows les processus (WIN32) ont un espace mémoire virtuel de 4Go et à l'intérieur d'un process les threads partagent le même espace d'adressage.
Donc la je suis dans 2 threads mais 1 seul process. Enfin aprés je suis pas certain car je suis developpeur embarqué/TR et je code plutot sous VxWorks ou QNX mais y'avait personne d'autre pour cette maintenance ou alors je suis puni ! :?

Merci à ceux qui pourront m'aider.
17/05/2020, 17h27
dalfab

Citation:

Envoyé par sybe30

En revanche même si c'est c'est moche, hideux, desastreux, etc ... le pointeur peut être valide.
Dans mes souvenirs d'école sous windows les processus (WIN32) ont un espace mémoire virtuel de 4Go et à l'intérieur d'un process les threads partagent le même espace d'adressage.
Donc la je suis dans 2 threads mais 1 seul process. Enfin aprés je suis pas certain car je suis developpeur embarqué/TR et je code plutot sous VxWorks ou QNX mais y'avait personne d'autre pour cette maintenance ou alors je suis puni ! :?

Oui, de toute façon ça n'aurait aucun sens d'envoyer à un pointeur à un autre process, n'étant pas dans le même espace mémoire sa valeur serait inutilisable.
Mais que fait le code ici :
- émission de la valeur d'un pointeur dans la file d'attente d'une fenêtre;
- un fois la mise en pile accepté : rendre au système la mémoire que désigne ce pointeur!
A partir de cet instant, on a :
- un thread va recevoir cette adresse pour y lire des informations
- la prochaine allocation de mémoire peut tout à fait réutiliser cette zone pour y écrire ce qu'elle veut.
Et là tout peut arriver, c'est un "undefined behavior" qui peut tout à fait tomber en marche (et c'était le cas jusqu'à présent!)

Pour revenir au message mystérieux. Il s'appelle WM_PROXY_RESPONSE, il est donc nommé comme un message standard de Windows, en tout cas je n'ai jamais entendu parler de lui! Y a-t-il une fenêtre ou une "pump" dans une liste d'attente qui cherche à reconnaître ce message? On peut aussi vérifier la valeur de retour de PostMessage() qui va retourner 1 si elle l'a émis et retourner 0 sinon. Et dans ce cas il faudrait appeler immédiatement après GetLastError() pour connaître le problème.

Il ne faut pas oublier que recompiler un code qui contient des "undefined behavior" risque de provoquer des "curiously different behavior"
26/05/2020, 09h52
sybe30
Bonjour,

Le code retour de PostMessage est bon. Je pense que le if devrait etre sur '==' et non sur '!=' . Car il faudrait que le code utilisateur le désalloue (ou pas, on n'est pas à une fuite memoire pret ...) et le code 'emmetteur' uniquement si erreur.

WM_PROXY_RESPONSE est un message custom. D'ailleur j'ai trouvé 2 definition dans ce code :
Code:

1 2 WM_PROXY_RESPONSE = WM_USER + 10 // dans un enum
et
Code:

1 2 WM_PROXY_RESPONSE=WM_APP + 1 // dans un autre enum
J'ai déjà supprimé le premier mais je pense que je vais aussi supprimer l'enum pour un define. Donc oui ce n'est pas un message windows.
Oui aussi il y a des fenetres qui attendent ce messages mais qui ne le recoivent jamais. J'ai l'impression qu'l est envoyé à une mauvaise fenetre. Mais cela fonctionnait avant en VC6 (sous reserve que j'ai le bon code).

Y a t'il eu des changements notables sur la gestion des fenetres entre VC6 et 2017 (et sur le principe de tratement des messages) qui pourraient expliquer que je n'ai plus le bon handle là ou il etait correct avant ?

Merci