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

List:       koffice-devel
Subject:    Re: Matrix handling in KSpread ?
From:       Tomas Mecir <mecirt () gmail ! com>
Date:       2005-08-19 12:45:18
Message-ID: 492258b105081905457deb41c6 () mail ! gmail ! com
[Download RAW message or body]

On 8/19/05, Ariya Hidayat <ariya@kde.org> wrote:
> > Hmm, as far as I understand it, and the OOo saves I've seen support
> > it, {} are only visual stuff displayed to show that it's a range
> > formula - the parser however doesn't see them.
> 
> This is true, but when you mark the cells, the formula bar shows
> also the {}. If the formula object only stores the version without {}, then
> you need to append those {}, which requires checking whether this is
> an array formula or not.

Hm, I'd say, only append the {}s in the displaying code in
KSpreadCell, nowhere else ... Then this will be solved.

> See above. When you mark any of the cells in this array, the same formula
> is shown (which makes sense, this cues the user of the situation). If you
> store INDEX(), then it is not really compatible.
> Of course this can be solved again by changing the displayed/for-editing
> formula depedent on whether this is a simple formula or an array formula.

Aye, that's not a big issue, plus we surely don't need to create a
100%-exact clone, do we ? ;)

> > - KSpreadCell: add some attributes (in CellExtra) pointing to the
> > first cell of a matrix, if any.
> 
> Perhaps the formula class is the best place for this? The first/anchor cell
> is not needed anyway if the cell does not contain formula (we save a pointer).

Hmm, maybe ... But this is not really related to formulas ... I'd like
to see these separated from the whole array stuff ... No reason to
clutter all the classes with this thing ...

> IMHO the check-and-barf-on-error should be done in the KSpreadView or whatever
> that triggers the action. setCellText should just ignore (or give an "error"
> returned value) if operation should fail.

Well, there are about three zillions of places that trigger an action
- they are everywhere. And I mean everywhere. Most dialogs and stuff.
The only common place is that endOperation() thingie, so I'll probably
put it to there, and then we'll move it somewhere else when the cell
damaging stuff and related concepts are ready.

> IMHO it should barf again if the range to be deleted does not include
> the whole array.

Hmmm ... I almost feel like we need something like about-to-modify
signal, which provides the range, and which would be called from all
the zillions places that want to modify something, else the whole task
will be unbearably difficult. Hmph.

> > - oasis loading/saving: if the cell isn't top-left, save as if it
> > didn't contain any formula, same for loading. For top-left cell, save
> > using the necessary tag (as I posted earlier), upon loading, prepare
> > all cells in the matrix.
> 
> For saving, ensure that you handle the top-left cell first before any other
> cells in the range.
> For loading, check that subsequent load of others cells does not override or
> conflict their contents which are set in the loading of top-left cell
> beforehand.

Only the cell-is-in-array is set here, values themselves are set when
the particular cell is loaded.

> KSpread 1.4 does not support array formula, so it can be ignored. For example,
> just save the calculation result.
> However, you could also extend the KSpread's XML to support array formula,
> in such a way that it will be still backward-compatible (KSpread 1.4 or older
> can still read it, albeit without array formula support).

Not sure if I want to start dealing with that XML stuff ... The
load/save code always gives me a lot of headaches. Lotsa XML
manipulation...

> > - when a part of a matrix is about to be modified, the can't-do-that
> > message will show up for each cell. This is bad. What to do?
> 
> Why does it show up for each cell?

If it's handled in setCellText, then yea. That's why some other place
must be found.

> > - how to handle undo/redo? We'll somehow need to remember the matrix stuff ...
> 
> Essentially, as long as upon undo you restore the cell's content to its
> previous value, then you're set. Or am I missing something?

Well, setting KSpreadValue is not enough, because that doesn't store
information about whether the cell is a part of an array or not. That
was the question - how to adjust undo to support these things, without
breaking everything else, if possible :)

/ Tomas
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

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