AnsweredAssumed Answered

vrf does vee trap all key presses, etc?

Question asked by VRFuser on May 19, 2008
Ummm.   If anyone is interested...


There are some notes within the Agilent vee 8.5 help file concerning limitations of using .net controls as follows:


"Some control methods like ProcessDialogKey, ProcessDialogChar, ProcessCmdKey are only called when the control is hosted inside a Windows Form application, but a VEE application is not a Windows Form application. A control writer will seldom need to implement these methods, but if he or she does, the VEE program may not offer all of the functionality of that control, or you may get unexpected behaviour."



I posted this to the manufacturer of the control I am looking at who responded as follows:


"The ProcessDialogKey/Char methods not being called by the VEE environment would explain the problem you are encountering.  A Windows Forms application calls the ProcessDialogKey/Char methods on both the focused control and the focused control's parent but only calls the OnKeyDown/Press/Up methods on the focused control.  The FpSpread control uses child controls for cell editing.  Many of the keystrokes handled by the FpSpread control need to be handled the same whether the FpSpread control or the child control has focus (e.g arrow keys and tab key).  Thus, the FpSpread control handles these keystrokes in the ProcessDialogKey/Char methods."


So, essentially, despite all the marketing blurb from Agilent, it Is not really possible to effectively use .net controls on a vee panel.


If you use individual controls such as text box, check box, etc they work but you have no way to tab around the interface as there is no mechanism to tab into or out of the controls.  OK you can use it with a mouse but in my experience most test engineers running test software prefer keyboard control.


If you try to use a consolidated control such as the Farpoint spread, vee does not allow the necessary key presses through to the control to allow any navigation.


You can program a container to have multiple controls but you have do this programmatically, ie cannot build the interface graphically.


Accepting that I am pretty frustrated at this point, is it just me that finds it incredible that a "graphical programming language" does not allow you to implement effective "graphical user interfaces".


I guess it is time to go to visual studio.










-----Original Message-----
From: Shawn Fessenden []
Sent: 19 May 2008 15:19
Subject: RE: [vrf] does vee trap all key presses, etc?


> If a .NET control has the focus,

> assigned keys don't work.


Which would seem to indicate exactly the opposite of:


> vee is capturing the tab key and

> arrow keys such that they never

> get through to the component.


The way this used to work was: the application (VEE) gets first shot at keystrokes unless the window has been subclassed or a keyboard filter is in effect (probably neither is the case).


Hot keys (like Ctrl+O etc.) are normally handled by the application immediately unless the control with focus wants to do something with them. For instance, in a database app, Ctrl+V might copy the current record to the clipboard unless focus is on an edit control, in which case the control copies the current selection to the clipboard.


Usually, the control with focus is given a chance to handle any other key first. This is the point were Tab & arrows would be handled by the control. Generally, the key (lets say a Tab key) is passed from the application window to the currently focused MDI window, then to any dialog that happens to be open, then to the currently focused control on the dialog.


This might be where things are getting screwed up. In the grand scheme of things, VEE panels ought to behave like non-modal dialogs and maybe they don't. The class name is AgilentVEE_CHILD not #32770, so in that sense they certainly are not dialogs.