In case the data source has a formula cell, the number format may be
inferred from the formula result in case the cell format is General.
Also,
1) no need to use UNO API in the API implementation. Let use the
internal API here.
2) this method didn't take into account the hidden cells.
TODO: We need to handle number formats for external ref data properly.
We dump the library's symbols we're trying to stubify, and then
assemble another library that looks just like it, except with all
of it's innards sucked out.
We also use pkgconfig to find all the relevant dependencies and
to build an entire library tree.
Catalan (Valencian) has no ISO 639 code assigned and the UI localization uses
the ca-XV hack where XV is of the reserved ISO 3166 user-assigned range. This
should not escape to document content therefor internally a replacement to
ca-ES is done for all locale attribution. For the UI localization to be
distinguishable under Tools->Options->LanguageSettings->UserInterface this
needed a special handling to allow Catalan (Valencian) again.
Setting a page-anchored object to cell-anchored didn't show the anchor
immediately until you unselect the object and re-select it. Same for
the cell-anchored to page-anchored direction.
This commit fixes it.
Currently on File->Properties we display "LibreOffice 1.0 Text Document"
etc. for OpenOffice.org XML format documents, which is wrong: these
should not be re-branded.
This should fix the spurious segfaults caused by running the test while
the library is being overwritten in parallel that cannot be reproduced
by just running the test.
CLASSPATH is supposed to show where to find the classes needed by Java
programs running at build time. The -cp switch to javac tells where to
find classes referenced by the code being compiled. These are
different things. (But it doesn't seem to have mattered much in our
build system.) So use T_CP instead, named in the same fashion as
T_CXXFLAGS etc.
But... for some reason this change, which as such should be just more
or less cosmetic, also fixes a build problem in the "scripting" module
on Windows, seen by Noel Grandin
(http://comments.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/19016
) and me.
