Stumped By GUILD_ROSTER Changes

[Deome]

So, for some time now I've had a neat feature in ddSK that re-does the whole Guild Roster screen so that members sales data can be shown/ranked in the winder.

But now, for the life of me I can't get the UI to recognize the <Label> controls in individual rows--the data is there, and the text is there, but the controls ain't loading.

Prior to 1.6, this is the code I used to add those controls to ZO_GuildRosterList:

ZO_ScrollList_AddDataType(GUILD_ROSTER.list, 2, "ddSKRosterRow", 30, function(control, data) GUILD_ROSTER:SetupGuildMember(control, data) end)

Obviously, GUILD_ROSTER is now a mess of keyboard and gamepad changes. Here's the best effort I have to simply adapt to the new Roster classes:

ZO_ScrollList_AddDataType(GUILD_ROSTER_KEYBOARD.list, 2, "ddSKRosterRow", 30, function(control, data) GUILD_ROSTER_MANAGER:SetupRow(control, data) end)

I've also updated the XML file so that:

<Control name="ddSKRosterRow" mouseEnabled="true" virtual="true" inherits="ZO_GuildRosterRow">

is now:

<Control name="ddSKRosterRow" mouseEnabled="true" virtual="true" inherits="ZO_KeyboardGuildRosterRow">

due to the change in the RosterRow control names.

What am I missing here? I just need the labels themselves, the fancy things that make the window display text, from my ddSKRosterRow control to show up.

[merlight]

function ZO_KeyboardGuildRosterManager:BuildMasterList()
     -- The master list lives in the GUILD_ROSTER_MANAGER and is built there
end
 
function ZO_KeyboardGuildRosterManager:FilterScrollList()
    ...
    local masterList = GUILD_ROSTER_MANAGER:GetMasterList()
    ...
end

So you need to hook BuildMasterList on GUILD_ROSTER_MANAGER, and FilterScrollList on GUILD_ROSTER_KEYBOARD.
Also for FilterScrollList, I wouldn't replace the function, but call the original and then rewrite all entries' typeId.

Or, and this may seem dirty but is nonetheless awesome, don't hook it at all, and make the original create entries with your typeId:

-- this will only work because GUILD_MEMBER_DATA is not local in ingame/guild/keyboard/guildroster_keyboard.lua
local DDSK_G = setmetatable({GUILD_MEMBER_DATA = DDSK_DATA_TYPE}, {__index = _G})
setfenv(GUILD_ROSTER_KEYBOARD.FilterScrollList, DDSK_G)

[Baertram]

I didn't try it and don#t know your addon, so i couldn't test it, but couldn't you just use GUILD_ROSTER_MANAGER:SetupGuildMember() again to add the controls?

[Deome]

Originally Posted by merlight function ZO_KeyboardGuildRosterManager:BuildMasterList()      -- The master list lives in the GUILD_ROSTER_MANAGER and is built there end   function ZO_KeyboardGuildRosterManager:FilterScrollList()     ...     local masterList = GUILD_ROSTER_MANAGER:GetMasterList()     ... end So you need to hook BuildMasterList on GUILD_ROSTER_MANAGER, and FilterScrollList on GUILD_ROSTER_KEYBOARD. Also for FilterScrollList, I wouldn't replace the function, but call the original and then rewrite all entries' typeId. Or, and this may seem dirty but is nonetheless awesome, don't hook it at all, and make the original create entries with your typeId: -- this will only work because GUILD_MEMBER_DATA is not local in ingame/guild/keyboard/guildroster_keyboard.lua local DDSK_G = setmetatable({GUILD_MEMBER_DATA = DDSK_DATA_TYPE}, {__index = _G}) setfenv(GUILD_ROSTER_KEYBOARD.FilterScrollList, DDSK_G)

Actually, I have my own hooks for BuildMasterList and FilterScrollList (though I've made no real changes to the latter) hooks. The sales data is in the ZO_GuildRoster control and all its children--I've already tested and noted that the "LabelText" that I use for the ddSKRosterRow controls can easily be posted to chat. The issue isn't in SetupGuildMember or even SetupRow as best I can tell; here's how those controls, and the normal ones, appear in my SetupGuildMember replacement function:

function ddShopkeeper.SetupGuildMember(self, control, data)
	origSetupGuildMember(self, control, data)
	
	local UserId = GetControl(control, "DisplayName")
	local Zone = GetControl(control, "Zone")
	local Class = GetControl(control, "Class")
	local Level = GetControl(control, "Level")
	local Vet = GetControl(control, "Veteran")
	local Note = GetControl(control, "Note")
	UserId:SetText(data.sortIndex.."  "..data.displayName)
		
	local tRosterSales = ddShopkeeper.Ledger.Options.cRosterSales.getFunc()
	local tRosterPurchases = ddShopkeeper.Ledger.Options.cRosterPurchases.getFunc()
	local tRosterTax = ddShopkeeper.Ledger.Options.cRosterTax.getFunc()
	local Sales = GetControl(control, "SalesLabel")
	local Purchases = GetControl(control, "PurchaseLabel")
	local Tax = GetControl(control, "TaxLabel")
	local SalesText = ddShopkeeper.LocalizedNumber(data.sales).." "..zo_iconFormat("esoui/art/currency/currency_gold.dds", 14, 14)
	local PurchText = ddShopkeeper.LocalizedNumber(data.purchases).." "..zo_iconFormat("esoui/art/currency/currency_gold.dds", 14, 14)
	local TaxesText = ddShopkeeper.LocalizedNumber(data.tax).." "..zo_iconFormat("esoui/art/currency/currency_gold.dds", 14, 14)

So, "SalesText" etc. can easily go to chat with a simple display function ( d(SalesText) ) and it'll post 500 lines of it to chat. Likewise, I can manipulate all the original controls like Vet and Note. But the "Sales", etc., variables, based on a GetControl("MyddSKRosterRowLabelName") function, come up nil.

As best I can tell, the issue is that my control(s) never get added like they used to, from this function:

ZO_ScrollList_AddDataType(GUILD_ROSTER_KEYBOARD.list, 2, "ddSKRosterRow", 30, function(control, data) GUILD_ROSTER_MANAGER:SetupRow(control, data) end)

[merlight]

Originally Posted by Deome As best I can tell, the issue is that my control(s) never get added like they used to, from this function: ZO_ScrollList_AddDataType(GUILD_ROSTER_KEYBOARD.list, 2, "ddSKRosterRow", 30, function(control, data) GUILD_ROSTER_MANAGER:SetupRow(control, data) end)

I guess you know this, but just to be clear: that only registers the data type, it must the be used to create data entries in FilterScrollList. Could it be that the list is built and filtered even before you hook that? Try RefreshData after you setup hooks. Oh and now I noticed: SetupRow is a method of ZO_KeyboardGuildRosterManager, not the shared manager. How come it doesn't spit errors?

Btw, you should give that "2" type a name, it'll be easier to find where it's used in the code

And final note for tonight. ZO_ScrollList_AddDataType with setup function that calls the base version, and then overriding the base version, is complicated and wrong -- if you're adding data type 2, you should not be changing the setup procedure for data type 1. Instead, provide a function that will call the base setup, and then your additional setup:

ZO_ScrollList_AddDataType(GUILD_ROSTER_KEYBOARD.list, 2, "ddSKRosterRow", 30,
function(control, data)
    GUILD_ROSTER_KEYBOARD:SetupRow(control, data)
    ddShopkeeper.SetupGuildMember(GUILD_ROSTER_MANAGER, control, data) -- don't call origSetupGuildMember from there, only init your own stuff
end)

[merlight]

Originally Posted by merlight I guess you know this, but just to be clear: that only registers the data type, it must the be used to create data entries in FilterScrollList. Could it be that the list is built and filtered even before you hook that? Try RefreshData after you setup hooks. Oh and now I noticed: SetupRow is a method of ZO_KeyboardGuildRosterManager, not the shared manager. How come it doesn't spit errors?

After I posted that and re-read again to check, it started coming together. Here's what I think is happening.
1. game starting
2. original BuildMasterList
3. original FilterScrollList => all entries have typeId == 1
4. ddSK installs hooks
5. list is shown, row controls are created for type 1
6. ddSK SetupGuildMember wonders where are children for type 2

[Minceraft]

I've also had similar problems with MailBuddy. ZO_FriendsList was renamed and we've tried to account for it by changing the name in the code, but it still doesn't anchor AT ALL... stumped...

[Deome]

Originally Posted by merlight After I posted that and re-read again to check, it started coming together. Here's what I think is happening. 1. game starting 2. original BuildMasterList 3. original FilterScrollList => all entries have typeId == 1 4. ddSK installs hooks 5. list is shown, row controls are created for type 1 6. ddSK SetupGuildMember wonders where are children for type 2

Okay, I'm starting to see it too. I really had no idea FilterScrollList is involved. Guess I'll be digging through the API tonight.

[merlight]

Originally Posted by Deome Okay, I'm starting to see it too. I really had no idea FilterScrollList is involved. Guess I'll be digging through the API tonight.

Yea that's kind of unexpected, more so that different parts of ZOS code do that differently.

For example KEYBINDING_MANAGER creates complete data entries for the underlying ZO_ScrollList in BuildMasterList, and then in FilterScrollList only throws these into ZO_ScrollList.

GUILD_ROSTER_MANAGER, on the other hand, creates only its inner data tables in BuildMasterList, and GUILD_ROSTER_KEYBOARD wraps them in ZO_ScrollList_CreateDataEntry later in FilterScrollList. This is necessary because the masterList is shared between KB and GP lists, but ZO_ScrollList assumes ownership of the entries you put in it, so KB and GP must create their own entries.

[Deome]

Originally Posted by merlight Yea that's kind of unexpected, more so that different parts of ZOS code do that differently. For example KEYBINDING_MANAGER creates complete data entries for the underlying ZO_ScrollList in BuildMasterList, and then in FilterScrollList only throws these into ZO_ScrollList. GUILD_ROSTER_MANAGER, on the other hand, creates only its inner data tables in BuildMasterList, and GUILD_ROSTER_KEYBOARD wraps them in ZO_ScrollList_CreateDataEntry later in FilterScrollList. This is necessary because the masterList is shared between KB and GP lists, but ZO_ScrollList assumes ownership of the entries you put in it, so KB and GP must create their own entries.

Okay, so here's what I've tested and found:

1) I still need to replace the old SetupGuildMember with my own, and call the old one in it first. Splitting it into two functions in the AddDataType function seems to only create more problems.

2) "2" has been assigned to a new local global DDSK_GUILD_ROSTER_DATA, just for fancy naming purposes.

3) Everything goes right in BuildMasterList. But my FilterScrollList replacement hook ain't adding DDSK_GUILD_ROSTER_DATA to row controls like it did pre-1.6. That seems to be where I'm screwed--all the data is available, but my XML label controls just aren't getting added to each row control's children so there's no control, like "SalesLabel", for my GetControl calls in the SetupGuildMember function. Why?

[merlight]

Originally Posted by Deome 1) I still need to replace the old SetupGuildMember with my own, and call the old one in it first. Splitting it into two functions in the AddDataType function seems to only create more problems.

No, that's just wrong. You're adding a new data type, you can do everything you need in your own setup function.
GUILD_MEMBER_DATA -> template "ZO_KeyboardGuildRosterRow" -> function ZO_KeyboardGuildRosterManager:SetupRow
DDSK_GUILD_ROSTER_DATA -> template "ddSKRosterRow" -> function ddSKRosterRowSetup

All row controls created from the template "ddSKRosterRow" will use your ddSKRosterRowSetup function. There's no point in hooking SetupGuildMember, any control not going through ddSKRosterRowSetup wil not have been created from your template.

Originally Posted by Deome 3) Everything goes right in BuildMasterList. But my FilterScrollList replacement hook ain't adding DDSK_GUILD_ROSTER_DATA to row controls like it did pre-1.6. That seems to be where I'm screwed--all the data is available, but my XML label controls just aren't getting added to each row control's children so there's no control, like "SalesLabel", for my GetControl calls in the SetupGuildMember function. Why?

Do you have the latest code somewhere? I could only guess. FilterScrollList was changed in 1.6 due to the surrounding changes.

[Deome]

Originally Posted by merlight No, that's just wrong. You're adding a new data type, you can do everything you need in your own setup function. GUILD_MEMBER_DATA -> template "ZO_KeyboardGuildRosterRow" -> function ZO_KeyboardGuildRosterManager:SetupRow DDSK_GUILD_ROSTER_DATA -> template "ddSKRosterRow" -> function ddSKRosterRowSetup All row controls created from the template "ddSKRosterRow" will use your ddSKRosterRowSetup function. There's no point in hooking SetupGuildMember, any control not going through ddSKRosterRowSetup wil not have been created from your template.

Actually, it works just fine now. I had to add a call to GUILD_ROSTER_KEYBOARD:ColorRow at the top of my SetupGuildMember function, right above where I call the old function, but that was never the issue.

Originally Posted by merlight Do you have the latest code somewhere? I could only guess. FilterScrollList was changed in 1.6 due to the surrounding changes.

Boom. That was exactly what changed--once I got and replaced the new FilterScrollList function, it was a very short trip downhill.

For everyone's benefit, these are my hooks, the FilterScrollList function, and the critical first part of my SetupGuildMember function:

Hooks:

origSetupGuildMember = GUILD_ROSTER_MANAGER.SetupGuildMember
origBuildMasterList = GUILD_ROSTER_MANAGER.BuildMasterList
GUILD_ROSTER_MANAGER.SetupGuildMember = ddShopkeeper.SetupGuildMember
GUILD_ROSTER_MANAGER.BuildMasterList = ddShopkeeper.RosterBuildMasterList
GUILD_ROSTER_KEYBOARD.FilterScrollList = ddShopkeeper.RosterFilterScrollList
GUILD_ROSTER_KEYBOARD.CompareGuildMembers = ddShopkeeper.CompareGuildMembers
		
ZO_ScrollList_AddDataType(ZO_GuildRosterList, DDSK_GUILD_MEMBER_DATA, "ddSKRosterRow", 30, function(control, data) GUILD_ROSTER_MANAGER:SetupGuildMember(control, data) end)

FilterScrollList:

function ddShopkeeper.RosterFilterScrollList(self)
  local scrollData = ZO_ScrollList_GetDataList(self.list)
  ZO_ClearNumericallyIndexedTable(scrollData)

  local searchTerm = self.searchBox:GetText()
  local masterList = GUILD_ROSTER_MANAGER:GetMasterList()
	
  for i = 1, #masterList do
    local data = masterList[i]
    if (searchTerm == "" or GUILD_ROSTER_MANAGER:IsMatch(searchTerm, data)) then
      table.insert(scrollData, ZO_ScrollList_CreateDataEntry(DDSK_GUILD_MEMBER_DATA, data))
    end
  end
end

New SetupGuildMember:

function ddShopkeeper.SetupGuildMember(self, control, data, selected)
	GUILD_ROSTER_KEYBOARD:ColorRow(control, data, selected)
	origSetupGuildMember(self, control, data, selected)

Should be ready to publish soon; the guild roster window is working just fine now.

[Elijafire]

Great work Deome, thanks for your hard work we appreciate it. Thanks for those who bounced ideas off him too.

Be blessed!

E

[merlight]

Originally Posted by Deome ZO_ScrollList_AddDataType(ZO_GuildRosterList, DDSK_GUILD_MEMBER_DATA, "ddSKRosterRow", 30, function(control, data) GUILD_ROSTER_MANAGER:SetupGuildMember(control, data) end)

I know I'm repeating myself, but... Why do you insist on calling SetupGuildMember, which doesn't do everything you want, effectively forcing yourself into hooking it? I'm always looking for ways to avoid unnecessary hooks, and this is exactly the case where you can do it cleanly and simply without hooking.

ZO_ScrollList_AddDataType(ZO_GuildRosterList, DDSK_GUILD_MEMBER_DATA, "ddSKRosterRow", 30,
  function(control, data)
    GUILD_ROSTER_KEYBOARD:SetupRow(control, data) -- original "ZO_KeyboardGuildRosterRow" setup
    -- ... your setup here
  end)

Note the original setup function, which I also used a few posts above, you should've copied that. Here is the function for reference:

function ZO_KeyboardGuildRosterManager:SetupRow(control, data)
    ZO_SortFilterList.SetupRow(self, control, data)
    GUILD_ROSTER_MANAGER:SetupGuildMember(control, data)
end

ZO_SortFilterList.SetupRow, among other things, calls ColorRow.