If I have a Scrivener project open, when I open the scratch pad and have the focus there, I’m still able to invoke various menu options that don’t make sense for the scratch pad, e.g. (if the focus in the project was left in the editor) inline annotations. Using the keyboard shortcut will turn on the annotations (I’ll see the menu flicker) but have no effect as I’m writing in the scratch pad. However, when I return to the project, inline annotation has been invoked in the editor and the next words I type will be in that format. This happens even if I switch to another application (even in another OS Space) and then back to the scratch pad before invoking the command, so that the Scrivener menu isn’t even visible.
Open a Scrivener project and type some text in the editor, then select the text.
Open the scratch pad and type in a note there.
Hit Shift-Cmd-A
The selected text in the editor receives inline annotation formatting. Typing in the scratch pad continues as normal.
This seems to work with all the commands that would normally be available to wherever you left the focus in the Scrivener project window, e.g. for the editor, highlighting, creating inspector footnotes and comments, taking snapshots, toggling scriptwriting mode; for the binder, move, merge, new document. It…probably should not be the case.
I’ve been looking at this one, and I don’t think it is fix-able - it’s certainly not trivial. It’s down to how OS X handles the responder chain. Basically, you have key windows (the window that has the focus in an app is the key window - not all windows can become key, as some utility panels refuse it) and main windows (not all windows can become main - panels, palettes, side windows and suchlike cannot become main). The way OS X’s responder chain works is this: When you hit a keyboard shortcut or menu item, it first looks at the key window and its controller code, to see if that can do anything with the command. If it can’t then OS X then turns to the main window. In this case, the scratch pad is the key window, but the project window is main; HUD panels cannot become main windows, only project windows. So, OS X is first checking the scratch pad but when that doesn’t respond to a command it’s automatically checking the project window and invoking it there. There doesn’t seem to be a way to tell the responder chain to look no further beyond a certain point (which you wouldn’t want it to do anyway because if the main window and controller doesn’t respond, it looks to the application, so if you stopped it from looking beyond a certain point, then it would fail to respond to messages such as “Show Help” and suchlike).
In fact, you’ll find the very same thing with the keywords HUD and other panels.
I ate ice cream for you!