• 0

    posted a message on Issue with AceConfig Options table.
    Quote from 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.


    Well, that sums it up then... ugh, thats gonna suck for my options, but a flaw is a flaw...

    Thanks for the information though.
    Posted in: Ace3
  • 0

    posted a message on Issue with AceConfig Options table.
    Quote from 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.
    Posted in: Ace3
  • 0

    posted a message on Issue with AceConfig Options table.
    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!
    Posted in: Ace3
  • 0

    posted a message on Issue with AceConfig Options table.
    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.
    Posted in: Ace3
  • 0

    posted a message on Issue with AceConfig Options table.
    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.
    Posted in: Ace3
  • 0

    posted a message on Issue with AceConfig Options table.
    Actually not working, anyone got any advice?
    Posted in: Ace3
  • 0

    posted a message on Issue with AceConfig Options table.
    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, ...)
    Posted in: Ace3
  • 0

    posted a message on Issue with AceConfig Options table.
    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!
    Posted in: Ace3
  • 0

    posted a message on AceConfig-3.0 - type="icon"
    OK, for icons....

    I understand the call, but I need to dynamically update the icon texture when the value of the field that the icon is under is changed. How can you dynamically update the icon texture via the AceConfig gui calls?

    I mean, is there a way to change it dynamically through the "get" argument?

    I'm making a rather complex options setup for my addon, sorry for all the questions, I'm really pushing the limits of the framework.

    for example (I know this is not proper!)
    mytest= {
         order = 1,
         type = 'input',
         icon = function() return("Interface\\Buttons\\UI-GroupLoot-Pass-Up") end,
         name = "test",
         get = function(info, texval) <change "icon" above to a new texture from 'texval'> end,
    },


    Does the icon function get called any time the get function is called? Guess that's my question to solve the above scenario. Going to test myself with simple print debug code, but last i looked servers were not up. Maybe someone will have an answer before I can perform my testing.

    Thanks, again.
    Posted in: Ace3
  • 0

    posted a message on AceConfig-3.0 inpit type question.
    Quote from Seerah
    Also ensure that what you want to display in the edit box is a string.


    OK, I think this was the issue. The values that were an issue were numeric, going to test this out.

    Thanks!
    Posted in: Ace3
  • 0

    posted a message on AceConfig-3.0 inpit type question.
    Yep, I think it's just a communication issue. No offense to all.

    Everything presented is not answering the question.

    in the editbox (the box displayed on the screen that the user can type in to set or change the value), it's blank. Nothing showing the current value.

    That's the problem. I want it to show the current value in the box.

    My get function is working - it does return the value and shows it ONLY after typing in the box.

    I think this is because it's not populating based on the values being default.
    Posted in: Ace3
  • 0

    posted a message on AceConfig-3.0 inpit type question.
    I posted a single subset of my options.

    No idea what some of the responses are asking, but my question was how to show the current value of the variable associated with the editbox for type=input.

    Nothing more. My db code is fine, it does what it should, there is no issue there.

    Yes, my db uses a defaults table, I presume this may be the reason the value is not showing. But I want it to, the question was - can it?
    Posted in: Ace3
  • 0

    posted a message on AceConfig-3.0 inpit type question.
    That's how I have it setup, but it is not showing the value in the editbox.
    offsetX = {
           type = "input", 
           order = 1,
           name = L2["X Offset"],
           desc = L2["This sets the 'X offset' value."],
           width = "half",
           pattern = "%d",
           usage = L2["Only valid numeric offsets are allowed."],
           get = function(info) return Serenity.db.profile["offsets"][ info[#info-1] ][1] end,
           set = function(info, offset) Serenity.db.profile["offsets"][ info[#info-1] ][1] = offset end,
      },
    Posted in: Ace3
  • 0

    posted a message on AceConfig-3.0 inpit type question.
    OK, here's another Q.

    for type = "input", everything works fine. What I want is the editbox that the type = "input" table creates to initially show the value in the editbox.

    Is this built in, or not supported?
    Posted in: Ace3
  • To post a comment, please or register a new account.