WPF界面编程与LabVIEW

计算机软件技术发展太快了，新的语言、体系，层出不穷。往往一个技术还没用熟练，就被要求换用更新的技术了。没准哪一天LabVIEW被什么其它语言替代了，我这方面的经验也就全作废了-程序员果然是吃青春饭的。

WPF是.NET中编写程序界面的一套体系。微软提出WPF时的构想是非常好的：它希望把程序的界面和运行逻辑部分完全分开来，这样可以有专门美工来设计程序界面；而程序员则专心实现程序功能的编码。它能不能实现这个美好的愿望呢?很难说，至少对于我和周边的同事来说，仍然需要同时负责相关程序的界面和代码。

虽然WPF之前，Visual Studio就号称支持可视化界面编程了，但那时可视化做的并不彻底。早期的VB、VC可视化编程，提供了一个可视化界面编辑环境。程序员在通过界面编辑器设计调整程序界面的同时，界面编辑器自动生成能够产生当前界面效果的VB或VC代码。也就是说，界面最终也还是程序代码的一部分，只不过可视化界面编辑环境帮可以助程序员生成相关的代码，从而简化了程序设计。

在WPF中，界面设计有了它自己的专门的记录方式，XAML语言，一种类似XML格式的文本语言。只有在程序进行编译的时候，编译器才把XAML代码编译成.NET的中间代码。这种行为与LabVIEW是类似的：界面与程序代码采用两套不同的机制表示。

与LabVIEW相比，WPF功能强大、灵活，但学习和使用难度更大。

先说LabVIEW的优点：LabVIEW的界面设计简单直观。WPF也许还不成熟，在可视化编辑方面做得并不好。最严重的问题是，一旦界面较为复杂，Visual Studio的界面编辑器就无法对其进行解析显示了。这样就完全失去了可视化编辑的功能。我现在接触的这个项目，有上百个XAML文件，超过7成的文件都无法被界面编辑器显示出来，只能手工的去修改XAML的文本。改完后，运行程序才能看到修改的效果。

再有，界面很少是静态的，界面上常有一些元素会根据程序运行时某些数据的不同而变化，因此，WPF上总有一些控件和程序中某些数据绑定起来。LabVIEW即便在编辑状态下，控件也可以拥有数据。这样以来，程序员在编辑状态下就可以看到程序运行起来后的控件状态。而WPF没有这一功能，程序只有在运行时才有数据，一旦进入编辑状态，所有数据都是空的。这样一来，在界面编辑器上看到的界面很可能与程序运行时的完全不同。

界面上的基本元素是控件，提供什么样的控件给程序员呢，LabVIEW与WPF采用了完全不同的策略。WPF面向通用编程，是给专业程序员用的，所以它侧重功能的强大与编程的灵活性。WPF自带的界面控件种类并不多，但是程序员可以很方便的就把它们组合起来，实现各种界面风格，完成各类复杂功能。LabVIEW只应用于某些领域，而且使用LabVIEW的不仅是程序员。因此LabVIEW侧重控件的易用性：它提供了大量自带的控件，每个控件可供修改的属性有限，如果想使用这些控件很容易：拖到VI前面板上就好了；如果想使用某种LabVIEW尚未提供的控件……那还是不要想了。

实际上LabVIEW今日的应用已远超出当时所定范围，相当一部分LabVIEW使用者都是专业程序员，他们对于功能和灵活性的要求越来越高，因此LabVIEW近几个版本也在这方面做了较大改进，比如增加项目管理功能，支持面向对象等。XControl便是转为补偿LabVIEW自带控件功能和灵活性不足而设计的新功能，但XControl使用起来太过复杂了，不如WPF的机制更加合理。也许将来的LabVIEW应该向WPF学习。

WPF中的控件差不多都可以作为容器再容纳其它控件。比如说按钮这个控件，它只提供一个按钮框架以及按下按钮相关的方法和事件。如果用户希望按钮上有一张图片，可以在按钮控件里面再嵌入一个图片控件；如果希望按钮上再有一行文字，那就在按钮中再放入一个文本框控件；如果还需要其它功能，再放入其它相应控件即可。LabVIEW中的控件不能嵌套使用，LabVIEW提供了带图片的按钮和带文字的按钮，如果需要其它功能，那只能去学习复杂的XControl了。界面常用到一种控件：列表。比如说一张列表有两列，第一列的每个元素都是一个按钮，第二列每个元素是一个下拉框。使用WPF编程非常容易，把按钮和下拉框嵌入列表控件就行了呗；LabVIEW编程可就复杂了，要自己编写程序把个按钮和下拉框控件在界面上移来移去，让它看上去好像在列表框里一样。

LabVIEW中有唯一和WPF控件这种性质类似的控件：Tab。你可以把一个按钮或者灯泡之类的控件放到某个Tab页上去，组合起来使用。

转载

曾经想研究WPF和Labview结合，其实就是为了界面好看专业。因为现在都是web 2.0时代的设计风格了。如果使用.NET和Measurement结合的话，用WPF就方便多了额