Current Addon issues

[Smacker]

After getting my addon running in the beta I have noted the following issues:

1. Global variable this has vanished (I think this is a documented change)
2. The Blizzard Feedback interface is throwing lua errors
3. Texture:SetTexture() always returns 1 even if the operation failed

All in all not too bad

[IQgryn]

I've also noticed that all anchor offsets (at least in xml) now require both x and y coordinates (it would default the unspecified one to 0 previously).

There's also something fishy going on with positioning that I'm still tracking down. All my frames that are positioned relatively to their peers seems to gather in a heap at the bottom of their container. Looks fun, but not quite what I'm going for.

[Monolit]

I noticed that CancelUnitBuff() now only available for BlizzardUI
So you can spawn your buffs with oUF, but can't right click cancel them

[yj589794]

Originally Posted by Monolit I noticed that CancelUnitBuff() now only available for BlizzardUI So you can spawn your buffs with oUF, but can't right click cancel them

This doesn't just affect oUF, anything that handles buffs is going to be affected. The secure handlers look to be a work-in-progress at the moment.

There is a new secure template for auras, but it is not visible yet. Best to wait a while before looking at that stuff.

[MysticalOS]

i haven't been able to figure out why dbm has invisible text in GUI in beta. there are no frame or lua errors at all. text is just invisible.

I do however get an error from trying to use scroll wheel


9/3 21:18:47.969 Frame DBM_GUI_OptionsFramePanelContainerFOVScrollBar: Unknown script element OnVerticalScroll

Error occured in: Global
Count: 5
Message: [string "DBM_GUI_OptionsFrameBossMods:OnMouseWheel"] line 2:
attempt to compare number with nil
Debug:
[C]: ?
[string "*:OnMouseWheel"]:2:
[string "*:OnMouseWheel"]:1

haven't been able to find any docs on that api change yet

[IQgryn]

Originally Posted by IQgryn I've also noticed that all anchor offsets (at least in xml) now require both x and y coordinates (it would default the unspecified one to 0 previously). There's also something fishy going on with positioning that I'm still tracking down. All my frames that are positioned relatively to their peers seems to gather in a heap at the bottom of their container. Looks fun, but not quite what I'm going for.

The fishy positioning is actually due to the same thing, but with sizes. Essentially, every AbsDimension must now use both x and y coordinates, even if one of them is made redundant with anchors.

I think they changed the default value from 0 to "fill your parent container". Again, this is from xml files. I'm not sure if you can even specify one coordinate without the other in lua.

[SDPhantom]

In my experience, the Lua code requires both offsets if you're specifying one.

[Pup]

Thought i'd mention a small change that I had noticed with my addon from WotLK to Cata beta that was causing me a few headaches to debug. The dropdown's on my options panel were all defaulting to 'Custom' even though that wasn't an item in the list.

Eventually I found that it was down to my initialisation code on load :

    UIDropDownMenu_SetText(MyDropDownFrame, "Selected Option");
    UIDropDownMenu_SetSelectedValue(MyDropDownFrame, "Selected Option");

I had a sift through the cata blizz interface that seemed to work fine, and noticed that these were called the other way around, so simply changing the above to :

    UIDropDownMenu_SetSelectedValue(MyDropDownFrame, "Selected Option");
    UIDropDownMenu_SetText(MyDropDownFrame, "Selected Option");

fixed my issue, and showed the correct text.

I noticed that blizzards own addon selection frame shows 'Custom' for the 'Configure Addons For:' dropdown, so also appears to have this problem.

[dr_AllCOM3]

One of my addons is causing WoW to hardlock.
I guess it's my nameplates. It happens on a mouseover in Throne of the Tides at the first pack, but only when I use the LFG tool.

[BDelacroix]

The trouble I am having is with button texture sizes. The button active area seems to be fine, the pushed texture is the right size, its just the normaltexture that is insisting on being large. Like clown shoes size.

I'll add in the button creation code here so someone can show me that I'm being stupid or that yes indeed its broken.

I find it interesting that even if I explicitly set a scale for the button, it ignores me. If I comment out the setwidth/height it remains the same.

Basically, the below checks for the existence of a button. If it exists, just grab its width and height. If it doesn't exist, make one and make its width and height a little smaller (20% smaller) than standard.

if trap_b[t]==nil then
			trap_b[t] = CreateFrame("Button","trapper_button"..t,trapper,"ActionButtonTemplate,SecureActionButtonTemplate")

-- Gather its width and height because the textures are larger than the button as given
-- this way we can set those sizes right and make all the other buttons match the size	

			W = trap_b[t]:GetWidth()*.8
			H = trap_b[t]:GetHeight()*.8
		else
			W = trap_b[t]:GetWidth()
			H = trap_b[t]:GetHeight()
		end

-- Set type and spell for each state
		trap_b[t]:SetAttribute("type","spell")
		trap_b[t]:SetAttribute("spell",trap_n[t])

-- Set the image for the button
		trap_b[t]:SetNormalTexture(trap_i[t])
		trap_b[t]:SetPushedTexture(trap_i[t])

		trap_b[t]:SetWidth(W)
		trap_b[t]:SetHeight(H)
		
		trap_b[t]:GetNormalTexture():SetWidth(W)
		trap_b[t]:GetNormalTexture():SetHeight(H)

		trap_b[t]:GetPushedTexture():SetWidth(W)
		trap_b[t]:GetPushedTexture():SetHeight(H)

[Zensunim]

Originally Posted by dr_AllCOM3 One of my addons is causing WoW to hardlock. I guess it's my nameplates. It happens on a mouseover in Throne of the Tides at the first pack, but only when I use the LFG tool.

This may not be an add-on. This happened quite frequently with the default UI on the previous build when using the LFG tool. I haven't run any dungeons yet on this build, though. Perhaps someone else can elaborate more.

[BDelacroix]

As an "answer" to my own query, in the case that someone else may have a similar problem, I have found a way around it.

Actually it may be a more elegant solution than I had been using all through the last two expansions.

First, I removed the inheritance of the ActionButtonTemplate from the button frame. If I have that inherited, the normatexture is huge. No idea why, it wasn't like that in the last two expansions.

Unfortunately doing that means there is no automatic handling of the pushed texture or creation of a cooldown frame.

You can manually create a cooldown frame derived from CooldownTemplate and make the button a parent. That neatly fixes that. Append "Cooldown" to the button name and you can manage it in the same generic manner as before (c=_G[name.."Cooldown"] etc.)

I'll have to futz around getting a pushed texture functionality. That doesn't exist for generic secureactionbuttons apparently so my buttons are flat.