Macro does not record my Run action

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.

Victorel Petrovich

@PeterJones Since there is no official list of what is supposed to work/ be recordable with macros and what not, I don’t think there is any “contract” here.
My impression is that, at least with regards to these dynamic-ID menu commands, the current situation is simply a result of the coding solutions that were deemed good-enough long time ago and then the developers never had enough time/incentive to change it.

But if enough people will agree that macros become much more powerful by including any Run/Macro/Plugin commands, then N++ code could be changed, for the better.

It’s also about the long term vision for Macros: is it desirable to make them more powerful, to give more power to the average user that doesn’t have time to learn scripting, or not?
(IMO, it makes it easier even for those who know scripting)

I already found some raw initial algorithms for making the user’s menu-command IDs constant - if other people want to work with the C++ part.

I’m not sure he’s noticed how much I abuse the macro system

I don’t think you are abusing it; you’re simply working around the current limitations.
That’s normal: any software has limitations; no software is perfect from the get-go. It evolves.

Victorel Petrovich

This post is deleted!

Alan Kilborn

@Victorel-Petrovich said:

I already found some raw initial algorithms for making the user’s menu-command IDs constant

Great.

if other people want to work with the C++ part.

Why not YOU?

Victorel Petrovich

@Alan-Kilborn if I knew it, I would.
Another big part is being more or less familiar with the organization and specifics of N++ code.

Alan Kilborn

@Victorel-Petrovich

How come it seems like the people will all these grand ideas for how the code should be changed have no ability to do it?

Victorel Petrovich

@Alan-Kilborn it just seems to you so. Just like it seems to you that my ideas are “great” and “grand”.