I'm reporting this as a bug in the Infragistic's Menuing system. It deals with displaying a popup menu over a third party control hosted by out-of-process COM server. The bug can be seen in the following video:
http://www.youtube.com/watch?v=KvdUjOlVZzE
It deals with simply popping a menu up over the Tracker company's Viewer control. The control is owned by an out of process COM server. The video shows a hack to their FullDemo.EXE sample application installed with their SDK (scream if you want my hacked version to reproduce it in house). I've reported the bug in their forum as well.
The video shows simply hovering the mouse over the menu and having it choke. An easier way is to simply pop up the menu and click in the Shadow of the menu, at this point the application will "freeze". Once frozen, if the user takes an application window (say your email client or something) and covers the menu, then the froze application will respond to input again.
Doing the same exact thing with a normal Window's menu works perfect! Again, the bug only manifests with the Infragistics menus.
I've reported to this to the Tracker group and their developer responded with:
"...when you clicks on shadow under Infragistic's context menu the client app (FullDemo.exe) will freeze.. We cannot solve this bug because it is not ours, please contact Infragistic ("Infragistic's popup menu works sometimes incorrectly when the menu is over a window from another process")..."
The link to the form post is (search for the text given above):
http://www.tracker-software.com/forum3/viewtopic.php?f=36&t=9193&p=44096#p44096
Please let me know if you need further information regarding this. I'm running VC 2008, Windows 7, 64-bit, fully service packed, patched, hacked, blah blah. I've reproduced the bug in version 10.3 as well as prior versions.
Hello DSSavant,
Our engineers have researched this issue and have come up with the following conclusion.
This is an issue in the axWebBrowser control that causes the Form to no longer receive any messages until the form is obscured by some other application.
If you perform a online search, you will find many reports of the axWebBrowser causing a form to become unresponsive. In our case, it is triggered by a mouse-click on a control that allows clicking through to the underlying control. The shadows on our dropdowns are designed to allow the user to click the control on the form under the shadow. This is done by overriding WndProc() for the WM_NCHITTEST(0x84) message, and setting the result to HTTRANSPARENT (-1).
To demonstrate this issue in the axWebBrowser, create a custom panel using the following code; add an instance of the panel to the form on top of the axWebBrowser control, then run the application. Clicking the panel will cause the same hang.
Panel
{
()
.Red;
}
WM_NCHITTEST = 0x84;
HTTRANSPARENT = (-1);
m)
.WM_NCHITTEST)
m.Result = (
.HTTRANSPARENT;
else
There is no way for us to determine what the shadows are over, or prevent the hang from occurring. The only solution is to turn off the menu shadows by setting the UltraToolbarsManager's ShowMenuShadows property to False.
Please let me know if you have any other questions about this.
Torrey,
Thanks. This post though did in fact sit for about 10 months before anyone looked at it and said "I can't reproduce it, I need more information". This post is not meant as a slam, more of a frustrated wake-up call.
DSSavant said: Glad Infragistics found it. May I ask why it took 10 months for this post to see any action?
Glad Infragistics found it.
May I ask why it took 10 months for this post to see any action?
I can't speak for everyone, but I started 4.5 here months ago. Having been an Infragistics customer for 5 years before that, I can relate with your frustration. Anytime, I come across a post like this, I take time out to investigate and answer it.
My guess is that Dave wasn't able to replicate the bug because it requires a specific scenario with com interop for triggering.
This bug is really easy to reproduce if the menu is over something like a PDF. I'll log a bug with one of the test projects that you provided, with slight modifications for an engineer to investigate further. Dave, I'll email you the bug number when I create it in the morning.
An educated guess without debugging much deeper is that the popup menu is not correctly handling an event which in turn causes a thread to wait forever. If you switch to another application and then back to the hung application, the application will be unfrozen (correctly handling that event and closing the popup menu).