Doing everything via OnUpdate?!

[zork]

I'm completly baffled by seeing this:

<GuiXml>
	<Controls>
		<TopLevelControl name="AddonName">
			<OnUpdate>
				AddonOnUpdate(self,time)
			</OnUpdate>
		</TopLevelControl>
	</Controls>
</GuiXml>

So from my understanding what currently some of the addons do is they use an OnUpdate function to simply do everything. To make it not freeze up your entire machine a buffer is set in place throttling the whole process.

What is wrong with doing this by event handlers?

Coming from the WoW API what I would do is init my basic frames and register some specific events to do stuff for me. There has to be unit specific or aura specific events right?
Is that because people don't know which events to use right now?

So here is what I would do.

1. Create a basic addon frame and register EVENT_LOGIN_SUCCESSFUL and/or EVENT_ADD_ON_LOADED
2. If my addon is loaded and I have access to my variables I set up my basic frames
3. After that depending on purpose of my addon I would register matching events with certain OnEvent functions to do stuff for me.

Do not use OnUpdate for everything in your addon. This is really bad imo.

Use event handlers! ESO events: http://wiki.esoui.com/Events

If you need XML to initialize your addon do this:
(it may be possible that this is obsolete if you register the addon loaded event)

<GuiXml>
    <Controls>
        <TopLevelControl name="AddonName">
            <OnInitialized>
                AddonOnInitialized()
            </OnInitialized> 
        </TopLevelControl>
    </Controls>
</GuiXml>

A really good example of how to work with event handlers can be seen in the code of DragonLoot.
http://www.esoui.com/downloads/info1...LootAddon.html

What I have not wrapped my head around yet is the event registering itself. DragonLoot uses two types of event registering. One on a global event manager and the others for the addon itself which seems to part of the global namespace after init.

local manager = GetEventManager()
manager:RegisterForEvent("UniqueEventIdentifier", EventName, OnEventFunction)
AddonName:RegisterForEvent(EventName, OnEventFunction)

Currently I'm not sure if you have to do it exactly that way. But it may be the case.

What you should be able to do aswell is unregistering of events. Like:

local manager = GetEventManager()
manager:UnregisterForEvent("UniqueEventIdentifier", EventName)
AddonName:UnregisterForEvent(EventName)

What would really help if we could access to the default ESO addons. Basically the Lua+XML files of the "EsoUI" folder that is packed in game0000.dat. It would help a ton.

Actually I have access to all of those files now but I doubt that we are allowed to post them to Github for code review. Or are we? It would be such a great help for learning how to write ESO addons.

[Wykkyd]

Far from the truth. Many addons use OnUpdate, yes. Many of those same addons also track individual events very specifically. It greatly depends upon what you're watching and what you're updating. An on-screen clock, for example, needs to update minimum once per second... which is best done in OnUpdate. The toolbar options I have available in Framework mostly update via OnUpdate to grab zone changes, currency changes, xp/vp/ap totals, etc. It does quite a bit every tic so that the data on screen is always fresh without having to peg individual updates onto 3 or 4 dozen specific events.

Still other parts of that same addon, and same feature, track data on specific events like... gaining experience and putting the number into scrolling on-screen text. The initial update to that screen text is done via normal event triggers. The scroll is facilitated via OnUpdate tics with no buffer.

... in other words each kind of event has its purpose.

[Seerah]

Yes, of course a clock would use an OnUpdate script as there is no event fired for the time changing.

The toolbar options I have available in Framework mostly update via OnUpdate to grab zone changes, currency changes, xp/vp/ap totals, etc.

There are events that fire for all of these things. You don't need to use OnUpdate. This causes your code to run MUCH more than needed. In theory, one should never use OnUpdate when an event is available.

I'm going to repost most of what I wrote on the pts forum for others to read.

If an event fires more often than you need, you should "code smarter, not harder". ... Events fire in response to things happening in the game. You have to register for each one you want to use, and call relevant code accordingly. Some events may fire often, others rarely. OnUpdate scripts run on each OnUpdate - this means on every frame draw. So, if your framerate is 35fps, this means that your screen is being drawn 35 times per second. The higher framerate you have, the more often your OnUpdate script will run. The OnUpdate script handler passes the control as the first arg, and the time of the update as the second arg. This is how I only bother with running my script every so often: local timelastrun = 0 control:SetHandler("OnUpdate", function(self, timerun)      if (timerun - timelastrun) >= 1 then     --change 1 to however long you wish your delay to be (1, 2, 0.5, 0.1, etc)           timelastrun = timerun           --do stuff      end end) When a frame (control) is hidden, its OnUpdate script ceases to fire. This is an easy way to start/stop your OnUpdate script.

Also, Wykkyd, I believe you're still calling OnUpdate scripts events. They are not.

[Wykkyd]

In theory, one should never use OnUpdate when an event is available.

Yes, in theory. But keep 2 things in mind:
1 - There are times when it's actually more efficient to use OnUpdate. For example in my WarTools addon the Cyrodiil events actually fire too fast and I need the same data regardless of the event that fires. So... I just parse OnUpdate with a 3 second buffer and it actually results in the process running less often.

2 - The Toolbar we've both used as an example I inherited. Some of which will be rewritten in the future but the updates that are occurring there are so tiny it's not very high priority.

[zork]

Ok just to make sure I am misunderstood.

Anyone can do whatever he wants. There is no right way but your way.

I was just curious because in the first addons I checked I found no event handlers. That cleared up shortly thereafter.

Anyone can have their mind on how he wants to solve a computing problem.