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
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
(i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
(i.e. it is registered at the Module, has it's own makefile, may be
in a different module than the target)
