[Need help pls] Find slowdown bug at Advanced Filters & FCOItemSaver addons

[merlight]

Originally Posted by Randactyl Edit: actually, it's really the "same inventory" in any of those contextual fragments just with special flavor like a label saying "Sell" instead of "Inventory" and the buttons to navigate through that fragment, right?

Exactly. It's always INVENTORY_FRAGMENT (top-level control ZO_PlayerInventory) with different layout fragment added to the scene. ingame/inventory/backpacklayouts.lua

Originally Posted by Randactyl So then we would want to include all of the LAF_BAGS filters by default? (at least for Advanced Filters, anyway) I'm trying to think of when I would want different filters in Sell vs. Mail vs. Inventory.

For example in an add-on named NeverSellRawMaterialsToNPC (but allow sending to friends). We don't have to come up with every possible usage, but if someone else comes with an idea and can use libFilters to implement it, that'd be great

Originally Posted by Randactyl Option B could involve something like me choosing the correct LAF by hooking the display of a scene just like libFilters uses to determine which LAF to apply. Option A sounds to be the easiest, but I have a gut feeling that is not the best thing to do.

Basically what I was thinking. B) looks like a bit more work for AF, but non-overlapping LAF filters might be worth it. libFilters could even tell you which LAF is active on INVENTORY_BACKPACK, it can save the value in layoutData when it hooks additionalFilter.

Originally Posted by Randactyl I'm hesitant to dive into these changes because I'm trying to figure out which would be the best option performance wise since that is what all of this discussion was borne out of. I just don't know enough about performance impacts of the different options to make a call out of the gate.

Even without help from libFilters or trying to figure out which LAF is active, registering all LAF types every time would impose marginal overhead. Compared to the previous version, which caused several inventory refreshes per click and chained filters ad infinitum, we could perhaps do some Folding@Home during the time saved.

Originally Posted by Baertram Avoid registering the filters twice by checking if the filter is already registered libfilters:IsFilterRegistered(filterId) in advance (btw: wouldn't this even make sense to be added inside the libfilters:registerFilter function by default?)

Agreed. I already wrote one modification inspired by event registration in the API, this would bring it further. RegisterForEvent fails silently if the event has already been registered, UnregisterForEvent fails silently if it hasn't been registered. Register/UnregisterFilter could work in the same way, only returning success/failure status.

[Randactyl]

Thanks for the detailed replies.

Originally Posted by merlight Agreed. I already wrote one modification inspired by event registration in the API, this would bring it further.

I saw your comment mentioning this. So you have a working modification already? I do like this idea.

[circonian]

Originally Posted by Randactyl Additionally: I just put up the new version of libFilters. I'm going through AF in order to familiarize myself with the debug outputs that have been added, but I'm curious to see if either Baertram or circonian can drop the new version of libFilters into their already working debug edits of AF and see if the problem still exists? I'm working toward this myself too, would just be speedier results if one of you were available to test as well

I don't use it, I use my own libItemInfo for research information. It would require to many changes to put it into my addon just to test it.
I just got back from out of town though, if no one has tested it yet I could whip something up to test it with.

[circonian]

I just downloaded new copies of FCOItemSaver & Advanced filters. Whatever you guys did while I was gone seems to have made a huge improvement.

[merlight]

Originally Posted by merlight Originally Posted by Baertram Avoid registering the filters twice by checking if the filter is already registered libfilters:IsFilterRegistered(filterId) in advance (btw: wouldn't this even make sense to be added inside the libfilters:registerFilter function by default?) Agreed. I already wrote one modification inspired by event registration in the API, this would bring it further. RegisterForEvent fails silently if the event has already been registered, UnregisterForEvent fails silently if it hasn't been registered. Register/UnregisterFilter could work in the same way, only returning success/failure status.

I have to revise my previous answer. UnregisterFilter already fails silently if you try to unregister something that's not even there, so nothing to change here. RegisterFilter, on the other hand, fails with an error message if you try to register something twice - and if you think about it, that makes perfect sense. Failure is definitely the correct resolution in such case - you wouldn't want it to replace a previously registered filter without even saying duh? And when it fails, a message telling you what's wrong is invaluable.

Originally Posted by Randactyl I saw your comment mentioning this. So you have a working modification already? I do like this idea.

Yes, I updated the gist.

libFilters.lua : https://gist.github.com/merlight/e45...libfilters-lua
This is based upon r10, without debugging stuff. I removed ENCHANTING2 because it overlaps with ENCHANTING (on EXTRACTION tab both would have to be called), instead there are LAF_ENCHANTING_CREATION and LAF_ENCHANTING_EXTRACTION. FCO Item Saver will probably want to register both.

I also exposed RequestInventoryUpdate, an enhanced scheduleListUpdate which, when called with e.g. LAF_STORE and LAF_MAIL, will only cause one update (my original scheduleListUpdate would use different callbackNames and thus cause two updates).

libFilters_tags.lua : https://gist.github.com/merlight/e45...lters_tags-lua
This is the above + the change from filterId to filterTag.

[Randactyl]

Okay, I used libFilters_tags as the base for r11. I added a function to get the LAF that was applied last (libFilters:GetCurrentLAF()) so an addon can apply its generic filters to whichever LAF is active. This is what I'm using in Advanced Filters to choose which LAF to register my inventory filters for.

Other uses such as Item Saver should work fine as normal just registering for the one or two LAFs they want.

[merlight]

I was wondering what bloody editor adds a space at every empty line ... until I found out it's github Next time I link a gist, I should note to use "Raw" source

[merlight]

Ok I was reluctant to inject LAF type into inventories/layoutData, I thought there might be a better solution. Saving currentLAF in runFilters looked good, unfortunatelly there's a problem with it.

I'm at Bank Deposit tab. When I put something in the bank, it triggers filtering of both the backpack and bank inventories (due to SLOT_UPDATE events I guess). Afterwards currentLAF == LAF_BANK, although I'm still at Deposit tab and subfilters stop working until I switch the top filter twice without touching any subfilter in-between.

[merlight]

Injected filterType into inventories, added inventoryType argument to GetCurrentLAF : libFilters.lua / gist

Required change in AF:

local function SetUpCallbackFilter( self, filterTag )
    local inventoryType = GetCurrentInventoryType()
    local laf = libFilters:GetCurrentLAF(inventoryType)

edit: updated with LAF_IMPROVEMENT from below
edit2: oops, now really

[Baertram]

Originally Posted by Randactyl Okay, I used libFilters_tags as the base for r11. I added a function to get the LAF that was applied last (libFilters:GetCurrentLAF()) so an addon can apply its generic filters to whichever LAF is active. This is what I'm using in Advanced Filters to choose which LAF to register my inventory filters for. Other uses such as Item Saver should work fine as normal just registering for the one or two LAFs they want.

@merlight
Thx for the rework on libFilters again. I'll tets around with FCOItemSaver and the libfilters with filterTags.

@Randactyl:
Would it be possible to add the following LAF to libfilters too, to make it more "complete" for all the different panels?

LAF_IMPROVEMENT = 13

This one would be used at crafting stations at the improvement tab. The tab already got registered standrd filters to only shown items you are able to improve at the current crafting station type and which are able to be improved yet.

I think we cannot use it the same way with LAF_DECONSTRUCTION like LAF_ENCHANTING_CREATION and LAF_ENCHANTING_EXTRACTION are used (ENCHANTING.enchantingMode selects the index entry from array enchantingModeToFilterType to get the appropriate LAF for the filterType),
because the active panel at SMITHING can only be distinguished by the panel names (deconstructionPanel, improvementPanel, refinePanel, researchPanel):IsHidden() function and not by help of a variable like smithingMode. Am I right?

Based on merlight's libfilters with filter tags this should be the needed additions:

--LAF_IMPROVEMENT
libFilters.filters = {
    [LAF_BAGS] = {},
    [LAF_BANK] = {},
    [LAF_GUILDBANK] = {},
    [LAF_STORE] = {},
    [LAF_DECONSTRUCTION] = {},
    [LAF_GUILDSTORE] = {},
    [LAF_MAIL] = {},
    [LAF_TRADE] = {},
    [LAF_ENCHANTING_CREATION] = {},
    [LAF_ENCHANTING_EXTRACTION] = {},
    [LAF_IMPROVEMENT] = {},
}
 
--this one doesn't set the filter, but it IS the filter
--since this is a PreHook using ZO_PreHook, a return of true means don't add
local function ImprovementFilter( self, bagId, slotIndex, ... )
    return not runFilters(LAF_IMPROVEMENT, bagId, slotIndex)
end
 
 
local inventoryUpdaters = {
    BACKPACK = function()
        PLAYER_INVENTORY:UpdateList(INVENTORY_BACKPACK)
    end,
    BANK = function()
        PLAYER_INVENTORY:UpdateList(INVENTORY_BANK)
    end,
    GUILD_BANK = function()
        PLAYER_INVENTORY:UpdateList(INVENTORY_GUILD_BANK)
    end,
    DECONSTRUCTION = function()
        SMITHING.deconstructionPanel.inventory:HandleDirtyEvent()
    end,
        IMPROVEMENT = function()
                SMITHING.improvementPanel.inventory:HandleDirtyEvent()
        end,
    ENCHANTING = function()
        ENCHANTING.inventory:HandleDirtyEvent()
    end,
}
 
local filterTypeToUpdaterName = {
    [LAF_BAGS] = "BACKPACK",
    [LAF_BANK] = "BANK",
    [LAF_GUILDBANK] = "GUILD_BANK",
    [LAF_STORE] = "BACKPACK",
    [LAF_DECONSTRUCTION] = "DECONSTRUCTION",
    [LAF_GUILDSTORE] = "BACKPACK",
    [LAF_MAIL] = "BACKPACK",
    [LAF_TRADE] = "BACKPACK",
    [LAF_ENCHANTING_CREATION] = "ENCHANTING",
    [LAF_ENCHANTING_EXTRACTION] = "ENCHANTING",
        [LAF_IMPROVEMENT] = "IMPROVEMENT",
}
 
unction libFilters:InitializeLibFilters()
    if self.IS_INITIALIZED then return end
    self.IS_INITIALIZED = true
 
    -- PLAYER_INVENTORY.inventories[INVENTORY_BACKPACK].additionalFilter
    -- is reset every time a different backpack layout fragment is shown,
    -- therefore it needs to be hooked in each fragment's layout data
    hookAdditionalFilter(LAF_BAGS, BACKPACK_MENU_BAR_LAYOUT_FRAGMENT)
    hookAdditionalFilter(LAF_BAGS --[[ correct, not LAF_BANK ]], BACKPACK_BANK_LAYOUT_FRAGMENT)
    hookAdditionalFilter(LAF_STORE, BACKPACK_STORE_LAYOUT_FRAGMENT)
    hookAdditionalFilter(LAF_GUILDSTORE, BACKPACK_TRADING_HOUSE_LAYOUT_FRAGMENT)
    hookAdditionalFilter(LAF_MAIL, BACKPACK_MAIL_LAYOUT_FRAGMENT)
    hookAdditionalFilter(LAF_TRADE, BACKPACK_PLAYER_TRADE_LAYOUT_FRAGMENT)
 
    -- other inventories seem to never reset additionalFilter
    hookAdditionalFilter(LAF_BANK, PLAYER_INVENTORY.inventories[INVENTORY_BANK])
    hookAdditionalFilter(LAF_GUILDBANK, PLAYER_INVENTORY.inventories[INVENTORY_GUILD_BANK])
 
    ZO_PreHook(SMITHING.deconstructionPanel.inventory, "AddItemData", DeconstructionFilter)
        ZO_PreHook(SMITHING.improvementPanel.inventory, "AddItemData", ImprovementFilter)  
    ZO_PreHook(ENCHANTING.inventory, "AddItemData", EnchantingFilter)
end

Btw:
What is this function doing: HandleDirtyEvent() ?
Found at SMITHING.deconstructionPanel.inventory

[Randactyl]

Can't get to my computer for about an hour, but just for my understanding:

This new method would result in both LAF_(GUILD)BANK and LAF_BAGS being registered? Couldn't I just as easily in Advanced Filters check to see if the current LAF is one for the banks and also register for BAGS?

Of course, this leads to currentLAF really being a misnomer since those situations have more than one currrently applied. Should be something more like lastLAF

edit: Ohh I see how it will work for Bank/Bag. Current inventory and therefor current LAF will change every time change filter runs (clicking one of the big default filters). Does it also trigger when switching between deposit/withdraw?

Also, I'm not sure what GetCurrentInventoryType() will return for store, mail, trade, etc? I'm pretty sure it will be INVENTORY_BACKPACK and we wouldn't end up with the LAF_STORE etc.

function GetCurrentInventoryType()
    return g_currentInventoryType
end

[merlight]

Apparently I wrote that, but had to look it up nonetheless g_currentInventoryType is assigned in OnEffectivelyShown hooks on "inventory display controls", it can only be INVENTORY_BACKPACK, INVENTORY_BANK or INVENTORY_GUILD_BANK.

When you're at the bank, tabs switch between ZO_PlayerInventory (INVENTORY_BACKPACK) and ZO_PlayerBank (INVENTORY_BANK). PLAYER_INVENTORY.inventories[INVENTORY_BACKPACK].appliedLayout == BACKPACK_BANK_LAYOUT_FRAGMENT.layoutData the whole time, btw.

When you withdraw/deposit an item, filters get run on both BACKPACK and BANK inventories, so it's not always true that the last filterType from runFilters is the filterType of the currently displayed inventory control.

g_currentInventoryType matches the displayed control, and you can ask libFilters what's the current LAF for this inventoryType - for BANK and GUILD_BANK it's trivial, for BACKPACK the answer is in appliedLayout.

[Randactyl]

Test time!

All done right after a /reloadui. Zgoo used to view data.

Open relevant fragment, then choose one of the main filters. Results follow.

Inventory:
1. /zgoo GetCurrentInventoryType() -> INVENTORY_BACKPACK
2. /zgoo PLAYER_INVENTORY.appliedLayout.libFilters_filterType -> LAF_BAGS
3. /zgoo PLAYER_INVENTORY.inventories[GetCurrentInventoryType()].libFilters_filterType -> LAF_BAGS

Bank (withdraw):
1. INVENTORY_BANK
2. nil
3. LAF_BANK

Guild Bank (withdraw):
1. INVENTORY_GUILD_BANK
2. nil
3. LAF_GUILDBANK

Store, Deconstruction, Guild Store, Mail, Trade, Enchanting Creation/Extraction, Improvement:
1. INVENTORY_BACKPACK
2. nil
3. nil

So there is an issue with the hooking function that is supposed to run on init?

[circonian]

Originally Posted by Randactyl Test time! All done right after a /reloadui. Zgoo used to view data. Open relevant fragment, then choose one of the main filters. Results follow. Inventory: 1. /zgoo GetCurrentInventoryType() -> INVENTORY_BACKPACK 2. /zgoo PLAYER_INVENTORY.appliedLayout.libFilters_filterType -> LAF_BAGS 3. /zgoo PLAYER_INVENTORY.inventories[GetCurrentInventoryType()].libFilters_filterType -> LAF_BAGS Bank (withdraw): 1. INVENTORY_BANK 2. nil 3. LAF_BANK Guild Bank (withdraw): 1. INVENTORY_GUILD_BANK 2. nil 3. LAF_GUILDBANK Store, Deconstruction, Guild Store, Mail, Trade, Enchanting Creation/Extraction, Improvement: 1. INVENTORY_BACKPACK 2. nil 3. nil So there is an issue with the hooking function that is supposed to run on init?

I was gone for a week for thanksgiving and kind of lost track of what you guys are doing and I'm not 100% up on what it is you were expecting from this test. But, a few weeks ago I separated my filtering feature from my JunkIt addon and had been working on writing my own filter library for a separate addon release (only because I wanted the experience & I have fun doing this stuff). The point is some problems that I ran into may or may not be related or helpful, you may already know these things, but I'm going to point them out just in case it helps.

I don't know what you were expecting from that test, but some things I learned may apply to your test on the backpack. I had originally wrote my library to hook into the: ZO_InventoryManager:ShouldAddSlotToList so that as items were added to the inventory lists I would run custom filters against it. It worked fine for the backpack, bank, & guild bank.

Everything worked fine until I started final testing and realized the different layout views for the backpack: Mail, trade, store, exc.. had some problems. When trying to track it down I noticed that, for example, when the mail is opened for the first time the list is populated, and when it is closed ZO_InventoryManager:ShouldAddSlotToList would run again and repopulate the list of items reverting back to the default backpack view. After the mail had been opened 1 time, ZO_InventoryManager:ShouldAddSlotToList would NOT run again when the mail was opened, only when closed. Why would it not run every time the mail was opened, but only run on close?? My best guess seemed to be that the layoutData was applied when it was opened (on the already populated/current backpack list), but the list is only repopulated the first time a layout view is opened and when the layout view is closed (in order to revert back to the default backpack view). I could not figure out a way to fix it & had to scrap it in favor of using the additional filters in the layoutData for the different backpack layouts like is done in libfilters. I could find no other way of doing it other than using those layout additional filters for: backpack, trade, mail, trading house, & vendor.

My point is, that if you were doing this:

Inventory:
 1. /zgoo GetCurrentInventoryType() -> INVENTORY_BACKPACK
 2. /zgoo PLAYER_INVENTORY.appliedLayout.libFilters_filterType -> LAF_BAGS
 3. /zgoo PLAYER_INVENTORY.inventories[GetCurrentInventoryType()].libFilters_filterType -> LAF_BAGS

and storing data in the backpack inventory it may have been wiped out when the other layouts were applied for Mail, trade, vendor, trading house because they also use the backpack, but with a different view.


As for the others (I don't know how you guys handled this in your code, but) Enchanting does not use the backpack. It uses: ZO_CraftingInventory, as do all of the other craft stations. In mine I wrote separate filters for each crafting station, research, & improvement. For the crafting stations (refine/deconstruction) I rewrote: ZO_CraftingInventory:EnumerateInventorySlotsAndAddToScrollData to add additional checks & run the custom registered filters as it was enumerating the crafting inventories.

For deconstruction I used: ZO_SmithingResearchSelect:SetupDialog to hide things from the research dialog box.

and for the improvement filter I used: ZO_SharedSmithingImprovement_CanItemBeImproved to run my registered filters to see if we should allow an item to be improved or not. If an addons registered filters say the item should be hidden I just returned that the item can not be improved.

The only tough one seems to be hiding things from the provisioning stations since it seems all code only refers to recipes with recipeListIndex, recipeIndex. I found a way around it & I've got it working, I just need to do some final testing to double check everything.

[circonian]

I do have one question though. I glanced at some changes you guys made & I'm unclear on why libfilters is doing:

PLAYER_INVENTORY:UpdateList(INVENTORY_BACKPACK)

Since libFilters is using the layoutData.additionalFilter, which runs when the layout is applied...the list gets Committed/automatically updated after the layout is applied, so why call UpdateList ever?

[merlight]

@Randactyl
I'm running out of ideas. Tried to reproduce what BigM wrote about Sell in comments, but for me it works (now). It'll be some stupid obvious bug, obvious bugs are hard to find, they look like features

Originally Posted by circonian I do have one question though. I glanced at some changes you guys made & I'm unclear on why libfilters is doing: PLAYER_INVENTORY:UpdateList(INVENTORY_BACKPACK) Since libFilters is using the layoutData.additionalFilter, which runs when the layout is applied...the list gets Committed/automatically updated after the layout is applied, so why call UpdateList ever?

Yes and no. Advanced Filters change filters when the tab changes, in which case the inventory list is rebuilt anyway, so in AF this step could be avoided. But Item Saver has icons in the bottom of the inventory, which when toggled change the rules, and so they need to force inventory refresh.

[merlight]

Originally Posted by Randactyl Test time! All done right after a /reloadui. Zgoo used to view data. Open relevant fragment, then choose one of the main filters. Results follow.

Repeated, only instead of Zgoo I dumped the values to debug window. (summary: everything looks ok to me)

Inventory:
1. GetCurrentInventoryType() -> INVENTORY_BACKPACK
2. PLAYER_INVENTORY.appliedLayout.libFilters_filterType -> LAF_BAGS
3. PLAYER_INVENTORY.inventories[GetCurrentInventoryType()].libFilters_filterType -> LAF_BAGS

Bank (withdraw):
1. INVENTORY_BANK
2. nil (this was unexpected, I thought it would apply layout immediately when opening bank; however, while on withdraw tab, appliedLayout is irrelevant, since it only applies to backpack)
3. LAF_BANK

Bank (deposit):
1. INVENTORY_BACKPACK
2. LAF_BAGS (now it's ok)
3. LAF_BAGS

Guild Bank (withdraw):
1. INVENTORY_GUILD_BANK
2. nil
3. LAF_GUILDBANK

Guild Bank (deposit):
1. INVENTORY_BACKPACK
2. LAF_BAGS
3. LAF_BAGS

Store (buy, sell):
1. INVENTORY_BACKPACK
2. LAF_STORE
3. LAF_BAGS (this is ok, because LAF from appliedLayout takes precedence)

Mail (send):
1. INVENTORY_BACKPACK
2. LAF_MAIL
3. LAF_BAGS (same as above)

Originally Posted by Randactyl So there is an issue with the hooking function that is supposed to run on init?

I see correct values there. For me AF now works in bank, sell, mail.
The only issue I'm aware of now is that when I switch the top filter from e.g. Weapons to All and back to Weapons, subfilter dropdown doesn't appear.

[merlight]

Originally Posted by Baertram Btw: What is this function doing: HandleDirtyEvent() ? Found at SMITHING.deconstructionPanel.inventory

Didn't notice this question before.

function ZO_SharedCraftingInventory:HandleDirtyEvent()
    if self.control:IsHidden() or ZO_CraftingUtils_IsPerformingCraftProcess() then
        self.dirty = true
    else
        self:PerformFullRefresh()
    end
end

[Baertram]

Ah, thanks for the function explanation. Really dirty :-)

Edit:
I've found the error... as I thought it was a simple one, but hard to find.
As libFilters was updated and LAF_ENCHANTING and LAF_ENCHANTING2 were removed and changed to new LAF_ENCHANTING_EXTRACTION and LAF_ENCHANTING_CREATION constants the constant's integer value changed too.
Inside my addon I forgot to update them properly and my maximum value of available panels did not increase as LAF_IMPROVEMENT was added later.
libFilters:UnregisterFilter() did silently fail then as the tag of the filter contains the panelId in FCOItemSaver...


Error description (SOLVED!)
I'm currently rewriting FCOItemSaver to speed up and use the new libFilters correctly.

Changed:
-Only the enabled filter settings (bags, bank, guild bank, vendor, etc.) will register according filters
-The filters and buttons at the inventories will only be registered if the panel is shown, otherwise only LAF_BAGS is registered (if enabled)
So at the start of the addon only the LAF_BAGS filter will registered
-The filter buttons will be created/changed (OnClicked function, colors, etc.) as the panel is shown
The inventory filter buttons will be used for all the panels where ZO_Inventory is used (banks disposal, mail, trade, guild store sell, vendor, inventory). This is done in function "CheckFilterButtonsAtCurrentPanel".
-I'm choosing the current panel by help of events and PreHooking function "OnMouseUp" at the top menu buttons at some stations, or using the scene callback for the mail_send part (thx to merlight).

It is working together with AdvancedFilters and seems to be ok so far.

The only part not working is the LAF_IMPROVEMENT one :-( It must be some silly "feature" like merlight has written above

LAF_IMPROVEMENT should be enabled as I click the improvement button at a crafting station (preHook OnMouseUp function at line 5638) or open up the crafting station (SMITHING is shown) and the improvement tab is already shown from the last usage of the improvement parts.
The current panel will be selected in function "checkActivePanel".

Error:
If I click the improvement button it will start to repeat the called function "FCOItemSaver_PreHookButtonHandler()" every second again?
This will go on until I click the deconstruction button (line 5631).
If I do not /reloadui or click the deconstruction button the game client might crash after a while.

I'm not able to see why this prehooked button is behaving that bad :-(
All other buttons react as aspected and will only run the code inside once.
I've even implemented a variable to prevent this repeating (preventerVars.gButtonChanging) but it is not working either.

Inside the chat type "/fcois deepdebug" (and use an addon to see the "pre addon loading text" maybe) to enable the debug output.

Here is the version causing this bug:
https://dl.dropboxusercontent.com/u/...ENT_button.zip

I'd be glad if someone could help me where this "repeating" button click error comes from.

btw:
I've not changed all the right click menu hook, self made pre hook functions, and that other stuff (debugMessage function etc.) circonian and merlight have pointed me to before. I focused on removing the unnecessary filters and buttons and inventory updates first.
So please don#t review this code again

[merlight]

Originally Posted by Baertram Error: If I click the improvement button it will start to repeat the called function "FCOItemSaver_PreHookButtonHandler()" every second again? This will go on until I click the deconstruction button (line 5631). If I do not /reloadui or click the deconstruction button the game client might crash after a while. I'm not able to see why this prehooked button is behaving that bad :-( All other buttons react as aspected and will only run the code inside once. I've even implemented a variable to prevent this repeating (preventerVars.gButtonChanging) but it is not working either.

Weird. I'm not going to test now, Dortene called I should come defend some elder scrolls...
I'd rather divert you from the idea of hooking buttons' OnMouseUp completely.

This is SMITHING:SetMode:

function ZO_Smithing:SetMode(mode)
    if self.mode ~= mode then
        self.mode = mode
 
        CRAFTING_RESULTS:SetCraftingTooltip(nil)
        self.refinementPanel:SetHidden(mode ~= SMITHING_MODE_REFINMENT)
        self.creationPanel:SetHidden(mode ~= SMITHING_MODE_CREATION)
        self.improvementPanel:SetHidden(mode ~= SMITHING_MODE_IMPROVEMENT)
        self.deconstructionPanel:SetHidden(mode ~= SMITHING_MODE_DECONSTRUCTION)
        self.researchPanel:SetHidden(mode ~= SMITHING_MODE_RESEARCH)
 
        KEYBIND_STRIP:UpdateKeybindButtonGroup(self.keybindStripDescriptor)
        TriggerTutorial(self.GetTutorialTrigger(self, GetCraftingInteractionType(), mode))
    end
end

It readily offers two ways of catching when a panel is shown/hidden. You can either hook SMITHING:SetMode, or OnEffectivelyShown/OnEffectivelyHidden handlers on each panel you're interested in. You won't need to check whether mouse button == 1 and upInside and lastClickedButton, and you don't need to delay it with zo_callLater - you know what's being shown right there. The code should really be simpler.