I've got a feature to auto accept group invites in my MultiTool addon if certain conditions are met...
self:RegisterEvent("PARTY_INVITE_REQUEST", "confirmPartyInvite")
function MultiTool:confirmPartyInvite(info, sender)
if (self.db.profile.groupRejectFlag and not self:isInWhiteList(sender)) then
DeclineGroup()
StaticPopup_Hide("PARTY_INVITE")
return
elseif (self.db.profile.groupFlag and self:isInWhiteList(sender)) then
AcceptGroup()
StaticPopup_Hide("PARTY_INVITE")
return
end
end
My problem is that it looks as though the call to StaticPopup_Hide("PARTY_INVITE") is happening so soon after AcceptGroup() that AcceptGroup() ends up getting overridden by the popup hide.
I can put in some kind of delay, or otherwise change the way the code works and probably get it working, but I wanted to post here in case either someone else already figured it out, or else to let folks know that it appears there was some undocumented (as far as I can see) change in the way the StaticPopup_Hide("PARTY_INVITE") is being handled.
I was thinking along slightly different lines, but I think either of these will work out better for me.
Still curious if 3.1 just plain changed something, or if I've had broken code all along, but was getting away with it until high server lag during patch day caused the "brokenness" to show through.
Still curious if 3.1 just plain changed something, or if I've had broken code all along, but was getting away with it until high server lag during patch day caused the "brokenness" to show through.
The 'Group' module in Automaton (not yet updated for 3.1) is suffering from a similar problem. Going to add the inviteAccepted workaround locally and see if it helps (it should).
edit: it does. left a comment on the automaton wowace page.
function MultiTool:OnEnable()
UIParent:UnregisterEvent"PARTY_INVITE_REQUEST"
self:RegisterEvent"PARTY_INVITE_REQUEST"
end
function MultiTool:PARTY_INVITE_REQUEST(_, sender)
if self.db.profile.groupRejectFlag and not self:isInWhiteList(sender) then
DeclineGroup()
elseif self.db.profile.groupFlag and self:isInWhiteList(sender) then
AcceptGroup()
else
StaticPopup_Show("PARTY_INVITE", sender)
end
end
I did indeed go with Borlox's code (even put thanks in change notes and in source code to him and Dridzt) and published as 0.3.02.
However, the idea about registering/unregistering sounds interesting.
Thus far I have pretty much relied on existing API documentation... I get the impression that the first place I should look is where? the Blizzard-generated addons?
Jerry,
First of all, thanks for the example fix.
I have a question though, if I unregister event, is that only local to my app or am I changing the way it works for all other addons? My assumption is it's only local, but I really want to be sure I understand what I'm doing.
I have a question though, if I unregister event, is that only local to my app or am I changing the way it works for all other addons? My assumption is it's only local, but I really want to be sure I understand what I'm doing.
You would be unregistering the "PARTY_INVITE_REQUEST" from UIParent. Which means that the frame UIParent would not receive notification when the "PARTY_INVITE_REQUEST" event fires, and thus the piece of code in FrameXML/UIParent.lua will not be run.
The effect is that UIParent stops showing a Dialog when the "PARTY_INVITE_REQUEST" is fired, so your code can determine wether or not it's relevant to show the dialog, and do so itself.
It's a global change in the sense that there is only one UIParent frame that is initialized by Blizzard. But any addon that which to listen to "PARTY_INVITE_REQUEST" can do so.
Another alternative is to raw hook the StaticPopup_Show() function and test whether (which == "PARTY_INVITE"). If it's true, then AcceptGroup() and exit. Otherwise, just call the original function.
I'm not comfortable with jerry's solution for that reason. It seems more likely to break down the line, should Blizzard decide to add something else to that event later.
Here's the solution I'm using:
function Automaton_Group:ProcessInvite(accept)
if accept then
AcceptGroup()
self:RegisterEvent("PARTY_MEMBERS_CHANGED")
else
DeclineGroup()
end
end
function Automaton_Group:PARTY_MEMBERS_CHANGED()
StaticPopup_Hide("PARTY_INVITE")
self:UnregisterEvent("PARTY_MEMBERS_CHANGED")
end
The only downside with this method might be that the window does actually get displayed for a second or two, depending how long it takes for your AcceptGroup() to go through. Personally, I prefer it this way, since it calls a little more attention to itself. I used to frequently not even notice I had joined a group.
First of all, thanks for updating wowwiki - I had updated that AcceptGroup() page earlier and once I worked out the issues here, I went back and started updating the example ... then realized you had beat me to it. I rolled back my edits and posted a comment in the talk page apologizing for the unintentional "edit war"
Second of all, I actually LIKE the idea that you would see the dialog for a little bit too... I mean, the reason I put the feature in my addon was so I could easily group my toons up together while multi boxing. I just needed something that would accept my request and get the dialog out of the way, not completely change the way wow works.
I'm going to test your solution and if it works nicely, I may just replace the current fix.
Still, my addon is working and updated, and I used Borlox's fix (with attribution) to help out another multiboxer addon (I say another, but really it's THE BIG multiboxer addon), Jamba because the author is away on holiday and can't fix and test his addon til he gets back in May.
I've said it before and Ill say it again, I love the developer community.
Another alternative is to raw hook the StaticPopup_Show() function and test whether (which == "PARTY_INVITE"). If it's true, then AcceptGroup() and exit. Otherwise, just call the original function.
Bit of a sledgehammer there though, isn't it? Potentially introducing taint and interspersing code for every single popup seems a "heavier" solution than just adjusting the one addon that needs it.
Bit of a sledgehammer there though, isn't it? Potentially introducing taint and interspersing code for every single popup seems a "heavier" solution than just adjusting the one addon that needs it.
Sure, although you obviously should have this kind of consideration any time you hook something so I don't see how this case is any better or worse than hooking anything else. I didn't say this was the best solution and it's not necessarily worse than, eg. blocking UIParents from receiving PARY_INVITE_REQUEST.
I really fail to see what problem you have with unregistering a event on a frame. And I beg to differ on the idea that it's more likely to fail than the idea I have seen around here, which either rely on undocumented assertions (that frame receive an event in a particular order that is not random) or that present the user with a confusing interface that make him think that he has a choice where he doesn't.
If you want to notify the user that he has entered a group, then you can do that.
I still think Borlox's idea is the smallest footprint one.
Just sets a flag for the specific popup and that's it.
Weab's idea of listening for the PARTY_MEMBERS_CHANGED event
and only hiding the popup (if it's there) after the party invite has gone through is also simple and minimal impact. (a different but clunky implementation of the same idea:
"hide the popup once you're sure the group inv has actually been accepted"
was my OnUpdate + check for GetNumPartyMembers())
Weab's way is much better if you go that approach.
The rest are all valid solutions but at the moment it's academic exercise imho.
Do you find a problem with either? I don't, while I find all comments
about "messing with more than needed" or "relying on a specific event firing order", valid.
I think we can safely assume that PARTY_INVITE_REQUEST will always precede PARTY_MEMBERS_CHANGED
Just my 2c :)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumself:RegisterEvent("PARTY_INVITE_REQUEST", "confirmPartyInvite") function MultiTool:confirmPartyInvite(info, sender) if (self.db.profile.groupRejectFlag and not self:isInWhiteList(sender)) then DeclineGroup() StaticPopup_Hide("PARTY_INVITE") return elseif (self.db.profile.groupFlag and self:isInWhiteList(sender)) then AcceptGroup() StaticPopup_Hide("PARTY_INVITE") return end endMy problem is that it looks as though the call to StaticPopup_Hide("PARTY_INVITE") is happening so soon after AcceptGroup() that AcceptGroup() ends up getting overridden by the popup hide.
I can put in some kind of delay, or otherwise change the way the code works and probably get it working, but I wanted to post here in case either someone else already figured it out, or else to let folks know that it appears there was some undocumented (as far as I can see) change in the way the StaticPopup_Hide("PARTY_INVITE") is being handled.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI only SetScript the OnUpdate in the PARTY_INVITE_REQUEST event
and nil it after hiding the popup.
for i=1, STATICPOPUP_NUMDIALOGS do local dlg = _G["StaticPopup"..i] if dlg.which == "PARTY_INVITE" then dlg.inviteAccepted = 1 break end endIt loops through all StaticPopups and sets the inviteAccepted flag for the one that is showing the invite message.-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI was thinking along slightly different lines, but I think either of these will work out better for me.
Still curious if 3.1 just plain changed something, or if I've had broken code all along, but was getting away with it until high server lag during patch day caused the "brokenness" to show through.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou loop though it to find the dialoug, why not just call the accept buttons :Click() script?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe 'Group' module in Automaton (not yet updated for 3.1) is suffering from a similar problem. Going to add the inviteAccepted workaround locally and see if it helps (it should).
edit: it does. left a comment on the automaton wowace page.
and choose yourself wether or not showing a Dialog in your code ?
function MultiTool:OnEnable() UIParent:UnregisterEvent"PARTY_INVITE_REQUEST" self:RegisterEvent"PARTY_INVITE_REQUEST" end function MultiTool:PARTY_INVITE_REQUEST(_, sender) if self.db.profile.groupRejectFlag and not self:isInWhiteList(sender) then DeclineGroup() elseif self.db.profile.groupFlag and self:isInWhiteList(sender) then AcceptGroup() else StaticPopup_Show("PARTY_INVITE", sender) end endDone.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHowever, the idea about registering/unregistering sounds interesting.
Thus far I have pretty much relied on existing API documentation... I get the impression that the first place I should look is where? the Blizzard-generated addons?
Jerry,
First of all, thanks for the example fix.
I have a question though, if I unregister event, is that only local to my app or am I changing the way it works for all other addons? My assumption is it's only local, but I really want to be sure I understand what I'm doing.
You would be unregistering the "PARTY_INVITE_REQUEST" from UIParent. Which means that the frame UIParent would not receive notification when the "PARTY_INVITE_REQUEST" event fires, and thus the piece of code in FrameXML/UIParent.lua will not be run.
The effect is that UIParent stops showing a Dialog when the "PARTY_INVITE_REQUEST" is fired, so your code can determine wether or not it's relevant to show the dialog, and do so itself.
It's a global change in the sense that there is only one UIParent frame that is initialized by Blizzard. But any addon that which to listen to "PARTY_INVITE_REQUEST" can do so.
Here's the solution I'm using:
function Automaton_Group:ProcessInvite(accept) if accept then AcceptGroup() self:RegisterEvent("PARTY_MEMBERS_CHANGED") else DeclineGroup() end end function Automaton_Group:PARTY_MEMBERS_CHANGED() StaticPopup_Hide("PARTY_INVITE") self:UnregisterEvent("PARTY_MEMBERS_CHANGED") endThe only downside with this method might be that the window does actually get displayed for a second or two, depending how long it takes for your AcceptGroup() to go through. Personally, I prefer it this way, since it calls a little more attention to itself. I used to frequently not even notice I had joined a group.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFirst of all, thanks for updating wowwiki - I had updated that AcceptGroup() page earlier and once I worked out the issues here, I went back and started updating the example ... then realized you had beat me to it. I rolled back my edits and posted a comment in the talk page apologizing for the unintentional "edit war"
Second of all, I actually LIKE the idea that you would see the dialog for a little bit too... I mean, the reason I put the feature in my addon was so I could easily group my toons up together while multi boxing. I just needed something that would accept my request and get the dialog out of the way, not completely change the way wow works.
I'm going to test your solution and if it works nicely, I may just replace the current fix.
Still, my addon is working and updated, and I used Borlox's fix (with attribution) to help out another multiboxer addon (I say another, but really it's THE BIG multiboxer addon), Jamba because the author is away on holiday and can't fix and test his addon til he gets back in May.
I've said it before and Ill say it again, I love the developer community.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumBit of a sledgehammer there though, isn't it? Potentially introducing taint and interspersing code for every single popup seems a "heavier" solution than just adjusting the one addon that needs it.
Sure, although you obviously should have this kind of consideration any time you hook something so I don't see how this case is any better or worse than hooking anything else. I didn't say this was the best solution and it's not necessarily worse than, eg. blocking UIParents from receiving PARY_INVITE_REQUEST.
If you want to notify the user that he has entered a group, then you can do that.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumJust sets a flag for the specific popup and that's it.
Weab's idea of listening for the PARTY_MEMBERS_CHANGED event
and only hiding the popup (if it's there) after the party invite has gone through is also simple and minimal impact.
(a different but clunky implementation of the same idea:
"hide the popup once you're sure the group inv has actually been accepted"
was my OnUpdate + check for GetNumPartyMembers())
Weab's way is much better if you go that approach.
The rest are all valid solutions but at the moment it's academic exercise imho.
Do you find a problem with either? I don't, while I find all comments
about "messing with more than needed" or "relying on a specific event firing order", valid.
I think we can safely assume that PARTY_INVITE_REQUEST will always precede PARTY_MEMBERS_CHANGED
Just my 2c :)