I'd want to see how it looked in practice, but it seems like a reasonable idea.
On Sep 17, 2010, at 7:24 PM, Chris Bartlett wrote: > On 18 September 2010 05:59, Greg Brown <[email protected]> wrote: > >>>>>> 3. (Improvement / New Feature) >>>>>>> XXX.keyTyped() methods which select the next item matching the >> keypress >>>>>>> should probably >>>>>>> - Move in the opposite direction when SHIFT is pressed >>>>> >>>>> Just as before, it is a continuation of the SHIFT key reversing >> direction >>>> >>>> That's what I figured, but is this a common convention? I have never >> heard >>>> of it before. >>>> >>>> >>> I couldn't tell you of a single place off the top of my head where this >>> does occur, but it was something that seemed natural to my (clearly) >>> perverted way of thinking ;) >> >> I can actually see the utility in it - but if it is not a widely known >> convention, users may not even think to try it, so not worth the effort of >> coding/testing. >> >> I'd rather see some effort go into the wrapping functionality, since this >> is actually a common convention that we don't currently support. >> >> >> > > I was thinking that it might be worth trying to consolidate the way this > kind of thing is handled throughout Pivot as it happens in a number of > places and the resulting code is not especially pretty. > > Something along the lines of > > public static int helperMethod(Sequence<T> items, int startIndex, Direction > direction, Filter<T> filter) > > You would pass it the list of items, a starting point & direction of > 'travel'. > It would take care of the while loops to iterate over potentially the entire > sequence, until it finds an object T which fulfills the required selection > criteria (such as enabled and 'toString() starts with a letter A') > > Possibly also include another boolean parameter to control if it 'wraps' or > ends when it hits the Sequence bounds. > > Chris
