Originally Posted by circonian
What about just just preventing the problem at the source. Stop using the right click context menu, and instead add an icon/button or something to each row entry that would pop-up our own custom context menu created with a library that could be shared, for use with all addons. Or Instead of adding a new button to the row just use the item icon that is already there as our button. Or just make it a left click context menu.
Either way then all of the code is our own. This would completely work around the secure code problem.
|
I like your pool hack more
This would be adding another UI element, and I can already see myself hovering over an item and thinking: "Is the thing I want to do in the core menu or an add-on?"
The whole menu interface looks very... old... like from before there was a class for ZO_Anything.
How about passing an optional object pool key to AddMenuItem?
Lua Code:
function AddMenuItem(mytext, myfunction, itemType, myfont, normalColor, highlightColor, itemYPad, itemKey)
local menuItemControl = ZO_Menu.itemPool:AcquireObject(itemKey)
You can use a string key with add-on name + some suffix, AcquireObject will create one object for that key and always return that one. That way you won't "steal" a secure menu item. Don't know if we can hook AddMenuItem and not break everything, in which case this parameter would've to be added by ZOS.
Edit: nevermind, this wouldn't work even if AddMenuItem could be hooked. AcquireObject() without a key would "steal" named ones...