I want to say first, Pete, that I appreciate you taking the time to put
down
your thoughts so thoroughly. My comments:
(1) My rejection of the "simple" solution was not on a whim; I do not
have
exposed methods to call needed by that solution (which I should have
stated).
Whim or not, you did reject it. It may be for good reason, but that
doesn't change the desirability of using that solution. Just the
feasibility.
(2) I maintain that the SendKey suggestion is an infinite loop--yet you
say
this is "appropriate"; please explain how.
I don't see an infinite loop. Presumably the Click handler that Linda
posted resides in the Control that should receive the keyboard input, not
the ToolStripMenuItem. So, unless the Control upon receiving the keyboard
input then turns around and somehow raises a Click event in the
ToolStripMenuItem, where's the infinite loop?
Does your Control do that?
(3) Regarding your comment "You're trying to translate an event
that occurs in one object to be handled by event handling in a different
object." That was present, in fact, for precisely the reason of
disambiguating what I wanted. I was giving a related example--note that I
said "IF it provided ...". (Sounds like I am damned if I do, damned if I
don't
Well, that's fine. It's not how I read that post though. It's not just a
matter of having the event use a different EventArgs class. There's just
not even that event mechanism. It wasn't clear from your post that was
understood.
(4) Yes, I am referring to ToolStripMenuItems. I was not aware there were
other types, a fact reinforced by Linda's use of it in both examples.
ToolsStripMenuItem is the most common, but there are legacy classes that
you could have been using instead. In any case, you should always be
specific, even if in theory there are no other alternatives.
(5) As for example code I cannot offer much beyond what Linda has already
provided twice:
private void toolStripMenuItem1_Click(object sender, EventArgs e)
{
// This menu command needs to pass the event--or perhaps
// generate a different event--so that the approrpriate
// event handler in a custom user control will act on the user's cmd.
}
Well, first...those are Linda's examples, both of which you said were
inappropriate. How are we supposed to know that those actually do serve
as examples of what you're trying to do?
Secondly, those are hardly complete enough to really understand the
issue. They don't tell us anything about the Control classes you're
trying to interface with, or about how you'd prefer them to work.
Based on the code you posted above, either of Linda's suggestions would
work fine. Since you say they don't work fine, obviously the above
example is not nearly specific enough to provide useful advice to you.
You need to provide an example that is at least complete enough for people
to understand why the simple example's Linda's offered don't work.
For another example, consider the ordinary TextBox. It supports a
variety of
keystrokes: cut, copy, paste, home, end, select-all, etc. I just want to
add
those types of keys to a menu in the menu bar so that they are enumerated
along with all the menu commands that I am providing explicit
implementation
for. It sounds like the only simple way to do this is from Linda's first
suggestion, i.e. call the specific methods.
Well, the TextBox class has all of those specific methods (well, cut,
copy, paste, home, end, and select-all...I don't know what's left in
"etc." so I can't comment on that). But you wrote "I do not have exposed
methods to call needed by that solution".
So what's really the problem?
Anyway, thanks for keeping me on my toes.
You're welcome.
Pete