|
- UID
- 1029342
- 性别
- 男
|
目录
一. UCGUI中的基本设计策略----微型.
二. 为什么UCGUI的消息处理机制会导致多对话框的问题.
三. UCGUI324与UCGUI390版本在处理多对话框上的几点不同之处.
四. 如何改进UCGUI390, 以使其支持在任意控件的点击消息当中弹出对话框.
问题:
caseWM_NOTIFY_PARENT:
Id = WM_GetId(pMsg->hWinSrc); //Id of widget
NCode = pMsg->Data.v; // Notification code
switch (NCode) {
case WM_NOTIFICATION_RELEASED: // React only if released
if (Id == GUI_ID_OK) { // OK Button
GUI_MessageBox("Message","caption",GUI_MESSAGEBOX_CF_MOVEABLE);
}
if (Id == GUI_ID_LISTBOX0 ){
pObj=LISTBOX_H2P(hListBox);
LISTBOX_GetItemText(hListBox,1,ListItemName,20); GUI_MessageBox("item is:",ListItemName,GUI_MESSAGEBOX_CF_MOVEABLE);
//改成下面这句正确..
//MESSAGEBOX_Create(ListItemName,"itemis:",GUI_MESSAGEBOX_CF_MOVEABLE);
}
在如上代码当中, 在点击ListBox时,执行GUI_MessageBox()会导致弹出N多对话框,以及"GUITASK.c: GUI_Lock() _EntranceCntoverflow "的错误提示. 但是点击按钮时, 执行GUI_MessageBox()没有问题, 这是什么原因??
论题分析:
深入UCGUI的消息处理机制当中,详细介绍一下为什么在UCGUI390版本中,仅有Button控件的点击支持弹出对话框,其它的控件均会导致出错呢?
UCGUI324版本当中, 我们详细的剖析了为什么在点击Button消息中弹出对话框会导致出错, 详细的分析可见"UCGUI窗体管理及消息处理机制分析.pdf"(可到www.ucgui.com/bbs当中下载).
[原创]有关UCGUI的几篇技术文章下载
http://www.ucgui.com/bbs/dispbbs.asp?boardID=1&ID=131&page=1
这里不再重复的讲先前讲过的东西了, 下面我们将大略介绍如下几点:
一. UCGUI中的基本设计策略----微型.
与其它一些同样是嵌入式的GUI图形系统相比, UCGUI很明显的一大区别是:微型; 这微型的特征主要体现在两点:节省空间, 包括代码空间与程序运行占用空间.
-----代码空间占用少, 是指其对于同样的功能, 其实现简单,结构简单,设计简单,复杂的功能放弃;
-----程序运行占用空间少, 是指支持GUI运行时, 所消耗的变量空间小, 这对于本来RAM空间就紧张的小型嵌入式应用, 是非常的重要的. 程序运行消息消耗的空间小, 主要有两个方面:
[1].消息处理不用队列,而是采取两个变量, 一个变量记载当前消息,一个变量记载先前消息,当前消息从外部输入驱动中获取更新, 处理消息时与先前消息进行比较, 处理完消息再将当前消息更新到先前消息变量中.这样处理起来,比起采用消息队列, 就省了不知道多少空间了,因为在启用MOSUE类设备时,移动消息是非常多的.不采用消息队列, 也导致了UGGUI中的所有的消息处理都是同步的, 但这对于UCGUI来说也不是什么严重的问题, 并不是必须的功能; 没有消息队列, 则每个消息的处理不能占用大量的时间, 否则严重影响消息处理的灵敏度,造成消息的丢失.但是这些问题都是可以接受的, 因来带来的空间效率带有帮助了.
[2].单一运行绪:UCGUI运行的时候, 仅有一条执行路径, 也就是单一运行绪.这与MINIGUI多线程版是有很大的差别的,熟悉MINIGUI的朋友都知道MINIGUI分了三个版本, 多进程版/多线程版/单一版.多线程版分如下线程:
-----用户程序是一个线程.
-----桌面程序是一个线程.
-----事集收集是一个线程.
-----时间Timer是一个线程.
-----创建窗口也可以单独启用一个线程.
分了线程,当然有些好处, 如计时器/消息接收不至被消息处理阻塞; 但是UCGUI中没有这些复杂的机制,从而少了很多的线程同步以及与其它系统的相关性(便于移植).而且在资源占用了又少了一层, 节省了线程资源.
[3].剪切处理, 窗口系统的剪切处理有两个要素, 一是时间效率;二是空间效率.UCGUI中采取的是空间策略, 每进行一次图形绘制,都必须处理剪切; 在时间效率优先的系统当中, 会计算过后就保存每个窗口的剪切矩形, 如果是在这个窗口上绘图, 就无须每一次绘图操作都进行剪切处理, 只须要判断是否处于剪切矩形之内即可, 当然这个判断也是很讲究策略的, 因为剪切矩形是一个系列,如果是绘制一个矩形, 这个矩形被分布在几个剪切矩形当中, 这个时候也能采取两种办法:一是逐点判断之后画点;二是再进行一次剪切计算,剪切出可以绘制的矩形.这两个方法其实也体现了空间与时间的问题, 不过第二种方法在时间上很优, 在空间上也仅是占用一时, 所以是比较优的. 但是如果要计算过每个窗体的剪切矩形后, 要保存起来, 供窗体上再次作画时用,这个空间占用则是比较大的.
二. 为什么UCGUI的消息处理机制会导致多对话框的问题.
同上面关于UCGUI中的消息机制的描述, 具体来看一看为什么会导致多话框支持上的问题.
[1].UCGUI中创建对话框后, 会形成一个独立的消息LOOP, 独自的进行消息处理. 我们已经说过, UCGUI中的所有消息处理都是同步的,而且是单一执行绪的. 所以这样一来, 明显就带来的一个问题, 试想如下一个点击消息中弹出窗体的流程:
----1.获取外部驱动的消息,更新了当前消息变量, 设当前消息为CurrentMsg, 先前旧消息为PrevMsg, 比较新旧消息,如单击发生的坐标及按下与否的状态.
----2.如果是外部驱动产生的新消息(如单击消息), 处理单击消息, .
----3.进入单击消息处理,发送单击消息给对应的当前窗体, 根据当前的点击坐标取得单击发生位置的窗体句柄.
----4.对应的消息窗体处理消息, 弹出对话框.
----5.更新消息,CurrentMsg=PrevMsg, 再转入第1步, 检测消息. |
|
