[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KSpread bug (was Re: KOffice-1.2 release schedule)
From:       Philipp =?iso-8859-1?q?M=FCller?= <philipp.mueller () gmx ! de>
Date:       2002-03-24 9:00:12
[Download RAW message or body]

Am Sonntag, 24. März 2002 01:15 schrieb Norbert Andres:
> > > Actually I just had the problem with Ctrl+down this morning  :-(
> >
> > Yes, but I'm on the way to fix it. Ctrl+down works here again.
>
> Do we really need to check the cells until we are at KS_rowMax?
> I think activeTable()->maxRow() is enough (and maxColumn() for Ctrl+right),
> because these values are the maximum of the currently used cells.

No, we don't need to check these values. I included this (quick) fix with all 
columns/rows only for the people already using ctrl+cursor and before it was 
something like a complete freeze by accident.

It wasn't optimized yet, especially as long as I didn't understand all of the 
possibilities. 
And it really needs to be optimized when we will support more than 2^15 
rows/columns. So this is still on my todo list.

> Right now I changed it to use maxRow() instead of KS_rowMax to increase the
> performance, but I can change it back if there is a good reason for the old
> behavior.

Ehm, you didn't get my intention, when I was making this. 
The check for the KS_rowMax was in most cases to ensure that it will never 
count > KS_rowMax (as this is the reference). Therefore even the QMIN in such 
cases.
You may now say, simply ensure that the rowMax is always < KS_rowMax is 
enough, wasn't save enogh to me, as I haven't seen most of the code yet.
In a final version, we/I can remove most of the checks.

But you are right, for the loop to check for the last empty column/row, this 
is a better approach, as we don't need to check the rest (they will be 
empty). Then simply we can jump to the end (KS_maxXXX).

> The other thing about this topic: the last CTRL+right or CTRL+down jumps to
> the last usable cell in this table, but what do we want there?

Simply see that there is nothing (the users will know, that this is the last 
possible column/row). This information is worth the calculation and is 
consistent to EXCEL. 

The other possibilty to simply stop at the end of a column/row may confuse the 
user more, as he used the cursor key and the programm does nothing and 
nothing indicates him directly that this is the last filled cell.

> I changed it so the focus stays in the current cell if below or on the
> right is no other used cell.

Can you change this behaviour back?


Generally:
I wasn't finished with this completely. Currently there is simply something 
more important (the visible area at the end of the columns/rows).

I changed one behaviour with my original commit, which is not consistent with 
EXCEL too:
When you in an empty cell and you move in the direction of empty cells, it 
simply goes to the last empty one. EXCEL in such cases jumps to the first 
filled one. What do you think is better?
With my approach you will be able to easily mark the empty part, with the 
EXCEL approach you more easily jump to filled cells only (because you don't 
stop on the last empty one).

Philipp
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]