Win32プログラミングノート --- Misc. ---

次の関数は、自分のバージョン番号を取得するためのものです。

1:	#include <malloc.h>
2:	DWORD GetVersionInfo()
3:	{
4:	TCHAR path[MAX_PATH];
5:	path[::GetModuleFileName(AfxGetInstanceHandle(), path, sizeof path / sizeof path[0])] = 0;
6:
7:	DWORD dummy;
8:	DWORD size = GetFileVersionInfoSize(path, &dummy);
9:	if (size == 0) {
10:	// Error...
11:	}
12:	LPVOID lpData = NULL;
13:	__try {
14:	lpData = alloca(size);
15:	}
16:	__except (EXCEPTION_EXECUTE_HANDLER) {
17:	// Error...
18:	}
19:	if (!GetFileVersionInfo(path, 0, size, lpData)) {
20:	// Error...
21:	}
22:	LPVOID lpBuffer;
23:	UINT vSize;
24:	if (!VerQueryValue(lpData, _T("\\"), &lpBuffer, &vSize)) {
25:	// Error...
26:	}
27:	VS_FIXEDFILEINFO* info = (VS_FIXEDFILEINFO*)lpBuffer;
28:
29:	return info->dwFileVersionMS
30:	}

解説

GetModuleFileName()にAfxGetInstanceHandle()の戻り値を渡すと、実行中のexeファイルの フルパスを取得できます。

GetFileVersionInfoSize()は、引数のファイル名に渡したファイルに含まれるリソースの バージョン情報の大きさを取得します。

alloca()でスタック上にバッファを用意し、 GetFileVersionInfo()で、バージョンリソースのチャンクを取得します。 取得したいのは単にバージョン情報だけなので、 ルートの情報をVerQueryValue()を使って取得します。

余談ですが、alloca は NULL を返しません。 NT の場合、メモリがアロケートできなかった場合には例外が発生します。 一般的には、alloca は使わないほうが良いライブラリ関数とされています。 (でも楽チンだから使っちゃうんだこれが…)

これで得られるポインタの型はvoid*ですが、VS_FIXEDFILEINFO*へキャストします。

その中の、 dwFileVersionMS というフィールドにバージョン情報が格納されています。 HIWORD()がメジャー番号、LOWORD()がマイナー番号となっています。

[補遺] 以前は dwProductVersionMS だと記述していたのですが、プロパティ他の表示にあわせ、 dwFileVersionMS の方を使うように変更しました。

インポートライブラリとして、version.libをリンクする必要があります。 プロジェクトのリンクするライブラリに追加してください。

アプリケーションの二重起動防止には、Mutexを使います。

1:	HANDLE gMutex = NULL;
2:	const TCHAR gMutexName[] = _T("Xxx Exclusive Mutex");
3:
4:	BOOL CXxxApp::InitInstance()
5:	{
6:	...
7:	gMutex = CreateMutex(NULL, FALSE, gMutexName);
8:	if (gMutex == NULL) {
9:	AfxMessageBox(_T("Cannot create Mutex"));
10:	return FALSE;
11:	}
12:	if (GetLastError() == ERROR_ALREADY_EXISTS) {
13:	#ifdef ACTIVATE_ON_DUPLICATE
14:	// activate the first instance
15:	CString title;
16:	title.LoadString(IDR_MAINFRAME);
17:	HWND hwnd = ::FindWindow(NULL, title);
18:	if (hwnd) {
19:	::SetForegroundWindow(hwnd);
20:	}
21:	#endif
22:	return FALSE;
23:	}
24:	...
25:	}

ACTIVATE_ON_DUPLICATEで囲まれた部分は、既にオープンしているアプリケーション(がウィンドウを作っていれば、ですが)をフォアグラウンドにします。 トップレベルウィンドウのキャプションが固定なダイアログアプリケーションで有効です。 ドキュメント・ビューモデルの場合には、通常MFCが勝手にウィンドウクラス名を割り当てる上、 編集中のドキュメントがキャプションに付加されるため、FindWindow()が使いにくくなっています。 このような場合、CMainFrameクラスのPreCreateWindow()をオーバーライドしてウィンドウクラス名を固定します。 その上で、FindWindow()でウィンドウクラス名を元に検索をかけます。

Win32アプリケーションからWin32コンソールプログラムを起動すると、新しいコンソールウィンドウが表示されてしまいます。 WinExec()やShellExecute(?)ではなく、CreateProcess APIを使えば、コンソールウィンドウの表示を抑止することができます。

1:	bool RunCmd()
2:	{
3:	STARTUPINFO startupInfo = {
4:	sizeof startupInfo,
5:	NULL, /*lpDesktop=*/NULL, /*lpTitle=*/_T("Update cmd"),
6:	0, 0, 0, 0,
7:	/*dwXCountChars=*/10, /*dwYCountChars=*/10,
8:	/*dwFillAttribute=*/0,
9:	/*dwFlags=*/STARTF_USEFILLATTRIBUTE | STARTF_USECOUNTCHARS | STARTF_USESHOWWINDOW,
10:	/*wShowWindow=*/SW_HIDE,
11:	/*cbReserved2=*/0,
12:	};
13:	PROCESS_INFORMATION processInfo;
14:
15:	TCHAR path[_MAX_PATH];
16:	GetSystemDirectory(path, _MAX_PATH);
17:	_tcscat(path, _T("\\cmd.exe"));
18:
19:	if (!CreateProcess(
20:	path, _T("cmd /c echo hello"),
21:	NULL, NULL,
22:	FALSE,
23:	CREATE_NEW_CONSOLE | NORMAL_PRIORITY_CLASS,
24:	NULL,
25:	NULL,
26:	&startupInfo,
27:	&processInfo)) {
28:	DWORD err = GetLastError();
29:	TRACE1("error code = %d\n", err);
30:	AfxMessageBox(_T("Could not run cmd.exe"));
31:	return false;
32:	}
33:
34:	CloseHandle(processInfo.hProcess);
35:	CloseHandle(processInfo.hThread);
36:	return true;
37:	}

STARTF_USESHOWWINDOW と、SW_HIDE がポイントっすかね。

タスクトレイへアイコンを登録するには、もう決り文句のようなイディオムがありますが、 せっかくタスクトレイにアイコンを登録しても、シェルが死んで復活すると消えてしまいます(シェルが自動的に復活することそのものは良いアイディアだと思いますよ)。プロセスは残っているのに…。

で、朗報です。IE4からだかIE5からだか忘れましたが、シェルが復活したときにプライベートウィンドウメッセージが送られるようになりました。こいつを使えば、 不安定な(?)シェルが死んでもばっちり(死語?)です。 で も、自分のDLLをシェルにインジェクトして不安定にさせちゃぁ元も子もありませんけど〜。

具体的には、 TaskbarCreated という名前でメッセージを登録して、そのハンドラを定義し、再度タスクトレイに登録してやります。

プライベートウィンドウメッセージの登録は、RegisterWindowMessage APIを使います。戻り値はUINTです。これを、クラスのスタティックメンバに収めておきます。
余談ですが、 一個のアプリケーションで閉じた世界では、 プライベートウィンドウメッセージを使うまでもなくWM_APP+xxxで済ませることも出来ます。 しかし、 複数のアプリケーションが関わる世界では、 RegisterWindowMessage()を使って、メッセージの一意性と一貫性を持たせるべきです。RegisterWindowMessage()は、引数の文字列をアトムとして登録し、同じアトムに対しては、同じ値を返します。
WM_APPは、0x8000に定義されています。RegisterWindowMessage() は、0xC000〜0xFFFFを返します。ですから、常識的にWM_APP+xxxと、RegisterWindowMessage() の返す値がぶつかることはまずないでしょう。もちろん絶対 とは言い切れませんが。世の中には、予想もつかない妙な処理をするアプリケーションがあるものですから…。ま、そういう変なアプリは、この際無視しておきます。

さらに余談。 NOTIFYICONDATA の uCallbackMessage には通知に使われるメッセージを指定します。 時折、WM_USER + xxx を通知メッセージとして使っているサンプルコードを見かけることがあります。 たいていの場合問題はないと思われますが、厳密に言うと WM_USER を基準にするのはあまり誉められたことではありません。 WM_USER がユーザ(あるいはアプリケーション)に完全に開放されていたのは Win 3.1x の頃の話で、Win32 では WM_APP 以降がアプリに開放されています。 WM_USER + xxx の領域は predefined なウィンドウクラス(たとえばツリービューやリストビューなど)で用いられている可能性があります。

というわけで、自分で定義したウィンドウクラスのウィンドウインスタンスに対して用いるのは問題がないのですが、ダイアログへポストさせるメッセージとしては、WM_USER + xxx はあまり適切ではありません。 代わりに WM_APP + xxx を使ってください。 32ビット Windows API が登場してからもう10年近く経とうとしていますが、いまだにこういう混乱が見られるのですね……。

MFCでは、登録したメッセージハンドラは、ON_REGISTERED_MESSAGE() マクロを使ってテーブルに記述します。さすがMFC、こんなマクロまで用意しているとはやるじゃん、という感じ。
なお、メッセージハンドラのテーブルはクラスのスタティックメンバなので、プライベートメッセージを入れておくUINT変数もスタティックメンバにしておくわけです。蛇足ですが、ON_REGISTERED_MESSAGE() はクラスウィ ザードでは設定できないので、手で書き込みます。まぁ大した手間ではありませんよね。

プライベートメッセージのハンドラは、ON_MESSAGE()のハンドラと同様、次の形になります。

LRESULT OnTaskbarCreated(WPARAM, LPARAM);

MFCのメッセージクラッカは何もしてくれないわけですが、この場合問題ないでしょ。

ハンドラでは、wParamもlParamも参照せず、単にタスクトレイにアイコンを設定しなおします。簡単でしょ？

そういうわけで、MFCでのコードは次のようになります。

おまけでタスクトレイのウィンドウハンドルを取得する部分も載っけてますが、単にタスクトレイにアイコンを登録するだけならそこらへんは不要です。

CCheckListBoxというのは、MFCでListBoxをサブクラス化してチェック状態を追加したコントロールです。 「罠」というほど大げさではありませんが…、CCheckListBoxを使うときに引っかかりやすい点について列挙しときます。

• オーナードロー、高さ固定にする
• "Has String"をチェックする
• UnicodeでMFCをスタティックリンクにするとき、_AFX_CHECKLIST_STATEというビットマップが定義されていないので、ランタイムエラーになってしまう。

デバッグビルドでスタティックリンクする場合、このMFC固有のリソースが定義されていないようです。 最後のランタイムエラーを避けるには、手っ取り早いのは、どっかからビットマップを引っ張ってくることでしょう。 ということで、%windir%\system32\mfc42ud.dllから、30996番のビットマップをリソースにコピーしたりして。

デバッグ時のみスタティックリンクにしているのだったら、コンパイルのコンディションとして、_DEBUG を付けとけばちょっと安心でしょう。

画像ファイル(GIF, JPEG, BMP, ICOなど)を読み込むのに、いちいちフォーマットに対応したコードを書くのも勉強になりそうですが、そんなこたぁやってらんねぇ読めさえすりゃぁいいじゃん、という私のようなすぼらプ ログラマのために。

ちょっと COM を使うハメになりますが、OleLoadPicturePath という API を使うと、種々の画像ファイルのロードを任せてしまうことができます(ただし、あまり robust ではないらしい)。

読み込みとBMPの書き込み

とりあえず、ファイルを読み込んで BMP にしてファイルへ保存する関数。
OleLoadPicturePath() で、IPicture のインスタンスを作ります。 次に、SHCreateStreamOnFile() で、ファイルを書き込みモードでオープン、IStream のインスタンスを作ります。 あとは、IPicture::SaveAsFile() を使ってストリームへ書き込むだけ。 どうです、簡単でしょ？ これだけ簡単じゃないと、私には画像なんて扱えませんて(笑)。

1:	#include <olectl.h>
2:	#include <objbase.h>
3:	#include <shlwapi.h>
4:
5:	#include <interface.h>
6:
7:	#pragma comment(lib, "delayimp.lib")
8:	#pragma comment(lib, "shlwapi.lib")
9:	#pragma comment(linker, "/delayload:oleaut32.dll")
10:	#pragma comment(linker, "/delayload:ole32.dll")
11:	#pragma comment(linker, "/delayload:shlwapi.dll")
12:
13:	bool ConvertToBmp(LPCWSTR src, LPCTSTR out)
14:	{
15:	try {
16:	Interface<IPicture> pic;
17:
18:	//
19:	// Create IPicture object that is associated with the src file.
20:	//
21:	HRESULT hr = ::OleLoadPicturePath((LPWSTR)src, NULL, NULL, 0, IID_IPicture, pic);
22:	ASSERT(hr == S_OK);
23:	if (FAILED(hr)) {
24:	TRACE1("Failed to OleLoadPicturePath. hr=%x\n", hr);
25:	return false;
26:	}
27:
28:	Interface<IStream> stream;
29:	hr = ::SHCreateStreamOnFile(out, STGM_WRITE | STGM_SHARE_DENY_WRITE | STGM_CREATE | STGM_DIRECT, &stream);
30:	ASSERT(hr == S_OK);
31:	if (FAILED(hr)) {
32:	TRACE1("SHCreateStreamOnFile failed hr=%x\n", hr);
33:	return false;
34:	}
35:
36:	LONG cbSize;
37:	hr = pic->SaveAsFile(stream, TRUE, &cbSize);
38:	TRACE1("SaveAsFile wrote %d bytes.\n", cbSize);
39:	ASSERT(hr == S_OK);
40:	if (FAILED(hr)) {
41:	return false;
42:	}
43:	//
44:	// N.b. the COM interfaces are automatically
45:	// released by their destructors.
46:	//
47:	} catch (...) {
48:	TRACE0("ConvertToBmp: failed to delay load oleaut32. dll\n");
49:	return false;
50:	}
51:
52:	return true;
53:	}

class Interface てのは、ものすごくシンプルな COM の自作ラッパです。 ここに出すのも恥ずかしいぐらいシンプルでいいかげんなので、出しません(笑)。 簡単に作れると思います。 ブロックを出るときに、デストラクタで COM のインスタンスを破壊してくれることだけが長所です。

ディレイロードを使っている関係で全体を try ~ except で囲っていますが、本質ではありません。

画像のレンダリング

さて、一度 IPicture のインスタンスを得てしまえば、画面に描画するのも簡単です。 たとえば、以下のコードは、トランスルーセントカレンダのプレビューダイアログのコードです。

特に難しいところはありませんが、ウィンドウのサイズを画像の縦横比に合わせてリサイズしてるとこが、ミソといえばミソでしょうか？ IPicture::get_Width() や get_Height() で大きさがわかります。
実際にレンダリングをするのは、IPicture::Render() です。 これも簡単ですね。 あえて言うと、height を負にしなければいけないところでしょうか？ これは確か、下から上へラスタラインが並んでいるという BMP の変な癖のためです(確かそうだったと思う…。もう忘れてしまった)。

1:	class CImagePreview : public CDialog
2:	{
3:	// Construction
4:	public:
5:	CImagePreview(CWnd* pParent = NULL);   // standard constructor
6:
7:	// Dialog Data
8:	//{{AFX_DATA(CImagePreview)
9:	enum { IDD = IDD_IMAGE_PREVIEW };
10:	// NOTE: the ClassWizard will add data members here
11:	//}}AFX_DATA
12:
13:
14:	// Overrides
15:	// ClassWizard generated virtual function overrides
16:	//{{AFX_VIRTUAL(CImagePreview)
17:	protected:
18:	virtual void DoDataExchange(CDataExchange* pDX);    // DDX/DDV support
19:	//}}AFX_VIRTUAL
20:
21:	// Implementation
22:	protected:
23:
24:	// Generated message map functions
25:	//{{AFX_MSG(CImagePreview)
26:	virtual BOOL OnInitDialog();
27:	afx_msg void OnPaint();
28:	afx_msg UINT OnNcHitTest(CPoint point);
29:	//}}AFX_MSG
30:	DECLARE_MESSAGE_MAP()
31:
32:	public:
33:	bool Create();
34:	bool SetImage(const CString& path);
35:	bool ClearImage();
36:
37:	protected:
38:	CString m_path;
39:
40:	hirofumi::Interface<IPicture> m_pic;
41:
42:	CRect m_rc;
43:	};
44:
45:
46:	void CImagePreview::OnPaint()
47:	{
48:	CPaintDC dc(this); // device context for painting
49:
50:	if (m_pic.Invalid()) {
51:	return;
52:	}
53:
54:	OLE_XSIZE_HIMETRIC width;
55:	OLE_YSIZE_HIMETRIC height;
56:	m_pic->get_Width(&width);
57:	m_pic->get_Height(&height);
58:
59:	m_pic->Render(dc.m_hDC, 0, 0, m_rc.Width(), m_rc.Height(),
60:	0, height, width, -height, NULL);
61:	}
62:
63:	bool CImagePreview::SetImage(const CString& path)
64:	{
65:	if (m_path == path) {
66:	return true;
67:	}
68:	m_path = path;
69:
70:	if (m_pic.Valid()) {
71:	m_pic.Release();
72:	}
73:
74:	try {
75:	HRESULT hr = OleLoadPicturePath((LPWSTR)(LPCTSTR)m_path, NULL, NULL, 0, IID_IPicture, m_pic);
76:	if (FAILED(hr)) {
77:	Invalidate();
78:	return false;
79:	}
80:	} catch (...) {
81:	TRACE0("CImagePreview::SetImage: delay load of OleLoadPicturePath failed. \n");
82:	return false;
83:	}
84:
85:	// Resize the window to fit the picture aspect.
86:	OLE_XSIZE_HIMETRIC width;
87:	OLE_YSIZE_HIMETRIC height;
88:	m_pic->get_Width(&width);
89:	m_pic->get_Height(&height);
90:	GetClientRect(&m_rc);
91:	if (width && height) {
92:	CRect rcW;
93:	GetWindowRect(&rcW);
94:	int offset = rcW.bottom - m_rc.bottom;
95:	m_rc.bottom = m_rc.Width() * height / width;
96:	rcW.bottom =  m_rc.bottom + offset;
97:	MoveWindow(rcW);
98:	}
99:
100:	Invalidate();
101:
102:	return true;
103:	}
104:
105:	[以下略]

蛇足ですが、ストリームをメモリ上に作るには CreateStreamOnHGlobal() という API が、そのストリームから HGLOBAL を取ってくるには GetHGlobalFromStream() が使えます。

なにも難しいことはないので、View の OnInitialUpdate() から、ResizeParentToFit(FALSE); を呼べばおっけ。 FALSE をつけることで、必要ならメインフレームの大きさを拡大します。 デフォルトの TRUE だと縮小だけになるので、環境によってはダイアログテンプレートのサイズよりクライアント領域が小さくなってしまうことがあってうまくありません。

void CXxxView::OnInitialUpdate()
{
    CFormView::OnInitialUpdate();
    GetParentFrame()->RecalcLayout();
    ResizeParentToFit(FALSE);
}

常識といえば常識なのですが、久々にコードを書いていて忘れていることに気がついたので、自分用のメモ。 どうやって思い出したかって？ 昔のコードを引っ張り出してそれっぽいところを眺めたわけです(笑)。

これまた知っていたらなんてことはないんですが。 CMainFrame クラスの OnCreate() に次の行を書き込むだけです。

int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
    ...

    // ステータスバーのペイン0を、縁ありにする
    m_wndStatusBar.SetPaneInfo(0, 0, SBPS_STRETCH, 0);

    return 0;
}

Since 1996