First, you really should not be using names like "PartyFrame" and "UnitFrame" in global function/table/anything names. Not only are such generic terms bad choices for globals anyway, but they're also extremely similar to Blizzard's global function and object names. Pick an addon name and use it, eg. "mrmrUnitFrame".
Well, I wrote the code in these codeboxes as "example", so indeed I will be using other names :)
It's simpler and just as effective to just use a "factory" function that creates and returns a unit frame.
Also, assuming every unit frame is going to have a health bar, and no unit frame will have more than one health bar, it's really just a waste to move the "create a health bar" code into a separate function. Just create the health bar right in the "create a unit frame" function.
If you are specifically trying to learn how to write OOP code, and don't actually have a particular end result in mind, that's one thing... but if you're actually trying to write a unit frames addon, I think you're going about it in a way that's much, much more complicated than it needs to be.
Actually, this would be the 3rd/4th rewrite.
Right now, I have a "factory" function that creates and returns unitframes and every element of such unitframes are created within the "factory function" itself.
This was more an exercise to "learn how to write OOP code".
Unless self refers to UnitFrame in that scope, no, those two are not the same -- calling UnitFrame:SomeFunction(x) means that inside that function, self refers to the UnitFrame object, while if you called self:SomeFunction(x) the self inside the function would refer to the same object as the self in the scope where you called it.
You're right. I guess the right way to call that is "self:SomeFunction(x)" for the purpose I was looking for.
Let's start over; can you describe briefly what, exactly, it is that you want to do/achieve?
Regarding hiding variables; yes, you should use local variables wherever possible.
Well, what I'm trying to achieve is to create a UnitFrame class.
This class will instantiate different types of unitframes for party/raid/pet members.
So, the UnitFrame table will be my class (in its own file).
The UnitFrame:new() method will be my constructor and different parameters will instantiate different types of UnitFrame, calling methods like:
Now, the UnitFrame table will be in its own file.
Declaring it local, would hide UnitFrame:new() method from everywhere else.
So how could I expose only such function?
Also, as you can see, in the 2nd codebox, I've declared, for example, two different method to draw my healthbars. Which one should I use?
That's clearly just an example to understand which way I should use, writing my code. As I've already told you all, both functions/methods achieve the same goal, aka, display a frame and a statusbar with some fontstring ontop. So, both "syntax" are correct...still the "style" (is it called style?) is kinda different.
About the setmetatable() call, sure, it's not used right now, and for sure I'll need extensive experience to use it as I should. That's why I wrote this post in the first place. Seeking hints and suggestion...
Seeking what I'm doing wrong and why.
EDIT:
Your last post show exactly what I'm looking for, except how to expose the "constructors".
About the "header", I was creating it with a plain function (PartyFrame_Init())
About your example, why in CreateUnitFrame are you returning the frame?
Isn't that "unitframe" already inside partyFrame.unitframes["party1"]?
Same goes for the healthbar.
-- now you can create stuff like this:
local partyFrame = createHeader("party")
partyFrame:CreateUnitFrame("party1")
unitframe1:CreateHealthBar()
Isn't this enough? Are you returning the frame, cause it's a "good" programming practice?
These two calls are doing the same thing (aren't they?)
Same question about my HealtBar methods.
Both of my examples are working (I believe), drawing frames on the screen, but yet I cannot understand what's wrong and what's right.
Am I missing something?
Aye, would be nice to "tag" loots as "Disenchanted" and "Guild Bank" for example...also, add some "modules" to keep track of various dkp systems.
Like add automatically GP costs to items, if not DE/Banked, if guild/tracker_player is using EPGP. This should be done with modules, btw...so we could have all systems supported
sorry, i'm here again...not sure if anyone has reported this, but after killing any boss (tested in MH tonight...a guildie with the same problem too), everytime you mouseover it, the "Win" music is played.
there should already be an event for mouse in and out OnEnter and OnLeave
Yes, there is
Quote from Kagaro »
now as far as keyboard awayness I could add an OnKeyUp, OnKeyDown Howver these only fire when the frame is in these stratas
* TOOLTIP
* FULLSCREEN_DIALOG
* FULLSCREEN
* DIALOG
I'm not sure how many ppl will use OnKeyUp/OnKeyDown, but could be a nice addition
Quote from Kagaro »
So depending on the frame behind it (and what strata it is in) you might get an ALT to lower your frame strata but then would not be able to get the release event and be stuck below. You could use frameLevel to control the z-indexing to push you panel to the top of the stack, you would also need to hook and add vent handlers to omen as well.
mmmh, this seem a bit "hard" to implement (for me at least :)), but are you suggesting using something like:
local level = Recount.MainWindow:GetFrameLevel()
self:SetFrameLevel(level + 1)
and btw, if it's not possible to restore "original" strata (getting the release of Alt), well i'll leave without it :)
mmmh...well, i could "force" strata back OnLeave (everytime the mouse leave the frame, don't bothering about Alt release)
so, at the end...if it's not too much effort...the new handler for keypress would be nice :)
the mouse click intercepts is controlled by wow not kgPanels. which ever frame is at the top of the stack gets the click. It may be possible via a script to pass the data down. not sure if it would work the way you intend.
Mouse click works fine.
And at this moment, kgpanel is getting the click (switching Omen/Recount).
What i would like is to make kgpanel aware of "ALT and MouseOver".
When the mouse is over kgpanel frame and ALT is pressed, i should temporary change the kgpanel's strata...that's all (so, mouseover+ALT, would make Omen/Recount clickable)
Right now is:
Omen -> Desktop
Recount -> Desktop
kgpanel_OmenPanel -> Dialog
would be enought to change kgpanel_OmenPanel strata to Desktop on MouseOver+ALT
mrmr
P.S.
Anothe problem...there's a way to "register" Pet's and Target's target?
I would like to resize pet's frame when my pet has effectively a target and self:Show() a frame when my target aquire a target itself.
I'm using Capping and RBM_Capping module, but there's a little problem.
Using capping, you could "click" on bars and send announce to /bg /w or /s (others maybe?).
When you have RBM, isn't possible to click on bars to send "messages".
hello, using this mod by some days now...nice mod indeed :)
so far i got a pair of panels for Omen and Recount.
Those panels hide when i toggle Omen/Recount.
Here's the scripts (put them OnLoad for the panel u using):
local myPanel = self
if Omen.Anchor then
Omen.Anchor:SetScript("OnShow",function(frame)
myPanel:Show()
end)
Omen.Anchor:SetScript("OnHide",function(frame)
myPanel:Hide()
end)
end
if Omen.Anchor:IsVisible() then self:Show() else self:Hide() end
local myPanel = self
if Recount.MainWindow then
Recount.MainWindow:SetScript("OnShow",function(frame)
myPanel:Show()
end)
Recount.MainWindow:SetScript("OnHide",function(frame)
myPanel:Hide()
end)
end
if Recount.MainWindow:IsVisible() then self:Show() else self:Hide() end
Add Recount or Omen to the "Script Dependency" field and they should work.
Basically, those scripts Hide/Show the kgpanel when you toggle Omen and/or Recount.
Btw, now, here's my problem...
I would like to have both Omen/Recount in the same frame, switching between them with a Mouse click.
1) Toggle Omen - Panel and Omen show
2) Click on Omen Frame - Panel stay visible, Omen hide and Recount show
3) Click on Recount Frame - Panel stay visible, Recount hide and Omen show
3) whenever i "toggle" the visible Omen/Recount - Panel hide, Omen/Recount hide
Do you think this is achivable using OnClick and raising Panel Strata?
Thank you
mrmr
EDIT:
after some tries, here's...
....just create the Omen Panel...
Now, put Omen and Recount togheter in the same frame
Raise the strata of the panel from Desktop to Dialog (Omen and Recount strata should be "Destop", so the kgpanel frame is higer and can intercept mouseclicks) and add the following to OnClick:
if Recount.MainWindow:IsVisible() then
Recount.MainWindow:Hide()
Omen.Anchor:Show()
self:Show()
else
if Omen.Anchor:IsVisible() then
Omen.Anchor:Hide()
Recount.MainWindow:Show()
self:Show()
end
end
this way, everytime you click on the frame, Omen/Recount are toggled as intended.
...too bad....would be nice to have Recount clickable still (lowering panel strata, when Recount show up) and toggle Omen.Anchor:Show() when "closing" Recount's main window.
In this way, clicking "over" Omen would show Recount (with Recount clickable), but to show Omen again you'd need to "close/toggle" Recount.
Still working on a nice way for this ^^
There's maybe a way to intercept in OnEnter a key like ALT or Control?
When mouse is over kgpanels' frame and ALT pressed we could lower the panel strata (just an idea :P), so Recount (with ALT pressed) would be clickable...
0
Well, I wrote the code in these codeboxes as "example", so indeed I will be using other names :)
Actually, this would be the 3rd/4th rewrite.
Right now, I have a "factory" function that creates and returns unitframes and every element of such unitframes are created within the "factory function" itself.
This was more an exercise to "learn how to write OOP code".
You're right. I guess the right way to call that is "self:SomeFunction(x)" for the purpose I was looking for.
0
Well, what I'm trying to achieve is to create a UnitFrame class.
This class will instantiate different types of unitframes for party/raid/pet members.
So, the UnitFrame table will be my class (in its own file).
The UnitFrame:new() method will be my constructor and different parameters will instantiate different types of UnitFrame, calling methods like:
Now, the UnitFrame table will be in its own file.
Declaring it local, would hide UnitFrame:new() method from everywhere else.
So how could I expose only such function?
Also, as you can see, in the 2nd codebox, I've declared, for example, two different method to draw my healthbars. Which one should I use?
That's clearly just an example to understand which way I should use, writing my code. As I've already told you all, both functions/methods achieve the same goal, aka, display a frame and a statusbar with some fontstring ontop. So, both "syntax" are correct...still the "style" (is it called style?) is kinda different.
About the setmetatable() call, sure, it's not used right now, and for sure I'll need extensive experience to use it as I should. That's why I wrote this post in the first place. Seeking hints and suggestion...
Seeking what I'm doing wrong and why.
EDIT:
Your last post show exactly what I'm looking for, except how to expose the "constructors".
About the "header", I was creating it with a plain function (PartyFrame_Init())
About your example, why in CreateUnitFrame are you returning the frame?
Isn't that "unitframe" already inside partyFrame.unitframes["party1"]?
Same goes for the healthbar.
Isn't this enough? Are you returning the frame, cause it's a "good" programming practice?
0
Didn't really know where to ask for this, but could someone direct me in this matter?
I'm trying to code a "PartyFrame" and I would like to have some nice writing style. So I'm here asking for advices.
Let's say I will create a frame to contain my UnitFrames, like this:
Now you can see that I would like my UnitFrames created inside that frame.unitframe table.
So I wrote in another file my "class", like this:
First off I would like to know if I should "hide" the class' methods/vars using something like
If this is the case, how could I expose the "new" method only?
Another matter is which style should I use for my methods?
These two calls are doing the same thing (aren't they?)
Same question about my HealtBar methods.
Both of my examples are working (I believe), drawing frames on the screen, but yet I cannot understand what's wrong and what's right.
Am I missing something?
Thank you everyone, for reading my (crappy) code.
0
Am I wrong assuming this?
0
0
Aye, would be nice to "tag" loots as "Disenchanted" and "Guild Bank" for example...also, add some "modules" to keep track of various dkp systems.
Like add automatically GP costs to items, if not DE/Banked, if guild/tracker_player is using EPGP. This should be done with modules, btw...so we could have all systems supported
mrmr
0
Kinda annoying and spammy :)
mrmr
0
Yes, there is
I'm not sure how many ppl will use OnKeyUp/OnKeyDown, but could be a nice addition
mmmh, this seem a bit "hard" to implement (for me at least :)), but are you suggesting using something like:
and btw, if it's not possible to restore "original" strata (getting the release of Alt), well i'll leave without it :)
mmmh...well, i could "force" strata back OnLeave (everytime the mouse leave the frame, don't bothering about Alt release)
so, at the end...if it's not too much effort...the new handler for keypress would be nice :)
thank you and sorry for all these requests
mrmr
0
Mouse click works fine.
And at this moment, kgpanel is getting the click (switching Omen/Recount).
What i would like is to make kgpanel aware of "ALT and MouseOver".
When the mouse is over kgpanel frame and ALT is pressed, i should temporary change the kgpanel's strata...that's all (so, mouseover+ALT, would make Omen/Recount clickable)
Right now is:
Omen -> Desktop
Recount -> Desktop
kgpanel_OmenPanel -> Dialog
would be enought to change kgpanel_OmenPanel strata to Desktop on MouseOver+ALT
mrmr
P.S.
Anothe problem...there's a way to "register" Pet's and Target's target?
I would like to resize pet's frame when my pet has effectively a target and self:Show() a frame when my target aquire a target itself.
0
I'm using Capping and RBM_Capping module, but there's a little problem.
Using capping, you could "click" on bars and send announce to /bg /w or /s (others maybe?).
When you have RBM, isn't possible to click on bars to send "messages".
I'm dumb or there's a workaround?
thank you
mrmr
0
so far i got a pair of panels for Omen and Recount.
Those panels hide when i toggle Omen/Recount.
Here's the scripts (put them OnLoad for the panel u using):
Add Recount or Omen to the "Script Dependency" field and they should work.
Basically, those scripts Hide/Show the kgpanel when you toggle Omen and/or Recount.
Btw, now, here's my problem...
I would like to have both Omen/Recount in the same frame, switching between them with a Mouse click.
1) Toggle Omen - Panel and Omen show
2) Click on Omen Frame - Panel stay visible, Omen hide and Recount show
3) Click on Recount Frame - Panel stay visible, Recount hide and Omen show
3) whenever i "toggle" the visible Omen/Recount - Panel hide, Omen/Recount hide
Do you think this is achivable using OnClick and raising Panel Strata?
Thank you
mrmr
EDIT:
after some tries, here's...
....just create the Omen Panel...
Now, put Omen and Recount togheter in the same frame
Raise the strata of the panel from Desktop to Dialog (Omen and Recount strata should be "Destop", so the kgpanel frame is higer and can intercept mouseclicks) and add the following to OnClick:
this way, everytime you click on the frame, Omen/Recount are toggled as intended.
...too bad....would be nice to have Recount clickable still (lowering panel strata, when Recount show up) and toggle Omen.Anchor:Show() when "closing" Recount's main window.
In this way, clicking "over" Omen would show Recount (with Recount clickable), but to show Omen again you'd need to "close/toggle" Recount.
Still working on a nice way for this ^^
There's maybe a way to intercept in OnEnter a key like ALT or Control?
When mouse is over kgpanels' frame and ALT pressed we could lower the panel strata (just an idea :P), so Recount (with ALT pressed) would be clickable...