-
December 11th, 2018, 21:30 #1
windowinstance self and reference databasenode bugs
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.getDatabaseNod e()) 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
-
December 11th, 2018, 22:02 #2
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,613
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
-
December 11th, 2018, 23:29 #3
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.Last edited by Ken L; December 11th, 2018 at 23:35.
-
December 12th, 2018, 00:17 #4
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,613
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:
Code:function onInit() DB.addHandler("npc.*.name@*", "onUpdate", onUpdate); end function onUpdate(nodeNPCName) Debug.chat("NPC NAME UPDATED", nodeNPCName); end
Code:s'NPC NAME UPDATED' | databasenode = { npc.a_tan.name@DD Tomb of Annihilation }
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
-
December 13th, 2018, 23:16 #5
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?Last edited by Ken L; December 14th, 2018 at 00:00.
-
December 14th, 2018, 00:23 #6
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,613
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
-
December 14th, 2018, 21:49 #7
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.
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks