by Nymbia | 23/05/2007 13:22:35

From the 2.1 changes thread: Q u o t e: * For "item" buttons, name can be an item ID or item link.
This doesn't work with item ids. The reason is that SecureCmdItemParse on line 1326 of ChatFrame.lua is not designed with itemids in mind.
function SecureCmdItemParse(item) if ( not item ) then return nil, nil, nil; end local bag, slot = strmatch(item, "^(%d+)%s+(%d+)$"); if ( not bag ) then slot = strmatch(item, "^(%d+)$"); end if ( bag ) then item = GetContainerItemLink(bag, slot); elseif ( slot ) then item = GetInventoryItemLink("player", slot); end return item, bag, slot; end
When an item link is fed through that function, it simply fails both matches and returns back the item link, but that doesn't matter, since UseItemByName can accept an item link (which is where the execution path lands in SecureCmdUseItem).
On the other hand, when you feed a number or pure number string in as the attribute, it gets caught in the second match: slot = strmatch(item, "^(%d+)$"); and it explodes quite spectacularly, thinking your itemid is a player equip slot:
Interface\FrameXML\ChatFrame.lua:1337: GetInventoryItemLink(): Invalid inventory slot: Interface\FrameXML\ChatFrame.lua:1337: in function `SecureCmdItemParse': Interface\FrameXML\SecureTemplates.lua:243: in function `SecureActionButton_OnClick': <string>:"*:OnClick":1: in function <[string "*:OnClick"]:1>
The kicker is that you can trick the pattern match into failing with a tailing space.
frame:SetAttribute("item", itemid) -- explodes spectacularly
frame:SetAttribute("item", itemid..' ') -- works beautifully
A check on the bound of the captured number should solve this easily. [ Post edited by Nymbia ]
Nymbia is a cheater. |