so, for another addon of mine, i decided to use the ace3GUI framework.
i am able to create a main frame (unable to acces the option to disable resize?), adding tabs and a treeview, all goes well...
then, i want to create more frames (using inlinegroup & simplegroup) which measurements are variable.. using this layout:
[ TOP ]
[ BOTTOM]
where the bottomframe contains:
[LEFT][RIGHT]
when i resize the main frame, the [RIGHT] frame occasionally floats away, and will be snapped into place after i resize the mainframe for a second time. (not when i move it)
the main issue i now have is when i add a scrollframe to the [LEFT] frame: the [RIGHT] frame's measurements are just fckd up with that
when i add the following frame into the [LEFT] container, the right container's measurements are just...
-- Scroll container
LMMainFrame_Loot_List = Ace3GUI:Create("ScrollFrame");
LMMainFrame_Loot_List:SetLayout("Flow");
LMMainFrame_Loot_List:SetFullHeight(true);
LMMainFrame_Loot_List:SetWidth(80);
LMMainFrame_Loot_BottomLeftCntr:AddChild(LMMainFrame_Loot_List);
local _, _, _, _, _, _, _, _, _, itemTexture = GetItemInfo(71354);
for i = 1, 5 do
myILabel = Ace3GUI:Create("InteractiveLabel");
--myILabel:SetText("20");
myILabel:SetWidth(48);
myILabel:SetHeight(48);
myILabel:SetImage(itemTexture);
myILabel:SetImageSize(48,48);
LMMainFrame_Loot_List:AddChild(myILabel);
end
The above code is called upon (and the var container is parsed, ofc) when i selected the correct tab to show these frames
does anyone see what i do wrong? or is the ace3gui just messing things up? if so, i think i'll go back to create my own frames
i hope i provided enough information, if not, let me know :)
thanks in advance,
Prop
Edit:
After a reloadui, the initial view of the rightframe is correct, tho after a resize, it is completely distort again, floats outside of the mainframe on occasion also
i am able to create a main frame (unable to acces the option to disable resize?),
See Ace3 ticket 80 and ticket 214. There isn't such an option until one of the maintainers makes a decision about that patch; if you really want to disable resizing, it's trivial to make a custom container using a copy of the Frame or Window code as a starting point, then make changes as needed.
And while AceGUI isn't really intended for direct use (it was mostly meant as a glue between AceConfig and the UI widgets), it is entirely doable as long as you have a certain discipline and plenty of caffeine. I would recommend a different GUI wrapper toolkit, except there aren't any. IMHO it's still less annoying than futzing around with the Blizzard frame methods. If you're getting lost in the chain of resizing/refreshing calls, you may find it useful to add print() calls to the guts of one copy of AceGUI-3.0.lua, and bump its revision number to something ridonkulously large to ensure it's the copy being used.
I still think it was poorly-named, since at least once a month a novice AddOn author posts asking how to do things with it; the library is more suited for config options (and only if you're well-versed in its inner workings or know black magic) than a generic GUI.
I can indeed hope that this patch will be approved (or a solution is found for the preventing of floating sub-frames upon resizing) soon(tm).
For now, i have poored myself a big mug of coffee, and gonna take a look in the resize calls to make sure sub-frames are resized/repositioned correct. If all else fails, i will make a mainframe container using Blizzard's frame, and try to fill that with the ace3 framework - either way enough to do for me
well, i am messing with the usage of create(window) instead of create(frame) to use its setting to disable resizing, but this results in the no-show of the very frame that was floating away on the usage of create(frame), so i reckon that i indeed should dive deeper into the resize chain and see where exactly things go wrong...
not giving up on the framework just yet ^^
Cheers,
prop
edit: using fixxed widths for the frames in the [BOTTOM] frame, and the issue is solved, using Relative width just doesnt seem to result in correct dimensions?
i am able to create a main frame (unable to acces the option to disable resize?), adding tabs and a treeview, all goes well...
then, i want to create more frames (using inlinegroup & simplegroup) which measurements are variable.. using this layout:
[ TOP ]
[ BOTTOM]
where the bottomframe contains:
[LEFT][RIGHT]
when i resize the main frame, the [RIGHT] frame occasionally floats away, and will be snapped into place after i resize the mainframe for a second time. (not when i move it)
the main issue i now have is when i add a scrollframe to the [LEFT] frame: the [RIGHT] frame's measurements are just fckd up with that
code i use for the mainframe of the selected tab:
when i add the following frame into the [LEFT] container, the right container's measurements are just...
The above code is called upon (and the var container is parsed, ofc) when i selected the correct tab to show these frames
does anyone see what i do wrong? or is the ace3gui just messing things up? if so, i think i'll go back to create my own frames
i hope i provided enough information, if not, let me know :)
thanks in advance,
Prop
Edit:
After a reloadui, the initial view of the rightframe is correct, tho after a resize, it is completely distort again, floats outside of the mainframe on occasion also
See Ace3 ticket 80 and ticket 214. There isn't such an option until one of the maintainers makes a decision about that patch; if you really want to disable resizing, it's trivial to make a custom container using a copy of the Frame or Window code as a starting point, then make changes as needed.
And while AceGUI isn't really intended for direct use (it was mostly meant as a glue between AceConfig and the UI widgets), it is entirely doable as long as you have a certain discipline and plenty of caffeine. I would recommend a different GUI wrapper toolkit, except there aren't any. IMHO it's still less annoying than futzing around with the Blizzard frame methods. If you're getting lost in the chain of resizing/refreshing calls, you may find it useful to add print() calls to the guts of one copy of AceGUI-3.0.lua, and bump its revision number to something ridonkulously large to ensure it's the copy being used.
Strongly disagreed. The Blizzard frame/widget API is straightforward and extensively documented; the AceGUI API is neither of those things. :p
I can indeed hope that this patch will be approved (or a solution is found for the preventing of floating sub-frames upon resizing) soon(tm).
For now, i have poored myself a big mug of coffee, and gonna take a look in the resize calls to make sure sub-frames are resized/repositioned correct. If all else fails, i will make a mainframe container using Blizzard's frame, and try to fill that with the ace3 framework - either way enough to do for me
Thanks for all your answers,
Prop.
PS: back to the kitchen; mug is empty >.<
not giving up on the framework just yet ^^
Cheers,
prop
edit: using fixxed widths for the frames in the [BOTTOM] frame, and the issue is solved, using Relative width just doesnt seem to result in correct dimensions?