Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


When the "Standard" Basic Macro Library for the document is loaded
(which happens implicitly as soon as a macro is executed), but not the
"Standard" Dialog Library, the "File / Save" action (or the equivalent
toolbar button) does nothing, without error message.

The attached patch (against libreoffice-3.4 branch, thus old
"bootstrap" repository) explicitly loads the library before trying to
extract embedded images from it, which is the part that gave rise to
the exception that aborted the save operation. Tested to fix the bug
as I experience it.

There was a comment there saying the libraries would already be loaded
from previous code, but that is not the case. I thought maybe the
"real" bug is in previous code, the code that was supposed having
loaded the libraries, or maybe that code was genuinely changed and
really does not need to load the libraries anymore.

Looking into that direction, the comment probably refers to the call
to SfxLibraryContainer::storeLibrariesToStorage, which calls
SfxLibraryContainer::storeLibraries_Impl with bComplete=sal_True
whose code looks like:

(...)

    if( !nLibsToSave )
        return;

(...)

    if ( bStorage )
    {
        // Don't write if only empty standard lib exists
        if ( ( nNameCount == 1 ) && ( aNames[0].equalsAsciiL( RTL_CONSTASCII_STRINGPARAM( 
"Standard" ) ) ) )
        {
(...)
            if ( !xNameAccess->hasElements() )
                return;
        }
(...)
    }
(...)
    for( ; pName != pNamesEnd; ++pName )
    {
        if( pImplLib->implIsModified() || bComplete )
        {
            // Can we simply copy the storage?
            if( !mbOldInfoFormat && !pImplLib->implIsModified() && !mbOasis2OOoFormat && 
xSourceLibrariesStor.is() )
            {
MY TESTING SHOWS THAT THIS BRANCH IS TAKEN
                try
                {
                    xSourceLibrariesStor->copyElementTo( rLib.aName, xTargetLibrariesStor, 
rLib.aName );
                }
                catch ... { ... }
            }
            else
            {
(...)
                // Maybe lib is not loaded?!
                fprintf(stderr, "about to maybe loadLibrary,
                bComplete='%d'\n", bComplete);
                if( bComplete )
                    loadLibrary( rLib.aName );
(...)


So probably what happened is that the "// Can we simply copy the
storage?" optimisation / fast path was added and suddenly
SfxLibraryContainer::storeLibrariesToStorage does not anymore load the
libraries, as the rest of the code in
SfxDialogLibraryContainer::storeLibrariesToStorage expected, which
would suggest that my patch is the right fix.


The remaining question is: if xSourceLibrariesStor->copyElementTo was
called, does the code under:

    // we need to export out any embedded image object(s)
    // associated with any Dialogs. First, we need to actually gather any such urls
    // for each dialog in this container

still need to be run? In other words, has copyElementsTo copied these
embedded image objects, or not?


I also attach a small patch that slightly simplifies the code without
changing its behaviour in any way.

-- 
Lionel
From ca35f4f5e586e6c4eed0f64a466bc471333b7b6c Mon Sep 17 00:00:00 2001
From: Lionel Elie Mamane <lionel.mamane@gestman.lu>
Date: Sun, 14 Aug 2011 17:00:54 +0200
Subject: [PATCH] fdo#40079: load Dialog library before trying to get embedded images

---
 basic/source/uno/dlgcont.cxx |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/basic/source/uno/dlgcont.cxx b/basic/source/uno/dlgcont.cxx
index c8da150..158d9fe 100644
--- a/basic/source/uno/dlgcont.cxx
+++ b/basic/source/uno/dlgcont.cxx
@@ -292,7 +292,7 @@ void SfxDialogLibraryContainer::storeLibrariesToStorage( const uno::Reference< e
     Sequence< OUString > sLibraries = getElementNames();
     for ( sal_Int32 i=0; i < sLibraries.getLength(); ++i )
     {
-        // libraries will already be loaded from above
+        loadLibrary( sLibraries[ i ] );
         Reference< XNameContainer > xLib;
         getByName( sLibraries[ i ] ) >>= xLib;
         if ( xLib.is() )
-- 
1.7.2.5

From db46b409b2a8c921846ed0b6808950824c2144a8 Mon Sep 17 00:00:00 2001
From: Lionel Elie Mamane <lionel.mamane@gestman.lu>
Date: Mon, 15 Aug 2011 14:02:25 +0200
Subject: [PATCH] Janitorial: deduplicate code; no behaviour change

---
 basic/source/uno/namecont.cxx |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/basic/source/uno/namecont.cxx b/basic/source/uno/namecont.cxx
index 4882c6f..2251d12 100644
--- a/basic/source/uno/namecont.cxx
+++ b/basic/source/uno/namecont.cxx
@@ -1806,10 +1806,8 @@ void SfxLibraryContainer::storeLibraries_Impl( const uno::Reference< 
embed::XSto
         // open the source storage which might be used to copy yet-unmodified libraries
         try
         {
-            if ( mxStorage->hasByName( maLibrariesDir ) )
+            if ( mxStorage->hasByName( maLibrariesDir ) || bInplaceStorage )
                 xSourceLibrariesStor = mxStorage->openStorageElement( maLibrariesDir, 
bInplaceStorage ? embed::ElementModes::READWRITE : embed::ElementModes::READ );
-            else if ( bInplaceStorage )
-                xSourceLibrariesStor = mxStorage->openStorageElement( maLibrariesDir, 
embed::ElementModes::READWRITE );
         }
         catch( const uno::Exception& )
         {
-- 
1.7.2.5


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.