| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: Icba39756a54d1225514048c55ddad0f31ce31699
|
|
|
|
|
|
|
|
| |
Use it in the cases where I yesterday changed SAL_DLLPUBLIC_EXPORT to
JNIEXPORT. It turns out that on Linux JNIEXPORT does not enforce
"default" visibility, but expands to empty.
Change-Id: I033b3cf538715fb596e965e17f3da12fb987df63
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now with DISABLE_DYNLOADING, SAL_DLLPUBLIC_EXPORT actually means
hidden visibilty. Which is OK in general as with a single DSO (or a
single executable, for iOS), none of our "normal" entry points need to
be visible froom the outside.
So for the JNI entry points use JNIEXPORT. On "normal" platforms it
should be equivalent to SAL_DLLPUBLIC_EXPORT.
Change-Id: Iad634950e635ac03a0e90cae6d00afd9fb4eeb64
|
|
|
|
| |
Change-Id: Iae8f93d096178532e2384a13b36e1385269aa14f
|
|
|
|
|
|
|
| |
regression from f42a9309760565d24619bad9ee1f5561ce89c14b
which forgot to adapt getImplementationEnvironment to new prefix
Change-Id: If5a6f804b8f9f91e22f093a76f6b81a2b62991ab
|
|
|
|
| |
Change-Id: I7a337ed15b86417faa5ac03089e8c315be95b717
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem is that ado driver creates a link file in the tree
leaving it dirty: tinderbox doesn't like it. Instead of reading
the mdb file direct from srcdir we copy it first to workdir and
read it from there with the new function: getPathFromWorkdir.
Thank you Norbert!
Change-Id: I504bc26b80686db55a505bac19a95cc9c6022fcc
Reviewed-on: https://gerrit.libreoffice.org/1004
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
|
|
|
|
|
|
| |
...if not even mozab. Otherwise, there is no implementation of
com.sun.star.mozilla.MozillaBootstrap and "File - Digital Signatures... - Sign
Document..." cannot show any certificates from Mozilla profiles.
Change-Id: Ie9b73fad798b2c2a3b52ba374ea967401694f685
|
|
|
|
| |
Change-Id: I6b8cdd69edb1e25cd7545cea5a3ffdfcff5000a0
|
|
|
|
| |
Change-Id: Icf337b7bb0894a61b2a36a594ff259c601ddaabb
|
|
|
|
| |
Change-Id: I4debeba1b9637fdaaa369a28c9a6c98a4729d76e
|
|
|
|
| |
Change-Id: Ie6e9c58cc4762a0159680a71ce2e03340dac6f7f
|
|
|
|
| |
Change-Id: I0499ad7de27b1539e97f01ab8aa0ef2d6713ae76
|
|
|
|
|
|
|
| |
That code was there since the beginning, but unreachable.
Consequent cleanup removed it.
Change-Id: I2564038ce58d7aff3860f154acac37266c155146
|
|
|
|
| |
Change-Id: I2c1aa64db61e281dc1cddc2e7d89d9b109dcf287
|
|
|
|
| |
Change-Id: I1a7f15c4fd97e3a134698e8b6f7e2a93701674fe
|
|
|
|
|
| |
Using operator= in a copy ctor is a rather bad idea when the operator= accesses
uninitialized data members.
|
| |
|
| |
|
| |
|
|
|
|
| |
Change-Id: I34f7a8ae58fa6af4c8cfdd13330420f1576fa2c9
|
|
|
|
|
|
|
|
|
|
|
| |
Through that different initialization pIUnknown
got random address. The consequence was that
if (pIUnknown)
pIUnknown->Release();
ends with access viloation in
WpBase& WpBase::operator=(const WpBase& rhs)
Change-Id: I8b3c5de233d0868fea052c990cc83aed917117ae
|
|
|
|
|
|
| |
Since the ADO driver does not support Catalog&Schema, just leave it empty
Change-Id: Iff9a5105e70a7b9a23f24263b0e74b4fc6d91332
|
|
|
|
| |
Change-Id: If8600f1b3d9346c54ffbba77826ff5ac4f1ed15f
|
|
|
|
| |
Change-Id: I9a55180e0a0ef1bc14ce7c84265fb3d5508bd541
|
|
|
|
| |
Change-Id: I88a64a19d9f2812a77f0a71f31fe8314732ec44f
|
|
|
|
| |
Change-Id: I19657ee92b5d0e1e51d11dd2aa69191fdb0f4f50
|
|
|
|
| |
Change-Id: Ib0573685773745ac8698d76faa5ebe2cd1a109b3
|
|
|
|
| |
Change-Id: I2433bd2cc289b9ded1c825ea3dbe1db2ccf4bae9
|
|
|
|
| |
Change-Id: I137d4f794c7c738deedddfe8ea5e0dc783b49e7c
|
|
|
|
| |
Change-Id: Id2846bd6db9bace6cffacf3a9fc4116ae727facf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example dbaccess::OSingleSelectQueryComposer::appendOrderByColumn expects it
(via impl_getColumnName_throw via getTableAlias)
There is some vagueness:
Should the TableName property contain just the table name,
or the *composed* table name
(that is with catalog and/or schema if used by this DB)?
In the case of a query, should it contain the table name (alias)
*in* *the* *query* or of the original table?
In the former case, what meaning do SchemaName and CatalogName have?
They should be empty?
For now, commit as such and deal with the fallout, if any,
when it hits the fan.
If we really need to store these *different* values,
(that is, some code validly needs them)
it would be easier / cleaner / ...
to define *different* properties
for these *different* notions.
Change-Id: I032e619a60e7563cd51478db16cb5e0e5452bfde
|
| |
|
|
|
|
| |
Change-Id: I5ff8335d9c7324a101d055ff9666fce867bac8ff
|
|
|
|
| |
Change-Id: I430929a19d7f5c9c6859c12a0952f9d335de4520
|
|
|
|
| |
Change-Id: If2422a618f98685d029289a5357fa7d7860567e7
|
|
|
|
| |
Change-Id: Ia5e4729c2c85dfacc4505c3674a113a6a4415ab0
|
|
|
|
|
|
|
| |
Change-Id: Iae27a96c1e2ed72d2744fcbe100d6ada7dc41c82
Reviewed-on: https://gerrit.libreoffice.org/914
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
|
|
| |
Change-Id: I579dd5fc6c71ac9dad2de622e9125b399f3e160e
|
|
|
|
|
|
|
|
|
|
|
| |
More type-safe way, instead of void* everywhere
void* instead of sal_Int8 for raw memory / multi-use buffers
Fixed more issues than I care to count, but at least:
- updates to a DECIMAL were truncated to integer because DecimalDigits set to 0
maybe/probably also NUMERIC
- setObjectWithInfo(... DataType::LONGVARCHAR ...) was passed as AT_EXEC, but the buffer was already free()d by then -> crash or wrong data
Change-Id: I0e6791a05b96fb345bfe3f911386263e6cfedde9
|
|
|
|
| |
Change-Id: Ifa9b93b2daf0bb448711eb1bd3ebab69febf4f9c
|
|
|
|
| |
Change-Id: I6de4e86f09be74518c9980d1b2347217cdcc4e02
|
|
|
|
| |
Change-Id: I70f92224e22e9a9a1283564b5b1be7bf1e0240d0
|
|
|
|
| |
Change-Id: Id2e8ad5b6bed1c184de6dccf7fa43254099fb958
|
|
|
|
| |
Change-Id: I50c64d5fcf1d642052be5edbe64dde2c03c1eba9
|
|
|
|
| |
Change-Id: Icf6a71900d79377cde84c2307ce85a9b3c96a54f
|
|
|
|
| |
Change-Id: I799a149b319bb6a3168117810084496f8b6d6fbb
|
|
|
|
| |
Change-Id: Ia1345904a819d8edfad53c8882be35b398e8bc6e
|
| |
|
|
|
|
| |
Change-Id: I057c3ea14cd1f224b339f884ae86890d16471215
|