ummm

[Grimsin]

sooo... where to start. Alright so the GrimUI is modular or at lest so its supposed to be... its a modular mess if you ask me... Well awhile back, a long while, i had gotten the use of the original move anything and when i say that i mean the one that can no longer be found for download anywhere.

Well, i worked it into the GrimUI made some changes thanks to Fyrye for position saving. Now heres where it gets complicated.... so i modified my player and party frames as well as moveanything to work in conjunction with one another. Basically i created a module called moveframes which is primarily the moveanything code. Now... my frames also allow for the user to hide/show them. When i tied the moveframes module to the playerframe module to the options module i have some weirdness going on. I have things narrowed down to one specific problem...

The hide handler for the move frames code does not save my frames correctly. It saves all other frames correct, just not the ones i have created and its only on the hide handler... the mouserelease handler saves position perfect. I will atempt to show what im talking about but... its going to be complicated... lol

The hide and mouse up handlers in the MoveFrames.lua

local function HideHandler(self, frame)
    local parentFrame = {}
    
    if GrimLayout.disabled == true then return; end
    if GrimLayout.doReset then GrimLayout.doReset = false; return; end
        if GrimLayout.nosave then return; end
    
    
    local frame = parentFrame[self] or self;
    if frame then
        local point, _, relativePoint, xOfs, yOfs = frame:GetPoint();
        GrimLayout[frame:GetName()] = {tostring(point), "UIParent", tostring(relativePoint), xOfs, yOfs};
    end
   
    
end

This is the results in the wtf !GrimUI.wtf as you can see my frame did not save proper, but the bliz frame did, also note that it only does not work on the show hide handlers the changes to the mouseup handler work and save proper.

GrimLayout = {
    ["locked"] = {
    },
    ["GrimPlayerFrame"] = {
        "nil", -- [1]
        "UIParent", -- [2]
        "nil", -- [3]
    },
    ["disabled"] = false,
    ["CharacterFrame"] = {
        "TOPLEFT", -- [1]
        "UIParent", -- [2]
        "TOPLEFT", -- [3]
        0, -- [4]
        -104.0000005623091, -- [5]
    },
}

This is the playerframes initalize function in the PlayerFrame.lua

GrimPlayerLayoutInitiate = function()
    
    local parentFrame = {}
    local frame = parentFrame[self] or self;
    
    if not GrimPlayerFrame:IsShown() then return end;
    
    if not GrimLayout.GrimPlayerFrame then
        GrimPlayerFrame:SetPoint("BOTTOMLEFT", GrimUIcoreArtB1, "TOPLEFT", 0, 0)
    end
    
    if GrimLayout.disabled == true then 
        GrimPlayerFrame:SetPoint("BOTTOMLEFT", GrimUIcoreArtB1, "TOPLEFT", 0, 0)
    
    --elseif GrimLayout.nosave == true then
      --  GrimPlayerFrame:SetPoint("BOTTOMLEFT", GrimUIcoreArtB1, "TOPLEFT", 0, 0)
    --elseif not GrimLayout.nosave then
      --  GrimPlayerFrame:SetPoint("BOTTOMLEFT", GrimUIcoreArtB1, "TOPLEFT", 0, 0)
      
    elseif GrimLayout.GrimPlayerFrame then
          if GrimLayout[GrimPlayerFrame:GetName()] then
              local points = GrimLayout[GrimPlayerFrame:GetName()];
              if not points then return; end
              GrimPlayerFrame:ClearAllPoints();
              GrimPlayerFrame:SetPoint(points[1], points[2],points[3], points[4], points[5]);
        end
end
end

This is the functions for the show/hide in the option panel that ultimate is where the problem lies... if i show hide the frame with my options panel it does not save the right frame position and when atempt to reshow it fires setpoint nil value errors from the saved vars...

GrimUIOptions.lua

function GrimUI:PlayerHideShowFunc()
    
    
    if GrimUIData.GUIPlayerFrame == "show" then 
    GrimPlayerFrame.Show = GrimPlayerFrame:Show()
    
    GrimPlayerFrame:Show()
 
    
    end
    
    if GrimUIData.GUIPlayerFrame == "hide" then
    
     
    GrimPlayerFrame:Hide()
    GrimPlayerFrame.Show = GrimUI.Dummy
    end
end
 
    local function PlayerHidShoCheckRes()
    local PlayerShoHidisChecked = CheckButtonPlayerShoHid:GetChecked()
 
    if PlayerShoHidisChecked == 1 then
 
    GrimUIData.GUIPlayerFrame = "hide"
    
    CheckButtonPlayerShoHid:SetChecked(true)
    
    elseif PlayerShoHidisChecked == nil then
    GrimUIData.GUIPlayerFrame = "show"
    
    CheckButtonPlayerShoHid:SetChecked(false)
    end
end
 
 
CheckButtonPlayerShoHid = CreateFrame("CheckButton", "CheckButtonPlayerShoHid", GrimOptionsPanel, "ChatConfigCheckButtonTemplate");
CheckButtonPlayerShoHid:SetPoint("LEFT", GrimOptionsPanel, 10, 50)
 
CheckButtonNamePlayerHid = CheckButtonPlayerShoHid:CreateFontString()
    CheckButtonNamePlayerHid:SetPoint('LEFT', CheckButtonPlayerShoHid, 'RIGHT', 0, 0)
    CheckButtonNamePlayerHid:SetFontObject(GameFontNormal)
    CheckButtonNamePlayerHid:SetText('Hide GrimUI Player Frame')
 
CheckButtonPlayerShoHid:RegisterEvent("PLAYER_ENTERING_WORLD")
CheckButtonPlayerShoHid:SetScript("OnEvent", function(self)
    
    if GrimUIData.GUIPlayerFrame == "hide" then
    CheckButtonPlayerShoHid:SetChecked(true)
    elseif GrimUIData.GUIPlayerFrame == "show" then
    CheckButtonPlayerShoHid:SetChecked(false)
    end
    
end)
 
CheckButtonPlayerShoHid:SetScript("OnClick", function()
    PlayerHidShoCheckRes()
    
    GrimUI.PlayerHideShowFunc()
    
end)

[Grimsin]

Upon further study... i think what is going on is im trying to get data out of multipul tables? let me ask a few questions...

first of all i have GrimUI = {} as well as a few other blahblah = {} now i know {} creates an empty table, but what exactly then is that? its like the wtf file right? but its not? and that table writes to the wtf file on log out? is there a way to force write to wtf at any given time? i think i need to be useing rawget somewhere, also obviously i dont fully grasp the tables vs the wtf file... help?

edit -- even more... so i think that when you load up without the wtf the first time it saves my frame positions it needs to do a rawget and rawset? on the points? in order to first build accurate table data? im still really confused on the metatables versus variables that go to the wtf files... thats got to be where my problem lies.... how to differentiate between the two's uses IE

if GrimLayout[frame:GetName()] then -- what exactly is that doing? is that looking in the wtf file? or in the metatable?

if GrimLayout.disabled then return; end -- this is looking in the wtf file correct? that im almost sure of or is it checking the metatable and the wtf? or is it checking the metatable and then writing the wtf? assuming it didnt return end i mean... if it said a function or grimlayout.disabled = true?

if its reading the metatable then writing the wtf then i think the problem is that when it reads the metatable for my frames start location its returning nothing or bad cords, since it does actually return something with one of the methods its just not a valid setpoint. well... it returns the right set point but does not return the right parent frame but thats because the moveframes sets the parents to uiparent as it should for optimal frame movement. With what i have how would i make it return the proper data at the proper timeS?

[Grimsin]

So i got it to write to the variables properly but its not picking it up when it loads back up now lol. the table is not populateing with my frames data on load

[Grimsin]

well i got it to work anyhow... lol if someone has a chance though i would still love to know more about the metatables and if how it hink they work is actually how its working.

[Xrystal]

Am I understanding you right here.

You have a table referenced as a saved variable table in your toc and are using it to store frame positioning and sizing ?

When are you repositioning/resizing the frames with the new information ?

I noticed that VARIABLES_LOADED is the event that blizzard uses to draw certain frames to the screen as their variables have all been loaded at that point. There is a layout-cache.txt file that holds information on several frames so you might want to see if that file coincidentally holds the values that are being used instead of the ones you were expecting. If, as I suspect, they are then simply repositioning and resizing when VARIABLES_LOADED has triggered should be enough for it to work the way you expect.

http://www.wowwiki.com/Events_that_f...oading_Process

Until 3.0, VARIABLES_LOADED used to fire upon completion of the addon loading process; since 3.0, it is fired in response to CVars, Keybindings and other associated "Blizzard" variables being loaded, and may therefore be delayed until after PLAYER_ENTERING_WORLD. The event may still be useful to override positioning data stored in layout-cache.txt

Edit: Reading your other posts ... I've not used metatables as far as I am aware yet but what I tend to do is define a default set of values I want the frame to use and set the saved variables table up with that before any functionality is started. This way the addon will work as if it had loaded the saved variables file. If the saved variable file exists it will simply overwrite the default values with the loaded ones and the addon will progress as normal.

[Grimsin]

yea thats how i do all my saved vars to but...

and the frame position generaly only resets if you /reload although im working on a reset frames position button but... right now you can do a /framereset and it will wipe the table and the variables then when you reload all the frames will bounce back to there normal location. basiclly though the entirety of the code allows me to toggle on off frame moving, toggle on off frame saving, lock individual frames, the move code does that and it does it for all bliz frames not attached to the frame management system and then it does it for all of my unitframes. well... the player frame so far... its partly working for the party frames or was... i threw another variable in there... two types of party frame styles... soon as i did that it fouled up the moveing again but... after fixing the last problem on the playerframe it hink i know why the party frames were having such issues... granted its a ton of code to go through and fix lol.


also my options panel allows me to show/hide my unitframes and the bliz unitframes which is where i started running into problems with the framemover code... making the setpoints available in the table for the show function on the option panel. its good to go now, i doubt its perfect im sure ill notice some other issues eventually but...

edit - what i mean by framereset the call to the locationing is anytime the frame is shown/hidien, on player entering world, and thats it but as far as when is the data being saved or changed... all the time, anytime you use one of the features i mentioned it changes the table and the wtf as well as onshow/hide and player entering world.

[Grimsin]

Originally Posted by Xrystal Am I understanding you right here. You have a table referenced as a saved variable table in your toc and are using it to store frame positioning and sizing ?

to clarify this one... i think so i think i have a Metatable referenced as a saved variable table in the toc and vice verse. i reference back and forth to the two as though they are all the same thing... which is where i think some of the weird variable changes are happening... although with what i just did to the code it fixed it all the way around as far as i can tell...

i added this line to the code and now when ever the code trys to pull the data and finds nil on the first setpoint itll drop back to its normal location

elseif points[1] == "nil" then GrimPlayerFrame:SetPoint("BOTTOMLEFT", UIParent, "BOTTOMLEFT", 0, 250) return end;

note once again this was only a problem when u first load or reset the frame positions and then hide the player frame and atempt to reshow it.

[Grimsin]

i think the biggest question i have is... when you have this...

GrimUI = {}

then you do GrimUI.blahblah = blahblah what is that GrimUI. part doing? adding it to the table? or metatable? then if you do this...

function GrimUI:blahblah(blah) what is the GrimUI: doing to the function? making the function a part of the table? THEN! if you do this....

GrimUI.blahfunction() is that then running the function from the table? or is that merely making the blahfunction() global via the table? or wtf is going on

oh one other if to boggle over... when you create a local function then do GrimUI.LocalFunction = LocalFunction ? is that then to another means of adding it to the table? or is it just making it global? or global to anything in the addons registered modules? or? lol are you confused yet? i am...

ONE last thing... when all is said and done... if it all works the way i think... what is the benefits and drawbacks to tabling functions, modeling functions and just making plain old every day local or global functions?

that was one big question wasnt it

[Xrystal]

Rofl .. yeah kinda confusing huh... In sleepy mode so cant think straight to explain rofl but hopefully these examples will help

I use that new local addonName, addonTable = ... ability that they bought in a few patches back.

In one file I could have maybe something along the lines of the following:

-- define table accessible by the whole addon this file is included in
addonTable["Utility"] = {}

-- define variable for use by any file in this addon
addonTable["Utility"].somevariable = true

-- define a function only used inside this file
local function alittlefunction(someparams)
end

-- define function that may need to be accessible in the main addon file
addonTable["Utility"].somefunction = function(self,otherparams)
self.somevariable = false
alittlefunction(otherparams)
end

In essence it is the same thing as what you are doing except in my case it is a table local to my addon only. No other addon will be able to access it so it isn't truly global. Think of the possibilities. A common utility file that has all those functions you find you are copying and pasting from other projects or retyping from memory cos you remember it that well from multiple past projects rofl. Add that one line at the top and all your addons can talk to it assuming its linked into the addon via the toc.

Smaller manageable code but the same functionality underneath.

Pros and cons. That I can't give you as at present I can't see anything negative with this functionality. rofl.

[Xrystal]

Originally Posted by Grimsin to clarify this one... i think so i think i have a Metatable referenced as a saved variable table in the toc and vice verse. i reference back and forth to the two as though they are all the same thing... which is where i think some of the weird variable changes are happening... although with what i just did to the code it fixed it all the way around as far as i can tell... i added this line to the code and now when ever the code trys to pull the data and finds nil on the first setpoint itll drop back to its normal location elseif points[1] == "nil" then GrimPlayerFrame:SetPoint("BOTTOMLEFT", UIParent, "BOTTOMLEFT", 0, 250) return end; note once again this was only a problem when u first load or reset the frame positions and then hide the player frame and atempt to reshow it.

Oh, do you use ClearAllPoints() to reset the frame positions ? That could be a factor. That function as well as reparaenting seems to cause some problems later on. Especially if dealing with blizz frames like I have done in the past. But yeah, that elseif statement is similar to what I do. Sometimes the GetPoint function will return nil if the anchor is UIParent or the parent frame if memory recalls from my time playing with it.

[Grimsin]

yea there is a clearallpoints call on some parts. i dont think its what is doing it but maybe, i had thought of that before and looked over it to see if that was why and it did not appear to be the reason.


and okay so i was right its adding to various types of tables then usable accross the addon or accross all addons or if local'd only its just usable by that lua file. if you put a local inside a function is it localized to that function then or still across the whole file?

[Xrystal]

a local inside any block of code is local to that block.

eg:

Start of file
local aFileWideVariable
End of File

If thisHappens then
local anIfBlockOnlyVariable
elseif thisHappens then
local anElseIfBlockOnlyVariable
else
local anElseBlockOnlyVariable
end

And the list goes on.

Basically a local variable is useable from the point it is defined to the point that it has reached its blocks closing statement. So either the end statement of many code blocks or the end of the file or the end of the addon based on the loading order.

However that local addonName,addonTable = ... seems to differ here as blizzard has made it so that despite being a local for the whole file it can be accessed in other files in the same addon.

[lilsparky]

can't say i followed this all very well, but that won't stop me from chiming in.

you mentioned something about metatables, but i didn't see a reference to any metatables in your code. it seems to be just normal tables.

lua files are parsed then executed as they are read from the .toc file (or included from the xml file). any X = {} calls will happen at this time and X will be an empty table. if you have a saved var called X (and "X = {}" is not "local X = {}") then X will be replaced by the new X when it is read in (the saved var file is actually just lua code that gets executed in the variable loading step after all addons have been loaded).

locals will never be visible outside your current lua file nor outside any do...end block. you can stuff them into some kind of global table if you need to access them between files. that's what the myAddon.myVar = myVar stuff there for. blizz has added an anonymous global table entry to lua files now so you don't have to create a table just to do this.

functions are the same way. you can define them as being members of a table or set a member of a table to be equal to some already defined local or global function after-the-fact. it doesn't matter, it's the same result -- your table now has a pointer to that function and anybody who can see your table can access that function.

[Grimsin]

how does what bliz added remove the need to use the table across the addon? right now im setting up a table to be used across the addon if i follow this all correctly.

also if i have two dif functions in two dif files both blahblah = {} where blahblah is the same on both functions will those overwrite each other or will they mash into a table together.

edit - didnt make sense when i read it again lol... i have to functions in two dif files each have a local blahblah = {} and the blahblah is the same in both...

[Xrystal]

file 1
local addonName, addonTable = ...
local blah = {}
blah.variable = true
addonTable["blah"] = blah
print(blah.variable)

file 2
local addonName, addonTable = ...
local blah = {}
blah.variable = false
addonTable["blah"] = blah
print(blah.variable)

toc
includes
file1
file2

1. File1 is loaded and parsed. The addonwide table is initialised with the current ... data stored in addonTable at that point.

2. You create a file wide local table blah and initialise it with no data.

3. You link the table you just created into the addonwide table meaning from this point onwards it is now accessible anywhere in the addon.

4. Printing blah or the addonTables version at this point will result in the output of false.

5. File2 is loaded into memory and during its parse it grabs the current contents of the addonwide table and stores it into addonTable as you request.

6. It then creates a file wide local table blah and initialises it with no data.

7. You then link this new table into the addonwide table and thus replacing the current contents of the same name.

8. Printing blah at this point or its addonTable version will result in the output of true as it was overwritten in this file.

I hope that clears things up a bit more.

[lilsparky]

Originally Posted by Grimsin how does what bliz added remove the need to use the table across the addon? right now im setting up a table to be used across the addon if i follow this all correctly. also if i have two dif functions in two dif files both blahblah = {} where blahblah is the same on both functions will those overwrite each other or will they mash into a table together. edit - didnt make sense when i read it again lol... i have to functions in two dif files each have a local blahblah = {} and the blahblah is the same in both...

what blizz did was create a table for you. it is anonymous -- meaning it has no name and is not in the global table (_G[]). only your mod lua files know anything about it.

it really doesn't make much difference whether you create a new global table or use the table blizz has created for you, really. it's just that creating your global requires proper timing of the init (it should be done in the first lua file you parse and nowhere else).

you could think of it as a passed argument to a function vs setting a global then calling a function that operates on that global. both work, but the passed argument is a cleaner solution.

you can print() pretty much any value in lua. try print()ing your tables or functions. they'll print their memory location which you can use to figure out which are references to the same thing vs those which are not.

[Vrul]

In your function GrimPlayerLayoutInitiate you do:

    local parentFrame = {}
    local frame = parentFrame[self] or self

In your function HideHandler you do the same weird thing (just a bit more spaced out). So why do you create an empty table and then try to make a local reference to an index of that empty table (which will always be nil based on the posted code)? You really are just doing:

    local frame = self

I really don't understand why you need HideHandler to begin with. Why not just save the position of every frame you care about once on PLAYER_LOGOUT?

What is this bit from GrimUI:PlayerHideShowFunc supposed to do?

	GrimPlayerFrame.Show = GrimPlayerFrame:Show()

Is that a round about way of setting .Show to nil?. If I am understanding the intent of the function correctly then it should be more along the lines of:

function GrimUI:PlayerHideShowFunc()
	if GrimUIData.GUIPlayerFrame == "show" then
		GrimPlayerFrame.Hide = GrimUI.Dummy
		GrimPlayerFrame.Show = nil
		GrimPlayerFrame:Show()
	else
		GrimPlayerFrame.Hide = nil
		GrimPlayerFrame:Hide()
		GrimPlayerFrame.Show = GrimUI.Dummy
	end
end

Originally Posted by Grimsin i think the biggest question i have is... when you have this... GrimUI = {} then you do GrimUI.blahblah = blahblah what is that GrimUI. part doing? adding it to the table? or metatable?

If GrimUI has a metatable with a "__newindex" field then what happens is up to that function otherwise GrimUI is assigned the value after the equal sign.

Originally Posted by Grimsin if you do function GrimUI:blahblah(blah) what is the GrimUI: doing to the function? making the function a part of the table?

If you call a function via a table index using ":" vice "." then the table itself is passed as the first argument so that GrimUI:blahblah(blah) is really just doing GrimUI.blahblah(GrimUI, blah).

Originally Posted by Grimsin if you do GrimUI.blahfunction() is that then running the function from the table? or is that merely making the blahfunction() global via the table?

It is just indexing GrimUI to find the index "blahfunction" and trying to run the value found as a function. No scoping is applied to the function beyond what it had upon creation. Obviously if the index "blahfunction" is not actually a function then an error occurs.

Originally Posted by Grimsin when you create a local function then do GrimUI.LocalFunction = LocalFunction ? is that then to another means of adding it to the table? or is it just making it global?

Assuming no metatable behavior, it just creates an index in GrimUI of "LocalFunction" with it's value being the actual function. Once again no scoping of the function has changed, you just created another way to reference it.

Originally Posted by Grimsin what is the benefits and drawbacks to tabling functions, modeling functions and just making plain old every day local or global functions?

Generally addons really only need to create two entries in _G (other than any named frames), one for it's saved variables table and another for it's API table (if any). There are a few minor exceptions but basically anything other than that is just polluting _G.

Using the table Blizzard now provides makes it really easy to separate code into multiple files and still have an easy means of accessing any needed information. The benefit over using globals is that table indexing speed is directly related to the number of indexes in the table. So, if you keep all your stuff in your own private table then you don't impact _G indexing and your own indexing will be much faster than index _G.

[Grimsin]

is there an addon or any other method of seeing what is in the tables while the game is running? the player frame is working fine but i have a small issue with the partyframes. They work fine except for when party member 2 and 4 join the party it seems to have conflicting info in the table when it goes to do the setpoint. 2 and 4 just never appear... because their setpoint is off screen or invalid.

Im pretty sure it has to do with it trying to change up the location of the frames as people join/leave/leader change.

edit -- it looks like devtools might do it? im just not sure, the /dump function provided in devtools says
"It should be able to handle pretty much any kind of return data (including self-referential nested tables!)"

what ever self-referential nested tables are.... and then what would i do to bring up the table? not sure how this works...

okay so obviously wow is not up so i cant try any of this but devtools also says this...
"e.g.
/dump GetPlayerMapPosition("player")

DevTools: value=GetPlayerMapPosition("player")
[1]0.43320921063423
[2]0.69365233182907
"
so can i do /dump GrimUI and itll dump the contents of GrimUI = {} ?? or the one im interested in is the dump of parent = {} and then GrimLayout which are the two things in control of the frame positioning.

[Grimsin]

just tested and /dump will dump anything including all the tables of all types.

[Xrystal]

ooh sweet .. love learning new things each day rofl.