Send4 from tw/X → save this tweet Macro (v11.0.2)
Recently this simple macro refuses to work ( it is fired acc. to Interactive Help)
Even after increasing the pauses.
It does not open the designated file, but the file at the top of other files.
It seems /sometimes/ not to be able to find the destination .txt file.
Somewhere I read to switch off / on a setting, in Accessibility ?! .
Once a reboot did help.
Send4 from tw-X → save this tweet.kmmacros (5.9 KB)
The Open a File Folder or Application action should explicitly specify BBEdit, since that is what you want.
The macro looks fine.
Check the Engine.log for any reported problem. (Help ➤ Open Logs Folder).
Now it happened again, same macro was triggered twice (A & B):
(A)
2024-04-24 20:55:35 Execute macro “Send4 from tw/X → save this tweet” from trigger Duplicate Macro Palette
with success, has only 1 line in the log
(B)
2024-04-24 20:57:01 Execute macro “Copy To Serial Clipboard1” from trigger Duplicate Macro Palette
2024-04-24 20:57:14 Execute macro “Send4 from tw/X → save this tweet” from trigger Duplicate Macro Palette
without success, has these 2 lines in the log
Any assistance will be much appreciated,
OmarKN
The previous line is a different macro that you triggered 13 seconds before the desired macro, so that does not tell you anything.
When it does not work, you need to determine what does not work.
Does the Copy happen? Is the selection now copied into the clipboard history (see the Clipboard History Switcher and check it is there).
Does the Open document not work?
Does BBEdit not come to the front?
Do the text insertions not happen?
Whenever debugging a macro, the sequence is the same - ensure it is triggering (which you have) and then verify which actions work and the first action that fails.
It is the text insertions which don't happen.
I added a 1.0 sec pause after the COPY and before opening the file.
It's working for now.
Question: Is there a way to better estimate the time for pauses - down from 1.5 sec (f ex if target app is always active / open) ?
/okn
So it looks like the Copy step is the problem -- instead of pausing for a set time, try pausing until the clipboard is changed i.e. the Copy is done:
In full:
I'm sure this is a better approach (higher math!)
Question: How is the variable set here, when the macro copies to the SystemClipboard?
So CLIPBOARDSEED a known entity for KM?
/
with best regards,
Omar KN, Stockholm, Sweden
This seems very odd to me because the Copy action already waits for the clipboard to change.
The Cut and Copy actions wait until the clipboard changes before proceeding.
So if that Pause is resolving the problem, then my guess is there is something else going on. Try moving the Pause before the Copy action and see if that works too. If so, try adding a Pause Until action with the Modifiers condition and pause until all the modifiers are released.
Ohhh, that's an interesting idea. That might be necessary for some apps which use unusual methods for inputting keystrokes.
macos 13.6.6
KM 11.0.2
Yes, it has to be something else.
Is there a plist file (?) which can be deleted, or ?
The Evidence:
Another macro, which never had any problem (for years) 'reacted' in the same manner as the original one above. The text was copied (Clipboard History Switcher), but the correct file is not found/ opened, although BBEdit is open, with those target files.
This is the log entry - no success
2024-04-26 17:28:05 Execute macro “SendKM Youtube title & date to watched-yt-videos vs.4” from trigger The Hot Key ⌃⌥⇧⌘Y is pressed
Then 1/2 h later it did work!
2024-04-26 18:09:08 Execute macro “SendKM Youtube title & date to watched-yt-videos vs.4” from trigger The Hot Key ⌃⌥⇧⌘Y is pressed
/
with best regards,
Omar KN, Stockholm, Sweden
It is not that kind of an issue.
That sounds more like an issue with permissions.
Is reporting of errors enabled on the action? Does the target file have the Quarantine bit set? That is known to cause problems.
How to enable 'reporting of errors on the action?' - info not found.
/
with best regards,
Omar KN, Stockholm, Sweden
In BBEdit, check that the "Open documents into the front window..." setting is off.
If that option is on and your document opens into a "shared document window", where there's a list of open documents in the left pane, your ⌘↑ will activate the first document in that list rather than moving the insertion point to the top of your target document.
If that solves the problem you may just have to find another way to move the insertion point.
I'm now testing with a very similar text macro ("watched YouTube") if someone could test it - I had it for years w/out any problem.
+How to enable 'reporting of errors on the action?' - info not found.
(I don't know how to upload image to existing thread, sorry.)
Yes, and that's the result of the ⌘↑ action you have between the "Activate BBEdit" and "Insert Text" actions. I think that is the problem.
Try either turning off BBEdit's "Open documents into the front window" so that your target is in a window of its own (will let the ⌘↑ command work properly) or find another way to get the insertion point to the top of the document. Note that you will have to close the target document after doing this -- if it is already open and in a "shared document window" it will reactivate there, not open in a window of its own.
Edit to add:
BBEdit's "Paste" will be enabled when your target document is active but won't be when the document list is active -- and you can move from document list to document with a single ⇥ keystroke. So:
Send4 from tw:X → save this tweet -- hopefully fixed!.kmmacros (5.9 KB)
No, if the file has an Qarantine bit set, then the Open a File Folder or Application action will not be able to open it.
You can use the xattr -p com.apple.quarantine /path/to/file command to display the attributes of the file if it displays anything other than No such xattr, then the bit is set.
2 observations
(1.)
When I wrote
So Terminal gives this 0086;6405c9c6;BBEdit;
Anyway these are my BBEdit settings
(2.)
The macro works fine when using a TextEdit.txt file with as usual 644 permissions.
Have you tried the version of your macro at the bottom of this post yet? How did you get on with it?
Well, well → it works!
Inserts the copy into a singular BBEdit window, which is fine!
Remains the question (which is less important, maybe)
why did those macros all work (for years) and then ≈ a month ago sometimes break,
Thank you Nige_S !
/
with best regards,
Omar KN, Stockholm, Sweden
