GNOME Bugzilla – Bug 444610
Only part of cell range highlighted when clicking inside entry toolbar
Last modified: 2007-06-08 04:26:11 UTC
Please describe the problem: When I select a range within a formula (from the entry toolbar), a cell range should be highlighted, which matches the actual range in the formula. I've noticed that whenever the range goes beyond two cells not displayed (because there's no space in the display to show everything), the remaining range is not highlighted when I scroll down the spreadsheet display. While the formula result is correct, that makes it more difficult to access its correctness (as I can't believe that the highlighted area corresponds to the real selected range). Steps to reproduce: 1. make a long vertical series of cells with numbers 2. in the top cell, make a formula which includes many cells which are beyond the visible area of the display 3. scroll down and check if the highlighted cells match the formula range parameter. Actual results: The highlighted area does not match the range in the formula Expected results: They should match Does this happen every time? Yes Other information:
Created attachment 89452 [details] sample gnumeric file which shows the problem I have included the data where I found the bug in this file. I hope it makes the point clear.
Created attachment 89453 [details] screenshot showing the mismatch between formula and highlight Notice the mismatch between formula and highlighted cell range
Interesting, I can not replicate. What version are you using ?
I'm using 1.7.10, in a Gentoo system. I noticed also that if I scroll down, so the intended range is completely out of sight, then click in the formula, then scroll back, nothing is highlighted at all. I'm attaching a text file with the gentoo compile+system information.
Created attachment 89510 [details] System info, with gcc version, etc. Information about my compiling environment (Gentoo). That's the output of the Gentoo-specific command # emerge --info
I can replicate this.
I see it too.
In item_cursor_update, we clip to visible region. I am not sure why. Unrelatedly, in item_cursor_bound_set, it looks like the two sides of && ought to be reversed.
If memory serves me right, there used to be a problem relating to a gtk issue with rectangles that are to large.
#9 : It was a bug in some X servers that would freeze up allocating massive amounts of memory trying to render a cursor for a full column. #8 : agreed. I'll add that to the patch. #1 Ahhh I see, you scrolled down with the scrollbar while editing. The logic here seems wonky. We should be clipping the region in _draw, not in _update. Now I just need to remind myself how this code works.
Looks like we were clipping twice. Fixed for 1.7.11