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

[Lionel Elie Mamane]

On Tue, Aug 16, 2011 at 09:41:43AM +0100, Noel Power wrote:
> On 15/08/11 13:10, Lionel Elie Mamane wrote:

>> 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.

> I would like to have a look at this, (...)

> Two questions,
> a) did you try this on master

No, not yet.

> ( I did and it appeared to work as expected ) but I am pretty 'base'
> disabled so I fear I may have missed something in trying to recreate
> it

You have to be very cautious what you do to reproduce it, it is
fragile: for example, if you open the Basic IDE, you have lost, as
this, according to my testing, leads to the Dialog library having been
loaded at the point I patch.

Either bind a macro to the "open document" event or run the macro from
Tools / Macros / Run Macro.

The "Standard" Dialog library also should not be empty; it should
contain at least one dialog.

Which leads me to another bug: If I remove the librarie's only dialog
and save, I restart LO, I reopen the file again, the dialog is
back. If the library has two dialogs and I delete one, it is gone
after a save and reload. This seems to be Base-specific.

> b) is this behaviour specific to base documents?

Well, this bug is, but that is because the other apps have another bug
that hides this one :-(

My testing shows that
SfxDialogLibraryContainer::storeLibrariesToStorage
aborts at the same place for a calc document (an exception is raised),
but this does not abort the save. Thus, logically, in the conditions
where this bug shows up, Calc looses the embedded images in
Dialogs. This is tested. And I guess also looses (the changes to?)
anything that is saved *after* the Dialogs, if anything is (this is
not tested).

> I wonder what does base do differently from 'normal' documents and
> why

It (correctly IMHO) aborts the save when the save raises an
exception.


On Tue, Aug 16, 2011 at 09:51:39AM +0100, Noel Power wrote:
> On 15/08/11 13:10, Lionel Elie Mamane wrote:

>> 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?

> not at all sure  but it should be easy enough to test, (...)

> After saving, the image should be stored in it's own document
> stream. After testing with your 'modification' scenario ( e.g. run
> macro, make change, re-save ) when you open the dialog the image
> should be still there ( best of course to check that after
> restarting libreoffice and re-opening the document )

I disabled the "export out any embedded image object" code by adding a
"return;" before it, and it does not loose the embedded images, even
after restarting LO and re-opening the document.

I additionally disabled the "// Can we simply copy the storage?" case,
and it seems to have corrupted the document: I cannot anymore edit the
dialog :-) It just shows the Basic code or another dialog instead.

-- 
Lionel