Product: PowerShell Studio 2020 (64 Bit)
Build: v5.7.179
OS: Windows 10 Enterprise (64 Bit)
Build: v10.0.19041.0
When debugging a Windows Form application, F11 does not step into a called Windows Form UNLESS there is already a breakpoint set. Code does get executed in the called Form, but the screen does not switch.
Debugger Step Into (F11) not working
Forum rules
DO NOT POST LICENSE NUMBERS, ACTIVATION KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.
Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
DO NOT POST LICENSE NUMBERS, ACTIVATION KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.
Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
- gareth.jacobs
- Posts: 34
- Last visit: Wed Jan 24, 2024 7:43 pm
- Alexander Riedel
- Posts: 8479
- Last visit: Thu Mar 28, 2024 9:29 am
- Been upvoted: 37 times
Re: Debugger Step Into (F11) not working
F11 steps into the function at the current execution context. This implies that F11 is pressed when the application being debugged is already stopped.
From your description I am not sure that this is the case here. Please provide a more detailed description.
"Code does get executed in the called Form, but the screen does not switch." I am not exactly sure what that means when you say the "screen does not switch".
I am assuming and please correct me if I am wrong, that you refer to code in event handlers. Event handlers are executed when an event occurs. To stop there, you will have to set a break point. You cannot "step into" an event handler. A Windows Forms application is event driven and not code executed in a linear fashion as a command line script would be.
From your description I am not sure that this is the case here. Please provide a more detailed description.
"Code does get executed in the called Form, but the screen does not switch." I am not exactly sure what that means when you say the "screen does not switch".
I am assuming and please correct me if I am wrong, that you refer to code in event handlers. Event handlers are executed when an event occurs. To stop there, you will have to set a break point. You cannot "step into" an event handler. A Windows Forms application is event driven and not code executed in a linear fashion as a command line script would be.
Alexander Riedel
SAPIEN Technologies, Inc.
SAPIEN Technologies, Inc.
- gareth.jacobs
- Posts: 34
- Last visit: Wed Jan 24, 2024 7:43 pm
Re: Debugger Step Into (F11) not working
Okay to clarify...
There appears to be a couple of issues. After I exited and restarted PowerShell Studio the debugger behaved itself again. It had been active for several hours so perhaps it was the result of a memory leak or some other bug.
What had happened is that I had set a Breakpoint and the code stopped at that point. I used F10 to step forward a few lines and then F11 to step into a form. At this point code from within the form executed, but the screen stayed on the same form I was in before calling the new form - it did not switch to the form I had entered.
A restart of the PS app fixed the issue.
There appears to be a couple of issues. After I exited and restarted PowerShell Studio the debugger behaved itself again. It had been active for several hours so perhaps it was the result of a memory leak or some other bug.
What had happened is that I had set a Breakpoint and the code stopped at that point. I used F10 to step forward a few lines and then F11 to step into a form. At this point code from within the form executed, but the screen stayed on the same form I was in before calling the new form - it did not switch to the form I had entered.
A restart of the PS app fixed the issue.