Button tabs in PC and NPC sheet

[SilentRuin]

I'm unsure what is being done with tabs now.

Previously had overridden common/scripts/buttongroup_tabs.lua to provide a call back function so that I knew when tabs were clicked. This required overriding numerous functions to allow the trigger of the callback. The code is common for both PC and NPC sheets so does not need to distinguish which is which.

When I ran with TEST - the PC sheet did not seem to have an issue. All good.

But as soon as I brought up an NPC sheet the

self.parentcontrol.window.tabs.setCallback (PolymorphismManager.TabsCallback, self);

function call setting the callback (same as in PC) claimed "tabs" was nil.

I need to understand how to recreate my stuff in this new world where PC and NPC tabs have somehow diverged.

So what has happened with "tabs" and how to do I implement my buttongroup_tabs.lua functionality that lets me know when tabs have been clicked or double clicked or whatever I do in my override.

I have had to replace code that added a tab into an NPC sheet - but that does not really tell me how or where the functionality I had in this buttongroup_tabs.lua would go.

[bayne7400]

You need to just do this
<windowclass name="npc" copy="record_window_tabbed">

and add your tabs like this
<tab>
<name>main</name>
<resource>tab_main</resource>
<class>npc_main</class>
<embed />
</tab>
<tab merge="add">
<name>inventory</name>
<resource>tab_inventory</resource>
<class>npc_inventory</class>
<embed />
</tab>

<tab merge="add">
<name>psi</name>
<resource>tab_powers</resource>
<class>charsheet_powers</class>
<embed />
</tab>

none of it is in sheedata

[SilentRuin]

As I said - I already updated things where i had to add tabs in - so this is known to me already.

I have code that intercepts the low level code to determine when a callback is made when a tab is selected - and it still works in PC but not in NPC. I need to know how to DO what I was doing with existing tabs - nothing to do with adding tabs.

Also the fact PC and NPC are now doing things differently for tabs is wrecking the common code - though I don't understand how I'm to replace that in the new tabs of NPC or if PC will eventually become common way of doing tabs.

Its all confusing right now and I'd like a hint on if the buttongroup_tabs.lua is still in play in the new way - and if so what I'm supposed to do to access the tabs as it used to be self.parentcontrol.window.tabs in the window access - what is it now?

Going through another many hour deconstruction code hunt is not something I want to do again, as I've already done that twice for two different update changes in this TEST round.

[SilentRuin]

I'm going to assume "hope" that the code is still the same at the low level for tabs and that the self.parentcontrol.window.tabs has just moved location. Trial and error here I come (sigh).

First guess will be [Wrong guess - here we go (sigh)] - but with my luck I'll be doing Debug.console prints of these till I can find where its at.

Its just going to be a pain to support PC and NPC differently (guess I'll have to check where tabs is for both now?).

[LordEntrails]

Have you asked Moon for help/clarification via Discord? Seems like he's willing to help if he's available.

[SilentRuin]

Having wasted his time on a corrupt (I assume) campaign in discord where the problem could not be duplicated anywhere but on my machine - I figured he'd get to this when he can.

I'm going on two major assumptions:

1) The underlying common/scripts/buttongroup_tabs.lua has not changed - just the location of "tabs" in window references has. The "/debug on" chat option seems to show its still in the same place - so there must be some trick to getting the window reference correct.

For PCs - which still work as they used to:

Type: genericcontrol
Window: charsheet
Control: tabs
Frame(tabs)

reference control from my subwindow as

window.parentcontrol.window.tabs

works. This is the same path that used to work with NPCs also.

For NPCs - which no longer work as they used to:

Type: genericcontrol
Window: npc
Control: tabs
Frame(tabs)

the reference no longer works with
window.parentcontrol.window.tabs

So I'm guessing with no luck on where it went with Debug.console(window.parentcontrol.window.getContr ols()) - its just no longer where I would think it would be. Stuck randomly guessing now how to access it.


2) That PC and NPC will be the same reference as they used to be at some point.

Gist being - this should be simple to figure out - but its not. No idea why. My subwindow is "invisibly" present in both sheets so one would think if I can back track to parentcontrol.window I'd be at where I was.

[SilentRuin]

I'm going to have to wait for clarification from @MoonWizard as I don't understand how the "/debug on" chat option is telling me the control is in same place relatively as it was before - but can't be referenced. Looking at the code it goes down into record_window_tabbed for the NPC while the PC is still as it was. I'm beginning to think there is no commonality with things I overrode in LIVE anymore - or at least a disconnect between PC and NPC sheets now.

Yeah its the ultimate nightmare with two tabbing systems and no direction on how to port from old one. I'm guessing at this point common/scripts/buttongroup_tabs.lua is not longer used at all in NPC and instead some new manager_window_tab.lua along with some other new undocumented wonders will have to be done from scratch by me to get my old callback logic.

I'm going to wait for feedback before I try to guess my way out of this one. It's to convoluted to move from the current tabbing PC mechanism that works still - to the new NPC tabbing mechanism which I'm beggining to suspect I will have to redesign and start from scratch. That way I can gain - nothing - and be back where I was. Maybe.

[SilentRuin]

Just to be absolutely clear on what I'm doing with tabs:

I override common/scripts/buttongroup_tabs.lua with new tab functionality.

I use "tabs" for PC and NPC as follows:

self.parentcontrol.window.tabs.setCallback (PolymorphismManager.TabsCallback, self);

local nActiveTab = window.parentcontrol.window.tabs.getIndex();

local sSub, sDisplay = window.parentcontrol.window.tabs.getTab(nActiveTab );

I now realize I have .main_creature references all over the place (including TabsCallback) that will have to be rewritten also (triple sigh). This brings up another reference issue on how you reference the new NPC main window?

Previously it was from NPC level:

window.main_creature

Not sure what it is now.

[SilentRuin]

Wow. And its even more confusing. I printed out my window.getControls() for the NPC window to figure out what to replace main_creature with (it's main) and I see the "tabs" in that reference. But clearly do not when backtracking through parentcontrol in the other extension's reference.

I need to stop giving a running commentary as it reads to me as "insane". Yet true.

[SilentRuin]

Well one thing I've found is that self.parentcontrol.window.tabs called from a subwindow's onInit is evidently not present yet. Its completely shifted where its put into the window structure so that the attempt to access it as part of a subwindows init gets nil. I found this out by pushing past that failure to see what happens and later the code found tabs in the same reference (after app was up and initialized fully).

I swear this update is trying to drive me nuts.

[Moon Wizard]

That's a lot to parse; and I have very limited time at the moment. Can you simplify what you are trying to accomplish in 2-3 sentences?

Thanks,
JPG

[SilentRuin]

1) My specialized tab logic works fine for PCs but not for NPCs - it appears they now support two different types of tabbing. Before it was one common one - but now I need to support two? PC still works with my stuff NPC does not.

2) I have an override of common/scripts/buttongroup_tabs.lua so I can get callbacks on tab changes and maybe some other things. Will this work for the new NPC tabbing?

3) I reference from my subwindow's init the following to access these tabs functions (works for PC):

window.parentcontrol.window.tabs

Which is nil in its onInit (PC works - NPC fails). This appears to be there later after the full app is initialized - making me think the new tabs in NPC is no longer done at the same level as the tabs for PC - breaking that attempt to set my callback for tab changes.

4) I doubt this can be summarized as you wish - but I'll stop here. Basically, my functionality that works with tabs in PCs no longer works with NPCs and trial and erroring down to point I can figure out what is going on is taking forever.

[SilentRuin]

5) May be another order change between PC and NPC initializations of windows - it appears I also have trouble accessing the "main" reference from my subwindow also (window.parentcontrol.window) - works with PCs - fails with NPCs.

[Moon Wizard]

1) The tabs on the character sheet and NPC sheet are initialized differently.
2) Overriding this script will be problematic, since this is part of the automation for tab initialization now. Plus, there are regular tabs and button tabs (aka Dune/Fallout/STA).
3) The tabs control will be added dynamically to a window by the onInit script, so you can't access the control until it is initialized.
5) The subwindow controls will be added dynamically to a window by the tabs control and the WindowTabManager script. You won't be able to access the windows unless they are initialized. If you need to make data changes, you should change through the database, rather than through window/control navigation.

Regards,
JPG

[SilentRuin]

1) The tabs on the character sheet and NPC sheet are initialized differently.
2) Overriding this script will be problematic, since this is part of the automation for tab initialization now. Plus, there are regular tabs and button tabs (aka Dune/Fallout/STA).
3) The tabs control will be added dynamically to a window by the onInit script, so you can't access the control until it is initialized.
5) The subwindow controls will be added dynamically to a window by the tabs control and the WindowTabManager script. You won't be able to access the windows unless they are initialized. If you need to make data changes, you should change through the database, rather than through window/control navigation.

Regards,
JPG

So basically, what I did before defining one generic subwindow to be added into the top of any tab based on which tab name was activated - kiss it all goodbye because we don't support that kind of thing anymore?

This update has taken up so much of my time breaking down what was done, so that I can try to redesign what I already had working, that I'm about totally burned out.

Extensions = RISK

And when the RISK is to much - let them go. The next update like this one and I'll do just that, let someone else maintain them if they wish. This is not worth this amount of effort just to "keep them working as they did".

[Moon Wizard]

Why can't you just add the generic subwindow to the top of the individual window class for that tab, so that it automatically gets instantiated when that tab gets instantiated?

Regards,
JPG

[SilentRuin]

Why can't you just add the generic subwindow to the top of the individual window class for that tab, so that it automatically gets instantiated when that tab gets instantiated?

Regards,
JPG
You mean redesign it so that it’s hardcoded into each tab class it needs to be in with new logic to determine when it gets added into top and move the other windows down if anchors are hardcoded (as they were at one time) instead of being relative as they should be?

Yeah. I know. Even though PCs work I can’t trust the old generic code that was not specific for PC or NPC because they have just diverged on how they handle tabs.

Thats known in the trade as a redesign after deconstructing what happened. To get back to “working as it did”.

Again.

[SilentRuin]

Before I waste another inordinate amount of time trying to push PC tab windowclasses down through windows calls because they have hardcoded fixed anchor points in sheets - is this going to be a huge waste of my time as you are somehow planning to redo those as you did NPCs?

[SilentRuin]

Never mind - as buttongroup_tabs.lua has changed completely since the days I overrode it (not even sure how PCs are working in my world) I'll just dump all that code and rewrite it from scratch based on what WindowTabManager.updateTabDisplay override can get me. Or at least that is what I'll try as I verified both PC and NPC call those now.

[SilentRuin]

Ok I've finally got to a point where it sorta coulda maybe might be working. Though only thorough testing "by my useless users" when it goes live will tell. That really means I'll find out the bugs when my first LIVE session with this TEST comes up of course.

So in case this horror saves anyone else time I'll go over some key points in the new world order of tabs...

I ditched all overrides of the buttongroup_tabs.lua and associated code using them and started over.

I override


-- in order to support tracking what tab is activated or deactivated so poly window can be added or removed
savesetTabDisplayVisible = WindowTabManager.setTabDisplayVisible;
WindowTabManager.setTabDisplayVisible = setTabDisplayVisible;


To replace where i determine if my common charsheet/npc subwindow and if it needs to be enabled and what needs to be displayed for the current tab that is being displayed (or not). As I still have to move the other hardcoded anchor windows out of the way I preserve all my windows manipulation code so I don't have to redesign that nightmare either. But of course all the window references have changed so I'll show you what I determined through trial and error and deconstructing the actual new buttongroup_tabs.lua logic.

First, while charsheet windowclass still has tabs instantiated as they used to have - the npc windowclass does not. Plus their tab classes got renamed ("main_creature" is now "main" and "text" is now "notes"). This means if you - like me - have to call window anchor code and other visibility settings directly on the window you need to be prepared for this. I handle it by checking WindowTabManager.setTabDisplayVisible before I process any of my stuff (calling the original code first of course because I'm not EVIL extension developer like some).


-- determine what tab is activated or deactivated
function setTabDisplayVisible(w, tData, bVisible)
--Debug.console(User.getUsername() .. "(" .. tostring(Session.IsHost) .. ") -> manager_polymorphism:setTabDisplayVisible called");
-- call original code
savesetTabDisplayVisible(w, tData, bVisible);
-- update polymorphism subwindow visibility in tab that has main window initialized
if w.sub_polymorphism and w["main"] then
TabsCallback (w, tData, bVisible);
end
end


that will make sure any window I receive from the tab code is mine and is instantiated (not some empty callback - which you will get for NPCs now).

Then to do the many joyful things I have to do to make room for my common subwindow class (is actually deactivated part of sheetdata not part of the tab stuff) at top of most tabs and have different parts visible based on the current state of things I found these easter eggs for accessing the UI fields in the tabs...

To access my controls directly...


window.sub_polymorphism.subwindow


followed by the control name for example...



window.sub_polymorphism.subwindow.polymorphism_ori ginal_token.setPrototype(sOriginalDBToken);


and to access tab data to reset the anchors to make room for my sub window...



window["main"].setAnchor("top", "overview", "bottom", "relative", 128);
if window["skills"] then
window["skills"].setAnchor("top", "overview", "bottom", "relative", 128);
end
if window["abilities"] then
window["abilities"].setAnchor("top", "overview", "bottom", "relative", 128);
end
if window["inventory"] then
window["inventory"].setAnchor("top", "overview", "bottom", "relative", 128);
end
etc.



you would not believe what I had to do to find window.subwindow was no longer a thing to get to the tab named controls because charsheet actually still supports the old referencing - fortunately it also supports the new window["tabname"] referencing also. The npc sheet ONLY supports the latter type of referencing.

Also, I have my own mycombobox.xml/lua code that allows for selection boxes to be on top and prevent any clicks being processed outside of them (this can become a problem when a selection box overlaps past the subwindow boundary into another window area - the base combobox code does not compensate for this).

Anyway - if that helps more power to you. As usual it may not look like much to do this - but to deconstruct everything and figure out how to redesign it so that I could still do what I used to do - was incredibly time consuming. And super frustrating. I did rip out all the call backs I had to force a tab to refresh as tis good enough for now and if I lose some minor ability to keep things updated in all cases so be it.