• 0

    posted a message on Blizzard ScrollFrame templates
    So it seems that the major difference is that the faux frame inherits from UIPanelScrollFrameTemplate.

    Both are defined in: FrameXML/UIPanelTemplates.xml

    http://wowprogramming.com/utils/xmlbrowser/live/FrameXML/UIPanelTemplates.xml

    But the portion of the XML dealing with the faux-frame definition consists only of:

    <ScrollFrame name="FauxScrollFrameTemplate" inherits="UIPanelScrollFrameTemplate" virtual="true">
        <Scripts>
            <OnScrollRangeChanged function="" /> 
        </Scripts>
        <ScrollChild>
            <Frame name="$parentScrollChildFrame">
                <Size>
                    <AbsDimension x="300" y="334" /> 
                </Size>
                </Frame>
        </ScrollChild>
    </ScrollFrame>


    So, other then forcing the faux frame to be an exact size, what else does this child-template of the main scroll frame template do?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Blizzard ScrollFrame templates
    I'm almost to the point where I understand this... but not completely.

    What is the difference between the following?:

    - FauxScrollFrameTemplate
    - HybridScrollFrameTemplate
    - UIPanelScrollFrameTemplate

    What I want is a scroll box with a 2-layer tree with selectable elements.

    [+]Section X
    --> [+]Category A
    --> --> Element 1
    --> --> Element 2
    --> [+]Category B
    --> --> Element 3
    --> --> Element 4
    [+]Section Y
    --> [+]Category C
    --> --> Element 5
    --> --> Element 6

    But I'm not really sure which of the (3) scroll frame templates that I should be basing stuff off of for creating something like that. The new dual-pane quest log seems to use HybridScrollFrameTemplate. But a lot of other examples use either the Faux template or UIPanelScrollFrameTemplate.

    If I understand things correctly:

    a) I have my master frame (f) which is the full size of the entire dialog

    b) I create a sub-frame (child of f), called "f_scrollframe", covering the area where the scrolling area will appear. Some notes indicate that the width of this doesn't matter, other places seem to indicate that the width should match the area you want covered.

    c) I create another frame (regular frame) as a child of the f_scrollframe, and call f_scrollframe:SetScrollChild(f_scrollchild). This frame is what the content actually gets shoved into. So if I wanted to put a tree in, or multi-line text, or a bunch of controls on individual rows, those would be children of the f_scrollchild.

    Since I'm not using AceGUI to build my UI, not sure whether I could lean on the TreeGroup widget in AceGUI.

    Reference links:

    http://wowprogramming.com/docs/widgets/ScrollFrame
    http://www.wowwiki.com/Making_a_scrollable_list_using_FauxScrollFrameTemplate
    Posted in: Lua Code Discussion
  • 0

    posted a message on AceDB storage location of realm/char data
    Ah, so it's the result of the Blizzard addon loader which creates the tables under "sv.*"?

    So how efficient is the mapping from the "sv.*" trees over to the global / char / realm / profile trees when AceDB initializes things? Is it making a copy of the tables / keys, or is it just pointing self.db.global at self.db.sv.global?

    For instance, when I walk the entire self.db (created by AceDB3's New() function during my addon's Initialize()), with a data structure like:

    global = {
        minimap = {
            hide = false,
            minimapPos = 250,
            radius = 80,
        },
        firstuse = true,


    I will see these 4 entries repeated twice in the tree. Once at "self.db.global.minimap.*" and a second time at "self.db.sv.global.minimap.*".

    If I understand the AceDB-3.0 Lua code correctly, it's doing a reference point from self.db.global to self.db.sv.global and not copying everything in the table. (Full table copy seems to only take place in DBObjectLib:CopyProfile().) With the bottom line that if you have 100KB of data in your self.db.sv.global tree, after AceDB finishes New(), you still basically have 100KB worth of "global" data and not a brand new 100KB of data that duplicates what was in the "sv" tree?

    Design-wise, I think what this means for me is that once I think users are going to store over 500KB (or name your pain threshold) of character specific data, I may wish to go ahead and start using a 2nd character-specific SavedVariablesPerCharacter.

    TOC:

    ## SavedVariables: MyAddonDB
    ## SavedVariablesPerCharacter: MyAddonDBPC

    Lua:

    self.db = LibStub("AceDB-3.0"):New("MyAddonDB", MyAddonDefaults, true)
    self.dbpc = LibStub("AceDB-3.0"):New("MyAddonDBPC", MyAddonPCDefaults)

    Then, anywhere where I would use "self.db.char.*" I would have to switch over to "self.dbpc.char.*". Which would get me the behavior of character-specific stuff gets saved in the character folder Lua file without having to do the impossible in the AceDB code. Character-specific stuff would then only get loaded when that character gets used and would not bloat the central MyAddonDB saved variable.

    That seems fairly clean. A small kludge, but nothing overly ugly, for cases where I do end up with a lot of user-specific data, which doesn't need to be accessed by other characters. And it can even be retro-fitted into my existing addon's Lua code with an easy search/replace.

    (The addon in question is a note/task addon where the user has the choice to store a particular note/tasklist as char-specific or to instead slot it into a global, profile or realm scope. Since some users tend to be packrats, I can easily see someone with a few dozen character-specific notes on each of their dozen-plus characters. But since notes will probably only take up 600 bytes of RAM at maximum size, they'd have to really work at it to exceed even 1MB of RAM. So it's a toss-up whether the optimization is worth it. Since it's not technically difficult to do, I'm stuffing the idea into my back pocket for when needed.)
    Posted in: Ace3
  • 0

    posted a message on AceDB storage location of realm/char data
    The AucDB was a typo, I was speaking of maintaining two separate AceDB objects.

    In this particular case, yes, the data would be specific to that character if the user chooses. But since I'm only tracking maybe a few hundred entities at worst (~600 bytes each at maximum) and more likely less then that across all the user's characters, it probably won't matter. I'm going to file the (2) AceDB objects idea away though, in case I decide to cut down on memory usage later (it makes no difference to my app due to how the data is structured, char-specific stuff is already in a separate section of the database tree).

    It stems more from disappointment that AceDB loads in everything, even if it only exposes the current realm / char / faction to the application (all the other junk is still sitting in memory under the "sv" tree of tables). I was hoping that it could be smarter then that. But without realm-level SavedVariables, I can't see AceDB cluttering up its code just to split anything under the "char" tree out to a separate saved variable.
    Posted in: Ace3
  • 0

    posted a message on AceDB storage location of realm/char data
    Ah right, there is no realm level SavedVariables folder. I was thinking there was this morning before I had my coffee.

    I guess if I'm willing to juggle both SavedVariables and SavedVariablesPerChar in my TOC file and maintain (2) AucDB databases, I would get what I want? At least as far as segregating char-specific data and preventing it from loading if I'm not on that character?
    Posted in: Ace3
  • 0

    posted a message on AceDB storage location of realm/char data
    So I'm getting ready to use AceDB for the first time, and I notice that it always shoves its saved data into the account's SavedVariables folder. Which makes sense.

    My question is why doesn't it save the server-specific "realm" or character-specific "char" data in the server/character folders instead of shoving all that into the global "myaddon.lua" file?
    Posted in: Ace3
  • To post a comment, please or register a new account.