Issue with AceConfig Options table.

[Soren]

OK, I have an AceConfig Options table that I'm having a small issue working around.

One of my calls refreshes a table element and sorts the elements, then re-adds them to the table. It works, but the change after the sort makes the options table open to the exact same table element... I need to somehow point the current "group" and object being manipulated to a different spot in the table.

Hope this makes sense...

For example...

table-arg-group-arg-element1
table-arg-group-arg-element2
table-arg-group-arg-element3
table-arg-group-arg-element4

If I change the element2 data and basically name the table field from "elemet1" to "element4", then re-order and sort (sort is done on a position setting in the db for the element)... When I call LibStub("AceConfigRegistry-3.0"):NotifyChange(...), it points to the same element (element1) but I need to make it point to Element4 which would be the current element, after the re-order and sort.

Any easy way to do this?

Thank You!

[Soren]

BAH, sorry think I found it.

--- Open an option window at the specified path (if any).
-- This function can optionally feed the group into a pre-created container
-- instead of creating a new container frame.
-- @paramsig appName [, container][, ...]
-- @param appName The application name as given to `:RegisterOptionsTable()`
-- @param container An optional container frame to feed the options into
-- @param ... The path to open after creating the options window (see `:SelectGroup` for details)
function AceConfigDialog:Open(appName, container, ...)

[Soren]

Actually not working, anyone got any advice?

[Soren]

Well, this is really annoying...

All I really want to do (simplified from above) is open to a specific options pane.

LibStub("AceConfigDialog-3.0"):SelectGroup(appName, "icons", subField, subField)

seems to do noting, no errors etc.

LibStub("AceConfigDialog-3.0"):Open(appName, "icons", subField, subField)

actually does what I want - BUT it opens in a new window instead of using the current blizzoptions frame.

My bigged questions about the OPEN function is "container" (optional 2nd argument). What should this be for the blizz options panel?

Thanks, ANY help appreciated.

[Farmbuyer]

It's sort of all or nothing. I have this comment block for an ugly piece of code in one of my addons, reminding me of what to expect:

-- Giving a custom container to :Open prohibits :SelectGroup, :Close,
-- and some other utility routines from working.

It may be best if you post actual code to paste.wowace.com and then one of the ace options gurus can have a look at it.

[Soren]

Thanks Farmbuyer, appreciate the help. I'll give that a shot.

Problem is the code is so large it's easier to post what's asked for / needed. Talking close to 300k in the options.

[Soren]

OK, http://paste.wowace.com/3532/ has a paste to better see the issues. The very bottom is the code in question for the :SelectGroup(..)

I included extra code so you can see how the initial structure is created.

Thank You!

[Farmbuyer]

I'm sorry, I have no idea whether your code is correct, because none of the options paths are actually visible. The bits that I can see look fine, but they depend on bits that aren't there.

Probably the most robust way of debugging this is:
1) figure out which copy of the Ace libraries on your hard drive is being loaded, or if there are multiple copies all of the same revision just pick one of them
2) fire up editors on AceConfigRegistry-3.0.lua and AceConfigDialog-3.0.lua
3) bump the "local MINOR" numbers at the top to ridonkulously large values to force that copy to be the "newest"
4) start adding print() statements to relevant calls. Figure out exactly what strings you're constructing, what "path keys" Ace is building as a result, and narrow down the mismatch.

Try getting it to work with just the standalone Ace GUI before trying to glue it together with the Blizzard Interface menu. Doing things with the latter often ends up requiring calls to the Blizzard API in addition to the AceConfig stuff.

[Nevcairiel]

SelectGroup does not work inside the blizz options frame. Its been too long since i've been in that code that i would know exactly why, but there was some reason for it.

Most likely because you create multiple frames for the same options table, and its impossible to find the correct status table based on the SelectGroup API.

The Blizz Options support was really just hacked onto the whole thing afterwards, its kinda surprising that it works as good as it does.

[Soren]

Originally Posted by Farmbuyer

I'm sorry, I have no idea whether your code is correct, because none of the options paths are actually visible. The bits that I can see look fine, but they depend on bits that aren't there.

Probably the most robust way of debugging this is:
1) figure out which copy of the Ace libraries on your hard drive is being loaded, or if there are multiple copies all of the same revision just pick one of them
2) fire up editors on AceConfigRegistry-3.0.lua and AceConfigDialog-3.0.lua
3) bump the "local MINOR" numbers at the top to ridonkulously large values to force that copy to be the "newest"
4) start adding print() statements to relevant calls. Figure out exactly what strings you're constructing, what "path keys" Ace is building as a result, and narrow down the mismatch.

Try getting it to work with just the standalone Ace GUI before trying to glue it together with the Blizzard Interface menu. Doing things with the latter often ends up requiring calls to the Blizzard API in addition to the AceConfig stuff.

Yep did that before and the callbacks for the table path were being read properly.