Created attachment 150516 [details] Example file with macro to examine the shape properties If you inspect a shape via macro, you will find the property "AnchorPosition". I see these problems: 1) If you change the zoom, you get different values for the X coordinate but not for the Y coordinate. 2) 'AnchorPosition' exists in the API only for legend, but not for shapes. 3) The values in AnchorPosition make no sense. Expected behavior: The values in AnchorPosition are in unit 1/100 mm, same as all other values. The values in AnchorPosition are independent from zoom. 'AnchorPosition' + 'Position' = 'Left or 'Top' respectively, so that 'Left' and 'Top' describe the distance from the page edge. Type 'Anchor to page' results in 'AnchorPosition' (0|0). The attached file contains the macro FrameRectWriter, which works on a selected shape. You can use it to examine the current behavior.
It seems, that 'AnchorPosition' is measured from the edge of the content area of the window? If that is indeed so and intended, it should be documented in the API.
@Regina, would you mind asking for more info in the dev list ?
(In reply to Xisco Faulí from comment #2) > @Regina, would you mind asking for more info in the dev list ? Done. https://lists.freedesktop.org/archives/libreoffice/2019-May/082677.html Answer: https://lists.freedesktop.org/archives/libreoffice/2019-May/082682.html
(In reply to Regina Henschel from comment #3) > (In reply to Xisco Faulí from comment #2) > > @Regina, would you mind asking for more info in the dev list ? > > Done. https://lists.freedesktop.org/archives/libreoffice/2019-May/082677.html > Answer: > https://lists.freedesktop.org/archives/libreoffice/2019-May/082682.html Thanks. Moving to NEW then...
Dear Regina Henschel, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The API is still not improved. Tested with 7.2 SDK from 9. Apr. 2021.
Dear Regina Henschel, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The requested info is still missing in LibreOfficeDev_7.6_SDK.
Miklos has related the property "AnchorPosition" to the method SdrObject::GetAnchorPos() in his answer https://lists.freedesktop.org/archives/libreoffice/2019-May/082682.html I think, the property "AnchorPosition" is not related to SdrObject::GetAnchorPos(). Two different shapes in a text document have the same values for "AnchorPosition", whereas GetAnchorPos() returns the m_aAnchor member of the individual shape. Using the now available tools "Development Tools" I see this: The property "AnchorPosition" of a shape reflects the properties Document > ViewData > ViewLeft and ViewTop. As it is a document property is makes sense that it is readonly at the shape. The document properties ViewLeft and ViewTop do not react immediately in the Development Tools, when the view in the application window changes. You need to save the document with the changed view to actualize the properties. The property "AnchorPosition" of the shapes in the Development Tools reacts immediately on a changed view. So it boils down to the question, "What is contained in ViewLeft and ViewTop?" In file format they are config items in settings.xml.