// filename: IRenderTarget.h
// author: enic
// date: 2014-02-12
#pragma once
#include "import_std.h"
namespace elib
{
class IRenerTarget
{
public:
virtual ~IRenerTarget(){}
// !!!這里原先的名字和Windows sdk中的DrawText，結(jié)果上當(dāng)了。表現(xiàn)在基類(lèi)定義的DrawText接口，派生類(lèi)始終調(diào)用不到
// 正確的class，感覺(jué)是虛函數(shù)表查的不對(duì)，后來(lái)發(fā)現(xiàn)泥馬明明函數(shù)名字都是DrawText結(jié)果派生類(lèi)調(diào)用DrawTextW編譯器都不
// 報(bào)錯(cuò)誤，然后把基類(lèi)的改了還居然就正常了，，，
// 最后發(fā)現(xiàn)是被windows sdk的UNICODE模式那些×××W ***A的宏忽悠了，然后編譯器這邊也沒(méi)能報(bào)錯(cuò)出來(lái)，導(dǎo)致運(yùn)行期間找
// 不到正確的虛函數(shù)然后傻逼了。
// 解決方案有兩個(gè)：1.在基類(lèi)中也引入Windows的頭文件，這樣大家一起被宏定義，始終是一致的名字。但是感覺(jué)不太好，仿
// 佛被綁架了一樣，我不喜歡這個(gè)感覺(jué)。而且不利于跨平臺(tái)（總覺(jué)得編譯器不夠給力，應(yīng)該報(bào)出來(lái)的）。或者是undefine，
// 或者把導(dǎo)致問(wèn)題的依賴(lài)文件移動(dòng)到cpp中，這樣應(yīng)該報(bào)錯(cuò)會(huì)明顯一點(diǎn)不至于到最后崩潰了無(wú)法分析(宏展開(kāi)才能發(fā)現(xiàn)代碼問(wèn)題)
// 2.該名字，果斷改了，，，以后windows api中有×××W ***A兩個(gè)版本的，果斷要記得危險(xiǎn)，，，
virtual bool DrawString(const estl::u16string& strText, int iX, int iY) = 0;
};
class CBaseRenderTarget : public IRenerTarget
{
public:
virtual bool DrawString(const estl::u16string& strText, int iX, int iY)
{
return false;
}
};
/*
class IRenderTexture
{};*/
}; //~ end of namespace elib
// filename: CDcRenderTarget.h
// author: enic
// date: 2014-02-13
// note:
// @2014-02-14：現(xiàn)在最糾結(jié)的事情是，怎么在PaintEvent的時(shí)候獲取到RenderTarget,目前只能確定一件事：
// 只有從NativeWnd才能獲取到DC，才可能創(chuàng)建出真實(shí)的RenderTarget，那么創(chuàng)建就只交給NativeWnd
// 然后通過(guò)Paint事件傳遞出去.
// 仔細(xì)想想，發(fā)現(xiàn)上面說(shuō)的方式也不行，上面的方式限制了paint的時(shí)機(jī)，也就是只有發(fā)生Paint事件
// 的時(shí)候才有可能得到Target然后繪圖，貌似不夠合理？下午想想有沒(méi)有別的辦法。
#pragma once
#include "../IRenderTarget.h"
#include "CDCT.hpp"
namespace elib
{
// DC渲染目標(biāo)
class CDcRenerTarget : public CBaseRenderTarget
{
public:
explicit CDcRenerTarget(CDCHandle dc);
virtual ~CDcRenerTarget();
public:
virtual bool DrawString(const estl::u16string& strText, int iX, int iY);
private:
CDCHandle m_dcHandle;
};
}; //~ end of namespace elib