用uCGUI画对话框时窗体和控件显示不全，后刷新的部分会破坏掉之前显示的部分。

传图太麻烦，有图版见 http://blog.sina.com.cn/s/blog_60c49bde0101kk1n.html?tj=1

图1-1

图1-2

图1-3

图1-4

图1-5

用uCGUI画对话框时窗体和控件显示不全，后刷新的部分会破坏掉之前显示的部分。开发板ALENTEK MiniSTM32V2.0，显示屏ALENTEK 7' TFTLCD MODULE，主芯片STM32F103RB。

下面记录一下解决过程和思路。

ALENTEK的MiniSTM32开发板自带有2.8寸屏的uCOS+uCGUI例程，但是没整合触摸功能。7寸屏有基本的显示和触摸例程，没有uCGUI例程。

先是在网上找直接能用的7寸屏整合uCGUI的例程，openedv上有几个，下载下来直接编译没问题，但是全部重新编译的话无法通过，显示的也只是基本的画线画色块功能，没有实现对话框的显示。

同时了解到uCGUI的源码中附带有VC仿真的工程，意识到这可是一大利器，花了些时间熟悉了使用方法和其中的各种例程。

同时还了解到有个叫uCGUIBuilder的图形化设计界面，可以快速创建对话框，也是一大利器。

既然没有没有7寸屏直接能用的例程，那就考虑自己移植看看吧，反正屏幕的底层驱动例程都有，移植过程看起来也比较方便，具体步骤参考网上各种移植说明。

运行结果如图1-4，可以看到是图1-2的按钮控件显示完之后整个屏幕就被刷新没了。

拿同样的代码在VC上仿真出来却是正常的效果就像图1-5那样。

这样就好办了，有一个正常的和一个不正常的，那只要对照着找差异就行了，VC和开发板同时调试，单步跟踪到一处变量差异，在图2-4的LCD_DrawBitMap（具体调用之层次关系见图2-1）执行完后观察到VC和MDK中_ClipContext.CurRect的值不一致,

图2-1

具体为在调用LCD_DrawBitMap前和进入LCD_DrawBitMap后_ClipContext.CurRect的值发生了变化，这本身应该只是一个参数传递的过程，不应该引起任何变量的变化。于是百度关键字参数传递错误，找了一篇帖子（http://www.amobbs.com/thread-4422928-1-1.html），高人总结出了可能的几种因素，其一就是堆栈大小设置是否正确。继续百度STM32堆栈大小设置，原来设置是在启动文件中（图2-6），图2-6

可这头文件一直是官方提供的，都是直接拿来用就行了，怎么这次还要自己作下修改？改大了堆栈大小之后再编译下载果然显示就正常了。

后来又进一步验证，在LCD_DrawBitMap是进入反汇编调试，发现是内核寄存器的记录的某些地址在进入LCD_DrawBitMap之前就已经不对了，可能是之前什么地方堆栈不够引起了混乱？

图2-2

自定义堆栈大小后：

图2-3

默认堆栈大小时：

图2-4

图2-5

总结一下，能够解决这问题很重要的两点：一是用的是开源代码可以层层跟踪到出问题的具体位置，二是有一个正常的工程可以作对比，否则只靠一个出错的工程要分析出来错误位置真不知要到什么时候了。

话说堆栈大小设置的问题大家都没有遇到过吗？看了很多的资料从来没看到过需要修改堆栈大小这一项。

图1-1

图1-2

图1-3

图1-4

图1-5

用uCGUI画对话框时窗体和控件显示不全，后刷新的部分会破坏掉之前显示的部分。开发板ALENTEK MiniSTM32V2.0，显示屏ALENTEK 7' TFTLCD MODULE，主芯片STM32F103RB。

下面记录一下解决过程和思路。

ALENTEK的MiniSTM32开发板自带有2.8寸屏的uCOS+uCGUI例程，但是没整合触摸功能。7寸屏有基本的显示和触摸例程，没有uCGUI例程。

先是在网上找直接能用的7寸屏整合uCGUI的例程，openedv上有几个，下载下来直接编译没问题，但是全部重新编译的话无法通过，显示的也只是基本的画线画色块功能，没有实现对话框的显示。

同时了解到uCGUI的源码中附带有VC仿真的工程，意识到这可是一大利器，花了些时间熟悉了使用方法和其中的各种例程。

同时还了解到有个叫uCGUIBuilder的图形化设计界面，可以快速创建对话框，也是一大利器。

既然没有没有7寸屏直接能用的例程，那就考虑自己移植看看吧，反正屏幕的底层驱动例程都有，移植过程看起来也比较方便，具体步骤参考网上各种移植说明。

运行结果如图1-4，可以看到是图1-2的按钮控件显示完之后整个屏幕就被刷新没了。

拿同样的代码在VC上仿真出来却是正常的效果就像图1-5那样。

这样就好办了，有一个正常的和一个不正常的，那只要对照着找差异就行了，VC和开发板同时调试，单步跟踪到一处变量差异，在图2-4的LCD_DrawBitMap（具体调用之层次关系见图2-1）执行完后观察到VC和MDK中_ClipContext.CurRect的值不一致,

图2-1

具体为在调用LCD_DrawBitMap前和进入LCD_DrawBitMap后_ClipContext.CurRect的值发生了变化，这本身应该只是一个参数传递的过程，不应该引起任何变量的变化。于是百度关键字参数传递错误，找了一篇帖子（http://www.amobbs.com/thread-4422928-1-1.html），高人总结出了可能的几种因素，其一就是堆栈大小设置是否正确。继续百度STM32堆栈大小设置，原来设置是在启动文件中（图2-6），图2-6

可这头文件一直是官方提供的，都是直接拿来用就行了，怎么这次还要自己作下修改？改大了堆栈大小之后再编译下载果然显示就正常了。

后来又进一步验证，在LCD_DrawBitMap是进入反汇编调试，发现是内核寄存器的记录的某些地址在进入LCD_DrawBitMap之前就已经不对了，可能是之前什么地方堆栈不够引起了混乱？

图2-2

自定义堆栈大小后：

图2-3

默认堆栈大小时：

图2-4

图2-5

总结一下，能够解决这问题很重要的两点：一是用的是开源代码可以层层跟踪到出问题的具体位置，二是有一个正常的工程可以作对比，否则只靠一个出错的工程要分析出来错误位置真不知要到什么时候了。

话说堆栈大小设置的问题大家都没有遇到过吗？看了很多的资料从来没看到过需要修改堆栈大小这一项。