[Libreoffice] [PATCH] Base fdo#40079 "file / save (as)" inoperant
nopower at novell.com
Thu Aug 18 04:52:55 PDT 2011
On 17/08/11 19:02, Lionel Elie Mamane wrote:
> On Wed, Aug 17, 2011 at 09:48:04AM +0100, Noel Power wrote:
>> On 16/08/11 17:32, Lionel Elie Mamane wrote:
> I did now. Reproduced there, but someone (you?) pushed my patch so
> *now* one cannot reproduce it anymore. I also took the liberty of
> adding you to the CC list for the bug. I did not go as far as
> assigning it to you ;-)
yes, I reproduced it too, the key point was you need to use the Tools |
Macros | RunMacro, I was using Tools | Macros | Organise Macros |
Libreoffice Basic. And yes, I did push the fix to master and the 3.4
branch, did you see the message ( in this thread ) with subject
"[PUSHED] - cherrypick to 3.4.2 Base fdo#40079 "file / save (as)"
inoperant" note: 3.4.2 is wrong and is corrected later in the mail spew.
>>> 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
>> probably worth opening another bug for that then, anyway, lets look
>> at one thing at a time ( otherwise I will get depressed )
> Fixed (by me) in master.
not sure about this, I would like to know why this seems to work outside
of base :/ I will try and see
>> 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
> Fixed (by me) in master for calc and writer, commit
> 7f3a944146879d2f0e6ee3f69cf721eb14f18689. I notice that calc and
> writer have the good sense of displaying an error message when an
> exception is raised during save. That's better than Base, that just
> silently aborts the save with no error message.
> However, calc seems to get very confused and disables (greys out) the
> save, close file, quit application, etc features :-|
then it might be an idea to back out that commit, it appears the
exception here isn't really handled, I think the exception is caught (
and ignored ) previously precisely because nothing really can be done (
or at least the calling code lacks the brains to handle the exception ).
This isn't unusual in libreoffice code, sad but true and especially true
when saving. imo a document that has lost possibly some basic related
changes is preferable to an inoperable document and of course the
particular scenario triggering this should no longer be an issue right ?
More information about the LibreOffice