Age | Commit message (Collapse) | Author |
|
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 dc05a825e71316e6f602e5c8dfcd3d10ecb6252f 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 60212988e1cd84169afb028a4255b6f935f1fd4b.
Revert "hrc cleanup: Remove unused strings"
This reverts commit 0e2d7550dd287843b70c03dee952c02f9bd8afb5.
Revert "hrc cleanup: Remove unused Strings in sfx2/source/doc/doc.hrc"
This reverts commit efb74b5dfdb773ba53b29080e1996a93d2c1cac2.
Revert "hrc cleanup: Remove unused Strings in cui"
This reverts commit 527e8f61868210c54bdad650f16390bda03c4353.
Revert "hrc cleanup: Remove unused Strings in desktop"
This reverts commit ac3800fbb9f3251276302b24fa0542441276a34f.
Revert "hrc cleanup: Remove unused cstitem.src"
This reverts commit ae95e31831916df760503bfc2496b7bc55bc638b.
Revert "hrc cleanup: Remove unused strings in wizards"
This reverts commit 20f9a1744319ecdf18c9ab6d0873bb586eb4d03f.
Revert "hrc cleanup: Remove unused Strings in sfx2"
This reverts commit c26d4d34467008418ebf138412e87886694c326c.
|
|
|
|
118568: switch to using ucpp
Patch contributed by Juergen Schmidt
http://svn.apache.org/viewvc?view=revision&revision=1209396
|
|
non-existent 'Sorting' HiddenControl
|
|
|
|
Change-Id: I4ca9942b3abd343b75336e68bfe669ce5d3a38de
|
|
like 3d3b3f656f92790225b89aa31ee61163fb2fc7e5
Change-Id: I6e80717de009e8a3a89ffc80cb945cc832917f8c
|
|
Change-Id: I089642eaa1465629575a55d623eea79427bc2871
|
|
Change-Id: I7e6f495eb56c0d6004c2e427b7fe9c3c09c7206f
|
|
Change-Id: I01756622dd7700d3918d156f118cd69c8a15879a
|
|
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
|
|
Change-Id: Icad1c4d4660cff2a9ad26e0d29faa4c809586b4e
|
|
Change-Id: I2b863b43db59e6904f97d9ad22fdb04013e8c76d
|
|
Change-Id: I26c2f112abd3421231f51e915a97391fa59907a0
|
|
Change-Id: I66cf3fd495485c92bdd9ed400482e7e72d806a89
|
|
Change-Id: I80212dae0b43505ccfb566b4855b5bd28f4314f4
|
|
Change-Id: I9fc995d9b3f971b9b8869cb3f21ddf69b4f90e08
|
|
Change-Id: Id1bb14458203393a2f40e0333afc62416719b1a0
|
|
Change-Id: Ia2e92ea7c5da3ef6e7235b724a82d28d0e562541
|
|
Change-Id: I4162dd0af7501013573590ee1a7a11fc1b36cc99
|
|
Change-Id: I585312848dacf5128a64469874a1c65452a2b5c8
|
|
|
|
|
|
Change-Id: I494ceee07d6825f9466cab810742d7f85291fe14
|
|
Change-Id: I4161a7fe929c81ac0bdd8506d2e0697bdc7f9c9e
|
|
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
|
|
Change-Id: I4da7700f5a706716d14ca25eebf416d14bd6cf63
|
|
Change-Id: I8018d9b5fa01d1720c0392dc5fdc4a0656f25a35
|
|
Change-Id: I6c145e984c885c7e06caa1c27bfb354ea49ad9ce
|
|
Change-Id: Ice06e639213aeb6f7f23cbf4634947dd25613db1
|
|
This was keeping the Base form wizard from applying styles
|
|
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
|
|
...making use of Java 5 variadic function parameters.
Change-Id: I1b538ec7fbb3021a225031543e25dad081a7a409
|
|
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
|
|
Change-Id: Ie0bdbed9578b95f7fccc3d9ff6d9c8b5b91ac0ab
|
|
Change-Id: Ia06794537ea4d0f6f069c83709792ebbcc084804
|
|
Change-Id: I05889ccac213743a55c302bd7249b30f817c0428
|
|
Change-Id: I1ce4279d434ffa58328e17863b2e68af1e813a99
|
|
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
|
|
Change-Id: I684fb4adb68d372914ea42cc4e7bd4459a08b150
|
|
Change-Id: If8ba8f4e12aaebadec86a7f445a6d32bd363106d
|
|
Change-Id: Ic51b50a5b06f2a96750a945754e44a302b070f77
|
|
Reports created in 3.4 and earlier lack it.
Change-Id: I2cf1cad75fff59f23ad98299c4f94253adf7355b
|
|
This should reflect the fact that this type was already used as a
generic HTML type.
Change-Id: I0a209d51ed229f07aff001075c39bfc82d4c3088
|
|
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
|
|
|
|
It's already set by Jar_reportbuilder.mk .
|
|
|