Hi Cor,

Sorry for late answer, got drowned in 3.2 CWSs ...

On Thursday, 2009-09-03 09:06:26 +0200, Cor Nouws wrote:

> Good to see you resolved the issue! *
> (I give my question here, in order not to disturb people in issuetracker  
> while giving applause ;-) )

Well, thank you :)

> I more or less expect that our users have their own spreadsheets  
> properly made up, so that there are no migration issues and we don't  
> have to take any special action to inform them. What do you think?
> Or should we ask UX?

For existing OOo documents there may be an issue with formulas that so
far quietly assumed numeric 0 for textual content and now will produce
a #VALUE! error instead, or a different value if interpretable.
Especially the latter my need some extra care. Users of Go-oo and Debian
based distribution's packages are somewhat familiar with this, as those
versions already interpret strings, though implemented differently, i.e.
accepting everything that a cell input would accept as well, including
all locale dependent issues that I explicitly did not implement on
purpose. As long as the change is prominently announced in What's New
(and users read that, but ...) I don't think additional measures must be
taken. We should be prepared though to receive some alleged error
reports and point the submitters to the change announcement. And your
CT2N extension ;-)


> * Also cause it saves me the task of trying to integrate the CT2N
>   extension, which work has various tricky elements (that I will
>   not have much time for anyway) and in the end would only result in
>   a partly solution.

I still would like to have your extension as a companion though, because
- interpreting strings on the fly of course does have some runtime
  penalty, performance wise
- loading such a document in a different application may still yield
  different results
- strings resulting in #VALUE! will still have to be fixed.

So the CT2N extension still has its value. If it could additionally
detect the origin of a #VALUE! error it would be a most useful tool to
fix such broken documents.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the [email protected] account, which I use for
 mailing lists only and don't read from outside Sun. Use [email protected] Thanks.

Attachment: pgp6ZOCWyRceD.pgp
Description: PGP signature

Reply via email to