本文讲述了如何实现以下几个具体问题：
1、设置控件的背景为透明。
2、以D3D9为渲染层的时候，Tooltip工作不正常（一闪而过）。
3、模拟MessageBox。

1、设置控件的背景为透明

有3种方法来解决这个问题：

1、修改Imageset文件，提供相关的透明位图；
修改Looknfeel文件，使用透明位图进行绘制；
修改Scheme文件，使用新的外观配置。

2、在程序里写如下代码：

d_framewindow->setProperty("FrameEnabled","false");
d_framewindow->setProperty("BackgroundEnabled","false");

3、在LayoutEdit 中配置对象的FrameEnabled，和BackgroundEnabled属性都为false。

2、以D3D9为渲染层的时候，Tooltip工作不正常（一闪而过）。

该问题是BUG引起的，但不是CEGUI本身的问题。

出问题的语句在CEGuiD3D9BaseApplication.cpp中的这句：

guiSystem.injectTimePulse(GetTickCount() - d_lastTime);

明显是个有问题的语句。。。。这句话导致CEGUI内部的时间流逝记数完全是个乱的....并且比现实至少快1000倍。Tooltip默认显示7.5秒，7.5S * 000.1 = 7.5ns，所以显示的时候一闪而过。

改为

unsigned int time_diff = GetTickCount() - d_lastTime;
d_lastTime = GetTickCount();
guiSystem.injectTimePulse( time_diff * 0.001f)

而以OpenGL或者OGRE的渲染层则不会出现这个问题。

3、模拟MessageBox

 1、使用LayoutEdit 搭建一个MessageBox，然后在程序的适当位置加入如下代码：

bool handleMessageBoxBtnOKClicked( const CEGUI::EventArgs& args);
void CEGUI_MessageBox();


bool handleMessageBoxBtnOKClicked( const CEGUI::EventArgs& args)
{
    using namespace CEGUI;
    const WindowEvetArgs& WindowArgs = static_cast<const WindowEventArgs&>(args);
    WindowArgs.window->getParent()->setModalState(false);
    WindowArgs.window->getParent()->setVisible(false);
    WindowArgs.window->getParent()->destroy();   
}

void CEGUI_MessageBox(const CEGUI::String& layoutfileName)
{
    using namespace CEGUI;
    // 读取MessageBox的布局文件
    Window* msgbox = CEGUI::WindowManager::getSingleton().loadWindowLayout( layoutfileName );
    // 注册MessageBox的按钮事件
    msgbox->getChild("Frame/OK")->subscribeEvent( Window::EventMouseClick, Event::Subscriber( &handleMessageBoxBtnOKClicked) );
    // 将MessageBox的属性设置为模态窗口
  msgbox->setModalState(true);
    // 显示MessageBox
    CEGUI::System::getSingleton().getGUISheet()->addChildWindow(msgbox);
}

不要担心关于删除的问题，CEGUI采用延后一贞删除的策略，任何Destory操作都延后了。可以查看CEGUISystem的代码。

在MS里我们一般这样写关于MBox的代码：
int ret = MessageBox("123","123",NULL,MB_OKCANCEL);
if( ret == 6 )
{}
else
{}

别想实现象MS里的MessageBox，否则将面临相当复杂的“重入”问题。

而且因为我们事先已经知道如果MessageBox的某按钮被按下时需要做什么事，所以只需要把这部分的逻辑事先写好，然后注册到MessageBox里的相应按钮对象上去就可以了。

原文地址http://thatax.blog.163.com/blog/static/20892680200882711513145/

本文是扩展CEGUI控件库的第2部分，对FalButton.CPP文件的分析记录。
目的是探究下如何去控制 Renderer，从而彻底实现一个CEGUI没有的控件类型。

但是分析未完成，希望这些半成品能对大家有用。

PS：由于公司的网络限制，所以Blog很长时间未更新。家里还没电脑，上班偷偷写的....
下次将整理下单独编译CEGUI，并给出CEGUI与Ogre结合的详细步骤。

//=====================================================================================================================
// 2008.4.18
//=====================================================================================================================
本来打算今天探究下如何去控制 Renderer，从而彻底实现一个CEGUI没有的控件类型。

首先从FalButton开始切入，但是发现问题远没有想象中那么简单。
在先前对Falagard的翻译中得知，如果要绘制一个控件，需要定义规定的StateImagery。
所以我期望在FalButton中看到这些状态的集合，否则手册里规定的状态从哪来呢？
实际上我看到的是 "Pushed" : "PushedOff"; "Disabled" "Hover"之类的 魔字符串！
现在知道这些状态是哪来的了：在CEGUIfalagardWRBase项目里相关文件里这样定义的！这可真要命，太不可接受了。

OK，既然已经知道如何定义需要实现哪些状态，再找找和显示相关的代码，在这个对象中，只有一句跟这个相关：
wlf.getStateImagery(actualStateName(state)).render(*w);
1、wlf是WidgetLookFeel，
2、getStateImagery返回StateImagery，
获取WidgetLookFeel的唯一对象，然后得到一个叫actualStateName(state)的StateImagery，并调用它的render()方法来进行绘制。
以w为参数。w是什么？
w是d_window，继续查找这个成员变量，发现是WindowRenderer类的成员变量，回头看H文件的定义，FalButton继承自WindowRenderer。
跟WindowRenderer类似的还有很多***Renderer的文件，所以推测Button，Frame等简单控件类型的绘制都继承这个WindowRenderer。
而List等复合控件类型需要另外特别的***Renderer来实现绘制。

***Renderer里实现绘制，确实是这样的吗？如果是这样的话，为什么要调用StateImagery对象的render()方法。
如果要绘制什么东西，一定需要绘制它的参数信息，包括数据和规则，既然***Renderer是作为参数传递给StateImagery的render()，
那么***Renderer要么给出了绘制方法，要么给出数据，要么给出规则。现在虽然不能确定，但是应该是提供规则的可能性大一些。
[后面将证明是错误的，它提供的不是规则而是数据。]
现在又有2条路了：
1、WindowRenderer是什么东西。
2、StateImagery的render()到底做了什么事。

先查看WindowRenderer类的介绍：
// Base-class for the assignable WindowRenderer object
这是什么，可支持的窗口渲染器对象的基类？显然不太好对付。
从类视图中可以看到它的派生类，找个复合控件,EditboxWindowRenderer类的介绍：
// Base class for the EditboxWindowRenderer class
OK，现在知道如果不看***Renderer的代码的话，是不知道这个类做什么用的了。
所以还是顺着render()看。
有2个版本，但结构差不多，所以只盯着一个看先。
先看这个函数的介绍，没什么很详细的信息....这说明如果我们了解整个设计目的的话，这个函数是理所当然的。
没什么好说的，RTFS。
void StateImagery::render(Window& srcWindow, const ColourRect* modcols, const Rect* clipper) const    
{
 float base_z;

 // render all layers defined for this state
 for(LayersList::const_iterator curr = d_layers.begin(); curr != d_layers.end(); ++curr)
 {
  // TODO: Magic number removal
  base_z = -0.0000001f * static_cast<float>((*curr).getLayerPriority());
  (*curr).render(srcWindow, base_z, modcols, clipper, d_clipToDisplay);
 }
}

又冒出很多新鲜玩意出来了，就知道！
LayersList？估计就是 XML里的Layer关键字定义的那段东西，在CPP文件里的对应对象，暂时不管它的细节。
getLayerPriority？优先权？为什么要和-0.0000001f相乘？请教老大之后得知，这个Z值是给3D渲染器用的。因为
getLayerPriority返回的是整数，而3D渲染器的Z值是0到1，所以才需要这么乘一下。
再看看 *cuur.render() 接受的参数：1个窗口的引用，1个Z值，1个顶点颜色矩形，一个裁减矩形，还有一个d_clipToDisplay？

bool d_clipToDisplay; //!< true if Imagery for this state should be clipped to the display instead of winodw (effectively, not clipped).
如果为true，就是相对于显示器进行裁减，而不是窗口（实际上没裁减）？
构造函数里的初始化为d_clipToDisplay(false)，搜索操作这个变量的方法，发现跟XMLHelper扯上关系，
而整个CEGUI里没有调用这个方法来设置这个变量，看来是放出去给外部进行设置的，那就不管了先，等以后在某个例子里发现的时候再回头看。

好吧，现在继续LayersList的render()。
 // render all sections in this layer
 for(SectionList::const_iterator curr = d_sections.begin(); curr != d_sections.end(); ++curr)
  (*curr).render(srcWindow, base_z, modcols, clipper, clipToDisplay);
又是个遍历，不过这次遍历的是SectionList。

再次回忆上次LookNFeel里的定义：
StateImagery
 layer
  section = ImagerySection

而ImagerySection的层次是：
ImagerySection
 ImageryComponent
  Area
  Image
  VertFormat

那在这里预测，如果查找(*curr).render()，一定是遍历一个ComponentList，然后调用 (*xx).render()。

不过找到的是获取ImagerySection的代码：
const ImagerySection* sect =
  &WidgetLookManager::getSingleton().getWidgetLook(d_owner).getImagerySection(d_sectionName);
然后sect->render(...);

结果与预测的不太一样，在这个地方已经开始使用try和catch，说明已经开始实际的绘制操作，马上就可以知道WindowRenderer提供
的到底是数据信息，还是规则信息了！
与预测不一样的地方有2个：
1、获取的不是Component，而是ImagerySection，为什么？
2、没有遍历，为什么？
回头查看SectionList，
typedef std::vector<SectionSpecification> SectionList;
说明Layer里可以有很多section，而section再来指出是哪个ImagerySection。所以应该先获取ImagerySection。
而section和ImagerySection是1对1的关系，所以没有遍历。

继续看ImagerySection的render(...)，在里面发现了3个遍历：
FrameList:   FrameComponent   的render()
ImageryList: ImageryComponent 的render()
TextList:    TextComponent    的render()
FrameComponent   的render()里进行了一大堆的计算，然后分别绘制了Frame的4个角、4条边、1个背景。
虽然没看，但估计其他2个差不多。这就是实际的绘制工作了！

现在回头看看，Button有Frame吗？之前写Button的时候，只写了ImageryComponent。而我从FalButton开始切入，最后却看到了
FrameComponent的绘制，这说明了什么？

再从更大范围上整理一下：
我在XML文件里定义 Button的渲染器 FalButton，
FalButton里（通过d_window）判断当前按钮的状态（现在对于***Renderer到底是个什么还不清楚，等整理完就去看。），
再通过这个状态来（通过WidgetLookFeel对象）得到对应的StateImagery对象。
然后调用StateImagery对象的render()方法，以*w为参数。

然而现在来看，从调用StateImagery对象的render()方法开始，已经跟Button没关系了，一切都是按照规定好的流程在进行。
这说明如果我们要使用CEGUI的话，从这里开始就是不变的东西，如果要改变的话，要做的事情就比较多了。

在这之前，我们能控制的（自由度）就是（添加或减少一个）控件状态的定义。
但是在之前我写Button1的时候，没实现Hover状态下的代码，然后当我鼠标移到Button1的时候，就没图片显示出来。
如果按这个流程的话，得不到StateImagery对象，就不会调用render，所以就没图片显示出来，这就说的通了。

今天就到这里，下周顺着WindowRenderer开始查。

CEGUI学习笔记五-- 如何如何扩展CEGUI库（一）

本文以FrameWindow为对象，粗略的讲述了如何扩展CEGUI库，从而添加一个全新的基础控件类型。

需求：

如果你使用过FrameWindow，那么你一定可以发现，FrameWindow的4个角落都可以进行缩放。

如果我们需要固定某个角呢？比如制作一个聊天框，它可以放大缩小，但是左下角锚定。

最开始我一个个的看例子，似乎除了4角全缩放，就是不能缩放，看来例子里没有我们需要的。

再去看FrameWindow的头文件和CPP文件，只有一个关于设置是否可以缩放的函数SetSizingEnable(bool Setting)，和几个protected属性、根据鼠标坐标来判断是否进行缩放的函数。

看来FrameWindow派生时，没有做锚定某个角的处理。那么就去Window的头文件和CPP文件里找找吧。

很可惜结果也是没有。

现在的解决方法有2种：

1、修改或继承FrameWindow，使之支持锚定角落。

2、编写函数，响应EventMouse DOWN、Move、UP事件，使具体对象支持锚定缩放。

我选择了前者。因为这样修改之后的FrameWindow更加方便，而且我也讨厌去计算那些烦人的坐标，何况FrameWindow里本身就有计算这些坐标的内部方法。

OK，我们需要做的就是定义下规则：

// AchorCorner
#define AnchorLeftTop                     0x01
#define AnchorLeftBottom               0x02
#define AnchorRightTop                  0x04
#define AnchorRightBottom            0x08

然后我们定义关于锚定的变量

private:
    int d_anchorCorner;

之后我们需要在构造函数里添加关于我们的变量的初始化。因为我们希望对FrameWindow的改变不会对其原有的行为有所影响。因此我们将锚定点设置为：

d_anchorCorner = 0;

再来我们定义关于设置锚定的方法：

public:
     void setAnchorCorner( int anchorCorner);
     int    getAnchorCorner( void);

并且实现他们，先是获取对象的锚定状态：

int FrameWindow::getAnchorCorner(void)
{
     return d_anchorCorner;
}

然后是设置锚定，在这里，我采用以下规则：“锚定角由用户给出，如果该角落已经被设置，则将这个角取消”。这样，我们的set函数就可以给对象既添加锚定信息，又可以删除锚定信息了：

void FrameWindow::setAnchorCorner( int anchorCorner)
{
    if ( d_anchorCorner  &  anchorCorner)
              d_anchorCorner  ^= anchorCorner;
    else
              d_anchorCorner  |= anchorCorner;
}

现在我们重新编译一下CEGUI工程里的CEGUIBase，让它重新生成一个dll(DEBUG)和LIB(DEBUG_Static)。并且将原来的替换掉，就可以使用我们刚刚修改的FrameWindow了--只是在代码里。

好吧，现在我们已经开始往CEGUI的源代码里胡乱加代码了，因此一切都会变的不那么顺畅。实际上我想说的就是，你的LayoutEdit识别不出来这个FrameWindow了，如果要Add的话，会使劲的抛异常！

你可以试试不用布局器，而是写代码来进行界面布局。相信我，你一定会被统一坐标系统弄疯。

我的解决方案就是：全盘COPY一次FrameWindow的代码，然后添加改动，把它改个名字，比如frame2，然后作为一个新的控件使用。但是没完，我们还需要为这个控件添加属性。这个可以全盘照抄FrameWindowProperty.h和.cpp。

上个步骤不难，不过在这里还是想提醒下大家，注意命名的统一。

接着，为了配合我们的新控件frame2，我们需要
在Scheme文件里Copy映射，并修改相应名称。
你也可以在视感文件里COPY FrameWindow的外观配置，然后尝试着修改一下。（我尝试将默认背景改为透明背景时，这一步对我来说异常痛苦...我恨XML...），或者直接使用FrameWindow的外观来作为frame2的外观--它们俩长的完全一样！（在这里我使用Taharez风格的相关文件进行的实验。）

去LayoutEdit看看，它还是抛异常。肯定有什么不对劲的地方，从异常提示的信息可以看到，我们的frame2不在WindowFactory的创建列表里面。

OK，这表明我们还没有完全的COPY FrameWindow。为了能让WindowFactory顺顺当当的创建我们的frame2，接着找找关于FrameWindow的代码，看看我们有没有漏掉什么include ，或者 大规模的添加控件的代码。通过搜索整个解决方案，有以下几个文件跟工厂和FrameWindow相关：

CEGUI.h(75)
CEGUIBaseFactories.cpp(43)
CEGUIBaseFactories.h(45)
CEGUIBaseFactories.h(80)
CEGUIForwardRefs.h(88)

照着改就行。

先在代码里测试下frame2这个新玩意，如果我没有漏掉什么的话，你应该可以用代码创建一个frame2窗口，它和FrameWindow一模一样，除了多了个缩放锚定功能。

以上做的事对我来说有点烦琐，或者中间穿插了一些别的事情，总之我弄了1天...最后思维敏捷度降为负数，人完全处于放空状态了.oO。现在回头再看我做的事情，只记得当时人搞的晕晕的，但好象都是些CVCV，然后修改下名字...

照着FrameWindow做个frame2出来不难，同时这也是很好的练习目标，在完成之前，我在这里等你。

好了，现在我不得不告诉你一个噩耗：LayoutEdit依然不支持我们的frame2！而且报的错误还是frame2这个类型在工厂里不存在。

恩，LayoutEdit的文件夹下面有个ceguibase.dll，让我们来编译一个Release版本的dll扔进去看看？

满怀希望的运行LayoutEdit，结果还是报错！

OK，肯定还有什么地方是我没研究到的，不过这已经属于辅助工具开发的范畴了。当然将来在项目运用中，肯定会修改LayoutEdit，使它更加完善和强大，但这不是研究CEGUI本身的事情，所以对这个问题，我觉得暂时就放一放吧。等将来更加熟悉CEGUI的时候再回头来解决我们一路遗留下来的知识盲点。

可是总得有个解决方案，不是吗？以下是我的解决方法：

假设你在Scheme文件里将frame2映射为“Taharez/Frame2”，
那么你可以在LayoutEdit里添加FrameWindow，
然后手工修改.layout文件里面的Taharez/FrameWindow，改为Taharez/Frame2。
这样，在载入文件的时候，程序就生成的是我们的frame2了。

我迫切希望与大家交流，一同研究这个CEGUI，上班的时候不能上QQ，只能上MSN：kun123456765@live.cn。我MSN上一个好友都没有，它还不支持QQ一样的查找和群....555

在这里对下一步的主要学习方向做个展望。
举个例子：StaticImage和StaticText 都是DefaultWindow，DefaultWindow从代码上来看，就是Window。那就是说全部的控件都可以显示一个背景图片咯？但是为什么这俩个对象一个可以显示图片，一个不能显示图片呢？
是谁在控制这些具体控件类型的表现形式？在Scheme文件里，我们可以看到，这2个控件类型的FalagardRender不同，这个渲染器模块是如何工作的？

显然我们对frame2的扩展工作还没有结束！