Re: [Libreoffice] Advice needed about some 3.4 named range related problem

Hello Noel,

2012/1/13 Noel Power <nopower@suse.com>:
> Hi Guys,
>
> We have a bug here in the suse system that highlights a regression
> attempting to resolve a range by name. Note: this is not a problem on
> master.
>
> the failing macro code is something like so;
>
> Sub test
>    ProjectPlanSheet = ThisComponent.Sheets.getByName( "ProjectPlan" )
>    chkCellControl = ProjectPlanSheet.getCellRangeByName( "TASK3_ON" )
> End Sub
>
> where "TASK3_ON" is a document global rangename
>
> after some digging the commits on master that seem to be involved are
> e9159d142a4f25bff88da3dd90e163135ae0bdfa &
> 9e8ae1d56076474e4673a953d8ebd726cb5daa18
>
> I attach a backport of these patches ( in so far as I could backport them
> with at times quite different code base )
>
> Note: for this bug the patch to rangeutl.cxx seems sufficient, I backported
> the rest for completeness. I want to sound you both out about applying the
> patch either partially ( e.g. just the rangeutl.cxx part ) or even
> completely to 3.4 or... even find out if ye considered either version too
> risky.

I think it makes sense to remove the findByName and replace them with
findByUpperName. The findByName is error-prone and therefore I removed
it for 3-5, internally we only use upper name (and in 3.5 we use it
even to store the range name). I will clean-up your patch a bit
because some changes to rangeutl.cxx only make sense with other
changes in master/3.5.

But before we push this changes to a stable branch I want to check
with backporting the tests from 3.5 to 3.4 and check my other range
name commits from my rework that I did not adjust one of these
patches. Just to make it clear, I don't think that this patch will
create any problems and is safe but I don't feel comfortable changing
such an important part without the tests.

Markus