[My test env: LibreOffice 3.4.4 WinXP Japanese] Originally reported here: https://issues.apache.org/ooo/show_bug.cgi?id=112775 See original bug report for description. This issue has not been fixed there. There are 2 workaround, however, it is difficult to deal with ordinary activities. This is a serious bug since data is lost. So, hopefully it can be resolved in LibreOffice. Could you please check on this issue?
Thanks for bugreport Please, verify if in last version of LibreOffice still reproducible
Hi, Verified the bug with LOdev3.5.2 WinXP Japanese, and it still persist.
Oops, slipped my finger. Verified the bug with "LO 3.5.2" WinXP Japanese, and it still persist.
Thanks for additional testing
Improved Summary and Platform a bit (Platform according to original description and comment #2/3).
In link in description mentioned Linux and Ubuntu. I reproduced something like it on Fedora 64 bit, but last time not tested. Changing again to All
I am also having problems in this area See bug report 50648 The fault is also present if changes are made to a dialog in the macro editor so it is not confined to code being edited. I am using Libre Office 3.5.3.2 and is present as of today Wednesday 6th June 2012
Are you sure this is a bug and not just user not compiling/saving macro? I had this issue but someone suggested that I compile the macro, then save from within basic editor, then close macro editor and save document. I never have problems doing it this way
Joel Perhaps it is the sequence of events that you describe that fixes/prevents the fault - I haven't made a conscious effort to note exactly what I do. Irrespective of the truth of your suggestion, there should be no requirement to go through that sequence of events simply to ensure that any changes that were made are saved. It is to be expected of any software program that once you have made changes to a file and closed it, those changes should still be present the next time the file is opened. I still regard this as a bug and I am raising the importance level as it is a major concern of mine that spending not an inconsiderable amount of time writing, running and debugging code and then finding that this time has been completely wasted due to Libre Office/Open Office not being able to save my changes.
I tend to agree that it's a bug just was trying to point out that I think there is a workaround. I agree that a save of the document implies saving the macro as well :) Setting as NEW as it's confirmed
*** Bug 50648 has been marked as a duplicate of this bug. ***
I'm changing status to NEEDINFO as we need to figure out exactly what steps are needed to reproduce this consistently or determine that there isn't exact steps. Either way, more testing needs done. For those of you experiencing this bug, if you email me directly we can brainstorm some possibilities and see if we can pinpoint the bug.
To reproduce this bug: Open Libre Office Calc, make New document, close all other Calc documents, make MsgBox macro, save, save document as bug.ods, close, open: macro will be lost. My platform: Linux Mint 13 Maya, Libre Office 3.5.4.2 Build ID: 350m1(Build:2) (the Ubuntu build). I have another document that *does* manage to keep its macros.
Tried this: Open Libre Office Calc, make New document, close all other Calc documents, make MsgBox macro, compile (see Joel Madero's comment on 50648) save, save document as bug.ods, close, open: macro was lost as before.
Currently I experienced some problem in 3.6.2 on RFR 64 bit When working with macro, time to time tool "Save" on toolbar not becomes enabled after changes in macro. The same problem with forms. I have lost today one freshly created form when closed document. No warning appears. But comment 13 is something different. There macro is lost. But how it lost? LO crashes or macro disappears from document?
Created attachment 69314 [details] A Libre Office Calc document that can save its edited macros.
@Sasha: Libre Office quietly forgets all it knew about about the edited macro. Save in macro editor, quit editor, save document, close document. All nice and quiet. Open the document: all changes lost; document macros are unchanged by the edits.
@Sasha: Oops, wrong document. Libre Office quietly forgets all it knew about about the document's macros. New macro, write it, save in macro editor, quit editor, save document, close document. All nice and quiet. Open the document: all macros lost; document has no macros.
Re comment 16: Oops, wrong attachment. That one is a Writer document. I (or Libre Office) lost the Calc document that keeps its macros. Searching backups now...
Backup lost. Sorry. Can't supply a Calc document that is able to save its own macros.
With those instructions it works for me. I tested: New Document Create New Macro Close Macro Editor Save Document/Close Document Open Document Macro is there in it's latest form....I really want to nail this one down as it's a serious problem that has caused several of us major headaches. Without consistent steps to reproduce there isn't much that a developer can/will do about it
@Joel Yeah, I hear ya... gotta find a way to reliably reproduce this. Got my working one back from another backup. It's vba-practice.ods. My bug recipe made the bug when I saved a new Calc document as Microsoft .XLS, but the bug does not bite on a document saved as Libre Office .ODS. In other words, LibreOffice .ODS docs *can* (I think) save their own macros. I'm in soggy New Jersey, so can pound away on this some more...
Just did a test with .doc....worked fine.....now I'm getting frustrated trying to figure out how in the past I've lost HOURS worth of work.
OK, try this to reproduce bug 42899: Open Libre Office Calc, make New document, write a simple MsgBox macro for Untitled, quit macro editor, save new document as Microsoft Excel 97/2000/XP/2003 (.xls), name document as bug, save, close, open bug.xls: macro will be lost; bug.xls will have no macros. Make New document, write a simple MsgBox macro for Untitled, quit macro editor, save new document as ODF Spreadsheet (.ods), name document as nobug, save, close, open nobug.ods : macro will be there and functional.
BINGO! Marking as NEW, keeping priority, also marking as MAB. Confirmed on master as well as 3.6.1.2 Thanks for getting to the bottom of this one. This is a major concern
Just curious -- what's MAB? Don't see it on https://bugs.freedesktop.org/docs/en/html/lifecycle.html
That's an internal thing we use :) You wouldn't see it on that diagram. Just supposed to ping the developers and what not, let them know to look at this one as soon as possible. Why did you mark this as NEEDINFO? I've confirmed it as NEW. In general once a QA member has changed status, the status shouldn't be changed again unless there is a comment explaining why :)
Oops, forgot to mark it. Marking it NEW.
I have also lost Writer macro changes quite often through this bug. My "workaround" was more or less crude force: simply saving very often from the macro editor and saving macros to bas files after extensive edits. But the steps listed in Comment #24 are not related to this bug. LO is working as expected: Basic macros are not saved to Microsoft file formats. Word and Excel cannot execute them. Joel, I wonder, did you really manage to save a Basic macro to DOC (Comment #23)? DOC and XLS can only store VBA macros... I think the bug must be related to regular file save and autosaves somehow interfering with each other, as Apache-OOo-Bug 112775 suggests. Try to reproduce the steps given there: > 1. Ensure the Save AutoRecovery option is turned on. For convenience, > set the time value short, like 2 to 5 minutes. > 2. Create a new document (spreadsheet and text documents have been tested) > Create a Module (Module1 by default). Save the document. Optionally, > open an existing document that contains a Module. > 4. Modify the Module (for example, add a comment). > 5. Wait for the autosave action (indicated by a 'saving' message in the > status bar, which can be very quick in a simple document and thus difficult > to see) or wait at least as long as the autosave minutes option is set to. > 6. Close (Save) the document). > 7. Open the document. Look at the Module. (The change you made is probably > not there.) (https://issues.apache.org/ooo/show_bug.cgi?id=112775#c0) I could reproduce the bug that way (Ubuntu 12.04, LO 3.5.4.2). You can also see that saving the file from the macro editor works as expected.
I'd have to go back and see through my stuff....interesting points though and you're probably correct. I'd recommend to a develop that there absolutely MUST be a warning pertaining to this so people don't lose work. Only experienced users/devs would knot that basic macros cannot be saved with doc -- again I'll have to check on this but it sounds right to me. You shouldn't be able to save any document with a macro and be able to close it without some trigger saying "is there a macro, and has this macro been changed/edited" Leaving as NEW still just because I think between the two cases (your steps along with #24) there is ample evidence that this needs to be looked at and a developer needs to decide the appropriate steps to take.
Oh, I see. Then 2 different issue have been mixed up during the discussion: (1) Macros not always saved to ODF file formats Basic macros are not always saved with the regular file save, as described in Apache-OOo-Bug 112775: https://issues.apache.org/ooo/show_bug.cgi?id=112775 (explicit saving from macro editor seems to work) (2) Macros are generally not saved to export file formats (DOC, XLS, DOCX, XLSX) Basic macros are never saved to Microsoft file formats (and cannot, because the file formats are not specified for LO/OO Basic); LO/OO may eventually be able to edit and save VBA macros, on the other hand - in the distant future. (1) is a regular bug, while (2) is more about conveying a limitation to the user. (2) is a bit difficult. It's not only Basic macros that are lost in export filters but all formatting options that LO supports but the export file format doesn't. When saving in export file formats, LO shows a warning dialog saying that only ODF formats guarantee all content will be saved, and it offers to save in ODF. So the dialog is there, but unspecific, and people remove the tick for the warning at some stage, so it won't show up again. One solution could be to use a similar warning dialog when the macro editor is opened. People would eventually disable that warning as well, of course, but it would probably make a deeper impression on users...
hm, perhaps I need to open a new enhancement bug then....or I'll wait until a developer request me to do so ;) I have already pinged Michael and Bjoern to see if we can find someone to tackle this one soon (I guess bug #1, but maybe they can do #1 and enhancement request #2) :)
A further note, it seems like #1 was my issue not the Excel not saving the macro. I just checked a few of my larger macro files and they are all .ots and I remember losing a ton of data from these because of the bug where saving the document not always saving the macro
Re Comment #23: I tried saving a macro with a Microsoft Word 97/2000/XP (.doc) document, and it was not saved. Now that Comment #29 and Comment #31 explain this, it makes sense.
Another possible WORKAROUND: before exit Basic IDE or after making changes, switch to editing dialog (create new dialog if needed) using tab in left bottom of IDE window. Then back to previous tab. Tool "Save" (diskette) on toolbar of Basic IDE will be now enabled if present non-saved changes.
Confirmed comment #31 - saving macros to .xls / .doc and the 'x' versions is a research level task: in fact we have some code that does this - but it's not enabled (yet) for various reasons - it needs some hard-core testing and more thought. So - altering this one to reflect the more tractable autosave issue.
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=af34774d260a68fc02cd78ba90dd8d4afaf1a2a4 hopefully this fixed the strange autorecovery related dataloss fdo#42899 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
since I proposed a patch probably makes sense to assign myself
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c2816cf4b51fd84aa530653acaa48112bb55a4a6&h=libreoffice-4-0 hopefully this fixed the strange autorecovery related dataloss fdo#42899 It will be available in LibreOffice 4.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Closing according to comment 39. Please reopen if you find it non-working in the next available build.