ToolStripDropDo wnMenu and SourceControl ??

[=?Utf-8?B?RGF2aWQ=?=]

Hello all,

I have dynamic controls all associated with a single ContextMenuStri p. For
each menu item I have click event method. For each event I have cast sender
to ToolStripMenuIt em to ContextMenuStip to use SourceControl to get the
control that initiated the event.

This all works well if the the menu items are one level deep on the
contextmenustri p control, but if I create a sub menu item doing the above
logic does not work.

First of all it gives a cast error of
"Unable to cast object of type "System...ToolS tripDropDownMen u" to
"System...Conte xtMenuStrip." So in the case of a sub menu I changed the cast
to ToolStripDropDo wnMenu.

ToolStripMenuIt em TlStrip = (ToolStripMenuI tem)sender;
ToolStripDropDo wnMenu temp = (ToolStripDropD ownMenu)TlStrip .Owner;
TlStrip = (ToolStripMenuI tem)temp.OwnerI tem;
ContextMenuStri p Mnu = (ContextMenuStr ip)TlStrip.Owne r;

Using above code Mnu.SourceContr ol is always null.

What am I doing wrong?

--
Best Regards

"Failure is the opportunity to begin again more intelligently" – Henry Ford

[=?Utf-8?B?RGF2aWQ=?=]

Its difficult to know when there are no responses wheather my question is not
detailed enough, not a common problem so no one is familiar with it to
answer, or just a dumb question (I have had a few). :)

For now going with need clarification. :)

I have a context menu strip as follows:
TestA
TestB - SubTestB

if I click on TestA Everything works fine. If I click on SubTestB the below
call to GetCtrl returns true but MyIcon is null.

Code Snippets:
///////////////////////////////////////////////////////////////
private bool GetCtrl(ToolStr ipMenuItem sender, ref MyDefIcon MyIcon)
{
bool bGood = false;
try
{
if (sender != null)
{
ContextMenuStri p Mnu = (ContextMenuStr ip)sender.Owner ;

if (Mnu != null)
{
MyIcon = (MyDefIcon)Mnu. SourceControl;
bGood = true;
}
}
}
catch (Exception ex)
{
MessageBox.Show (ex.Message);
}

return (bGood);
}
///////////////////////////////////////////////////////////////
private void TestAToolStripM enuItem_Click(o bject sender, EventArgs e)
{
MyDefIcon MyIcon = null;
if(GetCtrl((Too lStripMenuItem) sender, ref MyIcon ))
{
if (MyIcon != null)
{
// do command
}
}
}
}
///////////////////////////////////////////////////////////////
private void SubTestBToolStr ipMenuItem_Clic k(object sender,
EventArgs e)
{
ToolStripMenuIt em TlStrip = (ToolStripMenuI tem)sender;
ToolStripDropDo wnMenu temp =
(ToolStripDropD ownMenu)TlStrip .Owner;

MyDefIcon MyIcon = null;
if(GetCtrl((Too lStripMenuItem) temp.OwnerItem, ref MyIcon ))
{
if (MyIcon != null)
{
// do command
}
}
}
}


Please give advice or direction.

--
Best Regards

"Failure is the opportunity to begin again more intelligently" – Henry Ford

[Peter Duniho]

On Mon, 28 Apr 2008 12:52:00 -0700, David
<Da***@discussi ons.microsoft.c omwrote:

Its difficult to know when there are no responses wheather my question
is not
detailed enough, not a common problem so no one is familiar with it to
answer, or just a dumb question (I have had a few). :)

How about option D: three hours is way too early to start getting worried
about whether anyone's going to answer your question.

Anyway, I seem to be able to reproduce the issue you're seeing. And I'd
agree that it seems to be wrong. Upon finding the top-level
ContextMenuStri p instance in which your menu item is contained, the
SourceControl property should, IMHO, _always_ tell you the name of the
control used to show the menu. But for me, just as you said, I find the
property is set to null when handling the Click event of a menu item
that's not a top-level item.

Seems like a bug to me. I suppose it might not be, but I'd have to see a
really good explanation for the behavior for me to believe that. You may
at this point simply need to consider finding a work-around and report the
bug to Microsoft in the hopes of getting it fixed.

Pete

[Peter Duniho]

By the way, a quick Google search turned up these:

What looks like an earlier, worse manifestation of the bug you found:
http://connect.microsoft.com/VisualS...edbackID=96476

A newer bug report describing the specific behavior you're running into:
https://connect.microsoft.com/Visual...dbackID=282496

Looks like sloppy work by whoever fixed the first bug.

Both articles describe what seems to me to be a reasonable workaround
(handle the Opening event for the context menu, and get the SourceControl
value then, at which point it's apparently still correct, saving it for
later use in the Click handler for the item).

Pete

[=?Utf-8?B?RGF2aWQ=?=]

Thanks for the information Peter, and sorry for my impatience. :)

--
Best Regards

"Failure is the opportunity to begin again more intelligently" – Henry Ford