https://bugs.documentfoundation.org/show_bug.cgi?id=172748
--- Comment #5 from [email protected] --- (In reply to Neil Roberts from comment #4) > (In reply to Dmitry.Kulikov from comment #3) > > > As for saving macros, I consider this a genuine bug involving content loss, > > and the target format is irrelevant. Macros are lost in the LibreOffice -> > > xlsm -> LibreOffice cycle; Excel plays no role. The user saves their file, > > opens it again in LibreOffice, and the macro code is gone. I believe this is > > data loss within the product itself, regardless of whether someone opens the > > file in Excel. The goal of my patch is to protect user data, and the warning > > is too general. > > I think it’s inevitable that there will be data loss when saving in an > non-native format, which is why LibreOffice warns about it. Even with the > patch there will still be a kind of data loss because saving in xlsm will > force VBA-compatibility mode. This can change the behaviour of the script so > the user will still not have the same macro they had before they saved the > document. Regarding the concern that saving as .xlsm enables VBA compatibility mode and can change the script's behavior, I checked this before saving and after reopening the .xlsm file. The source code is saved verbatim, and the macro works the same. There may be some very specific constructs that can change the behavior after reopening the file, but it's still much better than having no code at all after saving the file. > > Perhaps you could explain the intended use case for saving in xlsm? If the > user wants to give the document to someone using another piece of software > then the patch won’t help because the macro will be written against > LibreOffice’s dialect of BASIC so it won’t run. Otherwise if they are giving > it to another LibreOffice user then why wouldn’t they save it directly in > ODT? > > > As for saving macros in VBA-compatible mode, I don't think they interfere > > with each other; they complement each other rather than being alternatives. > > My patch fixes the immediate data loss, and VBA-compatible macros in a new > > document is a separate, useful improvement; I'm willing to file a separate > > bug for it. But this new fix alone will not fix the loss of macros when > > saving in a non-VBA-compatible mode. > > I think providing a way to create VBA macros from scratch would fix the > issue in this bug of the behaviour being inconsistent. Then it is simple, > VBA macros are saved when using a document format where only VBA macros are > usable, and all other macros are discarded. If the user wants make a > document that will be usable in Microsoft Office then they have the option > to create VBA macros. Otherwise they save in the native LibreOffice format. Your position is completely understandable, but there are scenarios where my patch is genuinely needed. Here is a specific example: An organization keeps its documents in MS Office and decides to fully migrate to LibreOffice. Over the years, they had accumulated a huge number of documents in the .xlsx format, and then needed to automate them. Converting a large number of files to LibreOffice’s native ODF (.ods) format is a very labor-intensive process and can lead to unexpected consequences, such as formatting changes or data loss. Therefore, the safest solution is to convert the necessary documents to .xlsm format. Then the user opens the .xlsm files in LibreOffice, starts writing macros, these macros run, make some changes to the file, and then the user simply presses Ctrl+S, saving the file in the same .xlsm format. The next time the user wants to make new changes to the file, for example, edit their macros, opens it, and the macros are gone. In this scenario, it doesn't matter that the macros are incompatible with Excel, since the user is working in LibreOffice. That's why it's crucial, at a minimum, to preserve macros when saving as an .xlsm file. -- You are receiving this mail because: You are the assignee for the bug.
