Association between ToC index object and its paragraph content

[Jens Tröger]

Michael, I the case you describe would I not see the same UNO object address for the same paragraph in the document? But iterating over the ToC’s paragraphs as described previously in this thread, I get for the index view:

    pyuno object (com.sun.star.text.XTextContent)0x7feddb8d2638{implementationName=SwXParagraph, … }

and then for the global document view:

    pyuno object (com.sun.star.text.XTextContent)0x7fedd9f5f598{implementationName=SwXParagraph, … }

for the same first entry paragraph in the ToC. In fact, if I instantiate the ToC’s text range three times, then I get three different objects for the first paragraph:

    pyuno object (com.sun.star.text.XTextContent)0x7fc6b1d41188
    pyuno object (com.sun.star.text.XTextContent)0x7fc6b1e66968
    pyuno object (com.sun.star.text.XTextContent)0x7fc6b430e288

Do paragraphs have another unique identifier that associates these different instances as objects representing the same document paragraph?

Jens


> On Dec 12, 2017, at 22:27, Michael Stahl <mstahl at redhat.com> wrote:
> actually you can, because the SwXParagraph instance is cached, so if
> such an object already exists at the time when a new one is to be
> created the existing one is reused.
> 
> in C++ you can compare that via just 2 css::uno::Reference<...> and
> operator==, not sure how other UNO language bindings compare the object
> identity, but it should be possible.
> 
> the only exception to this is if there is a paragraph enumeration that
> partially selects a paragraph - those are never cached.
> 
> (also, not every UNO document  model service in Writer implements such
> caching.)

--
Jens Tröger
http://savage.light-speed.de/