After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 134627 - Cell indexing with shift-tab navigation
Cell indexing with shift-tab navigation
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
1.2.x
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2004-02-17 13:55 UTC by first
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description first 2004-02-17 13:55:31 UTC
Gnumeric version 1.2.6

Highlight a range for keyboard entry of values, use <TAB> or <ENTER> for
changing cells.  These work fine.  Reverse navigation with <SHIFT-TAB> or
<SHIFT-ENTER> changes cells as they should, but the cell index (box, upper
left of spreadsheet) reads incorrectly after the SHIFT key is released.  It
always contains the cell index corresponding to the upper left corner of
the highlighted range.
Comment 1 Jody Goldberg 2004-02-19 14:18:30 UTC
I can not replicate that behavior with 1.2.6

1) Select B2:D5 by clicking on B2 and dragging to D5 then releasing
2) Use shift-enter repeatedly to walk the cells in reverse
3) Use shift-tab repeatedly to walk the cells horizontally in reverse

the 'cell index' box appears to update for all of them
I tried it pressing individual keys, or using autorepeat.

Can you provide a more detailed example ?
Comment 2 first 2004-02-19 14:47:57 UTC
I repeated exactly the sequence you indicated.  The cell index box
updates fine *during* the reverse navigation (shift key pressed), but
when the shift key is released, the cell index always reads B2 (even
though the highlighted cell may be different).  In forward navigation,
the cell index box and the highlighted cell always agree. 
Comment 3 Jody Goldberg 2004-02-19 15:04:51 UTC
Ahhh, I can replicate it now.
Welcome to why we ask for extreme detail when reporting bugs :-)

This shouldn't be too hard to track. I'll have a look this evening.
Comment 4 Jody Goldberg 2004-02-25 13:48:44 UTC
fixed in both trees
patch will be in 1.2.7 which has not been scheduled yet.