Selection Behavior
I'm absolutely certain that something like this has happened to you. I was putting together some quick and dirty play lists in iTunes based on a random shuffle smart playlist I'd created (basically, a random list of 100 songs that I hadn't listed to in more than two weeks). I'd start on a song, and use <shift>-<up-arrow> to extend the selection to include the songs I want in the playlist.
From time to time, however, I'd go one song too far, and switch to <shift>-<down-arrow> to back off that one song. Only iTunes interprets that action to extend the selection at the song where I started.
I call this "unanchored" selection behavior. In this behavior, <shift> plus any cursor movement always extends the selection regardless of how or where you started selecting using the cursor keys.
And I hate it. I much prefer anchored selections. With an anchored selection, the item or location that was selected when you began extending the selection using a <shift>-<cursor-key> combination is pinned, and never moves. Only the "end" of the selection that you moved using the cursor keys moves.
Note that TextEdit uses anchored selections, as do most other text editors (though not MarsEdit, much to my chagrin). It would seem, though, that the data browser control doesn't "out of the box" as it were. This is really an annoying inconsistency.
So, consider this my personal plea to all software developers (including folks at Apple), please give us anchored selections. Not only would this make all of our applications more consistent, it also gives us fat-fingered users a way to correct our error when we've gone one character, or word or list item, too far.
Rick
Currently playing in iTunes: Passion, Grace, And Fire (Version I) by Al DiMeola
