WoW:BagId: Difference between revisions
No edit summary |
(Make 2.0 changes seem less new. Document constant names and how you SHOULD code.) |
||
Line 1: | Line 1: | ||
{{wowapitype}} | {{wowapitype}} | ||
While dealing with container and inventory items, many developers use a bag/slot couple and set bag to -1 for the case of an inventory item. But a problem occurs when the bank is opened (after BANKFRAME_OPENED event being fired) because the 28 slots of the bank count as actual container slots with -1 as bagID. In the same idea, items in the bank bags can be accessed via container item functions (like [[API GetContainerItemLink|GetContainerItemLink(bagID, slotID)]], [[API PickupContainerItem|PickupContainerItem(bagID, slotID)]]) with 5 as bagID for the first bank bag, 6 for the second ... until 11 for the seventh. | |||
While dealing with container and inventory items, many developers use a bag/slot couple and set bag to -1 for the case of an inventory item. But a problem occurs when the bank is opened (after BANKFRAME_OPENED event being fired) because the | |||
To sum up, the possibilities for bagID are : | To sum up, the current possibilities for bagID are : | ||
* 0 for the backpack | |||
* 1 to 4 for the bags on the character (numbered right to left) | |||
* -2 for the keyring | |||
While the bank is opened: | |||
* -1 for the bank content | |||
: | * 5 to 11 for bank bags (numbered left to right, was 5-10 prior to 2.0) | ||
== How you should code == | |||
You should not assume fixed numbers when there are named constants to use. Access your bags according to the following scheme: | |||
* 0 is your backpack | |||
* 1 -- NUM_BAG_SLOTS are your bags | |||
* KEYRING_CONTAINER is the keyring | |||
While the bank is opened: | |||
* BANK_CONTAINER is the bank window | |||
* NUM_BAG_SLOTS+1 -- NUM_BAG_SLOTS+NUM_BANKBAGSLOTS are your bank bags | |||
This follows the way [[FrameXML]] works. Future changes to APIs are less likely to make your addon break if you follow it. |
Revision as of 11:55, 28 May 2007
While dealing with container and inventory items, many developers use a bag/slot couple and set bag to -1 for the case of an inventory item. But a problem occurs when the bank is opened (after BANKFRAME_OPENED event being fired) because the 28 slots of the bank count as actual container slots with -1 as bagID. In the same idea, items in the bank bags can be accessed via container item functions (like GetContainerItemLink(bagID, slotID), PickupContainerItem(bagID, slotID)) with 5 as bagID for the first bank bag, 6 for the second ... until 11 for the seventh.
To sum up, the current possibilities for bagID are :
- 0 for the backpack
- 1 to 4 for the bags on the character (numbered right to left)
- -2 for the keyring
While the bank is opened:
- -1 for the bank content
- 5 to 11 for bank bags (numbered left to right, was 5-10 prior to 2.0)
How you should code
You should not assume fixed numbers when there are named constants to use. Access your bags according to the following scheme:
- 0 is your backpack
- 1 -- NUM_BAG_SLOTS are your bags
- KEYRING_CONTAINER is the keyring
While the bank is opened:
- BANK_CONTAINER is the bank window
- NUM_BAG_SLOTS+1 -- NUM_BAG_SLOTS+NUM_BANKBAGSLOTS are your bank bags
This follows the way FrameXML works. Future changes to APIs are less likely to make your addon break if you follow it.