windowinstance self and reference databasenode bugs

[Ken L]

Posted this in discord, reposting for brevity here.

It appears that for scripts defined in a windowclass the "self" parameter, though a windowinstance via type(self), cannot take windowinstance handlers such as onMove etc... You literally need to wnd = Interface.findWindow("myclass",self.getDatabaseNode()) to get a windowinstance which you can attach handles to.

Also you can't put DB handlers for non-local DB nodes via DB.addHandler("reference.npc.*") format. DB.addHandler("npc.*") works for local NPCs. Unless there's a way to have it affect all global nodes like DB.getChildrenGlobal

[Moon Wizard]

For the window handler registrations, it seems to be working in the examples in CoreRPG. See campaign/scripts/table_main.lua. I added a Debug statement in handleSizeChanged, and it gets called when initializing and resizing.

For the DB handlers, have you already tried "reference.npc.*@*" for your handlers?

Regards,
JPG

[Ken L]

Neither will work on 3.3.7.

I have not tested your particular example for the handle. In my case, I attach a moveHandler to onMove on Init with self.onMove = moveHandler. Which does not work. However using Interface.findWindow with self.databaseNode for the reference, the window reference returned works. No errors are thrown, it simply seems to be unassigned. I haven't checked the self.onMove reference to verify the write but I shouldn't need to.

reference.npc.*@* does not work, this is an easy example to replicate. If I have time this week, I'll upload an example extension illustrating both of these issues on 3.3.7.

As an addendum, Interface.onWindowClosed always has nil for the database node. I have an extension that relies on this to perform cleanup. My workaround is to iterate through all open windows of the windowclass against a dictionary of string dbpaths to see which one doesn't exist, and mark that as the one that closed for further bookkeeping.

[Moon Wizard]

Handler registration (onMove, etc.)
I was running v3.3.7 when I used the debug output from the table_main.lua script in the handleSizeChanged function. There must be something specific to where/when you are calling that is causing the self reference for handler registration not to work. Try testing for yourself on the CoreRPG example.

DB.addHandler
I was able to test this successfully on v3.3.7 by adding this code to a global script:


function onInit()
DB.addHandler("npc.*.name@*", "onUpdate", onUpdate);
end
function onUpdate(nodeNPCName)
Debug.chat("NPC NAME UPDATED", nodeNPCName);
end

which gave this output when I change the name in a module NPC record:


s'NPC NAME UPDATED' | databasenode = { npc.a_tan.name@DD Tomb of Annihilation }


Interface.onWindowClosed
Thanks for pointing this out. This was a by-product of having to update the entire window shutdown ordering to allow close() to be called during certain events (such as onInit). I will post a patch for v3.3.7 shortly.

Timing
I will most likely not update the client to resolve any specific coding issues like these for v3.3.7 unless I get them in the next day or two, since we are launching next week on Tuesday. It just depends on what the reasons are for the things you're seeing, how soon I get the information, and whether it's something that should be changed.

Regards,
JPG

[Ken L]

So there seems to be an odd confluence of events that cause this to happen. I perhaps have to replicate more of subwindow nesting to reproduce it later.

*edit* : It was due to it assigning it to the subwindow and myself forgetting the scope, problem resolved

Regarding the DB.addHandler, npc.*@* works, however reference.npcs.*@* does not. Since this wasn't documented I simply replicated data_library.lua's address for references as sans scouring every addDBHandler, there was no obvious usage of binding to wildcard module nodes. This is different from (reference.images, reference.npcs, etc...) that was invoked in DB.getChildrenGlobal. I'm guessing there's some reason for this discrepancy?

[Moon Wizard]

What event are you trying to capture on "reference.npcs.*@*"?
The code is not any different in the handling of "npc.*@*" vs. "reference.npcs.*@*". The main different is that reference.npcs is typically read-only (i.e. static), since the reference node is set to static for large majority of modules.

Regards,
JPG

[Ken L]

What event are you trying to capture on "reference.npcs.*@*"?

WI was trying to get module DB updates. In particular I was interested in category changes.

npc.*@* might seem obvious in "hindsight" vs reference.npcs.*@* but there was no documentation as to what address modified modules nodes would fall under, so I just replicated the address found in data_library.