CompactVendor

v11.1.7.250723 (2025-07-23)

Full Changelog Previous Releases

• Version bump
• Tooltip scanning will store callbacks and re-use existing ongoing requests, instead of making new duplicates. This way we simply respond to all callbacks interested in the same item hyperlink when it's ready.
• Split up the tooltipData into additional props to track state and data and the unique scanner ID (for response tracking).
  Moved the response handling and callbacks to their own methods RefreshTooltipData and OnTooltipScanResponse which are called when appropriate.
  This simplified the code in the Refresh routine to simply use the tooltipData when available, otherwise start a scan task and assign the relevant fields and provide the callbacks needed to update the correct item once the response returns.
  The TooltipScanner is now specifically containing the relevant methods we need for its purpose.
• TOC bump.
• The merchant item has awareness on which button is using it.
  Moved the cleanup of button code in a view factory resetter handler.
  The tooltip scan will ensure the results still match the expected merchant item ID, and abort if not. (This could happen if a response is delayed and the frame reused for another item in the meantime.)
  When the view assigns a button it also assigns that buttons merchant item object, and the parentButton on said object. (And during resetting this is cleaned up.)
  The update merchant routine will, when possible, call the UpdateMerchantItemButton method as data is refreshed so the visuals match the backend state.
  Previously this only occured when the button is displayed, or when specific events related to bags occured. This would sometimes lead to state missmatch, but hopefully not anymore.
• Tooltip scanning can be delayed, and when it is, we need to call the UpdateMerchantItemByID method. We only wish to do that when there is a delay, meaning there was no tail-call that instantly resolved tooltipData.
• Multiple requirements on the same item should yield results if one of them is checked.
  This way the list fills up with appropriate checked results, even if just partial.
• Removed the old tooltip scanning code, and replaced it with the new one.
  Added polyfill for the pre 10 clients by implementing a local C_TooltipInfo for our purpose.
  Can consider implementing the ScanMerchantItem equivalent, considering some tooltips contain requirements specific to that way of rendering tooltips.
• Fixed minor filter refreshing behavior issues. Setting filters and changing the merchant filters, should properly reset them as intended.
  Added new tooltip scanning code and trying it out by overloading the TooltipScanner.ScanHyperlink method.
  The new method will simply replace the old loading system, the new one should be better. After enough testing, I will remove the old code that is no longer needed if this is the case in practice.
  Setting MerchantItem:IsRequirementScannable() to true while doing these tests, so as many tooltips get scanned so I can inspect stability and accuracy.
• • TOC bump
    • Fixed the item stats filter
• If it wasn't for the tooltip scanning delay the requirements filter dropdown itself functions as expected.
  But there is some wonky behavior when swapping the filter between "All" and "All Specializations" which cause some wonky loading behavior, the provider doesn't always fully return all items, some pending once might get locked waiting, etc.
  This appears to be caused due to tooltip scanning of too many things at once adds more delay and potential failure, so need to re-think the tooltip scanning code and making it more robust to avoid this from happening.
  Need to revisit the events called from the bottom up, so we properly subscribe to callbacks relevant to each step, so that the filter button on top properly refreshes when it has to.
  After some cleaning up it is better, but not good enough to simply enable the full tooltip scanning behavior on all items, so keeping it on recipes and pets for now.
• Renamed the old CanLean method to a universal HasRequirements method which will scan and extract the various requirements, the old method did the same logic just worse and used an older naming convention which is now corrected.
  Requirements are scanned from the bottom up, and will stop scanning as soon a non-requirement is encountered after any requirements that were found.
  This is to avoid embed issues, where the tooltip contained data from an embeded item, but we couldn't know where it ends and the regular tooltip continues.
  Updated the stats filter and the requirements filter, it had to be adjusted to consider the checked options/values, so only those were taken into account when deciding if to show or hide the item in question.
  There are still some oddities with the requirements, will need to do more testing.
• Marked all items as scannable, since we don't know in advance if an item has or doesn't have any requirement lines in its tooltip.
  This flags all items for tooltip scanning, thus allowing the CanLearn method to extract all sort of requirements, not only for recipes, pets, cosmetics, etc.
  Need to profile performance on large vendors, like renown quartermasters and other quartermasters with a lot of items.
• Fixed a bit of docs and a bit of filter code. Added a TODO on the requirements filter, right now it won't work to toggle the filters, they are properly detected, but we need to change the filter dropdown to reflect the contents of the actual requirements.
• Created MerchantItem:CanAfford() and using it where suitable instead of the prop directly.
  Created MerchantItem:GetLearnRequirements(predicate?) and MerchantItem:GetLearnRequirementsForRedProfessions() methods and using these instead of a loop and logic in the UpdateMerchantItemButton function.
  This way it's a bit more clear what the purpose is, and reusable if I need similar checks elsewhere.
• No need to try to purchase something we can't afford. This avoids the confirmation popup for items we can't buy either way.
• Fixed tooltip scanning issues around profession scanning of requirements.
  An item can have multiple requirements, and we mostly care about the profession one for coloring, and the dropdown filters care for all of them combined.
  There is more work to be done to confirm the other kind of requirements: level, rating, achievement, guild, reputation, specialization, renown, and check for other kinds that we should add to the filter and scanning code.
• The merchant filter event is too costly, so we do like the default UI does it, just queue a full update to occur later once the events settle.
  This primarily affects merchants with a lot of items, like renown quartermasters, timewalking vendor, etc. And it only occurs the first time the merchant frame is opened, as the client caches the data until you properly logout and back in again.
• TOC bump
• Merchant filter needs to track the updatesd on a per-item basis and not just as "the last one gets updated" like it previously was.
  This wasn't really noticeable as long a full update was performed, which often happens once filter events settle, but still it could lead to some oddities.
  Added a loading spinner when the frame shows until it is done loading data. Would only affect the frame when initially shown as the server needs a bit of time to send data to the client.
  Added status text when the vendor has no items to sell, or is filtered by the filter system, so the user knows it's empty and not that it's waiting to load data (though the spinner now helps cover the loading aspect).
• TOC updates
• Minor doc updates.
  Updated the stat filter to accumulate multiple checks so that all items matching all the checked boxes appear in the list.
• Version bump.
• Placed the refresh and update merchant button behavior into RefreshAndUpdateMerchantItemButton for convenience.
  We call this when the merchant item button is being shown, or when an even fires, to ensure an up-to-date visual state.
• Merchant buttons listen for currency or bag item updates to refresh and update themselves.
  The refresh merchant item code might not be ideal there, so need to think about where to place it. The button update event on the other hand is fine as it related to the button visuals.
  Created a safer FrameUtil in case some event isn't available in the other client flavor. Might want to do specific research and cover those cases manually so everything keeps working as intended.
• Version bump.
• Cleaned up CreateMerchantItemButton since it always receives the widget button reference, didn't need the old code, except the update call.
  The merchant item refresh method had the quality and qualityColor assignment updated to always reflect the itemLink quality and to update both at the same time, to avoid odd de-sync behaviors that could previously occur.
• TOC bump
• Updated logic when merchant frame shows and loads items.
  The end result should be a smoother and more stable experience when opening a merchant that has items that the game has to load for the first time.
  Once ready the filters will also update themselves to ensure nothing is being incorrectly filtered.
• TOC bump
• Added support for the new color in hyperlinks.
• TOC bump.
• Transmog API are unstable on Classic so added an override to avoid that situation as a fix for the addon.
• Changes to GetMerchantItemInfo had to have a method implemented to migrate between the old style and the new table return value.
  Some minor docs changes.
• Fixed colorblind mode detection, in addition to the legacy or deprecated global, I also check the cvar itself just like the latest UI code does it when handling rendering money strings.
• Fixed issue on Classic SOD when talking to Pix Xizzix (and other vendors with Relics).
• Add support for CanIMogIt so when it's available we use it to detect the status of appearance collection.
• TOC bump
• Track the event for merchant show/closed by setting the merchantOpen boolean accordingly.
  Reply on this new boolean in UpdateMerchantInfo so that if we're not on a merchant we ensure to cleanup and answer properly, we can't be on a merchant if the event said we closed the interface.
  Added BuyEmAll support, if the addon is loaded, it will be used for stack purchase instead of the built-in standard frame.
  The new Open/Close/IsOpen methods on the quantity button widget will use the API for BuyEmAll when available, otherwise fallback to default behavior.
• The wow token price check should only happen on mainline, as classic era and other flavors might not be properly handling the token pricing, as it can cause lua errors on those clients.
• Updated GetItemCount to properly include reagent bank and the warbank when checking if you can afford something.
• TOC bump.
• Use Yes/No instead of the collected texts.
• Adjusted item appearance collection status logic. Will display Appearance with Yes/No, and Appearance: Collected if we have collected the appearance or not, given that the first filter is properly set to show collectable items.
• TOC bump
• Fixed minor issue with Learnable: Collected detection and classification.
• TOC bump.
• Minor layout adjustments for 11.
• Minor 11 changes.
• TOC bump