Remonter les appels en mode DEBUG

Version imprimable

18/11/2008, 10h08
Cedric33

Remonter les appels en mode DEBUG

Bonjour,
Lorsque j'arrive au point d'arret en Débug, j'aimerais savoir quelle fonction utiliser pour savoir quelle methode appelle celle dans laquelle je suis, et ainsi de suite....
Si quelqu'un peut m'aider...
Merci bp
Cédric
18/11/2008, 10h36
Vonziz

Tu peux situer un peu plus le contexte de ta question car si on interprète au premier degré ta question, on se dit que pour trouver l'appelant de l'endroit de ton point d'arrêt, il suffit juste de mettre un point d'arrêt en amont de ton code (genre au début de ton programme)...
18/11/2008, 10h40
Vonziz

J'ai peut être une réponse à ton besoin : lorsque tu es en debug, tu as un onglet nommé "Call stack" qui représente l'empilage des données dans ta pile durant l'exécution de ton programme.

Parmi ces données, tu as notamment l'appel aux fonctions qui s'empilent.

Par exemple, si tu es dans une fonction testDeleteBiblio appelée depuis un Main, tu auras la trace de pile suivante :

ConsoleApplication1.exe!ConsoleApplication1.Program.testDeleteBiblio() Line 28 C#
ConsoleApplication1.exe!ConsoleApplication1.Program.Main(string[] args = {Dimensions:[0]}) Line 20 C#

Merci pour ta réponse
C'est à peu pres ca mais il me manque des "appels". En fait, je demande ça car on ne sait pas forcément facilement d'où est appelée une méthode.
J'ai fait le test suivant :
J'ai une Form1 avec un Bouton. Quand je clique dessus ca m'ouvre une Form2. Celle ci contient un bouton qui appelle une méthode Test (de Form2). J'ai mis le point d'arret dans Test et voici ce que m'indique la "pile des appels" :
Code:

1 2 3 4 5 6 WindowsFormsApplication1.exe!WindowsFormsApplication1.Form2.test() Ligne 24 C# WindowsFormsApplication1.exe!WindowsFormsApplication1.Form2.button1_Click(object sender = {Text = "button1"}, System.EventArgs e = {X = 46 Y = 13 Button = Left}) Ligne 21 + 0x7 octets C# [Code externe] WindowsFormsApplication1.exe!WindowsFormsApplication1.Program.Main() Ligne 18 + 0x1a octets C# [Code externe]
Je ne vois pas indiqué que Form2 est appelée par le clique sur le bouton1 de Form1....

Mais dans l'idée c'est bien ça que je veux
Cedric

18/11/2008, 11h41
Vonziz

De quelle manière ouvre-tu ton nouveau formulaire?

Donne le code de ton event! Et je te dirais ton avenir... lol

Cela m'a tout l'air d'un appel javascript, d'où la présence d'un [code externe] non géré par Visual Studio pour le tracage de la pile.

VS doit uniquement gérer les traces de la piles estampillés Composant .NET, un appel javascript ne doit pas en faire partie...

j'ai fait au plus simple :
j'ai créé un nouveau projet, il y a donc Form1 par défaut, sur cette Form1 j'ai ajouté un Bouton1
j'ai donc :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
namespace WindowsFormsApplication1
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
 
        private void button1_Click(object sender, EventArgs e)
        {
            Form2 oForm2 = new Form2();
            oForm2.Show();
        }
    }
}

J'ai ajouté un Formulaire Form2, dans lequel j'ai placé un Bouton1, qui appelle la méthode Test, j'ai donc :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
namespace WindowsFormsApplication1
{
    public partial class Form2 : Form
    {
        public Form2()
        {
            InitializeComponent();
        }
 
        private void button1_Click(object sender, EventArgs e)
        {
            this.test();
        }
        private void test()
        {
        }
    }
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
>	WindowsApplication1.exe!WindowsFormsApplication1.Form2.test() Line 18	C#
 	WindowsApplication1.exe!WindowsFormsApplication1.Form2.button1_Click_1(object sender = {Text = "button1"}, System.EventArgs e = {X = 41 Y = 13 Button = Left}) Line 24 + 0x11 bytes	C#
 	System.Windows.Forms.dll!System.Windows.Forms.Control.OnClick(System.EventArgs e) + 0x76 bytes	
 	System.Windows.Forms.dll!System.Windows.Forms.Button.OnMouseUp(System.Windows.Forms.MouseEventArgs mevent) + 0xe4 bytes	
 	System.Windows.Forms.dll!System.Windows.Forms.Control.WmMouseUp(ref System.Windows.Forms.Message m, System.Windows.Forms.MouseButtons button, int clicks) + 0x409 bytes	
 	System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x71e bytes	
 	System.Windows.Forms.dll!System.Windows.Forms.ButtonBase.WndProc(ref System.Windows.Forms.Message m = {msg=0x202 (WM_LBUTTONUP) hwnd=0x1b0928 wparam=0x0 lparam=0xd0029 result=0x0}) + 0x1fd bytes	
 	System.Windows.Forms.dll!System.Windows.Forms.Button.WndProc(ref System.Windows.Forms.Message m) + 0x6f bytes	
 	System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x129 bytes	
 	System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 514, System.IntPtr wparam, System.IntPtr lparam) + 0x10e bytes	
 	[Native to Managed Transition]	
 	[Managed to Native Transition]	
 	System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(int dwComponentID, int reason, int pvLoopData) + 0x634 bytes	
 	System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason = -1, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.ApplicationContext}) + 0x58e bytes	
 	System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) + 0x6d bytes	
 	WindowsApplication1.exe!WindowsFormsApplication1.Program.Main() Line 17 + 0x2f bytes	C#

C'est assez indigeste, je te l'accorde. lol Mais tu peux voir que la frame2 a été générée à partir d'un évènement OnClick d'une Form. :)

18/11/2008, 12h00
Cedric33
Y'a un truc qui m'échappe quand même, je ne comprends pas pourquoi je n'ai pas un truc du style
Code:

1 2 WindowsApplication1.exe!WindowsFormsApplication1.Form1.button1_Click_1(ob....
18/11/2008, 13h36
Vonziz

Je crois savoir : la gestion évènementielle est une gestion asynchrone contrairement aux appels séquentiels que tu peux faire dans ton programme.

Donc, lorsque tu effectues un button_click, l'affichage de la Form2 s'effectue et l'exécution de l'évènement onClick se termine sans rien "poursuivre" dans le code. Au niveau de la pile, l'appel asynchrone à la fonction onClick est donc terminé, il n'y a donc plus de présence dans la pile de cet appel.

As-tu compris quelque chose?
18/11/2008, 15h30
Cedric33

oui je crois lol
Donc il n'y a pas une fonction qu'on peut appeler en DEBUG pour savoir ce genre de choses?
18/11/2008, 17h39
Vonziz

Une solution plus lourde pourrait consister à écrire dans un fichier plat le nom de la fonction à chaque fois que tu rentres dedans.

Ainsi, tu aurais un historique des appels à tes fonctions et ainsi, tu pourrais retrouver facilement l'ascendant de ton breakpoint.
18/11/2008, 17h59
Cedric33

oula non lol c'est bien trop lourd. Je pensais que c'était possible facilement, mais bon a priori non... En tout cas merci beaucoup pour ton aide
Cédric