ui_cases #77
giscus[bot]
bot
Replies: 4 comments 6 replies
-
|
阮老师，您好！在这一节里面，您提到了使用绘图控件实现带图标的菜单，这一想法在labVIEW里具体怎么实现呢？想了很久，没想到比较好的实现方法。 |
Beta Was this translation helpful? Give feedback.
-
|
大致思路是这样的：比如在界面上点开了一个下拉的菜单，整个这个菜单就是一个绘图控件。这需要：
如果菜单不需要特别花哨，可以使用列表框控件作为菜单，使用起来比绘图控件更简单。 |
Beta Was this translation helpful? Give feedback.
-
|
非常感谢老师，大概明白怎么实现了。 |
Beta Was this translation helpful? Give feedback.
-
|
之前博客上的相关文章，搬到这里： LabVIEW 黑白棋程序今天因为工作需要，察看了我原来备份的一些文件。 结果我翻出来了好多已经被我遗忘了的东西，都拿来跟大家分享吧，也作为一个纪念。 先分享一个 LabVIEW 下黑白棋的程序。这不是我说过的使用遗传算法的那个程序。 这是我刚开始学习 LabVIEW 时编写的程序。那时还是1999年，使用的是LabVIEW 5.1。 程序里基本只有界面，没有实现什么算法。 程序在LabVIEW 5.1上开发之后，我再也没有再维护过。我今天在LabVIEW 8.1 上试着打开它，发现以前所使用的一些库VI已经找不到了，不过只影响到了Othello server.vi。其他VI还可以正常运行。 解开zip包： |
Beta Was this translation helpful? Give feedback.
-
|
之前博客上的相关文章，搬到这里： 用 LabVIEW 编写 Wizard 类型的应用程序 Wizard 向导类型的程序，指的是可以类似安装程序那样，一步一步地指导用户完成功能的应用程序。这类程序极为常见。它一边要求用户提供必要的信息，一边给用户发出指导性的意见和反馈。这样，即便是新用户也可以轻松完成任务。但是，向导类型的程序虽然方便了用户，却是增加了开发人员工作的复杂度。 一、页面为独立 VI我在编写第一个程序时，首先想到的就是一个最直观的编程方案：为 Wizard 的每一个步骤编写一个独立的 VI。关闭当前的 VI，打开一个新的 VI，程序就自然而然从一个页面跳到另一个新页面了。完成后，就发现这并不是一个好主意。因为每个页面都是独立的，数据的交换和状态的控制都不方便。比如说，原来的面板在屏幕左边，按一下Next键，面板突然蹦到屏幕的右边了。 二、借助 Windows API于是，就考虑是否可以采用框架式的结构。当时 LabVIEW 还没有 sub panel 控件，做框架只能借助 Windows API 的帮助，把一个 VI 的面板当作子窗口，插到框架VI的界面中去。当时公司的一些产品就是采用了这种方法。但是，我并不喜欢。它的主要缺点是只能够支持Windows，无法跨平台使用。再者，我是一位地地道道的 LabVIEW fans，怎么能利用 Windows API 呢？我应该寻找一个纯G语言的解决方案。 三、变动控件位置 下面，就来介绍一个早期的纯 LabVIEW 的解决方案：通过挪动界面上控件的位置来达到界面切换的效果。具体说，就是当用户按下 Next 键，程序就把当前界面上的控件往旁边挪动一段距离，移动到用户界面的可视范围以外，用户就看不到它们了；与此同步，把那些原来在可视范围以外的、而下一页应当显示的控件，挪到可视范围内。这样，用户的感觉就是切换了一个页面。 http://ruanqizhen.googlepages.com/splitter.7z 从范例中可以看出，这种方法十分麻烦，每一步操作都要考虑如何挪动每一个控件。如果程序太大，就难以维护了。也许现在不会再这么编写程序了，然而在当年 LabVIEW 还不支持 Tab 控件与事件处理结构（event structure）时，这个方法还相当流行的呢。
四、Tab 控件+事件处理结构 LabVIEW 6.1 的出现才第一次大大简化了 Wizard 界面风格程序的编写。LabVIEW 6.1增加了两个非常重要的新特性，一个是Tab控件，一个是事件处理结构。 http://sine.ni.com/nilex/DisplayLinkAction.do?id=101NILEX。 它的功能是把一个 C 语言开发的仪器驱动程序转换为 LabVIEW 下的驱动程序。程序虽然是我编写的，但版权属于NI公司，所以不能把程序源代码公开给大家。 这种方法也有它的弊端。因为整个 Wizard 界面会用到的所有控件都集中在同一个 VI 上，这个主VI就可能特别庞大：界面可能有数十个控件，程序框图上的事件处理更为复杂，有近百个事件也不作为奇。如果需要对程序作修改，要找到相应的事件框就已经很困难了，要确定这个改动是否会影响程序的其他部分就更为困难了。 Tab 控件+事件处理结构的架构虽然大大简化了 Wizard 界面风格程序的编写，但是这样的程序很难对他的代码进行更细致的模块划分，并把模块的私用数据隐藏起来。为了使大型 Wizard 程序有更好的可读性，可维护性，还需找到一种更好的架构。 五、SubPanel主VI太过复杂，是肯定会影响它的可读性和可维护性的。所以，对向导类型程序的进一步改进的重点，就是把主VI进一步模块化，不但是程序代码要模块化，界面也必须模块化。代码模块化相对比较简单，多利用子VI就是了。但是界面的模块化，在之前的LabVIEW中是非常困难的，因为 LabVIEW 没办法在运行时，把不同的 VI 的界面拼在一起。是 LabVIEW 7.1 和 8.0 的一些新功能最终解决了这个问题。 对程序界面模块化，按一般的思路，第一步就是把每个页面划分成一个独立的模块。这似乎又回到了我们前文提到过的第一、二个阶段。但有所不同的是，旧版本 LabVIEW 功能不全，无法很好的管理被分为模块的页面，而新 LabVIEW 改进的对这方面的支持。
插件框架式程序的实现思路是，把向导的每个页面都分配到一个独立的VI上去，这个页面上所有的操作，都有这个页面所在的VI完成。图1左上部分的那些 VI 就是为每个页面编写的VI。这些 VI 都被当作插件，在主程序需要的时候被调用显示在主程序上。 这样的插件框架式程序在运行时，主VI和插件VI是在同时运行的。 虽然 SubPanel 在 LabVIEW 7.1 中就出现了，但是我当时却并没有在我的程序里采用上述的设计方案。只是因为当时还有一个棘手的问题没有解决。这个问题就是 VI 太多了，不好管理。 六、Project Library LabVIEW 8.0 作为一大升级版本，拥有了很多新特性。其中之一是“Project Library（工程库）”。 工程库给开发插件框架式的程序带来的很大的方便，特别是在 VI 文件的管理方面。
但是，现在的程序结构还是有些令我不太满意的地方-重复的代码太多。不同页面之间，有很多类似的VI。就比如图2中的程序，每个页面都会用到事件处理的一些 VI，他们的代码在每个页面中都是相同的。但是，利用这个工程库组织起来的程序却不能把这些重复的VI提取出来，变成共用的子VI，因为在每个页面里，这些代码相同的VI，处理的数据是不同的。并且这些数据会保留在 VI 的局部或全局变量中，不同的页面如果共用一套子VI，会相互影响，出现数据混乱的。 |
Beta Was this translation helpful? Give feedback.
-
|
之前博客下的留言： Qizhen 回复 回复 回复 回复 |
Beta Was this translation helpful? Give feedback.
-
|
之前博客下的留言： 帆 回复 回复 回复 回复 回复 回复 回复 回复 |
Beta Was this translation helpful? Give feedback.
-
|
之前博客下的留言： Qizhen 回复 回复 |
Beta Was this translation helpful? Give feedback.
-
|
之前博客下的留言： Qizhen 回复 回复 回复 回复 回复 回复 |
Beta Was this translation helpful? Give feedback.
-
|
之前博客下的留言： H 回复 回复 回复 回复 |
Beta Was this translation helpful? Give feedback.
-
ui_cases
虽然上面已经介绍了很多界面设计的原理和规范，但实际界面设计是非常灵活的，同一个功能可以有很多种设计方式。
https://lv.qizhen.xyz/ui_cases
Beta Was this translation helpful? Give feedback.
All reactions