brian@ut-sally.UUCP (Brian H. Powell) (07/14/87)
I'm trying to implement shift-arrow and cmd-shift-arrow (and probably
eventually option-shift-arrow) keys in a TextEdit window. The details of how
these guys act are discussed in the User Interface chapter of IM-IV. I'm
concerned about how to determine where the Anchor point is. What would be
best is if the TE record had a field for it, but it doesn't.
In case you don't see what the problem is, let me discuss it. Suppose
the user uses the mouse to select a range of text sweeping the mouse from the
start of the selection to the end. How does one know that the selStart field
(of the TE record) is the anchor point and the selEnd field is the active end?
Actually, one doesn't, and that's the problem.
One solution (the "ideal" solution?) is to act like this: (let the
carets beneath the line delimit the selection range)
We start with a line with a selection made by the mouse:
Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner
^ ^
and after a cmd-shift-left-arrow:
Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner
^ ^
and after a cmd-shift-right-arrow:
Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner
^ ^
and after another cmd-shift-right-arrow:
Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner
^ ^
In other words, it leaves the original selection there and works around
it. Any comments? This seems like the nice thing to do in this situation.
Now about implementation... I'm slowly resigning myself to the fact that
I'm going to have to keep track of the character that preceded the current
character, as well as where the selection range was when we started. I can
use this information to help me decide how to collapse selections. As a
pleasant side-effect, I can now implement the up & down arrows correctly (as
opposed to the way the 128K ROM TextEdit does it) where successive up/down
arrow movements stay as close as possible to the original cursor position.
(See IM-IV User Interface for that rule.)
Any comments on this?
Thanks for any assistance.
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-9536oster@dewey.soe.berkeley.edu (David Phillip Oster) (07/17/87)
1.) Thanks to Apple for fixing the keyboard! On a MacPlus, the shifted
arrow keys produce an EventRecord identical to the ones produced by
*,\,-,= on the numeric keypad. On the Mac SE and MacII, the shifted
arrow keys produce an EventRecord identical to the un-shifted arrow
keys (same ascii and keycode), but the shift bit is set in the
modifiers field of the EventRecord. This is just the right thing.
2.) The Human Interface Guidlines Notes released to devlopers gives
suggested standard behavior for the <Home> and <End> keys on the big
keyboard. What do keydown events for these keys look like? (Someone
one who has done the experiment, please respond.)
3.) The Human Interface Guildines chapter of Inside Macintosh Volume 4
gives a complete description of what the arrow keys should mean, and
how that meaning should chainge in the presence of shift, command, and
option modifier bits in the event record. Interestingly enough, I have
never seen a product that implements these guidlines. MPW and the
Dialog Manager both mess up in a number of points. Are these
suggestions still the bible?
4.) Brian H. Powell asked about anchor points in regard to these text
edit points. Brian, you _already_ had to keep track of whether the
start or end of the text edit record was changing: Suppose the user
clicks and drags off the edge of the window. The window has to
auto-scrolll. You are responsible for updating the scroll bar. Now,
what do you show? At the time your scrollbar update code gets called,
all you have are the current start and end of the selection. If you always
scroll to make the start of the selection visible, then you'll do the
wrong thing for scroll downs. If you always scroll to make the end of
the selection visible, then you'll do the wrong thing for scroll ups.
You could look at the mouse position relative to the current window,
but it is more robust just to always keep around the previous
selection start and end, and compare them against the current to see
which has changed more.
--- David Phillip Oster --My Good News: "I'm a perfectionist."
Arpa: oster@dewey.soe.berkeley.edu --My Bad News: "I don't charge by the hour."
Uucp: {seismo,decvax,...}!ucbvax!oster%dewey.soe.berkeley.edubrian@ut-sally.UUCP (Brian H. Powell) (07/17/87)
In article <19741@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David Phillip Oster) writes: < 4.) Brian H. Powell asked about anchor points in regard to these text < edit points. Brian, you _already_ had to keep track of whether the < start or end of the text edit record was changing: Suppose the user < clicks and drags off the edge of the window. The window has to < auto-scrolll. ... < You could look at the mouse position relative to the current window, < but it is more robust just to always keep around the previous < selection start and end, and compare them against the current to see < which has changed more. I'm not exactly sure what you're describing here, but I'm pretty sure I disagree. I look at the mouse position: if the mouse is below the window, I scroll down a line; if it's above the window, I scroll up a line. (except of course for the boundary conditions at the beginning and end of the file.) TextEdit takes care of the anchor point for me. If I'm understanding you correctly, I don't think your solution works if the user has already selected everything on the current page. If the user moves the mouse below the window, the selection hasn't changed so you won't scroll. But let me reiterate that I don't really understand exactly what you're describing. < 1.) Thanks to Apple for fixing the keyboard! On a MacPlus, the shifted < arrow keys produce an EventRecord identical to the ones produced by < *,\,-,= on the numeric keypad. On the Mac SE and MacII, the shifted < arrow keys produce an EventRecord identical to the un-shifted arrow < keys (same ascii and keycode), but the shift bit is set in the < modifiers field of the EventRecord. This is just the right thing. Thanks for this info. I agree that Apple has finally done the right thing. Does this mean that all future keyboards will be this way? I hope so, and I probably plan to assume so. (No, Apple, don't burn me.) This probably opens up a means of supporting shift-arrow keys on all mac keyboards (without giving up the keypad), but I'll have to think about it for awhile to be sure. < 3.) The Human Interface Guildines chapter of Inside Macintosh Volume 4 < gives a complete description of what the arrow keys should mean... < Interestingly enough, I have < never seen a product that implements these guidlines. There are some that come close. I think Apple made the guidelines before they tried to implement them. They are certainly logical semantics, but they aren't very easy to implement fully. I'm trying, though.
jww@sdcsvax.UCSD.EDU (Joel West) (07/18/87)
In article <19741@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David
< 1.) Thanks to Apple for fixing the keyboard! On a MacPlus, the shifted
< arrow keys produce an EventRecord identical to the ones produced by
< *,\,-,= on the numeric keypad. On the Mac SE and MacII, the shifted
< arrow keys produce an EventRecord identical to the un-shifted arrow
< keys (same ascii and keycode), but the shift bit is set in the
< modifiers field of the EventRecord. This is just the right thing.
Actually, I think this is fixed on System 4.1 and the Plus, which has
the new _KeyTrans trap used for the ADB keyboards on the SE and II.
In MPW 2.0b1, command-up-arrow and command-shift-up-arrow have distinct
meanings and they both seem to work.
--
Joel West, Palomar Software, Inc. (c/o UCSD)
{ucbvax,ihnp4}!sdcsvax!jww or jww@sdcsvax.ucsd.eduearleh@dartvax.UUCP (Earle R. Horton) (07/19/87)
In article <8503@ut-sally.UUCP>, brian@ut-sally.UUCP (Brian H. Powell) writes: > In article <19741@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David > Phillip Oster) writes: > > < 1.) Thanks to Apple for fixing the keyboard! On a MacPlus, the shifted > < arrow keys produce an EventRecord identical to the ones produced by > < *,\,-,= on the numeric keypad. On the Mac SE and MacII, the shifted > < arrow keys produce an EventRecord identical to the un-shifted arrow > < keys (same ascii and keycode), but the shift bit is set in the > < modifiers field of the EventRecord. This is just the right thing. And thanks, Apple, for selling me this piece of junk I am stuck with until I finish graduate school and find gainful employment! Oh, and thanks, Apple, for offering no way to fix it! So... 1) Thanks to Apple for NOT fixing MY keyboard! I suppose I shouldn't complain. At least both my disk drives operate at the same speed. -- ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************