PDA

View Full Version : When does onClose() for a Windowless lua script get called?



Varsuuk
August 9th, 2019, 00:42
** Edit: Oop, please ignore “Windowless” above, I wondered why people assumed that when I was referring to a file script used by char_main.xml file. It is a script attached to windowclass not global - Sorry **

I tried to set it up like a good little C++ boy and then to test I put trace code and only saw it register on onInit but never deregister.

Under what conditions does anything call onClose()? If not normally deterministic, is there a way to request it to test my code a la java force GC type hints?



function onClose()
local nodeChar = getDatabaseNode();

DB.removeHandler(DB.getPath(nodeChar, "abilities.*.score"), "onUpdate", updateAbilityScoreDependencies);
DB.removeHandler(DB.getPath(nodeChar, "abilities.*.baseautomod"), "onUpdate", updateAbilityScore);
DB.removeHandler(DB.getPath(nodeChar, "abilities.*.baseracemod"), "onUpdate", updateAbilityScore);

OptionsManager.unregisterCallback("HouseRule_SavingThrowMethod", onSavingThrowsOptionChanged);
end

Trenloe
August 9th, 2019, 02:24
onClose is based on a windowinstance: https://www.fantasygrounds.com/refdoc/windowinstance.xcp#onClose So it doesn't make sense in a script scope that is windowless.

Maybe provide some context of what you're trying to do?

celestian
August 9th, 2019, 04:02
onClose is based on a windowinstance: https://www.fantasygrounds.com/refdoc/windowinstance.xcp#onClose So it doesn't make sense in a script scope that is windowless.

Maybe provide some context of what you're trying to do?

I'm guessing he's talking about a "global script". While you can have an onClose() for those there really isn't a need unless you want to dump out something to file? Far as I know when you close/go back to campaign select all of those handlers/registers are removed.

Ikael
August 9th, 2019, 15:45
If you need to do something when desktop/vtt is closing you can use https://www.fantasygrounds.com/refdoc/Interface.xcp#onDesktopClose

But in general no cleaning is required for Global scripts.

Varsuuk
August 9th, 2019, 18:12
Thanks guys. I just wasn’t sure since I saw that sort of addhandler/removehander registercallback/inregcallback, etc behavior in 5E’s char.lua, 3.5’e charmain and of course a more full reg/unreg in Celestian’s fine 2e :) which I looked at a lot at the start before deciding to go minimal and add.

It appears in what I posted above I didn’t include info I listed in the prior thread I started, sorry.


In the Breaking up Lua file thread, I listed which lua file I was working on:


<root>
<windowclass name="charsheet_main">
<script file="campaign/scripts/char_main.lua" />


I’m sorry, I was flying that day with crazy delays and probably forgot what thread was on (got home today 3:25am)

So this lua file is supposedly not global ;) it is attached to the charsheet_main window.

I ran across this because I was moving my handler for Options from a control to the more general window lua script. I wanted to test set it up right and added the logging on init/close

Side note to Moon (if see): I THINK I was seeing the same multiple messages when I hit the options choices - more on that when I look up my old post here where you said I think it was a big to look at. I want to see the orig case and make sure still seeing it before start a new thread)

Varsuuk
August 9th, 2019, 18:15
PS - I don’t “need” to do anything of my own accord. Just trying to match existing patterns. Obviously from a C++ POV, I expect this sort of thing and patterns like RAII.

So if told not called, fine be me if that’s right. I haven’t added code I needed for my work - just for what I thought was proper plumbing.

Trenloe
August 9th, 2019, 20:40
Saying "windowless" in the thread header threw everyone...

Varsuuk
August 9th, 2019, 22:18
Argh - you are RIGHT, I was thinking of the CharManager to be honest when started writing and hen realized it was the window lass one.

I totally wasted everyone’s time in confusion. That day was hell. Dying to leave work to go get some sleep. <3 hours so far 30hours hurts ;)


So yeah, It didn’t SEEM (sleep deprivation?) to call onClose() as my Devug.console(“onInit”) prints but not Debug.console(“onClose”)

I won’t get a chance prob to look today as I will prob crash early. Thanks all.

Varsuuk
August 13th, 2019, 04:57
Hmmm ... this got "fixed" for me too...

Moon, was this also changed from like March of this year on?
Right now, notice the onClose() printouts that I had for the Windowclass are now logging as I hit reload and before I removed them the ones for globals threw errors saying unavailable global index or something on Debug ;)

Darn softlinks...

Moon Wizard
August 15th, 2019, 22:43
It's because window instances are closed (and trigger onClose event), before global packages are unloaded. Global packages (both built-in and custom) are unloaded all together, which is why Debug package calls in onClose of a global package will throw an error in many cases (because Debug unloaded first). In FGU, I believe I already fixed it so that custom global scripts are loaded after built-in packages, and unloaded before built-in packages.

Regards,
JPG

Varsuuk
August 15th, 2019, 22:47
I totally get that :) (and good to hear about the change - basically when poss ctor and dtor functionality are mirrors)

But what I meant is thanks to you correctly guessing I had an unpacked CoreRPG of Yore in my directory (March), that’s why the Options callback was still double. I wondered if you also did something since March on the onClose() since I never noticed ANY onClose() printouts or errors for sure prior to my removing that older CoreRPG pack.

Was curiosity, no answer needed as both are working fine now for me. Was all self-inflicted ;)