this is a continuation of the above bug, removing SAL_INFO's
that only mark function entry.
Change-Id: Idb0f72481415594e3f8b7a11ad6e4b8835f6fca0
Reviewed-on: https://gerrit.libreoffice.org/9343
Tested-by: Thomas Arnhold <thomas@arnhold.org>
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Convert code like
if( ! aStr.compareToAscii("XXX") )
to
if( aStr.equalsAscii("XXX") )
which is both clearer and faster.
Change-Id: I267511bccab52f5225b291acbfa4e388b5a5302b
Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
- nanosecond precision
- signed (allowed negative) year
Also: assorted improvements / bugfixes in date/time handling code.
Some factorisation of copy/pasted code.
Change-Id: I761a1b0b8731c82f19a0c37acbcf43d3c06d6cd6
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
I had to drop XEventBroadcaster from the merged interface
because it introduced method name conflicts (addEventListener).
Shouldn't be an issue since it was scheduled to be dropped anyhow,
and the service implementation still implements it, so existing clients
will be fine.
I dropped the interface XPropertySet from the combined IDL because nobody
seems to be using it, and it's primary purpose appears to be to set weird
flags.
I dropped the optional interfaces
XStatusIndicatorFactory
XDispatchInformationProvider
from the combined IDL because the service does not implement them, and
nobody seems to be using them. I suspect they were mistakenly copied
from XFrame.
I also did not convert the Title, UserDefinedAttributes and LayoutManager
properties to attributes, again because no-one is using them.
Change-Id: I678a00006ed2cca2d6c37c4e39465811442c33af
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
Hello lo-devs,
this patch series removes a lot of unnecessary includes for the various
tools header. The patches without suffix should be applied to the core
repository, the .binfilter.patch suffix should be applied to the
binfilter repository. I've tested the build with the configuration
--enable-binfilter --enable-dbgutil --enable-debug, is this sufficient
or did I miss another important configuration, that enables some
conditional compiled code? I've only build this on linux-x86_64, but the
patch also touches some of the mac specific code like
fpicker/source/aqua/SalAquaFilePicker.mm so it would be maybe a good
idea to test this patch.
regards Marcel Metz
