Macro does not record my Run action

Victorel Petrovich

Hi,
first time recoding a macro.
I have prepared a sequence of actions, the main of which is to run (with menu > Run > Run) a certain command invoking an external tool.
But Macro fails to record the Run part.

Are macros supposed to be able to record Run actions at all?

I have read the manual on Macros, as well as the FAQ pages in the community about Macro and haven’t seen Run actions mentioned specifically.

I tried recording the Run action in isolation, in several ways:

by using a shortcut key assigned to that Run action,
by navigating to Run > Run… where the command to run was already typed in
by navigating to Run menu where my command was saved with its own menu entry

Thanks

Terry R

@Victorel-Petrovich said in Macro does not record my Run action:

Are macro supposed to be able to record Run actions at all?

I can’t answer that but one of our regulars did some investigations a short time ago. Read his post here on what he found out.

In essence there is no definitive list of non-recordable commands.

Terry

PeterJones

@Victorel-Petrovich said in Macro does not record my Run action:

I have read the manual on Macros, as well as the FAQ pages in the community about Macro and haven’t seen Run actions mentioned specifically.

Sorry, I had thought it would be obvious that the “How to Cheat the Macro System” section of the FAQ would be applicable to anything that needs dynamic menu entries, including Plugins, saved Run-menu commands, or calling other Macros from your macro, even though the FAQ previously only mentioned Plugin commands. However, since it apparently wasn’t obvious, I have clarified the FAQ now: the same method can be used to playback saved Run-menu actions in a Macro, or to playback other saved Macros in a macro.

But, because they don’t have fixed menu command IDs, Plugin commands, saved Run-menu actions, and saved Macros will never be macro-recordable; you will always have to manually edit a macro to be able to playback any dynamic-ID commands.

Victorel Petrovich

@PeterJones Thanks for the fast reply and clarifications.
“Obvious” is a dangerous word, our math prof used to say. I think you know much more about N++ than the average user.
If you want to make it clearer for others, you can change this subfaq’s title https://community.notepad-plus-plus.org/topic/25400/faq-automating-notepad/2?_=1756262523622
to something like “Using Plugin, Run-menu and Macro Commands in Macros”
And this https://npp-user-manual.org/docs/macros/ would benefit from a link to https://community.notepad-plus-plus.org/topic/25400/faq-automating-notepad

Thank you for the detailed documentation, anyway.

I’m going to give a try to manually editing my macro and will report here.

Victorel Petrovich

This post is deleted!

Victorel Petrovich

It worked, based on the example in “How to Cheat the Macro System”.

@PeterJones Moreover, it continued to work even after I deleted another menu entry in Macro , located before the one I’m using one, plus experimtentally added then deleted several other saved macros and saved Run-menu actions and also after uninstalling a plugin and then after reinstalling it. Everytime restarting N++.

So it appears to me that in principle, Macro involving Run-menu actions should be recordable: the fact that the menu ID is dynamic does not affect the saved macro. Perhaps the same is true if the macro involves other macros and plugin actions.
The only case I can think of where the dynamic nature of a menu-command ID can ruin the saved macro is that it involves a plugin script and then you uninstall that plugin.
What do you think ?

PeterJones

@Victorel-Petrovich said in Macro does not record my Run action:

What do you think ?

I think your experiment was not sufficient.

Start with three recorded macros (A,B,C, which just type the character of the name), restart
Use NppUISpy! to see that those macros are 20001, 20002, 20003

Manually edit a new macro called “Do BC” which calls B and C

<Macros>
    <Macro name="Trim Trailing Space and Save" Ctrl="no" Alt="yes" Shift="yes" Key="83">
        <Action type="2" message="0" wParam="42024" lParam="0" sParam="" />
        <Action type="2" message="0" wParam="41006" lParam="0" sParam="" />
    </Macro>
    <Macro name="A" Ctrl="no" Alt="no" Shift="no" Key="0">
        <Action type="1" message="2170" wParam="0" lParam="0" sParam="A" />
    </Macro>
    <Macro name="B" Ctrl="no" Alt="no" Shift="no" Key="0">
        <Action type="1" message="2170" wParam="0" lParam="0" sParam="B" />
    </Macro>
    <Macro name="C" Ctrl="no" Alt="no" Shift="no" Key="0">
        <Action type="1" message="2170" wParam="0" lParam="0" sParam="C" />
    </Macro>
    <Macro name="Do BC" Ctrl="no" Alt="no" Shift="no" Key="0">
        <Action type="2" message="0" wParam="20002" lParam="0" sParam="0" />
        <Action type="2" message="0" wParam="20003" lParam="0" sParam="0" />
    </Macro>
</Macros>

Restart and use NppUISpy to see the new macro is 20004. (Verified the macro worked, typing BC)
Edit shortcuts.xml, delete macro “A”, save, Exit Notepad++, restart Notepad++
See that NppUISpy now lists B as 20001 and C as 20002 and “Do BC” as 20003
Run “Do BC” and see it type C a number of times: it’s running 20002 to get “C”, then it runs 20003, which recursively calling itself until it hits an internal recursion limit

I tried this multiple times, in various combinations. It is 100% repeatable: it renumbered the macros every time one was inserted or deleted from the sequence, invalidating the wParam value used.

Like with the LF vs CRLF, I think you happened to be in the “lucky” circumstance where your experiment happened to work. In general, you cannot rely on the the menuCmdID for any given macro staying the same if you change the number or order of macros. Telling other people that it’s okay to rely on that is to tell them to invite disaster.

Hence, the FAQ will continue to state that if you change the number of Macros (Run commands, or add/remove/update plugins), you should always check to make sure the menu command ID hasn’t changed, otherwise your macro will quite possibly not do what was intended, once circumstances change.

Victorel Petrovich

@PeterJones
Great walk-through.
You knew how the menu IDs are assigned, so you were able to design the proper experiment.

I have just performed an equivalent one where I created 2 Run-menu actions, then manually included the second one in a macro; tested fine; then deleted the first Run-menu action and restarted N++.
When calling my macro, it, predictably, failed for the reasons you mentioned (in fact, it crashed N++).

A question in your step 3 above:

<Macro name="Do BC" Ctrl="no" Alt="no" Shift="no" Key="0">
        <Action type="2" message="0" wParam="20002" lParam="0" sParam="0" />
        <Action type="2" message="0" wParam="20003" lParam="0" sParam="0" />
    </Macro>

shouldn’t sParam be "" ? based on https://npp-user-manual.org/docs/config-files/#attributes-for-the-action-tag
Same in your example in https://community.notepad-plus-plus.org/topic/25400/faq-automating-notepad/2?_=1756438181968

Now to the main part:

It is 100% repeatable: it renumbered the macros every time one was inserted or deleted from the sequence, invalidating the wParam value used.

Same happens when Run-menu items are inserted/removed from that menu; I guess similar thing happens with plugin menu.

This pinpoints the core issue and also a possible solution/ fix to N++ code that deals with menu ID (re)assignments:
The menu ID for a command should be kept constant.

(Up until that command is removed by the user.)

PeterJones

@Victorel-Petrovich said in Macro does not record my Run action:

shouldn’t sParam be "" ?

That would be better, yes. They ignore the sParam unless it’s one of the string-related actions, but for consistency’s sake, it should just be "". (I copy/pasted the line from a different macro, and didn’t notice it has the sParam="0" for that one)

The menu ID for a command should be kept constant.

That would be the easiest, from the hacker perspective. But since we are breaking the macro “contract” by trying to include non-recorded actions in a macro, we’re already past the edge into unsupported behavior; I am doubtful that storing/allocating a “constand commandID” in the XML would be implemented just to support a few hackers who aren’t following the intended behavior of macros.

I believe that the “official position” is that if you are doing something that doesn’t work with a recorded macro, you should instead switch to something like NppExec or PyhonScript plugins, instead of trying to use the macro system. I’m not sure he’s noticed how much I abuse the macro system, nor the fact that I have a FAQ explaining it. ;-) And I am really not sure I want this pointed out to him, lest he close the security gaps in the macro system.