Created attachment 82726 [details] This Writer ODT file contains code that demonstrates the problem. Problem description: The method “replaceByName()” in the interface “com.sun.star.container.XNameReplace” is used to change the contents of a BASIC Module so it can be made to execute different code. If the BASIC IDE Window is open and is displaying a module from this program, then, after executing “replaceByName()” to a Module, the module continues to display its original contents and does not update to display its new contents. If the document is saved, closed and then relaunched, a review of the replaceByName module will find that its contents were in fact updated. Steps to Re-Create the Problem: 1. Create a new Writer ODT document, call it Test.odt and save it to disk. 2. Manually create a BASIC module named Module2, and observe its contents. 3. Insert the following subroutine into Module1 sub Main BasicLibraries.getByName("Standard").replaceByName("Module2", "REM Replacement Module2") end sub 4. Start execution of the sub Main in Module1 5. Observe the contents of Module2 – Nothing has changed 6. Re-save Test.odt 7. Close Test.odt 8. Launch Test.odt 9. Observe contents of Module2. Now it contains, “REM Replacement Module2” The attached Writer.odt file has code that better demonstrates this bug. It inserts executable code into the replacement module and then proceeds to execute it. It is observed that the correct replacement code is executing, but displaying the code in the IDE Code Window for the module shows it still contains its original code. Current behavior: After executing replaceByName() a module has its contents updated and if its code it then executed it will execute the updated content. However the IDE Code Window does not display the updated contents of the module. Expected behavior: After executing replaceByName() a module has its contents updated and if its code it then executed it will execute the updated content. The IDE Code Window will display the updated contents of the module. regards, ian. Operating System: All Version: 3.3 all versions
This problem may be related to: Bug 67116 Macros: RemoveByName with IDE Code Window open causes program flow termination. Note: I was able to observe this problem with LibreOffice V4 versions on Linux 32-bit and 64-bit, Windows XP intel 32 bit, and Mac PowerPC. As I do not have LibreOffice V3.3 I can not prove that the problem actually existed at the time, however I suspect it is likely that it did. regards, ian.
@irs is bug still here with current 4.1.1 release?
I move this to NEEDINFO. please tell us if the issue is still there with recent (4.1.3) LibO releases.
(In reply to comment #3) > I move this to NEEDINFO. > please tell us if the issue is still there with recent (4.1.3) LibO releases. Hi Tommy, The bug still exists using a more recent version of LibreOffice (x86_64 bit): $ libreoffice --version LibreOffice 4.1.3.2 410m0(Build:2) This is on the Linux 64-bit platform: $ uname -a Linux ian-ubuntu-13-10 3.11.0-15-generic #23-Ubuntu SMP Mon Dec 9 18:17:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux I tested for the bug using the Bug Demo code https://bugs.freedesktop.org/attachment.cgi?id=82726 If the IDE Window is closed, then after running the Bug Demo and opening the IDE Window the NewModule with the replaced code does correctly contain the replaced code. The bug occurs when you start the Bug Demo with the IDE Window open as though you are editing Module1 of the Bug Demo program. Upon completion of the demo the NewModule that had its code replaced, is still displaying the original code that it contained. I don't know the internals of LibreOffice, but my guess regarding the cause of the problem is that the IDE Window modules code is not being update to display the cached / memory resident module code. regards, Ian.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO