Niko,

I know this was years ago and you’ve almost certainly resolved this, but you can get the calling object via the figure’s CurrentObject property. So from the callback:

get(ancestor(src, 'figure'), 'CurrentObject')

This answer really came from MVP Jan:
https://www.mathworks.com/matlabcentral/answers/67685-how-do-i-find-out-which-uicontrol-launched-my-context-menu

Is it possible to have multiple objects share the same uicontextmenu? I’ve tried it but the problem is I don’t know how to figure out which object is right-clicked on (the callback only contains the context menu object itself)… is there some sort of (possibly java-based) workaround or do you have to use a separate uicontextmenu for each object and label it somehow? Thanks!

Niko

Yaroslav,

Thank you for your comment – and indeed you are correct the solution above is a bit of a “sledge hammer” approach.

The point you make was (supposed to be anyway…) covered in point 2 of the conclusions – you need to take care and only delete the appropriate uicontextmenus.

Your solution is a good improvement for the reader of this blog! 🙂 And a reminder to me to explain in more detail in the future!

Regards

It is always a great deal of vexation, when some GUI components (UI-context-menus) are not associated to their natural object (plot/axes/etc.), which leads to confusion, and sometimes, as you have shown, to a significant slowdown; thank you for pointing that out for context menus. Yet I believe that your solution is incorrect in this case.

The reason is very simple: when you delete the context menus with

delete ( findobj ( h.main, 'type','uicontextmenu' ) )

you remove all the associated handles inside the figure; that may pose a significant problem if you have several axes with context-menus in the figure. Using listeners will not solve the issue (unless you use a different XObjectDeletedEvent for each axis), and may introduce additional peculiarities, since Matlab’s event-driving mechanism flushes the graphics in its own time (see drawnow for more details).

What I suggest, is using Matlab’s own DeleteFcn mechanism. More specifically, since the plot handles have both DeleteFcn and the linked UIContextMenu handle, we may use it together to obtain —

plot ( h.ax, x(ii), y(ii), 'rs', 'uicontextmenu',uim , 'DeleteFcn',@(obj,~)delete(get(obj,'UIContextMenu'))); 

so that when the plot is deleted, the associated UIContextMenu is removed as well. On my laptop it has shown the same improvement in runtime as in your example of deleting all the context-menus in the figure whilst retaining the linkage between the plot and the menu.

Sebastian – thanks for your comments.

Indeed you are correct – its always best to be smart 🙂

The example above is trivialising what was a very complex GUI with many individual and customisable uicontextmenus – even the “real world” example I quoted was not what was really done, but trying to provide some generalised numbers on how many objects can be created if you don’t take care.

The scenario I was showing here was to highlight that you should clean up uicontextmenus once they are no longer required/accessible (true for other objects too).

In both of your cases you would still need to clean up the uicontextmenu handle(s) after they have been used/no longer accessible, as the more objects you have the slower anything that uses findobj would become for example.

I’m pretty sure in most of such cases one can either
a) make the callbacks of the individual uimenu-entries dynamic, e.g. to act on the just clicked handle
or
b) make the uicontextmenu itself dynamic, by implementing an on-the-fly creation of its menus using the ‘Callback’ of the uicontextmenu.

E.g. in your example you could add the ‘X=…’ and ‘Y=…’ in the very beginning and simply change their labels according to which object was clicked by the user.