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 <mst...@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/
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
