Viewer control steals focus on first open

[m-files corporation]

Hi,

We are embedding the PDF-XChange Viewer ActiveX control in our application, and we have a seemingly small but very irritating problem where the ActiveX control of PDF-XChange Viewer somehow steals the focus or active window status from our application when the FIRST PDF document is opened. This causes the context menu in our main application to close.

This might be related to this old posting: "Viewer control takes focus away on open document"
https://forum.pdf-xchange.com/ ... cus#p17263

Anyway, the problem is very difficult to avoid at our end because the loading of the preview is asynchronous. Now, if the preview is already loading for the first PDF file and while it is loading, the user clicks the right mouse button to open a context menu in our application, then the user will get the unpleasent surprise of the context menu suddenly disappearing when the PDF document loading finishes.

I've used "API Monitor" to try to track why this happens. It might be because of a SetFocus call/calls that PDF-XChange Viewer makes when the _first_ document is opened. Those calls don't appear in API Monitor log for subsequent document opens, and similarly the context menu problem doesn't occur for those subsequent document opens either. However, I'm not 100-percently sure that there's an explicit SetFocus call in PDF-XChange Viewer that causes this.

Can you check if there is an explicit SetFocus call (or multiple SetFocus calls) that PDF-XChange Viewer would make when the first document is opened? Confirming that would be helpful. Then, if such call(s) exist, could an option be added to e.g. OpenDocumentFile to prevent such calls if the main application so wishes?

I know this may sounds like a small problem, but it is really a serious problem for our users and we've spent a lot of time trying to figure out a workaround on our own, but without success.

Best regards,
Antti Nivala

[Vasyl-Tracker Dev Team]

Hi, Antti Nivala.

We will try to reproduce and fix this problem in the next build. Thanks for detailed info.
If you can also supply a simple app. for reproducing the issue that would be very helpful..

Best
Regards.

[m-files corporation]

Hi Vasyl,

Thanks for your attention to this issue. I'm attaching a simple app that should allow you to easily reproduce the problem.

Run the ContextMenuTest.exe file in the Release folder, or build the app yourself in Visual Studio 2010.

The app is an MFC app that creates the PDF-XChange Viewer ActiveX control in a background UI thread. Wait for a few seconds for the control to appear after starting the app.

You should then press the TEST button. This causes two things to happen:
1) Posting a message to the background thread, asking the ActiveX control to open a PDF file.
2) Displaying a context menu in the main UI thread.

Now, observe this: the FIRST TIME you press the TEST button, the context menu only flashes on the screen and immediately disappears. This is the incorrect behavior, and I presume it occurs because the ActiveX control somehow steals the focus or the active window status from the main window or main thread when the PDF document finishes loading, which causes the context menu to disappear.

The problem does not occur when you click the TEST button again, even though the application first closes all documents and then opens a new one. But even so, the context menu now remains on screen, which is the correct behavior.

So, can you find out what happens in the PDF-XChange Viewer ActiveX control in the FIRST opening of a PDF file that would cause this kind of unwanted loss of focus and disappearing of the context menu?

If eliminating that by default is seen dangerous, then perhaps you can add a flag such as PXCVA_NoFocus for the OpenDocument method to let us call it without this happening?

-Antti

[m-files corporation]

Hi Vasyl,

Could you verify that you can reproduce the problem at your end with the simple app I provided as you requested?

-Antti

[Vasyl-Tracker Dev Team]

Hi, Antti.

The issue has been reproduced. Thanks for your example app. We've started an investigation of this trouble..

Best
Regards.

[Vasyl-Tracker Dev Team]

We fixed this issue successfully, the fix will be available in the next build.

[m-files corporation]

That's great to hear! Many thanks for fixing this so quickly.

What would be the estimated date of availability for the next build?

We are preparing for making a new version available for our clients in about 2 weeks and I'd like to include the updated PDF-XChange version with this fix in it if you are making the build available by the end of this month.

-Antti

[Paul - Tracker Supp]

Hi Antti,

we don't have a date for this next release yet, it should be early Feb so it may be possible to work that into your plan. I suggest you touch base in a couple of weeks and see if we have an ETA by then.

hth

[m-files corporation]

Thanks, I'll do that.

-Antti

[Will - Tracker Supp]

[m-files corporation]

Hi,

We are heading towards our Service Release date so I wanted to check if you have the ETA for the next build of PDF-XChange Viewer ActiveX SDK with this "focus stealing" issue fixed.

Any update on the schedule would be appreciated.

-Antti

[Will - Tracker Supp]

Hi Antti,

Thanks for the post - this build is expected to be out around the middle of February and should include the fix that you are after.

Cheers,

[Vasyl-Tracker Dev Team]

Hi, Antti.

We fixed this issue successfully, the fix will be available in the next build.

Bad news for you.
After full investigation and testing we found out that the standard Microsoft MDI-implementation steals the window activation when the first MDI-child is created (or probably it keeps current activation but sends the 'MDI-child window is activated' notification to the system, which can be handled by popup-menu processor). Currently we have no idea what workaround could be implemented there...

The first of our suggested fixes (the one I notified you about earlier) is unacceptable for us because it breaks the correct working of our internal MDI-manager - so we cannot include it in our new official build, sorry..

Best
Regards.