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


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

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.