4 Answers, 1 is accepted
The target option specifies the existing DOM elements the ContextMenu should open on. When new elements are created dynamically, you can reset the ContextMenu target via the setOptions() method, e.g.:
http://dojo.telerik.com/oruWE
I hope this helps.
Regards,
Dimiter Topalov
Telerik by Progress

Hi Dimiter,
Works like a charm. Too bad things like these are a bit hard to find in the documentation. Thank god for the forums.
Thanks,
Ron

Hi Dimiter, allthough the proposed solution does work functionally, I am experiencing a problem. Some of my context menu's are rather large (thousands of items). Without going into the discussion if having such a large amount of items is a good idea, I noticed that by calling the proposed setOptions method, the entire component seems to be re-initialized. This results in an unacceptable long wait time for the contextmenu to be responsive after each call to setOptions. I managed to come up with a workaround but unfortunately I have to call some internal code from the contextmenu component, which is obviously not ideal. Any thoughts of a better solutions or if it's really necessary for the contextmenu to re-init after a call to setOptions only to change the target?
Work around, see: http://dojo.telerik.com/eVUCuWat/2
I have carefully reviewed the implementation of the setOptions() method of the ContextMenu and the widget as a whole and have performed several test. Nevertheless, I did not managed to reproduce a scenario in which the ContextMenu gets re-initialized (executes its init() method) after the setOptions() has been called. May I ask you to prepare and send us such sample, where the described could be observed?
As per the _wire() method call, it does exactly what you need. It will reattach the required listeners to the target elements. As you have correctly noted, using internal methods is never the best option. Nevertheless, in this specific case it executes the appropriate logic.
Regards,
Veselin Tsvetanov
Progress Telerik