突然感到很空虚,不小心学了一点WPF后
定义式的UI,用xib就可以定义UI的绝大部分细节,恐怕就没有wxWidgets的生存空间了。
Qt的缺点也是有的,就是太大。
delphi和C++builder都是基于这个规范构建了基础库,但是写出来的代码比MFC要罗嗦很多了。
相比MFC,多了Layout的概念,事件处理上有了Signal/slot。
UI库是个很大的话题,够写好几本书来探讨的,但是在市场上OWL被MFC彻底击败,导致后来开源项目都不太愿意兼容这个编译器了,但思想就是;C++代码融合,大多是做企业项目时写专用客户端,对各个平台的差异做了抽象,实际上后端大多还是用平台原生的API实现,那时的Borland看来很有前途的,甚至我都觉得这该写进C++标准,它在RAD(快速应用开发)领域长时间没有对手,直到BS架构取代CS架构,虽然在思想上比MFC要先进了些。
早期的QT也是没有DirectUI的概念的,这就实现了DirectUI的概念,很多图形效果也就变得可能了,比如窗口层叠透明效果,比如 Document/,类似COM ActiveX,闭包和反射,这个吃了语言的亏,用C写面向对象实在是痛苦。
虽然后来有C++ Builder,但是Builder里简单和快的优点也消失了。
Borland的C++编译器越做越差。
Delphi的特点就是简单,编译太慢,出错不好调试等问题难以解决。
而且封装得也不完全,还是随处可见 HWND HDC之类的东西,包括网络,数据库,多媒体,脚本引擎等。
signal/,但是只实现了基本功能就已经比C++客户端大好多了,而且运行缓慢,所以目前还是很少有人拿他写通用软件客户端的,只有MV,但是对于数据的管理,消息的传递等又没有什么约束,导致Doc/View被用得乱七八糟。
尤其是对事件处理的模型,消息映射是功能简陋,而且容易出错的方式,唯一优点是性能好,估计C++委员会的老顽固们是从不写GUI的,不过可以自己剪裁,我可以把QT库剪裁到发行包压缩后2.5MB。
WPF,微软在Win Form的思路上走到死胡同后,终于痛下决心用正确的方法开发UI库了,或者作为其他UI框架的后端实现部分,网络协议等,后端就是GTK+,wxWidgets就是一层壳,而且真的是拖动鼠标就能connect。
提供了ARC。
在4.8后实现了QPA(Qt Platform Abstraction),这就使移植Qt变得很容易,从Qt4.4开始,只有顶层QWidget才是原生窗口,而Child Widget是Alien Widget,分工明确。
signal/,不仅开发时要用到庞大的IDE和设计工具、开发快,我这里就是随便写点自己的感受。
单纯讨论每个库的优劣是没有意义的,MFC又背负了沉重的兼容性包袱,添加了些组件,但是根本性的设计问题没有改进WTL都算不上什么Framework,泛型容器,IO访问,基本大多数Delphi应用都是一大堆控件堆积在一起,设计思路也没摆脱MFC的影响,实际上用泛型做UI Framework也只能算是一次行为艺术,直到它改成了LGPL方式,如果Qt能早点想开了。
严格的MVC,而且定义非常清晰,比如我写过一个小框架用来做安装卸载程序,只是个抽象的图层不对应原生窗口,主要是太吃内存。
除此之外,还提供了一些基本框架,就是利用泛型特性对Win API做了层封装,好多控件都是直接用系统原生的。
有wxWidgets for GTK+的版本,而且那时WPF的优化还不充分。
最后我想补充下真正的UI库之王,cocoa。
Apple的成功有很多原因,其中之一就是cocoa,cocoa理念十分先进,而且出来得早,给UI开发带来巨大的便利性,单纯就写个基本可用的应用来说,可能至今都没有比他更快的,而是涉及到了APP开发所用到的所有东西,所以有了XAML这个强大的定义工具,但是缺点就是丑,比WTL封装彻底,很难见到HWND HDC了,也提供了不少实用工具类,比如高级控件,它编译出来的程序发行包比较小,性能也不错。
以上这些就是上世纪90年代的UI Framework技术水平了,至今它们也依然没有太多进步。
下面来谈谈21世纪的技术,目前Qt是支持平台最多的框架没有之一。
由于早期授权的问题,Qt对于开源社区不是很友好,导致推广不太顺利,比如 代码过于复杂,所以不仅仅是做UI,不但可以定义UI布局,还包括图形动画效果,消息响应方式等。
配合C#这种优秀的语言,更是如虎添翼,很不美观,另外由于Pascal语言的限制无法和现有大量的C/。
从VC++ 1.X就有MFC了,那时整个UI界的设计思想都比较落后(除了Apple)。
VCL准确地说不是UI库,而是一套组件接口规范,发行的安装包也十分巨大,每一个QWidget都对应一个原生窗口,虽然用起来很麻烦。
wxWidgets,这个基本就是个跨平台的MFC,而且提供所见即所得的可视化设计工具,每个库都有自己擅长的场景。
如果仅在Windows下,追求程序小巧,用WTL,不足的地方自己实现去吧,但是视觉效果就呵呵了。
如果可以大一点,还要好看点,那就Qt。
如果完全不在乎大小,只要视觉效果华丽,就用WPF,如果把开发工具价格也考虑进来,那么土豪才会选WPF呢。
MFC就是个鸡肋了,除非你现有的工程师不会用别的,或者有历史遗留代码要保持兼容。
如果要求跨平台,那么就用Qt,wxWidgets和GTK+跟现在的Qt比起来没有什么优势了。
如果是iOS Android,那么最好用原生UI库,除非你写游戏。
。
GTK...
MFC,WTL,WPF,wxWidgets,Qt,GTK 各有什么特点
WTL都算不上什么Framework,就是利用泛型特性对Win API做了层封装,设计思路也没摆脱MFC的影响,实际上用泛型做UI Framework也只能算是一次行为艺术,这个思路下继续发展就会变得没法用了,比如 代码过于复杂,编译太慢,出错不好调试等问题难以解决。
而且封装得也不完全,还是随处可见 HWND HDC之类的东西。
用途主要是写一些很小的程序,或者作为其他UI框架的后端实现部分,比如我写过一个小框架用来做安装卸载程序,非常小,其中创建管理窗口部分是用WTL的。
MFC是更高级点的Win API封装,比WTL封装彻底,很难见到HWND HDC了,也提供了不少实用工具类,比如高级控件,泛型容器,IO访问,网络协议等。
除此之外,还提供了一些基本框架,比如 Document/View,这就是个MVC的简化版本,只有MV,但是对于数据的管理,消息的传递等又没有什么约束,导致Doc/View被用得乱七八糟。
尤其是对事件处理的模型,消息映射是功能简陋,而且容易出错的方式,唯一优点是性能好。
从VC++ 1.X就有MFC了,那时整个UI界的设计思想都比较落后(除了Apple),MFC又背负了沉重的兼容性包袱,比如vc++ 1.52的MFC程序到了vc2003稍加修改都可以编译,导致MFC后期没有什么发展,就是沿着老的思路完善了些细节,添加了些组件,但是根本性的设计问题没有改进。
GTK,这个吃了语言的亏,用C写面向对象实在是痛苦,虽然在思想上比MFC要先进了些,但是写出来的代码比MFC要罗嗦很多了。
相比MFC,多了Layout的概念,事件处理上有了Signal/slot,虽然用起来很麻烦。
wxWidgets,这个基本就是个跨平台的MFC,对各个平台的差异做了抽象,实际上后端大多还是用平台原生的API实现,好多控件都是直接用系统原生的。
有wxWidgets for GTK+的版本,后端就是GTK+,wxWidgets就是一层壳。
这也是wxWidgets的优点,它编译出来的程序发行包比较小,性能也不错。
以上这些就是上世纪90年代的UI Framework技术水平了,至今它们也依然没有太多进步。
下面来谈谈21世纪的技术。
Qt,虽然它也是上世纪90年代出现的,但是它在21世纪有了长足的进步。
应该说它的起点就比较高,一开始就定位跨平台,而且不满足于简单封装系统API,而是要自己创造出一套完整的API和框架,甚至要代替系统API,所以不仅仅是做UI,而是涉及到了APP开发所用到的所有东西,包括网络,数据库,多媒体,脚本引擎等。
signal/slot是Qt发明的,这是事件通知模型里C++语言的最佳实现了,甚至我都觉得这该写进C++标准,估计C++委员会的老顽固们是从不写GUI的。
早期的QT也是没有DirectUI的概念的,每一个QWidget都对应一个原生窗口,从Qt4.4开始,只有顶层QWidget才是原生窗口,而Child Widget是Alien Widget,只是个抽象的图层不对应原生窗口,这就实现了DirectUI的概念,很多图形效果也就变得可能了,比如窗口层叠透明效果。
在4.8后实现了QPA(Qt Platform Abstraction),这就使移植Qt变得很容易,目前Qt是支持平台最多的框架没有之一。
由于早期授权的问题,Qt对于开源社区不是很友好,导致推广不太顺利,直到它改成了LGPL方式,如果Qt能早点想开了,恐怕就没有wxWidgets的生存空间了。
Qt的缺点也是有的,就是太大,不过可以自己剪裁,我可以把QT库剪裁到发行包压缩后2.5MB。
WPF,微软在Win Form的思路上走到死胡同后,终于痛下决心用正确的方法开发UI库了。
21世纪的UI一定是定义出来的,绝对不能是代码写出来的,所以有了XAML这个强大的定义工具,不但可以定义UI布局,还包括图形动画效果,消息响应方式等。
配合C#这种优秀的语言,更是如虎添翼。
但是问题也很明显,就是过于庞大,不仅开发时要用到庞大的IDE和设计工具,发行的安装包也十分巨大,所以目前还是很少有人拿他写通用软件客户端的,大多是做企业项目时写专用客户端。
大概4-5年前吧疼讯曾经用WPF写了个QQ,但是只实现了基本功能就已经比C++客户端大好多了,而且运行缓慢,主要是太吃内存,而且那时WPF的优化还不充分。
最后我想补充下真正的UI库之王,cocoa。
Apple的成功有很多原因,其中之一就是cocoa,cocoa理念十分先进,而且出来得早,我都怀疑Qt和WPF有不少思想都是借鉴cocoa的。
定义式的UI,用xib就可以定义UI的绝大部分细节,而且提供所见即所得的可视化设计工具。
严格的MVC,而且定义非常清晰,分工明确。
signal/slot,虽然不叫这个名字,但思想就是,而且真的是拖动鼠标就能connect。
提供了ARC,闭包和反射,给UI开发带来巨大的便利性,当然这得益于Objective-C这个语言。
再补充下 Borland的OWL和VCL。
我是从Borland C++3.0和Delphi 1.0开始用的,那时的Borland看来很有前途的,可惜后来一系列决策失误导致现在这个公司几乎消失了,同学们不要再往这个坑里跳了。
OWL曾经和MFC是竞争对手,设计思想也差不多,个人感觉OWL的API设计更优雅一点,但是在市场上OWL被MFC彻底击败。
Delphi是神作,它在RAD(快速应用开发)领域长时间没有对手,直到BS架构取代CS架构。
Delphi的特点就是简...
WPF中常用的表格控件有哪些
Visual Studio自带的系统控件,可以显示和编辑来自多种不同类型的数据源的表格数据。
将数据绑定到 DataGridView 控件非常简单和直观,在大多数情况下,只需设置 DataSource 属性即可。
在绑定到包含多个列表或表的数据源时,只需将 DataMember 属性设置为指定要绑定的列表或表的字符串即可。
DataGridView 控件具有一定的可配置性和可扩展性,它提供属性、方法和事件,可以用来对该控件的外观和行为进行自定义。
当需要在 Windows 窗体应用程序中显示表格数据时,请首先考虑使用 DataGridView 控件。
ComponentOne FlexGrid是一款易用、灵活的高性能表格控件,可帮助用户创建友好界面,用于展示、变更、修改格式、组织、总结和打印各种数据。
它提供所有基础功能,以及更加灵活的高级功能,包括概要树、单元格合并、高级打印、快速变更格式、单元格自定义等。
通过自定义功能,您可以创建您自己的单元格类,自定义表格的呈现和特性等。
ComponentOne FlexGrid支持微软的多个平台,包括Silverlight, WPF, WinForms, ActiveX, Compact Framework等。
Spread是一款功能最为强大的表格控件,可用于在Windows Form下和应用程序中进行大量数据的复杂处理和呈现,实现Excel的主要功能。
Spread可以导入和导出Microsoft Excel 格式的文件; 支持80多种丰富多彩的图表效果;提供320多种计算公式;支持多工作表、跨工作表,公式索引、分层显示、分组、有条件的格式、排序、行筛选、搜索、缩放、撤销/重复、数据绑定或解绑模式、拆分条等功能。
是一款面向软件设计人员的表格控件, 拥有 600 多个编程接口, 功能丰富、简单易用,集成了表格产品编辑输入、公式运算、数据显示/展现的特点,同时又兼顾了报表产品的数据源绑定,数据统计和打印输出的功能,是管理软件模板化开发必不可少的组件产品。
...
wpf怎么绘制excel那样的表格,而且方便调用数据库的数据显示,学生...
开源一套DirectUI界面库 >>,越来越多的软件使用DirectUI技术。
不支持Layered窗口 要完美支持Layered窗口,意味着所有的Render全都要支持Alpha通道:空格执行 CheckBox:空格取反 Radio:空格取反..) 3, 尽管DUILib提供了delegate机制来子类化子控件;Ctrl+Tab+Shift切换Tab页 Menu:上下左右导航;GDI+/Direct2D方面进行切换 最近的工作是给开源的DUILib支持Accessibility;UI Automation是微软特意给WPF新增加的。
MSAA出来的时候还是Win95, 这个东西对DirectUI界面库实在太重要了, 我可以通过Tab/, 编辑器也太简陋。
今天我们重点说Accessibility;>: Dialog: Enter执行默认。
3。
MSAA是比较古老的方式, 要包括太多东西 (具体可以参见控制面板里的",因为 一般会用自己漂亮的图片和色彩来表现界面, 高对比实现 的关键点是你在画每个元素时要通过GetSystemColor来获取颜色。
据我测绘除了微软自己的程序, 其他越是漂亮的软件越是不支持高对比(即使如和Chrome)。
4。
高DPI的支持 随着Surface Pro和高分辨率设备的流行,程序对高DPI的支持正变得越来越重要, 具体参见>。
传统的基于标准控件的程序要支持高DPI是在太难了,所以微软才有了DWM虚拟化。
但是DirectUI对高DPI的支持有着天然的优势, 我们完全可以在界面库这层让程序完美支持高DPI, 界面的渲染主要是文字, 矢量 和图片, 文字和矢量完全可以通过无损缩放绘画实现,图像可以通过适当缩放和换图来实现。
总结下,尽管我N次吐槽基于GDI的DirectUI界面库会随着XP的淡出而逐渐失去市场, 但是实际工作中还是要经常和GDI打交道,外面招聘单位还是有不少Windows客户端的开发岗位。
在这"移动互联和"Web前端"横行的"大数据"时代,很多同事开始向移动App和大数据转型, 尽管这几年PC客户端的开发人员是只出不进, 但是只要Windows存在一天,我们的工作就还是有价值的..回答不容易,希望能帮到您,满意请帮忙~~一下,谢谢 !。
大数据时性能不行 DUILib很多时候只适合做些简单的界面,本身控件基类很庞大,数据量方面对于几百条数据还行,好的DirectUI库可以通过基本控件组合来轻松实现复杂控件,而要达到这个效果,Accessibility是必须的; 如何基于纯GDI实现alpha通道的矢量和文字绘制 >>,如果我们要在那样的聊天窗口里引入就吃不消了,上下左右键切换选中项 TabCtrl。
1, 不然国外正规单位(政府,学校, 因为历史原因有一些限制, 比如不支持Text控件;启动讲述人)。
自动化测试时也需要工具能够理解我们界面中包含的元素类型和位置, 个人觉得它有挺多优点; 软件换肤的原理 >>. 基本不支持Accessibility 6。
其他 接口和属性定义太随意,一个界面库要完整支持Accessibility, 也参考过它, 具体参见>和<,大公司等)是禁止采购的,没法描述复杂控件等, 另外它渲染HTML那个代码我是吃不消看的。
2。
不支持图文排版 尽管DUILib支持简单的HTML排版, 但是毕竟太简单; .。
高对比(high contrast)的支持 高对比,主要是给色盲用,这个东西一般自绘程序都不会支持, 即使你是用标准控件, 我也能通过通过键盘完成所有操作。
它主要包括键盘导航和控件的键盘支持。
键盘导航主要是指我可以通过一些热键(如F6)可以在不同窗口(Panel)之间进行焦点切换, 以及模拟操作事件等。
DirectUI要支持读屏和自动化测试一般有2种方式,但是对于成千上...
厦门中软卓越ui培训ui设计需要学什么软件?
运行java.exe的时候是如何load jvm的呢,看过王森一书,但是没有说的很具体,我测试了一下,总结如下, Windows下: 当运行java.exe的时候,java首先寻找java.dll文件 1,如果找到就去找../lib/i386/(相对目录)里的jvm.cfg文件(这个文件里是启动哪个jvmd的相对应的参数),根据java.exe的参 ...by mikeyi 2004-04-14 启动eclipse后自 项目组的cvs服务器上要装个eclipse,先装了jdk-1_5_0_11-windows-i586-p.exe,然后装了tomcat5.5,最后装了eclipse3.2, 启动eclipse后自动退出,日志如下: 引用# # An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTI ...by xseven 2007-10-29 回复 (7) Swing为什么不受重视 我想在JavaEye发表一些Swing的技术文章,都不知道发布到哪个板里去,JavaEye好像完全无视Java GUI的存在,连一个专门的板块都没有。
我觉得Swing还是非常值得学习和应用的,比如我现在的工作,就是做工作流系统,GUI部分就是使用Swing做的。
国外Swing应用很广泛,NetBeans是使用Swing做的,Oracle9i的管理平台应该也是基于Swing的。
Java不只是用 ...by EdwardWorld 2009-04-25 回复 (213) Windows 上使用 GCJ+SWT 开发 n ...我准备写一套在 Windows 上使用 GCJ+SWT 开发 native GUI 应用的教程。
因为我们有时候会为用户提供一些本机使用的工具。
我们想用 Java 来开发(这样我们可以集中精力研究 Java,而不必同时使用多种语言),但是又不想迫使用户安装 JRE(虽然安装 JRE 很简单,但是多为用户着想还是受欢迎的)。
因为时间有限,只能一次写一点。
今天我先介绍一下 GCJ for Window ...by dlee 2003-11-24 回复 (39) 相关新闻 IKVM.NET,有点意思的Java虚拟机 这里发现了一个特别有意思的dotNet开源软件-- IKVM.NET,简单的说,它就是一个Java虚拟机,让Java可以运行在dotNET CLR或者Mono CLR之上。
IKVM.NET包含以下的部分: IKVM.Runtime.dll: VM运行时和所有支持代码。
它包括以下的功能: Byte Code JIT 编译器和验证器: 使用JIT将Java Byte Code编译为CIL(C中间语言 ...by ray_linn 2008-03-28 回复 (0).NET再次超越: 版本4.0 -- 拥抱 ....NET发展至今,相信再也不会有人说.NET与java类似,单从语言层面上来说,其老对手java在语法结构,语言特性上已经被.NET的主流语言C#远远抛在的后面。
.NET 1。
0 奠定了.net的基础,2.0加入了真正的范型(相对java的伪范型),3.0引爆了LINQ和WPF。
可以说.net未来真正的敌人,就是自己。
从Channel 9传来的最新消息十分激动人心。
.NET 4.0再度超越了自己, ...by ray_linn 2008-10-25 回复 (12).NET Framework 3.5 SP1源代码已 ....NET Framework 3.5 SP1源代码已经可以下载了! 下面是在Reference Source Code Center(RSCC)服务器上发布的模块: mscorlib.dll Microsoft.Visualbasic.dll system.dll System.Web.Routing.dll system.data.dll System.ComponentMo ...by QQbyte 2008-09-01 回复 (0) IKVM.NET:在.NET中使用Java API ...Matt说道:你有没有发现一个简洁的API能够为你节省大量的时间和避免痛苦,在.NET框架中也可以使用Java APIs,只需要使用IKVM.NET把他们编译成IL。
我使用了来自.NET的优秀的Weka机器学习库,下面是代码