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
- -4 for the tokens bag
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 to 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 to 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. Many of these globals are defined in FrameXML\Constants.lua, if you're curious.