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? |
frame:SetPoint("LEFT", otherframe or someotherframe, "LEFT")
|
Does that work for doing SetParent(something or somethingelse) ? as far as i can tell it does not :(
|
If, for some reason, it's not working, then do this:
local frame = something or somethingelse SetParent(frame) |
I'm pretty sure you can do something along the lines of:
Code:
if frameName then If that does nothing you could just to the nil check Code:
if (frameName~=nil) then |
Quote:
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. |
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.
|
That does, indeed, work; the frame has to be named, however.
|
Quote:
|
Quote:
|
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.
|
Quote:
Quote:
For example, these will create the global MyFrame. Code:
CreateFrame("Frame","MyFrame",UIParent);-- Creates the frame and API stores it in the global; Code:
CreateFrame("Frame",nil,UIParent);-- Be careful with this, you create a frame, but have no way of referencing it again |
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 :) |
Should this be at the top of each of my files?
local addonName, addon = ... _G[addonName] = addon or just my first file? |
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?).
|
Quote:
doing a frame =~ nil did work :) |
Quote:
|
Quote:
It doesn't hurt to put that line in all of your files, but it's completely redundant. |
Quote:
|
Quote:
Code:
local addonName, addon = ... |
All times are GMT -6. The time now is 08:45 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI