LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Keyboard not working on front panel

There must be something strange going on here, because this seems like a pretty weird problem.

I have several numeric controls on my front panel and an event loop inside a while loop on the diagram. My numeric controls are located inside the while loop, but outside the event loop.

When I start my VI, I lose the ability to change any numeric control values with my keyboard. I can't backspace, type numbers, delete, nothing. Even when I stop the VI, I still can't change any numbers with my keyboard. If bring the block diagram to the front, then bring the front panel back to the front, I can type in the boxes again.

I have an IE ActiveX control on my front panel as well... could it be stealing keyboard focus?
0 Kudos
Message 1 of 21
(4,025 Views)
My first thought was to check the event structure for 'Lock Front Panel Until Complete' option but given that the keyboard is locked even after the VI is stopped, perhaps you can post your code (or simplified example) so that we can look into further.
0 Kudos
Message 2 of 21
(4,011 Views)
I'm encountering the same problem.
I think there is a problem with ActiveX control, multithread (web browser's navigate method uses it's own thread) and focus management.

To sum up:
focus is on a panel's component but keystrokes are going somewhere else (to one component of the navigated page).

I reproduced the problem using an RTF editor ActiveX component.
When loading an RTF file in the same thread there was no problem but when loading the file from an other thread, the same problem occured.

Any idea about going round this problem ?

0 Kudos
Message 3 of 21
(3,875 Views)

I'm not the only one with this problem then.  I just found this thread after spending several days tearing my hair out.  The keyboard focus is not switching from the embedded ActiveX control to the VI when the user clicks on the VI panel itself.

I've attached a simple VI that illustrates the problem.  In my case I'm using the Adobe (Acrobat) Reader ActiveX control.  Clearly the problem is at the LabVIEW end, as we're all using different ActiveX controls.  Adobe Reader is required to run this VI.  I'm using Adobe Reader 8.1.0 and LabVIEW 8.20.

The VI saves a small PDF file in your temp directory, then gets the Adobe Viewer to display it.  The PDF file is deleted on exit.

To illustrate the problem, try this:

  • Click on the PDF document then press F1.  The Adobe help is displayed.  Correct behaviour.
  • Click on the VI panel outside of the Adobe control then press F1.  The VI's help dialog is displayed.  Correct behaviour.
  • Click within the Find box at the top of the PDF document and type some numbers in.  Works correctly.
  • Now click within the numeric control at the bottom left of the VI and try to type some numbers in.  The numbers appear in the Adobe control.  Not correct behaviour.

I've found that if I press F1 after clicking on the VI or operate the boolean control with the mouse then the focus does correctly switch back to the VI.  I can then type numbers into the control following this.  However, after I've clicked anywhere on the ActiveX control I can click as much as I like on the VI panel or the numeric control and the focus will not switch to the VI's numeric control.

I believe that the fault is that the keyboard focus does not leave the ActiveX control until a LabVIEW boolean control is operated.  This means my application doesn't work properly.

I will submit a fault report for this, but any clever workaround would be very much appreciated.  I'm going to have a play with some of the events, e.g. mouse over the numeric and see if I can come up with anything.  I will report back if I get anywhere.

Message Edited by Sean on 08-07-2007 11:27 AM

Message Edited by Sean on 08-07-2007 11:29 AM

Download All
0 Kudos
Message 4 of 21
(3,850 Views)
I've tried adding an event for "Number":Mouse Enter.  In this event, I set the control's KeyFocus property to True.  This temptingly selects the number, ready to overtype its value.  However, the actual keyboard focus still remains with the ActiveX control.  I'll try some more weird ideas but I may not be able to get anywhere.
0 Kudos
Message 5 of 21
(3,837 Views)

Fault logged with NI UK.

0 Kudos
Message 6 of 21
(3,823 Views)

Just a thought - if anyone reading this has LabVIEW 8.5 it would be very useful to know whether this bug is still there.

I can't even download an evaluation version of it yet.  I think it's only been launched today.

0 Kudos
Message 7 of 21
(3,817 Views)
This is NI's reply to my bug report:
 
The issue you reported is a known problem with LabVIEW 8.x when used with
the ActiveX Adobe Acrobat control. As it stands there is no workaround for
this problem and is isolated to this particular control due to it's
architecture. Redevelopment for future releases of LabVIEW may or may not
contain a fix for this 3rd party control.

Thank you for bringing this problem to our attention and I'm sorry that I
could not help more but unfortunately this information is all I can offer
at the present.

I will be now closing this Service Request. Thankyou for calling National
Instruments.
I have since tried using a few different ActiveX controls in place of the Adobe PDF Reader and, to my surprise, LabVIEW does seem to work perfectly with the other ActiveX controls that I've tried (calendar and Office 2003 spreadsheet).
 
So it looks like this may be an Adobe issue, or possibly just an oddity.  However, others on this thread have reported similar problems with other controls.  If so then please post a simple example VI that demonstrates this.  If it's a LabVIEW problem then I would expect NI to fix it.  As it is, I'm stuck without a resolution or workaround.

Message Edited by Sean on 08-08-2007 03:22 PM

0 Kudos
Message 8 of 21
(3,799 Views)
A copy of my email sent to NI today:
 
The attached zip file contains an exe built in .net with the same functionality as the LabVIEW VI posted earlier.  It works perfectly in .net.
 
This appears to be a LabVIEW issue.  Could NI please give some commitment to fixing this issue?  As it stands, my application will not work.  I need to display a work instruction to the user (a PDF file), and take a result from them, which is the numeric control.  This issue means I can't do what I need to do using LabVIEW.
 
If we ditch LabVIEW for all GUI development (which at the moment is the only fix for this problem) then we will need far fewer development licences.
 
 
0 Kudos
Message 9 of 21
(3,767 Views)
Hi Sean,

This is a known issue and is being investigated.  I will get in touch with the owner of the issue and get more information.
0 Kudos
Message 10 of 21
(3,745 Views)