Are you thinking of keeping the doc in that disabled group? I'm not sure, but it's been my presumption that whether or not macros and groups are disabled does not affect the size of the macro file, and thus has little influence on how long it takes to write out the file with each incremental change. Thus disabling macros will not speed up the Editor when it becomes sluggish. That is my purpose in getting the doc into a separate file, especially when it's lengthy.
Maybe an AppleScript Observer could be created to watch for that folder being opened.
KBM does have a trigger for when a file is added or removed from a watched folder and there are several other products that do the same thing, trigger an action when a file is added or removed from a watched folder.
Perhaps there could be a Master Doc folder, and a separate Open Doc folder. The Read Remote Doc action wcould LINK the Master Doc file to the Open Doc folder, which would add a file to that folder without actually creating a "new" file, just a new pointer to the contents.
%TriggerValue% is the name of the found new file, so that could be immediately editable. By making it a LINK a link instead of a copy, that would allow changes in the Open Doc file to be automatically included in the Master Doc file.
That's a little convoluted, but doable. How would it work in the KBM UI while actually editing the macro? You want it to be a Comment, as far as macro execution is concerned, and yet you want it to actually do things when you want to see the doc.
Are there any KBM Tokens that identify the macro currently being EDITED in the KBM Editor? Is that accessible through AppleScript? If so, then there would be no need to make any changes in the macro that is being edited, maybe only a comment that says, "This Macro is documented in the file xxxxxxx; press the ⌘⇧K hotkey to open it in a separate editor." Then pressing the hotkey would identify the macro currently open in the editor and open the corresponding doc. But I don't know if that aspect of the Editor is exposed anywhere.
Why not just include the documentation in the forum post when you release the macro? Then you can link to that in the comment.
I did read your posts more than once, but I don't understand whose "files" you are trying to create links for. In my first post, I was assuming this was just for you, yourself, and so I used the "file://" protocol. But now it sounds like you want this feature to work for other people too, but as we know they don't have access to your file system, which probably means I don't understand what you are trying to do. But maybe noisneil knows, so let's see what he can say to help.
I had the same thought as you, and presumed there might be some kind of downloadable packaged to accompany the macro, as I've seen that a few times; resources etc.
I do think linking to the forum is the simplest solution, and it's what most people do when they want the user to refer to helpful info that pertains to a macro.
The other day I managed to do that (ie, "linking to the forum") in my OCR speed test macro, using a button, where I created a link in the macro that brought the user to the web page where the macro was uploaded to. Maybe that approach might work. I had never seen anyone do that before I did it.
In order to do that I had to modify my macro after I had created the web page, because I needed the link to the web page. It was kinda a chicken and egg problem.
When/if it's published, that would be fine. But what I'm looking for is documenting my development process for myself, while it's a work in progress.
Yes, and that may indeed be the simplest way for me to proceed.
I'm not sure what gave you that idea, other than the way that I am my own audience when I come back to work on or enhance a macro after being away from it for a while.
At the moment, the only sharable or publishable aspect of this is the documentation support macro/scheme/whatever itself.
In that case August send yourself a private message containing your documentation; you can then link to its URL in the usual way, but only you will be able to access it. If later on you wish to make it public you can copy its content into a normal forum posting.
Use this macro:
Download Macro(s): Get Macro Actions Name Info.kmmacros (5.6 KB)
- Macros are always disabled when imported into the Keyboard Maestro Editor.
- The user must ensure the macro is enabled.
- The user must also ensure the macro's parent macro-group is enabled.
- The macro parent group is "[Test]".
- macOS 13.6.1
- Keyboard Maestro v11.0.1
LOL! I'm not sure what problem you're solving here, but I'm pretty sure that to find an even longer way I'd have to go around the neighbor's barn too.
My apologies for not being clearer in my statement of the problem. I'm looking for an easy way to link to working doc that I use to keep track of the various layers, problem threads, and open questions in the process of developing a complex macro that includes what I hope will be a smooth and fast user interface. When I have an idea or a question, I want to get it written down right away, and if that's in an outside doc, then I want to be able to link back and forth from the macro to the doc and from the doc to the macro, if not in live links, then at least in an organized outline form that matches between the two forms.
My KBM editor is getting slow and sometimes misses characters that I type. I've read that I need to reduce the size of the macro file. A lot of my own macros have pretty verbose comments in them and I've thought that maybe I could put most of that into separate files, but still have it accessible when I need ot maintain or simply re-understand the workings of a macro. This is for me keeping track of my problem solving and development process, not (yet) intended as something for others to use. That's a whole 'nother problem.
THAT'S what I was trying to remember. That's what I remember using before.
I guess it's not intuitive to me (yet) that the Editor has a Stop Editing mode.
COOL! I'll try it.
On skimming it, it looks like it produces just a list of titles, while the "Stop Editing" method shows all the various settings too. So this may well come closer to my "Minimize all Actions and do OCR on an Image" technique.
Nothing more, nothing less - as per the title of your OP.
I was able to reduce the size of my macro file by removing Images from Find Image actions and replacing them with my ClickOnWord() macro.
THANKS! I'm going to have to check that out.
I have also seen a macro that helps similarly by moving the saved images in the Find Image actions out to external files. Using an external file as an image source is directly supported by the Find Image action and this macro helps facilitate the conversion. Unfortunately, I didn't install it when I saw it, so I'm going to have to dig for it.
Thanks for the memory prompt.
That's also a good way too, and I do it occasionally, but I found difficulties doing that because some apps change the DPI of an image resulting in a mismatch when reloading. So I avoid using files. Peter has mentioned this issue in other threads like this one:
Do you know which apps to look out for? That seems a hairy problem to debug.
I had some macros that were growing over time, like some I'd created to automate saving Facebook items that I want to respond to later. Facebook would imperceptibly change a graphic element which I had been using to tell, for instance, that I had scrolled to the bottom of a list, so when the macro broke, I would fix it by adding a new capture into the macro as another OR condition, while leaving the older images in place, so that my macro would hopefully work no matter which version of the UI I was given.
Most of the time my Click on Found Image actions are ways to interact with an app's UI. For many of my macros, I think I can eliminate images entirely by using @noisneil's macro:
I've already used it on the color picker of TextEdit and found it very straightforward to use in generating an AppleScript snippet to click directly on a specific UI element, without having to get KBM to position the mouse at all.
My testing comes from about 5 or more years ago, so I'm not sure if it's still valid, but the macOS Markup utility and some free image editor called PaintX, I think, were what I tried. When I saved images, they changed the DPI resulting in complete mismatches. I think I had an alternative solution which was to always use the middle value in the Displays pane of System Settings:
I suspect that using a different setting than "Default" results in DPI mismatching. I think this was the underlying cause of my DPI problem. I haven't tested this idea in about 5 years, however. That was a tough problem to diagnose.
After that I just gave up editing images and just used screen captures without editing them, and I never had another problem.
That's what I've been doing all along.
Thanks for the voice of experience.