While I understand how it's used... I've never really understood the NEED for do blocks. I've never once felt that I needed to use one in my code.
Going out of your way to hide things from yourself sounds like overly defensive programming in my opinion... There is certainly a need to hide your own stuff from external code, but I find that do...end blocks just make things harder to read in the end. I would split an addon into multiple files *primarily* (not only) for readability, not to prevent myself from accessing certain parts of it depending on where I am.
I've noticed a problem with multi-line edit boxes in AceGUI. If the length of the edit box exceeds its displayed height, then its clickable area will also exceed its visible area.
This can be verified by placing a multi-line edit box in your options menu, and giving it a description. Now enter enough text into the edit box to make it scroll down several lines (easy by just holding the return key for a few seconds). Now place your cursor above the edit box, and a tooltip will appear with the name and description of your edit box, even though you are not hovering directly over the visible portion of the edit box. If you scroll back up to the top, then it is now the bottom portion of your edit box which is clickable beyond its visible area.
This can prove problematic if you have options buttons such as checkboxes above or below your multi-line edit box, as clicking those will actually result in a click on the invisible portion of your edit box.
It only does anything if send == 1. I don't see how a single if statement returning false whenever a key is pressed is any more inefficient than having to check possibly thousands of messages being sent by addons only to not do anything with them.
The term "inefficient" gets used a lot, with a seemingly broad range of meanings. In this specific case, there likely won't be any performance impact since you're doing a simple integer comparison. However it is still more inefficient than the other solution brought forth here since your code gets executed a heck of a lot more this way.
Er I should have mentioned that I tried with my whole addon folder removed too. People in my guild report the same issue. Is this not happening to other people?
I did dailies last night and everything was being tracked properly on pickup. I'll try to remember to check my settings tonight.
This is a very good thread and an important topic. Being a software engineer and a novelist, I don't think you can raise community awareness to copyright enough.
Frames don't get GC'ed, even if all references are nil'ed and they go out of scope.
Edit: You can still access them with EnumerateFrames(), so I guess they never go out of scope.
WoW keeps a reference to all frames, which is why they don't get reclaimed. So in effect the statement that frames never get reclaimed, "even if all references are nil'ed and they go out of scope" is not true. It's just that you can't remove all references to frames.
I've known of plenty of addons which, over the course of WoW, dropped the ! in front of their names because it wasn't having the intended effect on Windows (although I think it did under Linux + Wine or something). Addtionally, I'll refer you to Tekkub's article:
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.
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.
0
Wouldn't it rather be more simply:
? A do block isn't defining a function, unless I missed something.
0
Not to nitpick, but those characters are extended-ASCII.
0
Going out of your way to hide things from yourself sounds like overly defensive programming in my opinion... There is certainly a need to hide your own stuff from external code, but I find that do...end blocks just make things harder to read in the end. I would split an addon into multiple files *primarily* (not only) for readability, not to prevent myself from accessing certain parts of it depending on where I am.
0
Just make sure your code behaves :p
0
I've noticed a problem with multi-line edit boxes in AceGUI. If the length of the edit box exceeds its displayed height, then its clickable area will also exceed its visible area.
This can be verified by placing a multi-line edit box in your options menu, and giving it a description. Now enter enough text into the edit box to make it scroll down several lines (easy by just holding the return key for a few seconds). Now place your cursor above the edit box, and a tooltip will appear with the name and description of your edit box, even though you are not hovering directly over the visible portion of the edit box. If you scroll back up to the top, then it is now the bottom portion of your edit box which is clickable beyond its visible area.
This can prove problematic if you have options buttons such as checkboxes above or below your multi-line edit box, as clicking those will actually result in a click on the invisible portion of your edit box.
Has anyone else experienced this?
0
The term "inefficient" gets used a lot, with a seemingly broad range of meanings. In this specific case, there likely won't be any performance impact since you're doing a simple integer comparison. However it is still more inefficient than the other solution brought forth here since your code gets executed a heck of a lot more this way.
0
I did dailies last night and everything was being tracked properly on pickup. I'll try to remember to check my settings tonight.
0
Those are for incoming messages.
0
0
WoW keeps a reference to all frames, which is why they don't get reclaimed. So in effect the statement that frames never get reclaimed, "even if all references are nil'ed and they go out of scope" is not true. It's just that you can't remove all references to frames.
0
http://www.wowwiki.com/Warmup#Option_1.2C_Windows_users
It might be outdated, which is why I was wondering if the behavior had changed. I haven't verified it either way.
0
Last I checked, WoW loads addons in order of (folder) creation date on Windows, not alphabetically. Has this changed?
0
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.
0
0