Inventory search boxes & guild store sell tab filters

[merlight]

The basic UI deliberately hides either the filters (guild store sell tab), or the search box (everywhere else). It's not a bug, it's just a feature that doesn't make any sense.

Then there are search box bugs circonian discovered. I guess #2 and #3 are normally hidden because the search box is hidden.

Fun comment from ingame/inventory/inventory.xml

<!-- not dead, but dreaming... -->
<EditBox name="$(parent)SearchBox"

Now we have a multitude of scattered fixes:

• AdvancedFilters -- shows+moves search boxes and fixes bug #2
• AwesomeGuildStore -- adds its own filters to guild store sell tab
• Circonian's FilterIt -- shows search boxes and fixes bugs
• Votan's Search Box -- shows+moves+decorates search boxes

Please fill in what I got wrong or missing, out of these add-ons I only use AdvancedFilters, and am so used to it that I sometimes can't tell what's the default behavior.

For me the most annoying part is missing filters at the guild store sell tab. And that's coming from someone who only sells common racial motifs when he finds some, or small stacks of green improvement mats. Like twice a month. It's been even more frustrating since (many months ago) I somehow bugged it in such a way that sometimes the filters were there.

Yesterday I managed to make the default filters show up on the sell tab with very little code, and AdvancedFilters simply work there with no additional changes.

Now I have a dilemma: to fix or not to fix. It's not a bug, but so inherently broken that I want it fixed But I will have to check the presence of AwesomeGuildStore at least, as I don't want to screw other add-ons. Are there any other?

[sirinsidiator]

The last time I tried to activate the default sell tab filters for the guild store, I got consistent crashes. It was easier to roll my own version in AGS than to debug the ingame ui code because I already had them made for the search tab.
I won't remove them from AGS, but I can add a setting to disable them if you want to offer a different addon that allows AF to work on the sell tab. Keep in mind that the AGS version of the filters hides items that cannot be sold on the store in addition to filtering categories and uses the same icons as on the search tab though so I don't see any reason to not use them. :P

[circonian]

That was something I said I was going to add to FilterIt a long time ago, but never did.
As you said it takes very little code:
EDIT 1: I forgot to hide the quest filter, added.
EDIT 2: Heres one for you...I just realized the trading house additional filter does NOT filter out bound items? Might as well fix that too. Removed EDIT 2. I just realized it will mess up the filtering libraries for the trading house.

local function InitTradingHouseLayout()
    BACKPACK_TRADING_HOUSE_LAYOUT_FRAGMENT.layoutData.inventoryTopOffsetY = 43  
    BACKPACK_TRADING_HOUSE_LAYOUT_FRAGMENT.layoutData.hiddenFilters = { [ITEMFILTERTYPE_QUEST] = true }
end
 
local origSetTradingHouseMode = ZO_InventoryManager.SetTradingHouseModeEnabled
function ZO_InventoryManager:SetTradingHouseModeEnabled(enabled)
    origSetTradingHouseMode(self, enabled)
    ZO_PlayerInventoryTabs:SetHidden(false)
end

Although now that I'm thinking about it. I might as well add it to FilterIt.

[QuadroTony]

btw how to filter bound items in your deposit tab when at the guild bank?
you cant deposit em anyway

[Randactyl]

Originally Posted by QuadroTony btw how to filter bound items in your deposit tab when at the guild bank? you cant deposit em anyway

https://github.com/Randactyl/HideBoundItems

[Randactyl]

Originally Posted by sirinsidiator Keep in mind that the AGS version of the filters hides items that cannot be sold on the store in addition to filtering categories and uses the same icons as on the search tab though so I don't see any reason to not use them. :P

Neither do I. I've been putting off fixing up AF to make guild selling behave because I always just recommend downloading AGS. However, now that circonian has shown how easy it is to make it work, I may go ahead and do something just for completeness.

[circonian]

One thing I just thought of though:

BACKPACK_TRADING_HOUSE_LAYOUT_FRAGMENT.layoutData.additionalFilter = function (slot)
            return (slot.quality ~= ITEM_QUALITY_TRASH) and (not slot.stolen) and (not IsItemBound(slot.bagId, slot.slotIndex))
        end

That was a bad idea, don't use it.
It will mess up addons using either of the filtering libraries for the trading house if the library gets loaded first & sets the additional filter and then some other addon changes it. That could of course be fixed, by saving the original additional filter & calling it with the new function, but you'de never be able to remove the changes. Although would that be necessary? Do you ever need to see bound items...well I guess it would be ok.

local origAdditionalFilter = BACKPACK_TRADING_HOUSE_LAYOUT_FRAGMENT.layoutData.additionalFilter 
BACKPACK_TRADING_HOUSE_LAYOUT_FRAGMENT.layoutData.additionalFilter = function (slot)
            return origAdditionalFilter(slot) and (not IsItemBound(slot.bagId, slot.slotIndex))
        end

[sirinsidiator]

Okay. In this case I suggest everyone adds a setting to disable it and on updating the addon checks if there is already another addon running that offers this feature.
Instead of checking for specific addons we could set a flag on BACKPACK_TRADING_HOUSE_LAYOUT_FRAGMENT.layoutData. The first to set it stays active, all the others deactivate themselves until the user activates them again and reloads the UI. That way there should not be any conflicts and the user can decide which version he prefers.

[circonian]

How about sellFiltersEnabled
I would also recommend then no one hooks SetTradingHouseModeEnabled like I suggested. No reason for every addon to be hooking into that if their not even going to use it.
Switched to prehook the HandleTabSwitch(...) that way only the addon who is handling the sell filters will need to set a hook.

local function InitTradingHouseLayout()
    local layoutData = BACKPACK_TRADING_HOUSE_LAYOUT_FRAGMENT.layoutData
    local sellFiltersEnabled = layoutData.sellFiltersEnabled
    -- Check if someone has already enabled it:
    if sellFiltersEnabled then return end
    
    -- Check if its turned on in my addon:
    if not MY_ADDON_SETTING_ON then return end
    
    -- Set flag:
    layoutData.sellFiltersEnabled = true
    
    -- Set the new layoutData:
    layoutData.inventoryTopOffsetY = 43
    layoutData.hiddenFilters = { [ITEMFILTERTYPE_QUEST] = true }  
    local origAdditionalFilter = layoutData.additionalFilter 
    layoutData.additionalFilter = function (slot)
                return origAdditionalFilter(slot) and (not IsItemBound(slot.bagId, slot.slotIndex))
            end
    
    -- Prehook HandleTabSwitch for sell mode:
    local function OnHandleTabSwitch(self, tabData)
        local mode = tabData.descriptor
        
        if mode == ZO_TRADING_HOUSE_MODE_SELL then
            ZO_PlayerInventoryTabs:SetHidden(false)
        end
        return false
    end
    ZO_PreHook(TRADING_HOUSE, "HandleTabSwitch", OnHandleTabSwitch)
end

[merlight]

@circonian: I have the code, including bound items filtering and hiding statValue column, I just need to make sure it doesn't break other add-ons. I'm a little off-focus now, hopefully I can test later this week.

@sirinsidiator: I'm not a fan of unnecessary toggles, keep it simple for users. And yourself as well. Guild store scene seems to be AwesomeGuildStore's domain, I can easily check for its presence and skip tackling with it.

[circonian]

Originally Posted by merlight Guild store scene seems to be AwesomeGuildStore's domain, I can easily check for its presence and skip tackling with it.

I agree, that would be the best method. If they want to use AGS they might as well use those filters and as you said it will keep it simple. AGS is actually the reason I never added this feature, but now I figure it might as well for those that dont use it.

[sirinsidiator]

@merlight of course you can add code to watch out for a specific addon, but I always try to achieve compatibility in a generic way that can be reused by new addons in the future

Maybe you can make a small library instead of everyone making their own version?
That way you don't have to do anything special to make it work between your addons.

[circonian]

Originally Posted by sirinsidiator Maybe you can make a small library instead of everyone making their own version? That way you don't have to do anything special to make it work between your addons.

For our addons it would need the same code, both Advanced Filters & FilterIt use the default inventory menu bar (with a subBar), but how would AGS or other addons that want to use their own menu bar handle it? Do you still want to use a flag to decide which filter bars get shown? If were doing it in a library I'de rather not watch for loading addons. That would force library updates if addons make changes or new addons are released wanting to use their own bars as well like AGS.

Example Lib:

Warning: Spoiler

-- Register with LibStub
local MAJOR, MINOR = "LibTradeSellFilters", 1
local lib, oldminor = LibStub:NewLibrary(MAJOR, MINOR)
if not lib then return end -- the same or newer version of this lib is already loaded into memory
 
do
    local layoutData = BACKPACK_TRADING_HOUSE_LAYOUT_FRAGMENT.layoutData
    local sellFiltersEnabled = layoutData.sellFiltersEnabled
 
    -- Give AGS & others a chance to block
    -- this code from being run ??
    if sellFiltersEnabled then return end
    layoutData.sellFiltersEnabled = true
 
    layoutData.inventoryTopOffsetY = 43
    layoutData.hiddenFilters = { [ITEMFILTERTYPE_QUEST] = true }  
    local origAdditionalFilter = layoutData.additionalFilter 
    layoutData.additionalFilter = function (slot)
                return origAdditionalFilter(slot) and (not IsItemBound(slot.bagId, slot.slotIndex))
            end
 
    -- Prehook HandleTabSwitch for sell mode:
    local function OnHandleTabSwitch(self, tabData)
        local mode = tabData.descriptor
        
        if mode == ZO_TRADING_HOUSE_MODE_SELL then
            ZO_PlayerInventoryTabs:SetHidden(false)
        end
        return false
    end
    ZO_PreHook(TRADING_HOUSE, "HandleTabSwitch", OnHandleTabSwitch)
end

Then for an addon like AGS that doesn't want to use those bars you could check to see if the flag is set & if not set it and use your bars.

One other problem, if we use a library, it will pretty much be whichever addon loads first wins without giving the user an option to select which bars to use, unless someone has a suggestion on how to handle that part.

[merlight]

Originally Posted by circonian One other problem, if we use a library, it will pretty much be whichever addon loads first wins without giving the user an option to select which bars to use, unless someone has a suggestion on how to handle that part.

Perhaps I found a way. My lib does its overrides in EVENT_PLAYER_ACTIVATED. Unless an add-on calls lib:disableGuildStoreSellFilters() in their EVENT_ADD_ON_LOADED handler, the lib proceeds to enable the default filters.

[circonian]

Originally Posted by merlight Perhaps I found a way. My lib does its overrides in EVENT_PLAYER_ACTIVATED. Unless an add-on calls lib:disableGuildStoreSellFilters() in their EVENT_ADD_ON_LOADED handler, the lib proceeds to enable the default filters.

1. That would put all of the work on AGS (and any other addon) to have a setting to turn it off & not call that function if they want to see the filter bars of another addon though. Another addon wanting to use the default inventory menu bar would have no way of overriding anyone else who runs that function if the user wants to display those bars via a setting they chose (unless that setting is in AGS, everyone else would be dependent upon the setting in AGS).
2. It would also not solve any problems if more than one addon called that so they could each display their own menu bars.

No matter what though there is going to be an unsolvable conflict if the user chooses to show the menu bars for multiple addons...although ??? would it be a good thing to allow it? Yes it would be a mess several menu bars showing, but it would help the user figure out whats wrong rather than wondering why xxx addons menu bars aren't visible and some other menu bars are.

How about instead of using a lib function to "block" the default inventory menu bars create a function that must be called to enable the defualt menu bars. This way each addon can handle its own code & not worry about any other addon. Each addon would be required only to have a setting that would allow users to turn the given addons menu bars ON/OFF.

• If ON the addon does what it needs to show its menu bars. If their custom, run whatever code you need. If its the default menu bars call that lib function.
• If OFF the addon just does nothing & does not call the lib function and does not create its own menu bars.

If a user turns on menu bars from multiple addons then they just need to turn some of them off in the settings.

[circonian]

Actually forget that last post....I have a better idea.

How about we create a settings menu panel just for the menu bars. Register the panel with LibAddonMenu just like its an addon and only have 1 setting, which menu bars to display. Each addon could call something like:

lib:RegisterTradeHouseSellMenuBars(string displayText, function:nillable callback)

to register that it has menu bars to be shown for the trade house sell filters and the user chooses in the settings menu which one they want, but the setting would be in its own panel and then we don't all need to create our own ON/OFF settings. This would eliminate the problem of needing to know which addons are turned ON/OFF and would prevent multiple menu bars from getting shown.

The callback would be nillable and any addon wanting the default menu bars could just pass nill for the callback and then the library could just handle that code on its own.

FilterIt does not have filters for the browse category in the trade house. I know AGS does, do any other addons? While were at it we might as well add a register function for that as well. They should be separate registrations so that, for example, A user could choose to display the FilterIt menu bars for the sell tab, but still have the AGS filters on the browse tab.

[sirinsidiator]

I think a dedicated settings menu is over-complicating it a bit.

If I understood it correctly, we currently have two different sell tab bars. My AGS custom bar and the default ingame bar.
You are trying to activate the ingame bar through the code posted by merlight in 3 separate addons.
If a user has more than one of these the other two do not need to run the same code to activate the ingame bar again, so I said we could put it in a library because it will only load once by design.

The only problem left is to handle if a user has the AGS bar running, which I would solve by including the library too and offering a setting in AGS. If it is set to show the my bar, I will call a method on the library to deactivate its functionality and call my own code. If it is set to off, I won't do anything and the library will work normally.

Unless you have plans to make a custom sell tab bar this should be all that is necessary.

[circonian]

Originally Posted by sirinsidiator I think a dedicated settings menu is over-complicating it a bit.

It was just an idea I thought would be a simple solution. I'm ok with whatever.

Originally Posted by sirinsidiator You are trying to activate the ingame bar through the code posted by merlight in 3 separate addons. If a user has more than one of these the other two do not need to run the same code to activate the ingame bar again, so I said we could put it in a library because it will only load once by design.

I'm not sure what you mean, merlight hasn't posted any code. But if your talking about the first code I posted it only activates 1 time regardless of how many addons have it. I was using the idea you suggested of setting a flag which prevents the other addons from running the same code:

Originally Posted by sirinsidiator Instead of checking for specific addons we could set a flag on BACKPACK_TRADING_HOUSE_LAYOUT_FRAGMENT.layoutData

local sellFiltersEnabled = layoutData.sellFiltersEnabled
    -- Check if someone has already enabled it:
    if sellFiltersEnabled then return end
    
    -- Check if its turned on in my addon:
    if not MY_ADDON_SETTING_ON then return end
    
    -- Set flag -- prevents other addons from running
    -- this code because of check above:
    layoutData.sellFiltersEnabled = true

Originally Posted by sirinsidiator Unless you have plans to make a custom sell tab bar this should be all that is necessary.

But no I have no plans of doing so and as I said I'm good with whatever you guys want to do. I was just offering some ideas.

[sirinsidiator]

Ah. Sorry. I was somehow thinking that he had some code in his initial post.

[merlight]

I'll try to better explain my thought process. I'll post the "libCommonInventoryFilters" later today.

Currently on the SELL tab we either have no filters (because the basic UI hides them), or custom AGS filters. AGS doesn't need to worry about conflicts, it just fills empty space. If another add-on wanted to put its own custom filters there, it would have to talk to AGS, or they would both need a toggle -- similar to how numerous combat add-ons have a toggle for every feature, and people mix them up in the most unimaginable ways. The idea of a centralized "pick one" setting is interesting, but it seems overkill for what we currently have. Perhaps if there were many contestants, but I doubt that will happen.

So, I wanted the default filters on the SELL tab, when AGS is not there. With AGS I don't really care, as long as there's exactly one set of filters
The library says: "If you load me, I'm going to put filters on the SELL tab, unless you intend to put something better in there, in which case you need to explicitly tell me!" (does that make sense?)
You may have 3 add-ons wanting to put their controls in there, the library doesn't care how they get along, it just won't interfere if at least one of them tells it not to.

AF can include the library and do nothing else, it will just work.
FilterIt can include it and it will almost work (I just need to figure out why it's wrongly anchored).
AGS can include it, but must also call libCIF:disableGuildStoreSellFilters() in its EVENT_ADD_ON_LOADED, otherwise both sets would show up and overlap. It doesn't need to have a toggle, it can simply prefer its own filters.

---

Now the difficult part: the search box. When filters are enabled on the SELL tab, there's no room for it.

AF moves the search box to the top, above filters. Which kinda makes sense, since the search persists as you switch filters. Btw, AF shows the search box on startup only, if you open/close the guild store, it won't appear in inventory/bank again. But don't worry, libCIF solves that, too.

AGS moves the search box below its filters on EVENT_OPEN_TRADING_HOUSE, and moves it back to the original location on EVENT_CLOSE_TRADING_HOUSE. This will probably need to be changed. I don't know when exactly these events occur, but if the CLOSE happens after SCENE_HIDING, I'd need to find a way to run another move function after that. But as with AF the search persists while switching filters, it'd probably be best to move it to the top.

FilterIt enables the search box, but uses it differently. It only works on the generic ALL filter, other top-level filters and sub-filters don't have a search box. Which means in the case of FilterIt, having the search box down there next to sub-filters actually makes sense. So I added libCIF:disableSearchBoxes(), which prevents the lib from showing search boxes and moving them to the top. Now I'm trying to figure out how to make FilterIt look nice on the SELL tab.

---

And because adding filters forced me to play with the search box, the lib (by default) also moves search boxes to the AF location, and contains circonian's bug fixes as a bonus.