https://bugs.documentfoundation.org/show_bug.cgi?id=77722
Gigi GD <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #12 from Gigi GD <[email protected]> --- Tested it on LO Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: fb4792146257752f54eab576deb869869b108571 The described effect is still there, but only if the security-settings for macros in LO are set to medium (and confirming to use macros) or low. The effect is: -------------- There is Basic-Code in Modules. That Basic-code has errors on compiling (syntax-error). After confirming those errors inside the Basic-Editor-GUI by clicking on "OK" one can work inside the Basic-Editor-GUI without problems. Clicking on the Calc-Workbook itself leads to the result, that the Calc-GUI is shortly displayed but then the Basic-Editor-GUI appears again, showing a syntax-error, which needs to be confirmed by clicking "OK". Concerning THIS XLS-File ------------------------- The first reason why there are basic-compiler-errors in this XLS-File is, that the #if #else #endif-directive from VBA is used. LO-Basic does not have preprocessing-directives, so the code can't work. Although LO ignores the #if-statement and does not complain about it, the effect is, that the statements in the #if part is executed just as well as the statements in the #else-part. In this case the result is, that a type-definition for "utc_ShellResult" is being executed two times, which result to an error. The question is: why this code is executed at all ? Answer: There is Workbook-specific Basic-Code because of the procedures "Workbook_Activate()" and "Workbook_Open()". If those procedures are existing, then LO has to call them when somebody tries to view or work on a sheet. But in order to call them, they have to be compiled. I guess, LO needs to compile ALL the code inside the file, to make sure, that the code works, because you never know, which procedures are being called from inside of "Workbook_Activate()". And on compiling the code inside the modules, errors occure. So the process is : 1. LO opens file 2. Calc-GUI is shown 3. Workbook_Activate() or Workbook_Open()-function is found in workbook-specific code 4. LO-Compiler tries to compile ALL the Basic-Code 5. Error inside the code of the modules 6. Basic-Editor-GUI is opening and error-position is displayed 7. Basic-Editor-GUI wants a confirmation of user by clicking "OK" 8. User jumps back to Calc-GUI 9. Jump to Step 3 (Workbook-specific code is found) => loop As soon as those procedures Workbook_Activate() or Workbook_Open() are existent and there is any error in Basic-Code inside of modules, then the described behavior occurs. That behavior is not specific to this XLS-file, it is a general behavior of LO and can be reproduced by a very simple file. The question is : is that a bug ? In order for LO to compile the workbook-specific-code, obviously LO needs to compile all the Basic-Code. I would not consider this a bug. LO is not crashing but with this constellation, it's just that you can't continue to view or work in the calc-sheets. Workaround: how do you close LO when it shows this behavior ? 1. Move the mouse at the bottom of the surface, where all the running programs/apps are shown. There you could close LO, using the operating-system functionality (on linux and windows) 2. That problem doesn't occur, if you set the macro-security-settings to high or very-high. Then the macros in this XLS-File are being deactivated. -- You are receiving this mail because: You are the assignee for the bug.
