Please, Create the Directive #DebugStepByStep Step End All

Propose new features and changes
User avatar
caribeiro
Posts: 13
Joined: 22 May 2019, 11:00
Contact:

Please, Create the Directive #DebugStepByStep Step End All

Post by caribeiro » 05 Oct 2022, 12:30

Hi AutoHotKey developers.

I ask you the favor to create the positional #DebugStepByStep Step End All directive, being Step , End and All global hotkeys that we choose and set when we include this directive at the script.

This directive would have the following effects and characteristics :

When any macro between :
> the line with #DebugStepByStep Step End All and
> the line with #DebugStepByStep End
is triggered, the following would happen :

=> The AutoHotKey Script Utility automatically opens top screen (being movable by dragging), and displays the code of the whole running macro, with its 1st line highlighted and no line executed yet. This does not make the AutoHotKey Script Utility the active window. (Moving it may activate it, but to click the window that were active when the macro was triggered returns the focus to it.)
=> EACH TIME the user types the Step global hotkey, only the currently highlighted line of the running-but-paused macro executes, the macros pauses again and its next line is highlighted at the AutoHotKey Script Utility. Again, this does not make the AutoHotKey Script Utility the active window, the active window remains the one that was active when the macro was triggered.
=> IF the user types the End global hotkey, the macro execution ends without running its remaining lines.
=> IF the user types the All global hotkey, all the remaining lines of the macro run (from the line that was highlighted to the last one) and the macro execution ends.
=> When the macro ends, the AutoHotKey Script Utility returns to the state it was before the macro triggering. (That previous state may be closed or showing another of its data pages.)

I see this new directive significantly improving AutoHotKey, allowing the line-by-line debugging of macros that act in OTHER SOFTWARES, what is very common with AutoHotKey and probably is also its main distinctive characteristic.

Note that Scite4AutoHotKey line-by-line debugging feature does not allow this, because, to execute each macro's line (F10), we must have Scite as the active software and, so, the next line of the macro acts on Scite itself, it does not act on ANOTHER SOFTWARE where it is intended to.

I believe you will see the great utility of this new directive and will be able to code it.

Thank you very much.
Marcos Cançado Ribeiro

PS 1 : Maybe, the scope of the 3 HotKeys in the 3 parameters of this new directive, Step , End and All, could be, instead of Global HotKeys :
• "Procedural or Directive" HotKeys (that is, detected only by this directive itself, while a macro inside it is running, or by the running macro) or
• AutoHotKey HotKeys (that is, detected only by AutoHotKey itself) or
• Software HotKeys (that is, detected only by the software that was active when the macros inside this directive was triggered).
Of course, the more restrict their detection scope the better, because this expands the options of hotkey that can be assigned to Step , End and All. I only propose, initially, the Global scope because these hotkeys must be detected with the active window remaining the same one that was active when a macro inside the directive was triggered.

PS 2 : In practice, this directive will be included on the code :
> only temporarily, only while debugging, being deleted when the macro is working as desired AND
> each time, for only 1 (one) macro.
This means that, instead of having 2 lines :
> the line with #DebugStepByStep Step End All and
> the line with #DebugStepByStep Off
it could also :
> be a directive with only 1 line, but acting only on 1 macro, the 1st macro after it or
> be a command to be placed as the 1st one of the macro.
But it seems to me that it would be better to have it as a directive before and outside the target macro, what would make it more visible and probably easier to create.

User avatar
caribeiro
Posts: 13
Joined: 22 May 2019, 11:00
Contact:

Re: Please, Create the Directive #DebugStepByStep Step End All

Post by caribeiro » 18 Oct 2022, 19:14

PS 3: The window that presents the whole macro and highlights the next line to be executed after the typing of the Step hotkey does not need to be at the AutoHotKey Script Utility, it may be a simple dialog with a multi-line editbox, independent of the AutoHotKey Script Utility, created specifically for the execution of this debugging directive.

Now, this solution appears to me better and easier to code than to use the AutoHotKey Script Utility for this directive.

That's it.

I hope some of the many that have read this request (94 for now) are trying to implement this important debugging feature for AutoHotKey. :thumbup:

lexikos
Posts: 9569
Joined: 30 Sep 2013, 04:07
Contact:

Re: Please, Create the Directive #DebugStepByStep Step End All

Post by lexikos » 18 Oct 2022, 23:27

I hardly understand what you're asking for, or how or why we would use a directive for this. As far as I can tell, your only reason for it at all is that SciTE4AutoHotkey activates its own window when it reaches a breakpoint. That is just a minor behaviour of the client, which is an AutoHotkey script and part of SciTE4AutoHotkey, not AutoHotkey. It would be trivial to remove the WinActivate call.

You are free to implement your own debugger client using DBGp with whatever user interface or hotkeys you want. There are example implementations at https://github.com/Lexikos/dbgp, in addition to SciTE4AutoHotkey, AHK Studio and Adventure IDE.

User avatar
caribeiro
Posts: 13
Joined: 22 May 2019, 11:00
Contact:

Re: Please, Create the Directive #DebugStepByStep Step End All

Post by caribeiro » 20 Oct 2022, 17:32

Thanks for the answer, lexikos.

The debugging feature I am requesting enables AHK to offer for its >>macros that act on others programs<< what MS VisualBasic Editor offers for its macros that act on the MS-Office programs: Word, Excel, etc. With this VisualBasic debugging feature, we can execute step-by-step each line of the macro in the VisualBasic Editor and see its results on Word, Excel, etc, not on the VisualBasic Editor itself, despite the fact that it is a resource of the VisualBasic Editor, not of Word, Excel, etc. SciTE4AutoHotkey does not offer this ability to :
a) control the step-by-step execution of a macro that acts on another program, like Word, GoogleChrome, CorelDraw, etc, and
b) see its effect on that other program.

I will try to be clear with an example. Suppose I am creating an AHK macro to work with GoogleChrome, say to alternate JavaScript between disabled <=> enabled, and that this macro has the following 3 lines that open some dialogs and select some options, but that it is not working as I want.

This example sets, for the parameters of the directive I am requesting:
> for Step: Numpad1
> for End: Numpad2
> for All: Numpad3.

Code: Select all

#IfWinActive, ahk_exe chrome.exe
#DebugStepByStep Numpad1 Numpad2 Numpad3

  Numpad4:: 
  Line1
  Line2
  Line3
  Return

#DebugStepByStep
#IfWinActive
As usual, this macro only triggers with GoogleChrome active. The debugging directive #DebugStepByStep Numpad1 Numpad2 Numpad3 would :
> Execute Line1 and stop temporarily
> Allow me to see the effect of Line1 >on GoogleChrome<, like the opening of its dialog
> Simultaneously, allow me see the AHK line just executed highlighted in another window, presented by the directive itself and
> Be able to use the following 3 hotkeys to :
a) Numpad1 to execute the next line of the macro and see the same above >>>on GoogleChrome<<< (not on SciTE4AutoHotkey or on another Code Editor or an autonomous program created by the macro itself) or
b) Numpad2 to cancel the macro execution or
c) Numpad3 to execute the rest of the macro until its end, no more stopping at each line.

The point is to allow simultaneously:
> The macro acting over the target program (GoogleChrome in this example) and the visualization of its effect in this program
> The typing of Numpad1, Numpad2 and Numpad3 NOT been sent to the target program (GoogleChrome), that is, the AHK directive sequestrates them before and
> The presentation of a window that highlights the next line to be executed (or just executed) without receiving the next command of the macro, if Numpad1 is typed.
> The next line of the macro continuing to act over the target program (GoogleChrome in this example), as intended.

Is it clear now ? Let me know if any doubt remains.

PS4: Something about me: I am an intesive computer user, but I am not a programmer. I make a lot of AHK macros, but all of them are in only 2 AHK files, that are always running in my computers. One of them has a lot of macros for many other programs, in exactly (for now) 11398 lines of code and comments. The other has a lot of hotstrings, and I disclosed in this forum the simple way I found to troubleshoot an AHK bug with hotstrings for words with accent marks and+or cedillas.

lexikos
Posts: 9569
Joined: 30 Sep 2013, 04:07
Contact:

Re: Please, Create the Directive #DebugStepByStep Step End All

Post by lexikos » 21 Oct 2022, 04:18

I just don't understand why you would come up with this specific way to set hotkeys for debugging and describe it in such a long-winded way.

The reason SciTE4AutoHotkey can't already be used for this, is very simple; as you said, the window must be active.

This can be broken into two parts, still very simple:
  1. S4A activates its own window when script execution is halted.
  2. S4A's hotkeys only work when the editor window is active (usually this is a good thing, in my opinion).
There are obvious solutions for both parts:
  1. Change S4A to not activate the window - just remove some WinActivate calls.
  2. Set global hotkeys.
I use the following hotkeys, although I'd forgotten they work when SciTE isn't active, because I've never needed that.

Code: Select all

#IfWinExist [Debugging] ahk_class SciTEWindow
F5::    SendMessage 0x111, 1127 ; run (debugging)
F10::   SendMessage 0x111, 1130 ; step over
F11::   SendMessage 0x111, 1129 ; step into
+F11::  SendMessage 0x111, 1131 ; step out
Stopping SciTE from activating its window is just a case of disabling two WinActivate calls in SciTEDebug.ahk which currently look like this:

Code: Select all

	IfWinNotActive, ahk_id %scitehwnd%
		WinActivate

Code: Select all

	IfWinNotActive, ahk_id %scitehwnd%
		WinActivate, ahk_id %scitehwnd%
Then you can just put SciTE to the side and use the hotkeys to step through.


The comparison to VBA macros is misguided; Office macros do not rely on the keyboard focus to perform their function. The same macros can be implemented in AutoHotkey, and will work with SciTE4AutoHotkey's debugger just fine. If you call Application.SendKeys or SetForegroundWindowEx from VBA, it will have the same problems as Send and WinActivate in AutoHotkey (with S4A). There are other automation methods available to AutoHotkey scripts that do not rely on keyboard focus.

User avatar
caribeiro
Posts: 13
Joined: 22 May 2019, 11:00
Contact:

Re: Please, Create the Directive #DebugStepByStep Step End All

Post by caribeiro » 21 Oct 2022, 12:42

Thanks again for the answer, lexikos.

This time I understood what you mean by 'Change S4A to not activate the window - just remove some WinActivate calls'.

When you said how to do it, it became both clearer and possible.

I will try your solution an inform you the results I got. :thumbup:

User avatar
caribeiro
Posts: 13
Joined: 22 May 2019, 11:00
Contact:

Re: Please, Create the Directive #DebugStepByStep Step End All

Post by caribeiro » 21 Nov 2022, 03:45

Hi Lexicos and AutoHotKey Community,

I have experimented with the solution that lexikos proposed and discovered that it works, since under the following 2 conditions :
• the macros that creates the global hotkeys must be in one running script and
• the macro to be debugged must be in another script and as an Auto-Exec section of the script, that must have only it, that is, the script must not have any trigger on it, neither a hotkey nor a hotstring.

Lexicos:
• Can you please tell me the numbers of the SendMessage parameters for the following Scite command and tool :
• Tools menu > Debug (F7) and
• Stop script (the tool that, at the Debug Mode, takes the place of the Debug script tool, without a command menu for it).
• How do you discover the numbers of the parameters of the SendMessage command ? (It got frustrated trying to find them using Spy++ and WinSpector.) This command would be very useful if there were an easy way to find their parameters' numbers.
Thank you.

PS 1 : The reason for the 2 conditions I pointed at the beginning :
To activate the Debut Mode in Scite :
> compiles the whole script and
> IF the script does not have any trigger, the commands at the auto-exec section only are executed by using the debugging tools or by typing F10, F11 or Shift+F11, as intended, but
> IF there is any trigger after the auto-exec section, the auto-exec section is already entirely executed, in fact making the Debug Mode useless. (What I consider an inoffensive bug of the Scite's Debugging Mode — inoffensive because it is easily troubleshot.)

PS 2 : Follows a simple macro that makes handy to experiment with AutoHotKey step-by-step debug, since it does not change anything in the active window :

Code: Select all

InputBox, VarForUserInput , Command 1, Command 1, , , , , , , 1, Command 1
InputBox, VarForUserInput , Command 2, Command 2, , , , , , , 1, Command 2
InputBox, VarForUserInput , Command 3, Command 3, , , , , , , 1, Command 3
InputBox, VarForUserInput , Command 4, Command 4, , , , , , , 1, Command 4
; Send Some Text {Enter}

lexikos
Posts: 9569
Joined: 30 Sep 2013, 04:07
Contact:

Re: Please, Create the Directive #DebugStepByStep Step End All

Post by lexikos » 21 Nov 2022, 05:37

0x111 is WM_COMMAND. You can look it up in various places.

In general, the first parameter of WM_COMMAND is the ID of a control or menu item. You can catch it with Spy++ or similar (it is easier if you exclude all messages other than WM_COMMAND), or sometimes find it in the program's documentation or source code.

If you open ahk.commands.properties (which can be found in the Options menu), you will find the command definitions.

Commands with a number are assigned in ID which is just 1100 + number.
The command number can be in the range of 0 to 49. ... Internally these commands use IDs starting from 1100 (IDM_TOOLS)
Source: SciTE
The "build" (debug) command is 302.

There is a list of SciTE menu commands, but S4A displays "Build" as "Debug". The IDM_* values can be found in the source code or by evaluating them with Lua in SciTE.

Something useful I have recently added to my SciTEUser.properties is:

Code: Select all

command.go.$(file.patterns.lua)=dofile $(FilePath)
command.go.subsystem.$(file.patterns.lua)=3
I then write Lua code into a file (test.lua or whatever) and press F5 to run it. print(IDM_BUILD) would send 302 to the output pane.

To activate the Debut Mode in Scite :
> compiles the whole script
No, it doesn't, but you're probably just using the wrong terminology.
> IF the script does not have any trigger, the commands at the auto-exec section only are executed by using the debugging tools or by typing F10, F11 or Shift+F11, as intended, but
> IF there is any trigger after the auto-exec section, the auto-exec section is already entirely executed, in fact making the Debug Mode useless.
What are you talking about?

When you start debugging with S4A, it does not automatically execute the script, regardless of what the script contains.

I have assigned F10 to the step_over debugger command. When you execute this command, the debugger resumes execution of the script and does not break until a line is executed and the stack depth is equal to what it was before you executed step_over. If you use step_over immediately after starting the debugger, the stack depth is 0, so the debugger will just resume execution of the script, and will generally only halt if it hits a breakpoint or you press the break button (pause icon) on the toolbar.

I have assigned Shift+F11 to step_out, which resumes execution and does not break until the stack depth is less than before. If the stack was empty, like step_over, it just does not break.

I have assigned F11 to step_into. It will always break execution at the next executable line of the script. If you use it immediately after starting the debugger, this is the first executable line of the script (which is sometimes a static initializer in v1).

Obviously, F5 will just run the script.

User avatar
caribeiro
Posts: 13
Joined: 22 May 2019, 11:00
Contact:

Re: Please, Create the Directive #DebugStepByStep Step End All

Post by caribeiro » 22 Nov 2022, 00:55

Hi, Lexicos.

Thanks for your attentive answer.

Thanks also for the number 302 of the SendMessage parameter for the Tools menu > Debug (F7) command. It worked!

If possible, also give me the number of the parameter for the Stop script tool. I read carefully your instructions on how to get these numbers, but I really consider they require a knowledge level higher than I have. Would you be able to get this number by using the interesting addition you did in your SciTEUser.properties file?

About my statement that "To activate the Debut Mode in Scite compiles the whole script", I really used the wrong terminology and probably the correct is to say that "To activate the Debut Mode in Scite interprets the whole script". Is it right now?

About your "What are you talking about?" question, what I said, with 2 short examples, is that the Scite's debug feature:
a) Works fine in a script without any trigger, hotkey or hotstring (like the commands in the Auto-Execute section of the AutoHotKey scripts), as a script with only the following :

Code: Select all

Send Paragraph 1 {Enter}  
Send Paragraph 2 {Enter}  
Send Paragraph 3 {Enter}
b) But does not work in a script with any trigger (hotkey or hotstring), as a script with the following :

Code: Select all

Send Paragraph 1 {Enter}  
Send Paragraph 2 {Enter}  
Send Paragraph 3 {Enter}  
F11::   SendMessage 0x111, 1129  ; <== The presence of this line breaks the Scite's debug mode, because it is a macro, with the F11 trigger, different from the commands at an Auto-Execute section. This is the reason why the macro to be debugged must be in a script different from the script where the global hotkeys are defined.
The 2 above examples are very easy to test and I am pretty sure you will get the same I got.

The above has no relation with the effects of each debug tool, that you presented after your question. But, since you treated these effects, I will also add my observations about them, from my user perspective, as follows :
> Step_into (or step-by-step) : Nothing to add. It is the core of this debugging feature.
> Step_out (or jump-to-break-or-end) : At the Debug Mode, the run tool (F5) has this same effect, it and the step_out tool (Shift+F11) work exactly equal. I see this as a nice curiosity, with no problem.
> Step_over (a mix of the previous 2) : I see no utility for this tool. Immediately after starting the debugger, it works like step_out. After that, it works like step_into. So, it isn't needed and the use of only step_into and step_out is much more intuitive and easy. So, in the script where I defined my global hotkeys, I did not included a hotkey for this tool, that I consider useless and confusing.
> Stop_script : This is an important tool in this debugging feature, because the utility of this feature is, by going step-by-step, to help to find where the error is, and, once the error is found, we usually want to stop the macro, without running until its end. So, I think this tool was somewhat overlooked by the Scite programmers and deserved a little more care in giving more access to it.

I hope I was clear and not too much wordy. :thumbup:

lexikos
Posts: 9569
Joined: 30 Sep 2013, 04:07
Contact:

Re: Please, Create the Directive #DebugStepByStep Step End All

Post by lexikos » 22 Nov 2022, 02:21

I really consider they require a knowledge level higher than I have.
I don't think so. As I said, it is in the ahk.commands.properties file. There is a numbered command (starts with the word "command" followed by a number) which is clearly labeled as "Stop". The ID for the message is, as I said, 1100 plus the number of the command. 1128.
"To activate the Debut Mode in Scite interprets the whole script". Is it right now?
I think you are probably under a misconception, or I just don't get the point of your statement. SciTE does not interpret the script. The debug mode in SciTE runs AutoHotkey. AutoHotkey interprets the script as per usual, but then connects back to the debugger for commands.
b) But does not work in a script with any trigger (hotkey or hotstring), as a script with the following :
I was not aware that you even attempted to put the debugging hotkeys into the script you are debugging. I would not recommend it.
The presence of this line breaks the Scite's debug mode
I see no reason for that to be the case. However, the hotkey can't work if the script is in a break state in the debugger, because a script in the break state cannot execute.
I see no utility for [step_over]
It is obviously not intended to be used immediately after starting the debugger. The purpose is to step to the next line when the current line contains function calls, instead of stepping into the called function.

User avatar
caribeiro
Posts: 13
Joined: 22 May 2019, 11:00
Contact:

Re: Please, Create the Directive #DebugStepByStep Step End All

Post by caribeiro » 24 May 2023, 05:44

Lexicos,

I owe you a big thanks for your kind answers in this post that resolved 100% the problem that I raised with an initial ask for a new resource.

I delayed this thanking because I intended to add a few phrases in it to increase the chances of Google searches for an AutoHotKey step-by-step debugging solution to present this post. Phrases like the following:
> AutoHotKey: Solution for How to Debug Step-by-Step
> AutoHotKey: Solution for How to Execute Only 1 (One) Instruction and Pause Until a Keypress.
Well, I just did it. I hope this will help some people to find this solution.

The writing of this text did not take me too much time and I should have done it earlier, but I had too many thinks in my to do list and some went before this one. Anyway, as I we say here in Brazil, "better late than never". :)

Thanks again, Lexicos.

Marcos Cançado Ribeiro

Post Reply

Return to “Wish List”