Re^2: Lite.pm Causing Problems

jcb: No, nor will applying undef to your globals fix the problem. The problem is that, somewhere in your code, a Win32::OLE object handle is getting corrupted, and the destructor in Win32::OLE::Lite is finding that a resource it is supposed to release is not there and complaining about this state of affairs.

So you havent heard of global destruction phase? Super Search cures what ails ya

Comment on Re^2: Lite.pm Causing Problems

Replies are listed 'Best First'.
Re^3: Lite.pm Causing Problems by jcb (Parson) on Sep 06, 2019 at 04:05 UTC
Using `undef` will merely move the error from the end of the output to the middle of the output. The `DESTROY` method will be called at some time, and the only solution is to ensure that the object is valid when it is called. A small addition: if the corruption is occurring due to the undefined order in which global destruction is carried out, releasing the last reference prior to global destruction will resolve the problem. But you do not know that that is the case — there could be a bug in the questioner's program that is corrupting the object or global destruction may be trashing it before destroying `Win32::OLE::Lite`. You. Do. Not. Know. Which. Is. Happening. Here.	[reply] [d/l] [select]
Re^4: Lite.pm Causing Problems by Anonymous Monk on Sep 06, 2019 at 04:20 UTC
At the end of the output you can't do nothing about it :) in the middle you can	[reply]
Re^5: Lite.pm Causing Problems by jcb (Parson) on Sep 06, 2019 at 04:27 UTC
What? If anything it is easier to chop off of the end by adding an end marker to the intended output and using `sed` to remove anything after that marker. Oh wait, our questioner is using Windows and therefore probably does not have `sed` installed. And why did writing this feel like answering Insane Troll Logic?	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.