Hi, I am looking at some proposal to improve the uno code in writer. But some definitions surprised me in the API. I started from the definition of a TextContent which is "an object which can be anchored in a text, like instances of TextFrame or TextFields." (see wiki IDL ref.): - The Paragraph service declares supporting TextContent service but its implementation throws an exception if we call the attach method. Moreover, the DevGuide states that a paragraph may not be inserted into a text like other TextContent objects using the insertTextContent method. Shouldn't it be understood as: a paragraph may not be anchored in a text, and thus should not support the TextContent service? - Althoug a mark (e.g. bookmark) may be anchored in a text, it does not own the text it is attached to: you may delete a bookmark without deleting the text it is anchored in, which is not the case for a TextField for example. BTW the definition of the DocumentIndexMark states (see wiki IDL reference) that it "is a TextRange [...]" but inconsistently supports the TextContent but not the TextRange. - A TextRange refers to a Text in a TextDocument. I'm not quite sure of this but I found no way to retrieve the TextDocument from the TextRange using the API (like XTextRange->XText->XTextDocument).
Although this seems to be somehow a kind of "linguistic" discussion, it has the following consequences: - you have to know the precise class of a TextContent to know how to anchor it in some parts of the code, - you have to know the precise class of a TextRange and use some implementation specific methods to retrieve the TextDocument. It is probably some historical reasons that led to this design. And I certainly miss this historical background... But some modifications may make the code simpler (thus easier to maintain) and maybe more modular... So my question is: what is the policy for API modifications and backward compatibility? Regards, Christophe --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
