To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=84979
------- Additional comments from [EMAIL PROTECTED] Sun Jan 6 16:08:45 +0000
2008 -------
The enum convention (address.hxx:255) defines 5 types (CONV_OOO, CONV_XL_A1,
CONV_XL_R1C1, CONV_XL_OOX, CONV_LOTUS_A1). ScRangeData::MakeValidName
enumerates over these calling ScAddress::Parse and ScRange::Parse as object
methods with two acquisition objects: aName and aRange.
The main logic flaw is that these Parse functions process the range name
left-to-right returning a USHORT containing SCA_FLAGS (see address.hxx:201 et
seq) which indicate which component parts of a range have been decoded. There
is no flag to indicate that garbage is found after the range reference.
However, ScRangeData::MakeValidName treats them as a simple boolean. Hence if
any of the parse methods see a fragment reference then this is treated as a
match and the _ prefix is applied.
Incidentally these parse methods only decode for CONV_OOO (the default),
CONV_XL_A1 and CONV_XL_R1C1 so CONV_OOO is called 3 times, and as the match
routine does not quit on first match, multiple transformations can occur. For
example, in the case of
A123:B124 aRange.Parse(,,CONV_OOO) returns 0xF700 resulting in A123_B124
aRange.Parse(,,CONV_XLA1) returns 0xC700 resulting in _A123_B124
Because this is processing 10 parse routines which could (partial) match under
various conditions we get the bizarre variants described in the original post.
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. 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. What you could do in 3.x is a minimum change to
disable some of more bizarre aspects.
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?
---------------------------------------------------------------------
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]
