#0 - Jan. 9, 2009, 7:08 a.m.
The most nightmare line one could possibly include in a macro. Current functionality of this line involves executing an "acceptance" of the last pop-up box the client displayed. "StaticPopup1" is the name of the frame used for:
Confirming rolling on a BoP item,
Accepting an enchant overwrite,
Accepting a summon,
Accepting a resurrect,
Accepting a group invite,
Confirming the command to reset instances,
and a multitude of others I'm sure I've missed.
If a player logs in and executes the command /click StaticPopup1Button1 before any confirmation boxes have been displayed, the player promptly receives an error:
Interface\FrameXML\StaticPopup.lua:2790:
attempt to index field '?' (a nil value)
If, however, a player has received at least one pop-up box during their play session, they will never receive an error, even if the box is not currently on-screen. My first real encounter with this bug was when I wrote a simply macro to bind to a key to roll Greed on any item currently being rolled on. My first draft of this macro was:
/click GroupLootFrame1GreedButton
this worked just fine for BoE greens, but upon using it to roll on a BoP blue boss drop, I still received the annoying confirmation box. Therefore, my second draft of the macro became:
/click GroupLootFrame1GreedButton
/click StaticPopup1Button1
This worked just fine at first. A BoP blue item drops, I press it and roll Greed. A BoE green drops, I press it, roll Greed again. In the background on this second press, it was attempting to confirm a loot roll that didn't need confirmation, but this wasn't visible to the client. The bug surfaces when I exit the instance, issue the "Reset All Instances" command, and zone back in. Next time a BoE green drops, I press my macro, and everyone in my group receives a yellow system message to their chat frame:
"Your group leader has attempted to reset your instance. Please zone out to allow the instance to reset."
or something very similar to that. This is all despite the fact that, should a group leader right click their portrait while inside the instance, the "Reset All Instances" option is no longer present. This is because the BoE green did not generate a confirmation box, and so the /click StaticPopup1Button1 simulated a confirmation of the last pop-up box that DID appear, and promptly attempted to reset my instance. If I wasn't in an instance, my macro would have ACTUALLY reset the instance, despite nothing of the sort being present on-screen or in the macro, simply because it was the last pop-up I received.
Now, additional funny errors can be similarly generated by using this command to send commands to the server to:
Accept a resurrection while alive,
Accept a summon you've already accepted,
Accept a group invite you're already in,
and the list goes on and on.
Now, this is all good information about why /click is broken and why you should avoid using it in this manner, but I haven't said anything about using it to circumvent protected functions. Hang on, I'm almost there.
So, I stopped using /click in this manner after all kinds of bizarre undefined behavior, and instead replaced it with the "correct" way of doing things, which involves a method call looking similar to:
/script AcceptSomeSortOfDialogue();
depending on the exact application. This worked fine until I got to my enhancement shaman, and decided to write one-click macros to refresh my weapon enchants. My first draft of this macro looked like:
#showtooltip
/cast Windfury Weapon
/use 16
/script ReplaceEnchant();
imagine my surprise when I receive a big ol' fat error:
"A macro script has been blocked from an action only available to the Blizzard UI."
Oh. Well then. Apparently, ReplaceEnchant() is a protected function. Well then, not to fear, lets just replace it with:
#showtooltip
/cast Windfury Weapon
/use 16
/click StaticPopup1Button1
and, of course, it works perfectly, circumventing a protected function. Unless, of course, my weapon is currently unenchanted. In which case...it probably resets my instance. ^_^
