This changes all generated API headers (.hpp and .hdl) to use a
namespace alias 'css' instead of the pointlessly long com::sun::star
Makes the change in cppumaker & associated tools, adds a global
namespace alias definition in sal/types.h, and removes a kiloton
of local, now pointless-to-harmful versions of that alias from all
over the code.
Change-Id: Ice5a644a6b971a981f01dc0589d48f5add31cc0f
The a11y API has never really been picked up by tools vendors, let's
not tie ourselves up here for no good reason.
This unpublishes all css::accessibility, and dependend API.
With that, we can change the rather unfortunately-named add/
removeEventListener to be add/removeAccessibleEventListener, thus
not conflicting with the XComponent methods of the same name.
Change-Id: I595598c3a8e46415f80b2780f333333174865fe4
The service is deprecated, but we still have a handful of in-tree
users, and converting it lets me thread XComponentContext through
a bunch of classes.
Change-Id: Iffdfe537ada6b9e4a89f9b3c8dd82ca85f4bfaba
old code used to use XCell->setString, new code uses rDoc.SetString which by default tries to detect number formats. The ScColumn::SetString that eventually
gets called seems to do lots of additional checks ( and apparently even if
an ScSetStringParam instance with mbDetectNumberFormat ( false ) was passed
it seems that it will still try to detect decimal number formats. With that
in mind I restore and un-unoified version of what XCell->setString used do
Change-Id: Ifaef74c78b198f492a390a3d5dc1721622a01ea4
After having discussed with Michael Meeks, a better way would be to be iterator free
Now, should all textwindowaccessibility part be iterator free?
Change-Id: I8079b3ffbc9d37bc2c3b9ede088485dd3a7e410e
...by folding the contents of java_accessibility.jar back into
java_uno_accessbridge.jar.
In the old build system there were two jars, java_uno_accessbridge.jar
containing the handful of org.openoffice.accessibility classes and all
org.openoffice.java.accessibility classes (though how the latter got included
was fairly obscure in the makefile.mk) and unused java_accessibility.jar that
contained all org.openoffice.java.accessibility classes. When adapting this to
gbuild, the unused java_accessibility.jar was carried over, but all its
org.openoffice.accessibility classes were inadvertently droped from
java_uno_accessbridge.jar.
Change-Id: I9b582ba22667b1dae635828e85c4cc5b530353ac
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
With gb_Jar_add_jar and gb_Jar_add_system_jar adding to the manifest
classpath automatically it is no longer necessary to call
gb_Jar_set_jarclasspath manually except for the URE jars, which
are apparently not supposed to be added automatically.
Change-Id: I1e743e7ecb9cb5651e02005aa09e127bea1b0a29
Part of MultiLineEdit was moved down from stvools to vcl
with name VCLMultiLineEdit. MessBox uses it to display the
message in read-only mode. Some of svtools' classes - which
are necessary to implement VCLMultiLineEdit - were moved to
vcl as a whole, and their includes are rewrite.
Note: ExtTextView and ExtTextEngine classes would be leaved in svtools
if VCLMultiLineEdit is a template class, but two macros: IMPL_LINK
end IMPL_LINK_NOARG make it impossible to use template syntax.
Change-Id: I26543868d8081c225c7125404d23369de3c3afcd
