This was broken before...
Time used to take centiseconds, so the nanoseconds should have been *divided* by 10^7 for conversion.
Now Time takes straight nanoseconds, so no conversion necessary.
Change-Id: Ibac3eeca7020c5d8c5ff4be3e7617fac26ee8180
As the recent regression after merging AOO patch adding code serializing
"long" variables has shown, this overload (which was added in
7b2a0e541567be9750dfc7d98374555967da3470) is a bad idea.
In a unxlngx build, nm finds uses of the symbols _ZN8SvStreamrsERl
and _ZN8SvStreamlsEl in these files:
- sbxvalue.cxx: this appears to be a legitimate use with sal_Int64
- dateitem.cxx: this was accidentally changed by commit
9830fd36dbdb72c79703b0c61efc027fba793c5a
- atrfrm.cxx: this was added for Table Autoformat enhancement in
7e8c0bd73ee59ff3041e55268c77203373962e51, which is after the
sal_Int64 operators were added, so the file format is now
platform dependent
Change-Id: I78352b5429b53612c4831cdb81b587b5de5180a9
Regression from cbd1a89676f39135ed2e9c47d20475b2053289b9, that commit
accidentally not only removed the #if 0 block, but also two other
braces -- because of this, in case bStorage was false, nothing was
saved. The effect of this was that if the user edited some macro in the
basic IDE, then saved the macro, it was shown as saved, but in fact that
didn't happen.
Change-Id: I20f8358dddfb226976be72f95dcad64de88d83c3
Don't depend on accidental definition depending on the version of boost used.
Change-Id: Ib26afdde895411bdf827e1af21e490b59ef7f2d5
Reviewed-on: https://gerrit.libreoffice.org/4111
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
...recently introduced with c75a46fbd0ba4daf857fcd7d70badeed5aae8e28 "fdo#46808,
use DialogProvider service constructor." The general theme of this additional
ctor appears to be more about "Scripting" than "Listener," and the DialogLib
argument is actually expected to be of XNameContainer type.
Change-Id: Iea7d906d9b2ffc3b3ee5b2cbfaf7c58191037c9b
This reverts commit 6c61b20a8d4a6dcac28801cde82a211fb7e30654. As discussed at
<http://lists.freedesktop.org/archives/libreoffice/2013-May/052449.html> "Re:
fdo#46808, Convert awt::UnoControlDialogModel to new style problem" why the odd
change in 2e2a4827ce6708f0e8677dba9cc92e1479a44086 "scripting: get
CreateUnoDialog() work again" appears to fix things again:
The problem is that the implementation of the css.awt.UnoControlDialogModel
involves UNO aggregation
(IMPL_CREATE_INSTANCE_WITH_GEOMETRY(UnoControlDialogModel) in
toolkit/soruce/helper/registerservices.cxx creating a
OGeometryControlModel<UnoControlDialogModel> instance that aggregates a
UnoControlDialogModel instance). That means that queryInterface can return a
reference to something that is technically a different object, and that's
what's happening here, and explains why calling setPropertyValue in two
different ways on what logically appears to be a single object can end up
calling two different implementations (of two different physical objects).
(UNO aggregation is known to be broken and should not be used. Nevertheless,
there's still code that does---code that is a horrible mess and hard to clean
up.)
That all this worked as intended in the past is just sheer luck, but any
way of substantially touching it is asking for trouble. I'm going to
revert 6c61b20a8d4a6dcac28801cde82a211fb7e30654 again.
I wasn't able to revert without also reverting
be50ad28f5bbdaeff527f646481ce263843c2401 "fdo#46808, Convert
awt::XUnoControlDialog to new style," as the two were tightly dependant. Also
reverts all the follow-up fixes cb4b6dde8fda2a5848e11063028bf44d72f85431
"-Werror,-Wuninitialized" (sans the const-ness fix in
UpdateHandler::insertControlModel), 697a007c61b9cabceb9767fad87cd5822b300452
"Fix exception specifications," 2ce6828bbbf6ba181bb2276adeec279e74151ef6 "fix
awt::UnoControlModelDialog crash," and 2e2a4827ce6708f0e8677dba9cc92e1479a44086
"scripting: get CreateUnoDialog() work again."
Conflicts:
basctl/source/dlged/dlged.cxx
filter/source/t602/t602filter.cxx
xmlscript/test/imexp.cxx
Change-Id: I5d133468062f3ca36300db52fbd699be1ac72998
I left in that block in the mentioned commit above for mostly because
I preferred a more obvious hack/change to cherry-pick to 4.0
The more I think about this ( despite the still imho problematic setting
of the modify state ) I think always writing from memory to the storage
is the right thing to do
Change-Id: I13c82b9d6b55120482c65fb7a5bfadb2396c347c
also this is a fix for bnc#817477
Disabling the optimisation of copying the library container storage
to target storage for the moment ( hopefully after some rework
it might make some sense to re-enable this code ) The problem here is
there is a tragic flaw in the api implementation. In the implementation
the library in-memory model state reflects that the library model
has been saved to storage but not the library container storage
as you ( or at least I ) would expect but actually any storage.
So to illustrate the problem, during autorecovery when the
basic library containers are stored to the autorecovery file the
library pImplLib->implIsModified() is set to false, any subsequent save
attempt will think the library is not modified and will attempt
to the librarycontainer storage to the target one. However, in this case the
source (library container) storage has never been updated with the changes
from memory.
Can't we simply only update the 'implIsModified' state only if the library
container's own storage and the storage to store to are the same ?
Sounds like a good idea, unfortunately this is not possible due to the way
that sfx spaghetti code uses temporary storages for even own copies and
also because it sets the new root storage for the library container
after the library copy happens. ( some stuff in dbaccess appears to
depend on this as well )
AFAICT for any document save/saveas etc. operation the librarycontainer's
own storage and the storage we save to are *always* different.
So for the moment it seems best to *always* write the storage from the
in-memory model.
Change-Id: Ia24e7a6119558497d901370dbc0986101bde4de9
Insert basic/source/runtime/step[012].cxx into
basic/source/runtime/runtime.cxx.
Follow-up to https://gerrit.libreoffice.org/#/c/3373/ .
In many cases the sources for some class have been split up into several
source files, typically suffixed with a number 0, 1, 2 etc. Presumably this
has been done because some compiler years ago was not capable of compiling all
the source for that class at one time, or some other no longer relevant
reason.
It would be nice to get rid of this convention, so that clever compilers have
a better chance of noticing unused private fields in a class, for
instance. Just combining the source files in question into one source file and
removing the old source files from git leads to a discontinuity in version
control history. But the consensus seems to be that this is not such a big
deal.
I picked these sources just because they happened to be the first ones I came
across when looking for files called *0.cxx.
Change-Id: Ia7e8ece9a4374721bbcce6b0e2aba5721436faae
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
Now all these usages were removed from LO.
Change-Id: I8a7233db20abdcdbb18428ad4004c78cc516a0e6
Reviewed-on: https://gerrit.libreoffice.org/3326
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
This reverts commit c5e5699c80cfb32a164696a2c5144b5ccb0a91a9.
And adapts to OUString.
Conflicts:
basic/source/runtime/runtime.cxx
Change-Id: Icd7c1e1e57162eefb1f3631aa5509fd3a09c9b08
- nanosecond precision
- signed (allowed negative) year
Also: assorted improvements / bugfixes in date/time handling code.
Some factorisation of copy/pasted code.
Change-Id: I761a1b0b8731c82f19a0c37acbcf43d3c06d6cd6
