Fix regressions introduced with
6a043e9c0acff20e1618ca8ec15c21d5d0fd0d37 "Use the new type-checking
Reference constructor to reduce code noise"
Change-Id: I85662856f21c810a7db497fe3b0e116f075b1687
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Now that we have default values for Exception constructor params,
remove lots of boilerplate code.
Change-Id: I620bd641eecfed38e6123873b3b94aaf47922e74
Also fixes fdo#42899 and fdo#67685 in a different way; the previous fix
for fdo#42899 caused the problem with password-protected libraries for
which the password is not known: only the binary representation of the
BAISC module was stored, not the source code; by simply copying from the
source storage the problem can be avoided.
It would be possible to ask for the password when storing, but that
would not work when non-interactive (called via API).
An alternative fix would be to pass in the
SfxObjectShell::IsSetModifyEnabled() flag and actually reset the BASIC
library's modify flag correctly, but that requires adding a
parameter to XStorageBasedLibraryContainer::storeLibrariesToStorage().
(regression from af34774d260a68fc02cd78ba90dd8d4afaf1a2a4 )
Change-Id: I4701401f35171139fc2fe8d225d13d4e533091a0
This reverts commit fc9080a0c60f263d00eb71111fcda72b3c0a2ebb.
This bug was apparently introduced by
af34774d260a68fc02cd78ba90dd8d4afaf1a2a4, which will be reverted
in the next commit.
Change-Id: I81ccb5bf9cc7e29fbf1e66d02f38268ee1fd1d0c
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
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
This is a big commit, so thanks for your time reviewing this :)
Conflicts:
basic/source/sbx/sbxscan.cxx
Change-Id: Ib9bc710b87475b5695764557321e5dcef25e5933
Signed-off-by: Miklos Vajna <vmiklos@suse.cz>
I upgraded the service to return XSimpleFileAccess3, since it
already implemented that interface, and it's backwards
compatible.
Change-Id: I40001a46048bd21a23b6a2f58a95376f06fc634b
parsing 1000s of line of code is hard enough without having to fight
with weird indentation and irregular formatting.
So as the review progress, in order to follow the code, cosmetic changes
were made...
In order to minimize the task of the reviewers and allow them to
concentrate on what matter, an effort is made to collect these
cosmetic changes into this separate commit.
Change-Id: I3c9b04a0150d0d0a048c2e976fe24de4f2b6b98a
