Apparently Xalan was introduced years ago to have a DOM implementation
with JRE < 1.4 (i#37179), which then got automatically converted to
saxon years later.
Change-Id: Ibc13b84331854926965f35e3afe25e923bad821b
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
This is especially the case when the source is a (saved) query.
Fixes: Report Builder wizard "Finish" button does nothing -> cannot create report through wizard
Change-Id: I266772035435a7c623beb0c0f66fc88e6316be8e
This reverts mostly all of my hrc string cleanup commits. As Markus
stated in dc05a825e7 those are erroneous
and mostly untested. And therefore absolutely unsave. I only did test
them by compiling and checking the main screens. Cleaning those files
seems to be much more complicated than I thought.
So to be absolutely save I do this huge revert. Sorry for this.
Revert "hrc cleanup: Further cleanup"
This reverts commit 60212988e1.
Revert "hrc cleanup: Remove unused strings"
This reverts commit 0e2d7550dd.
Revert "hrc cleanup: Remove unused Strings in sfx2/source/doc/doc.hrc"
This reverts commit efb74b5dfd.
Revert "hrc cleanup: Remove unused Strings in cui"
This reverts commit 527e8f6186.
Revert "hrc cleanup: Remove unused Strings in desktop"
This reverts commit ac3800fbb9.
Revert "hrc cleanup: Remove unused cstitem.src"
This reverts commit ae95e31831.
Revert "hrc cleanup: Remove unused strings in wizards"
This reverts commit 20f9a17443.
Revert "hrc cleanup: Remove unused Strings in sfx2"
This reverts commit c26d4d3446.
In particular com/sun/star/wizards/ui/FilterComponent calls getSelectClause before calling getFromClause, and then all hell breaks loose: composedCommandNames is empty, thus cannot find the proper Alias column name, thus the column names in the select list were not properly escaped, ...
We have just made getFromClause quadratic instead of linear, but:
1) I do not think this would be a problem (small datastructures)
2) If it is, rather use a hashmap or something like that, wich will also make getSelectClause faster
Also make the fallback case of "unknown table" more robust: escape the table name (if any) and column name!
Change-Id: I474adc51fc6378d836bd5865d9eb9505983dcbc5
a) it doesn't work
b) isn't connected up to any menus
c) is arbitrarily localized to big 12 nations
d) out of date wrt public holidays in those anyway
Change-Id: I4a16490b3ae84c6e5dbe0774ea8eb0000ed6dc3d
1) Set FormatsSupplier property only if underlying object has one.
Else, exception is thrown and the format is not set
2) getTyperelatedFieldData uses the format keys, so initialize them
before call, not after.
Change-Id: I68c4c96a9da9a6afdc3ab8964e973588f53ee814
These warning arise because of the additional of varargs parameters
in Java1.6. Casting the parameter eliminates the compiler
confusion.
Change-Id: I4906bcfa2700ef80a67b79c61c6848a18e8a7168
In *both* cases, the value of hidden control "Sorting" (if non-empty)
decides the columns being sorted on.
Change-Id: I7f4b50c3af8c12e48e5dedd36b5877ad7a9e1b66
Legacy report means done with the "old" report system, as opposed to
with report builder.
This was caused by a misguided attempt to sort-of work around i#110536
instead of fixing it cleanly. Revert that.
Apparently the idea was to not explicitly set grouping columns as
sorting columns, but that the report execution would automagically add
grouping columns at begin of sorting list at report execution
time. That's a bad idea for at least two reasons:
* This does not allow the user to chose ASC/DESC for grouping columns
* In rare / advanced cases, sorting on another column *before*
grouping is desirable.
Plus, the "automagic adding" part apparently wasn't implemented
anyway.
Change-Id: I81e76eb4b6a0e543571a4df97d0ead77f6a2d7c8
