Converted wrong usage of sal_uIntPtr to appropriate other types in basic
module.
The bug is not fully fixed with this since many other occurences of sal_uIntPtr remain.
Update due to code review comments:
Fixed forgetting to change some declarations in iosys.cxx.
Cleaned up the one remaining sal_uIntPtr in iosys.cxx
Fixed adding a sal_uInt64 to a Date (uses long now instead) in methods.cxx
Fixed the VarDecFromUI4 call in sbxdec.cxx from sal_uLong to ULONG .
Conflicts:
basic/source/runtime/iosys.cxx
Change-Id: Ia6460be04967deb68b92eb62d945da8814fae605
to use cppu::supportsService and other pieces.
Change-Id: I16893b3d31a8055acd214ff23d01e63d38fe0826
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Change all instances of hardcoded "program", "share" etc subfolder names to
use those from <config_folders.h> instead. In normal builds, the end result
will not change.
Change-Id: I91c95cd8e482818be67307e889ae6df887763f53
else it keeps loadLibrary from completing,
because the latter cannot open the storage
because it is already open in read/write mode.
Change-Id: Icd0aabfff6e67af2c38a8f9185f8485b46ab1516
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
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
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
