Interesting as the times we are living in. This little project revealed so many flaws in the spreadsheet API, that I wonder how I finally got to the point where I dared to publish it.
It started with:
[quote=“Villeroy, post:12, topic:39770, full:true”]
A macro solution would be straight forward, if the required API function would work as expected.
https://bugs.documentfoundation.org/show_bug.cgi?id=159973
[/quote].
Thanks to @Lupp and your pointer to https://opengrok.libreoffice.org/xref/core/include/formula/compiler.hxx?r=fd0cc5b2d352dc4d2c1fd406ec2998e91adbd3a1#SC_OPCODE_PUSH, I began to understand some relevant formula tokens with their OpCodes. Nevertheless, I had to fix broken tokens and loop through all kinds of collections in order to get selectable range objects from tokens.
We can have hyperlink jump marks selecting named ranges in the current document like #SomeName
or #Sheet1.SomeName
or #DatabaseRange
, but I don’t know any way how to follow such links by means of API methods.
The API can resolve string addresses like Sheet1.A1:B5 in all their absolute/relative variants. Either you split the sheet name from the address, and then query getCellRangeByName
from the sheet OR you query getCellRangesByName
from the sheets collection. This was the first project where I tried the second method and found out that the controller can’t select the return value of that method. I had to write another helper function getRangesFromArray
.
Until now, I could not figure out any case where getCellRangesByName
returns more than one range. The returned array always consists of one range. Even if the input is a 3D-reference Sheet1.A1:Sheet3.B7
, the returned array of cell ranges consists of a single range, converted to a collection of SheetCellRanges
, the outcome is a collection of one range Sheet1.A1:B7
.
I did write another work-around converting Sheet1.A1:Sheet3.B7
into a collection Sheet1.A1:B7
, Sheet2.A1:B7
and Sheet3.A1:B7
, but when my spreadsheet controller successfully selects this collection, the sheet tabs do not visually indicate the multiple selection. So I considered, it might be safer sticking with the simple code performing a single selection.
My problem with the context menu wasted some time of try-and-error, but this problem is secondary. I’ll see how I can integrate your code into the next version. First, I’ll have to add a test if the menu item exists already. Then the menu item will be added after the macro has been called for the first time because there is no way to run any code at installation time.