Authors CurseForge

Quote from sylvanaar

The do block is the equivalent of the following C code:

void myFunc() 
{
static int a = 1;
 
... do stuff
}

Wouldn't it rather be more simply:

{
    stuff in an isolated scope
}

? A do block isn't defining a function, unless I missed something.

Quote from Graveeater

You mean, that one has a NON ascii char in its name? Like Gändálf?

Before we can help you, it would be great to explain in more detail (read: post code) how you compare.

Not to nitpick, but those characters are extended-ASCII.

Quote from Tekkub

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.

Quote from Bitwise

Actually, this is what I already had. It just seems to me that running code for a timer say, 60 times a second is overkill.

Thanks anyway.

Just make sure your code behaves :p

Hello,

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?

Quote from WanderingFox

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.

Quote from arnath2

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.

Quote from arnath2

Arguably the chat event filters are simpler :p

Those are for incoming messages.

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.

Quote from egingell

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:

http://www.wowwiki.com/Warmup#Option_1.2C_Windows_users

Option 1, Windows users

Windows loads addons in the order their folders were created on the disk, oldest first. The simplet trick to make warmup's folder the oldest is:

1. Move all you addons out of the addons folder to a temporary folder
2. Move !!Warmup back to the addons folder
3. Move everything else back

It might be outdated, which is why I was wondering if the behavior had changed. I haven't verified it either way.

Quote from Xinhuan

Or change your addon name to have ! in front, like !MyAddon (NTFS harddisks return folder names in alphabetical order, most users run Windows).

Last I checked, WoW loads addons in order of (folder) creation date on Windows, not alphabetically. Has this changed?

Quote from Farmbuyer

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.

Interesting. Thanks!