Python macro assigned to document open event throws DisposedException when doc is reopened

English
, ,
#1

Hi,
I have a trivial python macro installed into the document. I have assigned it to the document open event through the UI.

def doNothing(*args):
    result = 17*4

If I open the document the first time, everything is o.k.
If I close the document without closing LO, end then reopen the document, I get a com.sun.star.lang.DisposedException.

This does not happen if I also close and restart LO. It does also not happen when I install the macro globally to MyMacros instead of storing it locally in the document.

Any help?

I am on LO 7.4.3.2 (x64)

Cheers ms777
document open event.ods (7.5 KB)

#2

This may be related to bug tdf#151376.
If your experiences tell you “Python afflicted like Basic” not only concerning onViewCreated action, you may report this commenting on that bug. You may even edit the subject there to “Basic or Python” in place of “Basic” then

#3

Thanks for the quick reaction! I added a comment in bugzilla.

Maybe some people with non windows operating systems can doublecheck, if this is system specific?

#4

@karolus, @Villeroy : Something for you?

#5

This is not a python only issue. It also happens in Basic, when you assign this sub (stored in the document) to the document open event

Sub doNothing
End Sub
#6

Yes, I know. I simply wanted to make clear that this only is about document-located scripts. On my behalf there isn’t a single related observation concerning profile-stored scripts - and I am using some of them called onViewCreated


#7

@ms777 Cannot reproduce the issue neither with »doNothing« in python or basic on event document open
with me:
Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Raspbian package version: 1:7.0.4-4+rpi1+deb11u3
Calc: threaded

@Lupp I miss the promised link in “disposedExceptionBug.ods” ?

#8

My experiments in OS Windows show that the conditions for the occurrence of the bug mentioned in the topic are as follows:

  1. In this (running) instance of LO, a document was previously opened that had an OnLoad event handler.
  2. A document is opened that has an Onload event handler, and at the time of opening this document there are no other windows open, except for the application’s start window.
    It does not matter the language in which the event handler is written and whether the document is opened from LO or through OS tools.

On Linux systems (available to me), the bug cannot be reproduced.

#9

Concerning the version:
The bug was reported by myself for V7.4.1.2. The backwards-next version I could test was V7.2.0.4 which didn’t show the bug for me. Meanwhile there was a comment telling that also V7.3.6.2 was afflicted, but the reporter didn’t update the version field of the bug respectively, and I couldn’t check.
My fresh versions always are Win X64. Old ones are PortableApps for Win 32 bit.

The link you missed is bouind to the textportion reading “An URL TextField” in bold. The field is contained in cell A2 but displayed in the area of B2.
If you permitted execution of document macros, it should be activated by either a simple click on it or using Ctrl+Click depending on your settings.
Sorry. I missed to also allow direct calls to the macro by prefixing an Optional to its parameter, and including a default.
The bug anyway only shows for calls via a link.
I will add this info to the bug report. When I originally reported I missed to do so.

1 Like
#10

I can’t confirm the conditions @sokol92 listed.
And I again emphasize that up to now the earliest version reported (by somebody else) to show the bug is V7.3.6.2.
In all the older versions I could test myself the bug was absent.

Also note: I did not test with Python, and I did not test a case where the document macro was called as an event handler.

I suppose, this is a bug where a somehow ticklish complex of conditions needs to be regarded.

#11

IMO, @Lupp confused things here by mentioning a different issue reported in tdf#151376. Another report is needed. The problem discussed here is a regression in 7.4. Specifically - after 3f768cddd28a2f04eb1ffa30bed4474deb6fbfc4 - core - Gitiles

#12

I was aware of the risk of upcoming confusion, and tried to narrow it down by the words “This may be
”.
I should have added that a comment claiming a wider scope should only be made if all the aspects of the original bug were checked, and everything was the same.
I am confident to not repeat my mistake soon - and this should mean ‘never’ in my case. Hopefully Mike will know remedy in this case of confusion I caused.

1 Like
#13

:slight_smile: @ms777 please file your own bug report.

#14

@mikekaganski, perhaps the two bugs are somehow related (?). :slightly_smiling_face:
With a “clean” profile:

  1. Change the macro security level
  2. Open LO
  3. Open and close the document “document open event.ods” (allowing macros).
  4. Open the document “disposedExceptionBug.ods” (by @Lupp) and click on the hyperlink. The specified exception occurs.
Version: 7.4.2.3 (x64) / LibreOffice Community
Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf
CPU threads: 6; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL
1 Like
#15

I doubt it: given that tdf#151376 is repro on 7.3.
Or comment 2 there was wrong.

And then it’s me who confused things here (and that it becoming more likely, when I tried to repro @Lupp’s bug with 7.3.0, and failed 
 it could still be something backported to 7.3.6, but now I doubt that).

#16

I also just tested with 7.3.6.2 (PortableApps) and the bug did not show. I reported commenting on tdf#151376.

Impressum (Legal Info) | DatenschutzerklĂ€rung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.