On 08/08/08 17:30, Cor Nouws wrote:
When Calc will generate an error for such cells when used in
arithmetic operations, it would even be possible to enhance the
extension to make use of the detective to track down the source of the
error and point the user to original problem.
Yes that would be possible. Plus that it would speed up the work of the
extension :-)
That would be closer to the proposed "potential errors" component (see
http://wiki.services.openoffice.org/wiki/Summer_of_Code_2008/proposals,
http://wiki.services.openoffice.org/wiki/Community_Innovation_Program/proposals).
Few remarks:
1 The bells and whistles have a lot to do with strange situations that
people want to have solved. Mixed use of decimal separators, for
example... (but I read in your last paragraph, skipped in this mail,
that you know enough causes of textual numbers).
2 Quite some digging is done to prevent unwanted conversion of certain
numbers to dates.
(So the generated error might need to distinct between various situations.)
Without examining formulas, I think your extension offers the options
that would usually be needed.
The problem is, it may be fully intentional to have a text like "1.2" in
a spreadsheet, referring to some book chapter, or software version, that
shouldn't be replaced by a number, even if the dot is the decimal
separator. If you know how the cells are used in formulas, you still
can't reliably detect these cases, but it gives another hint.
Then, there's also the issue of textual formula results, like a date
constructed as =A1&"/"&A2&"/"&A3, but of course a single component can't
solve all the world's problems.
Niklas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
