WowAce

AceGUI uses an internal pool to recycle frames. Which is great for performance reasons. I get that. :) But those frames are not properly reset to their initial state when you reaquire one with Create().

A simple Demo:

local AceGUI = LibStub("AceGUI-3.0")

local group1 = AceGUI:Create("SimpleGroup")
print(group1.frame:IsShown()) -- true :)

AceGUI:Release(group1)

local group2 = AceGUI:Create("SimpleGroup")
print(group2.frame:IsShown()) -- false :(

In this simple case Release() hides the frame and puts it back into the internal pool. The next Create() of that widget returns it again with a lot of it's previous states/settings, including the visibility. But it's not just that. This affects also framestrata, framelevel, attributes and so on. These are just examples a third party addon can change on its side and release it back into the pool. For the next addon, which gets that modified frame, it could lead to completely unexpected behavior.

At least I expected AceGUI to always provide a nice widget on every Create()-call. :)

Now knowing that it actually doesn't... well, I can surely adapt my addons to reset some settings myself. But that's not very userfriendly, isn't it? I mean I can't be the only one to stumble over this behaviour.

Addons are not "allowed" to change any properties of the frames outside of the exposed AceGUI Widget API.

If any of them accessed widget.frame directly to change something like level or strata, thats a violation of the AceGUI API, and they should not release it back into the pool. Its impossible to try to fight about what kind of properties an addon could possibly change, because that list is infinite once you start messing around with internals.

As for the show state, you can pretty much assume that any given widget is in an indetermined state when it comes to those properties. You should anchor and Show them after acquiring them. Or even better, use them in an Layout, thats what they are really designed for.

> Addons are not "allowed" to change any properties of the frames outside of the exposed AceGUI Widget API.

Aah, I see. There is indeed a Note in the wiki explaining that. That just doesn't keep people from doing it anyway. :-/
I still think that it's a nice feature, which would make the lib more robust against user mistakes.
Anyway, I'll show this to the responsible developer buddy. Thank you for clarifying it again. :)

> ... you can pretty much assume that any given widget is in an indetermined state ...

Well there is the problem: I simply assumed that it's always shown, like a normal call of CreateFrame() would do. Assuming does rarely help in development. For instance, the widgets Frame and Window are actually always shown during acquisition. One could also assume that all other widgets are always shown as well. This really feels completely inconsistent across all widgets.

In my humble opinion AceGUI should always show the widget frame during acquisition. The Lib already hides the frame during Release(). It could also just show it again with the next Create().

Also, you basically just told me not to directly temper with the frame and use the Widget API instead. Well, there are no methods yet to show/hide the frame of most widgets. ;-)