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]