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 77321 - Incorrect range outlining during eqn editing
Incorrect range outlining during eqn editing
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: GUI Expression Entry Widget
1.0.x
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2002-04-02 07:07 UTC by Jason Mancini
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jason Mancini 2002-04-02 07:07:16 UTC
Cell C1 contains "=sum(c3:c99)"
Click on the cell so the equation shows up in the edit box.
Click on the "c3:c99" portion of the equation in the edit box.
A red outline box is rendered onto the spreadsheet.

Scrolling down reveals that only c3:c28 has been "redboxed",
where it should have extended down to cell c99.

(It appears to red-box only just past the bottom edge of the
screen.  So if I unmaximize, the red-box stops even sooner.)
Comment 1 Jason Mancini 2002-04-02 07:13:10 UTC
After entering "=sum(c3:c99)" into cell C1, select C1.
Scroll down to C99.
Click in the edit box on "c3:c99".

Nothing highlights at all.
WHILE still in this edit mode, scroll back up to A1 location.
Change the cell range to anything on the screen,
nothing gets highlighted ever -- highlighting fails entirely.

Comment 2 Andreas J. Guelzow 2002-04-02 19:30:44 UTC
This is definitely related to the expression entry widgets (and it's
sheet support)
Comment 3 Andreas J. Guelzow 2002-04-04 06:24:31 UTC
I was mistaken. It seems to be a scrolling problem: other cursors
(selections) are being relocated and redrawn as we scroll while the
red outline is not. We do not always draw the whole selections because
we would run into overflow situations since there are 65000+ possible
rows.

The same problem occurs with horizontal scrolling.
Comment 4 Andreas J. Guelzow 2002-04-04 07:27:02 UTC
I believe I fixed the second part of this problem in cvs-head, ie. it
will be in the next 1.1.x release.

The scrolling problem is still there.
Comment 5 Andreas J. Guelzow 2002-04-05 00:55:16 UTC
This turned out to be a near-trivial fix in src/gnumeric-pane.c
(gnm_pane_reposition_cursors). Committed to cvs-head. This fix will be
in the next 1.1.x release.

Jody, should we backport the fix to the scrolling problem?
Comment 6 Jody Goldberg 2002-04-05 08:46:10 UTC
Yes, that fix looks simple enough that we can be sure it will not screw other things up.