Faire déborder la pile en déclarant un message !

**Neilos** · 13/07/2004, 12h40

Salut à tous !

J'ai déclaré un nouveau message que recevra ma fiche MainForm. Donc j'a rajouté cela dans la déclaration de la classe TMainForm :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
protected:
      // Gestion des messages
   void __fastcall AMEditUpdate ( TMessage &message );
 
   BEGIN_MESSAGE_MAP
      MESSAGE_HANDLER( AM_Update_Edit, TMessage, AMEditUpdate);
   END_MESSAGE_MAP (TMainForm)

Le message est défini de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define AM_Update_Edit     WM_APP + 500

Lorsque je lance mon application (dont MainForm est la fiche....principale

) j'ai immédiatement droit (avant même de voir la fenêtre principale apparaître) à un doux message :

Le projet Project.exe a provoqué une classe d'exception EStackOverflow avec le message 'Débordement de pile'L Processus stoppé. Utilisez....bla bla...

Cette erreur ce produit sur le BEGIN_MESSAGE_MAP.

Quelqu'un peut il m'explique ce qui ne va pas dans mon code ?

Merci d'avance pour votre aide !

**Trap D** · 13/07/2004, 13h38

Peut-être faut-il voir ce que tu fais dans "AMEditUpdate", fais-tu un return à la fin du traitement ?

**Neilos** · 13/07/2004, 13h56

Non je ne fais pas de return à la fin du traitement.

J'ai juste un if et 3 changement des valeurs Text et Caption de différents composants.

**Trap D** · 13/07/2004, 14h26

Ce que je voulais dire, c'est que tu as le choix entre un return ou mettre à la place TForm:ispatch(&Msg)
Au fait, comment as-tu déclaré ton nouveau message, sous la forme WM_USER + XXXX ?

**Neilos** · 13/07/2004, 14h33

Je n'avais rien mis de spécial à la fin de la fonction.
J'ai essayé avec return et Dispatch, cela ne change rien.

Comme écrit dans mon premier post j'ai déclaré le message de la façon suivante (comme indiqué dans l'aide de C++ Builder) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define AM_Update_Edit     WM_APP + 500

Le 500 étant tout à fait arbitraire. Je viens d'essayer en remplacant WM_APP par WM_USER. Cela ne change rien au problème

Merci beaucoup de ton aide ![/code]

**Nicolas** · 13/07/2004, 14h33

Bonjour,

Envoyé par Neilos

Non je ne fais pas de return à la fin du traitement.

J'ai juste un if et 3 changement des valeurs Text et Caption de différents composants.

Je pense que cela peut venir de ces changements de valeur. Il se peut que le message arrive AVANT que l'instance de la fiche ne soit finie d'être créée. On accède alors à des composants qui 'n'existe pas'.
Cela m'est déjà arrivé ; pour contourner le problème, j'utilise un booléen m'indiquant que la fiche est finie d'être créée. Je passe ce booléen à 'true' dans une méthode que j'appelle entre le " Application->CreateForm(__classid(TFMainProd), &FMainProd);
" et le "Application->Run();" du main.

En espérant que cela réponde à ton problème...
Nicolas

**Neilos** · 13/07/2004, 14h36

Salut,

c'est une bonne idée. Mais ce message n'est envoyé que par une autre fiche de mon application. Elle même appelée via un bouton de ma fiche principale et elle n'est pas crée avant. Donc cela ne peut être le problème !

Merci quand même !

**10_GOTO_10** · 13/07/2004, 15h03

C'est plus simple que ça: le changement de titre des composants doit générer des messages Windows (des SETTEXT, par exemple) qui sont interceptés par le MESSAGEMAP, ce qui entraîne un nouvel appel de AMEditUpdate, etc... Jusqu'à ce que la pile soit pleine.

**Neilos** · 13/07/2004, 16h57

Non le changement des propriétés n'appel pas mon message. C'est lorsque ce message reçu par la fiche que les propriétés sont modifiée.

Etant un message défini par moi même il n'est appelé que par des fonctions que j'ai écrit...or pour l'instant je n'ai fait que définir ce message. Pour l'instant aucune ligne de code n'envoie ce message à ma fenêtre principale...d'où mon problème !

**Neilos** · 16/07/2004, 11h40

Personne n'a la moindre idée ?
Cela me bloque tout mon projet et je ne vois vraiment pas quoi faire....

**Trap D** · 16/07/2004, 13h06

As-tu essayé de pister les messages avec SPY ?
Au debuggueur ,ça donne quoi ?

**Neilos** · 16/07/2004, 13h14

Euh je ne connais pas SPY ! Je vais voir si je le trouve...

Au débugueur en execution pas à pas depuis le début, lorsque j'arrive sur les lignes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
BEGIN_MESSAGE_MAP         // 1
      MESSAGE_HANDLER( AM_Update_Edit, TMessage, AMUpdateEdit)
END_MESSAGE_MAP (TMainForm)  // 2

J'arrive sur la 1 -> F7
J'arrive sur la 2 -> F7
je retourne sur la 1...indéfiniment (bon j'ai pas essayé jusqu'au bout

mais ça boucle).

**Bayard** · 16/07/2004, 13h21

Est-ce que CodeGuard est "coché" ?

**Neilos** · 16/07/2004, 13h53

Non je ne maitrise pas du tout CodeGuard et je ne sais même pas trop ce que c'est.

J'ai coché CodeGuard voici les différents messages qu'il me sort plusieurs messages, voici le premier :

Attempt to access 4 byte(s) at 0x004297B8. The 'this' pointer points to block 0x004297B8(=monexe.exe:0x02:0027B8) which is only 1 bytes long

**Bayard** · 16/07/2004, 13h59

Bon, ben voila.

Il faut regarder la ligne de code qui "casse du code". Peut-être est-ce un tableau sous-dimensionné ?

Quelle est cette ligne ?

Il est également possible de regarder la pile d'appels (Voir -> Fenêtre de debugage).

**Neilos** · 16/07/2004, 14h08

Là j'avoue je ne comprend plus...
Je lance mon programme en mode pas à pas pour savoir qu'elle ligne fait planter (car en double cliquant sur la ligne dans CodeGuard je tombe sur une ligne de l'unité dstring.h).

Et en fait c'est directement sur la ligne d'entrée dans le programme (WinMain....) que les erreurs arrivent

La ligne en question dans dstring.h est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

__fastcall AnsiString(): Data(0) {}

J'avoue être vraiment perdu là !

**Neilos** · 16/07/2004, 14h22

Bon apparement après avoir désactiver CodeGuard et effecuter une petite modification dans le code je n'ai plus ce problème de débordement de pile !

Voici l'original qui plante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
   BEGIN_MESSAGE_MAP
      MESSAGE_HANDLER( AM_Update_Edit, TMessage, AMUpdateEdit)
   END_MESSAGE_MAP (TMainForm)

et le nouveau qui ne plante à priori pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
   BEGIN_MESSAGE_MAP
      MESSAGE_HANDLER( AM_Update_Edit, TMessage, AMUpdateEdit)
   END_MESSAGE_MAP (TControl)

Sachant que cela est déclaré dans protected de mon TMainForm.

J'ai modifié ça comme ça sans vraiment réfléchir et je ne vois pas trop ce que ca change...à part que TMainForm est un descendant de TControl...

Une explication ?

Merci beaucoup à tous ceux qui m'on aidé à avancer!!!!!!!!!!

**Bayard** · 16/07/2004, 16h02

Pas d'explication avec le faible niveau d'information.

J'ai déjà eu ce type de souci. Et je n'ai trouvé que le langage python (comme le C++, mais interprété) pour ne jamais avoir de problème enigmatique. Quand il y a un souci, il s'arrête (proprement) et indique la ligne qui pose problême. Avec le C++ (et d'autres langage) on peut "casser de code" et continuer à dérouler le programme bien trop loin.