Hi Noel, So, in a calm minute now.. sorry for the long gap, that UI/feature freeze nearing is always distracting ;)
On Wednesday, 2007-10-24 17:08:18 +0100, Noel Power wrote: > But there seems to be ( possibly ) be a bug in the > > lcl_ScRange_Parse_XL_Header which it seems will always sets some > SCA_VALID...2 bits e.g. > > nFlags |= SCA_VALID_TAB2 | SCA_TAB2_ABSOLUTE - ( if only only single > cell address with sheet ref e.g. Sheet1!R1C1 ) > > or > > nFlags |= SCA_VALID_TAB | SCA_VALID_TAB2; - ( if just something like > R1C1 is passed ) > > otoh the comments ( certainly for the 'Sheet!R1C1` case seem to indicate > this is intentional ) Looks strange indeed. As lcl_ScRange_Parse_XL_Header() is a subroutine of lcl_ScRange_Parse_XL_A1() and lcl_ScRange_Parse_XL_R1C1() that may as well be some internal precondition needed for the code following it, I didn't dive into that and whether those functions may return valid range bits if in fact there was no range. I think that setting the flags before really having encountered the condition they express may be confusing (as we just have seen), given the complexity of the R1C1 case it might ease things a lot though. Jody could tell ;-) As the code isn't executed in upstream OOo yet, your bug tracking system might indicate whether there's something wrong with it and single references being erroneously treated as ranges in some cases. > so I changed the routine ( once again ;-) ) while this uncertainty > exists > > > - USHORT nRes = aRange.Parse( aOne, pDoc, eConv ); > + USHORT nRes = aRange.ParseAny( aOne, pDoc, eConv ); > + USHORT nEndRangeBits = SCA_VALID_COL2 | SCA_VALID_ROW2 | > SCA_VALID_TAB2; > + // nRes & (SCA_VALID_TAB | SCA_VALID_COL | > SCA_VALID_ROW | > SCA_TAB_3D | SCA_TAB_ABSOLUTE | SCA_ROW_ABSOLUTE | SCA_COL_ABSOLUTE); > + USHORT nTmp1 = ( nRes & 0x070f ); > + USHORT nTmp2 = ( nRes & nEndRangeBits ); > + // If we have a valid single range with > + // any of the address bits we are interested in > + // set - set the equiv end range bits > + if ( (nRes & SCA_VALID ) && nTmp1 && ( nTmp2 != > nEndRangeBits ) ) > + nRes |= ( nTmp1 << 4 ); > + > if ( (nRes & nMask) == nMask ) > Append( aRange ); > > the above expects that a valid ( non-single ) case will have at least > nEndRangeBits set - that I think is not an unreasonable assumption given > ScRange::ParseAny tests the same bits in order to decide to try parsing > an address. That should be fine. > (p.s. I didn't forget about the suggestion for a define for 0x070f, it's > just I don't want to trigger a ripple re-compile right now ) With ccache it takes just 30 minutes or so ;-) 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 this [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks.
pgphOjU5dnA9t.pgp
Description: PGP signature
