I found the problem. Please ignore
I was going to post how one goes about resolving problems such as the one you originally posted.
Using the KM Macro Debugger along with having the KM Variable Panel open (with the Variable in question selected), and then step through your Macro, Action by Action, observing how the Variable changes, or does not change.
2 Likes
very good idea. I don't use the debugger enough. thanks very much
I now remember why I don't use the debugger.
I am embarrassed to admit that I have been unable to resolve a status menu bar conflict (KBM vs ?) causing me to either not see the KBM menu bar icon or it being non functional (nothing happens when I click on it). This has been going on for quite a while and driving me crazy.
Since as far as I understand the debugger is only accessible via the menu bar (I can't find a debugger in the KBM app menu), I have to function without a debugger.
You can also start the KM Debugger by using one of the Debugger Actions:
Debugger Start Actions (multiple Actions available).
I usually use the Debugger Breakpoint This Macro, at the point in the Macro where I want to start debugging.
2 Likes
great !! thanks very much
Since you removed your original question, and this topic became about debugging:
I hope you don't mind that I have revised your topic title to better reflect the question you have asked.
FROM:
Looking for correct syntax to paste variable
TO:
How To Solve KM Problems Using the KM Debugger
This will greatly help you attract more experienced users to help solve your problem, and will help future readers find your question, and the solution.
1 Like
great idea, and thank you for the work
Thanks for pointing out the Macro Debugger. I cannot pause a step and check the value of Local_ variables in the Variables list. Other than displaying such a variable, is there a built-in panel where they can be monitored?
Nope. This is a major shortcoming of the KM Debugger -- inability to show Local and Instance variables. We have made a request to @peternlewis for this previously. Hopefully he will agree at some point and provide this sorely needed feature.
The same issue exists with the new KM9 "Value Inspector"
To be really useful, any debugger needs to display all variables used by the code (Macro) in real time as it steps through the statements (Actions).
1 Like
I have three suggestions here:-
a: Allow the ability to clear the Value Inspector of all variables shown
b: Be able to right click on a macro and LOAD the Value Inspector with all the fields used in that macro
Whether you want to let it "recurse" to a deeper level would be nice, but just the top level would help a lot
Right clicking on another macro would add its names to those displayed.
c: Having created a list of variables in the Value Inspector, then the abilty to save and restore that list (debug work environment) would also help, as opposed to having to retype them all in again.
1 Like
That would be a good workaround, but every debugger I have ever used automatically presents a list of variables from those used in the code/script/macro. IMO, that is what we really need, and it must include Local and Instance variables.
2 Likes
I do not mind, but it needs to be improved.
Also why are we limited to just one "instance" of the value inspector, you might want one to be focussed on global variables and another just the macro in question.
1 Like
Thanks @DanThomas , I still have a lot to learn about Keyboard Maestro though I have been using it for years now at this point. An area in particular that I would really like to improve is understanding how to debug issues better. I feel like I waste so much time with trial an error and settle on things working when macros are not optimized and use pause actions more than I would like to.
If you have made video or know of any good videos on how to use the debug mode and showing it in use that would be great. I would love to watch a video series on Keyboard Maestro. Beginner, intermediate and advanced would be awesome! Someday someone will make them.
Your video that you made on inserting common saved macros has been awesome and something I have used thousands of times! I use it almost every time I make a macro in Keyboard Maestro and has been awesome. You have so many great posts on this forum of things you have shared. I would love to get to understand this better.
Most of the time I just use "prompt" commands, because it's quicker to narrow down the section that's causing problems. I'm sure there's better ways of doing it, but like most people, when I'm trying to solve a problem, I usually don't have time to learn new tricks. I still use these logging macros, but I use them mostly in macros that run based on a time of day - like kicking off backups. But knock on wood, that's been running so smoothly that I basically forget all about the logging. 
1 Like
I have moved your post and related replies to this existing topic on KM debugging.
Debugging Resources
- Macro Debugger -- KM Wiki, June 2019
- KM 6 Macro Debugger Tutorial by Philippe Martin, May 2013
- Using the KM Debugger -- YouTube video by Ez Buttons, May 2014
Finally, I'll quote myself from above:
This is the main method I use for debugging KM Macros.
One other key point is to place a Debugger Breakpoint This Macro Action at places in my macro JUST BEFORE the Action where I suspect the bug is.
I change the color to red so I can easily identify and find it in my macro.
When I "think" I have resolved my issue, I just disable the Breakpoint Action, in case I need it later (which I often do).
The next time I have a real issue to debug, I will do a screen recording and post here.
Questions?
1 Like
could you give an example of how you use prompts to debug ?
thank you
I'd love to see this as well. Sounds like you might just be using them as stopping points like Michael is doing with the Debugger Breakpoint. I typically use voice over to hear things said right before where I think issues might be. Hasn't felt the most efficient way to do it but it certainly has helped me find several issues. A recent macro issue I have had though that didn't help very much and things remained a mystery.
Glad to hear that.
Thanks, Michael, that would be great!
I read all those posts and rewatched that video (I had watched that several times when I first made the jump from QuicKeys years ago), I will have to play around more and see what I can learn. The more videos out there in this area the better for me. Especially something that shows debugging switching between applications and waiting for windows to pop up. Philippe talked about these but I would love to see this in action in a few videos.
Thanks for your help.
Debug techniques based on bitter experience (see 8 below)
1: Write perfect code.
Then you will never, never, ever need to debug.
Very, very, very few people on this planet have this ability.
Maybe you know one?
Maybe PeterNLewis is one?
I do not know, but I do know I am not one of them.
2: When you have sketched out your code, then think how you will test it, BEFORE you start writing it or testing it.
The analogy I would use is that you are playing a game of chess.
You have the White pieces.
The opponent is has the Black pieces.
You carefully analyse the position from the White perspective.
THEN, to test, you walk around to the other side of the board and look at the situation from the Black perspective.
i.e. you change your point of view and try and see how you will test this.
This will often throw up things you have not thought of because you are looking at it from a different point of view, typically unusual conditions, initialisation problems, race conditions, semaphore conditions etc.
3: Explain what you are trying to do to an imaginary dog, cat, or third person.
This makes you formulate the problem in a different way often leading to an “Ah-Ha” moment.
You do not need the dog or cat or whatever, it is just a question of changing your perspective on the problem. (I used to explain to my wife, but she used just carry on ironing, and ignore me completely, but it did the trick). If you are in an office, a fellow programmer or the office coffee machine is a suitable substitute.
4.Go for a walk round the block, do something else, and comeback to the problem later, sleep on it. Again it is a question of having a different perspective or a fresh look.
- Redefine the problem. If solution A is not working, then rewrite as a different solution
e.g. assume you had to print the three times table from 1x3, 2x3 then the alternative solution would be print the 4 times table from 12x4 to 1x4 i.e. the same problem modified.
6a. Redefine the complete problem. Ie make it more generic e.g. tables 1…12 x 1…12
6b Redefine the complete problem. Ie make it more specific.
-
Create test cases and scenarios and see what would happen
-
Goto the pub and have a pint ( my personal favourite)
===================================
- Keyboard Maestro debug specifics.
9.1 Check you have not mis-spelt a variable name.
9.2 Add start and stop debug statements at key points
9.3 Change the name of Instance and Local variables to GLOBAL by adding say xx as a prefix.
e.g. Instance_loop_count_n becomes xxInstance_loop_count_n and therefore will appear in the Global variable list. Later, you remove the xx.
9.4 Create a debug macro that just consist of Display text in a window of ALL the variable names you are using. (This will not work for Local variables, so make all your variables either global or Instance unless it really really is a local variable) e.g. “Var123” >>> Its actual value so you know what is what. The advantage of the debug macro is that you can include at ANY point in the macro under test, but the variables must be global or Instances….
9.5 Do NOT do complicated functions in KM function calls
e.g. instead of say MOVETO( sqrt(var1 x var2) / var3)) do
temp_var = sqrt(var1 x var2) / var3)
MOVETO(tempvar)
then you can check on the value of temp_var
9.6 the KM debugger advances to “Nextstep”
You can “force” it to stop at intervening points by inserting dummy statements as
temp_debug_point is set to text “ I am now here”
code ~~~~~~~
temp_debug_point is set to text “ I am now here2 ”
code ~~~~~~
temp_debug_point is set to text “ I am now here3”
This stops the KM macro debugger running away and you know exactly where you are
This can be enhanced by
temp_debug_point is set to text “ I am now here3:: var 88 = %Variable%var88%
so you know the intermediate value.
9.7 XML. Save the macro by exporting to .kmmacro format i.e. XML.
Open the macro using an XML editor e.g. Atom.
This will enable you to search for specific strings especially if you have a variable name mis-spelt
9.8 Use KM> Prefs> variable and clipboard as these are updated in “realtime” as the macros is run.
9.9 It is remotely possible it is not your fault i.e. a bug in OSX, but in my experience this is rarely the case.
9.10.When all else fails ask JMichaelTx or one of the other major contributors to this forum.
I am going to rebadge myself as Caspian as Sleepy has been taken.
9.11 Here are some quotes from HitchHikers Guide to the Galaxy which are worth remembering, after all, it is only a “bug”.
9.11.a. “Funny,” he intoned funereally, “how just when you think life can’t possibly get any worse it suddenly does.”
9.11.b. The chances of finding out what’s really going on in the universe are so remote, the only thing to do is hang the sense of it and keep yourself occupied.
9.11.c. A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
9.11.d. Not unnaturally, many elevators imbued with intelligence and precognition became terribly frustrated with the mindless business of going up and down, up and down, experimented briefly with the notion of going sideways, as a sort of existential protest, demanded participation in the decision-making process and finally took to squatting in basements sulking.
1 Like
Most of the time I just add a prompt that says "Here", or "1". If the problem hasn't happened yet, then I add another prompt further on. The prompt might also display the values of some variables.
I learned a technique called "binary search" a million years ago, and it really helps track down where bugs occur. Put a prompt halfway through the code. If the prompt displays before the problem occurs, then add a prompt halfway between the prompt and the end - otherwise, add a prompt halfway between the prompt and the start. It doesn't take long to track it down.
Of course, there are some types of problems that prompts won't help, but hey, if it was easy, everyone would do it!
2 Likes