Custom Events

To allow for Wildpants to be used by two very different user interfaces (Bagnon and Combuctor), different features and UI components tend to be agnostic to each other. Thus, to communicate, they broadcast messages for others to listen to. This is done using AceEvent-3.0 and the addon name as a prefix.

The addon object and every UI component provide these methods:

• :RegisterSignal
• :UnregisterSignal
• :UnregisterSignal
• :SendSignal

Thus, you can listen to an event as either:

Bagnon.RegisterSignal('MyAddon', 'UPDATE_ALL', myCallback)
AceEvent.RegisterMessage('MyAddon', 'BagnonUPDATE_ALL', myCallback)

This page lists the events currently used in Bagnon and Combuctor, as it can be potentially useful when making plugins. It also helps keeping me sane. For more information on the API used to register and fire the events, look at AceEvent-3.0 documentation.

Global Events

Some of the Blizzard inventory server events are not very informative. Thus, making a performant inventory related addons is not as simple as one might expect. Wildpants simplifies this process. It builds upon the server events to implement additional more informative ones:

Name	Description
BAG_UPDATE_SIZE (bagID)	Fired when number of slots in a bag changes
BAG_UPDATE_CONTENT (bagID)	Fired when items in a bag change

The following events affect all Wildpants frames. They are used by frames to communicate with each other, and can be used by 3rd party addons to communicate with them as well:

Name	Sent by	Used by	Description
UPDATE_ALL	Configuration menus	All components	Refresh every UI component
RULES_LOADED	Ruleset API	ruleFilter	Fired after one or more rulesets are registered or updated
SEARCH_CHANGED	Search boxes	item	Fired when the global search query has been changed
FLASH_ITEM (itemID)	item	item	Flash every item with the given itemID

💡 UPDATE_ALL can be fired by calling Addon:UpdateFrames()

Frame Events

UI components can also send messages only to be received by components in the same frame. These typically involve reacting to user interaction in a frame which has no effect on other frames. To allow for this behaviour, all UI elements provide these additional methods:

• component:RegisterFrameSignal
• component:UnregisterFrameSignal
• component:SendFrameSignal

Current frame events are as follows:

Name	Sent by	Used by	Description
PLAYER_CHANGED	playerDropdown	Multiple components	The player to be displayed has been changed
FILTERS_CHANGED	Multiple components	itemFrame	Parameters dictating which items should be shown (bags, quality, rule, subrule) have changed
QUALITY_CHANGED	qualityButton	qualityButton	The item qualities selected have changed
RULE_CHANGED (ruleID)	sideTab	sideTab, bottomFilter	The rule selected has changed
SUBRULE_CHANGED (ruleID)	bottomTab	bottomTab	The subrule selected has changed
BAG_TOGGLED (bagID)	bag		A bag visibility has been toggled
BAG_FRAME_TOGGLED	bagToggle	bagFrame, frame	The bagFrame visibility has been toggled
FOCUS_BAG (bagID)	bag	item	The items in the given bag slot should be highlighted. bagID is ´nil´ if none should
ELEMENT_RESIZED	itemFrame, currencyTracker	frame	The dimentions of a component of the frame has changed

💡 FILTERS_CHANGED is a generalization of the QUALITY_CHANGED, RULE_CHANGED, SUBRULE_CHANGED and BAG_TOGGLED events. If you fire any of these events, you should also fire FILTERS_CHANGED.

Frame messages are implemented as a global message prefixed by the ID of the frame in question (result ain't pretty, but efficient). Thus, you can still access these events in a 3rd party mod. For example:

Bagnon.RegisterSignal('MyAddon', 'inventoryPLAYER_CHANGED', myCallback)
AceEvent.RegisterMessage('MyAddon', 'BagnoninventoryPLAYER_CHANGED', myCallback)

Would register a callback to be fired when a different character in the Bagnon inventory frame is selected.