Issue:

Due to the fact that not everyone declines applicants that are not desired for their dungeons you can be left on hold for the full 5 min duration of the application.

This combined with the 5 application limit of the dungeon finder means that trying to get in grps can lead to alot of manual canceling for applications that have left you on hold but not hard declined you.

Suggestion:

Implement a "opt-in" improvement to the SingleClickSignUp module that when trying to apply goes through the list of current live applications and cancels the oldest application that has been there for an arbitrary or configurable number of seconds/minutes.

I have been using a modified version of the SingleClickSignUp module that does this (in a very crude and hacky way since i have no knowledge of wow interface API) and it really helped alot when slogging through numerous applications to get in mythic plus groups which are plentifull and often leave you on hold instead of declining.

This might only make sense when paired with the SkipSignUpDialog config as well

Crude solution used attached in file

Thanks for sharing your improvement!

Not sure how many players are interested in this feature as clicking on cancel is not a big issue, but will think about adding it.

Could you please post the relevant code in here using triple backticks at start and end like this:

```lua
--code
```

Sorry for the open and close spam, keep pressing the wrong button

function RemoveOlderApplication()
    local apps = C_LFGList.GetApplications();
    local minCurrentDuration =  600;
    local applicationId = 0;
    for i=1, #apps do
        local id, status, pendingStatus, appDuration = C_LFGList.GetApplicationInfo(apps[i]);
		if ( status == "applied" and tonumber(appDuration) < minCurrentDuration) then
            minCurrentDuration = tonumber(appDuration)
            applicationId = id
		end
	end
    if(applicationId ~= 0 and minCurrentDuration < 240) then
        C_LFGList.CancelApplication(applicationId)
    end
end

hooksecurefunc("LFGListSearchEntry_OnClick", function (self, button)
    if not PremadeGroupsFilterSettings.oneClickSignUp then return end

	local numApplications = C_LFGList.GetNumApplications();
    local panel = LFGListFrame.SearchPanel
    if button ~= "RightButton" and LFGListSearchPanelUtil_CanSelectResult(self.resultID) then
        if panel.selectedResult ~= self.resultID then
            LFGListSearchPanel_SelectResult(panel, self.resultID)
        end

        if (numApplications >= 5) then
            RemoveOlderApplication()
        end

		if (numApplications < 5) then
			LFGListSearchPanel_SignUp(panel)
		end
    end
end)

@0xbs I currently implement a "double click" to apply that allows users to double click on listings. Upon doing so, if they have the "Save Note" setting enabled, then it will automatically apply to the listing that was double clicked using the last night that was entered.

@ChrisKader That's already the case with a single click. This topic is about cancelling the oldest application if you have the maximum of five pending applications reached.

Ahh, my apologies. I did not read the whole thing. I would think that maybe setting a threshold would be better. So, if I apply to a 6th group and I have an application that has, say, 3 or less minutes on it, then it would be cancelled.

Would be interesting as I expect you would need to create a secure button to use for pressing cancel as the oldest application could very well not currently be displayed. I may do this instead of how I currently do it: (un)applying to a group by simply calling the Click() function of the listing's buttons since it it's likely that the listing you double clicked will be visible. My implementation of double click apply will also cancel if the listing that is double clicked is a valid listing that's been applied to.

I am working on rewriting LFM+ anyway as there are a lot of things I could do better, and I would like to get rid of my dependency on a lot of the Ace libraries.

Oh maybe appduration is counting down instead of up? I will check that.

Regarding the visualization:

I prefer the 0.3 opacity one.

Alternative design would be cleaner, but to be honest, I wouldn't understand it. Also the tooltip is about the hovered group, so this information does not really belong in there and I wouldn't look at it anyway.

Ok np, do whatever you think will be best for the addon and easiest to understand ^^

Well, as this option is disabled by default, you could just add a detailed description to the tooltip in the options. :) So when someone enables it, they will know what it is and how it works. But if 0.3 will make the group info readable under it, I'd be fine with that - will have to see what it's like in reality.

Right clicking should not cancel signups imo, only left clicks

I like this idea, would love to see it being added to the addon so you could just spam signup for groups and the oldest signup gets replaced on the 6th signup etc (if it takes more than 1 minute you are probably not getting invited and people don't bother to decline most of the time to avoid angry whispers, or just laziness) and would save us a click so we don't have to do the cancelling ourselves 😛

Personally I think "Click to cancel oldest application" on hover would be better but only when left clicking so you can still use right click to access the options without cancelling if you want to whisper/report/see rio profile of another group.

Also would it be possible to make this feature a separate setting so you can still use this feature even if you don't use the single click option? so when you are max capped on signups you can still just left click the next group with 1 left click to cancel oldest application then double click to signup if you prefer that style #293

Sweet 👍

Can be tested soon in version 6.5.0-beta

Alright, I changed it so that it shows the message "Click to cancel oldest application first" on hover if you're at max applications. It's also a separate option so that you can use it independently from all other options.

So I tried to implement that and noticed that you cannot both cancel and apply with a single click. As both functions require a hardware event like a mouse click, canceling already "eats up" the first click event and you need a second click to apply to the new group. I tried to do it with a message like in the screenshot:

However I was wondering if it would be more intuitive to show a message "click to cancel oldest application" first (while hovering over groups), then show no message for signing up (because a new slot is available after that). This makes it more explicit that when you click now, your oldest application is canceled.

This is a cool feature!

I have some suggestions to improve:

1. Make the hovertip not cover the whole group (or move it slightly in any direction) because currently when it's displayed, it's impossible to see if I'm actually about to apply to the group I want (or if I was about to use one of the right-click features on a group, would that be the one I intended to use it on).
2. It would be even better if groups that have fallen out of the filter range could be cancelled first. E.g. my filter has partyfit and some group has filled my role in the meantime, so when using this feature, that group would be cancelled first instead of the oldest.
3. Try to not call the sort/refresh/whatever it's called function after clicking it first to cancel because it makes the list re-sort so clicking at the same spot will result in another group jumping there and applying to the wrong one.

@zeenk Would be great if you could do a test with the beta version and give some feedback if everything works as expected.

You can install the beta in CurseForge client by right clicking on the addon and choosing release type beta. Or just download from the release page or git clone out the code.

1. Yes sorry for unclear phrasing. I know it is possible to right-click on the group but I cannot see if I'm doing it on the one I intended to click on. :) It's okay if the tooltip is this big, just move it from the top of the group you're currently hovering over. Either a configurable anchor or up or down (because I think that's what would not make it go off screen for most people).
2. Great, thanks!
3. Yeah I figured that would be the case, very sad they do this forced jumping BS now. So then, would it be possible to mark that group somehow? For example, color it something like blue so after the canceling and forced jump, we'd find that group we wanted to apply to more easily.

Regarding your points:

1. Right click is always possible, even if the message is displayed. I could make it smaller, but some translations of the message might require more space than English. I will see if I can make it multiline and shrink it.
2. Would be more useful indeed, but requires some work. I will have a look.
3. I don't, I just update/enable the Sign Up Button. However canceling a group triggers an event, I assume Blizzard sorts the list on that event. I can't prevent that.

@zeenk Would be great if you could do a test with the beta version and give some feedback if everything works as expected.

You can install the beta in CurseForge client by right clicking on the addon and choosing release type beta. Or just download from the release page or git clone out the code.

Yea I was planning to do some m+ tonight, was playing Diablo last night so didn't fully test it yet, only did a brief test to see how it works, I'll try it later today to see how it feels and if I can find anything to improve with it ^^

I like this alternative design. It just occurred to me that the tooltip of its meaning could just be attached to the bottom of the regular tooltip, that way it wouldn't go off screen for anybody for sure.

I could make it half-height and stick it to the bottom (or top). But the click-area is still anywhere on the group, as I am using the click handler of the group itself (starts flickering otherwise). Could be misleading as players might think that clicking on the upper half will not cancel. But I could make it more translucent.

Coloring the group blue is likely not a problem, but removing the color is. When should the color be removed? Also feels a bit like stacking workaround on workaround. That jumping really sucks.

Click area remaining anywhere on the group is perfect, just make the tooltip not cover the group so the important parts of it would still be visible, so I'd stay the top if moving it above the group is not feasible. Transparent/translucent might work.

I would say remove the color when other colors are removed or when you apply to a different group, but for me it wouldn't be a problem if it stayed colored forever, as they relist anyway and my (and I guess everyone's) filter also contains an age<x too so they would disappear eventually.

Ok I did some more testing and it feels good and I agree with hollo6's points, if using filters (partyfit, members etc) that should take priority over oldest when canceling and for the hover part I think just lowering the background transparency could probably work so you can see the group info better, maybe 0.3 or 0.5 instead of 0.8
0.8

0.3

Alternative design, that just adds a x icon on the group, and text to the tooltip to show what it means?

Hmm, I just noticed that that it doesn't cancel the oldest one, only the latest applied to group
2 examples:

I fixed various things and released a new version 6.5.1-beta:

• Now cancels the oldest instead of the latest application
• No longer cancels on right click
• Fixed attempt to cancel already canceled groups
• Moved info text below the hovered group

This is how it looks now (German client):

You can't see it on the last group, but I think that's okay.

I also noticed that when you click to cancel, the group is automatically selected on my client. So even if the groups do jump around (never did for me), you can just click the selected group again.

Something is not right. Even if I only have 1 current application and click on another group, that 1 application will be cancelled and after that I have to click at least 3 times on the group to actually apply.

Yeah I get the bar without even signing up to anything first

Ah sorry I forgot to comment out my debug code. Fixed with 6.5.2-beta

Looks good, tested with the new beta and the only thing I think is missing now (if it's possible) is to cancel group that is not within your filters anymore first instead of always oldest application, if a group gets 3 dps and you have partyfit for example and queuing as dps

+1 wanted to comment the same thing :)

Sweet, will do a non-beta release then. I will have a look into the "cancel non matching group first" next and keep this open.