Instead, you'd use AceConfigDialog-3.0 which uses AceGUI-3.0 internally, and was specifically designed for handling options tables.
That's what I wanted to say :P
I made a AceGUI widget for loot items (has a place for and items name, texture, type, drop rate) then i make 1-4 container frames (depending on how many difficulty's a dungeon has) this container i fill with a AceGUI Scrollframe, then i simply add all the items to the scrollframe which takes care of the layout for me thus saving me from needing to write all the scrollframe and layout code.
This a good example of the issue I'm facing.
It's pretty clear to me now that I shouldn't be using AceGUI for my main UI. I have a lot to rewrite now :P
Ok, I'm not saying AceGUI it's the better option for me, just that it does some things I don't know how to handle the most important being "AceGUI:Release()". I understand this function disposes the frame to improve memory management.
Anyway, Torhal you solved the main issue:
For some reason, there's a major misconception by novice AddOn authors that AceGUI will make frame creation and manipulation easier - this isn't actually what it was designed for, and it is actually easier to use the default UI API for those things.
I guess the best approach would be to use AceGUI to handle the option frames, and the default UI API for the rest. Isn't that right?
Let me explain better. I have some of functionalities that are in the WoW API are not present in AceGUI, p.e.: the method SetResizable() on a frame widget, or SetTexture() on an options group. Maybe they exist, but they are not documented. So I just wanted to use those functions to create my addon's UI.
Perhaps a better aproach is let AceGUI handle the Options frame so they look just how most addons do, and create the main window without AceGUI. I guess I could do that whith:
local frm = Frame:Create()
or something similar (I know where to find that documentation :P), but then I would have to handle a few things myself that now are handled by AceGUI.