which addon caused this error?

[merlight]

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?

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...

[votan]

Originally Posted by merlight 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? 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.

Hehe, thanks.

Well, we can not hook AddMenuItem, as it would make all code paths "in-secure". So, build-in menu entries must look as they do now.
I will try some things at weekend.

Back to QuadroTony's error:
Does it happen, if MM is not active, too?

[sirinsidiator]

I started to tinker around with LibCustomMenu.

It's showing the submenu, but you can't interact with it yet, because it disappears once the mouse leaves the entry on the main menu.

[merlight]

libraries/zo_contextmenus/zo_contextmenus.xml

<!--
    TODO: ZO_Menu needs to become virtual and be reparented to ZO_Menus to enable
    nesting.  This is just a quick first pass.
-->

I wonder if that's still on TODO

[QuadroTony]

Originally Posted by votan Back to QuadroTony's error: Does it happen, if MM is not active, too?

i probably cant test because error persist only till /reloadui
and if i meet it again, and go and turn off MM i will need reloadui after it, error will gone anyway

[sirinsidiator]

Nested menus rule. Love it already

[votan]

Hi guys,

I released LibCustomMenu v2.0.
Big thank to everybody

[QuadroTony]

hmmmm

new for me



when alt+enter game window from fullscreen to windowed mode

[QuadroTony]

and this one on the PTS while buying DLc in the crown store

looks like ZOs issue too