Macro ignores Python script & erratic Shortcut Mapper



  • Dear all!

    I have a python script, which works fine (1) if it is invoked by its keyboard shortcut (assigned by means of the Shortcut Mapper, in my case Ctrl.-E) or (2) if it is applied via the menu entry Plugins\Python Script\Scripts\MyScript. However, whatever I do, if I try do start MyScript from a recorded Macro (either using method (1) or (2) during recording), nothing happens. (Note: the script works as expected while recording the macro, but it does not if it is re-called again by the saved macro.) It appears, the macro simply ignores the call of the script when getting saved!

    With respect to Ctrl.-E, maybe, some strange observation applies. The Shortcut Mapper erratically announces a “CONFLICT FOUND!” (when re-opening the mapper) although it says “No conflict …” directly after assigning that shortcut.

    npp++ is 7.9.5 (64bit), python plugin and, generally, OS (Win10Pro) are up to date.

    Many thanks for any idea!



  • @Peter-Greistorfer ,

    It appears, the macro simply ignores the call of the script when getting saved!

    Correct. Macro recording does not record calls to plugin menus, including calls to pythonscript entries. This is because the macro recorder can record three basic actions, per the docs: editor commands (essentially keystrokes inside the editor panes), most built-in Notepad++ menu actions, and search/replace actions.

    Honestly, though, anything you can do in a macro can be translated into PythonScript commands. So if you’ve already got a PythonScript that you’re running, why not just expand it – or write a wrapper PythonScript – to include the other commands that you had been trying to send with a macro? (There should even be examples in the Forum of calling one pythonscript from another.)

    The macro system is good for automating built-in actions in a linear fashion. If you want anything else – loops, conditionals, calling non-built-in actions, etc – then a scripting plugin like Python Script is your best bet. That said, there is a caveat: the reason why the Macro recorder doesn’t like plugin actions is because they don’t have fixed IDs – as you add or remove plugins, the command-id for the menu actions change. However, if you are 100% sure that you will not be adding or removing plugins or plugin menu entries, you can sometimes get away with cheating. If you have a plugin like NppUISpy, you can look at what Command ID is currently assigned to a given PythonScript entry. If you make note of that entry, you can then go edit %AppData%\Notepad++\shortcuts.xml to add a type=2 action to the recorded macro, where it the wParam value is the Command ID that you manually looked up. But that’s fragile, because lots of things can influence that. (Which is why the Macro Recorder doesn’t try, because it would give you a false sense of security.)

    With respect to Ctrl.-E … The Shortcut Mapper erratically announces a “CONFLICT FOUND!” (when re-opening the mapper) although it says “No conflict …” directly after assigning that shortcut.

    Did you try to assign that keystroke to both the PythonScript and to the macro? But even then, I cannot replicate those results. If I assign Ctrl+E to a script, and then go and try to assign it to a macro as well, it tells me that there’s a conflict immediately.
    b5f257e1-bec3-425f-8ea5-5ce2a5727702-image.png
    … the ShortcutMapper main menu will also tell you where this conflict is, so after CONFLICT FOUND suddenly starts appearing – even if you didn’t expect it to – look at the entry that it tells you, because that’s what’s causing the conflict. If you need help debugging that, you could paste us a screenshot or two – one showing the conflict, and the other showing us the entry that the conflict points to.



  • @PeterJones said in Macro ignores Python script & erratic Shortcut Mapper:

    But even then, I cannot replicate those results

    I take it back. When I was cleaning things up after my experiment, I replicated it.
    I deleted the shortcut from the blah macro, and deleted the blah macro. Then I went to my PerlMonksQuestion PythonScript entry, where I had assigned the Ctrl+E shortcut for the script.

    In the shortcut mapper view, it originally said “No shortcut conflicts for this item”:

    a7985132-73b0-4593-a3e7-1e4afeefc787-image.png

    But if I Modify that line’s shortcut, it claims it is conflicting with itself:

    9021eb54-0020-4951-aee6-f0d6e49557dd-image.png

    If I Clear it and modify it again to re-add the Ctrl+E, it finds no conflict.

    If I clear it there, and assign Ctrl+E to some other Plugin Command entry, the same thing happens (it claims CONFLICT on that keystroke if I Modify that same entry).

    More experiments show: It’s caused when I filter the view – and then, only when the number in the far-left column changes. If I go to ShortcutMapper’s Main menu tab in a brand new unzip of v7.9.5 (no additional plugins, etc) and filter by new, then edit Move to New Instance to add Ctrl+E, it says no conflict. If I then Modify the Move to New Instance while still filtered, it claims a conflict with itself at #167. If I cancel the Modify (so it’s still Ctrl+E) and remove the filter, and scroll down to #167 Move to New Instance and Modify, it does not say it’s conflicting with itself.

    Now that I describe it, this problem sounds familiar. If I get a chance, I may have to do some searching here and in the issues list, and see if I can find something similar (or if anyone beats me to it, feel free to link to the resulting discussion and/or issue).



  • @PeterJones said in Macro ignores Python script & erratic Shortcut Mapper:

    Now that I describe it, this problem sounds familiar.

    Found it. issue #5374 – it was apparently closed/fixed in v7.6.6… so apparently this is a regression; I will need to experiment with v7.6.6 vs 7.9.5, and maybe even bisect it back to the original, to figure out when it came back (or whether I was wrong about it being fixed in v7.6.6)



  • @PeterJones I absolutely appreciate your fast and comprehensive answers, thanks a lot!

    So I will have to forget the macro-script-approach (since your workaround sketched actually is a little fragile) and try to find some insight to extend my running python script with the missing link (it’s just the saving of the active document …).

    And, yes, these conflicts and non-conflicts did arise when I filtered the Plugin commands to find my Python scripts written before!



  • @Peter-Greistorfer said in Macro ignores Python script & erratic Shortcut Mapper:

    find some insight to extend my running python script with the missing link (it’s just the saving of the active document …).

    notepad.save() ?



  • @Peter-Greistorfer said in Macro ignores Python script & erratic Shortcut Mapper:

    try to find some insight to extend my running python script

    @Alan-Kilborn mentioned the right command if it really just is a save action.

    But in general, you can edit shortcuts.xml, and look for your macro name (in my instance, it was blah). There will be a list of <actions> as described in my previous manual link. For type=0 and type=1, the scintilla.iface file will map message=# to the appropriate command – then you can search for that same text in the PythonScript docs to find the editor-object method name. For type=2, the mapping of built-in menu commands can be found in menuCmdID.h, though you have to do a little math: for example, IDM_FILE_SAVE maps to (IDM_FILE + 6), where IDM_FILE and IDM are defined near the top of the .h; putting that together, ((40000 + 1000) + 6) = 41006, so set type="2" wParam="41006" in the macro definition will map to IDM_FILE_SAVE – you would then look through the notepad object methods in the PythonScript docs to get the equivalent command.



  • What should be the argument of notepad.save() if I want to save the current active edited file?

    Your second post …, well, thanks, but that will need some more time.



  • Think I found it: no argument and dont use Notepad.save() :-)



  • @Peter-Greistorfer said in Macro ignores Python script & erratic Shortcut Mapper:

    dont use Notepad.save()

    Notepad is the “class name”.
    notepad is the instantiated object name.
    You call functions on an instantiated object.
    So, yes, you want it in your code, just as I wrote it before: notepad.save()

    Same for Editor and editor.



  • @Alan-Kilborn Thank you too … now it’s clear ;-)


Log in to reply