sorry i didnt post earlier. I never got any of it working. the fact that you guys are having problmes also getting it to work makes me think that i should stop beating my head against a brick wall and just stop messign with acegui until I learn alot more and it ages a little more. its clearly designed for standalone windows and stuff and i shouldn't be trying to force it to do stuff its not meant to be doing. Im going to try and learn from my mistakes :-)
thank you guys for all ur advice!
- Registered User
Member for 10 years, 3 months, and 15 days
Last active Fri, Oct, 4 2013 14:35:15
- 0 Followers
- 7 Total Posts
- 0 Thanks
Aug 27, 2009Posted in: Ace3Quote from OrionShock[FONT=monospace]AceConfig:Open(options.name, aceConfigGroup)
Ya that dosn't work. You need to pass the name of the app. [/FONT]You need to pass the appName that was passed in RegisterOptionsTable call. The first lvl .name field is quite irrelavant to everything.
I use options.name for RegisterOptionsTable also. Everywhere that acegui/aceconfig needs an 'appname' field, I feed it options.name and it works. Ace doesn't "know" that it's using options.name, but it makes it easier for me to reuse data.
Like I said the title of the interface options is being set correctly, and :Open would give errors if it couldn't look up the options table by appname (around line 1720). Its just that everything being placed inside the containers vanishes. I get a panel with a title and nothing else.
Aug 27, 2009Posted in: Ace3Quote from odfgtu:Open sets width and height of the container being passed in (aceconfiggroup) so I dont think its turning out to be 0x0 or something else that would cause it not to be drawn.
that might actually be a lie. the :Open code doesn't call :SetWidth or :SetHeight, only sets .width and .height fields in something called a status table. Status table isnt documented anywhere so I dont know if that has an effect or not.
but its same code as before so either way nothing should have changed. arggg
Aug 27, 2009ow my head.Posted in: Ace3
I think I understand what that code is doing, but now its actually worse than before. Ive started with trying to only display the options from the basic aceconfig options table, ie doing the same thing as :addtoblizoptions() but by hand. That was working before so I figured it was a good place to start.
My OnInitialize calls :RegisterOptionsTable (lets say my options table is 'options'). Then my OnEnable does only
local AceConfig = LibStub("AceConfigDialog-1.0") local AceGUI = LibStub("AceGUI-3.0") local blizzFrame = AceGUI:Create("BlizOptionsGroup") blizzFrame:SetName(options.name) blizzFrame:SetTitle(options.name) blizzFrame:SetLayout("Flow") local aceConfigGroup = AceGUI:Create("ScrollFrame") blizzFrame:AddChild(aceConfigGroup) blizzFrame:SetCallback("OnShow", function(self, event, ...) AceConfig:Open(options.name, aceConfigGroup) end) blizzFrame:SetCallback("OnHide", function(self, event, ...) aceConfigGroup:ReleaseChildren() end) InterfaceOptions_AddCategory(blizzFrame.frame)
So not doing anything custom, just doing the same steps as far as I can tell.
The interface option panel now has the title across the top, but nothing else. No errors are happening, so I know that :Open is finding the right appname and options table and everything. Just none of the components of 'options' gets drawn.
The lack of errors is really frustrating because those would at least give me a clue why its broken.
:Open sets width and height of the container being passed in (aceconfiggroup) so I dont think its turning out to be 0x0 or something else that would cause it not to be drawn. maybe something blank is being drawn on top of the panel? I dont even know where to look now.
Aug 26, 2009first - thank you both for replying!Posted in: Ace3
Quote from dpsgnomeAceConfigDialog will wipe all widgets out of the container when repainting. And add them back again.
So, yes, you would indeed have to re-add your custom widgets every time it gets updated. Which AceConfigDialog does not support.
I found a hook, sortof, so Im cheating. At the end of :Open, it tests whether the container has a :Show method and calls it. The container in question (AceGUIWidget-BlizOptionsGroup) doesn't have that method. So after I call :AddToBlizOptions (which creates the widget and does the initial registrations and layout and stuff), I take the returned frame, get the widget out of it (thank you Borlox), and then do
widget.Show = function() my_addon:add_things_to_widget() end
Its inside that function that Im creating additional widgets and then adding them to the main widget container. So even when :Open releases and recreates the entire set of children its still calling this extra function exactly once each time.
Aren't you going about this the wrong way though? Just create your own container and have AceConfigDialog paint inside that. Tadaa.
Edit: Hrmmm is that possible though? If not, perhaps it should be?
If it is then I dont know how to do that. Especially using the BlizOptionsGroup widget. And not much in the way of acegui-3 docs.
Quote from OrionShockthere is an ace gui widget that's called similar to "BlizzardOptionsFrame" thet that perticular api uses. From there add a child widget to it of type "Frame" or "group" and then have ace dialouge open the options inside of that widget. you can then add a 2nd frame/group to the blizzardOptions widget and populate that with your stuff. (hint: SetLayout("Flow") to the blizzardOptions widget)
If you pass the container widget as the 2nd arg to Open i think is the intended method.
I am confused.
The only widget with a name anything like that is BlizOptionsGroup, used by the :AddToBlizOptions. It sets an OnShow that calls :Open, but the 2nd arg is the BlizOptionsGroup widget itself. I dont know how to override any of that without just reimplementing the whole thing from scratch. It doesn't look for any user hooks.
Adding more children to that widget is what I've been trying to do, and absolutely nothing happens. I did find that :FeedGroup screws things up for me, when it looks for a container (and :Open has already supplied one), it makes a new ScrollFrame widget as a top-level container, and then puts everything into that ScrollFrame. And that makes sense and everthing but it means that later on trying to call :addchild on the original BlizOptionsGroup widget does nothing, because the "Fill" layout only cares about the first child. So I changed my add_things_to_widget function to add stuff to "widget.children" instead of just "widget". Now it should be adding things to the same ScrollFrame that everything else is going into.
the lack of working examples out there makes me think that BlizOptionsGorup is just too limited for this though. I dont want to try and design my own frame to pass to InterfaceOptions_AddCategory tho so Im stuck with this one.
Aug 25, 2009Thank you, that helped! This is starting to drive me nuts.Posted in: Ace3
I call :AddToBlizOptions and save the result's ".obj" member. Everything in the options table shows up fine. Then I hook into a show callback and call a routine in my addon to add additional acegui-3 widgets into the same BlizOptionsGroup widget that was stored. And... nothing additional appears on the window.
I've been adding a TON of print calls to my code and my copy of aceconfigdialog so I can track where stuff is happening. So I know that when I display the options window,
1) all the norml stuff from the options table is getting set up before my routine is getting called, which is good. and my routine IS getting called exactly once, so okay.
2) none of my additional widgets are being :Released() accidentally. that was a problem for a while because aceconfigdialog:Open() releases all children before doing anything, so my stuff was immediately being tossed out. worked around that.
3) I set some debug fields in my widgets before passing them to AddChild. Then I added some tests and print()s to all 3 kinds of layout loops in acegui-3.0.lua, Flow and List and Fill. none of my added widgets are even in the children in the loops. *ANY* children, anywhere.
I looked thru FeedGroup and FeedOptions that get called by Open and they just do the same :AddChild stuff that I'm calling later. But none of the :AddChild calls after :Open returns ever have an actual affect. And :Addchild() calls :DoLayout() so its not just missing a refresh or aanything like that. it's just doing nothing at all.
Aug 25, 2009Im using AddToBlizOptions to get my aceconfig-3 options added to the Interface Options menu. That part is okay. But I also want to add other acegui widgets to the bottom of the options panel. The widget BlizOptionsGroup is registered as a container object so I think I can add more widgets to it but I need the blizoptionsgroup widget itself to do that.Posted in: Ace3
The AddToBlizzOptions function doesn't return the widget tho. It only returns the widget's frame and the widget itself is not returned (like as a second return value or whatever).
Right now Im thinking of doing this
local acecd = LibStub("AceConfigDialog-3.0") local direct_frame = acecd:AddToBlizOptions(name-of-my-addon) local widget = acecd.BlizOptions[name-of-my-addon]
Then widget.frame == direct_frame. I can still call InterfaceOptionsFrame_OpenToCategory with direct_frame or widget.frame, but then I can also use the rest of the acegui api on the widget object. But accessing BlizOptions like that feels like a hack. Is there another way of getting the widget pointer back?
- To post a comment, please login or register a new account.