Hello Miklos, thanks for your message.
Le 16/06/2022 à 12:13, Miklos Vajna a écrit :
I think the root of the difference is that UITests are out of process:
they start a soffice.bin process (with SAL_USE_VCLPLUGIN=svp, so it's
not visible) and then remote-control it.
[…]
Perhaps you can look at CppunitTest_smoketest, which seems to be a
cppunit test that actually spawns a soffice process?
Bingo, hooking in there do give me the accessible tree I'm hoping for,
as with the Python UITest, thanks.
Unfortunately, I'm supposed to write in-process tests [1], so that
wouldn't really be an option. If really it's the only way I'd bring the
discussion and see if that requirement can be lifted, but then maybe I
should just switch to Python directly as it's probably more
beginner-friendly as it's one of the aims of the work I'm on. Anyway,
for the moment that's not the option I'm hoping for :)
Most of our cppunit tests run in-process, using --headless, so if there
would be any dialogs popping up, we would instantly cancel them.
OK, that's an interesting info. However, I'm not anywhere close to
dealing with dialogs or even popups yet, all I'm after is the accessible
objects representing the menu items. This shouldn't require anything to
actually get displayed or pop up.
I guess however that maybe in headless mode the UI is in a degraded
state; would it be possible to trigger loading of the missing bits? Any
idea where to look?
Regards,
Colomban
[1]
https://blog.documentfoundation.org/blog/2021/10/13/tender-to-implement-c-accessibility-tests-202110-01/
