@Tom, thanks for the testing and feedback.
Yes, ⌘⇧4 is working for me, but I'm already on an updated version.
All screenshot shortcuts are working for me. Tested on two Macs, but both Yosemite (10.10.5)
I think you are seeing an error I had originally in the RegEx for parsing the file name and ext. It should be:
(.+)\.(.+)$
I'll upload my revised macro shortly.
No, the regex is fine. (Otherwise it wouldn’t work with large screenshots.) It indeed needs the ‘Pause Until…’ or, better, the Semaphore Lock.
Possible that it’s different on Yosemite.
Just updated my original post above with Ver 2.1
@Tom, please test this version when you have a chance. I think it will fix all of the issues you reported.
Note that I did not have to add any of these:
However, I have not tested for doing another screen shot before you have finished the macro of the current screen shot. I don't know why that would every happen. As soon as you complete a screen shot, the macro immediately pops up.
But maybe I'm missing something.
However, I have not tested for doing another screen shot before you have finished the macro of the current screen shot. I don't know why that would every happen. As soon as you complete a screen shot, the macro immediately pops up.
But maybe I'm missing something.
Yes, you are 
It’s not the user who is making two subsequent screenshots, it’s the OS that is placing two files in the Desktop folder. The first one you don’t see. It’s the temporary dot file (see my post above and/or the screenshot here). This triggers the first run of the macro. You won’t see the user prompt, because the macro gets stopped at the ^Screenshot condition.
A little bit later (how much later depends on the size of the screenshot) the final file —without dot— appears on the Desktop. This triggers the macro again.
Run the macro in debugging mode (Keyboard Maestro Menu > Start Debugging) and you’ll see the two instances of the macro. Or remove the file name condition, and you’ll see two user prompts. If you don’t see it, than the whole thing is something new of El Capitan.
Note that I did not have to add any of these:
Pause before the variable declaration
a Semaphore Lock action
It seems your new version runs fine so far, even with small screenshots. But, as said, the whole thing seems to be a timing issue between the first and the second instance of the macro. Since you inverted the file name condition (!^Screenshot) in the new version you may have “accidentally” resolved the issue. But when the macro is run on a different machine (faster or slower CPU/disk) I wouldn’t bet that the issue won’t appear.
With the Semaphore Lock you are on the sure side, since it doesn’t let run the second instance unless the first one (the one from the dot file) has terminated.
Just updated original post with Ver 2.2.
This ADDs the semaphore that @peternlewis suggested to ensure that " the macro will then execute to completion before the next instance is allowed to run. The first one will ignore the dot file because it does not have the right name."
@Tom, thanks for making it clear that the macro needs the semaphore to always ensure proper execution. I had not seen any issues, but others could.
Please give the update a test when you have time and let me know how it goes.
Please give the update a test when you have time and let me know how it goes.
Technically it works flawlessly so far! Just an UI observation:
You can get rid of two superfluous dialog boxes:
Thanks. Please post if you find any issues.
I suppose the button label is a matter of preference. "Delete" is the action, and "Trash" is where it goes. IME, most apps use the word "Delete".
I could eliminate the Delete confirmation, but I have observed users sometimes accidently delete something, not even knowing they clicked on the Delete button. Then they are lost because they can't find their file. IMO, the confirmation is a minor nuisance that can help eliminate this confusion.
Maybe instead of another button for "Save & Open", another checkbox can be added for "Open in Preview".
Of course, the great thing about KM is that each user can take the macro and further modify it to their liking.
Thanks for the suggestions.
I suppose the button label is a matter of preference. "Delete" is the action, and "Trash" is where it goes. IME, most apps use the word "Delete".
No, I didn’t mean only the wording. Of course, you also have to change the action to ‘Trash’:
The Delete action deletes a file, the Trash action puts it into the Trash.
I could eliminate the Delete confirmation, but I have observed users sometimes accidently delete something, not even knowing they clicked on the Delete button.
That’s why I think Trash is better than Delete.
Maybe instead of another button for "Save & Open", another checkbox can be added for "Open in Preview".
These are two clicks. A Save & Open button is one click. And to the buttons you can assign hotkeys(!)
You can do it the same way as with a checkbox. You just have to save the Result Button variable to another variable (e.g. Result Button 1) for later reference, because you have the Rename prompt in between.
But either way is better than a second dialog.
the great thing about KM is that each user can take the macro and further modify it to their liking.
Of course. Already done 
I just proposed these changes because they have advantages for every use case (not just mine). I think nobody likes to click through confirmation dialogs, if not necessary
[I edited the ‘Open Button’ section in my post above.]
Thanks for that. I have changed (but NOT updated my post above yet) both "Delete" actions to "Trash" actions.
However, I think the button should stay as is: "Delete".
I don't see that used anywhere else.
Thanks for your suggestions. However, I disagree with your "for every use case" assertion, and with your "nobody likes to click through confirmation dialogs" assertion.
I have designed the UI the way I think it should be based on my experience with a lot of users. Maybe some will like it, some will not. IAC all can modify it to suit their own liking. It see my post as just a starting point for people to use, not as a final production product.
Feel free to post your own macro with the UI as you like it.
That’s why I think Trash is better than Delete.
I don't see that used anywhere else.
Sorry, not the wording. I did mean: trashing a file is preferable to deleting a file, because for “recovering” a trashed file you only have to move it back from the Trash can. If you delete a file it’s not that easy.
Feel free to post your own macro with the UI as you like it.
Of course.
I didn’t want to offend you. You asked for feedback. These were mere suggestions of improvements that seemed plausible to me. No problem at all if you don’t agree.
I added this macro but for some reason I end up with the full path in my TriggerValue, instead of just the file name. Why? What am I missing?
See Compatibility Notes for KM 7.1:
Folder Trigger now sets TriggerValue to the full path. Adjust macros to account for this.
OK, so I have been working on a regex to strip the filename. While it works just fine in Regex buddy I get an error message when I try to use it in Keyboard Maestro. The regex is
^(./)([^/])$
What is wrong with this? I am running on a mac and I can see the filepath + filename being passed into the regex and it looks like this:
/Users/gary/Desktop/Screen Shot 2016-10-28 at 4.01.38 PM.png
To strip the first path components (before the basename) this should do: .*/
(Then you have the same value for TriggerValue as before 7.1.)
Edit:
In more detail:
%TriggerValue% to a variable, e.g. %Variable%triggerValue%
%TriggerValue% with %Variable%triggerValue%
But if your only purpose is to have all screenshots go to a specific directory, it’s probably more convenient to use this macro. (With it you just set the destination folder for screenshots, instead of moving them around.)
Hey @odin,
Keyboard Maestro has you covered in the Get File Attribute action.
Amongst the many attributes are “File Name” and “Parent Path”.
To answer your original question – you haven't properly populated the variable you're applying the regex to.
Always test first with hard-coded strings you can control and verify.
Generic-Test 01.kmmacros (1.8 KB)
In the case of this macro the variable filePath will not be populated until you run the macro OR right-click on the Set Variable action and select “Try”.
-Chris
