投稿日：2012-05-17 Thu
たまには更新してみるか、ということで、ごそごそっと更新。＞＞お引越ししました(遅
３月にお引越ししまして、2DK(６畳×２＋１０畳くらいのキッチン、風呂、トイレ)から
1K(８畳フローリング＋3.8畳のキッチン、風呂トイレ別)にお引越し。
職場が玄関開けると見えるというほど近距離で、通勤時間徒歩３分。
引越し前は６：３０に家を出て駅で朝飯＋モーニングコーヒー、その後出勤だったん
だけど、現在は８：３０位に出て出勤、です。
近いといいよね。定時後家に帰ってくると１８時前には夕飯のご飯の炊飯器のSWを
ONして、まったりモード夕方版に突入。楽だわー。
＞＞自炊してんですよ、昼飯も作って。
引っ越してから、自炊してんですよ。
それまで外食だらけだったんだけど、自炊を初めたお陰で、時間はかかるけど、なんか楽だし、
時間が有益に使えますなぁ。注文して待ってるより、料理して時間経つほうが有益に感じる不思議。
まぁ、作ればすぐ食えるからねぇｗ
自炊も意外と面白くて、未だに続いてはいます。毎日消費期限と戦っていますけどね。
朝飯作るついでに昼飯も作って、弁当持参です。朝飯＝昼飯になるのはしょーがないwww
よく作るのは、炒め物としては肉キャベツ炒め、もやし炒め、ピーマン味噌炒め等の野菜炒めの類。
塩コショウを多めに入れて、少量のおかずでご飯を食える様にしています。
キャベツ1/4〜1/2か、もやし1袋に対して、大体塩コショウ大さじ１程度。止めに少量の醤油かな。
少量と言いつつ、なんか大さじ１位は入れてる気がする。
まぁ、もやしを1袋使い切るのは大変なんですけどねぇ。結構量がある。でも結構食えるから謎だ。
元々、もやし炒めを食いたくなって自炊始めたという感じではあるんですよ。理由があれなんですが。
最初はシャキシャキ感のある炒めを作れていたのですが、最近しなしな〜っとなっていて、炒め過ぎな
様子だったのでシャキシャキ感を戻すべく、試行錯誤。火を通して即効(1分程度？)で味付け開始すると
いい感じになるのが判った。もやし自体は日持ちしないので、実はそんなに頻繁に作れないんですけどね。
買出しを２日に１度でやってます。冷蔵庫小さいので、これ以上買うと入らないwww
※食費的な目安は、２日で1200円前後。他に調味料やらお米もあるので、大体月４万前後で計算。
あとは、漬物の代わりに、きゅうり５ｍｍ幅に斜めに切って、キムチの素大さじ１？程度＋味の素
小さじ１〜２、醤油大さじ多分２〜４。それをボールに入れて手でまぜる。
(自分で食う奴だから手でまぜちゃう。そのほうが早い)
昼飯の弁当に入れる場合は、朝飯＋弁当なのできゅうり２本使います。1食あたり１本ですかね。
大きさは標準的なやつ。まれに太いきゅうりとか手に入ったりするのですが、その場合そこそこの
量になるので、炒め物とかそっちの量を減らす感じですかね。
他には、ピーマンの味噌いためや、焼きナスも好きですよ。うまうま。
ピーマンの味噌いためは、インスタント味噌汁の味噌を使って作ります。これだと下手に味付け
に悩まなくていいのです。ピーマン４個位を種を抜いて、縦に千切り？にした後、軽く炒めてから
インスタント味噌汁の味噌を1/3袋程度入れて、ラストに醤油大さじ０．５〜１程度。これでおいしい。
ピーマンがしなぁ〜っとする程度まで炒めると、いい味しますぜ。
野菜炒め以外には、フライパンで鮭を焼いてる位かな。好きなんですよ、塩鮭。うめぇ。
弁当に入れる場合は、鮭＋炒め物＋上のきゅうり和えとか。炒め物を作ってる暇なかったりすると、
手抜きで卵焼きだったりしますが。
そうそう、たまーにですけど、万能葱を炒めてますね。
葱の白いほうを５ｃｍ位に切ってから縦に十字に切るか、斜めに切るかして、これを炒める。
塩コショウ大さじ半分程度で味つけ。意外と食えるものだな、これ。おいしい。多少焦がす感じにすると
いい風味が出ます。
自炊してわかったことが、１食あたりのごはん消費量は１合、米袋5kgだと月半分程度しか持たない。
意外と食ってるなぁと関心するね。まぁ、昔からよく食べる方ではあるのですが。
なお、10kgだと一月弱なのですが、それだけ使うとしけってしまいそうなので、5kg×2が一月分です。
今のところ、作れるメニューが少ないので、今後もうちょい増やしたい所ではあるんですよ。弁当も
もうちょい色彩をよくしたい感じでもあるし。
使ったことの無い野菜で料理が浮かぶと、購入した後にうきうきしながら帰宅し、準備を整えてから
料理開始です。まさかこの年になってこんな感覚が味わえるとはなぁ、と自分でも意外な気持ちに
なっているのですが。料理おもしれぇ。
あと、どこぞのオリーブオイルじゃないんですが、塩コショウや醤油どばー！の癖を直さないと…。
結構入れすぎて、しょっぺー！とか、かれぇwwwwとかありすぎて。幾ら東北育ちとはいえ、限度が
ありますよね。
＞＞自炊ネタの後ですが、ネット環境が良くなった！
引越し先もアパートなんですが、全部で２４部屋あるので、NTT東のフレッツネクストHighSpeed
タイプでネットを整えました。元々ここは光の設備が入ってた様で、一週間で光開通です。
早いね〜早いね〜。
測定サイトで図ったら２０Mあたりしか出てなく、こんなもんかーとしょぼーんしてたんだけど、KDDIの
測定サイトで仙台サーバを使って調べて見たら、90Mbps近く出るんですよ。めっさ早い。
まぁ、ニコニコとか再生しても、こんな速度でませんけどね。(人が少ない時間帯はまれに出る)
本来、100Mbps契約だと50Mbpsが良い所なのですが、今回契約しているのは、アパートまで
1Gbpsで来ていて、各部屋に100Mbpsで光ファイバで配信するタイプなので、こんな値が出るん
ですわね。早いっていいなぁ・・・でもサーバーが遅いから意味ねーなぁ…。
ちなみに、光に変えた人はわかると思いますが、光に変えると、電話加入権は休止状態に入ります。
そして10年メタル線を使わないと消滅します。10年以内であれば、引っ越し先に光が無い！という場合
にメタル線で契約可能で、再び加入権を使って電話を使える様になります。
まぁ、私も持ってる加入権は会社から安く譲って貰ったやつなので、もう消滅してもいいけどね〜ｗ
…と、新しい生活をなんだかんだでエンジョイしているうなちょでありましたとさ。
まぁ、スーパーへ買い物に行くとか、買出し用ママチャリ(後ろにかご増設済)を購入したとか(他に、
遠距離用にMTBっぽいちゃりんこはある)、いろいろあるんですけどね。
かご便利だなぁ…ということで、今回はここまで。
(*ﾟωﾟ)ﾉｼ ｱｰﾋｻﾋﾞｻﾀﾞﾅｰ ﾋｻﾋﾞｻｲｳﾅ(ﾟωﾟ*)
投稿日：2012-01-18 Wed
さて、スマホ壁紙コンバーターで使ったDrawImageについて、メモの変わりに残してみよう。コンバーターのコードは長いし他の機能もあるので、今回は検証用もかねて、DrawImageのテスト用ツールを作って検証してみた。
【手順１】GDI+の初期化
MFCでGdiplusを使うには、初期化をしてやらねばならない。
こんな感じ。
BOOL CDrawImageTestApp::InitInstance()
{
// アプリケーション マニフェストが visual スタイルを有効にするために、
// ComCtl32.dll バージョン 6 以降の使用を指定する場合は、
// Windows XP に InitCommonControls() が必要です。さもなければ、ウィンドウ作成はすべて失敗します。
InitCommonControls();
CWinApp::InitInstance();
AfxEnableControlContainer();
// 標準初期化
// これらの機能を使わずに、最終的な実行可能ファイルのサイズを縮小したい場合は、
// 以下から、不要な初期化ルーチンを
// 削除してください。
// 設定が格納されているレジストリ キーを変更します。
// TODO: この文字列を、会社名または組織名などの、
// 適切な文字列に変更してください。
//SetRegistryKey(_T("アプリケーション ウィザードで生成されたローカル アプリケーション"));
free( (void *)m_pszProfileName );
m_pszProfileName = _tcsdup( _T(".\\DrawImageTest.ini") );
//GDI+初期化コード
GdiplusStartupInput GSInput;
GdiplusStartupOutput GSOutput;
ULONG_PTR pulToken;
ULONG_PTR pulHookToken;
GSInput.SuppressBackgroundThread = TRUE;
GdiplusStartup( &pulToken, &GSInput, &GSOutput );
GSOutput.NotificationHook( &pulHookToken );
CDrawImageTestDlg dlg;
m_pMainWnd = &dlg;
INT_PTR nResponse = dlg.DoModal();
if (nResponse == IDOK)
{
// TODO: ダイアログが <OK> で消された時のコードを
// 記述してください。
}
else if (nResponse == IDCANCEL)
{
// TODO: ダイアログが <キャンセル> で消された時のコードを
// 記述してください。
}
//GDI+後始末コード
GSOutput.NotificationUnhook( pulHookToken );
GdiplusShutdown( pulToken );
// ダイアログは閉じられました。アプリケーションのメッセージ ポンプを開始しないで
// アプリケーションを終了するために FALSE を返してください。
return FALSE;
}
※コンパイラが古い(2003)ので注意！
基本的には、上記に示す通りＳｔａｒｔｕｐとＳｈｕｔｄｏｗｎを呼び出すだけ。
だが、ここで驚いたのがWin7の32Bitと64Bitでは、(32ビットアプリの)挙動が少々違う模様だ、ということ。
なんでかしらんが、コンバーターは上記の用なフックとかバックグラウンドスレッド停止(TRUE設定している所)とかやって無いんだけど、問題無く動くのに対して、この検証用ツールはエラーで動かなかった。
コンバーターはWin7 64Bitなんだけど、ツールはWin7 32Bit。てことは、WOW64の環境だとエラーにならないってことらしい。なんでだろうな…。
まぁ、動くからいいか。
これは他の人のBlogを参考に作ったのであるが、コンバーターではGdiplusStartup()の第3パラメータはNULL。
とりあえず、(このツールはダイアログアプリなので) DoModal()を挟んでおけばOK。
【手順２】ＤｒａｗＩｍａｇｅを使ってみよう
次、使う方法。
画像を変換するのは、１つのメッセージでやらせて、1行で変換できる様にした。
ヘッダ：stdafx.h
〜途中省略〜
#include <atlImage.h>
#include <gdiplus.h>
using namespace Gdiplus;
#pragma comment( lib, "gdiplus.lib" )
ヘッダ：CDrawImageTestDlg.h
#pragma once
#define WM_UPDATEDRAW (WM_USER+0x0001)
class CDrawImageTestDlg : public CDialog
{
〜途中省略〜
// 実装
protected:
〜途中省略〜
DECLARE_MESSAGE_MAP()
LRESULT OnUpdateDraw( WPARAM wp, LPARAM lp );
private:
CImage m_ImgBase;
CBitmap m_BmpBase; //m_ImgBaseと透過の画像を保持する
CDC m_DCBase;
CBitmap m_BmpDraw; //拡大縮小後の画像を保持する描画用画像
CDC m_DCDraw;
CSize m_szDraw;
int m_nDrawMode;
CString m_strDrawMode;
};
ソースコード：CDrawImageTestDlg.cpp
BEGIN_MESSAGE_MAP(CDrawImageTestDlg, CDialog)
〜途中省略〜
//}}AFX_MSG_MAP
ON_MESSAGE( WM_UPDATEDRAW, OnUpdateDraw )
END_MESSAGE_MAP()
//初期化ルーチン
BOOL CDrawImageTestDlg::OnInitDialog()
{
CDialog::OnInitDialog();
// このダイアログのアイコンを設定します。アプリケーションのメイン ウィンドウがダイアログでない場合、
// Framework は、この設定を自動的に行います。
SetIcon(m_hIcon, TRUE); // 大きいアイコンの設定
SetIcon(m_hIcon, FALSE); // 小さいアイコンの設定
// TODO: 初期化をここに追加します。
CString strFile = theApp.GetProfileString( "SETTING", "ImageFile", ".\\una.png" );
m_ImgBase.Load( strFile );
PostMessage( WM_UPDATEDRAW );
return TRUE; // フォーカスをコントロールに設定した場合を除き、TRUE を返します。
}
//拡大・縮小ルーチン
LRESULT CDrawImageTestDlg::OnUpdateDraw( WPARAM wp, LPARAM lp )
{
//各種画像エリアとペアのDCの削除
if( m_BmpBase.GetSafeHandle() != NULL ){
m_DCBase.DeleteDC();
m_BmpBase.DeleteObject();
}
if( m_BmpDraw.GetSafeHandle() != NULL ){
m_DCDraw.DeleteDC();
m_BmpDraw.DeleteObject();
}
//クライアント矩形取得
CRect rcClient;
GetClientRect( &rcClient );
m_szDraw.SetSize( rcClient.Width(), rcClient.Height() );
//画像エリア作成
CDC* pWndDC = GetDC();
m_BmpBase.CreateCompatibleBitmap( pWndDC, m_ImgBase.GetWidth(), m_ImgBase.GetHeight() );
m_DCBase.CreateCompatibleDC( pWndDC );
m_BmpDraw.CreateCompatibleBitmap( pWndDC, m_szDraw.cx, m_szDraw.cy );
m_DCDraw.CreateCompatibleDC( pWndDC );
ReleaseDC( pWndDC );
m_DCBase.SelectObject( &m_BmpBase ); //これを忘れると真っ黒画像！！！
m_DCDraw.SelectObject( &m_BmpDraw );
//Image->Bitmap
m_ImgBase.BitBlt( m_DCBase.GetSafeHdc(), 0, 0, SRCCOPY );
//Bitmapオブジェクトを、HBITMAPから生成
Bitmap* pBmp = Bitmap::FromHBITMAP( (HBITMAP )m_BmpBase.GetSafeHandle(), NULL );
//m_DCDrawを出力とするGraphicsオブジェクト作成
Graphics Grap( m_DCDraw.GetSafeHdc() );
//補完モード設定
switch( m_nDrawMode ){
default:
case 0: Grap.SetInterpolationMode( InterpolationModeNearestNeighbor );
m_strDrawMode = "Neighbor";
break;
case 1: Grap.SetInterpolationMode( InterpolationModeBilinear );
m_strDrawMode = "Bilinear";
break;
case 2: Grap.SetInterpolationMode( InterpolationModeHighQualityBilinear );
m_strDrawMode = "HighQualityBilinear";
break;
case 3: Grap.SetInterpolationMode( InterpolationModeBicubic );
m_strDrawMode = "BiCubic";
break;
case 4: Grap.SetInterpolationMode( InterpolationModeHighQualityBicubic );
m_strDrawMode = "HighQualityBicubic";
break;
}
//Bitmapオブジェクトの持つ画像を、Graphicsオブジェクトへ転送(クライアントの大きさに拡大・縮小)
Grap.DrawImage( pBmp, 0, 0, rcClient.Width(), rcClient.Height() );
//使わなくなったBitmapオブジェクトの削除
//Graphicsオブジェクトはスコープ外に行ったら消える(…かもしれない？)
delete pBmp;
//ウィンドウ再描画指示
Invalidate( FALSE );
return( 0 );
}
m_ImgBaseには、OnInitDialog()でＬｏａｄ（）を使って画像を読み込んである。これでBMPの他、Jpeg、PNG、GIF等も読める。
m_DCBase & m_BmpBaseは、m_ImgBase の画像をCDCとCBitmapで使うために確保してあるワークみたいなもの。
後で説明するが、正直ＨＢＩＴＭＡＰが欲しいだけなので、別段メンバーで確保しておく必要はなかったかもしれない…
※ただし、m_ImgBaseからは取得できなかった。
(方法があるかもしれないけど、少なくともGet〜()という処理の呼び出しでは取得できなかった)
m_DCDraw & m_BmpDraw は、ウィンドウへの描画処理 (OnPaint()) へ拡大・縮小した画像を渡すためのバッファ。
こうやって、加工済画像を確保しておくのは、最近の私のお気に入り。
再拡大・縮小が必要の無い再描画指示ってあるわけで、その都度拡大・縮小したくないってだけ。
この処理は単純に拡大縮小しているだけだけど、画像に対して直接編集をかけるコードが大量にあるツール等を作ったら、再描画処理（OnPaint())に編集コードは書きたくは無い…！と考えているのですよ。
それに、途中どこで再描画が入るかわからんので、自分で再描画コードを割り込ませちゃっても大丈夫な様に、描画用とワークを分けてある。
結局、m_BmpBase、こいつは、DrawImage()へ渡すための等倍画像を保持している、と思えばOK。
なんでこんな回りくどい事をするかというと、DrawImage()へ渡すための画像は、Gdiplus::Image でなければならないから。
IStream経由でもできるけど、こいつは面倒なので、HBITMAPから持ってくる方法を探していたら…
・DrawImage()の元画像ってGdiplus::Imageのポインタか・・・
・GlobalAlloc()だのなんだの呼び出してIStreamに渡してImage作るのか〜…めんどくｓ（ｒｙ
・IStreamにどこから格納するんだろ？BITMAPINFOHEADER入れんのか？・・・うん、わからん！
・HBITMAPから画像を持ってこれるのあるかな・・・（ヘッダ漁り)
・ほぉ、Gdiplus::Bitmapが持ってこれるか…FromHBITMAPはぐぐる先生に聞いたほうが早そうだ
・ん？Bitmapって、スーパークラスがImageなんだなー…
・もしかして、もしかして、派生してるBitmapが、指定できたりしないか…？（改造改造・・・）
・やった、Bitmapでも使えるぞ！！！
という流れ。だから、画像を一度HBITMAPに持ち直す必要があった。
CImageはHBITMAPなさそうだったので、簡単にBitBlt()で転送させることにした。
そのために、m_DCBaseが必要。まぁm_BmpBaseをいじくるには、DCあったほうが楽だしね。
再度ファイルを読み込む場合は、m_BmpBase.GetSafeHandle()がNULL以外の場合に限り、DeleteObject()してる。
(当然ペアになっているm_DCBaseも消します。なお、先にDCを消すのが良い・・・のかな？いちいちSelectObject()したくねーしなー)
まぁ、クリアしないで使う訳にもいきませんからね。
拡大・縮小処理(OnUpdateDraw()) をメッセージにしているのは、単純に描画指示とのぶつかりをある程度抑止したいからってだけで、これといった深い意味は無い。
【手順３】拡大・縮小の際の補完モードを変更するべ
Gdiplus::Graphicsには、拡大・縮小に使うロジック (補完モード) が設定できる。
ソース内でも指定しているが、Gdiplus::Graphics::SetInterpolationMode()という関数があり、こいつに以下のパラメータを渡すことで設定する。
InterpolationModeNearestNeighbor
InterpolationModeBilinear
InterpolationModeHighQualityBilinear
InterpolationModeBicubic
InterpolationModeHighQualityBicubic
なお、こいつらはGdiplus名称空間にいるので、using namespace Gdiplus をつけていない場合は、きちんとGdiplus::を付けましょうね。
※おいらは、未だに名称空間なんてなんでできたんだろ？って思ってますけどね〜。
どうでもいいけど、namespaceはIntelliSense(2003のね)にでてこねぇ…ﾏﾝﾄﾞｸｾ
さて、前記OnUpdateDraw()の場合は、GraphicsをGrapという名前で使っているので、Grap.SetInterpolationMode(ほにゃらら)と呼び出せばOKです。
あ、DrawImage()の前に呼び出さないと意味ないよ？
※”ほにゃらら”がコンパイルエラーになった？知らんがな(´・ω・｀)
なお、StreｔｃｈBltは、NearestNeighborが使われています。(全タイプ試してみるとわかります。ただ、微妙に違いますけどね)
BilinearやBibubicにするだけで効果が見えるのですが、斜め線とかの場合、線が切れているのが見えてしまいます。
なんとか補完しているのを隠したいという場合は、HighQualityの方を指定すると幸せになれるかもしれません。
ただし、これは多少画像がぼやけるので注意です。一度お試ししてみるのをお勧めします。
※思ったよりがんばって補完してくれます。３〜４倍拡大した線も、ドット境界が結構隠れてしまいます
【終わりだよっ！】
いずれにせよ、StretchBlt()を使うよりはきれいに拡大・縮小できるのではないかと思います。
いろいろ自分でロジックを組むのもよいのですが、どうせすでにOSがある程度できるものをもっていて、さらに使うまでそんなに苦労しないのですから、使わない手はないかと思います。
・・・まぁ、GDI+の土俵で動く関係上、ある程度環境依存になるのはしょうがないんでしょうね。
もしエラーがでる環境の場合、StrechBlt()で我慢してもらうという場合は、フラグで制御すればよろしいかと思います。
せめて、SetStretchBltMode( HALFTONE ) だの、同( COLORONCOLOR )位は付けてあげたいものです。
まぁ、ぐぐってもなかなかMFCでHBITMAPの画像を使うというものが見つけれなかったので書いてみました。
(もちろん参考にした所はあるので、皆無ではないですよ。ただ探すと.NETFrameworkのだったり、C#とかだしねぇ…？)
実際、スマホ壁紙コンバーターの場合は、一度ファイルに保存してそれを読み出すという荒業も使ってましたからねぇ。
gdiplusのヘッダを見てHBITMAPから持ってこれるのはわかったので、これは収穫あったなーという所。
※ただし、アプリのお仕事が終わりそうなので、仕事には使えない・・・かもしれない(´・ω・｀)ｼｮﾎﾞｰﾝ
(*ﾟωﾟ)ﾉ最近年とったので、メモしておかないと忘れるのだよっ！
投稿日：2012-01-10 Tue
久々に更新してみる。・・・と言っても、ROは最近ラグが酷くてテンション落ちまくってるので、ネタとしてはMFCとかになっちゃうね。
【MFC】PlgBlt()で画像の回転をしてみた
職場で手の空いたときに実験してみた。
PlgBlt()は、元となる四角形の画像の左上と、これに隣接する右上、左下の３点を指定(４点目は平行四辺形として
自動的に計算される)すると、回転できますよ、という画像転送API。
この３点の指定は座標で指定します。
こいつを使って面白いなぁと思ったのは、回転する角度で処理時間が変わるという所でしょうか。
90度のエリア(0,90,180,270)は早いとか、ある象限は多少早いとかあるみたいです。
また、当然ながら、でかい画像を回転させると、時間が掛かります。
(試してみたところ、1600x1200の画像を回転させると、大体200ミリ秒程度かかってました。元画像はDDB？
(DirectDrawのサーフェイス)です)
サンプルコードはインターネットのあちこちで転がっているのと、職場のソースコードは持ち出せないので、ｇｄｇｄと
文章で書いているだけなので、サンプルコードを見たい人は他を当たってくださいまし。
まぁ、綺麗に回転、というわけにはいきませんが、とりあえず回転できればいいやーという方向けのAPIでした。
【Explorer？Aero？】やっと直った個人設定・壁紙設定 (Windows7 64Bit)
自宅のPCはWindows7 64Bitを使ってるのですが、昨年末に突然HDDが多少ダメージを受けていまして、帰宅後
PCを起動したら、異常に重かったんですよ。
CHKDSKかけたら、いくつかCドライブのファイルがぶっとびました。
イベントログみたら、前回起動の分で、1秒の間にえらい数のNTFSの警告が出てた。久々にみた。
イベントログで調べてみたら、thumbcache.dllとthemeui.dll、そしてticft.ratという３つが壊れてました。
ところが、themeservice.dllは無事なので、Aeroとかは動きますし、個人設定も開くのですが、壁紙候補の
サムネイルが出てこなくなったんですよね。
ネットを調べていたら、Windows7 64Bitのthemeui.dllはあったので入れてみたのですがだめでした。
まぁ、壁紙設定でちょっと不便なだけだったので放置したのですが、後述のスマートフォン用壁紙変換ツールを作って
動作検証にPictureフォルダを開いたら・・・
(*ﾟωﾟ)なぁなぁ、画像何かなんだかわかんねー なんで？(ﾟωﾟ*)
(*ﾟωﾟ)サムネイルでないんだわ･･･表示する設定なのに！ 何かやったろ？(ﾟωﾟ*)
まぁ、どうやら個人設定の壁紙サムネイルが出てないのに関連しているんだろうなーと思って、再び調査を開始。
とりあえず、上記のCHKDSKでぶっとんだ各ファイルは、幸いというかなんというか、夏にCドライブがふっとびかけた
際に取ったバックアップフォルダにあったので、３つのファイルをコピーして復元させてthemeサービスを再起動
したら、復活しました。
まぁ、おそらくthumbcache.dllが無いから、サムネイルが見えなくなっていただけだとは思うのですが。
※そーいえば、縮小版でサムネイルを表示させているのに、thumbdbが無いとおもったら、Vista以降？でサム
ネイルの保存方法変更になっていたんですね。
これはこれで問題があるらしく、一定量以上たまるとサムネイルデータが壊れるのでクリーンアップの縮小表示？を
選択して消去して作り直さないとだめとかあるらしいですが…
【手抜き】スマートフォン用壁紙変換ツール
Twitterでつぶやいたのがこれ。
スマートフォンの壁紙って、画面横の２倍サイズ×高さ(等倍)っていうサイズなんですよね。
私の場合、Xperia aeroは480x854なので、960x854というサイズです。
※単にアプリ側で横サイズ×２倍という風に処理しているだけなので、フィーチャーフォンの横サイズの半分を
指定してやれば、フィーチャーフォン用も作れます。
そして、この壁紙をつくろうと思ったら､元画像が縦長か横長でどちらかに合わせてからはみ出たところを切り取る、
という感じで拡大縮小・トリミング・ポジショニングをしなければなりませんが、いちいち画像編集ソフトを起動する
のもめんどい。
…という訳で、簡単に変換できるツールを作ってみた訳です。
Explorerから画像ファイル(PNG,JPG,BMP等Windowsが標準でサポートしてるのは読めるはず)をDrag&Dropでツールに
落とすと、リストに追加されます。
リストを選択すると画像化しますが、基本的には画面枠内に収まる用に縮小・拡大しています。
縦長だったら横が不足気味になりますが。
チェックボックスで短辺を枠にあわせることもできて、これを選択すると画像が枠からはみ出ます。
初期配置で、上/左寄せ、中央配置、下/右寄せという位置の設定も可能です。
画像はマウス左ボタンで移動できますし、この状態からの拡大縮小はホイールで0.5%単位に変更できます。
これらの機能を組み合わせると、簡単に変換できちゃう・・・かもしれない。
一応自分で使って過不足はなくなったので、基本的な機能はできたかなーと。
あとは、作成した画像の転送と壁紙設定だけど、これはスマートフォン側でがんばって設定してね！ってことで。
今回のツールでは、拡大・縮小を綺麗にやりたい！という願望がありました。
まぁ、PCの壁紙は、起動しているアプリを全画面で使う関係上どうでもいいのですが、スマートフォンの場合、画面
ロック解除やホームでは壁紙が見えてしまうので、どうせなら綺麗に拡大縮小したかったのです。
ところが、GDIのStretchBlt()の場合、SetStretchBltMode( HALFTONE )をやっても、綺麗にならない。
なぜかHALFTONE設定が聞いていない感じがしましたが。
インターネットを探したところ、GDI+のDrawImageを使うと綺麗にいけるよ、という記事があったので、チャレンジ
してみました。
GDI+を使うには初期化と後始末が必要なので、ダイアログアプリケーションで作成されるメインダイアログウィンドウ
の生成前にStartupを、DoModal()の後にCleanupを入れました。
そして、CImageで指定画像を読み込んでそれをテンポラリのCBitmap/CDCペアに転送し、テンポラリの
CBitmapハンドルからGdiplus::Bitmapへ変換し、これをGraphic::DrawImageしてやったら、綺麗に拡大縮小
ができました。いやまじで綺麗だ。
(専門家からすりゃ大して綺麗でないかもしれないけど、普通に見る分には綺麗だよ！)
ここでStretchBltとDrawImageの比較画像がでてくりゃ最高なんだろうけど、そんなもの作るつもりはねー！
(*ﾟωﾟ)手抜き？ ただ面倒くさがってるだけ(ﾟωﾟ*)当然ｼﾞｬﾝ
まぁ、最初は、CImageの画像をテンポラリファイルに保存して、それをImage::FromFileで読み込んで
DrawImageで拡大縮小、なんていうことをやってたりしましたが、GDI+のヘッダ見てみたら、Bitmapって
CBitmapから直接作れるし、Bitmap自体がImageを継承してるじゃないですか。
だったら、DrawImageの第一パラメータ(Imageを渡す)に使えるんじゃね？と思ってBitmap::FromHBITMAP
で画像をBitmapクラスに格納してやってみたら、動くから助かった。
IStream経由でImage作らないといけないのか？とか思ってたので… (GlobalAllocしてうんぬんはめんd(ry )
えらい手抜きの方法があったもんだ。
あ、そうそう。Bitmap::FromHBITMAP()の第２パラメータのHPALETTEは、フルカラーBitmap使ってるならば
NULLで良いみたいです。
HPALETTEなんてCBitmapで取れないっぽかったので、やけくそぎみにNULL設定したら動いたのですよ。
まぁ、やってみるもんですなぁ。
※どうしてもパレットが必要となる場合(Highカラーとかの画像)は、CBitmap::GetObjectで取得する(できた
っけかな…？)か、24ビットBitmapを作ってそこにBitBltしてやればフルカラー画像変換できますから、
それでGdiplus::Bitmap::FromHBITMAPすればいけると思われます。
(意識してやってないけど、このツールではCImage→CBitmap/CDCペアへBitBlt()してるので、できるかも
しれない？)
最近は、こんな感じですかねぇ。
(*ﾟωﾟ)ﾉ そうそう、AC6のフライトタイムが432時間行ったよ！ Mission数15しかないのに飽きないねぇ(ﾟωﾟ*)
投稿日：2011-10-19 Wed
久々にMFC書き書き。最近、よくMFCのウィンドウクラス(CDialogがメインだけど)でワーカースレッドを
使うので、メモ代わりに書いておこう。
・ウィンドウ(クラス)に所属するワーカースレッドの手抜きメンバアクセス
ワーカースレッドは、static宣言するのでそのままではクラスメンバにアクセスできない。
簡単に言うと、thisポインタが無い。
スレッドパラメータでthisを渡して、参照ポインタを付ければアクセスできるのだが、
さすがに面倒。
最近は、ワーカースレッドから呼ばれる処理を追加して、そこの中にメインの処理を書いている。
class CWorkerTestDlg : public CDialog
{
public:
CWorkerTestDlg();
virtual ~CWorkerTestDlg();
protected:
virtual BOOL OnInitDialog();
afx_msg void OnDestroy();
afx_msg void OnPaint();
afx_msg void OnTimer( UINT_PTR nIDEvent );
private:
BOOL m_fAbortThread;
CWinThread* m_thWorkerThread;
UINT WorkerExecute();
static UINT WorkerThread( void* pParam );
BOOL BeginWorkerThread();
};
UINT CWorkerTestDlg::WorkerExecute()
{
while( m_fAbortThread == FALSE ){
処理ごにょごにょ
}
return( 0 );
}
UINT CWorkerTestDlg::WorkerThread( void* pParam )
{
CWorkerTestDlg* pDlg = (CWorkerTestDlg *)pParam;
UINT uiResult = pDlg->WorkerExecute();
pDlg->m_thWorkerThread = NULL;
return( uiResult );
}
BOOL CWorkerTestDlg::BeginThread()
{
m_fAbortThread = FALSE;
m_thWorkerThread = AfxBeginThread( WorkerThread, this );
return( m_thWorkerThread != NULL ? TRUE : FALSE );
}
上記処理では、「WorkerExecute()」が、手抜きワーカースレッド。
処理自体は、WorkerThread()のタイムスライスで動いてるけど、「pDlg->WorkerExecute()」
としている為、WorkerExecute()はthisポインタがあり、WorkerThread()のpDlgポインタが、
WorkerExecute()ではthisポインタとなる。
この記述をし始めてから、大分楽になった気もするが、どうなんだろうなぁ…？
ワーカースレッドの起動は、上のBeginThread()を呼ぶ。
まぁ、こんな感じで起動するよ、というだけ。
・ワーカースレッドの中断と監視方法
VB6の頃は、ボタンを押すとか、ウィンドウが移動するとかのイベント処理は、他のイベントと
排他的に動いていたんだよね。
この点については、MFCも変わらない。
イベントで処理していれば、他のイベントが発生しても、メッセージキューに入って処理待ちに
なるだけ。
最近、リストボックスを使って動作ログを表示するんだけど、ワーカースレッドの終了指示を
ボタンで行い、その中でワーカースレッドも参照する終了フラグをTRUEにしてタイムアウトを
待つ処理にしておいて、「中断しています」「中断が失敗しました」って言うのをログに出そうと
すると、表示が全て終了した後になってしまっていたのよ。
なんでだろうなぁと思ったら、ごくごく当たり前だったり。
ボタンイベントで中断フラグをTRUEにしてワーカースレッドの終了を待っているわけだから、
そこに動作ログにメッセージを追加しても、ボタン処理が終わるまでは再描画が行われない。
すでにイベント処理中な訳だしねぇ。
しょうがないので、いずれかの方法を取る。
1) タイマで監視
中断フラグをTRUEにした後で、SetTimer()で100ミリ秒程度の周期で終了を監視する。
これだと、ボタンを押してフラグセット、SetTimer()した後は処理を終了できるので、
リストボックスの再描画が行われる。これはよく使う。
欠点として、面倒。OnTimer()に処理かかなきゃいけないし、タイムアウトを監視する
カウンタつけないといけないし。
2) リストボックスへ文字を追加したら、RedrawWindow()
一番楽。
リストボックスへの追加は関数化してあって、追加後5120行を越えたら、古い行から
消していって5120に保ち(5120は適当)、最後にSetTopIndex()で最後の行を表示範囲に
入る様にスクロールさせている。
ここにRedrawWindow()を入れれば良い。
欠点として、常にRedrawWindow()が行われるので、リストボックスが多重更新される
タイミングもあるという感じ。
処理時間がシビアになると、もったいない処理時間となる…かも？
・ワーカースレッドの終了と終了監視
そんなに難しくはないのだが、ワーカースレッドも見る、初期値FALSEのBOOL変数をクラスに
追加しておいて、ボタンが押されたらこのフラグをTRUEにするだけ。
あとは、インループしない様にループさせるか、タイマで監視するか。
簡単な処理だと、こんな感じ。
//終了ボタン処理
void CWorkerTestDlg::OnButtonclicked1()
{
//終了要求ON
m_fAbortThread = TRUE;
//終了待ち。ワーカースレッドが終了するか、約3秒経過でタイムアウトして抜ける
for( int nTimeout=0; (nTimeout<3000) && (m_thWorkerThread != NULL); nTimeout+=100 ){
Sleep( 100 );
}
//終了要求OFF
m_fAbortThread = FALSE;
//終了結果確認
if( m_thWorkerThread == NULL ){
//終了成功
} else {
//終了失敗
}
}
ワーカースレッド側のコードは、一番上にあるコード参照。
ワーカースレッドでは、ループの頭や途中で、必ずm_fAbortThread==FALSEであることを監視。
これがTRUEになったら、ループを全て終了(break)させて、終了させる。
終了させる際、AfxBeginThread()の返すポインタを記憶している、m_thWorkerThreadにNULLを
セットして終了することを忘れない様にする。
フラグで終了指示を出して、本当に終了したかを確認するために、CWinThreadポインタを消す、
終了側はこれがNULLになるのを確認する、というハンドシェークで終了させる。
これが一番シンプルな感じがする。
いくらなんでも、TerminateThread()はしないよ！
…特殊な事情があって、タイムアウトしたならば別だけど。
派生として、スレッドラストで終了フラグをFALSEにするという手もあって、nTimeoutのループ
では、ポインタでなくて終了フラグがTRUEでなくなったことを監視すれば、同様のことが
可能となる。
ただし、終了フラグが落ちるのを監視するので、ちょいと後処理が心配になる。
(一応、for()側の処理の最後にでも、終了フラグを常にFALSEにすればいいんだけど…)
ワーカースレッドを書く際に、真っ先に書いておくのは、こんな所かなぁ。
いろんな手段をやってきたけど、最近記述するこのコードが、一番あっている気がする。
|ωﾟ)ﾉ 手抜き万歳！ でもおいら達の料理は手を抜くなよ！(ﾟωﾟ*)ﾅ?
投稿日：2011-10-07 Fri
たまには更新しようかねぇ。今のキャラ、HW50%、修羅2号機(スタンダードカラー)30%、
修羅初号機(紫カラー)20%位で動かしてる。
HWは後150%位で転職だったっけかな？と思ってSNSを
見に行ったら、次のレベルアップに必要なEXPしかないwww
後139M必要だってさ！…ダリいwww
現在、Base95、Job68。
今育てたいのは修羅2号機。
こいつは、釣りの為にVITもりもりタイプ。
やっと素で70行って、MHPが10k越えた。
ノーグの釣りなら、活かけた状態で被弾ダメが１になる。
まぁ、2〜3匹までだけど！
釣りが失敗するのは、主にラグ。震災以降、だいぶラグる。
ラグが終わったら、ボコられて脱出できないとｵﾜﾀ…
現在、Base96、Job…30は過ぎたような気がする(ぇ
修羅初号機が動くのは、大体パッシブ需要か、テンプラを
使う場合だね。
オデンとか、棚の火力になった場合に出ていく。
現在、Base101、Job36。
唯一つの100越え。ASPD190オーバー行ける！と思ったが、
こいつ耐久度上げるために、Agi削ってて、行けない状態。
ｼｮﾎﾞｰﾝ…
(*ﾟωﾟ)ﾉ うなちょう？惰眠貪ってるよ？
次のページ
△ PAGE UP