Is the debugger difficult to use?

[JRL]

Usually, when I use Onevent>KEY_DOWN with or without a modifier key (shift, alt, ctrl) all works well. But when I tried to setup two onevents for the same key one with a modifier and one without. I only got results from the one without the modifier key even when I used the modifier key.

This example will only display the "=" character even if the shift key is held down.

Code: Select all

//VK187+shift=+(plus)
OnEvent>KEY_DOWN,VK187,1,KeyPressed187s
//VK187==(equal)
OnEvent>KEY_DOWN,VK187,0,KeyPressed187

SRT>KeyPressed187s
	MDL>+
END>KeyPressed187s

SRT>KeyPressed187
	MDL>=
END>KeyPressed187

Label>loop
wait>0.01
goto>loop

After a fair amount of aggravation, I discovered that the order of the onevents in the script matters. The following example is the same as the previous example except that the onevent statements are in reverse order. This example will display the "=" and the "+" properly.

Code: Select all

//VK187==(equal)
OnEvent>KEY_DOWN,VK187,0,KeyPressed187
//VK187+shift=+(plus)
OnEvent>KEY_DOWN,VK187,1,KeyPressed187s

SRT>KeyPressed187s
	MDL>+
END>KeyPressed187s

SRT>KeyPressed187
	MDL>=
END>KeyPressed187

Label>loop
wait>0.01
goto>loop

Hopefully this will save someone else some time.
Later,
Dick

Original topic:OnEvent KEY_DOWN with and without modifier issue. Has been addressed and rectified. The post has changed direction so I've changed the topic to: Is the debugger difficult to use?

[jpuziano]

Thanks JRL,

Maybe a note should be added to the Help File for the "OnEvent>" topic and perhaps even your example or a similar example could be included... Marcus?

Running v10 beta on XP SP2... here's something interesting:

• - open Advanced Editor
  - paste in 2nd example code above
  - position cursor at the beginning of the 1st line (a comment)
  - run "from within" the Advanced Editor by clicking the "Run" toolbar button
  - press = and SHIFT-= (+) a few times, script works fine
  - click "Stop Debug" toolbar button to stop script
  - notice your = and + key presses are now part of the first line

When running from within the Advanced Editor, I guess you are essentially running in "Debug mode".

I also understand that this is how OnEvent> works, it does not intercept the keystroke, it merely fires if it notices it go by... so the actual keystrokes were passed on to the active window which is still... the Advanced Editor.

What seems odd to me is, while I am running this script in the Advanced Editor, I can actually modify the lines of code while it is running. I even deleted them all with the Delete key and still the macro did not stop so... obviously, the macro must be running from what's in memory not what's on the screen. As soon as I clicked the "Stop Debug" toolbar button to stop the script, all the lines of code I had deleted from the screen... popped back into view.

I am wondering why it works this way. If I am running (perhaps debugging) a script from the Advanced Editor, why not "lock out" any changes to the lines of code on the screen? Any such changes are going to be lost anyway when you click "Stop Debug" so why even allow them?

Or, are there reasons it works this way? Marcus, can you fill us in here?

P.S. I am really enjoying the Word Wrap feature in v10, thanks again for that.

edit: 28-Nov-2007 12:25 AM
I just repeated the above test using version 9.2.01... with slightly different results. In 9.2.01, you can also delete the lines of the macro while you are running(testing/debugging) it in the Advanced Editor only when you click the "Stop Debug" toolbar button to stop the macro, the deleted lines of code don't pop back, they are gone.

Marcus, rather than locking the lines, was the new behavior (original lines pop back when you hit "Stop Debug") introduced in v10 to protect lines of code that might have been inadvertently altered or deleted during a debug test run? Sorry to bug you, just curious as other users of the debugger may be...

[Marcus Tettmar]

Every IDE I have ever used lets you modify code during debug. You may want to do that as you are debugging and as you notice things that need changing. The changes won't take effect until the next run. I can modify the code for Macro Scheduler while I debug it.

If you send keystrokes you've got to expect them to land on the active window. If the active window is the editor, or Macro Scheduler's main window ... well the keystrokes will land there. You can use "refocus windows" and focus a different window if you don't want keystrokes to land in the editor.

Regarding your edit - there has been no change to "protect lines of code" in v10. There is absolutely no difference between v9 and v10 in this regard. I can also delete/change lines in v10 during debug. All changes are listed in the release notes: http://www.mjtnet.com/beta10notes.htm

Re the original topic: Looks like the issue is that ZERO for the modifier key is actually being interpreted as IGNORE - i.e. NONE or ANY. As the script scans through all event handlers one by one, both are evaluating true. I think the correct fix is to make ZERO for the modifier parm act as explicitly described in the help file (only act when NO modifier key is pressed).

[JRL]

From this post

Beta 10 Build 002 is now available from registered downloads.

Fixes/Changes since 001:
- Added more hotkey options to macro properties.
- Debugger will auto-scroll when stepping to keep debug line roughly central in editor
- Fixed: 0 for modifier key in KEY_DOWN event was treated as NONE or ANY, not just NONE

Thank you. I've tested and this issue appears to be fixed for version 10 beta. The workaround will continue to be valid for versions 8 and 9.

[jpuziano]

Every IDE I have ever used lets you modify code during debug. You may want to do that as you are debugging and as you notice things that need changing. The changes won't take effect until the next run. I can modify the code for Macro Scheduler while I debug it.

If you send keystrokes you've got to expect them to land on the active window. If the active window is the editor, or Macro Scheduler's main window ... well the keystrokes will land there. You can use "refocus windows" and focus a different window if you don't want keystrokes to land in the editor.

Thanks for the reply above. Up to now, when debugging, if I wanted to make a change to the code, I would always Stop/Make Changes/Run. You are saying I could also Make Changes/Stop/Run. Good to know, thanks.

Also, I almost always use Step mode because I like to see the variables in the Watch List change and in Run mode, the Watch List variables are not updated, ahh well.

Regarding your edit - there has been no change to "protect lines of code" in v10. There is absolutely no difference between v9 and v10 in this regard. I can also delete/change lines in v10 during debug. All changes are listed in the release notes: http://www.mjtnet.com/beta10notes.htm

Like I said above, when running JRL's second macro example above in the Debugger (Run Mode), I deleted the lines of code with the Delete key... and when I clicked the "Stop Debug" button, they popped back onto the screen. This is what started me asking questions. Version 9 does not do this, once deleted, they're gone. I'll test this again on the work PC tomorrow. This was on XP SP2. If anyone else sees the same behavior please let us know.

Re the original topic: Looks like the issue is that ZERO for the modifier key is actually being interpreted as IGNORE - i.e. NONE or ANY. As the script scans through all event handlers one by one, both are evaluating true. I think the correct fix is to make ZERO for the modifier parm act as explicitly described in the help file (only act when NO modifier key is pressed).

Thanks for fixing this Marcus and good catch JRL.

[Marcus Tettmar]

To see variables when running, set a breakpoint. It could just be the last line, or before the last line. Hit run and it will stop at the last line and you will see the variables in the watch list.

In v10 if you set a breakpoint you can now run to the next breakpoint or end. You can also start off stepping and then run from wherever you are.

[jpuziano]

To see variables when running, set a breakpoint. It could just be the last line, or before the last line. Hit run and it will stop at the last line and you will see the variables in the watch list.

In v10 if you set a breakpoint you can now run to the next breakpoint or end. You can also start off stepping and then run from wherever you are.

Hi Marcus,

I read the "Using the Debugger" topic in the Help File but I didn't see anything about having to set a breakpoint to see the variables in the watch list if using "Run". I just assumed you could only see them if "Stepping" through one line at a time. Thanks for these pointers.

If you're looking for another topic for your Blog or even better, the video demos you sometimes make, then I think "Using the Debugger" would make a great topic. Besides helping the users, it might even cut down on support questions eventually as users would more easily find their own problems if they knew their way around the Debugger.

No rush of course, you seem pretty busy right now with all the v10 stuff, just a suggestion for later if you think its warranted.

[Marcus Tettmar]

I read the "Using the Debugger" topic in the Help File but I didn't see anything about having to set a breakpoint to see the variables in the watch list if using "Run". I just assumed you could only see them if "Stepping" through one line at a time. Thanks for these pointers.

Erm, yes, you only see the variables when you step. If you set a breakpoint and run to it, you are then left in step mode. Run to breakpoint, it then sits there waiting for you to continue stepping, or stop. So it's in step mode. Run to breakpoint runs to breakpoint and puts it in step mode. Not sure what else it would do, so to me this is self explanatory. If you run without a breakpoint or without stepping then you run to the end and the variables are no longer. Run to breakpoint means it runs to that point, stops and then waits for you to step. It puts it in debug mode, step mode. So the watch list will show the variables.

If you're looking for another topic for your Blog or even better, the video demos you sometimes make, then I think "Using the Debugger" would make a great topic. Besides helping the users, it might even cut down on support questions eventually as users would more easily find their own problems if they knew their way around the Debugger.

Well, granted there's no video to go with it, but this article has been there since May 2006:
http://www.mjtnet.com/blog/2006/05/17/use-the-debugger/

As for support requests, that is precisely the reason the above page is linked to right above the main support contact form:
http://www.mjtnet.com/contact.htm

Where it says: "Finally, if you're emailing for help with a script problem, have you debugged it yet?"

I've also linked to that article here in the forums when I've suggested someone use the debugger.

The debugger is frighteningly easy to use. Press F8 and see what happens and it should all become clear. Set a breakpoint and see what happens. There's not much more to it. Does that really warrant a video?

[jpuziano]

I read the "Using the Debugger" topic in the Help File but I didn't see anything about having to set a breakpoint to see the variables in the watch list if using "Run". I just assumed you could only see them if "Stepping" through one line at a time. Thanks for these pointers.

Erm, yes, you only see the variables when you step. If you set a breakpoint and run to it, you are then left in step mode. Run to breakpoint, it then sits there waiting for you to continue stepping, or stop. So it's in step mode. Run to breakpoint runs to breakpoint and puts it in step mode. Not sure what else it would do, so to me this is self explanatory. If you run without a breakpoint or without stepping then you run to the end and the variables are no longer.

Except for scripts that don't naturally "run to the end" like JRL's example scripts from earlier in this post which will run forever waiting for the user to hit a key. Step mode isn't suited to debug OnEvent> commands (event handlers) because in step mode, the macro only runs for a brief instant right after you press F8 (or click "Debug Step F8" toolbar button). You can't really press + or = fast enough to see how the event handlers might respond so... the only way to use the debugger to test this script was to click Run. So I did, its running, I can hit keys to see how the event handlers respond but I noticed the Watch List was blank. Note that normally I've always stepped through a macro so I'm used to seeing the Watch List populated. I know now the thing to do is insert a breakpoint, perhaps in the event handler's SRT> code and when execution reaches the breakpoint, it will pop into Step mode and then I can see the state of the variables. In v9 after it hits the breakpoint, I can only Step from then on. I actually wanted to just continue running but couldn't. I see in v10, you now have...

Enhanced debugger - multiple breakpoints, step, then run.

...which is great, I'll have to try that out.

Run to breakpoint means it runs to that point, stops and then waits for you to step. It puts it in debug mode, step mode. So the watch list will show the variables.

You used the phrase "run to breakpoint" three times in your reply but on searching, that phrase doesn't appear in either the "Using the Debugger" help topic or the Use the Debugger! blog post.

v9 Help text says:

• Insert Breakpoint
  Inserts a breakpoint after the selected line. Simply inserts **BREAKPOINT** on the next line. If running the script using 'Run' from the Debug menu, execution will pause when this Breakpoint line is reached and the script can then be stepped from this point.

but could say this instead:

• Insert Breakpoint
  Inserts a breakpoint after the selected line. Simply inserts **BREAKPOINT** on the next line. If running the script using 'Run' from the Debug menu, execution will pause when this Breakpoint line is reached, Watch List variables will be shown and the script can then be stepped from this point.

Also, in v9, you have three toolbar buttons in a row with the following tooltip text:

Code: Select all

Debug Step (F8)
Stop Debug (Ctrl+F2)
Run

Why just Run? The other two contain "Debug", why not one of these?

Code: Select all

Run Debug
Debug Run
Debug Run until Breakpoint

Just changing that tooltip text could serve as a reminder to users that always click that button to test their scripts that they actually have a Debugger at their disposal, not just an Editor and encourage them to explore its features.

If you're looking for another topic for your Blog or even better, the video demos you sometimes make, then I think "Using the Debugger" would make a great topic. Besides helping the users, it might even cut down on support questions eventually as users would more easily find their own problems if they knew their way around the Debugger.

Well, granted there's no video to go with it, but this article has been there since May 2006:
http://www.mjtnet.com/blog/2006/05/17/use-the-debugger/

Good blog post, however:

- Is there any info in that post that isn't in the Help File?
- Users will hopefully read the Help File when trying to learn the debugger but they may never find that blog post. Adding a link to it in the Help File "Using the Debugger" topic would make it more findable.

As for support requests, that is precisely the reason the above page is linked to right above the main support contact form:
http://www.mjtnet.com/contact.htm

Where it says: "Finally, if you're emailing for help with a script problem, have you debugged it yet?"

I've also linked to that article here in the forums when I've suggested someone use the debugger.

The debugger is frighteningly easy to use. Press F8 and see what happens and it should all become clear. Set a breakpoint and see what happens. There's not much more to it. Does that really warrant a video?

Well, you start off your blog post with...

• "The first thing I turn to when helping someone get their script working is the debugger. But I’m often surprised to hear people say they didn’t know about the debugger."

...so I'd say that yes there is an issue. To increase the visibility of the Debugger, you could:

- change the tooltip text from "Run" to "Debug Run until Breakpoint" or other choices as mentioned above
- change the window title from Editor to "Editor/Debugger"
- in Main screen File menu and right-click menu, menu item just says "Edit Script", why not "Edit/Debug Script"
- I say a video because some users who won't read through a page of text to learn something new... will actually watch a video to learn how something works. It takes them by the hand, they don't need to visualize, they can just watch.

Note that none of the above is meant as criticism, just feedback and opinions... take care.

[Marcus Tettmar]

Phew. Just a few points. The Run button is called Run because that is precisely what it does. IMO that is correct and well descriptive and adding other verbage is unhelpful and confusing.

I use the term "run to breakpoint" to mean exactly what it says in the help file: "when run is used execution will pause when this breakpint is reached". Means the same thing - run - breakpoint - pause.

Don't go searching the help file for the exact phraseology I use in conversation or in these forums. Like most humans I don't always describe things in precisely the same sentences.

It has always been possible to set a breakpoint - but until now only one. So for OnEvent handler it has always been possible to put a breakpoint in the subroutines to step through only those when the event handler has triggered.

I would be interested to hear from other people on this matter. Is the debugger complicated? Is the help file unclear? There are two blog posts about the debugger. Are they confusing? Are the debug options in the editor not self explanatory?

[JRL]

I like the new feature for multiple breakpoints.

I've never had any trouble with the debugger. I've used the debugger extensively for so long that my opinion about the instructions being clear or unclear may not be relevant. But I would comment that in my opinion many of the posts in this forum would not exist if the original posters had read the instructions and used the Advanced Editor's debugging feature. Many times I've answered questions simply by stepping through posted code and looking at the watchlist to see what issues popped up.

[Bob Hansen]

I could not work without the debugger, and never found it difficult. It is almost intuitive, but that will vary on one's other experiences.

The only problem I have seen in the past was with CTL/ALT key combinations. Always had to change focus and do those manually, but that was corrected some versions ago.

Using Step, and Watch List, and the log files is the best way to troubleshoot a script. Having multiple BreakPoint/Step/Run ability will be great.

I don't think a video is necessary, but perhaps a little more than mentioning "debug" might be better. Mention the debug tools instead. Ask if they have used the log, or Single Stepped and looked at the Watch List.

And because the log files are so useful, that is why I almost always use %variable% percents, so I can see the actual value in the log file, like having the WatchList built in.

[Marcus Tettmar]

Don't forget _DUMP_VARS also:

_DUMP_VARS
Set to 1 to dump all variable names and values to log file.