Didn't know that if I do


Code after will be executed anyway ..

I'll upload and test. Think it's SuperStar and Kill Counter which are only using the library for now.

It depends on the loading order. You may lucky or not :)
It works like this:
Every embedded lib tries to register itself as the newest. The first (not the newest) is newer than nothing, second may newer as the first or not, and so on.
After all addons are loaded, the functions of the newest are registered.
Any code execution before the EVENT_ADDON_LOADED events get triggered, can cause trouble.
LibAddonMenu before r17 had the same problem.

yes its kill counter
i update it today and got this

Well, I've updated it. It's now initialized on 1st addon call.

still get it sometimes after load a hero

if there is no error before, (you can check it with interface.log), it's often an xml problem.

hehe long time no seen
too many anchors =)

i know its smthing in JunkIt

happends only once
when i:
alt+enter to make game windowed
win+shift to move to other monitor
alt+enter to make game fullscreen windowed again

That sounds like it is coming from LAM. I'll have a look while I am at it. The new version r18 is nearly ready ;)

hmmm
wtf?

This happens if an insecure code path creates a menu entry which is then re-used by the ingame UI. We now create 10 secure ones on startup to prevent this, but you have 13 menu entries. We can bump this up to a bigger number like 30 to handle bigger menus.

Maybe it's time to make a library for a secondary level in context menus?
Placing more than 7 entries in one menu is bad UI practice.

Thats a great idea!

Thank You Chip! This helps alot.

Yes, I agree to sirinsidiator and circonian. If there are more than 10 menu entries on the first level, one starts to seek with the eyes up'n'down just to click there the mouse pointer is already :D:rolleyes:
On the other hand, we must be careful, that it does not end up in a first level menu with two entries and a second level menu with two entries.
Do we really want to copy the windows contextmenu?

@QuadroTony: Try to remember which contextmenus you used before. Not that much addons are using contextmenus. FilterIt and FCO ItemSaver are using my LibCustomMenu already.

@Chip: Did you add security checks, which could make LibCustomMenu contra-productive?

votan's settings menu told its LibCustomMenu Rev. 1

Yep, that's the newest and only existing version.

Just clarify for those new to this topic:
LibCustomMenu is not an automatic fix. It can't be, because of the "secure" checks:
Any add-on code is "in-secure". Therefore LibCustomMenu can not prevent other add-ons from calling AddMenuItem by hooking it. Because that would make "secure" code "in-secure", too.

Instead LibCustomMenu introduces a new global function AddCustomMenuItem, which should be used by all add-ons calling AddMenuItem.
This function swaps the control-pools before calling AddMenuItem itself and swaps back again. This way the "secure" code does not re-use "in-secure" controls simply because the pools do not contain them.

But if ZOS has extend the "secure" check, this work-around may not work anymore...

BTW: This technique could be used to introduce new menu-item-types, if it is still allowed.

do you like smthing like this?

A "more"-button should be doable by hooking ShowMenu and truncating the menuitems table at a specfic index. maybe "smart" enough not truncating for just two more entries. For example starting at index 7, but not if just 10 at all.

What I had in mind was a bit over-sized: Grouping the entries in groups of upto 5 and arrange them radial around the mouse pointer.
But that's a lot stuff for how many contextmenus having more than 10 entries? one?

So, your approach is better.
It highly depends on how other add-ons add their entries and ZOS would tolerate it.

But back to your last error:
What were the previous context-menus?
Do you use Votan's Fish Fillet v1.0.0+? Because v0.9 did cause it again, although I'm sure it did not when I released it. This is why I asked Chip, if they had extend the "secure" check.

Edit 1: Where does "Stats to chat" come from?

We could add a new submenu type as part of LibCustomMenu.
Addon authors then can add a submenu entry instead of several normal entries and group their options together logically.

While the idea to dynamically add a "more" element at the end of the list is good, I also think that it should not be necessary as there are not too many addons out there that add context menu entries and once they adapt the submenu it should be back to less than 10 entries.

I already wrote most of the necessary code for a new menu element as part of the iconpicker widget in LAM and it should be pretty easy to adapt it for submenus.

master merchant
btw this error happends only if clicking use on the Psijick part of the recipe without having all other parts
and ye i cant reproduce it next attempt

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.

It could be a system like libAddonMenu, where addons can register themselves & each addon can have 1 entry to the main context menu (the entry referenced by the addon name registered) which will pop-up a second context menu for that addon, like in QuadroTonys More -> picture.