Oh wise KM community,
After finding a searched item in Prompt with list, selecting shift-return or option-return seems to pick the matching selection the same as return does (whereas cntl-return appears to select the second item in the list). I'd love to branch to different workflows in an Alfred-like manner based on the value of this last selection keystroke. Is it possible to determine the last keystroke entered in selecting to a Prompt with list result?
Thanks!
Oh unwise unwashed masses, (<-- parody)
CTRL-RETURN does not select the second item in the list, at least not for me. For me it does the same thing as RETURN. Maybe I fail to understand your symptoms. Why would it select the second item? Are you suggesting this is a buggy behaviour?
What do you mean when you say "I'd love to branch to different workflows in an Alfred-like manner based on the value of this last selection keystroke." I'm trying to guess what that means because I don't have Alfred. Each character I press in that window causes the window to narrow the number of available items. What other, or what additional, behavior should it be doing?
It might be possible for an asynchronous KM macro to "remember what keys you pressed" while in that dialog box. But I can't write any code until I'm sure what you want.
Thanks so much for the quick response!
I'm not sure why you're seeing a different result for CTRL-RETURN than I am. I don't really care, I just thought it odd behavior.
What I'm trying to do is set a variable to a different value based on whether RETURN, OPT-RETURN, or SHIFT-RETURN is used to select an item from a Prompt with List action.
In the example below, I want to eliminate the ToDo section that prompts to set LocalOperation and set LocalOperation automagically based on the keyboard input used select the item from the Prompt with List action (with RETURN, OPT-RETURN, of SHIFT-RETURN).
Item Search.kmmacros (69.2 KB)
Hi @svinter. I don't think so. However, you can expand the possibilities by detecting modifier states when the Prompt With List choice is made (using return or by clicking).
Here are the modifiers that can be detected:
Here's a simple example:
DOWNLOAD Macro File:
Prompt With List with Modifiers Optionally Pressed.kmmacros (13 KB)
Note: This macro was uploaded in a DISABLED state. It must be ENABLED before it can be run. If it does not trigger, the macro group might also need to be ENABLED.
For a more complex example, see Markdown Link Tool.
I did a test and didn't have any trouble determining the last keystroke. What you have to do is as follows:
This seemed to work for me. But I have an errand to run right now.
Hi, @_jims. Yes, it is the modifier states that I do want to detect, and your macro does just that. Problem solved. Thank you! I'm a little confused why the modifier condition matches after the Prompt operation is complete (as opposed to when it occurs), but obviously, it does!
Thanks, @Sleepy, that's an interesting way to capture the last key, but it was actually just the modifier that I was hoping to capture so I'm good.
And in the process, I discovered the quite useful The text entered in a Prompt with List action which allows me to also grab that actual search string entered.
My mistake. But I suspect that with a very little modification, my macro could also capture the modifier. Since you have a working solution, I won't update my macro.
@svinter, you're welcome; glad I could help.
It's because the KM Engine is faster than your fingers. 
All kidding aside, when you press return (or click an item), the Prompt With List action detects the return (or click).
Then within a millisecond or two the Switch/Case action evaluates local_Choice. Then within another millisecond or two the If Then Else detects that state of the modifiers. All of this occurs before you have lifted you finder from the modifier key(s).
But @svinter, your question does raise an interesting point. Theoretically, if would be better to determine the modifier states first, then use the Switch/Case within each. Here's the above shortcut with that change.
DOWNLOAD Macro File:
Prompt With List with Modifiers Optionally Pressed.kmmacros (19 KB)
Note: This macro was uploaded in a DISABLED state. It must be ENABLED before it can be run. If it does not trigger, the macro group might also need to be ENABLED.
The macro also includes the MILLISECONDS() function four times which are used to generate this:
The race condition created here has my fingers losing to KM every time 
+1 for slow fingers.
If speed was important, you could also try my macro, documented above, and see if it's faster. Step 4 in my macro could be modified to save the modifier key rather than the key itself.
Come to think of it, I'd like to see token in KM called %Modifiers% which returns "lscoacoas" if no modifiers are pressed, and "LSCOACOAS" if all modifiers are pressed. You can probably guess what those letters stand for if you look at the initial letter of each modifier key on your keyboard. Actually, it may be more convenient if %Modifiers% returns this: "0,0,1,0,0,0,0,0,0" because KM allows indexing on this.
Yeah, I agree: a %Modifiers% token would allow it to persist beyond the keypress, and a list would make it easy to access, too.
