My latest pet peeve

I agree, this one caused me some pain a while back. I was adding menu items dynamically based on user actions, and had no simple way to tie new menu items to specific data objects. I wound up having to use a Hashtable to look up objects from menu items; that works, but is a real pain to keep up to date and requires some references between objects I'd rather were independent from each other. I considered deriving a class from MenuItem, but I'd have to also create my own main menu component and designer.

aye, i agree with that ken..but that's just a workaround for osmething that you would assume would be common enough to be included. I've implemented an IExtenderProvider in one solution and derived my own MenuItem in another situation...it isnt a big deal, like i said, it's just more of a pet peeve that would be nice to have.

How much of a hassle would it be move the Tag property from the Control class to the Component class? It shouldn't really be a breaking change as there isn't a tag property on any of the non-visual components (as far as I know). But, maybe there should be...

I solved this by just inheriting from MenuItem and creating my own TaggedMenuItem. Simple stuff, and I only needed a tag on some items generated at runtime anyway.

I've done this before, but then I sacrifice being able to use the designer to modify the menu. Does anyone know if the Menu designer can be forced to use a custom MenuItem instead of the normal framework MenuItem?

Thanks,
Robert W. Grubbs