Not doc'n, but the /general/ meaning (sometimes it is more tightly
defined) of .Tag is:

You (the developer) can use .Tag for your own purposes; it is typed as
object, so contain any single thing (which could be an array), but you
will need to track what it contains, as it only your doing. You will
need to cast it back to what you think it is to use it, though...

for instance, you could put a MethodInvoker instance in there so that
each menu-item (from this chain) keeps its "what to do when clicked" in
the .Tag property (for some reason) - then:

// initialization
newItem.Tag = new MethodInvoker(SomeMethodWithoutParams);
// or
newItem.Tag = (MethodInvoker) delegate {DoSomething(newItem, "abc",
123);};

then later (perhaps during the shared Click event handler):

MenuItem mi = sender as MenuItem;
if(mi!=null) { // sender *was* a MenuItem
 // some generic checks
 // more shared code
 MethodInvoker action = mi.Tag as MethodInvoker;
 if(mi!=null) mi(); // invoke action if any
}

Alternatively, .Tag is often used to track the business entity of
identity / key that corresponds to the UI element, particularly when a
control is dynamically repeated by the data being displayed - i.e. you
might show a TextBox for each user in a database, and have .Tag contain
the corresponding (app defined) SystemUser class (or something that
will help the developer *find* that instance, such as the username,
even if the .Text is the "friendly name" or "display name").

Or it could contain the original (pre-edit) values. Up to you (the
developer), you see?

Does that help?

Marc

Should have been:
 if(action !=null) action (); // invoke action if any

Marc