LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

ActiveX is stealing my key presses?

Solved!
Go to solution

Hi all,

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?

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 1 of 13
(4,738 Views)

Here's an example project in LabVIEW 8.6

(You'll need Adobe Reader on your machine)

 

Any ideas yet anyone?

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 2 of 13
(4,733 Views)
Unfortunately I don't have a good solution, but I can sympathize - I've had the same problem.  In my case I was able to work around it by hiding the ActiveX control (an Internet Explorer page with text input boxes) except when displaying the one page I want the user to see.  Clicking in any LabVIEW control re-hides the ActiveX control so that it no longer receives keystrokes.  If this isn't an option for you, perhaps you could put your PDF viewer in a subVI that displays its own front panel, and manipulate which window is in front programmatically?
Message 3 of 13
(4,706 Views)

nathand wrote:
Unfortunately I don't have a good solution, but I can sympathize - I've had the same problem.

Hi nathand, thanks for the sympathy Smiley Happy

 

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 Smiley Sad

 

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!!!

Thoric (CLA, CLED, CTD and LabVIEW Champion)


Message 4 of 13
(4,697 Views)

Hi Thoric,

 

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. 

 

Kind regards,

Ashish Naik
Automotive Business Development Manager
National Instruments UK
Message 5 of 13
(4,692 Views)
Hi Ashish - that's odd.  I have an almost identical setup to you (XP SP 2, LabVIEW 8.6, Acrobat Reader 8.1.3) and I see exactly the behavior Thoric describes.
Message 6 of 13
(4,690 Views)

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!

 

Ashish Naik
Automotive Business Development Manager
National Instruments UK
Message 7 of 13
(4,688 Views)

Hi all, thanks for trying this Ashish.

I'm on Win XP SP3, LV 8.6 (not 8.6.1 yet), with Adobe Reader 8.1.3 and it definitely doesn't work for me.

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 8 of 13
(4,685 Views)
Solution
Accepted by Thoric

Hi Guys,

 

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



 

Message Edited by Ashish N on 02-27-2009 04:40 PM
Ashish Naik
Automotive Business Development Manager
National Instruments UK
Message 9 of 13
(4,682 Views)

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 

Ashish Naik
Automotive Business Development Manager
National Instruments UK
Message 10 of 13
(4,670 Views)