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?

self.disallowVehicleSwap = true

This will stop the vehicle/player swapping. It may not be the solution you're looking for, but until what you described has been fixed (if it is indeed a bug) this may be your only option. I never took the time to check it out in-depth, because I don't even want vehicle swapping in my layout.

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?

I've updated to 1.3.1 and I'm getting this error also and I've been trying for hours to get rid of it but nothing seems to be working. For me it is only happening during raids and when im solo or party its fine.

!BugGrabber is my only way of stopping the error and it doesnt seem to cause any other ill affects so I was hoping the print error trap that P3lim suggested would work but when I add that code the unit frames just dont show at all and I get the default UI frames for some reason.

Can someone please tell me how I can go about fixing this in laymans terms as I've read this thread back to front and still am no clearer on how to fix it. I know you guys (haste, p3lim etc) are rolling your eyes thinking "what a noob go work it out yourself" but I wouldn't be asking for help if I didnt need it so please explain the problem, whats happening and how I fix it.

oUF is a brilliant unit frame but sadly everytime it updates my Unit Frames just start erroring and there is little in the way of documentation etc telling me what I should do and the changes to the code I should be making.

-- Events
local OnEvent = function(self, event, ...)
if(not self:IsShown() and not self.__unit) then return end
self[event](self, event, ...)
end

change it to

Code:

-- Events
local OnEvent = function(self, event, ...)
if(not self:IsShown() and not self.__unit) then return end
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), even))
end
end

Most of the errors people see is because they update oUF before the layouts have been updated. This is probably due to there being a lot of confusion about layout compatibility between oUF releases.

The current versioning scheme is: a.b.c, and the current version is 1.3.1.
a - major version - this will probably never change, unless the entire layout system is replaced with something else.
b - minor version - acts as an indicator of what changes have been made to the API. This is changed when I make an internal change which will break with current layouts.
c - maintenance version - bug fixes made to the core, which are backward compatible with previous versions.

Based on this we've basically had three versions which have broken layouts since August 2008. In most cases it might not seem that a lot has happened on the back-end, but here's the diff stats between every minor version:

It was probably especially bad with this release, as the event system and element system got a complete rewrite, while mostly maintaining "compatibility" with previous versions. In many cases you could just use oUF 1.3.x on a 1.2.x layout, without getting any errors, at least at first.

My guess is that many of the layout authors just have done some minor testing, and thought "hey, this works! *release*". The line 94 error that most people have at is an indicator of this being the case. It happens because people just registered events, assuming that the event handlers would always be in the oUF table. In 1.2 and earlier the elements just forced themselves into the core table, and acted as a event fallback for all oUF objects, while in 1.3 they are hidden away until registered on a object.

I wanted to get some error checking in before I made the 1.3 release, but in the end I had to make a choice between releasing 1.3 as is, or delaying it yet another week. I announced on the forum that I wanted to have it released by the 15th December, but that was delayed until 21st due to time restrictions.

-- Events
local OnEvent = function(self, event, ...)
if(not self:IsShown() and not self.__unit) then return end
self[event](self, event, ...)
end

change it to

Code:

-- Events
local OnEvent = function(self, event, ...)
if(not self:IsShown() and not self.__unit) then return end
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), even))
end
end

That should fix the error

That's not a fix at all. It will only print a error when a layout is doing something wrong.

I need to say a big thankyou to Haste and Mordog for these responses both detailed and information so thank you guys!

Ok so problem is solved ... well not entirely but I'll explain.

When I put in the code with the print I got the error message pop up basically saying there is a problem with UNIT_AURA. Now these is a bit of redundant code I had in my layout which has never worked and I've never got round to fixing it. I had intended to use the oUF_DebuffHigh module and I had some code in my layout for it but it never worked as intended. This code was only in the raid frame and therefore only popped up when I got into a raid. So problem found thank the lord eh!

Hence 2 work arounds, one rip out all the code in my layout for Aura's and debuff hightling which isnt a bad thing as it doesn't work anyway or put in a handler for it which is what I did as when I get chance I'll still try and fix the debuffhighling. So I added the below line

the layout are bottom and i cant move them.
is this general discussion right ?

It's the same answer anyway. Moving is done through the code for most layouts. Which means this is completely layout dependent. oUF itself doesn't and will not provide any in-game options because layouts can solve and modify behavior as they like.

There really isn't any straight forward way to hook with the new event system. You can however just register the event with a function parameter, and oUF will place it afterwards in the call rotation. It's just a post-hook however, nothing more.

Replacing the function isn't really recommended as oUF uses this to handle unregistering of events tho'.