- 追加された行はこの色です。
- 削除された行はこの色です。
#analog
#norelated
#contents
* Today プラグインサンプルプログラム3 [#ya388a19]
[[Today プラグインサンプルプログラム2]]では、背景を透過して、文字を書いてみました。~
文字が表示できたら、今度は画像を表示してみたくなるのが人情というもの。~
というわけで、ただ表示するだけでは面白くないので、α(アルファ/透明度)の情報を持ったPNG画像を、背景上にBlendして表示してみましょう。~
具体的には、以下のような画像を用意し、数字を背景上に描画します。~
#ref(digital.png,left,nowrap,デジタル数字)
絵じゃなくて字じゃん!というツッコミはなしでw~
わかりにくいかもしれませんが、背景が透過しており、なおかつ数字の縁にはアンチエイリアスがかかっています。~
白一色だと見にくいと思うので、同じサイズの黒の画像を裏に重ねて、少し右下にずらして影の効果を出しています。~
** ファイルパス作成 [#b53c2144]
まずは、読み込む画像ファイルのフルパスを作る必要があります。~
WindowsMobileは、相対パスが使えないという制限もありますし、そうでなかったとしても、フルパス指定の方が、何かと安全です。~
今回は、DLLと同じところに画像ファイルを置きます。~
なのでまず、DLLがアタッチされた時に、自分自身のパスを保存しておきます。~
現状、DLLアタッチ時に、リソースのロードをしているので、そこでDLLのパス保存もしておきましょう。~
自分自身のパスを得るには、DllMainの第1引数を指定して、GetModuleFileNameをコールします。~
通常、実行ファイルが自分自身のパスを得るには、第1引数にNULLを指定してGetModuleFileNameをコールしますが、DLLでそれをやると、DLLを呼び出した実行ファイルの名前が取れてきてしまいます。~
(Todayプラグインだと、「\Windows\shell32.exe」)~
今回は、DLL自身のパスを知りたいので、ちゃんとDLLのインスタンスハンドルを渡しましょう。~
実際に画像ファイルのパスを作りたい時には、このDLLのパスをベースに、ファイル名を入れ替えればいい事になります。~
本当は、makepathやsplitpathといった関数が使用できれば楽でよかったのですが、見あたらなかったので、自力で入れ替えています。~
処理としては、後ろから文字を調べて、最初に「\」が出てきたところより後ろを、読みたいファイル名に置き換えています。~
// パス作成
bool CApp::makePath( LPTSTR path, LPCTSTR fname )
{
int len = 0;
int len2 = 0;
int i = 0;
if( NULL == path || NULL == fname ){
return false;
}
if( NULL == ::lstrcpy( path, m_dllPath )){
return false;
}
len = ::lstrlen( path );
len2 = ::lstrlen( fname );
if( 0 >= len || 0 >= fname ){
return false;
}
if( MAX_PATH < len + len2 + 1 ){
return false;
}
for( i = 0; i < len; i++ ){
if( TEXT( '\\' ) == path[len-i-1] ){
break;
}
}
if( i == len ){
return false;
}
if( NULL == ::lstrcpy( path + len - i, fname )){
return false;
}
return true;
}
** DIBSection [#e399e3eb]
PNGファイルをロードする前に、ロードした画像を保存しておく領域が必要です。~
しかも、ただ保存しておくだけではなく、そこから裏画面に転送(描画)が可能な必要があります。~
さらに、今回はそこまではやりませんが、ピクセルデータをメモリ上で直接いじれると、色々と便利です。~
というわけで、これらが可能なDIBSectionを作成することにします。~
裏画面はそのまま表画面へと転送するので、24bitのRGB。~
画像をロードする領域は、透明度を扱える必要があるので、32bitのARGBで作成します。~
もちろん、ロードする画像に透明度がないようであれば、こちらも24bitで構いません。~
ただし、今までは、裏画面は表画面との互換性があるものを作成していましたが、固定で24bitのものとすることにより、裏画面と表画面の形式が異なってしまいます。~
異なるとどうなるかというと、転送(BitBlt)時のパフォーマンスが落ちるので、他のアイテムに比べて、一瞬遅れて表示されるように見えるかもしれません。~
まぁ、ゲーム等の頻繁に画面の書き換えが発生するような用途の場合には、このあたりを考慮してやり方を工夫する必要があると思いますが、必要なときに必要なところだけ書き換えればいいようなTodayアイテムであれば、あまり気にしなくてもいいでしょう。~