https://bugs.documentfoundation.org/show_bug.cgi?id=168409
Michael Weghorn <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #14 from Michael Weghorn <[email protected]> --- (In reply to Jean-Pierre Ledure from comment #12) > Actually a script receives the X, Y, Width, Height values for any button. > However, in se, this info is not very useful. Except when a button is > clicked, activates a script, and a popup menu or alike is desired. > That's why I proposed in comment#9 to pass to the script a MouseEvent > argument. > This would be an IMHO acceptable incompatibility between LO releases: easy > to explain and to fix in existing scripts. Thanks for the additional explanation. It's currently still not fully clear to me how the script hooks up to the events of the buttons, though. > > Do you have any UNO interface (X...) for the underlying button object, or > > only some name/text retrieved from the resource associated with the button? > > > > Since you mention com.sun.star.comp.framework.LayoutManager: Do you possibly > > have a com::sun::star::ui::XUIElement reference from which you can retrieve > > a com::sun::star::awt::XWindow reference of the corresponding button, or is > > only the toolbar available that way? > > TBC ? What do you mean by this? Are you planning to give more details or expecting further info from my side? (In reply to Jean-Pierre Ledure from comment #13) > > accessiblecontext = element.RealInterface.getProperty("XAccessible") > > This is great news. However it works fine in LO 26.2, but not in LO 25.8. > > I tried > accessiblecontext = > element.RealInterface.AccessibleContext.AccessibleParent.AccessibleContext. > getAccessibleChild(1) > > where (1) is hardcoded (should be computed in reality) being the index in > the layoutmanager.XUIElements array related to the concerned toolbar. > This works fine in LO 25.8, but not in LO 26.2. > > => To bypass the current blocking, I can prepare a patch in ScriptForge code > with a few specific lines of code depending on the LO versions: <= 25.2, > 25.8, >= 26.2 Quoting from my comment 6: "As far as I can see, this commit is also not included in the 25-8 branch, but if such a temporary workaround is desirable for now to give more time for finding a better solution, making that approach available for 25.8 as well could be investigated." If sticking to the a11y logic, either having different code for LO 25.8 and master in ScriptForge or backporting a LO commit to 25.8 could be potential ways forward. Does ScriptForge need to be compatible with multiple LO versions at the same time, or is each ScriptForge version tied to a LibreOffice version? (I thought that ScriptForge by now gets bundled with LibreOffice, i.e. is tied to that version. In that case: Wouldn't it be fine for the ScriptForge code of each version to also be specific for a particular version?) > Better idea ? This should work for now, but as I mentioned, UNO a11y API is subject to change, so I wouldn't rely on that in the longer run. Another potential approach I could think of is using the UNO API used by UI tests, similar to what commit 864904e8d04fadb905dc9e22326a7bf0f69d38c7 Author: Michael Weghorn Date: Mon May 26 08:56:43 2025 +0200 sw uitest: Port tdf146145 away from using a11y API did to port an existing UI test away from using UNO a11y API (s. commit message for more details). That UITest UNO API is also unpublished, but it at least doesn't depend on a11y implementation details any more and will likely stay around for now, as it's used in our own UI tests that need to access details about VCL windows (which is exactly what ScriptForge seems to be doing here as well). It also still suffers from the problem mentioned in comment 7, however. As far as I understand, this demo should be doing something similar to your example from the initial description, but using the UITest UNO API: Sub Main Dim I as long Dim windows as Object With GlobalScope.BasicLibraries .loadLibrary("ScriptForge") If .hasByName("XrayTool") Then .loadLibrary("XrayTool") End With doc = CreateScriptService("Calc", ThisComponent) ' ScriptForge (Basic) object toolbar = doc.Toolbars("standardbar") ' ScriptForge (Basic) object toolbar.Visible = True layoutmanager = toolbar._LayoutManager ' com.sun.star.comp.framework.LayoutManager resourceURL = toolbar.ResourceURL ' private:resource/toolbar/standardbar element = layoutmanager.getElement(resourceURL) ' com.sun.star.ui.XUIElement uitest = GetProcessServiceManager().CreateInstance("org.libreoffice.uitest.UITest") toolbarUiObject = uitest.getWindow(element.RealInterface) toolbarItems = toolbarUIObject.getChildren() For i = 0 To UBound(toolbarItems) childId = toolbarItems(i) ' filter: only consider the toolbar item children; their ID starts with "toolboxitem-" prefix = "toolboxitem-" If Left(childId, Len(prefix)) = prefix Then toolbarItem = toolbarUiObject.getChild(childId) state = toolbarItem.getState() For j = 0 To UBound(state) property = state(j) If property.Name = "Text" Then print property.Value EndIf Next EndIf Next End Sub As far as I can see, position/size of the items is currently not available that way, but that could be added (in ToolBoxItemUIObject::get_state), e.g. by adding a "Rect" property (similar to the "Text" one used in the above example) or something like that. Does that sound like a better potential approach/workaround for now? (Due to the nature of depending on implementation details and unpublished UNO API, that approach may still require adjustments in ScriptForge in the future as well and there's no guarantee it will keep working, but not depending on a11y details would in my opinion be a step forward.) @Xisco: Any thoughts on whether using the UITest API from ScriptForge for this purpose would be OK? -- You are receiving this mail because: You are the assignee for the bug.
