Select of result of search fail to evidence last instance founded

Hello everyone. The following search code with the last select statement should select all found instances of a string.

But the last one does not select it, the viewCursor stops at the beginning of the last instance found, then in the text the last found if you search from the beginning or the first found if you search from the bottom

The only solution for now is to add a dummy string that meets the search criteria to the bottom or bottom of the text.
Is this normal or am I wrong?

Thank you all for any help you have received

d = ThisComponent
 f = d.createSearchDescriptor()
 f.SearchString = "***"
 oF = d.findAll(f):    n=oF.Count

(Please edit your question and append info about your LibO version and your OS.)

That’s clearly a bug, imo. Please report to
As an (ugly) interim workaround you may use the respective recorded macro which works as expected. Of course you will need to assign values to some of the args() by your calling Sub depending on the use case.

(In addition: The SearchDescriptor property .SerachWildcard (introduced with V 5.2, see LibreOffice: SearchDescriptor Service Reference is missing when the SD object is inspected in the IDE in V This may be a related bug.)

Thank you. I have version of libreoffice, SO Ubuntu 16.04 LTS. I also think it’s a bug. By inspecting the oF object, there are alle instances. I also made this request to understand if it was only a problem of my installation / version of writer and to see if the problem was reproduced on other different installations / versions.

I had already tried the registered version which uses DispatchHelper and works perfectly.

Alternatively I will use the trick of inserting an extra dummy string at the bottom, perhaps with a minimum fontsize so as not to highlight it.

Meanwhile, report the bug. If there are no other answers by tomorrow I close the discussion as resolved.
Thank you again.

I tried to report the bug, but when it asks me for the email and password for the login it does not recognize the one I use to connect here.
Do I have to register on the bug reporting site with another account?

I answer myself, I read only now on the site, you need to create a new account on to report a bug

If there are no other answers by tomorrow I close the discussion as resolved

There shouldn’t be. @Lupp is completely right. This is a bug, and I already found where. As soon as you create the bug and mention its # here, I’ll create and push a fix.

The bug should be related to the fact that the current selection always automatically appends a TextRange with empty .String (for the blinking cursor?) to what was actually selected in a text. Object’s .select() method may therefore expect a TextRanges object of the same kind, but .FindAll only returns the findings. One of these may then be rededicated to the “blinker” range automatically …


I’m finishing to test a macro module to select a sequence of single textrange in multiselection mode obtaining a collection of textrange.

The question I asked today was related to a possible application that had a similar problem already observed in this module.

I don’t know if it can help, I tell you about it because I think it has to do with the last observation of lupp.
The problem is the following: the last selected textrange appeared in item 0 of the selection object without however being inserted in a new item, the last, of the selection object

In fact, the manual count of the scanned textrange coincided with the count of the selection object. But the selection object, having also the element 0, had to contain one more element.
To make the last item appear in the selection object, a further selection was needed, obtained with the virtual cursor v with this code:

 if c = d.currentSelection.count then
    v.goDown (1, false)
    v.goRight (0, true)
  end if

Concerning macro usage in the context: As far as I can see TextRanges objects (the relevant services) can neither be created by the document (.createInstance or .createUnoService or …) nor do they provide methods for .add and .remove or similar. This is fundamentally different from how SheetCellRanges and other containers (Shapes e.g.) work, and it makes TextRanges next to useless when programming with the API. I actually don’t understand how a “container” I can nothing put in or take out (dispose) should be supposed useful.

I don’t know if we’re talking about the same thing, but from the tests I’m doing, using macros, the multiselection mode and the goleft / right and goDown / Up methods of the virtualCursor it is possible to partially compensate for the absence of the add and remove methods of the TextRanges object using the selection object as a surrogate.

Currently I have an apparently working module on textrange of paragraphs (but I think it is possible to include tables) with which it is possible to start from a sequence of textrange and using a macro select them all in multiselection.

By saving the final current selection (a selection object with as many items beyond the element 0 as there
are textranges) BEFORE returning to the standard selection mode, you actually get a rudimentary textranges that can be used to re-select all the distinct textrange (for example to limit the range search) or access them in sequence (for example to move around the document using them as bookmark

I don’t understand what you are talking about. The original question had one distinctive property: it was clear. It contained the complete code, and the definition of what is expected and the actual result. Here, starting with @Lupp’s comment about “The bug should be related to the fact”, I don’t see what you are talking about. (Hint, hint!) - maybe just add a separate question.