[Libreoffice] [PATCH] Base fdo#40079 "file / save (as)" inoperant

[Lionel Elie Mamane]

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