API version 5: changes and discussion - Page 6

Dawn · 10-15-10, 06:37 PM

The Eclipse bar doesn't initialize correctly. Seems like it doesn't check for the unit power event anymore.

E: EvilPaul already posted an issue on github. Reverting those changes fixed it, indeed.

Elisios · 10-17-10, 09:31 AM

By the way, the SecureGroupPetHeader seems to assign invalid pet unit ids (when both useOwnerUnit and filterOnPet are false), e.g. raidpetpet1 instead of raidpet1. A workaround consists in adding the following snippet when spawning the header :

Code:

oUF:SpawnHeader(name, template, visibility, 
	'oUF-initialConfigFunction', [[
		self:SetAttribute('refreshUnitChange', [=[
			local unit = self:GetAttribute('unit')
			if unit then
				unit = unit:gsub('petpet', 'pet')
				if unit ~= self:GetAttribute('unit') then
					self:SetAttribute('unit', unit)
				end
			end
		]=])
	]]
)

The "refreshUnitChange" attribute is called by the SecureGroupHeader when the header buttons are updated.

neverg · 10-17-10, 09:52 AM

I've noticed something strange.

On my Party or Raid Units, when hover the mouse on a unit, the Tooltip flickers. It doesn't happen on Single Unit Frames. And somethings when using clique it doesn't catch the clicks, I guess it's related to the flicking of the tooltip.

Any clues why it behaves like that?

Dawn · 10-17-10, 10:55 AM

RegisterStateDriver/RegisterAttributeDrive

It's the pretty thing that causes all of the funny things that happen to units spawned via headers (party, raid, ...). haste already answered that several times, though.

I'm confident that this will be solved (by blizzard), just takes some patience on our side.

neverg · 10-17-10, 11:02 AM

Originally Posted by Dawn

RegisterStateDriver/RegisterAttributeDrive

It's the pretty thing that causes all of the funny things that happen to units spawned via headers (party, raid, ...). haste already answered that several times, though.

I'm confident that this will be solved (by blizzard), just takes some patience on our side.

Ye I know he has, but thought it was only related to Portraits, which I don't use. Well, being that, it's just a matter of time to wait for Blizzard to fix it.

haste · 10-17-10, 11:31 AM

I tracked down the exact cause the other day, and it's been patched. We have to live with the issue until the next patch however.

As for the PetHeader, I'll have a look during the week if I remember.

Talyrius · 10-17-10, 03:08 PM

Originally Posted by haste

We have to live with the issue until the next patch however.

Any idea about which patch that will be though? A bug patch or 4.0.3?

Luzzifus · 10-19-10, 12:37 AM

Why do headers actually have to have a size at all? I mean that "initialConfigFunction" thingy:

Code:

local raidgroup = oUF:SpawnHeader('oUF_Raid'..i, nil, 'raid',
	'groupFilter', tostring(i),
	'showRaid', true,
	'showParty', false,
	'showPlayer', false,
	vg and 'yOffset' or 'xOffset', vg and -3 or 3, 
	(not vg) and 'point' or nil, (not vg) and "LEFT" or nil,
	'oUF-initialConfigFunction', ([[
		self:SetWidth(%d)
		self:SetHeight(%d)
	]]):format(nivDB.prx, nivDB.pry)
)

I've added it to my layout because it was proclaimed in the OP, but actually, everything works just fine even without it. My current understanding of headers is that they're just like anchor points for the actual unit frame elements, so they don't neccessarily need to have a size. Am I understanding it wrong?

haste · 10-19-10, 02:05 AM

oUF-initialConfigFunction is set on the header, but it isn't actually used on the header. Every time the header spawns a frame it calls initialConfigFunction. In this "function" oUF looks at what was spawned, and calls oUF-initialConfigFunction on the frames spawned, not the header.

You can take a look at what oUF uses it for internally.

10-19-10, 07:46 AM

I wanted to get started with my own oUF layout, so I take a look at the oUF main page, where it is clearly stated:

Do note that 1.5 is not backwards compatible with 1.4.x layouts.

OK, no problem - because a few lines below we find this gem:

A wiki with some documentation regarding the API can be found here.

Great

As I hate working blind, I follow the link in anticipation of getting something up and running in a jiffy

- and come to a grinding halt, as I encounter this header:

oUF 1.4

WTF ...

Er .... {censored!

} Project on halt!

An update of the wiki would be highly appreciated.

yj589794 · 10-19-10, 08:27 AM

Originally Posted by PingHansen

An update of the wiki would be highly appreciated.

The wiki has been a work in progress for some time now. The information on there is *mostly* up-to-date (although I've just seen some stuff I'll fix on there tonight).

The best starting point I can point you at are the example layouts Haste has made on how to use the oUF API:

oUF_Classic
oUF_Lily

Have a read through them as they will give you a good understanding of how the majority of oUF works.

10-19-10, 02:50 PM

Originally Posted by yj589794

I've just seen some stuff I'll fix on there tonight

Many thanks.

neverg · 10-19-10, 03:20 PM

haste, updated to the latest version and getting and error when Entering World:

Code:

Message: Interface\AddOns\oUF\ouf.lua:678: attempt to call method 'SetFrameRef' (a nil value)
Time: 10/19/10 22:16:55
Count: 1
Stack: Interface\AddOns\oUF\ouf.lua:678: in function `SpawnHeader'
Interface\AddOns\oUF_lumen\oUF_lumen.lua:2108: in function `func'
Interface\AddOns\oUF\ouf.lua:732: in function <Interface\AddOns\oUF\ouf.lua:728>
(tail call): ?

Locals: self = <table> {
 DisableBlizzard = <function> defined @Interface\AddOns\oUF\ouf.lua:181
 SetActiveStyle = <function> defined @Interface\AddOns\oUF\ouf.lua:495
 EnableFactory = <function> defined @Interface\AddOns\oUF\ouf.lua:742
 ColorGradient = <function> defined @Interface\AddOns\oUF\ouf.lua:368
 SpawnHeader = <function> defined @Interface\AddOns\oUF\ouf.lua:654
 RegisterStyle = <function> defined @Interface\AddOns\oUF\ouf.lua:485
 AddElement = <function> defined @Interface\AddOns\oUF\ouf.lua:751
 UnitlessTagEvents = <table> {
 }
 Factory = <function> defined @Interface\AddOns\oUF\ouf.lua:736
 RegisterMetaFunction = <function> defined @Interface\AddOns\oUF\ouf.lua:474
 Tags = <table> {
 }
 TagEvents = <table> {
 }
 DisableFactory = <function> defined @Interface\AddOns\oUF\ouf.lua:746
 objects = <table> {
 }
 error = <function> defined @Interface\AddOns\oUF\ouf.lua:18
 RegisterInitCallback = <function> defined @Interface\AddOns\oUF\ouf.lua:470
 colors = <table> {
 }
 version = "1.5.3"
 units = <table> {
 }
 IterateStyles = <function> defined @Interface\AddOns\oUF\ouf.lua:508
 Spawn = <function> defined @Interface\AddOns\oUF\ouf.lua:699
}
overrideName = "oUF_Party"
template = "SecureGroupHeaderTemplate"
visibility = "custom  [group:party,nogroup:raid][@raid6,noexists,group:raid] show;hide"
isPetHeader = nil
name = "oUF_Party"
header = oUF_Party {
 0 = <userdata>
 style = "lumen - Group"
 styleFunction = <function> defined @Interface\AddOns\oUF\ouf.lua:597
}
(*temporary) = nil
(*temporary) = oUF_Party {
 0 = <userdata>
 style = "lumen - Group"
 styleFunction = <function> defined @Interface\AddOns\oUF\ouf.lua:597
}
(*temporary) = "clickcast_header"
(*temporary) = CliqueHeaderFrame {
 0 = <userdata>
 WrapScript = <function> defined @Interface\FrameXML\SecureHandlers.lua:718
 SetFrameRef = <function> defined @Interface\FrameXML\SecureHandlers.lua:729
 Execute = <function> defined @Interface\FrameXML\SecureHandlers.lua:713
 UnwrapScript = <function> defined @Interface\FrameXML\SecureHandlers.lua:724
}
(*temporary) = "attempt to call method 'SetFrameRef' (a nil value)"
style = "lumen - Group"
error = <function> defined @Interface\AddOns\oUF\ouf.lua:18
generateName = <function> defined @Interface\AddOns\oUF\ouf.lua:540
select = <function> defined =[C]:-1
styleProxy = <function> defined @Interface\AddOns\oUF\ouf.lua:597
initialConfigFunction = "		local header = self:GetParent()
		local frames = table.new()
		table.insert(frames, self)
		self:GetChildList(frames)
		for i=1, #frames do
			local frame = frames[i]
			local unit
			-- There's no need to do anything on frames with onlyProcessChildren
			if(not frame:GetAttribute'oUF-onlyProcessChildren') then
				RegisterUnitWatch(frame)

				-- Attempt to guess what the header is set to spawn.
				if(header:GetAttribute'showRaid') then
					unit = 'raid'
				elseif(header:GetAttribute'showParty') then
					unit = 'party'
				end

				local headerType = header:GetAttribute'oUF-headerType'
				local suffix = frame:GetAttribute'unitsuffix'
				if(unit and suffix) then
					if(headerType == 'pet' and suffix == 'target') then
						unit = unit .. headerType .. suffix
					else
						unit = unit .. suffix
					end
				elseif(unit and headerType == 'pet') then
					unit = unit .. headerType
				end

				frame:SetAttribute('*type1', 'target')
				frame:SetAttribute('*type2', 'menu')
			getCondition = <function> defined @Interface\AddOns\oUF\ouf.lua:524

haste · 10-19-10, 03:29 PM

1.5.4 pushed

.

neverg · 10-19-10, 03:37 PM

Originally Posted by haste

1.5.4 pushed

.

Yep, seen you fixed it. Thanks!

Btw commented on EclipseElement (here: http://github.com/haste/oUF/issues/i...comment_479463) suggesting a Spark object.

Another thing... I've implemented the actual EclipseBar, but the statusbar are not moving the text (with the Tag) it's updating well, my fault or?

Regarding one of the latest patch commits (http://github.com/haste/oUF/commit/0...958399a00e9992) does this address this (http://www.wowinterface.com/forums/s...ad.php?t=30473) UnitSufix for pets? EDIT - Forget it, it does indeed address it. Using it now and it works well.

Thanks for your work, haste.

yj589794 · 10-19-10, 04:47 PM

Originally Posted by neverg

Another thing... I've implemented the actual EclipseBar, but the statusbar are not moving the text (with the Tag) it's updating well, my fault or?

There is no functionality in the eclisebar element to move the position of your tag, as the element does not know anything about the tags.

If you do want to do this, then add your own self.EclipseBar.PostUpdatePower function and move the tag in that function.

neverg · 10-19-10, 04:54 PM

Originally Posted by yj589794

There is no functionality in the eclisebar element to move the position of your tag, as the element does not know anything about the tags.

If you do want to do this, then add your own self.EclipseBar.PostUpdatePower function and move the tag in that function.

Ok, maybe I explained it wrong (most certainly did I forgot a comma, I ment: "but the statusbar are not moving, text (with the Tag) it's updating well".). The StatusBars are not moving, they are just static at half position both.

They Stay like this all the time:

yj589794 · 10-19-10, 05:31 PM

Hmm, not sure. Is this happening every time login/reset ui or just occasionally?

neverg · 10-19-10, 06:35 PM

Originally Posted by yj589794

Hmm, not sure. Is this happening every time login/reset ui or just occasionally?

Meh.. Forget it. I had the handlers wrong. Working fine now.

I had this:

eBar.lBar = LunarBar
eBar.sBar = SolarBar

And it's this:

eBar.LunarBar = lBar
eBar.SolarBar = sBar

zork · 10-21-10, 02:30 AM

I have a question regarding the FrameStrata of the self object. I noticed that the FrameStrata is very high by default, even higher as the chat. Adding FrameStrata to my init func fixed it though. Not sure if that is intended.

Code:

  --init parameters
  initUnitParameters = function(self)
    self:SetFrameStrata("BACKGROUND")
    self:SetSize(self.cfg.width, self.cfg.height)
    self:SetScale(self.cfg.scale)  
    self:SetPoint(self.cfg.pos.a1,self.cfg.pos.af,self.cfg.pos.a2,self.cfg.pos.x,self.cfg.pos.y)
    self.menu = func.menu
    self:RegisterForClicks('AnyDown')
    self:SetScript("OnEnter", UnitFrame_OnEnter)
    self:SetScript("OnLeave", UnitFrame_OnLeave)
    --func.createBackdrop(self)
    func.applyDragFunctionality(self)
  end

Once I added the line all frames anchored to self behaved like I wanted them.

Sth. in my head remembers me that this (adding framestrata) may cause problems for units spawning in combat...but not sure.