interaction aléatoire entre 2 programmes Msv2005

Bonjour a tout le monde.

J'ai créer 2 programmes en Visual C++ 2005, et quand je lance l'exécution d'un des programmes, la fenêtre de l'autre est rafraichis (et pas toujours correctement!) .
Des 'Static Text' disparaisses, et parfois la moitié de certaines icones!
Nota:
Pour créer de nouveaux programmes j'ai l'habitude de faire une copie d'un existant et de changer les nom dedans (j'ai fais un programme qui fais cela tout seul!)

Je me demande si quelqu'un a déjà eu ce type de problème?
C'est quand même incroyable, je n'utilise pas de Mutex dans les programmes.
je suis sous W10 et je considère que c'est un problème très grave de fonctionnement.
Imaginer la pagaille si cela ce généralise!

Mes programmes sont assez gros 2429 lignes pour ChaudierDlg.CPP et 5539 lignes pour l'autre Dlg.cpp

Si quelqu'un a des idées je suis preneur!
Merci

Tes programmes utilisent-ils FindWindow()?
Ou des fichiers ouverts sans autoriser le partage en lecture? (par exemple, avec fopen(); seul fopen_s() autorise la lecture quand on ouvre un fichier en lecture seule)

Bonjour,

Merci pour le réponse, je n'utilise pas FindWindow(), mais j'utilise fopen avec des fichiers non communs qui n'ont pas les mêmes noms et se sont pas dans les mêmes répertoires

par contre j'utilise SetTimer(ID_CLOCK_TIMER,500,NULL); dans tous les programmes

Sans code, ça va être compliqué d'être précis.
Mais si vous faites du développement à base de copier-coller, vous cherchez sérieusement les emmerdes.
Si vous utilisez des vieux machins comme Win32 SDK qui utilisent des enregistrements globaux à l'OS comme les classes de fenêtres ou l'enregistrement de type de message custom ou encore des GUID pour des "classes" COM, c'est normal que cela fout le bordel dans l'exécution des exécutables.
NE FAITES PAS DE COPIER-COLLER, les wizards des framework sont là pour faire ces choses CORRECTEMENT.

Il est dont très très probable que le problème soit entre la chaise et le clavier et pas dans l'OS.

Utilisez GitHub ou l'équivalent pour montrer vos codes "Frankenstein".

Bonjour,

Merci Bacelar pour ta réponse, mais je ne suis pas très chaud pour donner le code comme cela (pas mal de jours de codage)

(le programme marche, ce n'est que l'affichage)
J'ai fait quelques manip! le problème ne se produit que si je lance le 2me code a partir de VISUAL studio. je réduit et j'agrandis la fenêtre du 1er programme et l'affichage redevient OK!
Idem que le 1er programme soit compile en debug ou en release, et toujours idem avec 'Use MFC in a Static Library' ou 'Use MFC in a Shared DLL'

le phénomène ce produit au tout départ ou a l'arrêt du 2eme programmes.

j'essaye d'envoyer une image avant et après du problème

Pour information pour les leds en couleur en haut, c'est normal, j'ai mis des flip flop sur la réception des messages de la chaudière électrique 6KW/9KW que j'ai fait, sur la liaison radio rs232 avec le compteur LINKY, la liaison USB RF433.92MHz pour les 4 capteurs de température dans la maison, et enfin une autre liaison radio rs232 avec les panneaux solaires.

Pour le reste ce n'est pas normal, pas mal de message on disparus(pas toujours les mêmes) exemple 'T_in 24.4°' … et surtout le bouton d'arrêt d'urgence 'STOP' (parfois la moitié de gauche reste intacte!)

Bref c'est la CATA!

dans chaudiereDlg.h

Code:

---

1 2 3 4 5 6

// Dialog Data //{{AFX_DATA(CchaudiereDlg) enum { IDD = IDD_CHAUDIERE_DIALOG }; CString m_edit_t1; public: CColorEdit m_edit_t1_ctrl;

---

dans chaudiereDlg.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

m_edit_t1 = _T(""); DDX_Text(pDX, IDC_EDIT_T1, m_edit_t1); DDX_Control(pDX, IDC_EDIT_T1, m_edit_t1_ctrl); BOOL CchaudiereDlg::OnInitDialog() { ... m_edit_t1_ctrl.SetBkColor(BLACK); m_edit_t1_ctrl.SetTextColor(WHITE); ... void CchaudiereDlg::OnTimer(UINT nIDEvent) { ... if (mot[7] == "t1") { t1 = strtod(mot[8],&stopstring); m_edit_t1.Format("T_in %03.1f °", t1); }

---

dans resource.h

Code:

---

#define IDC_EDIT_T1 1009

---

dans chaudiere.rc

Code:

---

EDITTEXT IDC_EDIT_T1,60,130,70,14,ES_CENTER | NOT WS_BORDER

---

bref comme dans beaucoup de programmes!

Je regarderais plutôt le code de consommation des évènements qui doit manquer d'un filtre et trigger sur timer d'une autre fenêtre, ou un truc du genre.
Cela dit, utiliser Win32 et copier/coller de la sorte c'est de toutes façons chercher les problèmes imo...

Es-tu sûr que ce n'est pas tout simplement cette liaison rs232 qui n'est pas partageable?

Dans le 2eme programme, je n'utilise pas de liaisons RS232.

Il fais juste des réponses automatiques sur internet avec wpcap (pas avec les socket c++, par habitude car beaucoup d'équipementier en avionique font exprès de faire des erreur dans les checksums, donc trame invisible pour les sockets, de plus pas de table ARP a gérer et en plus tous les droit, un petit bijou )

Merci Bousk pour ta réponse, mais je ne comprends pas bien ce que tu veut dire par 'Je regarderais plutôt le code de consommation des évènements qui doit manquer d'un filtre et trigger sur timer d'une autre fenêtre, ou un truc du genre'

j'ai juste

Code:

---

1 2 3 4

BEGIN_MESSAGE_MAP(CchaudiereDlg, CDialog) //{{AFX_MSG_MAP(CchaudiereDlg) ON_WM_SYSCOMMAND() ON_WM_TIMER()

---

Ça https://en.wikipedia.org/wiki/Messag...rosoft_Windows
https://docs.microsoft.com/en-us/win...ser-getmessage

Je n'utilise pas int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)

Ça accepte d'être utilisé par deux processus à la fois, WinPCap? Parce que ça ressemble au genre de truc à bas niveau qu'on ne peut ouvrir qu'en mode exclusif...

PS: Si tu utilises Microsoft Foundation Classes (MFC), tu utilises WINAPI. Si tu regardes l'article "leaky abstraction" dans un dictionnaire, tu y trouveras une photo du logo MFC.

pour WinPCap Oui, on peut l'utilisé dans une application C++ et utiliser Wireshark en même temp

pour WINAPI je veux dire je n'utilise pas WinMain


J'utilise

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

// chaudiere.cpp : Defines the class behaviors for the application. //   #include "stdafx.h" #include "chaudiere.h" #include "chaudiereDlg.h"   #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif   ///////////////////////////////////////////////////////////////////////////// // CchaudiereApp   BEGIN_MESSAGE_MAP(CchaudiereApp, CWinApp) //{{AFX_MSG_MAP(CchaudiereApp) // NOTE - the ClassWizard will add and remove mapping macros here. // DO NOT EDIT what you see in these blocks of generated code! //}}AFX_MSG ON_COMMAND(ID_HELP, CWinApp::OnHelp) END_MESSAGE_MAP()   ///////////////////////////////////////////////////////////////////////////// // CchaudiereApp construction   CchaudiereApp::CchaudiereApp() { // TODO: add construction code here, // Place all significant initialization in InitInstance }   ///////////////////////////////////////////////////////////////////////////// // The one and only CchaudiereApp object   CchaudiereApp theApp;   ///////////////////////////////////////////////////////////////////////////// // CchaudiereApp initialization   BOOL CchaudiereApp::InitInstance() { AfxEnableControlContainer();   // Standard initialization // If you are not using these features and wish to reduce the size // of your final executable, you should remove from the following // the specific initialization routines you do not need.   #ifdef _AFXDLL Enable3dControls(); // Call this when using MFC in a shared DLL #else Enable3dControlsStatic(); // Call this when linking to MFC statically #endif   CchaudiereDlg dlg; m_pMainWnd = &dlg; int nResponse = dlg.DoModal(); if (nResponse == IDOK) { // TODO: Place code here to handle when the dialog is // dismissed with OK } else if (nResponse == IDCANCEL) { // TODO: Place code here to handle when the dialog is // dismissed with Cancel }   // Since the dialog has been closed, return FALSE so that we exit the // application, rather than start the application's message pump. return FALSE; }

---

et

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

// stdafx.h : include file for standard system include files, // or project specific include files that are used frequently, but // are changed infrequently //   #if !defined(AFX_STDAFX_H__6A232179_3113_470E_85A8_7BAC0D38CDE3__INCLUDED_) #define AFX_STDAFX_H__6A232179_3113_470E_85A8_7BAC0D38CDE3__INCLUDED_   #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000   #define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers   #include <afxwin.h> // MFC core and standard components #include <afxext.h> // MFC extensions #include <afxdisp.h> // MFC Automation classes #include <afxdtctl.h> // MFC support for Internet Explorer 4 Common Controls #ifndef _AFX_NO_AFXCMN_SUPPORT #include <afxcmn.h> // MFC support for Windows Common Controls #endif // _AFX_NO_AFXCMN_SUPPORT     //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line.   #endif // !defined(AFX_STDAFX_H__6A232179_3113_470E_85A8_7BAC0D38CDE3__INCLUDED_)

---

Désolé de venir après la bataille.

Sans votre code ça va être compliqué.

Pour moi, le plus probable, outre l'utilisation d'identifiants identique, c'est une mauvaise gestion des évènements de type WM_PAINT.

Vous pouvez vérifier les messages reçu par les fenêtres avec l'utilitaire "Spy++".