To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=84979
User er changed the following:
What |Old value |New value
================================================================================
Target milestone|--- |OOo 3.x
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Mon Jan 7 18:59:58 +0000
2008 -------
> What is very cleat ro me is that whoever coded this up did not start by
> getting
> a stable logical functional specification, physicalising it and the
> refactoring
> it before moving onto design and implementation. This whole area of
> functionality it a mess.
Please let's stick to the topic of this issue and not theorize about the
history of implementation.
> You are not going to sort it out as a 3.x release.
> You need a consistent detailed specification before you can sort this out so I
> think that this is a 4.0 issue.
I doubt that there is need for a much detailed specification. The method
has to assure that a generated name does not clash with any address
convention OOo supports, hence the attempt to do this via the Parse()
methods. What the Parse() methods need is a return flag to indicate
whether all input was digested, and/or not set SCA_VALID if that was not
the case. Needs to be checked with already existing semantics of other
callers of course. What the caller here in this case does wrong is that
it doesn't check the return flags at all, but converts them to a boolean
instead.
Furthermore the Parse(,,CONV_XL_...) methods seem to need some fixing if
with A123:B124 aRange.Parse(,,CONV_XL_A1) returns 0xC700, where
SCA_VALID_ROW2 and SCA_VALID_COL2 are missing.
> What you could do in 3.x is a minimum change to
> disable some of more bizarre aspects.
What else do you think is necessary than what I mentioned?
> I will make some note on what I regard as a sensible FS. I wouldn't attempt
> to
> try to fix this tangled code "bottom up". One options might be to disable all
> bar OOO parsing for 3.1. Thoughts?
I don't quite understand what you mean by "disable all bar OOO parsing".
Probably "disable all but OOo parsing" instead? That's not really an
option, because then later on when we wanted to support the other
address conventions we might have clashing names in already existing
documents. And as mentioned, patched go-oo releases do already ship with
R1C1 address convention activated in the UI.
If you do have some better approach than fixing Parse() and caller then
please don't hesitate and submit a patch.
Thanks
Eike
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
