Jumping chatframe

[Greencap]

I'm having some difficulties positioning my chatframe. I am using Ace3 and in the OnEnable of a module I am repositioning the chatframes. This works well on every reloadui and it also works well in most of the login attempts, however on some login attempts it is slightly off. I cannot figure out what I am doing wrong. Does anyone have any ideas?

function Module:OnEnable()
	self:SetupChat()
	print("test")
end

function Module:SetupChat()
	self:SetDefaults() -- Sets the default channels, etc 
	... -- Some code that removes some blizzard frames
	for i = 1, NUM_CHAT_WINDOWS do
		self:SetupChatFrame(_G["ChatFrame"..i]) -- Repositions the chatframe (if it is the first one)
	end
end

I am calling FCF_SavePositionAndDimensions(frame) and frame:SetUserPlaced(true). I confirmed that the function is being executed by using the print statement. The strange thing is that in setDefaults I'm calling FCF_ResetChatWindows, which is seemingly being executed as the global channels have been reset (as you can see in the incorrect screenshot), but none of the other code seems to work including joining the correct channels again.

The correct look: http://imgur.com/DVTvqr5
The incorrect look: http://imgur.com/mm21C3z

Thanks for the help!

[Phanx]

Originally Posted by Greencap I am calling FCF_SavePositionAndDimensions(frame) and frame:SetUserPlaced(true).

Great, where is that code? It's impossible for us to debug code without being able to see it. Posting random snippets is just useless.

[Greencap]

Hi Phanx, sorry I thought it was something glaringly obvious as I'm still new to this. Please refer to this link to find the code: http://pastebin.com/d0iN596f

[Phanx]

I wouldn't bother trying to get the client to handle the positioning, as your addon is overwriting the positions every time you log in anyway. Just use ClearAllPoints and SetPoint to put the chat frame where you want it, and skip all the SetUserPlaced and FCF_SavePositionAndDimensions stuff.

Alternatively, try getting rid of just the SetUserPlaced call. That's already called (conditionally) by Blizzard's code in FCF_RestorePositionAndDimensions, and calling it unconditionally in your code may be interfering with how the game client is saving the frame position.

[Greencap]

I will try it again when I am at home. I do remember that the way you suggested is how I actually started in the first place (I only found out about these functions later). I noticed that without them the positioning was way worse.

I'm guessing that I am either running this code too soon or too early and some other blizzard code is interfering. I'm just not sure what.

Is there an easy way to enforce my code to run after blizzard's code has run?

[Phanx]

An easy way that works for any and all Blizzard code? No. It depends on what you're trying to do. If you're overriding something that happens in the main chunk or in an OnLoad script, then you're already doing that, as all such code has already run before your addon is loaded.

If you're overriding something that happens in response to an event (eg. PLAYER_ENTERING_WORLD) then you should post-hook the Blizzard UI function that you want to override (eg. FloatingChatFrame_OnEvent) and run your code after the original function, since simply registering for the same event doesn't guarantee that the Blizzard event handler will run before yours.

Reading the default UI code for the part of the UI you're trying to modify is usually a good starting point -- look at the OnLoad scripts (in XML) and which events are registered, and look at which functions are called from those places.

Back on the original topic, you may want to try removing the clamp insets on the chat frames. Clamp insets let you specify a region that must stay on-screen that's larger (or smaller) than the actual frame, so if the chat frame has a bottom clamp inset of -50px, then the bottom edge of the chat frame can't be moved any closer than 50px from the bottom edge of the screen.

chatFrame:SetClampRectInsets(0, 0, 0, 0)

[Greencap]

FloatingChatFrame_OnEvent got me in the right direction. I'm not convinced yet it is the perfect way to do it, but it seems to work. I am now using the PLAYER_LOGIN event to call SetupChat and in the PLAYER_LOGIN event I also register to the UPDATE_CHAT_WINDOWS event (no need to do it earlier than PLAYER_LOGIN). In the event handler for UPDATE_CHAT_WINDOWS I call RepositionChatFrame.

The one thing that makes me wonder if it is correct is that I notice that I do not see the guild message of the day in the rare cases where I end up in the UPDATE_CHAT_WINDOWS event handler on login.

Thanks for the help!

[Phanx]

Originally Posted by Greencap The one thing that makes me wonder if it is correct is that I notice that I do not see the guild message of the day in the rare cases where I end up in the UPDATE_CHAT_WINDOWS event handler on login.

Several things can clear the contents of the chat frame, eg. changing the number of history lines. You don't do that in your code, but you do call FCF_ResetChatWindows() which I would guess clears all chat frames.

[Greencap]

That's exactly what I thought as well, which is why I made the code as follows:

function Module:OnInitialize()
	self:RegisterEvent("PLAYER_LOGIN", function()
		self:SetupChat()
		self:RegisterEvent("UPDATE_CHAT_WINDOWS", function()
			for i = 1, NUM_CHAT_WINDOWS do
				self:RepositionChatFrame(_G["ChatFrame"..i])
			end
		end)
	end)
end

It still clears the guild message of the day sometimes. I can live with that though.

[Phanx]

That won't help, as PLAYER_LOGIN is what triggers OnEnable for AceAddon addons anyway. Try calling most your code from the main chunk, outside of OnInitialize/OnEnable. Use those only to run the parts that actually need your parent addon's saved variables to be loaded, like the font size.

[Greencap]

I actually moved it to the OnInitialize function. As far as I understood this is triggered before PLAYER_LOGIN (basically immediately after all addons have been loaded). OnEnable seems to be triggered after PLAYER_LOGIN (I'm guessing the first occurence of PLAYER_ENTERING_WORLD).

You are right though, it doesn't add anything at all to use those functions. I don't care about disabling modules anyway.

[Phanx]

OnInitialize is called in response to the next ADDON_LOADED or PLAYER_LOGIN event that fires. In most cases, this will be the ADDON_LOADED event for your addon.

OnEnable is also called in response to the next ADDON_LOADED or PLAYER_LOGIN event that fires, but only if you are already "logged in" -- eg. the event is PLAYER_LOGIN, or PLAYER_LOGIN has already fired and your addon was loaded on demand afterwards -- and all addons have already had been initialized. In most cases, this means your OnEnable will get called when PLAYER_LOGIN fires.

AceAddon is actually quite well documented with comments, and the code is fairly easy to follow, so I'd encourage you to take a look through if you plan to use it much. It doesn't even register PLAYER_ENTERING_WORLD.