Macro ignores Python script & erratic Shortcut Mapper
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!
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.xmlto add a
type=2action to the recorded macro, where it the
wParamvalue 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+Eto a script, and then go and try to assign it to a macro as well, it tells me that there’s a conflict immediately.
… 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.
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
blahmacro, and deleted the
blahmacro. Then I went to my
PerlMonksQuestionPythonScript entry, where I had assigned the
Ctrl+Eshortcut for the script.
In the shortcut mapper view, it originally said “No shortcut conflicts for this item”:
But if I Modify that line’s shortcut, it claims it is conflicting with itself:
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+Eto 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 Instanceto add
Ctrl+E, it says no conflict. If I then Modify the
Move to New Instancewhile 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 Instanceand 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).
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!
find some insight to extend my running python script with the missing link (it’s just the saving of the active document …).
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=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
IDMare 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
notepadobject 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() :-)
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:
Same for Editor and editor.
@Alan-Kilborn Thank you too … now it’s clear ;-)