Viewer freezes/waits when loading a Tool

[DSSavant]

Issue with calling DoVerb and not having it return until the mouse cursor has changed due to hovering over a non-viewer window.

Long Summary:

Yea, this should be fun to explain. When selecting the Pencil Tool from the Page Context Menu (I “Deny” your menu and display mine – see Notes below), the mouse cursor will not change from its prior state to the Pencil’s “+” cursor. At this point the application will “freeze”. When I say freeze, I mean that the viewer will do nothing. I cannot draw, click on thumbnails, scroll, expand/contract the comments area, select an annotation, etc. Nothing. Zip. Three things I’ve found thus far allow me to recover from this state.

1. I can sit and wait and do nothing. The amount of time varies from 20 seconds to a couple of minutes. After that time, the mouse cursor will change to the expected affordance and the viewer becomes usable.
2. I can move the mouse cursor out of the viewer and cause it to change somewhere else within my WinForm. For example, I will size my window. At this point when going back into the viewer, the mouse cursor will be set right and the tool will work. Note that clicking on other applications does not always unlock/unfreeze the viewer.
3. I can hit a keystroke. This causes the viewer to unlock as well.
4. I can go get a beer at the local pub. They have a very nice porter on tap. This really is the same as #1 but it make me feel better.

I have placed an immense amount of logging statements throughout my code to point the finger at the viewer (sorry). Below is the outline of what occurs:

User selects the Pencil tool on the menu. I BeginInvoke(InternalDoVerb(…)). InternalDoVerb(…) looks like this:

>> Log.Debug("CALL - Viewer.DoVerb(\"{0}\", \"{1}\", \"{2}\", out dataOut, {3});", objectName, operationName, dataIn, flags);
>> Viewer.DoVerb(objectName, operationName, dataIn, out dataOut, flags);
>> Log.Debug("RETURN - Viewer.DoVerb(\"{0}\", \"{1}\", \"{2}\", out dataOut, {3}); dataOut = '{4}'", objectName, operationName, dataIn, flags, dataOut);

Notice the time in the call below:

 10/29/2010 2:33:51 PM - DB :: InternalDoVerb :: CALL - Viewer.DoVerb("", "ExecuteCommand", "33129", out dataOut, 0);

Viewer is froze. I wait. 17 seconds go by and then I get an event notification from the viewer.

>> 10/29/2010 2:34:08 PM - DB :: _viewer_OnEvent :: Name: 'Tools.Active', Type: 'PXCVA_OnPropertyChanged', Flags: '0', DataIn: '', DataOut: ''

I do some really cool stuff like figuring out what is now the active tool.

>> 10/29/2010 2:34:08 PM - DB :: InternalDoVerb :: CALL - Viewer.DoVerb("Tools.Active", "get", "", out dataOut, 0);
>> 10/29/2010 2:34:08 PM - DB :: InternalDoVerb :: RETURN - Viewer.DoVerb("Tools.Active", "get", "", out dataOut, 0); dataOut = '33129'
>> 10/29/2010 2:34:08 PM - DB :: InternalDoVerb :: CALL - Viewer.DoVerb("Tools.Active", "getNamed", "", out dataOut, 0);
>> 10/29/2010 2:34:08 PM - DB :: InternalDoVerb :: RETURN - Viewer.DoVerb("Tools.Active", "getNamed", "", out dataOut, 0); dataOut = 'Pencil'
>> 10/29/2010 2:34:08 PM - DI :: ViewerOnToolActivationNotification :: Active Tool changed. Name: Pencil, ID: 33129

And then I get the ending part of the initial call to activating the Pencil tool.

>> 10/29/2010 2:34:08 PM - DB :: InternalDoVerb :: RETURN - Viewer.DoVerb("", "ExecuteCommand", "33129", out dataOut, 0); dataOut = '33129'
The big deal here is the time I must wait. Please note, I have waited minutes before. I will be very hard pressed to release this to my customer base – let me know how I can help but please don’t ask me to create a project that exhibits the bug as it will take me a very long time. This post should have all the necessary information someone should need to start looking into the issue. The key problem here being that it does not happen 100% of the time, just 20% every other day. The log statements show the thread going into the viewer code and sitting there for a very long time. I would humbly suggest that someone looks into what types of items the viewer could block/wait on such that some type of UI event would wake it up. I have seen this bug for over six months now so it was in prior versions/builds.

Notes:
• I’ve had to remove your context menus for various reasons. I’ve replaced them with Infragistics menus.
• When I get a menu click notification, I BeginInvoke() DoVerb to ensure that any thread in the Infragistics code has a chance to unwind itself; this should take Infragistics out of the picture.
• I do not get this problem 100% of the time.
• I’ve seen this with other tools and not just the Pencil Tool. The Pencil Tool is the most frequent problem child.
• It does not seem to matter what Tool the viewer is currently set to when selecting the Pencil Tool from the menu.

Let me know what I can do further to help.

[Vasyl-Tracker Dev Team]

Hi, DSSavant.

We'll try to reproduce the problem but we're not sure we can do it. It can strongly depend on the client(your) code. For example, try to temporarily switch off your _viewer_OnEvent handler and try to reproduce the issue again... Maybe there is a collision with Infragistics UI...

...let me know how I can help but please don’t ask me to create a project that exhibits the bug as it will take me a very long time.

Sorry, but it would be very helpful if you'll send us an simple example for problem reproducing.

Thanks.

[DSSavant]

Yep, I fully expected you to say that. Oh well

I have a hack-work-around right now where I simply query for the active tool Before setting the active tool. That is enough to cause the Viewer not to freeze. I will play with the code more in the future to see if I can eliminate more variables but this will not be a priority for me. Please notify your Development staff of this issue as it would be an easy thing for them to look at their code.

[John - Tracker Supp]

Hi,

actually Vasyl is one the lead project developers on the Viewer - so your questions are going directly to someone who knows the product and the source code inside out - if he cannot reproduce then you can be assured we need more from you I am afraid to take us forward ...

We are always concerned when a client finds a problem and particuarly so if we cannot reproduce - so if you can provide us with more info or a simple project allowing us to do so - we would be pleased to take this further.

Thanks

[DSSavant]

Just as a head's up. I will be sending you two projects that demonstrate the issue. One will be using your FullDemo project and the other a simple project. If you are lucky, I will even enclose a video showing the issue as a picture is worth several thousand words.

[Paul - Tracker Supp]

looking forward to it DSSavant

if it is to large for the forum let us know in a post here and I'll send you ftp credentials to upload with.

regards

[DSSavant]

I've a attached a ZIP file with two projects and a readme document that fully describe the problem. Further, please see the following URL for the promised video:

http://www.youtube.com/watch?v=KvdUjOlVZzE

Scream if you need anything further!

[Paul - Tracker Supp]

Thanks DSSavant

we have the files. I'm positive you will hear from someone soon.

[Vasyl-Tracker Dev Team]

Hi, DSSavant.

We investigated the collision issue between Infragistic's context menu and our control.
Probably this issue arises because Infragistic's menu works incorrectly when it is over a window from another process (our control "lives" in the other process, not in the client's process).
We added one workaround for resolving the issue with the mouse moving over the menu as described in http://www.youtube.com/watch?v=KvdUjOlVZzE. Thanks for your video. This workaround will be available in the next(190) build.

However, there is still one bug: when you click on a 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")...

To resolve potential UI-problems - the new version (V3) of our control will "live" in the client's process...
Thanks for your clear report. Also, please see the attached sample.

Here we added some code for correct closure of Infragistic's popup menu, look to modified OnEvent..
And please do not forget about activation of mouse monitor (already in this example):

Code: Select all

string bsVerb = "Notifications.Mouse.Filter";
object vFilter = 6; // down/up notifications
axCoPDFXCview1.SetProperty(bsVerb, vFilter, 0);

Best
Regards.

[DSSavant]

Thank you for the quick response. I've posted the bug in the Infragistics forum.

[Paul - Tracker Supp]

Thanks DSSavant,

do let us know what ensues.

thanks

[DSSavant]

Just thought I would let you know that it is just now being looked at by Infragistics. Thanks for being so very active on bug fixing!

[Jamie - Tracker Supp]

Our Pleasure!

Regards,
Jamie

[DSSavant]

Infragistics just let me know that they have figured out the problem. As for fixing this issue, I really don't care as I simply do not use menus with shadows anymore thus no problem.

Just passing this on for you guys to know about.

From Infragistics:

Re: Context Popup Menu freezing application...
By [Infragistics] Dave Frischknecht in WinToolbars
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.

Refer to http://community.infragistics.com/forum ... spx#313937

[Vasyl-Tracker Dev Team]

Hi, DSSavant.

Many thanks for your information. We will check this issue and fix if it is possible...

Best
Regards.

[Tracker Supp-Stefan]

Hello DSSavant,

As per the guys request I've made a ticket for this case:
#1325: Issue (deadloop) with shadowed Infragistic's menus
So that it can be investigated. This is not of the highest priority but we will still keep you updated with any news as they become available.

Best,
Stefan

[DSSavant]

"Not the highest priority"...

Personally, I would not fix this at all in V2.X . I would ensure it is not found in Version 3.X though.

[Tracker Supp-Stefan]

Personally, I would not fix this at all in V2.X .

Thanks for the understanding

Yes it will most likely be fixed for ver3

Cheers,
Stefan

[Tracker Supp-Stefan]

Hello DSSavant,

We will be closing the ticket for this case - as you confirmed Infragistics have resolved the problem, and this won't be present at all in v3 - so we can consider this one clsoed.

Best,
Stefan