Originally Posted by kurapica.igas
For now, there is only one data provider with Label field. Never mind, Theroxis is talking about my addon EnhanceBattlefieldMinimap, the area label is created in it, so in the newest version, a setting is already given for the labels.
Back to the hooking data provider, since there is no action button on the world map, it's safe to just replaced them with our own codes, I replaced some of them to reduce the memory increment, like :
Lua Code:
local viewRect = CreateRectangle(0, 0, 0, 0) BattlefieldMapFrame.ScrollContainer.CalculateViewRect = function (self, scale) local childWidth, childHeight = self.Child:GetSize() local left = self:GetHorizontalScroll() / childWidth local right = left + (self:GetWidth() / scale) / childWidth local top = self:GetVerticalScroll() / childHeight local bottom = top + (self:GetHeight() / scale) / childHeight viewRect:SetSides(left, right, top, bottom) return viewRect -- the origin: CreateRectangle(left, right, top, bottom) end
Unfortunately, waste comes from the APIS can't be done.
If we need use the hooksecurefunc, the target should be the object created from the CreateFromMinxin, like(The Label has a Mixin named AreaLabelFrameMixin) :
Lua Code:
local areaLabelDataProvider = CreateFromMixins(AreaLabelDataProviderMixin) BattlefieldMapFrame:AddDataProvider(areaLabelDataProvider) hooksecurefunc(areaLabelDataProvider.Label, "SetLabel", print)
|
Learning from/with you while tweaking and improving your addon is fantastic. Thanks for being so responsive! Hopefully I can get to a point where I'm helping more than just having you add features! LOL
Originally Posted by p3lim
As a sidenote, there are discussions on how to improve hooking into the providers of a canvas-based map frame, and one of the suggested solutions is being able to query by mixin name. Feel free to chime in with alternate suggestions.
|
Personally (from other development in languages not as foreign to myself as lua) I typically expect things that behave like the dataproviders do to put things into categorically appropriate arrays (tables, for lua, I guess?) for ease of integration.
Using this case as an example, instead of the DataProvider completely omitting the name field, it should create a new child variable of the parent frame:
*MapFrame.AreaLabelMixin
And then that should provide child elements for different properties; in this case:
*MapFrame.AreaLabelMixin.Label[#]
This avoids the case of having random ID's floating around in memory and relying on costly iterative conditional logic.
Basically following Object Oriented Philosphy, any time a function adds variables into the memory map it should behave like a class does, and expose those variables appropriately so they can be addressed in a human manner. It prevents confusing situations down the road, too. Obviously this would have to be implemented by Blizzard, and in some cases may not be appropriate - the pins for various nodes for example. Maybe have the parent table have names and then have the children have random ID's since that data is more or less going to be random regardless.