I have a window where I want Command-S to save the contents (if dirty). I don’t want to put this in a menu, it’s just a keyboard option. So in the window KeyDown event I trap for this. Works great except for TextFields and TextAreas. In this case, any CommandKey combination send my app an AppleEvent with the parameters
eventClass tsvc
eventID unim
Since I don’t handle these, I return false. But the key combination then is sent to the ether, my window never sees it. I don’t want to have to handle a KeyDown event handler to every text control in the window. Anyone know what’s going on?
I found this ancient thread (2003) describing this problem. The the resolution (returning false from the AE) isn’t working for me.
[quote=153957:@Jonathan Ashwell]I have a window where I want Command-S to save the contents (if dirty). I don’t want to put this in a menu, it’s just a keyboard option. So in the window KeyDown event I trap for this. Works great except for TextFields and TextAreas. In this case, any CommandKey combination send my app an AppleEvent with the parameters
eventClass tsvc
eventID unim
Since I don’t handle these, I return false. But the key combination then is sent to the ether, my window never sees it. I don’t want to have to handle a KeyDown event handler to every text control in the window. Anyone know what’s going on?
I found this ancient thread (2003) describing this problem. The the resolution (returning false from the AE) isn’t working for me.
The solution is to catch the keydown in both the window and every control that catches focus, and in every one of these, all the same method and return true in Keydown.
You can also monitor the keyboard state with System.Keyboard. Without a handler in the controls, though, you will get a beep when Command-S is pressed.
Finally, you could create a menu item with title “” that contains an option with Command S as key. Sure, the user could find it by hovering the menu bar, but in term of code, it is only a menu handler. I do not quite understand why you do not want to make it an option of the File menu, as the Apple Human Interface Guidelines recommend, and as every Mac OS X application around does.
So it’s not a bug in Xojo? The workaround are all ugly.
The vast majority of the time in my app data are saved automatically to a database, there is no user file “save”. I have just one window, in which the user can edit a configuration file, where manual save is done. I don’t want to add a menu just for that. Right now the user is prompted to save when he closes that window. I simply would like to make Command-S do the trick, too (the window dirty dot in the red close button is set, so there is user feedback).
[quote=154032:@Jonathan Ashwell]So it’s not a bug in Xojo? The workaround are all ugly.
The vast majority of the time in my app data are saved automatically to a database, there is no user file “save”. I have just one window, in which the user can edit a configuration file, where manual save is done. I don’t want to add a menu just for that. Right now the user is prompted to save when he closes that window. I simply would like to make Command-S do the trick, too (the window dirty dot in the red close button is set, so there is user feedback).[/quote]
Workarounds are always ugly when you insist on making things more difficult than they are. Should I understand you removed the File menu entirely ? I hope not. It is expected to contain Quit as well. Apple conceived the user interface with a few standard commands which are considered mandatory. The file and edit menu are part of it. Removing them is akin to remove the brake pedal or the fuel intake from an automobile. Workarounds would be terrible in that case as well.
Look at the way Apple manages the dirty text in TextEdit : if text is dirty, the File/Save option is enabled. When it has been saved, it is disabled. As I said, Save is a permanent resident of every File menu in Mac OS X applications.
So what you want to do is to offer Command-S only when text is dirty, and not show it when it is not ? Use the Visible property of the MenuItem to hide it when text is not dirty. The whole idea of the Mac OS X interface is that when a user does not know which keys are available, he can always turn to the menu, and if a command is there, it will tell him, as well as offer to select the action there. Hiding and showing File/Save is the proper way to handle that. Not insisting on using an antediluvian keyboard only command that has been forgotten since the Apple II.
Nothing in particular, I may do that. Thanks for the suggestion.
And since we’re being pedantic, the IIe came out years after the model you cited (1977 vs. 1983). Personally, I bought the Apple II+ in 1980. The Command key of course came with the Mac, and oddly enough, Command-S has not been forgotten, but is found is such apps as, just to pick one, Xojo.
