ESOUI - [open] Search Box Bug

ESOUI (https://www.esoui.com/forums/index.php)

- Bug Reports (https://www.esoui.com/forums/forumdisplay.php?f=187)

- - [open] Search Box Bug (https://www.esoui.com/forums/showthread.php?t=4551)

[open] Search Box Bug

I have found 2 more bugs in the searchBox game code and added them to this post.

BUG 1
If you unequip an item by double clicking on it in the character window (or right clicking and selected unequip) everything works fine.

But when you double click an item to equip it & you already have an item equiped in that equip slot, they just swap slots and the searchData does not get updated and still has the cached searchData for the old item.

Steps to Reproduce:

Log in or /reloadui to clear searchData.cache for all slots
Do a search in the search box so that it will cache search data in to each slot.searchData.cache
Double click on an item to equip it AND you must already have an item equipped in that slot so they swap slots !!
The item that was unequipped was placed in the inventory slot of the item you equipped & it still contains the old searchData.cache.
Try to search for the name of the item you EQUIPPED (yes its not in your inventory you equipped it, but) it will display the item that was UNEQUIPPED in the search results...because it has the searchData.cache for the old item.

Example:

I "HAD" the "Ironthread Jerkin" equipped
I double clicked on the "Robe of the Magic Furnace" (now it is equipped)
Then I /zgoo'd the row control for the "Ironthread Jerkin" that got unequipped.
We can see the slot data shows the "Ironthread Jerkin", but the searchData still has the cached data for the "Robe of the Magic Furnace"
When I search for "Robe of the Magic Furnace" the "Ironthread Jerkin" appears

Fix:
It looks like you need to clear the searchData.cache & set searchData.cached to false when the slots are updated with a different item, something like:

Lua Code:

function ZO_SharedInventoryManager:CreateOrUpdateSlotData(existingSlotData, bagId, slotIndex, isNewItem)
    ...
    if not wasSameItemInSlotBefore then
        slot.itemType = GetItemType(bagId, slotIndex)
        slot.uniqueId = GetItemUniqueId(bagId, slotIndex)
        
        --------------------------------------
        -- Add these to clear the old cache --
        --------------------------------------
        local searchData = slot.searchData
        
        if searchData.cached then
            searchData.cache = nil
            searchData.cached = false
        end
        --------------------------------------
        --------------------------------------
    end
    
    ...
end

BUG 2
I'm not sure when this broke, but the search box does NOT work in the guild bank.

The virtual control that is inherited by all inventory search boxes comes from this control:

Lua Code:

<EditBox name="ZO_InventorySearchBox" font="ZoFontWinT1" inherits="ZO_DefaultEdit ZO_EditDefaultText" virtual="true">
   ...
    <OnTextChanged>
        ZO_EditDefaultText_OnTextChanged(self)
        ZO_PlayerInventory_OnSearchTextChanged(self)
    </OnTextChanged>
    ...

which calls:

Lua Code:

ZO_PlayerInventory_OnSearchTextChanged(self)

But it only updates the backpack or bank.

Lua Code:

function ZO_PlayerInventory_OnSearchTextChanged(editBox)
    if(editBox == ZO_PlayerInventorySearchBox) then
        PlayerInventory:UpdateList(PlayerInventory.selectedTabType)
    else
        PlayerInventory:UpdateList(INVENTORY_BANK)
    end
end

Fix: It should be

Lua Code:

function ZO_PlayerInventory_OnSearchTextChanged(editBox)
    if(editBox == ZO_PlayerInventorySearchBox) then
        PlayerInventory:UpdateList(PlayerInventory.selectedTabType)
    elseif (editBox == ZO_PlayerBankSearchBox) then
        PlayerInventory:UpdateList(INVENTORY_BANK)
    else
        PlayerInventory:UpdateList(INVENTORY_GUILD_BANK)
    end
end

BUG 3
In inventory.lua, when the "guildbank" scene is registered for the "StateChange" callback it Ends the search for the wrong searchBox. Which means the searchBox for the guild bank does not get cleared properly.

Lua Code:

local guildBankScene = ZO_InteractScene:New("guildBank", SCENE_MANAGER, GUILD_BANKING_INTERACTION)
guildBankScene:RegisterCallback("StateChange",  function(oldState, newState)
    if(newState == SCENE_SHOWING) then
        self:RefreshMoney(GetCurrentMoney())
        self:RefreshAlliancePoints(GetAlliancePoints())
        guildBankFragmentBar:SelectFragment(SI_BANK_WITHDRAW)
        ZO_SharedInventory_SelectAccessibleGuildBank(self.lastSuccessfulGuildBankId)
    elseif(newState == SCENE_HIDDEN) then
        guildBankFragmentBar:Clear()
        ZO_InventorySlot_RemoveMouseOverKeybinds()
        
        --============================================================--
        -- This line is incorrect. 
        --ZO_PlayerInventory_EndSearch(ZO_PlayerBankSearchBox)
        -- It should be:
        ZO_PlayerInventory_EndSearch(ZO_GuildBankSearchBox)
        --============================================================--
    end
end)

For anyone interested I have added a fix for the two new bugs I found to my SearchBox Bug Fix addon, you can find it here: SearchBox Bug Fix V3.0

Does this fix it for you? For me it does.

Lua Code:

local function OnSlotUpdated(bagId, slotIndex, slotData)
  if slotData and slotData.searchData and slotData.searchData.cached and slotData.searchData.cache then
    slotData.searchData.cached = slotData.rawName:lower() == slotData.searchData.cache[1]
  end
end
 
SHARED_INVENTORY:RegisterCallback("SlotUpdated", OnSlotUpdated)

Although the equipType would be the same since both items go in the same equip slot the itemStyles might not be the same, so that really needs to be updated also. You could just nil out the cache & set cached = false, like I did in my example above, but if you want to fix the cache instead of nilling it out the itemStyle needs to be updated as well:

Lua Code:

local function OnSlotUpdated(bagId, slotIndex, slotData)
  if slotData and slotData.searchData and slotData.searchData.cached and slotData.searchData.cache then
    local name = GetItemName(bagId, slotIndex)
    name = name:lower()
    
    if name ~= slotData.searchData.cache[1] then
        local _, _, _, _, _, equipType, itemStyle = GetItemInfo(bagId, slotIndex)
        
        slotData.searchData.cache = {name, equipType, itemStyle}
    end
  end
end
 
SHARED_INVENTORY:RegisterCallback("SlotUpdated", OnSlotUpdated)

Nilling it out would probably be the best solution though. Whenever a search is started it checks to see if data is cached and if its not it grabs that data on its own. That way it would only have to mess with those calls to update the cache if a search is being run instead of every time they don't match in the OnSlotUpdate.

Quote:

Originally Posted by circonian (Post 20323)

You could just nil out the cache & set cached = false, like I did in my example above

That's what it does. By setting cached to false (not updating cache), if the names do not match, a second slotUpdated occurs with corrected data. This way, you do not re-implement something but invalidating the cache. No need to change the hashtable by nilling something.

Nethertheless, if a small code snippet like that would fix it, it maybe something for Mer Band-Aid ZO-UI Fixes

Quote:

Originally Posted by votan (Post 20326)

That's what it does.

Oh, my bad your right. I guess I read it wrong. For some reason I looked at this:

Lua Code:

slotData.rawName:lower() == slotData.searchData.cache[1]

and thought it said:

Lua Code:

slotData.searchData.cache[1] = slotData.rawName:lower()

2 MORE SearchBox Bugs

I have found 2 more bugs in the inventory searchBoxes.

I have edited the original post to reflect all three bugs (scroll up to first post to read).

I have a question regarding bug #1 fix. You set .cached to false if .rawName doesn't match. Is that condition sufficient? I mean, I noticed the search also includes item style, e.g. "breton" finds all items in Breton style. Hopefully I can find a pair of identically named items in different styles to test. Just wanted to ask how much "wrong" it would be to clear the .cached flag unconditionally.

One more question: I can't find the fix to #1 in FilterIt. Has it been fixed by ZOS already?

Quote:

Originally Posted by merlight (Post 22177)

I have a question regarding bug #1 fix. You set .cached to false if .rawName doesn't match. Is that condition sufficient? ... Just wanted to ask how much "wrong" it would be to clear the .cached flag unconditionally.

EDIT: Nevermind, I missunderstood. I thought you were talking about the code posted in this thread. You meant in that fix I posted. I'll look at it.

Quote:

Originally Posted by merlight (Post 22177)

At the time I assumed two items with the same name would be the same style, but now that you mention it your probably right.

(untested) Probably the easiest way I can think of to fix that would be to copy the itemInstanceId and check it instead to see if its changed:

Lua Code:

local function OnSlotUpdated(bagId, slotIndex, slotData)
    if not slotData then return end
    local searchData = slotData.searchData
    if not (searchData and searchData.cached) then return end
    if not (searchData.cache) then return end
    
    local newItemInstanceId = slotData.itemInstanceId
    local oldItemInstaceId  = slotData.itemInstanceIdOLD
    
    -- if its the same item, nothing to do return.
    -- if there is no item in the slot newItemInstanceId will be nil
    if newItemInstanceId == oldItemInstaceId then return end
    
    searchData.cache = nil
    searchData.cached = false
    
    -- if there is no item in the slot this will 
    -- nil out the old Id for us:
    slotData.itemInstanceIdOLD = newItemInstanceId
end

Quote:

Originally Posted by merlight (Post 22178)

One more question: I can't find the fix to #1 in FilterIt. Has it been fixed by ZOS already?

I guess not, I just tested it and those bugs are all still there. I don't see any of the fixes in FilterIt. I think what happened was I added a fix for the first bug, then I found the other two & I didn't want to keep adding code to fix bugs and posted that SearchBox Bug Fix instead.

there is a ticket # 200415-001514