I have a fairly simple front panel with a handful of LabVIEW controls and an ActiveX container. In the ActiveX container is the Adobe Reader plugin.
My vi works, but exhibits an odd behaviour that I presume is focus related. Once the ActiveX control is programmatically told to open and display a pdf file, it seems to steal the focus - permanently. If I select my LV string control, I can select any text in it, but key presses are all still sent to the Adobe Reader ActiveX control. If I click a few check boxes, then the string control again, it still doesn't accept my keyboard presses. The only way I've found to stop all this is to press tab, as this causes LabVIEW to move the focus away to the next control in the tab sequence. After that, all is ok until the next pdf file is read into the ActiveX control, and then I'm back at square one.
Now I don't want to be telling my customers, "that's alright mate, just make sure you press the tab key after every pdf you generate and you'll be just fine."
I've tried programmatically moving the focus away from the ActiveX control, and setting "SkipTabbing" to true, but this doesn't work.
Anyone know how I can prevent this darned ActiveX control from permanently stealing my focus?
Solved! Go to Solution.
Unfortunately I don't have a good solution, but I can sympathize - I've had the same problem.
Hi nathand, thanks for the sympathy
I've tried a few things, including navigating away from and straight back to the tab panel which houses the control to attempt to change the control focus. I've even tried simulating the keyboard TAB key press, which actually works - but only once for some annoyingly unfathomable reason! A second call to the ActiveX AdobeReader control makes it the focus again, but this time permanently. I've even tried putting the ActiveX control into a subvi that's hosted within a subpanel - no difference.
Ultimately, like yourself, I've had to settle for a separate window, which I've called a Preview Window. Of course, putting my large ActiveX container in a separate subvi has left a dirty big empty space on my main vi front panel
I'm tempted to try to hide all borders around the preview window, and programmatically control its location such that it sits perfectly over the empty space within my main front panel. Of course, this means monitoring main panel window resizes and movements to maintain the correct relative locations, but it's do-able...
I've got a new problem now - I thought about using Invoke to Get the Front Panel Image, then place this into a picture control. However, it seems the AdobeReaderActiveX control evades the LabVIEW Front Panel Image method, revealing nothing but the blank front panel colour behind the container. I can't seem to find a way around this either!
Dam dam dam dam dam dam dam dam dam dam dam dam!!!
I have downloaded your zip file and tried your code.
Once I run your code, and use my mouse to click into the string, (which you have to do to select the string) I am able to type quite happily.
I can also use my keyboard to stop the app (Ctrl +.), and go to the block diagram (ctrl +e), and turn context help on and off (ctrl + h).
I have tried this in LabVIEW 8.6.1, 8.6, and I am using Adobe Reader 8.1.3, on a Windows XP Professional SP3 machine.
Hi there, I am on SP3, that's the only difference. I will have a quick look on some others computers in office, and see if I can narrow it down a lil more!
Sorry I have done a little bit more digging.
I got it wrong earlier.
I get this issue on LabVIEW 8.6(Adobe Reader 8, and 9), but NOT LabVIEW 8.6.1(Adobe Reader 8 and 9)
The issue seems to be fixed in LabVIEW 8.6.1
Just to let you know,
I had tried it on 4 LabVIEW 8.6.1 machines, and it worked, some had Adobe Reader 8, 1 had Adobe Reader 9.
I tried 2 LabVIEW 8.6 Machines, one on Adobe Reader 8, one on Adobe Reader 9. - Neither of these worked!
Hope this helps