| |
OK, while coding a bit the other day, and working with the Drop Down Menu, I stumbled some annoyances with it, that I'd like to address.
First of all, the UIDropDownMenu_SetWidth() function.
By looking through the code, it sets the width of the control, and then set a variable:
frame.noResize = 1;
What you'd expect, is that this changes the way the dropdown menu works, so that it's always the same width, no matter the context. But this is not true. The variable noResize is used nowhere. You might think it's used in the UIDropDownListTemplate OnShow code, but no, that's the DropDown#.noResize - a variable never set anywhere, never copied from the frame.noResize. In other words, the OnShow code for DropDown# is doing nothing, the list is always resized to fit the largest item.
Currently, I'm using a work-around for this, by adding:
DropDown1.maxWidth = xxx;
to my drop down init function (the one with the UIDropDownMenu_AddButton() calls). But this is a workaround, that should not be neccesary, since they functionality is already present in the Blizzard code, but for some reason, not finished. Also, it will only work to make the list wider than it already is.
Another thing I noticed, when comparing the 1.6.1 and 0.7.0 code, was the added UIScale to the list in ToggleDropDownMenu(), always applying the global UIScale, or 1.0 if the dropdown menu was from the world map. Why not just add a function to set the scale, or just use tempFrame:GetScale(), which would remove this ugly hack:
if (tempFrame ~= WorldMapContinentDropDown and tempFrame ~= WorldMapZoneDropDown)
in an otherwise clean code, free for hardlinked references. By using tempFrame:GetScale() or adding a method to specify it, coders can also easily specify their own scale.
Again, work-around for custom scale, is DropDown1:SetScale(xxx); in the drop down init code (or DropDown2, DropDown3, depending on menu-level).
It's just some small annoyanced, with work-arounds, but there shouldn't be a need for these work-arounds
Maldivia <Cynosure>, Sargeras
|
