Using Modifier Keys with Prompt With List

[August]

I'm trying to figure out how to use Modifier Keys with a Prompt With List.

A few weeks ago I pointed out an open question in an old thread:

@August

@ccstone

Peter – why does the Prompt with List action BALK when you hit ⌘Return – but is fine with ⌘ and any of ⇧, ⌃, ⌥.

No one picked up on that question. Could I be mistaken about the feature?

I remember reading a while ago about a change to Prompt With List, that it now keeps track of the modifier keys that were pressed when a selection is made. But now I can't find any reference to that idea, in the manual or in the Forum. Did I make it up in a case of Deja Vu wishful thinking? Does anyone else recall that feature and especially, has used that feature in a situation like this?

Specifically, I have a PWL menu that has some entries which can also be accessed with hot keys, ⌥⌘K, ⌥⌘D, ⌥⇧⌘K, ⌥⇧⌘D. I'm trying to figure out if it's possible to access the first two in the PWL with K and D and the second two with ⇧K and ⇧D.

I think what I'm going to have to do is have the PWL results from K and D treated separately, they can't go directly to the result, they have to be filtered as special cases to determine if they were selected with the ⇧ key pressed. But I can't get started on that because I haven't figured out from the PWL doc how to use the Modifier Keys.

If this is indeed a feature, could someone point to where it's documented?

Thanks.

[griffman]

I'm not sure I completely understand the question, but I use modifiers with Prompt with List a lot, and they "just work." I don't normally use Command, but I just changed one of mine to do so, and it worked:

If I select an item and hold Command when I hit Return, the URL winds up on my clipboard. Is that what you're trying to do? (The Command key, not my specific action.)

-rob.

[August]

Thanks for the real-world example. That helps my thinking about how this might work.

@griffman

Is that what you're trying to do?

I'm trying to have four different entries in the PWL, among many others.

For a limited set of those entries, I want the Shifted choice to be different from the Unshifted choice. I want to be able to pick those options with K, ⇧K, D, and ⇧D so that each results in its own different option result from the PWL.

Right now, pressing K or ⇧K results in the same single option being picked by the PWL, so I think I will have to filter the result afterwards so that if the PWL produces the K result, it checks to see if Shift was held down so that it can change that to the ⇧K option instead.

Where most of the list is automatically generated and can handle 30 or more items automatically, these few where I want modifiers to work because of other mnemonic uses will have to be specially programmed to be caught.

Whatever I do for K can then be duplicated to handle D, etc. but the "whatever I do" part has me stumped.

[griffman]

@August

For a limited set of those entries, I want the Shifted choice to be different from the Unshifted choice.

Yea, I think you'l have to post-process, as I'm doing in the screenshot above. Have an If/Then which is:

IF
    [The Shift modifier is pressed] AND [The Choice = K]
THEN
    Do some stuff

Repeat as necessary for all the other combinations.

-rob.

[August]

@griffman

Have an If/Then which is:

IF
    [The Shift modifier is pressed] AND [The Choice = K]
THEN
    Do some stuff

That simple, huh? OK, I'll give it a try. Thanks.

The IF action with the modifiers options, that's one of the normal IF/THEN conditions, right? Nothing special in the PWL action? The Modifiers value in the IF/THEN is held over from the keystrokes used in the PWL?

[griffman]

Yes, it's a normal If-Then-Else condition; here's the full section from my macro above:

I set a variable's value based on which key was held, then later on, process things differently according to that variable. I could add another condition to the IF that checks the value returned from the prompt as a "all conditions" test, then both would have to be true.

-rob.

[August]

@griffman

it's a normal If-Then-Else condition; here's the full section from my macro

Thanks! This is very helpful.

[griffman]

I just made a super-simple test macro, and it works as I expected.

Prompt with Modifiers.kmmacros (3.5 KB)

Hope that helps!

-rob.

[August]

@griffman

a super-simple test macro, and it works

I'm still trying to grasp the actual sequencing of pressing -- and reading -- the modifier keys in conjunction with the PWL choice so that the immediately following Modifier Conditional can potentially change the interpretation of the PWL result.

You have both "car" and "cat" in your test PWL macro. So typing "c" won't be sufficient to disambiguate them, neither will "ca" be. When you type that much, the PWL will collapse the list to just those entries that match and will show you in the title field which one it will respond with if you press Return at that point.

I think, but I'm not sure, that if you are testing for a modifier key, as you are, and you press any of the modifier keys while you are typing the "c" and/or the "a", you will still get those normal characters typed as the beginning of a choice into the title field and the list collapsed to only the other valid choices.

I think, but again I'm not sure, that the only modifier key press that can be tested by the Modifier Conditional test that immediately follows the PWL is whatever modifier keys are actually being pressed when you press the Return key. (I recall being confused about this before and getting an explanation from @peternlewis, but I can't find it now. So I'm running on vague memory, limited logic, and sketchy understanding.) If I'm right abouy that, you would not be able to pick your "wicked" option and get the special action by typing "⌘w" and Return, you would have to get it by typing "w" and then ⌘Return or "⌘w" and then ⌘Return (or other modifiers on the "w") as long as the ⌘ was applied to the Return.

Is that how it works for you?

I'm trying to sort this out in excruciating detail because I want to be able to use it with
MACRO: “Follow Menu Choice with Return” (v0.5) which automatically generates the Return for me. I am not sure yet what it is going to take to be able to distinguish shifted keys used with the PWL in that context.

It's particularly confusing to try to write about it because the keys are usually named by their shifted characters and that's how they show up in the macro definition. So when a macro defines "K" as a hotkey, it displays the uppercase letter while it actually means the keystroke that produces the lowercase letter. The macro hotkey definitions distinguish between the trigger "K", which usually types a "k" character when it's not triggering a macro, and the trigger "⇧K", which usually types a "K" character. See? Confusing.

The v0.5 vrsion of the "Follow Menu Choice with Return" macro just includes 47 normal keystrokes. But I would like to expand it to be able to accept shifted characters as triggers.

However, if the FMCwR macro simply feeds the PWL a "K" as a shifted character instead of a "k", followed automatically by a normal Return, that Return is not going to be "shifted" and thus presumably is not going to trigger the modifier conditional properly, unless the Shift key just happens to be still being held down from pressing the "K" key and the "Shift" as the initial trigger that gets the macro to type "K" instead of "k".

Or the FMCwR macro can send a shifted Return to the PWL if it has been triggered by a shifted hotkey:

That's what I'm trying to figure out about the dynamics of modifiers and PWLs: If the Shift key is held down while triggering the FMCwR macro, which automatically adds the Return, will that Shift be down long enough to affect the Return and thus be detected by the Modifier Conditions after the PWL action? Or does the FMCwR macro need to send a Shifted Return, and will that do the job?

And both of those options depend on my having guessed right about what's going on with how that Modifier Conditional works, that it is indeed the modifier on the Return that is being tested.

Is that clear, or at least intelligible?

[griffman]

@August

If I'm right abouy that, you would not be able to pick your "wicked" option and get the special action by typing "⌘w" and Return, you would have to get it by typing "w" and then ⌘Return or "⌘w" and then ⌘Return (or other modifiers on the "w") as long as the ⌘ was applied to the Return.

Yes, that's exactly how it works. Command-W is a hot key, and won't be recognized in the PWL typing box. Option and character will type special characters. So you need to select first, then press and hold the hot key while hitting return.

@August

which automatically generates the Return for me

I honestly have no idea how that would work. My first thought is that you'd need to check for all the modifier key codes you want to use, somehow. I have no idea how you'd do that, though. For instance, here's A and ⌘A:

Key Down
	Characters:	a
	Unicode:		97 / 0x61
	Keys:		A
	Key Code:	0 / 0x0
	Modifiers:	256 / 0x100 ⓘ

Key Down
	Characters:	a
	Unicode:		97 / 0x61
	Keys:		⌘A
	Key Code:	0 / 0x0
	Modifiers:	1048840 / 0x100108 ⓘ

(The above output is from our freebie app Key Codes.)

@August

unless the Shift key just happens to be still being held down from pressing the "K" key and the "Shift" as the initial trigger that gets the macro to type "K" instead of "k".

As far as I know, that's the only way the event key conditional test works: The keys must be down (assuming you're using the "Pressed" setting) to be detected. But I assume your macro is sending that shifted "K" to the PWL macro, so the first thing I'd try is just putting the if/then conditional after it, checking for the shift key, and seeing what happens?

If that doesn't work, maybe by doing something with the codes for "key + modifier key," somehow, you could get around that issue.

@August

Is that clear, or at least intelligible?

It's both, but it's also way beyond anything I've ever done with PWL nor am ever likely to do. My only best guesses on how to proceed are above, and there's not much there. I honestly think you might wind up with a list of hundreds of keys you'd have to be checking, somehow ... and all in the name of saving one keystroke for someone who is already typing on the keyboard.

I admit, I don't know all the possible use cases that macro may have, but it seems that wanting to support both "any key" and "any key with modifier" when generating a Return might be very difficult.

Sorry I can't be of more help;
-rob.

[August]

@griffman

My only best guesses on how to proceed are above,

Thanks for even thinking about it.

I've been trying to make this whole thing as "ergonomic" and unobtrusive as possible. I use it possibly 100 times a day, certainly that much when I deep into a project that has both research and testing. I've learned that petty annoyances add up and become a distraction.

Ideally I would make each Desktop Workspace change with a single hotkey, and I have hotkeys set up for my most frequently used spaces. It doesn't interrupt my thought flow and (thanks to my recent implementation of a push-down stack for DeskSpace names) I now have a hotkey for "Previous DeskSpace" which I use a lot as well.

Other spaces I access by menu, and I there are several ways that I can pop up a menu, including a Finder window that has icons for every (in use) Desktop. But my favorite is a PWL that lists the Desktops in most-recently-used order, and that's the one I'm trying to streamline.

I was initially advised that I couldn't pick from a PWL with a single keystroke, but with some hints found in other macros, I figured out how to add the Return automatically. It makes the process enough more comfortable and smoother, not interrupting my thought process, that I really want to see if I can extend it to included modifier keys.

Of course I don't have to. I use K for my KBM Editor Desktop and ⇧K for the Forum and WIki. The actual hotkeys are ⌥⌘K and ⌥⇧⌘K. I could just as well use J instead of ⇧K, I haven't used J anywhere else. But it involves both comfort and esthetics, comfort in simpler and fewer keystrokes, two instead of three, and esthetics in being able to preserve my desired mnemonics, so I want to see if I can do it.

Your macro, your understanding, any your suggestions have given me some directions. Thanks.

[August]

I have some info to add.

If I use a macro like MACRO: “Follow Menu Choice with Return” (v0.5) which automatically generates the Return, and I change the Return character to a Shift+Return,

a Modifier Conditional immediately following the PWL which makes a selection based on that Shift+Return reports that the Shift key is not pressed.

It looks like the above action is sending the character code with its attached modifier while the conditional test is reading from the actual hardware. I'm guessing, of course.

As for my actual problem, I found a way to do what I have been trying to do that does not depend on remembering to use the modifier key with the Return key in a PWL.

My original PWL used a generated list where every entry began with a mnemonic single letter that I could use as the key to the PWL. The flow of a onehanded hotkey to bring up the list, ⌃⌥⇧Z, then typing a single letter choice that is instantly, automatically, invisibly followed by a Return to go to my desired Desktop, has been very easy, almost at the speed of thought.

But in my "new, improved" system, instead of single characters at the beginning of Desktop names set within CurrentKey Stats, I now have filenames that start with things like "[K]..." or "[K⇧]...", which is fine for reading filenames and sorting lists into alphabetical order, but as PWL choices aren't so friendly.

I took my initial macro that adds the return and modified it to add the brackets too. So popping up the PWL and typing "K" triggers the macro that spits out "[K]⏎". The "[K]" matches a single entry in the list so that file is selected, activated, and I pop over to the Desktop where that file is open.

To handle the Shift, I copied that macro with its 47 triggers, edited the XML to change the Modifier field from 0 to 512 so everthing would be shifted, and instead of simply inserting the TriggerValue into the output string, modified it to swap the characters, because that's how they are in my filenames.

The result is that when I pop up the PWL and press a shifted K key, the second macro gets triggered instead and it spits out "[K⇧]⏎". The "[K⇧]" again matches a single, different entry in the list, the file that begins with that string. That file is opened and I pop over to that Desktop.

That's the behavior that I was trying to achieve with the Modifier Keys conditional, as we had been discussing.

By keeping all of the special handling in the triggering macro, each entry has a unique trigger instead of trying to sort out which K entry was actually meant after the PWL choice was made. Much simpler.