| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I52bba4d4c0558e6b87530e4577f4b1ef458b7012
Reviewed-on: https://gerrit.libreoffice.org/16888
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
|
|
Instead, atls.lib should be used also with code compiled to use the
debugging runtime. See
http://msdn.microsoft.com/en-us/library/bb531344.aspx which says
"Atls.lib no longer has character-set dependencies or code that's
specific for debug/release. Because it works the same for Unicode/ANSI
and debug/release, only one version of the library is required."
Change-Id: Ie39ea271513dec1084cae8d1bbf93afa286f357a
|
|
Change-Id: I9cc9bfbddd3a90e00eee3e674994e5d6207f9034
|
|
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
|
|
Change-Id: Ife0960b235e24f17640b197f952a9a094b7d654d
|
|
Perhaps delayloading the URE dlls makes it easier to register the
UAccCOM.dll during installation or something? Well we don't do that any
more.
Change-Id: Ic7c356f5954f869c8752aab2563f059a27ef731f
|
|
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>
|
|
Change-Id: I691c5fc3554bcdeb6c3beb0e5b445cfcd7b51e4c
|
|
Original code from:
Author: Steve Yin <steve_y@apache.org>
Date: Sat Nov 16 23:58:19 2013 +0100
Integrate branch of IAccessible2
With these improvements:
Make IAccessible2 an experimental feature, with fallback to Java a11y.
Move initial setup of windows into the bridge and clean, remove conditionals
Check for presence of AT in the bridge as well to clean. Merge VCL events
extensions and their handling. Clean and split WB_GETOBJECT handling out to
it's own method. Add component prefix namespacing.
Cleanup msaa service info, and implement XComponent to share mxAccessBridge.
Add suitable debugging output, remove VCL dependency from UAccCOM causing
registration issues.
Change-Id: Ib19e38ddca71182018df438df27dcdb555d91402
|
|
Conflicts:
winaccessibility/source/UAccCOM/UAccCOM.def
winaccessibility/source/service/AccObjectWinManager.cxx
winaccessibility/source/service/checkmt.cxx
winaccessibility/source/service/checkmt.hxx
Change-Id: Ia66872bee7c70c840c1bd5caa626bf63eac9ef7c
|
|
Change-Id: I1aae7ec50c3bb78ac1035d70eaf39c6efef465ab
|
