Authors CurseForge

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 put an OnUpdate in my code and check at 0.2 intervals for GetNumPartyMembers()>0 before hiding the static popup.

I only SetScript the OnUpdate in the PARTY_INVITE_REQUEST event
and nil it after hiding the popup.

Thank you both for the suggestions.

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.

Borlox workaround is more elegant.

while it might be a bit hacky, why not just use the static popu's own scripts?

You loop though it to find the dialoug, why not just call the accept buttons :Click() script?

Quote from DigitalSorceress

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.

Why not simply:

UIParent:UnregisterEvent"PARTY_INVITE_REQUEST"

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
end

Done.

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.

Quote from DigitalSorceress

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.

Weab,

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.

Quote from Valana_TB

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.

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 :)