Treeview and Adobe Preview - Form Unable To Be Clicked

[AlastairP]

Good afternoon

I have a VFP9 program that holds an activex treeview control (TreeCtrl2 - The standard one that ships with VFP).
The nodes in the treeview when selected will open a PDF file to be previewed in an explorer control (Shell Explorer2).

Just occasionally, the form becomes unresponsive to interaction with a mouse. When clicking buttons or areas on the form - except for the treeview control.
You can continue to select different files for preview, but the rest of the form will not respond. This is not an issue where the process is unresponsive due to a busy process, it is more like the something has focus and won't release control to the form.

Can anyone provide any thoughts on how to identify the issue?

Alastair

 

[Chris Miller]

I think you have some kind of deadlock situation. Changing _vfp.autoyield might help.

Another thing VFP has to deffine basic bahavior are the OLE properties of _VFP, mainly OLEServerBusyTimeout. An OLE server usually is an automation server like Word.Application, but it can also refer to OLE controls.

There's one well known issue using Shell.Explorer aka the Webbrowser control. You have to have NODEFAULT in the Webbrowser control Refresh() method.

Chriss

 

[AlastairP]

I checked my web browser class and I have the NODEFAULT already in Refresh.
However _VFP.AutoYield = .f. was not implemented in my application.
I had a read of the help file, and it seems that it is advisable to set this to false if your form contains an activex control.
I will also experiment with OLEServerBusyTimeout in the load event of the form and see it that makes any difference

I will try both and see how it goes.

With thanks

Alastair

 

[Chris Miller]

I see the remark about that in the help, yes. At the same time, with _vfp.AutoYield = .F. ensure that you don't have any long running code that only puts your process in a wait state (READ EVENTS) after that is done.

The problem is a two edged sword, not interrupting code execution can also mean events queue to be processed too late or in the worst case never - in a deadlock situation.

A very general rule about that is not introducing any local wait states. Usage of inkey() and WAIT, for example, without a timeout. As the help topic also states, WAIT isn't causing a wait state.

All in all it's shots in the dark, but it seems to have to do with ActiveX having it's events separate from the VFP event queue, which is just normal as ActiveX or COM servers do run with their own runtime always. It's less important they have their own HWND, multiple HWNDs are normal for any process, but that can be problematic with setting focus, too.

VFP manages that clicking on an ActiveX isn't like activating another form. The form including the ActiveX stays the active form, I guess because the ActiveX hwnd is a child of the form. So actually there's littel to worry about, but then you have that problem. Adobe has caused trouble for VFP and more generally, with it's restrictions, but using Adobe Preview within a webbrowser control, I don't see how it would effect VFP directly, if there's a problem it should be with the webbrowser control.

But it wouldn't be the first time Adobes software is only prepared to be embedded into a browser and not into a browser canvas embedded in something else.

So an idea to check whether it's a mishap of the Adobe Preview: How do things change, if you don't use a webbrowser control, but start an IE instance and show that as a separate IE window? It's not the interface as you imagine it, but if that still has the same problem you'd know it's nothing in the domain of how VFP embeds ActiveX into its forms.

That the webbrowser control does not embed the Edge browser and MS discontinues IE is maybe contributing to the problem, because it might be that Adobe Preview isn't working well in IE.

Chriss

 

[Chris Miller]

I don't know how far you have solved your issue, but I found that the combination of Adobe and IE11 (which is the standard for Windows 10) are posing a few problems.

Therre is quite a drastic solution, drastic in two ways:
First: Instead of using the Microsoft Webbrower Control, use WebkitX ActiveX - you can get the 32bit from

https://www.webkitx.com/#Downloads.

The usage to use it as PDF viewr is as simple as navigating to the PDF file.
You put an Olecontrol on the form, pick "WebkitX" from the control type list that comes up when you add an Olecontrol to a form.
You now just need one line in the "OnBrowserReady" event of that control:

this.Open('file://C:/Your/Path/To/Some.pdf')

And that's it.

The reason why it's so simple is shortly explained: While MS IE browser still needs plugins to display file types other than images or HTML, browsers like Firefox and Chrome have built-in support for PDF, for example. So that's exactly what I expected to work, you just navigate to a file URL of the PDF and the rest is done by the browser control. You can expect it have better compatibility with modern HTML5 and latest JS versions, too. I'll not go into details about what this enables. The fly in the ointment of course is licensing cost of 600 GBP.

I also assume Adobe Preview differs from the native WebKit PDF viewer and maybe that'll already be a show stopper alone. Also the problem may be in the treeview control instead. But I think from all I found the problematic part is the PDF viewer. There are other solutions, PDF.js seems to be a standard. You can test it in a JSFiddle:

https://jsfiddle.net/pdfjs/9engc9mw/,

but, well, navigate there with an MS Webbrowser control and you see how problematic that is.

In the end PDF support only needs a PDF viewer plugin that installs into IE 11, 32bit, too. One tip for Adobe also was to do the simplest thing you can do: De- and reinstall it to get it fixed. Anyway, I wanted to showcase this for it is a very interesting ActiveX component that can be used for better support of modern HTML within a VFP desktop application. Not only for PDF. Just look at the documentation if it.

Chriss

 

[AlastairP]

Hi Chris,
I have looked at third party controls. Not really an option at this stage due to cost.
I am considering running a document preview in another thread. The users can have this running on their second screen and I will use a node server or similar to listen to the latest file to be loaded.

I have been testing the freezing issue and have found that the issue only occurs when using a treeview to make the file selection.
Making the file selection with the treeview without sending to the web browser does not freeze the form either.

I made a temporary button on a form that has a link to a file in the click event, and I can click this many times and shows/reloads the pdf in the web browser with no freeze up.
I will keep looking and report back if I find a solution.

Alastair

PS EDIT
I added a timer to the container class that holds the treeview, and called the timer from the treeview nodeclick.
That way the treeview is not calling the web browser directly, and this seems to work.

 

[Chris Miller]

I added a timer to the container class that holds the treeview, and called the timer from the treeview nodeclick.

A timer running its Timer event once is a good way to have an asynchronous call. Doing that one call that could freeze up in a timer that first disables and releases itself after the call can actually ensure it doesn't freeze, or you won't care for it. It could just hit you when exiting the application and there are timers sitting in memory stuck at their timer event. But I never had that problem.

Chriss