brian@ut-sally.UUCP (Brian H. Powell) (08/21/87)
I sent a letter to Apple concerning several topics, one of which was a request for any information on how to get the anchor point info out of TextEdit. I got a rather unusual reply, which I think needs some discussion. >Brian, > As a general rule, your application should not take any explicit action >when special keys are pressed. Instead, your application should just pass the >key on to TextEdit. This way, when we develop new keyboards (or alternate >input devices), we will also update TextEdit to handle the new keys. > For example, TextEdit now handles the arrow keys correctly. If you >handle the arrow keys yourself, not only are you relying on the character or >key codes of the arrow keys remaining unchanged, but you will also be changing >the functionality of TextEdit with which users are already familiar. It's news to me that TextEdit now handles the arrow keys correctly. It handles left and right arrow correctly. It does not handle up and down arrow correctly, and it doesn't handle the arrows with any of the modifier keys pressed. (If we neglect the option-key, which has application-specified semantics, there are 16 cases to handle (four arrows * no modifiers, shift, cmd, and cmd-shift). Apple got two of them right in TextEdit.) Be sure to read the User Interface chapter of Inside Mac, Volume IV, to learn the proper actions to be taken by the arrow keys. If you think about it, TextEdit isn't powerful enough to implement those guidelines; they'd need two or three more fields in the TERecord to do it right. And then there's the fact that TE on a 128K Mac (and the Lisa) doesn't handle arrows at all, but I don't think Apple really cares about that. If Apple changes the character codes returned by the event manager for the arrow keys, my program will not be the only program to break. What about all those programs that don't use TextEdit and still try to use the arrow keys. Several such programs come to mind: MS-Word, MacWrite, spreadsheets, programming language editors, ... I'm not saying that Apple should set the character codes in stone, but get real: a lot of programs are going to break, and I don't mind if mine is one of them. I'll take that chance. As for the key-codes. I really doubt they'll stay the same. But somehow, I've got to implement shift-arrow and cmd-shift-arrow, and the 64K and 128K ROMs (or is it the keyboard 8021 ROMs?) return certain mathematical symbols (consult your numeric keypad) for those keydowns. (Actually, the Mac-Plus works right for cmd-shift-arrow, but not shift-arrow. The 64K Rom macs don't get either right.) Sooo, my program checks the ROM version number, and if it finds a 64K or 128K ROM, it consults the key-code, otherwise it takes the event manager's word that the character-code is right. As for users being familiar with TextEdit, that's not the point. The point, last time I checked, was to implement the Mac User Interface guidelines. (Or did the U.S.S.R. take over North America? I didn't get to see the news last night.) Let's continue with the letter: > When shift-clicking to extend a selection range, TextEdit considers the >selStart point to be the "anchor". If the user shift-clicks within the >current selection, the selection is reduced to be from selStart to the click >location. If the user shift-clicks past the end of the range, then the new >selection is also selStart to the click location. > Only if the user shift-clicks before the start of the selection are >things different. Then the new selection range extends from the click >location to selEnd. > > I hope this helps, > > Chris Derossi > Developer Tech Support Technoid I disagree with this behavior, but I live with it. Shift-Clicks before the anchor point should select from the click to the anchor point. Shift-Clicks after the anchor point should select from the anchor point to the click. Remember, IM-IV, p. IV-5 says "Once selection begins, the anchor point cannot be moved except by beginning a new selection." To fix this, you have to do some nastiness inside your clik_loop. (You are using your own clik_loop, aren't you? Surely you're not using the ROM's.) I don't think it would be worth it to change this behavior. (Actually, I may try it, just to see if it works.) I've got 8 pages of C code that handles keyboard input. Most of it addresses, you guessed it, arrow keys. It's a pain to implement them in TextEdit, but it can be done. I may put together a medium-sized posting which discusses some of the finer points. Brian H. Powell UUCP: {ihnp4,seismo,ctvax}!ut-sally!brian ARPA: brian@sally.UTEXAS.EDU _Work_ _Not Work_ Department of Computer Sciences P.O. Box 5899 Taylor Hall 2.124 Austin, TX 78763-5899 The University of Texas at Austin (512) 346-0835 Austin, TX 78712-1188 (512) 471-9536
tecot@apple.UUCP (Ed Tecot) (08/25/87)
In article <8821@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: > > I sent a letter to Apple concerning several topics, one of which was a >request for any information on how to get the anchor point info out of >TextEdit. I got a rather unusual reply, which I think needs some discussion. > . . . > As for the key-codes. I really doubt they'll stay the same. But >somehow, I've got to implement shift-arrow and cmd-shift-arrow, and the 64K >and 128K ROMs (or is it the keyboard 8021 ROMs?) return certain mathematical >symbols (consult your numeric keypad) for those keydowns. (Actually, the >Mac-Plus works right for cmd-shift-arrow, but not shift-arrow. The 64K Rom >macs don't get either right.) Sooo, my program checks the ROM version number, >and if it finds a 64K or 128K ROM, it consults the key-code, otherwise it >takes the event manager's word that the character-code is right. There is one major problem with that approach: The user will not be able to use the =, /, *, and + keys on the numeric keypad section of the MacPlus keyboard (as well as the separate keypad that some users have). Why? Because there is no way to distinguish a shift-arrow from any of those keys. This is done not by the Mac ROMs, but by the keyboard (but no longer true for the newer ADB keyboards). My recommendation is to not use shift-arrows; you are asking for trouble. _emt
brian@ut-sally.UUCP (Brian H. Powell) (08/25/87)
In article <1599@apple.UUCP>, tecot@apple.UUCP (Ed Tecot) writes: <Concerning the use of shift-arrow keys...> > There is one major problem with that approach: The user will not be able to > use the =, /, *, and + keys on the numeric keypad section of the MacPlus > keyboard (as well as the separate keypad that some users have). Let me quote from IM-IV, page IV-5. "If the use of Shift-arrow for making selections is more important to your application than the numeric keypad, the following paragraphs describe how it should work." (&c., the following paragraphs describe what shift-arrow is supposed to do.) First of all, the statement by Ed Tecot is not correct, at least in my implementation. My code only looks at the key-codes if the shift-key is held down (and as I mentioned in my previous message, only if the machine I'm using has the 64K or 128K ROMs). On a Mac-Plus keyboard, if the user hits (keypad) '*', he gets an asterisk. If the user hits shift-(keypad)asterisk, he gets shift-right-arrow. On a Mac-Plus keyboard there is some question as to why the user would press shift-asterisk on the keypad. The problem occurs with the old separate numeric keypad. There, the only way to generate an '*', '+', '/', and ',' on the keypad is with the shift-key held down. The quote from IM-IV above applies here. It's more important for the TextEdit portion of my application to support shift-arrow keys than it is to support special characters on the old numeric keypad. So, in conclusion, the only thing my code doesn't support is the special characters on the old separate numeric keypad. On the Plus keyboard, shift-keypad characters can result in shift-arrows, but I consider shift-keypad keydowns to be of questionable use. On the ADB keyboards, and any future keyboards for the SE, II or any future machine, shift-keypad keydowns will result in whatever the event manager feels appropriate. This means that Apple could add, at some later date on some future keyboard, characters to be entered for shift-keypad events, and my program will support them. Brian H. Powell UUCP: {ihnp4,seismo,ctvax}!ut-sally!brian ARPA: brian@sally.UTEXAS.EDU _Work_ _Not Work_ Department of Computer Sciences P.O. Box 5899 Taylor Hall 2.124 Austin, TX 78763-5899 The University of Texas at Austin (512) 346-0835 Austin, TX 78712-1188 (512) 471-9536
tecot@apple.UUCP (Ed Tecot) (08/27/87)
In article <8837@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: >In article <1599@apple.UUCP>, tecot@apple.UUCP (Ed Tecot) writes: > <Concerning the use of shift-arrow keys...> >> There is one major problem with that approach: The user will not be able to >> use the =, /, *, and + keys on the numeric keypad section of the MacPlus >> keyboard (as well as the separate keypad that some users have). > > Let me quote from IM-IV, page IV-5. "If the use of Shift-arrow for >making selections is more important to your application than the numeric >keypad, the following paragraphs describe how it should work." (&c., the >following paragraphs describe what shift-arrow is supposed to do.) > > First of all, the statement by Ed Tecot is not correct, at least in my >implementation. My code only looks at the key-codes if the shift-key is held >down (and as I mentioned in my previous message, only if the machine I'm using >has the 64K or 128K ROMs). On a Mac-Plus keyboard, if the user hits (keypad) >'*', he gets an asterisk. If the user hits shift-(keypad)asterisk, he gets >shift-right-arrow. On a Mac-Plus keyboard there is some question as to why >the user would press shift-asterisk on the keypad. Try again. Pressing the asterisk on the MacPlus keypad looks EXACTLY like Shift-Right-Arrow. Those four keys (=, /, *, +) all force the shift key down. You cannot distinguish Shift-Right-Arrow, Keypad-*, and Shift-Keypad-* on that keyboard. Please try it out before you post. _emt
brian@ut-sally.UUCP (Brian H. Powell) (08/28/87)
In article <3726@apple.UUCP>, tecot@apple.UUCP (Ed Tecot) writes: > Try again. Pressing the asterisk on the MacPlus keypad looks EXACTLY like > Shift-Right-Arrow. Well, you are indeed right. I apologize. I don't plan to change my code; that's what people get for using those obsolete Mac+'s. :-) (make that a double :-) If I decide to add a set of options for the user to set various aspects of the behavior of my program, I'll be sure to include this, but on the whole I think shift-arrows are more important in my program than the keypad is. (This is, of course, highly application-dependent.)