Created attachment 182864 [details] The announced example for reproducing Tested only with Win 10.0 (Build 19043). (Also already tried with a virgin -except macro security- user profile.) If NOT the running instance of LibO is fresh or the used document loaded first time by the LibO instance: Trying to call a Basic Sub located in the component throws an error "com.sun.star.lang.DisposedExceptipon". A bit more detailed information you will find inside the attached example file. A bit of code and an example for a calling link helping to reproduce the issue are included. Reproducible on my system!
Addendum: The issue also shows if the second load is done with a COPY of the original file even if this has a changed URL.
It also happened in 7.3.6.2.
I can confirm that for LO 7.4.3.2 (x64) Same problem happens when assigning a trivial sub to the document open event and reopenning the doc without closing LO: sub doNothing end sub Same problem happens with python: def doNothing(*args): result = 17*4
(In reply to ms777 from comment #3) > I can confirm that for LO 7.4.3.2 (x64) > > Same problem happens when assigning a trivial sub to the document open event > and reopenning the doc without closing LO: > sub doNothing > end sub > > Same problem happens with python: > def doNothing(*args): > result = 17*4 Did you also test with a document-stored Python sub later called from the open document (not just onViewCreated) as I asked you? If so, please state this expressly and attach an appropriate example file.
Concerning the original report: For the BASIC case I missed to explicitly state that the bug only shows if the Sub is called via A LINK from a TextField inside a cell-text or from a respective HYPERLINK() result. Direct calls via >Tools>Macros>Run or via Sub or Function not directly concerned themselves are NOT afflicted. I did not yet test myself a call as onViewCreated handler.
There is a related discussion here: https://ask.libreoffice.org/t/85146
Regression after commit 3f768cddd28a2f04eb1ffa30bed4474deb6fbfc4 Author Miklos Vajna Date Mon May 02 16:25:31 2022 +0200 framework: avoid re-creating protocol handler instances all the time Comment 2 is likely wrong, this is a regression in 7.4, and is not backported to 7.3.
Just tested wit V7.3.6.2 (PortableApps Win32 on Win 10). Using the attrachment to the original report the bug did NOT show. @Nukool Chompuparn Please attach an example showing the bug for you under V 7.3.6.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4bcf6d9c905e7b5558ee8d9f7f616ce61eadb8f8 tdf#151376 framework: fix calling in-document macros with reused frames It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/961a322ec0a754b0c372a32de81a8e4c5f2190ea tdf#151376 framework: fix calling in-document macros with reused frames It will be available in 7.5.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/de1e46fcda2b8b805891baeec09228b5846ed34a tdf#151376 framework: fix calling in-document macros with reused frames It will be available in 7.4.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Testing with the originally attached file the bug is still living in V7.5.0.3 though it seems to suffer from a wqeakness now: The unexpected 'DisposeException' NOW only occurs if the file was RELOADED without being closed interim. If the reloading was ordered WITHOUT having closed the file in advance, the DisposedException still is thrown on the next usage of the link calling the Sub. Reopening.
Could you please open a follow-up bug for the additional problem? As far as I see, the originally reported problem is resolved. We try to have 1 fix for 1 bug, otherwise it'll be a mess. Thanks!
(In reply to Miklos Vajna from comment #13) > Could you please open a follow-up bug for the additional problem? As far as > I see, the originally reported problem is resolved. We try to have 1 fix for > 1 bug, otherwise it'll be a mess. Thanks! "One bug - One fix" is a good idea. "One bug(cause) - Many workarounds" is not. Sorry, I won't report a follow-up. If someone else goes this way, I will not oppose either. Explanation: 1. As I see it, the continuing misconduct was already addressed with the original report. 2. A bugfix should not deal with a specific manifestation, but fix the root cause of the problem. In this case, the cause is apparently that a document instance leaves traces when it is closed - possibly in preparation for reopening. Such traces should not exist. Without them, however, the newly created instance would not try to continue using a (disposed) script that the old one had provided. If a remedy is found in one case where not the cause is removed, but one of its effects is suppressed, the problem is not solved. And if another effect of the same cause is also suppressed without removing the cause, this is not an improvement, but a worsening: The cause is now hidden in such a way that it will never be worked on again, unless it develops a malicious effect in a different context Even if it is then treated, the now superfluous workarounds will remain in the code.
[Automated Action] NeedInfo-To-Unconfirmed
I can't repro the problem that should be seen after reloading. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b5c3a7502f7ff6ccf0f829c1f3a2ba50b8584c41 CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6dfa9c7c0db91a71f3787226636864161d5367ca CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 23 March 2023
(Win 10, 64 bit) Tested again with 7.5.3.2: The unfixed variant of the bug (as seen from my point of view) still showed. Tested with 7.6.0.0.alpha1: The bug (as originally reported; both later distinguished variants) did not show. That's a bit strange to me because there wasn't an additional commit notification. Anyway: The bug seems to be finally fixede completely. Will test again with the final release of 7.6.0 Meanwhile "provisionally verified".
Tested with Dev versions 7.6.0.0.alpha and 7.0.0.beta1 Win 64 bit The bug is still living there. This for a vnd.sun.star.script: URL assigned to a text portion (textfield in this case) in a Calc cell and for the same URL passed as the first argument to a HYPERLINK() call.
Sorry! Typo! Read 7.6.0.0.beta1 in the respective place. (In reply to Wolfgang Jäger from comment #18) > Tested with Dev versions 7.6.0.0.alpha and 7.0.0.beta1 Win 64 bit > > The bug is still living there. > This for a vnd.sun.star.script: URL assigned to a text portion (textfield in > this case) in a Calc cell > and for the same URL passed as the first argument to a HYPERLINK() call.