Button tabs in PC and NPC sheet

[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_original_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.