是否可以捕获所有按键等？

嗯。
如果有人感兴趣...安捷伦vee 8.5帮助文件中有一些关于使用.net控件的限制的说明如下：“只有当控件托管在Windows窗体中时，才调用ProcessDialogKey，ProcessDialogChar，ProcessCmdKey等一些控制方法
应用程序，但VEE应用程序不是Windows窗体应用程序。控件编写器很少需要实现这些方法，但如果他或她这样做，VEE程序可能无法提供该控件的所有功能，或者您可能会意外
“我将这个发布给我正在查看的控件的制造商，他回复如下：”VEE环境未调用的ProcessDialogKey / Char方法将解释您遇到的问题.Windows窗体应用程序调用ProcessDialogKey /
聚焦控件和聚焦控件的父控件上的Char方法，但只调用聚焦控件上的OnKeyDown / Press / Up方法.FpSpread控件使用子控件
用于细胞编辑。
无论FpSpread控件还是子控件具有焦点（例如箭头键和制表键），FpSpread控件处理的许多击键都需要处理相同。
因此，FpSpread控件在ProcessDialogKey / Char方法中处理这些击键。“所以，基本上，尽管安捷伦的所有市场营销模糊，但实际上不可能在V形面板上有效地使用.net控件。如果您使用单独的控件，
作为文本框，复选框等，它们可以工作，但是你无法在界面上选项卡，因为没有机制可以进入或退出控件。好的，你可以用鼠标使用它，但根据我的经验，大多数测试工程师都在运行
测试软件更喜欢键盘控制。如果你试图使用一个统一的控件，如Farpoint传播，vee不允许必要的按键通过控件允许任何导航。你可以编程一个容器有多个控件，但你做的
这个以编程方式，即不能以图形方式构建界面。接受我在这一点上非常沮丧，是不是只有我发现令人难以置信的“图形化编程语言”不允许你实现有效的“
图形用户界面“。我猜是时候去视觉工作室.RegardsNick -----原始消息-----来自：Shawn Fessenden [mailto：shawn@vrfarchive.com]发送时间：2008年5月19日15:19
：VRFSubject：RE：[vrf]确实捕获了所有的按键等？>如果.NET控件有焦点，>分配的键不起作用。这似乎表明完全相反：> vee正在捕获
这里以前的工作方式是：应用程序（VEE）首先按键击，除非窗口已经被子类化或键盘过滤器生效（可能是
情况也不是这样。。热键（如Ctrl + O等）通常由应用程序立即处理，除非焦点控件想要对它们做些什么。
例如，在数据库应用程序中，Ctrl + V可能会将当前记录复制到剪贴板，除非焦点位于编辑控件上，在这种情况下，控件将当前选择复制到剪贴板。通常，有焦点的控件有机会
首先处理任何其他密钥。
这就是Tab＆amp;
箭头将由控件处理。
通常，键（比如一个Tab键）从应用程序窗口传递到当前聚焦的MDI窗口，然后传递到碰巧打开的任何对话框，然后传递给对话框上当前聚焦的控件。这可能是事情的所在。
搞砸了。
在宏观方案中，VEE面板应该像非模态对话框一样，也许它们不应该。
类名是AgilentVEE_CHILD而不是＃32770，所以在这个意义上它们肯定不是对话框。-SHAWN-



     以下为原文

  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.



Regards



Nick











-----Original Message-----
From: Shawn Fessenden [mailto:shawn@vrfarchive.com]
Sent: 19 May 2008 15:19
To: VRF
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.

-SHAWN-