The text says, "If there is no title and no search string and less than 100 items, then all the items will be shown." But it doesn't work that way. If I have no title and no default search string and 21 items, I see a default title and 14.5 entries.
Clearly the default title takes up just as much space as a text title or default search value and the window is not showing any 99 entries.
“all the items will be shown” in the scrolling list, not necessarily all of them visible on the screen (which would certainly be very difficult if there were 90 items).
"Otherwise no items will be shown until you search for something..." comes as the alternative to "If there is no title and no search string and less than 100 items" -- implying that all three conditions are necessary to have the scrolling list. But lists with titles and defaults can have scrolling lists too.
I suggest, "For 100 or more items, no items will be shown unless there is a default initial search string or until you search for something; then matching items will be shown in the list."
There is nothing in that section which mentions that case-insensitive matching is the rule.
There is nothing on the page which specifies that the choice of entry must be confirmed with a [Return] character.
That requirement for a [Return] character means that the %PromptWithListModifiers% token always and only applies to the modifiers applied to that [Return], which gives you up to 16 recognizable variations on the [Return], even though the string you match before pressing [Return] is case insensitive.
I can't think of any other places where that kind of search is case sensitive. It's a spotlight-like search, and all of them are case insensitive.
Ditto. It's the same behaviour as Spotlight, which should be familiar to Mac users generally.
I do not understand what you mean. You can complete by pressing Return or Double Clicking, but either way the modifiers are the set of up to 4 standard modifiers.
I'm not sure I understand. I think you're saying that you can have any of the 16 combinations of modifiers pressed while you either press Return or double-click on an entry. Is that right?
I was having a little trouble wrapping my head around that because I have been so accustomed to thinking of the modifier keys in the context of hotkeys, where they modify alphanumeric and function keys. I was looking for how to get a user interaction with a PWL choice to select different menu options if the user presses "s" vs pressing "⇧s" ("S").
This is apparently still not possible. Pressing "s" or pressing "⇧s" will get the same menu choice where pressing "⌥s", "⌘s", or "⌃s" does not select any menu choice.
I think it's important to clarify that the %PromptWithListModifiers% token refers only to modifiers applied when either Return is pressed or the entry is doubleclicked. To me, that is not obvious and my intuitions go in an erroneous direction.
Yes - assuming the modified click/Return still does a return, the action will complete and the modifiers are available in the PromptWithListModifiers token.
No, the Prompt With List, like all the Spotlight-like windows, is case insensitive.
That said, you can differentiate it afterwards in the same way as for the modifiers, using the PromptWithListText token.
That is a misconception. Using ⇧S as a hotkey is not "when I type a capital 'S'" -- it's "when I press the 'S' key while the Shift key is down".
Look at the menu shortcuts in eg Safari. "New Window" is ⌘N, "New Private Window" is ⌘⇧N -- and the "N" is always displayed as a capital letter because Apple's HIGs say you should use the same as the key cap that's to be pressed (for some nominal "standard" keyboard, I guess!).
Because in every case you are choosing "s", but you are choosing "s" with different modifiers and you have to test for those to distinguish the different cases. If you want "S", put in the list.
Demo time!
(Brief pause and tumbleweed while I actually install the updated version of KM )
Here's a little macro that'll let you choose from "r", "s", and "t" plus their capitals along with ⌥ and ⇧ as modifiers, then show an "Alert" with your choice and modifiers listed. You'll see that that the selection made when you type in the search box is case insensitive but the case of the list item chosen is respected, and you can test the %PromptWithListModifiers% token to branch depending on the modifiers used.
So from the above you can see you have a choice -- present a list with both "s" and "S" and let the user choose, or just provide "S" and test whether the Shift key was down at the time the double-click or Return keypress happened. (And I say just the capital letter version because of the HIGs and consistency with other areas of the OS and apps.)
Wait a minute. Does this token show the exact text that the user typed in the PWL search field to get the match? So if the user was able to type "s[Return] to select an option, that token would contain a lower-case s and ?
That's not quite the same as making a case-sensitive match, but, like the PWL modifier token, it might be made to work.
)