oUF - General discussion

[grimman]

Originally Posted by haste Fixed on git.

New bug found! :P
self.Name:SetText(UnitName(unit)) in my updateName function does not display the correct text for tapped mobs. So far I've only checked dead+tapped mobs, so I'm not sure living+tapped mobs display the same behavior.
The fontstring has the value of the last mob targeted.

The colouring done in the same function works nicely though.

Edit: Tested using version 1.3.0 as well as version 1.3.1.

[haste]

There is no .Name element in oUF anymore, so you have to handle all the updating yourself. Take a look at how Lily does this for example.

I don't set any OnShow update in Lily however, since the function is called from the UNIT_HEALTH function.

[grimman]

Originally Posted by haste There is no .Name element in oUF anymore, so you have to handle all the updating yourself. Take a look at how Lily does this for example. I don't set any OnShow update in Lily however, since the function is called from the UNIT_HEALTH function.

AHA, you had snuck an event in inside the updateHealth function too. :P
Since my layout is based on your Lily layout the code is practically identical in some places. Thanks once more!
Any performance difference between using this method and using tags?

[wcshadow]

sorry im not very knowledgable in lua, but is there a way to port, oUF D3Orbs to 1.3.x , so i can get the names of myself and the mobs to show again

[haste]

Originally Posted by grimman Any performance difference between using this method and using tags?

I haven't done any benchmarks, so I can't give you any numbers. It will be slower than writing the updating yourself.

[Kellen]

I get the following error whenever something AURA related happens (self buff, eating, debuff):

ouf.lua:94: Attempt to call field '?' (a nil value)

I see the warning, but it doesn't seem to have any ill effects. Even if I remove all of my Aura handling code, it still shows up.

I hesitate to file a bug report because other than the warning, nothing seems wrong.

This seems to fix it:

if (self[event]) then
  self[event](self, event, ...)
end

Dunno if that fix has any bad consequences, but I haven't seen any so far.

[Celil]

with the update today (1.3.1) i got this errormessage every time if something changes in the UnitFrames (e.g. joining party, hp-loss, etc):

oUF\ouf.lua:94: attempt to call field '?' (a nil vlaue)

Anyone an idea where this bug come?

[haste]

Originally Posted by Kellen This seems to fix it: if (self[event]) then self[event](self, event, ...) end Dunno if that fix has any bad consequences, but I haven't seen any so far.

You'll want to add a print if it can't find the event there. It's your layout registering an event, but not setting any handler on it.

Originally Posted by Celil Anyone an idea where this bug come?

See above.

[Celil]

I should get used to reading all posts, thanks a lot

[p3lim]

Originally Posted by haste You'll want to add a print if it can't find the event there. It's your layout registering an event, but not setting any handler on it. See above.

Add an detailed error print to that event handler by default, it would ease up the mess on these forums.

I have one, but I added that myself

[Blood Druid]

Originally Posted by haste .__elements is used for OnShow updates of the frame. :RegisterEvent() is used for ordinary event handling. I don't use .__elements in oUF_Lily, because the UNIT_HEALTH function will make the OnShow call for me.

ок, it is clear, I spoke that there is no sense to call function of show of name UNIT_NAME_UPDATE as UNIT_HEALTH update, i.e. it is not necessary to refresh so often UnitName...
I am am disturbed by additional load

Such question:
if to make so in Style

local UnitDraw = function (self, unit)
.....
self:RegisterEvent (' UNIT_NAME_UPDATE ', updateName)
table.insert (self. __ elements, updateName)
.....
end


or


local updateHealth = function (self, event, unit, bar, min, max)
....
self:UNIT_NAME_UPDATE (event, unit)
...
end

local UnitDraw = function (self, unit)
.....
self:RegisterEvent (' UNIT_NAME_UPDATE ', updateName)
.....
end


it too most?

[haste]

In Lily I make a call from UNIT_HEALTH to UNIT_NAME_UPDATE because I have the named colored gray if the unit is tapped. This isn't needed in most other cases however.

[Blood Druid]

Originally Posted by haste In Lily I make a call from UNIT_HEALTH to UNIT_NAME_UPDATE because I have the named colored gray if the unit is tapped. This isn't needed in most other cases however.

I have already understood it, simply I ask as more correctly to make as in the first case or how in the second?

[haste]

It depends on how often you would want to update the name. The first solution will make it only update when the event fires, or when the frame is forced to update all elements (OnShow). While the second solution will update it every time the health changes for the unit, and when the frame is forced to do a full update.

[Mordog]

Originally Posted by haste You'll want to add a print if it can't find the event there. It's your layout registering an event, but not setting any handler on it. if (self[event]) then self[event](self, event, ...) end See above.

can someone tell me were to add this?

[haste]

Originally Posted by Mordog can someone tell me were to add this?

if (self[event]) then
  self[event](self, event, ...)
else
  print(string.format('Object %s (%s) attempted to call event [%s], which has no handler.', tostring(self), tostring(self.unit), event))
end

[p3lim]

Originally Posted by haste if (self[event]) then self[event](self, event, ...) else print(string.format('Object %s (%s) attempted to call event [%s], which has no handler.', tostring(self), tostring(self.unit), event)) end

Please add that as a default

[haste]

Maybe, but most likely no.

[Mordog]

works, no message in the chatframe. thank you

[Blood Druid]

Originally Posted by haste It depends on how often you would want to update the name. The first solution will make it only update when the event fires, or when the frame is forced to update all elements (OnShow). While the second solution will update it every time the health changes for the unit, and when the frame is forced to do a full update.

Thanks Haste, the answer settling that it was required to understand

by the way are a new problem:
with vehicle, if in combat to quit from vehicle that units do not vary back, i.e. "player" remains "pet"

as it to correct?