WoWInterface

WoWInterface (https://www.wowinterface.com/forums/index.php)
-   General Authoring Discussion (https://www.wowinterface.com/forums/forumdisplay.php?f=20)
-   -   a means of checking if a frame exists (https://www.wowinterface.com/forums/showthread.php?t=42499)

Grimsin 01-30-12 09:56 PM

a means of checking if a frame exists
 
is there a means to check if a frame exists not just if it is shown or visible?

if you put an or inside of a setpoint say...
frame:SetPoint("LEFT", otherframe, "LEFT", or "LEFT", someotherframe, "LEFT") would it skip passed the first if it could not find that frame?

Seerah 01-30-12 10:06 PM

frame:SetPoint("LEFT", otherframe or someotherframe, "LEFT")

Grimsin 01-30-12 10:12 PM

Does that work for doing SetParent(something or somethingelse) ? as far as i can tell it does not :(

Seerah 01-30-12 10:42 PM

If, for some reason, it's not working, then do this:

local frame = something or somethingelse
SetParent(frame)

Waky 01-31-12 11:29 AM

I'm pretty sure you can do something along the lines of:

Code:

if frameName then
-- Code to be executed if it exists
end

If I'm not mistaken

If that does nothing you could just to the nil check

Code:

if (frameName~=nil) then
-- Code to be executed if it exists
end


Grimsin 01-31-12 11:31 AM

Quote:

Originally Posted by Waky (Post 251839)
I'm pretty sure you can do something along the lines of:

Code:

if frameName then
-- Code to be executed if it exists
end

If I'm not mistaken

If that does nothing you could just to the nil check

Code:

if (frameName~=nil) then
-- Code to be executed if it exists
end


The first method i know does not work... that only works for addon names. You could do a check to see if an addon is loaded via if name then but does not work for frames that do not exist. Ill try the if framename == nil then do such and such or vice verse ~=

Last night i already went with a method not listed here at all... since what im trying to do is run my UI with files missing and i want to have one file in the UI check to see if frames from the other file are available and run them if they are or dont if they are not. What i ended up doing is just having the file create a variable when it loads and have the other file check for the variable. Most likely not an efficient method and if i can get either of the above to work im going to do that.

Waky 01-31-12 11:41 AM

If you're trying to check if another addon's frames have loaded you need to make sure that those frames are visible (aka not local.) If they're global you can access them via the _G.frameName, I believe.

Torhal 01-31-12 11:44 AM

That does, indeed, work; the frame has to be named, however.

Waky 01-31-12 11:46 AM

Quote:

Originally Posted by Torhal (Post 251842)
That does, indeed, work; the frame has to be named, however.

Another valid point, lol.

Grimsin 01-31-12 11:57 AM

Quote:

Originally Posted by Torhal (Post 251842)
That does, indeed, work; the frame has to be named, however.

What works? doing the "if framename then"? it works if the framename can be found but if the frame does not exist then it fires an error. Im not exactly trying to see if another addon has loaded but rather if a certain file within the same addon has loaded. GrimUI is comprised of like 20 different lua files. In an attempt to find the DC bug in my UI im loading up one file at a time, the problem is many of the files had cross references so im going through and making each file work on its own without any of the cross referencing causing errors. Which is why its pertinent for me to check for frames existence. The best method may in fact be to have each file save a variable and then have other files check for that variable. Problem i foresee with this is any checks for variables have to come after addon loaded and that could cause a problem. It would be much easier if i could just check for a frames existence.

Waky 01-31-12 12:08 PM

If the addon functions are not dependent on learning another frame loading, you can just debug by adding print("frameName has loaded") after a frame is created as a debug method right now. Once you're finished you could remove those.

SDPhantom 01-31-12 12:23 PM

Quote:

Originally Posted by Waky (Post 251841)
If you're trying to check if another addon's frames have loaded you need to make sure that those frames are visible (aka not local.) If they're global you can access them via the _G.frameName, I believe.

Quote:

Originally Posted by Torhal (Post 251842)
That does, indeed, work; the frame has to be named, however.

To make this more simple, no matter how it's assigned, when a frame is created with a name, the Widget API assigns the frame automatically to a global of the same name.

For example, these will create the global MyFrame.
Code:

CreateFrame("Frame","MyFrame",UIParent);--                Creates the frame and API stores it in the global;
local frame=CreateFrame("Frame","MyFrame",UIParent);--        Creates the frame, API stores it in the global, Lua code keeps a local pointer
MyFrame=CreateFrame("Frame","MyFrame",UIParent);--        Redundant, API stores the frame in the global, Lua code overwrites it with itself
MyFrame=CreateFrame("Frame",nil,UIParent);--                Creates a frame with no name, but Lua code stores it in a global anyway (Same result only MyFrame:GetName() will return nil)

These will not:
Code:

CreateFrame("Frame",nil,UIParent);--                        Be careful with this, you create a frame, but have no way of referencing it again
local frame=CreateFrame("Frame",nil,UIParent);--        Creates a frame with no name and only a local pointer is stored


Grimsin 01-31-12 12:50 PM

True story ^

wish the game would come back up im ready to continue hunting this dc bug. With my editor in one hand and the wowi forums in the other i shall slay the mighty bug.

my thinking right now is if i go through and set up each file to function independently with checks in place for any call out of the file so that it does not error, it will make any future issues like this easier to troubleshoot. As of right now i still dont know exactly what file the dcing bug is coming from. Granted im getting closer one file at a time :)

Grimsin 01-31-12 01:17 PM

Should this be at the top of each of my files?

local addonName, addon = ...
_G[addonName] = addon

or just my first file?

Torhal 01-31-12 01:37 PM

The first line should be at the top of any file in which you want to use the shared table and the AddOn's folder name. The second line should only be used once (what's the point of repeatedly putting the AddOn in the global table keyed by name?).

Grimsin 01-31-12 01:45 PM

Quote:

Originally Posted by Seerah (Post 251827)
If, for some reason, it's not working, then do this:

local frame = something or somethingelse
SetParent(frame)

Neither of the or'ing methods work it always trys to hook to the first frame passed and when it finds its not a frame it errors.

doing a frame =~ nil did work :)

Waky 01-31-12 02:28 PM

Quote:

Originally Posted by Grimsin (Post 251860)
Neither of the or'ing methods work it always trys to hook to the first frame passed and when it finds its not a frame it errors.

doing a frame =~ nil did work :)

Did you put ~= or =~?

SDPhantom 01-31-12 02:55 PM

Quote:

Originally Posted by Grimsin (Post 251856)
Should this be at the top of each of my files?

local addonName, addon = ...
_G[addonName] = addon

or just my first file?

I usually have a core file in a UI addon that is loaded first out of all the others that handles all the basic needs, typicly global registration of the addon table, API for registering modules, event callback system, and/or any functions/structures I want globally available to the entire addon.

It doesn't hurt to put that line in all of your files, but it's completely redundant.

Grimsin 01-31-12 02:55 PM

Quote:

Originally Posted by Waky (Post 251862)
Did you put ~= or =~?

~= :) of course

Torhal 01-31-12 04:06 PM

Quote:

Originally Posted by SDPhantom (Post 251863)
I usually have a core file in a UI addon that is loaded first out of all the others that handles all the basic needs, typicly global registration of the addon table, API for registering modules, event callback system, and/or any functions/structures I want globally available to the entire addon.

It doesn't hurt to put that line in all of your files, but it's completely redundant.

Including this line, however, is not redundant:

Code:

local addonName, addon = ...
That ensures the file it's included in has an upvalued version of the name and the shared table. Personally, I prefer NOT putting that table in the global space and instead using it as a shared private namespace.


All times are GMT -6. The time now is 08:45 AM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI