This is the only reference in the code to this function left. That's calling the default UI function. Maybe you are running some other mod hooking that function or something?
This was a buglet in the GMail.xml. Before it had GMail:SendMailFrame_SendeeAutocomplete() in that line and it no longer worked since I removed the function hook.
This is the only reference in the code to this function left. That's calling the default UI function. Maybe you are running some other mod hooking that function or something?
I searched every file under Interface\Addons, and GMail.xml is the only file where "SendMailFrame_SendeeAutocomplete" is found, so I guess that no other addon is hooking the function.
edit:
just opened GMail.xml... and the line there still says
I removed the GMail: and now the error is gone, and the autocompletion works ... but I swear, I "thought" I did a svn update this morning before I tested if the error really is in the latest svn - something went wrong I guess ;-)
I am trying to re-write the "Open All" functionality to be more tolerant of the fact the mail system is error prone and also because I think the CT_MailMod method is retardedly complex.
Here is what I am looking at doing:
function:GMail:InboxOpenAll()
GMail:Inbox_DisableClicks(1)
GMailInboxFrame.id = { }
while GetInboxNumItems >= 1 do
self:TakeMoney(1)
self:TakeItem(1, 1)
DeleteMail(1)
end
GMail_SelectedItems = { }
end
function GMail:DeleteMail(index, overrideTextOnly)
local _, _, _, _, money, COD, _, hasItem = GetInboxHeaderInfo(index)
local bodyText, _, isTakeable = GetInboxText(index)
if money > 0 or COD > 0 or hasItem or isTakeable or (bodyText and not overrideTextOnly) then return end
DeleteInboxItem(index)
return true
end
function GMail:TakeItem(index, confirmCOD)
local _, _, _, _, _, COD, _, hasItem = GetInboxHeaderInfo(index)
if not hasItem or (COD > 0 and not confirmCOD) then return end
TakeInboxItem(index)
return true
end
function GMail:TakeMoney(index)
local _, _, _, _, money = GetInboxHeaderInfo(index)
if money == 0 then return end
TakeInboxMoney(index)
return true
end
The Take* and DeleteMail function are from ExpressMail by Tekkub.
Honestly, I can't even figure out how Open All works currently in ct_mailmod. Its either of such brilliance that I can't comprehend it or so nasty its not worth learning.
--Sending a single mail from the Mass Mail panel doesn't work. Click Send, then again in the verification box, nothing happens. Tried it 6 times including relogging; it wasn't lag. As soon as I added another item to the Bulk Mail box and retried Send, things were sent.
--As with CT_MailMod, this isn't compatible with the MailTo mod. Send things via Bulk Mail, they are not recorded by MailTo. Which is the main issue preventing me from continuing to use this/BulkMail/CT_MailMod.
--As with CT_MailMod, this isn't compatible with the MailTo mod. Send things via Bulk Mail, they are not recorded by MailTo. Which is the main issue preventing me from continuing to use this/BulkMail/CT_MailMod.
Workaround:
Have 1 billion things to mail. Mail one thing manually. Mail 999,999,999 via bulk/grennon/ctmail.
More sensible this than mailing all billion things manually.
Real solution:
Kidnap Grennon's teddy bear. Ransom it for Mailto features included in grennon mail.
--As with CT_MailMod, this isn't compatible with the MailTo mod. Send things via Bulk Mail, they are not recorded by MailTo. Which is the main issue preventing me from continuing to use this/BulkMail/CT_MailMod.
Real solution:
Kidnap Grennon's teddy bear. Ransom it for Mailto features included in grennon mail.
CT_Mailmod had savedvariables for 1 lousy variable that isnt that useful. Right now GMail has zero so I didn't even use AceDB. I'd like to keep it that way. If anyone has any recommendations on supporting MailTo I will gladly review their code.
--Sending a single mail from the Mass Mail panel doesn't work. Click Send, then again in the verification box, nothing happens. Tried it 6 times including relogging; it wasn't lag. As soon as I added another item to the Bulk Mail box and retried Send, things were sent.
I just tested and it worked for me. It could be the variables for the bulk mail weren't cleared or something. Next time it happens, try closing the mail window and re-opening so I can be sure.
--As with CT_MailMod, this isn't compatible with the MailTo mod. Send things via Bulk Mail, they are not recorded by MailTo. Which is the main issue preventing me from continuing to use this/BulkMail/CT_MailMod.
Whose fault is it? MailTo or the other mods?
Don't know. MailTo doesn't record anything sent via Gmail or CT_MailMod's Bulk Mail windows, only via the regular Blizzard mail window when those mods are active. With BulkMail (I expanded upon in the thread for it), MailTo records multiple entires for every single item sent (which reduces the utility of it substantially), whether you use the default Blizzard Windows or BulkMail's. Note that Gmail, BulkMail & CT_MailMod all work completely fine with MailTo active; it is MailTo's log captures that are the problem.
His responses to my (and many other people's) inquiries about this from months ago to now on Worldofwar.net: "It sounds like BulkMail is hooking the Send Mail function and not handling it properly. I suspect there is some kind of send-retry logic that is causing multiple calls to MailTo. This would need to be fixed by the BulkMail author." As to what the issue is with CT_MailMod (& Gmail), nothing other than...he is uninterested in doing anything about it, even if it is a problem on his end: "I don't plan on supporting mail logging of items send with CT_MailMod" (from the readme), among others.
So yes, if you implement MailTo features into Gmail, that's one more non-Ace mod we can abandon. The link to the current version is above. As to features of it that I (personally) find more necessary than bulk mailing or opening:
--"To:" options, where, instead of autocomplete, you can add a name to a drop-down list and easily pull them off the list without having to type anything and/or remember the name.
--in-game (slash command) access of logs for when items will be arriving at a destination after sending.
--in-game access of logs that show you when items will soon be expiring in one of your character's inboxes.
Less important:
--viwing a GUI "Inbox" that quickly shows and/or searched the contents of your inboxes of any character. As well as bank & personal inventory if you also use the Characters Viewer mod. Not that important if you use a superior inventory mod like Possessions.
His responses to my (and many other people's) inquiries about this from months ago to now on Worldofwar.net: "It sounds like BulkMail is hooking the Send Mail function and not handling it properly. I suspect there is some kind of send-retry logic that is causing multiple calls to MailTo. This would need to be fixed by the BulkMail author." As to what the issue is with CT_MailMod (& Gmail), nothing other than...he is uninterested in doing anything about it, even if it is a problem on his end: "I don't plan on supporting mail logging of items send with CT_MailMod" (from the readme), among others.
Run your own fork of BulkMail.
if GetSendMailItem() or self.sendCache and next(self.sendCache) then
metro:Start("BMSend")
else
Change to:
if GetSendMailItem() or self.sendCache and next(self.sendCache) then
self:Send()
else
Or something like that. I've been reading BulkMail tonight to see how he handles things. My guess is your dupe log entries are due to the fact that some in-game systems just throw away transactions they don't like.
Ever used the guild management interface? Half the time it wont even promote people. Mail isn't quite as bad but yes isn't 100 percent reliable.
You either need to give up mail resending or mail logging or just deal with the messages.
IMO It would sound like MailTo just needs an ace'd replacement (designed to be compatible *with* BulkMail / GMail).
No reason to go clammoring for features that can easily be implimented in a seperate mod. (The reason why BulkMail dosen't take care of looting mail, thats ExpressMail's job.) Keep things simple and seperate. :)
IMO It would sound like MailTo just needs an ace'd replacement (designed to be compatible *with* BulkMail / GMail).
No reason to go clammoring for features that can easily be implimented in a seperate mod. (The reason why BulkMail dosen't take care of looting mail, thats ExpressMail's job.) Keep things simple and seperate. :)
ExpressMail is nice and very small. Ill probably add that functionality to GMail once I get done with the code enema.
IMO It would sound like MailTo just needs an ace'd replacement (designed to be compatible *with* BulkMail / GMail).
No reason to go clammoring for features that can easily be implimented in a seperate mod. (The reason why BulkMail dosen't take care of looting mail, thats ExpressMail's job.) Keep things simple and seperate. :)
Something I've often been clamoring for with many different Ace mods here :). Sleek, slim, simple, separate, s, s... For sure, if MailTo could be Aced (Ace2) separately while changed to become compatible BulkMail/Gmail, that would be great.
Seeing as that BulkMail & Express mail already handle opening & sending--and Grennon asked for implementation suggestions--just offered up some. For sure, though, having MailTo features implemented in a separate mod would preferable for you, I and others.
Then again, a wider audience is usually found for mods like this (unit frames, bar mods, casting helpers, mail mods, etc.) if you implement (a bloated pile of) features. For most people, the less hassle/different things to deal with, the better.
--------------
Quote from grennon »
Run your own fork of BulkMail.
if GetSendMailItem() or self.sendCache and next(self.sendCache) then
metro:Start("BMSend")
else
Change to:
if GetSendMailItem() or self.sendCache and next(self.sendCache) then
self:Send()
else
Or something like that. I've been reading BulkMail tonight to see how he handles things. My guess is your dupe log entries are due to the fact that some in-game systems just throw away transactions they don't like.
The code change to Bulkmail suggested above doesn't work, Grennon. Add multiple items to the list, press "Send" and the first item on the list heads to the default mail window...and is not sent. Doesn't matter how many items you put in the BulkMail window--1 or 20. Reverse the code changes, it works again.
In testing Gmail to verify the previously reported problem, ran into an issue of "Gmail: cannot attach item" with revision 5618 (had updated before logging on tonight). In the last little while, though, you updated to revision 5723 ("Gmail: Unmailable Item Check Fix"), which fixed the problem.
As to the previously reported problem with the current revision, its still present, but in a slightly different form. A single item can be sent from the Bulk Mail window without a problem...the first time. Try to send a single second item after the first (without closing the mailbox first), the item turns gray and is not sent. Close the mailbox & open it again, try the single item again (the same one tried before that didn't go through or a different one), it works. Then try another single item right after that first one...nope. This behavior is consistently reproducible here through relogging.
As well, MailTo still does not record anything for items sent from the Bulk Mail window.
Quote from grennon »
You either need to give up mail resending or mail logging or just deal with the messages.
Obviously...until the problem is fixed. I've given up bulk mailing and dealing with the multiple messages (other than the above testing). MailTo's uncorrupted logging is more important here.
A single item can be sent from the Bulk Mail window without a problem...the first time. Try to send a single second item after the first (without closing the mailbox first), the item turns gray and is not sent. Close the mailbox & open it again, try the single item again (the same one tried before that didn't go through or a different one), it works. Then try another single item right after that first one...nope.
Sounds like some variables aren't getting reset. Ill take a look-see.
But if I dont close the mailbox and try and send another multimail then it refuses to send.. nothing happens... if I close the window and reopen it works another try.
But if I dont close the mailbox and try and send another multimail then it refuses to send.. nothing happens... if I close the window and reopen it works another try.
Yeah, Im kinda busy with work this week and plan on fixing it up a bit more. Its still not release quality. I assume some variable isnt getting reset and it shouldnt be too bad to fix.
Anyone help me? I keep screwing up hooking the following:
local oldSMMFfunc = SendMailMoneyFrame.onvalueChangedFunc
SendMailMoneyFrame.onvalueChangedFunc = function()
if ( oldSMMFfunc ) then
oldSMMFfunc()
end
local subject = SendMailSubjectEditBox:GetText()
if ( subject == "" or string.find(subject, "%[%d+G, %d+S, %d+C%]") ) then
local copper, silver, gold = SendMailMoneyFrameCopper:GetText(), SendMailMoneyFrameSilver:GetText(), SendMailMoneyFrameGold:GetText()
if ( not tonumber(copper) ) then
copper = 0
end
if ( not tonumber(silver) ) then
silver = 0
end
if ( not tonumber(gold) ) then
gold = 0
end
SendMailSubjectEditBox:SetText(format("[%sG, %sS, %sC]", gold, silver, copper))
end
end
Im sure its something simple, but everytime I trying converting that to AceHook I mess up.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
This is the only reference in the code to this function left. That's calling the default UI function. Maybe you are running some other mod hooking that function or something?
This was a buglet in the GMail.xml. Before it had GMail:SendMailFrame_SendeeAutocomplete() in that line and it no longer worked since I removed the function hook.
I searched every file under Interface\Addons, and GMail.xml is the only file where "SendMailFrame_SendeeAutocomplete" is found, so I guess that no other addon is hooking the function.
edit:
just opened GMail.xml... and the line there still says
I removed the GMail: and now the error is gone, and the autocompletion works ... but I swear, I "thought" I did a svn update this morning before I tested if the error really is in the latest svn - something went wrong I guess ;-)
Here is what I am looking at doing:
function:GMail:InboxOpenAll()
GMail:Inbox_DisableClicks(1)
GMailInboxFrame.id = { }
while GetInboxNumItems >= 1 do
self:TakeMoney(1)
self:TakeItem(1, 1)
DeleteMail(1)
end
GMail_SelectedItems = { }
end
function GMail:DeleteMail(index, overrideTextOnly)
local _, _, _, _, money, COD, _, hasItem = GetInboxHeaderInfo(index)
local bodyText, _, isTakeable = GetInboxText(index)
if money > 0 or COD > 0 or hasItem or isTakeable or (bodyText and not overrideTextOnly) then return end
DeleteInboxItem(index)
return true
end
function GMail:TakeItem(index, confirmCOD)
local _, _, _, _, _, COD, _, hasItem = GetInboxHeaderInfo(index)
if not hasItem or (COD > 0 and not confirmCOD) then return end
TakeInboxItem(index)
return true
end
function GMail:TakeMoney(index)
local _, _, _, _, money = GetInboxHeaderInfo(index)
if money == 0 then return end
TakeInboxMoney(index)
return true
end
The Take* and DeleteMail function are from ExpressMail by Tekkub.
Honestly, I can't even figure out how Open All works currently in ct_mailmod. Its either of such brilliance that I can't comprehend it or so nasty its not worth learning.
--Sending a single mail from the Mass Mail panel doesn't work. Click Send, then again in the verification box, nothing happens. Tried it 6 times including relogging; it wasn't lag. As soon as I added another item to the Bulk Mail box and retried Send, things were sent.
--As with CT_MailMod, this isn't compatible with the MailTo mod. Send things via Bulk Mail, they are not recorded by MailTo. Which is the main issue preventing me from continuing to use this/BulkMail/CT_MailMod.
Workaround:
Have 1 billion things to mail. Mail one thing manually. Mail 999,999,999 via bulk/grennon/ctmail.
More sensible this than mailing all billion things manually.
Real solution:
Kidnap Grennon's teddy bear. Ransom it for Mailto features included in grennon mail.
Whose fault is it? MailTo or the other mods?
CT_Mailmod had savedvariables for 1 lousy variable that isnt that useful. Right now GMail has zero so I didn't even use AceDB. I'd like to keep it that way. If anyone has any recommendations on supporting MailTo I will gladly review their code.
I just tested and it worked for me. It could be the variables for the bulk mail weren't cleared or something. Next time it happens, try closing the mail window and re-opening so I can be sure.
Don't know. MailTo doesn't record anything sent via Gmail or CT_MailMod's Bulk Mail windows, only via the regular Blizzard mail window when those mods are active. With BulkMail (I expanded upon in the thread for it), MailTo records multiple entires for every single item sent (which reduces the utility of it substantially), whether you use the default Blizzard Windows or BulkMail's. Note that Gmail, BulkMail & CT_MailMod all work completely fine with MailTo active; it is MailTo's log captures that are the problem.
His responses to my (and many other people's) inquiries about this from months ago to now on Worldofwar.net: "It sounds like BulkMail is hooking the Send Mail function and not handling it properly. I suspect there is some kind of send-retry logic that is causing multiple calls to MailTo. This would need to be fixed by the BulkMail author." As to what the issue is with CT_MailMod (& Gmail), nothing other than...he is uninterested in doing anything about it, even if it is a problem on his end: "I don't plan on supporting mail logging of items send with CT_MailMod" (from the readme), among others.
So yes, if you implement MailTo features into Gmail, that's one more non-Ace mod we can abandon. The link to the current version is above. As to features of it that I (personally) find more necessary than bulk mailing or opening:
--"To:" options, where, instead of autocomplete, you can add a name to a drop-down list and easily pull them off the list without having to type anything and/or remember the name.
--in-game (slash command) access of logs for when items will be arriving at a destination after sending.
--in-game access of logs that show you when items will soon be expiring in one of your character's inboxes.
Less important:
--viwing a GUI "Inbox" that quickly shows and/or searched the contents of your inboxes of any character. As well as bank & personal inventory if you also use the Characters Viewer mod. Not that important if you use a superior inventory mod like Possessions.
Run your own fork of BulkMail.
if GetSendMailItem() or self.sendCache and next(self.sendCache) then
metro:Start("BMSend")
else
Change to:
if GetSendMailItem() or self.sendCache and next(self.sendCache) then
self:Send()
else
Or something like that. I've been reading BulkMail tonight to see how he handles things. My guess is your dupe log entries are due to the fact that some in-game systems just throw away transactions they don't like.
Ever used the guild management interface? Half the time it wont even promote people. Mail isn't quite as bad but yes isn't 100 percent reliable.
You either need to give up mail resending or mail logging or just deal with the messages.
No reason to go clammoring for features that can easily be implimented in a seperate mod. (The reason why BulkMail dosen't take care of looting mail, thats ExpressMail's job.) Keep things simple and seperate. :)
ExpressMail is nice and very small. Ill probably add that functionality to GMail once I get done with the code enema.
Quite the visual... thank you so much for that laugh.. I needed that today.
Something I've often been clamoring for with many different Ace mods here :). Sleek, slim, simple, separate, s, s... For sure, if MailTo could be Aced (Ace2) separately while changed to become compatible BulkMail/Gmail, that would be great.
Seeing as that BulkMail & Express mail already handle opening & sending--and Grennon asked for implementation suggestions--just offered up some. For sure, though, having MailTo features implemented in a separate mod would preferable for you, I and others.
Then again, a wider audience is usually found for mods like this (unit frames, bar mods, casting helpers, mail mods, etc.) if you implement (a bloated pile of) features. For most people, the less hassle/different things to deal with, the better.
--------------
The code change to Bulkmail suggested above doesn't work, Grennon. Add multiple items to the list, press "Send" and the first item on the list heads to the default mail window...and is not sent. Doesn't matter how many items you put in the BulkMail window--1 or 20. Reverse the code changes, it works again.
In testing Gmail to verify the previously reported problem, ran into an issue of "Gmail: cannot attach item" with revision 5618 (had updated before logging on tonight). In the last little while, though, you updated to revision 5723 ("Gmail: Unmailable Item Check Fix"), which fixed the problem.
As to the previously reported problem with the current revision, its still present, but in a slightly different form. A single item can be sent from the Bulk Mail window without a problem...the first time. Try to send a single second item after the first (without closing the mailbox first), the item turns gray and is not sent. Close the mailbox & open it again, try the single item again (the same one tried before that didn't go through or a different one), it works. Then try another single item right after that first one...nope. This behavior is consistently reproducible here through relogging.
As well, MailTo still does not record anything for items sent from the Bulk Mail window.
Obviously...until the problem is fixed. I've given up bulk mailing and dealing with the multiple messages (other than the above testing). MailTo's uncorrupted logging is more important here.
Sounds like some variables aren't getting reset. Ill take a look-see.
Then I use the mass feature once it is nice..
But if I dont close the mailbox and try and send another multimail then it refuses to send.. nothing happens... if I close the window and reopen it works another try.
Yeah, Im kinda busy with work this week and plan on fixing it up a bit more. Its still not release quality. I assume some variable isnt getting reset and it shouldnt be too bad to fix.
local oldSMMFfunc = SendMailMoneyFrame.onvalueChangedFunc
SendMailMoneyFrame.onvalueChangedFunc = function()
if ( oldSMMFfunc ) then
oldSMMFfunc()
end
local subject = SendMailSubjectEditBox:GetText()
if ( subject == "" or string.find(subject, "%[%d+G, %d+S, %d+C%]") ) then
local copper, silver, gold = SendMailMoneyFrameCopper:GetText(), SendMailMoneyFrameSilver:GetText(), SendMailMoneyFrameGold:GetText()
if ( not tonumber(copper) ) then
copper = 0
end
if ( not tonumber(silver) ) then
silver = 0
end
if ( not tonumber(gold) ) then
gold = 0
end
SendMailSubjectEditBox:SetText(format("[%sG, %sS, %sC]", gold, silver, copper))
end
end
Im sure its something simple, but everytime I trying converting that to AceHook I mess up.