Created attachment 54064 [details]
Compare testcase with 3.4 and 3.5. In 3.5 Results = Sheet.findAll(SearchDescriptor) always returns 1 element in 3.5 (if anything found). Results(0).AbsoluteName is the whole sheet.
I can confirm that the results are different in 3.4.4 and 3.5.0
Your macro seems to be looking for number 3 in the whole spreadsheet (I can't confirm if your macro is correct because I'm not an expert in Basic Macros).
While version 3.5.0 reports 1 result, version 3.4.4 reports 6. But there are 7 visible cells containing value 3, so both results are wrong...
(In reply to comment #1)
> While version 3.5.0 reports 1 result, version 3.4.4 reports 6. But there are 7
> visible cells containing value 3, so both results are wrong...
No, the result in 3.4.4 is right, because the results with adjacent cells are grouped together into 1 result. See screenshot.
Created attachment 54109 [details]
There is an extension with which you can navigate through results: http://extensions.libreoffice.org/extension-center/search-in-calc
This extension freezes in LibO 3.5, because it tries to do Results(0).DataArray, but because DataArray is huge (Results(0) is the whole sheet), it freezes the program forever.
For me already [Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 5d1a991-4cb1bac-ca7e6f5-9125509-ce71330)]" (111109), so not a particular Beta0 problem.
Was ok (result=6) with Server installation of Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI
82ff335-599f7e9-bc6a545-1926fdf)]" (in July 2011)
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
I don't think that this is a problem in basic, instead it is more likely a problem either in calc core or in calc's uno implementation.
Let me see if I can add an api test for the problem and check if there has been an old java based api test which is disabled.
markus, push it back to me if not an api/core prob, thanks!!
Can reproduce this problem.
I will add a test to sc/qa/extras in some minutes showing the problem and debug it.
Ahh! This error was dumb. I forgot to adjust this part while switching the ScMarkData behavior. We now pass the ScMarkData as const and the found range is stored in another variable.
Will push the fix to master and ask for review for 3-5 and 3-5-0.
fixed in master with http://cgit.freedesktop.org/libreoffice/core/commit/?id=b0af6fd51c644827593f3d69c46dc8074dca0ee3
OK in LibO 3.5.0rc3
Light needs vary depending on the tree species, so you’ll want to check your specs. https://tutuappx.com/