cyantree's blog

c/linux/video/audio

导航

<2017年5月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

统计

常用链接

留言簿(3)

随笔档案

搜索

最新评论

阅读排行榜

评论排行榜

2007年8月22日 #

在ocx中的worker thread中触发事件,vb调用时会崩溃

     摘要: 这个操蛋的问题要从一年前说起,当初做无线点菜,PC端的接口是用C写的,提供的是lib/dll方式。有些客户惯于使用的是vc或delphi,这些都很方便,但是某些客户使用的是vb和pb,问题就来了。pb因为我并不熟悉,所以没有多管,vb一开始打算用的是dll,但是发现一触发事件就崩溃,在网上找了很久,发现问题出在事件触发是在thread中的,vb属于线程不安全的类型,所以一触发就崩溃,但是我又不能更换模型,后来写了一个ocx的版本,但是问题依旧  阅读全文

posted @ 2007-08-22 05:00 cyantree 阅读(839) | 评论 (1)编辑 收藏

2006年6月7日 #

FLTK简介

首发站点:http://www.heybrain.com

  FLTK,如同其名字所表达的:The Fast Light Tool Kit,一个轻量级的GUI开发库。但这轻量级并不代表功能的羸弱,相反,FLTK在具有基本的GUI功能之外,还拥有一些特殊的功能,比如跨平台、内置 OpenGL功能、速度更快、尺寸更小、协议宽松等。当然,缺点也是有的,比如对于复杂的界面构件支持不够,资源支持的不足等。但一个工具如果使用的好, 取其长而去其短,自然可以飞花摘叶皆可伤人;P

   我选择FLTK 的过程还是比较曲折的,当初做ARM下的GUI开发,选择的GUI库是MiniGUI,一个国内开发的界面库。当时还支持类unix平台,对 Windows的支持尚在开发中。由于需要寻找一些问题的解答,所以经常在其论坛上搜索,从而知道了还有microwindow、nano、 qtembedded等嵌入型GUI开发库,但当时没有太过注意。后来又开始转向WINCE平台的开发,这一搁就是2年。再后来终于要做跨平台的开发,对 具有跨平台的GUI开发库开始注意起来。

  一开始的选择是wxWidgets,但是研究了一段时间后发现不好解决的问题越来越多,终于 放弃。最头疼的就是C++类的事件传递,wxWidgets内部使用的是一个类似MFC的方法,所有传递事件的类全部要从一个根类继承,这样就导致创建的 类和wxWidgets绑定过甚,复用性大大降低,同时由于wxWidgets的目标不仅仅是GUI,造成其包含功能过多,其内部结构非常复杂,虽然是 OpenSource,但要若要修改其代码还是很困难的。综上所述,wxWidgets并不符合我的要求,从而被排除在外。

  之后研究的QT,老牌的跨平台GUI开发库,工具很多,开发也很人性化,qtdesign很像Delphi的界面开发方式,代码带有强烈的linux风格,但是看看附带的库文件又实在让人有些泄气,尺寸大,发布麻烦。所以在试用了一段时间后还是放弃了。

   在此期间,其实也看到过一些对FLTK的介绍,但大多数对其评价不高,也就没有注意。直到有一次偶然心血来潮,上http: //www.fltk.org看了一下,发现FLTK 似乎正对我的胃口,这才开始对其进行了深入的研究。经过一段时间的实际开发,个人觉得,对于跨平台和代码简洁而言,FLTK是再适合不过了。

   FLTK的底层只提供一套完整的画点、画线功能,另外附带了字体的显示功能,但FLTK对字体的支持还很粗糙,尤其对于非英文字符集而言,后面我会详细 说明。在基本的点、线功能基础上,FLTK完全自己实现了一套界面,比如Button、Label、Edit、Tab等,全部都是由基本的点线画出。看到 这,可能你会觉得这实在是属于自己造轮子,吃力不讨好。诚然,如果你只针对一种平台开发,这样的做法不能带来多少好处,还造成学习时间的拉长。但若要针对 多个平台开发,这样做的好处就很明显了。首先是移植容易,只要针对目标平台实现基本的点线功能就可以实现代码的移植,这可能是所有跨平台GUI库中最方便 最直接的方案,目前FTLK支持MacOS、Windows、Linux(x-window)等平台,针对WinCE(主要是unicode的问题)和 plam 的开发正在进行中。其次是保持了界面的一致性,虽然QT、GTK等开发库也具有这种功能,但是他们都需要一套基本库的支持,无法做到系统尺寸的优化,而对 于FLTK而言,这却恰恰是他的优点和长项。最后是代码层次清楚、结构简单,由于大部分的工作就是基于底层的点线功能进行自绘,所有很多代码都是简洁明 了,很少费话。

  底层之上是一套以Fl_开头的类,代表了各种GUI构件,比如Fl_Window、Fl_Button、 Fl_Input等,使用起来很是容易。同时由于上面所说的,所有的界面构件都是画出来的,因此在熟悉了这种方式后,生成自己的构件也是很容易的,反正是 画界面嘛,既然别人能做到,你也能做到,实在不行可以查阅源代码进行学习。这些界面类的共同特点是轻量型、都拥有一个draw(),只要在draw()里 实现自己的绘画动作即可。

  说到界面就不能不说其事件实现方式,对于FLTK而言,使用的是最直接的方法:while(1){}。这也 是很多人批评FLTK原始的一个原因。但仔细想想,其实这是最直接的办法,不管是哪种平台,最终的事件方案不外乎是死循环和中断,中断的确具有很多好处, 但只要while(1)能完成这部分的功能,那又有什么关系呢。每个界面类都有一个handle(int event),只要继承这个成员函数,就可以在其中处理自己的事务。是不是很简单?同时由于这样的事件方式,造成FLTK的刷新速度很快,事件反应迅速, 也算是个附带优点了。现在大多数的开发库都是采用OO方式的事件处理方式,但FLTK却采用了最原始的函数指针方式,也算是一个异类,这可能和FLTK的 unix背景有关,无论如何,这种方式还是需要一定的适应时间的,而且这种方式的优缺点也是属于各花入各眼了,不过我本人还是很喜欢这种方式的,谁叫我比 较原始呢#-_-

  FLTK产生于NeXT环境,发展于X-window环境,所以对图形加速的支持必然是选择OpenGL。FLTK 使用Fl_Gl_Window这个类将OpenGL的基本功能囊括其中,只要在Fl_Gl_Window的draw()里glbegin/glend即 可,基本的设置工作FLTK全都做好了,对于我现在的系统要求简直是最适合不过了。

  FLTK基于LGPL,对使用者的要求非常宽松: Contrary to popular belief, it can be used in commercial software - even Bill Gates could use it! 所以开发者不需要担心其项目的隐形问题。但是如果对FLTK进行了卓有成效的修正最好还是能回馈给开发组,所谓我为人人,人人为我嘛。

   说了一堆的好话,现在开始谈谈FLTK的缺点。首先一条就是对非英文字体特别是中文的支持比较差,甚至是非常差。在Windows平台下还好一点,因为 在 Windows平台下使用的是TextOut函数输出字符串,但是在X-Window环境下就完蛋了,无法正确显示中文,也不能调用输入法进行输入。从这 点来说,FLTK还是只适合一些封闭软件的开发,对于通用软件而言FLTK并非是一个好的选择。但只能在Windows平台下开发中文软件也不是个办法, 要解决中文的显示问题也不难,目前FTLK的稳定版是1.1.7,开发版是2.0,有人针对1.xx版本修改了一个unicode版本,可以很平滑的支持 汉字的显示,但很遗憾,我没有编译成功过,如果谁编译成功了可以给我来个信。2.0已经对非英文的支持进行了专门的开发,但目前还没有release,在 不久的将来应该可以完整的解决这个问题。目前,要么等待,要么就像我这样,用点阵字库瞒天过海。具体方法因为还不够成熟,就不公布了。

  无论如何,FLTK的目标还是针对嵌入式和封闭软件的开发,所以复杂的界面并非其长项,如果想做出花哨复杂的界面,还是用其他GUI库比较好,FLTK并不适合。

  综上所述,FLTK的优点和缺点都是非常的突出,如何取舍还是自己决定吧。

2006-04-16 22:02

posted @ 2006-06-07 23:36 cyantree 阅读(466) | 评论 (2)编辑 收藏

仅列出标题