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

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:

---

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:

---

#define AM_Update_Edit WM_APP + 500

---

Lorsque je lance mon application (dont MainForm est la fiche....principale :lol:) j'ai immédiatement droit (avant même de voir la fenêtre principale apparaître) à un doux message :

Citation:

---

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 !

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

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.

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

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:

---

#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 :cry:

Merci beaucoup de ton aide ![/code]

Bonjour,

Citation:

---

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

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 !

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.

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 !

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

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

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:

---

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 :lol: mais ça boucle).

Est-ce que CodeGuard est "coché" ?

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 :

Citation:

---

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

---

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).

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:

---

__fastcall AnsiString(): Data(0) {}

---

J'avoue être vraiment perdu là !

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:

---

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:

---

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!!!!!!!!!!

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.

Salut !

Citation:

---

END_MESSAGE_MAP (TControl)

---

Il me semble qu'il vaut mieux indiquer la classe dont dérive TMainForm

Code:

---

END_MESSAGE_MAP (TForm) ?

---

Code:

---

END_MESSAGE_MAP (TCustomForm) ?

---

A plus !

Salut,

j'ai finallement mis

Code:

---

END_MESSAGE_MAP (TForm)

---

Merci pour l'info !