Added a set of UNO accessibility roles for specific kinds of
documents:
* DOCUMENT_PRESENTATION for Impress
* DOCUMENT_SPREADSHEET for Calc
* DOCUMENT_TEXT for Writer
The other applications still use the existing DOCUMENT role.
These roles translates directly to ATK but in the other toolkits we
keep using the same association that DOCUMENT role had.
Change-Id: Ibac47527e5effdecb28d2314cde8558cf4fb010a
Reviewed-on: https://gerrit.libreoffice.org/7847
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
interface methods do not check for NULL pointer access, nor do they trap
exceptions
Fixed by Michael Curran
(cherry picked from commit 113171f2a5d726af6c5266e98e8e790ac6729d2d)
Conflicts:
winaccessibility/source/UAccCOM/MAccessible.cxx
Change-Id: I28d4b885a6c2db487c2754c2ca11290b3844570b
- document general COM threading architecture in vcl README
- document winaccessiblitiy locking in README
- define _ATL_APARTMENT_THREADED for UAccCOM
Change-Id: I7c3fd952f2cdee7d245a818bf33c477e7ea20fc2
The AccObject is stored by value in XIdAccList, so don't call GetResID()
after it has been erased.
Change-Id: I391aad1e3ab71d443cc6e6b92381f74918e0bcfb
The COM components will (usually? always?) be called on the main thread
via COM, and may also be called on any thread from the UNO event
listeners. Both ways may access the global AccWinObjectManager.
So the easiest way to lock all that without introducing new deadlocks
seems to be to just use the SolarMutex.
The fact that the main thread is in a COM STA is rather irrelevant here
since we don't currently do the required manual marshalling of the COM
pointers so they can be accessed from UNO event listeners running in
threads other than the main thread anyway.
To get that to build:
- use prewin.h and postwin.h around ATL headers
- link UAccCOM against vcl
- define both UNICODE and _UNICODE to not break on mis-matching TCHAR
nonsense
Change-Id: I1ccdf7a4a5c2b5f0b9c29ef39d126c4b8a16898a
Replace it with a map for the new direct C++ instantiation and move this
implementation detail to the cxx file.
Change-Id: Ia961da03f8eb899481cf02f430c921aa8abd7c5c
Multple external definitions of a symbol causes problems when linking
statically, as for Android. Just make the functions static for now, as they
are only used locally in the files where defined anyway.
Change-Id: I8ddbaf01497c171bed4e15f6183ba43461c672d1
Using identifiers starting with underscores is questionable even if they don't
happen to clash with anything used by the language implementation.
Change-Id: I0af605d40d85ea7e47e1047572fbe180270e08ac
This only works partially: the ClassObjects are only registered on the
main thread; CoCreateInstance on other threads still fails.
This reverts commit 29c6216af8c502f220bb84857d3dda901ddfd234.
This is an alternative (to 732ec36edfd09d2091d70c4d71b5f182fe279c45)
solution to the "CoCreateInstance does not work" problem:
replace all CoCreateInstance calls with equivalent calls to create
the components directly.
Since the only reason why this COM stuff needs to be registered
at all is that AccObject uses CoCreateInstance() to create its
COM objects, another possible solution appears to be to simply link
the libraries and instantiate the COM objects directly, without COM.
The only difference appears to be that CoCreateInstance would
automatically add proxy objects in case the COM objects reside in a
single-threaded appartment; not sure if that is relevant here.
Change-Id: I8ffb8af501f6084f3145fa4d4f53366a070e1691
Reviewed-on: https://gerrit.libreoffice.org/6792
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
The COM services are not found because they are not registered in the
registry via regsvr32 (doing that is unnecessary since the components
are only instantiated by winaccessibility code and undesirable since
that would likely register the IAccessible2 types too, breaking A11y
tools) and the special manifest resource #97 that ActivateActContext()
tries to load does not exist in UAccCOM.dll; this would need to be a
XML manifest, the *.rgs and *.tlb that are already included as
individual resources won't work.
After reading ATL headers for hours it is immediately obvious that the
COM components can simply be registered by a call to
CComModule::RegisterClassObjects() from DllMain; this just requires
actually loading the UAccCOM library from somewhere so the DllMain runs.
Change-Id: Id58b754835cd2f1bcada37e5639a6b6042a42fd5
