長年その方法でやっていたのですが、最近になって __argc や __targv （頭にアンダースコア２個） を使えば、解析済みの引数が参照出来る事を知りました。
ParseCommandLineを使うとわざわざCCommandLineInfoの派生クラスを作る必要があったりして面倒くさいのですが、__argcと__targvならば簡単に参照できるので、場合によってはこちらを使った方が手軽そうです。

データ構造として、起動引数を１クラスに管理させたい、とか思い始めるとParseCommandLineの方が良いのかなとも思ったりして、悩みどころではあります。

今まで結構回りくどいやり方をしていたのですが、PreTranslateMessageにちょろっと書いたら上手く動いたようなので、載せておきます。
（あまり動作検証していませんが）

BOOL CMainFrame::PreTranslateMessage(MSG* pMsg)
{
	if (pMsg->message == WM_MOUSEWHEEL) {
		CWnd* pWnd = WindowFromPoint(pMsg->pt);
		if (pWnd && IsChild(pWnd)) {
			pMsg->hwnd = pWnd->GetSafeHwnd();
		}
	}

	return __super::PreTranslateMessage(pMsg);
}

↑右がリソースエディタで貼ったツリーコントロールで、
左が↓のコードで貼ったツリーコントロール。

// m_TreeはCTreeCtrl型
m_Tree.CreateEx(WS_EX_CLIENTEDGE, WS_CHILD | WS_VISIBLE | TVS_SHOWSELALWAYS, CRect(10, 10, 200, 200),
this, 0);
m_Tree.InsertItem(_T("ああああ"));

見てお判りの通りWS_EX_CLIENTEDGEが付きません。
CTreeCtrl::CreateExのソースを見てみると、変なことやってますので、そりゃ付かないですね。

BOOL CTreeCtrl::CreateEx(DWORD dwExStyle, DWORD dwStyle, const RECT& rect,
	CWnd* pParentWnd, UINT nID)
{
	BOOL bRet = Create(dwStyle, rect, pParentWnd, nID);
	if (bRet && dwExStyle != 0)
	{
		bRet = ModifyStyleEx(0, dwExStyle);
	}
	return bRet;
}

かと言って

m_Tree.CreateEx(0, WS_CHILD | WS_VISIBLE | TVS_SHOWSELALWAYS, CRect(10, 10, 200, 200), this, 0);
m_Tree.ModifyStyleEx(0, WS_EX_CLIENTEDGE, SWP_FRAMECHANGED);
m_Tree.InsertItem(_T("ああああ"));

こんなコードにしても、↓のようにビジュアルテーマ（？）が適用されません。

（WS_BORDERだとちょっと濃い枠が付くため、これもちょっと違います。）

回避方法としては、

m_Tree.CWnd::CreateEx(WS_EX_CLIENTEDGE, WC_TREEVIEW, _T(""), WS_CHILD | WS_VISIBLE | TVS_SHOWSELALWAYS, CRect(10, 10, 200, 200), this, 0);
m_Tree.InsertItem(_T("ああああ"));

というように、CWnd::CreateExを直接呼び出してしまう事ぐらいでしょうか。

これで一応リソースエディタで貼った物と同じ枠が付きます。

MFCのバグ一覧とかどっかにまとまってたりしないのかな・・・。

これで少しハマっていたのですが、ダイアログの親クラスをCDialogではなくCDialogExにするとうまくメニュー処理がされるようです。
（こういうものこそASSERTで引っかけてくれよorz）

これが結構面倒だなーといつも思っていたので使い回せるようなイベントハンドラを作ってみました。

bool Scroll(CWnd* pWnd, int nBar, UINT nSBCode, UINT nPos, int nLine /*= 1*/)
{
	SCROLLINFO info = {sizeof(SCROLLINFO), SIF_ALL};
	if (!pWnd->GetScrollInfo(nBar, &info)) {
		return false;
	}
	int nNewPos = pWnd->GetScrollPos(nBar);
	int nOldPos = nNewPos;

	switch (nSBCode) {
	case SB_LEFT:
		nNewPos = info.nMin;
		break;
	case SB_ENDSCROLL:
		break;
	case SB_LINELEFT:
		nNewPos -= nLine;
		break;
	case SB_LINERIGHT:
		nNewPos += nLine;
		break;
	case SB_PAGELEFT:
		nNewPos -= info.nPage;
		break;
	case SB_PAGERIGHT:
		nNewPos += info.nPage;
		break;
	case SB_RIGHT:
		nNewPos = info.nMax;
		break;
	case SB_THUMBPOSITION:
		nNewPos = nPos;
		break;
	case SB_THUMBTRACK:
		nNewPos = nPos;
		break;
	}

	pWnd->SetScrollPos(nBar, nNewPos);
	return pWnd->GetScrollPos(nBar) != nOldPos;
}

スクロール位置に変更があったときにtrueを返しますので、これを見て画面更新などを行います。

こんな感じで使います。

void CHogeHogeWnd::OnHScroll(UINT nSBCode, UINT nPos, CScrollBar* pScrollBar)
{
	if (Scroll(this, SB_HORZ, nSBCode, nPos, 16)) {
		// ここで画面更新など
	}
}

void CHogeHogeWnd::OnVScroll(UINT nSBCode, UINT nPos, CScrollBar* pScrollBar)
{
	if (Scroll(this, SB_VERT, nSBCode, nPos, 16)) {
		// ここで画面更新など
	}
}

page移動量は若干の調整が必要かもしれませんね。

てか、CScrollWnd的なものを作ってテンプレートっぽくしておくのがベストなんだろうなぁ。

中は見ていませんが、おそらくカスタマイズ時のドラッグ＆ドロップ処理はOLEのドラッグ＆ドロップなんでしょうね。
なので、
CXXXXApp::InitInstanceの適当な所で「AfxOleInit()」を呼べばカスタマイズ機能が正常に動くようになります。

void FillGrad(CDC* pDC, CRect rc, COLORREF colBegin, COLORREF colEnd)
{
	TRIVERTEX av[2] = {
		rc.left, rc.top, GetRValue(colBegin) << 8, GetGValue(colBegin) << 8, GetBValue(colBegin) << 8, 0xff00,
		rc.right, rc.bottom, GetRValue(colEnd) << 8, GetGValue(colEnd) << 8, GetBValue(colEnd) << 8, 0xff00,
	};
	GRADIENT_RECT gr = {0, 1};
	GradientFill(pDC->GetSafeHdc(), av, 2, &gr, 1, GRADIENT_FILL_RECT_V);
}

GradientFill APIは古いOSでは動きませんのでご注意ください。

Visual C++6.0ではよくそういう事をやっていたのですが、Visual Studio 2008 + MFCだとどうやるんだろう？と思いましてちょっとやってみました。

メニューからクラスの追加を実行します。

「TypeLibからのMFCクラス」を選びます。

エクセルのタイプライブラリを選び、使うインターフェースを追加して（今回は面倒なので全部追加）完了ボタンを押します。

ちょっと生成に時間が掛かりますが、ヘッダーファイルが生成されます。
ただ、何故か#import文が入っていて、コンパイル時にエラー（名前の競合）が出てしまうので一括置換でコメントアウトします。

VC6ではできなかった芸当ですね（ソリューション内一括置換）

あとはごりごりコードを書けばエクセルの操作ができます。

既存のファイルを開いて、最初のシートのA1のテキストを取得するにはこんな感じになるかと思います。
（Excel 2007使用）

#include "CApplication.h"
#include "CWorkbooks.h"
#include "CWorksheets.h"
#include "CWorkbook.h"
#include "CWorksheet.h"
#include "CRange.h"

void CHogeHogeDlg::OnBnClickedButton1()
	CApplication App;
	if (!App.CreateDispatch(_T("Excel.Application"))) {
		ASSERT(0);
		return;
	}
	App.put_Visible(TRUE);

	CWorkbooks Workbooks = App.get_Workbooks();

	// 既存のエクセルファイルを開く
	COleVariant varNull;
	varNull.ChangeType(VT_NULL);
	CWorkbook Workbook = Workbooks.Open(_T("c:\\hogehoge.xls"), varNull, varNull, varNull, varNull, varNull, varNull, varNull, varNull, varNull, varNull, varNull, varNull,varNull, varNull);

	CWorksheets Worksheets = Workbook.get_Worksheets();
	CWorksheet Worksheet = Worksheets.get_Item(COleVariant((long)1));

	CRange Cells = Worksheet.get_Cells();
	CRange Cell = Cells.get_Item(COleVariant((long)1), COleVariant((long)1)).pdispVal;
	CString str = Cell.get_Text().bstrVal;
}

CRange::DialogBoxとかいう関数でコンパイルエラーが出ますが関数名変えるなどして回避します。

当然ながら実行する環境にエクセルがインストールされている必要があります。
また、使用したタイプライブラリと実行時のエクセルのバージョンが違うと、うまく動かない事があるかもしれません。うろ覚えですが。上位互換はあるかも？

もしいろんな操作をやりたい場合、エクセルのマクロのヘルプが参考になると思います。若干関数名は違いますが、構造などはほぼ同じです。

静的分割ウィンドウを作成するとき、同時にすべてのペインを作成する必要があります。CreateView メンバ関数は、この目的のために使われます。しかし、さらにほかの非ビュー クラスも作成できます。

と書いてあるではありませんか。

が、具体的にどうやって実装すれば良いかは書かれておらず、ソースを読んでいたところ、

• 親にCSplitterWndのインスタンスを指定してコントロール等を作成
• IDをCSplitterWnd::IdFromRowCol関数で算出した値にしておく

だけで良いみたいです。

m_wndSplitter.CreateStatic(this, 2, 1, WS_CHILD | WS_VISIBLE);
m_edit1.CreateEx(WS_EX_CLIENTEDGE, _T("Edit"), _T(""), WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_HSCROLL | ES_WANTRETURN | ES_AUTOVSCROLL | ES_AUTOHSCROLL | ES_MULTILINE, CRect(0, 0, 300, 300), &m_wndSplitter, m_wndSplitter.IdFromRowCol(0, 0));
m_edit2.CreateEx(WS_EX_CLIENTEDGE, _T("Edit"), _T(""), WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_HSCROLL | ES_WANTRETURN | ES_AUTOVSCROLL | ES_AUTOHSCROLL | ES_MULTILINE, CRect(0, 0, 300, 300), &m_wndSplitter, m_wndSplitter.IdFromRowCol(1, 0));

あとはm_wndSplitter自体をウィンドウ全体に広げて配置したりだとか、m_wndSplitter.SetRowInfoで行の高さを変更したりするだけです。
ダイアログベースのアプリでも気軽に使えそうですね。

他の開発環境ではグリッドコントロールなどと呼ばれている物が有りますが、VC（MFC）には付いてきません。
（標準のコントロールとしては、そのような物が無いため）

とはいえ、実際にアプリを作る際には、グリッドコントロールはしょっちゅう必要になってきますし、ソフトウェアハウスなんかではグリッドコントロールを独自開発して使っているのが実状だと思います。

そんな中、商品でも何でも良いのである程度汎用的に使えるグリッドコントロールは無いものか、ざっくりと探してみたので、ざっくりとまとめておきます。

Microsoft FlexGrid Control

ActiveXで使うグリッドコントロール。
http://noribeat.s38.xrea.com/developer/03031501.html
http://hp.vector.co.jp/authors/VA014436/prg_memo/windows/vctips/004.html

DataGridという奴もあるようですが、こちらはDB用なのかな？

MFC Grid control

Code Projectで公開されているライブラリ。
http://www.codeproject.com/KB/miscctrl/gridctrl.aspx

UNICODE環境でコンパイルするとOLEデータの貼り付け時に文字化けたり、そもそもコピペ時にCF_TEXT使ってたり（UNICODEなら本来はCF_UNICODETEXT）、ちょっとプログラムを修正する必要がありますが、結構いろんな事ができます。

ただ、操作性やデザイン面で好き嫌いが出そうな予感です。

BCGControlBar Library Professional Edition

VS2008 Future Packの元ネタである、このライブラリ集にもグリッドコントロールがあります。
http://www.bcgsoft.com/samples/grid.htm（サンプル）

デザインがなかなか格好良く、しかもかなりの高機能っぷりです。
なんでも出来そうです。

ただ、これだけデザイン良くて高機能なのに、すごく動作が重いんです。
とても実用に耐えられるものではありません。
（データが１画面に納まるような時でないと使い物になりません。）
これが動作が軽ければ文句なしに買っていたのに、非常に残念です。

ご意見お待ちしております

うちの会社はこの万能グリッドコントロールを使ってるよ！とか、むしろうちの会社でグリッドコンポーネント作ってるから買ってよ！みたいな宣伝とかありましたらメールください。

※ VS2005/VS2008 + UNICODE + MFC 環境でサクっと動く物をお願いいたします。

一応回避方法があったので載せておきます。

CMainFrame::OnCreateの上の方で

LOGFONT lf;
SystemParametersInfo(SPI_GETICONTITLELOGFONT, sizeof(LOGFONT), &lf, 0);
CMFCMenuBar::SetMenuFont(&lf);
m_fontGUI.CreateFontIndirect(&lf);

を実行すれば良さそうです。

これどっかに連絡すればsp2で治してくれるのかな？
MSのサポートって有料なのでこういう不具合を見つけてもいまいち報告する気にならないのですが。

-----
（コード修正しました）
なにやらSPI_GETNONCLIENTMETRICSでフォントを取得する方法は
開発環境によってはXPでうまく動作しないようなので、
SPI_GETICONTITLELOGFONTを使う方式に変更しました。
参考：http://d.hatena.ne.jp/NyaRuRu/20080303/p1

EDGE2を作ろうとした頃、タブブラウザで有名なsleipnir 1.66を使っていまして（今は2を使っています）、 sleipnirはわりとカスタマイズ性を売りにしているところがあって、どうやってカスタマイズ機能などを実現しているのかちょこっと調べてみた事があるのですが、どうやらBCGSoftというメーカーが出しているBCGControlBarという商用ライブラリを使っていたようなんですね。

それで初めてBCGControlBarというライブラリの存在を知って、当時買おうかちょっと迷ったんです。こうした機能を独自で実装するとなると、なかなか手間が掛かりまして、面倒くさいんですよね。当時の私はまだ学生だったという事もありまして（バイトもあまりやっていなかったので）結局自前でなんとかしたわけなんですが、それがVS2008 SP1からは新規作成した所で全部備わっちゃってるわけですから凄いものです。

で、どうもこのBCGControlBarの一部の機能がVS2008 SP1にそのまま入ってるみたいなんです。ただ、一部と書いたとおり、すべての機能が入ってるわけではなくて、商品のBCGControlBar Pro版には、更にグリッドコントロールや高機能エディターなどが付いているようです。
（VS2008 SP1との機能比較が個人的には欲しかったです＾＾；）

そうしてVS2008 SP1持っているけどそれでは足りない人向けにBCGSuiteという商品があるっぽいです。
（Pro版からSP1を引いた程度の内容になっている感じです。）

ちなみに製品の紹介はこちらが参考になるかと。
http://www.bcgsoft.com/featuretour/bcgcontrolbar-tour.htm
（グリッドコントロール標準で欲しいですわorz）

VS2008 SP1、実際に使ってみると、結構クラス設計とか綺麗に作られている印象を受けました。
BCGSoftさんやり手ですね。

ただ、デフォルトでカスタマイズ機能の保存先がレジストリになっている点が、一部のユーザーに反感を買いそうな感じではあります（＾＾；
一応頑張ればiniファイルとかバイナリに保存できるようになっているようですが、最初っからレジストリに当たり前のように書くのはちょっと勘弁して欲しいですね。

他にもツールバーの登録がツールバーリソース経由しかなさそう（？）なのが個人的にはちょっと痛いところ。
VS2008のツールバーエディタで16色のツールバー画像を作成し、その後で自動作成されたbmpをフルカラー画像に置き換えるか（置き換えるとVS2008上で開けなくなりますが）、もしくは別リソースとしてフルカラー画像リソースを用意してCMFCToolBar::LoadBitmap（だったっけ）しないといけません。
どちらにしてもあとで手を入れるときに二度手間な時があってあんまり好きじゃありません。

そういえば、マニュアルには載ってませんが、ソースを追っていたら、CMFCToolBar::LoadBitmapだったかは、 PNG形式のリソース画像も読めるっぽいです（試していませんが）。
そこはマニュアルに書いておくべきかと（＾＾；
なので、16色のツールバーリソース＋PNGフルカラー画像リソースという組み合わせが現状ではベストかと思われます。
（フルカラーBITMAPリソースはEXEがメタボになるのであんまりリソースとして持ちたくないんですよね）

何かSP1MFCの詳しい書籍が出てくれると良いんですが。
インプレスさん、Visual Studio 2008 SP1 MFCパワフルテクニック大全集とか出してくれませんかね？

需要ないかな・・・

《参考資料》
CodeZineさんの記事→http://codezine.jp/article/detail/2516
BCGSoft→http://www.bcgsoft.com/
MSDNのチュートリアルとか→http://msdn.microsoft.com/ja-jp/library/bb982451.aspx

→ダウンロードなどはこちらから

◇

昼休みゲオにダッシュで行ったんですが、スマブラ売り切れでした。

(´・ω・`)ｼｮﾎﾞｰﾝ
(´・ω・,';,';,',
(´・ω,';,';,',
(´,';,';,',
(,';,';,
';,,('

世の中のお父さんはすごいね！

◇

ところで仕事でもVisual Studio 2005（MFC）を使っているのですが、印刷周りでいくつかバグを見つけましたので、情報として出しておきます。

《その１》
例えば印刷可能範囲が１～１０だとして、印刷画面で２～３ページを印刷しようとした場合、実際には２～１０ページが印刷されてしまう。

→回避策：http://codezine.jp/forum/message.aspx?thid=472

海外のサイトではOnPrint内で印刷範囲を書き換えて回避するコードもありました。

《その２》
リリースでMFCをスタティックリンクすると、印刷プレビュー画面の上のボタン類が英語になる。

これは、リソースファイルのインクルードで
#include "afxprint.rc" // 印刷/印刷プレビュー リソース
となっている所を
#include "l.jpn/afxprint.rc"
にすればOK。

ちなみに、字が小さいのをなんとかしたい場合は、この「l.jpn/afxprint.rc」を開いてプロジェクトフォルダに別名保存し、中のリソースの文字サイズを変え、#include "l.jpn/afxprint.rc"の代わりに別名保存したファイルをインクルードすればOKです。

《その３》
A4縦用紙の印刷プレビュー画面にて、一段階拡大したときに、マウスカーソル（ルーペ）と用紙の当たり判定がおかしい（紙の右側をクリックしても、もう一段階拡大しない）

こちらは検索しても回避策が出てきませんでしたので自前でなんとかしました。
CPreviewViewの派生クラスを作成して、マウスカーソルの当たり判定部分を修正すればOKです。

.NETもいいですがVS2005でせっかくMFCもバージョンアップするなら、こういう初歩的なバグは直してからリリースしてほしいです（というか未チェックなんじゃ・・・）。
あと、クラスウィザードは復活させてほしいです（イベントハンドラの追加が面倒）。
あと、ラジオボタンかなんかの変数を追加したときにBOOL型にしようとするのは止めてほしいです。
あと、インテリセンスの更新をVC6並にちょっぱやにしてほしいです。
あと、CFile系の処理でブレークポイント貼ると落ちることがあるのをなんとかしてほしいです。
あと、「CHogeHoge* pHoge」の「CHogeHoge*」だけをCtrl＋左ドラッグで選択出来るようにしてほしいです（VC6ではできた）

そんな事を挙げていくとキリがないですが・・・。
コンパイラはVC6よりも2005の方が良いと思うのですが、IDEは使いづらいところが目立ちます(´･ω･`)ｼｮﾎﾞｰﾝ
何か、改善策などをご存じの方がいらっしゃいましたら、こっそり教えてくださると助かります。

ＭＦＣに関してはバグもいくつか確認していますが（印刷のページ範囲がバグるとか、ＭＦＣをスタティックリンクするとシステムの文章がデフォルトで英語になってるとかｗ）そんなことよりも未だに慣れないのがイベントハンドラの追加周り。

例えばメニューコマンドのイベントハンドラを作成する場合、ＶＣ６だったらクラスウィザードを表示させて各コマンドのUPDATE_COMMAND_UIとCOMMANDハンドラを一気に追加する事が出来たんですが、 VS2005だとクラスビューを右クリックしてプロパティ選んで、プロパティペインから対象のコマンドを探してUPDATE_COMMAND_UIを追加したら、ソースが切り替わってプロパティペインの内容が変わっちゃうもんだから、次COMMANDハンドラを追加したいときはまたクラスビューからクラスを探して右クリックして・・・・まだ一つのコマンドなら良いんですがそれが「切り取り」「コピー」「貼り付け」「削除」・・・と複数追加したい時に、毎回この作業しなくちゃならなくて、やってるウチにムキィーーーっとなるわけです。

各言語間で操作を統一する事は否定しませんが、今までより効率が下がるのは勘弁してほしいなと思います。

インテリセンスにしても、たしかにＶＣ６より性能が上がったとは思うのですが、さっき追加したばかりのメンバ関数が候補になかなか出てこない、というのが気になる所です。ＶＣ６の時はすぐに反映されたのですが・・・。インテリセンス情報が更新されるまでネットサーフィンしてやろうかと思うこともしばしば(笑)

たぶん、どこかいじればこの辺の問題も解決できると思いこんでるのですが、何かそのあたりの情報をご存知の方はこっそり教えていただけると嬉しいです！

MFCのCRectクラスは初期化を忘れてもデバッグビルドではそれなりに動作するのですが、リリースビルドだとうまく動かないため、開発時に検出しづらいです＿|￣|○

CStringクラスは初期化しなくとも（？）データが無い状態となりますが、それと同じような感覚でCRectなんかを使うと痛い目にあいますので開発者の方はご注意を。
（普通こんなミスしないか）

そもそもの原因は「TranslateAccelerator」というAPIの仕様とMFCの相性が悪いことにあります。 TranslateAcceleratorはキー入力をメニューコマンドへ変換するAPIですが、メニュー状態が無効だったら変換（送信）しないという仕様になっています。そのため、 MFCのコマンド更新ハンドラで pCmdUI->Enable(TRUE); となっていても、メニュー状態が無効ならば、ショートカットキーは使えません（深い場所のメニューコマンドは）。

ちなみに浅いコマンドが効くようになったことについては、少し憶測ですが書いてみますね。 TranslateAcceleratorの仕様として、キー→メニューコマンド直前（？）に WM_INITMENUなどのメッセージを送信してきます。そのメッセージをMFCフレームワークが掴み、メニューコマンドを「コマンド更新ハンドラ」を使って更新し、最新の状態になるため、ショートカットが効いたのだと思われます。
（ルート直下のメニューコマンドしか更新しません）

さて、深い位置のメニューコマンドを効かせるために、まず思いつくのが、「メニュー状態を更新する」という方法です。しかしいつ更新してよいのかわかりません。毎回キー入力（またはTranslateAcceleratorが送信してくるWM_INITMENUなど）でメニューコマンド全ての状態を更新することは負荷となりパフォーマンスの低下に繋がることは目に見えています。

で、私が使用した解決方法は、以前ちょろっと書きましたが、アクセラレータ処理を「TranslateAccelerator」を使わず自前で実装するという事です。もともとEDGE2はショートカットキーのカスタマイズに対応しており、キーの設定をリソースではなく、通常のデータ（謎）として持っているため、WM_KEYDOWNやらWM_SYSKEYDOWNメッセージを捕まえて、メニューコマンドへ変換し、SendMessage(WM_COMMAND・・・);しています。幸い、MFCはコマンドを実行する直前でコマンドUI更新ハンドラを呼び出して、コマンドを実行可能か調べているため、例えば「実行出来ないはずのメニューコマンドを実行する」というような事も起こりません（コマンド更新ハンドラでEnable(FALSE)となっているとwarningはTRACEされますが＾＾；）。

現在公開しているEDGE2β版では既にこの方法で実装しています。今のところ問題も出ていませんので、おそらく大丈夫かと思われます。

最近はEDGE2の動作チェックなどをやっているのですが、また新たな不具合が発生しまして・・・、これがなかなか曲者でして、今まで気が付きませんでしたがなんとEDGE1でも再現します＿|￣|○・・・。

例によってシンプルなプロジェクトファイルと実行ファイルを用意しましたので、もし通りすがった方で良い解決策などをご存知の方がいらっしゃれば、私まで連絡をお願いいたします（という他力本願な日記です）。なお、興味のある方向けに実行ファイルも用意しました。

Visual C++ 6.0 プロジェクトファイル
実行ファイル

概要

今回の不具合は、アクセラレータキー（Ctrl+Zでアンドゥが効くような機構・・・ショートカットキーと呼ぶのが一般的？）が場合によって効かなくなるというものです。

再現手順

1. 起動する
2. 「↑（矢印）」キーが「浅い」というコマンドに割り当てられ、「↓」キーが「深い」というコマンドに割り当てられています。
   

   

   つまり、「↑」キーを押せば「浅い」が実行され、「↓」キーを押せば「深い」が実行されるというわけです。

3. では試しに「↑」「↓」キーを押してみてください。
   どちらもコマンドが実行されるとメッセージボックスが表示され、「実行された」という事が目で見て解るようにしてあります。

   どちらのキーでも処理が実行されることを確認してみてください。
   

4. ここで、ツールボタン「ONで有効」の凹んでる状態を解除します（OFFになります）
   

5. すると、「浅い」や「深い」が無効状態になります（無効状態にしています）。

   メニューを表示し、各コマンドが両方とも使えなくなっていル事を確認してください（必須）
   

   

6. さて、ここで「↑」「↓」キーを押してみてください。

   「浅い」や「深い」は使えない状態ですので、もちろん処理は実行されません。

7. では、ツールボタン「ONで有効」をもう一度凹まし、ONの状態にしてください。

   

8. これで内部的には「浅い」も「深い」も実行可能状態になります。
   （メニューは開かないでください。）

   このまま、「↑」「↓」キーを押してみてください。

   「浅い」は処理されますが、「深い」が処理されません。

   「浅い」位置にあるコマンド（ルートの直下）は使えるのに、
   「深い」位置にあるコマンド（サブメニュー？）は使えないのです。

   これが今回の不具合です。

9. ちなみに、このあとメニューを開き、「深い」が有効状態になっているのを確認してから「↓」キーを押せば処理されるようになります。

EDGE1の場合・・・

EDGE1の場合は、矢印キーで選択範囲を移動する事が出来るのですが、
選択範囲が無い時点でメニューを見に行き、座標微調整コマンドが無効状態になっているのを確認してから、画像を選択し、矢印キーを押してみると、キーが効かなくなるという不具合が発生します。

考察

まだちょこっとしか調査していませんが、キーアクセラレータ機構については、キー入力系メッセージ（KEYDOWNとか）からTranslateAccelerator APIを通ってコマンド(WM_COMMAND)に変換されるようなのです。
その際にTranslateAcceleratorは、対応するメニューコマンドが無効だとコマンドを送信しない仕様らしいんです（MSDNの資料はこちら）。
だから、MFCのフレームワークで深い位置にあるメニューコマンド状態が更新されないのかなぁなどと推測しています（あんまりWindowsSDKとかメッセージ処理とか詳しくないのでどっかかん違いしていたらごめんなさい）。

仕様なのか不具合なのか、どちらにせよ、便利であるはずのライブラリに時間を取られるのだけは勘弁してほしいです(´･ω･`)ｼｮﾎﾞｰﾝ

＃アクセラレータキー処理を自前でやれば問題無しかも？

＃今回は矢印キーばかりでしたが、「Ctrl+A」のような感じのキーも同様です

当初は闘う前から負けていた（だってドッキング部分はいろいろなサイトで難解と言われていましたから）のですが、きよのさんの協力もあってやる気が出まして(笑)、駄目元でデバッグをしていったところ、それっぽい原因を見つけ出すことができました。

折角ですので、VC6.0を使ってどうやって問題を解決したかなどを簡単に書き記しておこうと思います。

さてさて、ドッキングしているツールバーをドラッグ＆ドロップした際、ドロップした位置より下側にずれてドッキングしていまう、というのが今回の不具合です（詳しくは12日の日記を参照してください）。

なんとなく「ドロップしたあとのツールバー位置を決める処理」に不具合があるんだろうなぁとは予想出来ましたので、その辺をさぐろうと思ったのですが、ソースを見るに当たってまずは大体どんなかんじでドッキングしたツールバーなどを管理しているのか、データ構造を探ることにしました（その方がソース見ていて解りやすくなると思いまして）。

もともとCToolBarやCStatusBarのヘルプを見たときに、それらがCControlBarというクラスから派生していたのを何度か目にしていたため、「きっとメインフレームがCControlBarの一覧を持ってるんだろう」という憶測はしていました。

早速、CMainFrameの親クラスを参照機能でたどって行くとCFrameWndというクラスに

CPtrList m_listControlBars;

という名前がそのままの変数を見つけました。

ためしに一つずつポインタを取得してみてGetWindowRectでウィンドウ座標を取り、その位置に四角形を描画してみたのですが、思ったとおり、全てのツールバーやステータスバーが格納されていました。

しかし実際にはそれだけでなく、謎のクラスCDockBarというクラス（これもCControlBarの派生クラス）が上下左右に1つずつ存在していました。どうやらこのCDockBarというのがツールバーのドッキングを受け入れるバーのようです（受け入れるバーと受け入れられるツールバーが同じリスト内に存在している、というのも不思議な気がしますが）。

＃ちなみにCDockBarのコンストラクタにブレークポイントを設定してみたところ、
　上下左右の4つだけでなく、ツールバーを浮かせた状態にした際にも生成されるようです。

CDockBarがドッキングを受け入れるバーならば、そのCDockBarがドッキングしているコントロールバーの座標を持っているんじゃないかと思い、さっそくソースを見ていったところ、

CPtrArray m_arrBars;    // each element is a CControlBar

という怪しいポインタ配列を見つけたので、例によって一つずつポインタを取得してみてGetWindowRectでウィンドウ座標を取り、その位置に四角形を描画してみましたが、またも思ったとおり、ドッキングされているツールバーなどが格納されていました。
ところが、中にはNULLという情報も含まれており、どういったルールでこの配列の中身が決まっているかが気になりました。

そこで、ツールバーのドッキング状態をいろいろ変えながらm_arrBarsがどのように変化するか試したところ、上の行から順番にコントロールバーのポインタが格納されており、NULLは「コントロールバーの改行」を意味するようでした。

つまり、

↑このような状態では、

    m_arrBars[0] = NULL;
    m_arrBars[1] = ツールバー1のアドレス;
    m_arrBars[2] = NULL;
    m_arrBars[3] = ツールバー2のアドレス;
    m_arrBars[4] = NULL;
    m_arrBars[5] = ツールバー3のアドレス;
    m_arrBars[6] = NULL;

このような配列状態になり、

↑このような状態では、

    m_arrBars[0] = NULL;
    m_arrBars[1] = ツールバー1のアドレス;
    m_arrBars[2] = ツールバー4のアドレス;
    m_arrBars[3] = NULL;
    m_arrBars[4] = ツールバー2のアドレス;
    m_arrBars[5] = NULL;
    m_arrBars[6] = ツールバー3のアドレス;
    m_arrBars[7] = NULL;

このような配列状態になりました。

「・・・ということは、ツールバーをドロップした際、この配列への挿入場所を導き出す処理がうまくいかず、こちらが期待する位置にツールバーが配置されず、下の段にドッキングしてしまうのではないか」、というような考えにいきつきました。

データ構造は大体解りましたので（？）ようやくここからドッキング部分のソースを追うことにします。

・・・どうやって追うのか？

10秒ぐらい悩みましたが、ドッキング後には、メインフレームのRecalLayoutが呼び出されると思い、ここにブレークポイントを設置し、実際にツールバーをドラッグ＆ドロップしてみたところ、見事にひっかかりました。

そこからコールスタックウィンドウを駆使して呼び出し元を辿り、

CDockContext::EndDrag()という関数の最初の方でまたブレークポイントを設置し、また実行してドラッグ＆ドロップして停止させて、今度はステップ実行でひとつずつ怪しいところが無いか見ていきました。

しばらく追っていき、
CDockContext::EndDrag()　→　CFrameWnd::DockControlBar()　→　CDockBar::DockControlBar()　→CDockBar::Insert()　この関数内で先に出た「CPtrArray m_arrBars;」というポインタ配列へバーを挿入している事が判明しました。

というわけでこの関数の先頭にブレークポイントを設定して、実行→ツールバーをドラッグ＆ドロップ→ブレークポイントで停止させ、
今度は変数ウォッチに、この関数内で使用している変数を表示させ、変数の変化を見ながらステップ実行していきました。

このCDockBar::Insert()という関数、完璧に理解したわけではありませんが、
配列の先頭（＝一番上のコントロールバー）から順番に座標を照らし合わせながら、
ドッキングしたいコントロールバーの「順番（配列番号）」を求め、ポインタを挿入している関数だと思われます。

int CDockBar::Insert(CControlBar* pBarIns, CRect rect, CPoint ptMid)
{
    ASSERT_VALID(this);
    ASSERT(pBarIns != NULL);

    int nPos = 0;
    int nPosInsAfter = 0;
    int nWidth = 0;
    int nTotalWidth = 0;
    BOOL bHorz = m_dwStyle & CBRS_ORIENT_HORZ;

    for (nPos = 0; nPos < m_arrBars.GetSize(); nPos++)
    {
        CControlBar* pBar = GetDockedControlBar(nPos);
        if (pBar != NULL && pBar->IsVisible())
        {
            CRect rectBar;
            pBar->GetWindowRect(&rectBar);
            ScreenToClient(&rectBar);
            nWidth = max(nWidth,
                bHorz ? rectBar.Size().cy : rectBar.Size().cx - 1);
            if (bHorz ? rect.left > rectBar.left : rect.top > rectBar.top)
                nPosInsAfter = nPos;
        }
        else // end of row because pBar == NULL
        {
            nTotalWidth += nWidth - afxData.cyBorder2;

            nWidth = 0;
            if ((bHorz ? ptMid.y : ptMid.x) < nTotalWidth)
            {
                if (nPos == 0) // first section
                    m_arrBars.InsertAt(nPosInsAfter+1, (CObject*)NULL);
                m_arrBars.InsertAt(nPosInsAfter+1, pBarIns);
                return nPosInsAfter+1;
            }
            nPosInsAfter = nPos;
        }
    }

    // create a new row
    m_arrBars.InsertAt(nPosInsAfter+1, (CObject*)NULL);
    m_arrBars.InsertAt(nPosInsAfter+1, pBarIns);

    return nPosInsAfter+1;
}

この関数でどんな処理が行われているか、私の解釈で簡単に説明しますと・・・

コントロールバーというのは種類によってバーの高さが異なりますので、行の中で一番高いサイズをnWidthという変数で記憶しておいて、改行（=NULL）または表示されていないバーが来たら「高さの合計」を示すnTotalWidth変数にnWidthを足す、というような処理が入っています。

この高さ合計と、ドッキングしたい場所のY座標（中央）を比較し、条件が合えばその位置にバーを挿入、というような感じです。

＃垂直状態のドッキングも考慮しているとはいえ、何故「nWidth」という名前なのかはちょっとわかりません・・・

さて、デバッグ実行しているときに気が付いたのが、改行と表示されていないバーが連続で来たときなどに、

    nTotalWidth += nWidth - afxData.cyBorder2;

という処理が実行されると、nTotalWidthが減るという事です。

nWidthは0ですが、afxData.cyBorder2は0ではないため（2だったかな？）
改行＆表示されていないバーが来るたびに
nTotalWidthの値がどんどん減っていきました。
　
　
・・・これってバグじゃないの？
　
　
　
この部分の不具合疑惑が浮上し、ここをなんとか書き換えて実行しようと思いました。
　
書き換えたい気持ちは山々なのですが、ここはMFCソース内部、変えるのが困難な部分です。

誰か変えた人いないの！？ってなかんじでぐぐってみましたが、ヒットせず＿|￣|○

しょうがないので自分でやることに（＾＾；
　
　
まず、CDockBar::Insertという関数はvirtual関数ではないため、オーバーライドさせることが出来ません。そんなわけで、virtual関数が出てくるまで呼び出し元をたどりました。

CDockContext::StartDrag(CPoint pt);
という関数が仮想関数であることがわかったため、
この関数からCDockBar::Insertまでのすべての呼び出し処理を変更すればCDockBar::Insert処理を別のものに変えられそうでした。

具体的には
CDockContext::StartDrag() → CDockContext::Track() → CDockContext::EndDrag() → CFrameWnd::DockControlBar() → CDockBar::DockControlBar() →CDockBar::Insert()
これら全ての関数を修正する必要があるという事です(´･ω･`)ｼｮﾎﾞｰﾝ

クラス別に見て

• CDockContext
• CFrameWnd
• CDockBar

これら3つがありますで、これらから新たにクラスを派生させ、そこで別関数を用意すれば良いという事です。
（CFrameWndに関してはCMainFrameという関数がありますので、クラスを新しく用意する必要はありませんね。）

で、これらのクラスから新たに

CDockContext
→CMyDockContext
CDockBar
→CMyDockBar

というクラスを作るのはまぁ出来るだろうとは思うのですが、
いままでCDockContextクラスをnewしていた部分を今度はCMyDockContextクラスをnewさせるようにしないといけないわけで、それが出来るかどうかの実験から始めました。
　
　
CDockContextのコンストラクタにブレークポイントを設定して生成タイミングなどを調査した結果、
CControlBar::EnableDocking();関数内でnewされている事が解りました。

CToolBarから新たにクラスを派生させ、そこからEnableDocking()を作る、というのが普通かもしれませんが、
なにしろツールバー以外にもコントロールバーというのは多数ありますから（ダイアログバーなど）
少し汚い手ですが、

EnableDocking();させた後で全コントロールバーに対してメンバ変数m_pDockContextを見て、インスタンスあれば一旦deleteして、CMyDockContextをnewさせ、保持させておくという手段を用いました（爆

CDockBarの方はCFrameWnd::EnableDocking時に生成されるようでしたので、その関数のソースをそのままコピペしてnew CDockBar部分を書き換えました。

これでクラスのインスタンスをごっそり変える事が出来ましたので、
CMyDockContextや、CMyDockBarのメンバ変数をコピペしたりして
各関数を実装します。

CMyDockContext::StartDrag() → CMyDockContext::TrackDebug() → CMyDockContext::EndDragDebug()　→　CMainFrame::DockControlBarDebug() → CMyDockBar::DockControlBarDebug() →CMyDockBar::InsertDebug()

というように呼ばれるわけです。

CMyDockContext::EndDragDebug()　→　CMainFrame::DockControlBarDebug()
というように、クラスが異なる呼び出しの場合には、
呼び出す際の型キャストも必要です。

    CMainFrame* pMainFrame = dynamic_cast<CMainFrame*>(m_pDockSite);
    if (pMainFrame) {
        pMainFrame->DockControlBarDebug(m_pBar, pDockBar, &rect);
    }
    else {
        m_pDockSite->DockControlBar(m_pBar, pDockBar, &rect);
    }

こんな感じで最終的にCMyDockBar::InsertDebug()が呼ばれるようにし、
これでようやく・・・ようやくCDockBar::Insert部分をいじれるようになりました＿|￣|○

早速例の「高さの合計を示すnTotalWidth変数にnWidth足す」という部分に修正を試みます。

#if 1
            if (nWidth > 0) {
                nTotalWidth += nWidth - afxData.cyBorder2;
            }
#else
            nTotalWidth += nWidth - afxData.cyBorder2;
#endif

これで実行してみたところ、ドッキング不具合は発生しなくなりました！
　
　
・・・長かった。
　
　
そんなわけで治ったっぽいプロジェクトはこちらです。
今後同じような問題にぶちあたった人のお役に立てられれば幸いです・・・。
　
　
・・・Microsoftさん、貴重な休日を返して（T_T

もし解決策、回避策などが解る技術者の方がおられましたら、
私まで連絡をお願いします。

＃Microsoftに質問メール送る方法が解らなかった＿|￣|○
　プロフェッショナルサポートとか契約してないとメールで質問出来ないのかな～？
　変わりにMSへ問い合わせてくれる人でも構いません(＾＾ゞ

症状１　ツールバードッキングで嫌な感じ （解決したかも？）

→問題部分のみを抽出したプロジェクトファイルはこちら(40KB)
（Visual C++6.0が必要です）
VisualC持ってないけど見てみたいという方はこちらをどうぞ。

プロジェクトの主な作成手順は次の通りです。

1. ウィザードでMFC→MDIアプリケーションを作成（他の設定はそのまま）
2. CMainFrame::OnCreateにて
   1. ツールバーを5個以上作成する
   2. 作成したツールバーで、最初の2個だけを残し、残りのツールバーをShowControlBar(・・・,FALSE, TRUE);で非表示する
   3. また、症状がわかり易くなるように、ここでダイアログバーを一つ作成しています。（無くても症状は発生します）
3. ビルドし、実行します。

症状の再現方法は次の通りです。

1. EXEを実行します。
   

   ツールバー5個中、2個が表示されています。
   

2. 上のツールバーを、ダイアログバーの下へドラッグ＆ドロップしてドッキングさせます。
   

   すると、普通にドッキングします。
   

3. さて、ここでもう一つのツールバーを、さきほどのツールバーの横へドラッグ＆ドロップしてドッキングさせようとすると・・・

   

   下にずれる。
   

これが嫌な症状です。
ちなみに、がんばると（ちょっとダイアログバーへめり込むようにドロップすると）、隣へドッキングさせることも出来るのですが、また少しずらそうとすると、一段下がった場所へ勝手に配置されてしまいます。

二つしかツールバーが無い程度ならばいいのですが、それが複数になって、隣へ配置出来なくなるのは、ツールとしての使い勝手が悪くなる要因ともなりかねませんので、解決したいところです。

ツールバーは5個中2のみ表示、と書きましたが、5個全て表示したり、最初から2個しか
作らなかった場合には、これらの症状は発生しません。

症状が発生しない期待通りの実行ファイルはこちら

MFC側の不具合のような気もするのですが、もしそうであっても直したい部分ではあります＾＾；

（20:00 追記）
きよのさんからメールを頂きまして（有難うございます！）
Visual C++ 6.0 Enterprise Edition SP6では症状が発生しないとの情報を頂きました。
ちなみに私の環境は
Visual C++ 6.0 Professional Edition SP6です。
MFCのソースが異なるんでしょうかね～＿|￣|○
もう少し追ってみます。

（20:24 追記）
と思ったらEnterprise Editionでも症状が確認されたようです（＾＾；
更にはVisual C++ .NET Professional 2003でも再現したそうです＿|￣|○

ツールバーの表示方法とか作成方法が間違ってるのかなぁ、と不安になってきました。

（3/13 0:55 追記）
解決したかも？明日解決方法などを紹介します。

あ、掲示板のSISTさんサンクス！
たしかにでにくくなってましたが、いろいろやっているうちに症状が再現してました。

症状２　ツールサイズ変更でアプリがフリーズ （解決しました！）

こちらはだいぶ解りやすい症状です＾＾；

→問題部分のみを抽出したプロジェクトファイルはこちら(40KB)
（Visual C++6.0が必要です）
VisualC持ってないけど見てみたいという方はこちらをどうぞ。

プロジェクトの主な作成手順は次の通りです。

1. ウィザードでMFC→MDIアプリケーションを作成（他の設定はそのまま）
2. CMainFrame::OnCreateにて、デフォルトで作成されたツールバーの状態をいじり、ドロップダウンボタンをいくつか追加する（2つぐらいあると症状が発生しやすい）
3. ビルドし、実行します。

症状の再現方法は次の通りです。

1. EXEを実行します。
2. ツールバーをドラッグ＆ドロップし、浮かせます（ドッキングを解除）
   

   

3. あとは、その浮いたツールバーの上の部分を上へドラッグするとフリーズします。
   

ドロップダウンボタンが2つぐらい有ると起こる症状のようです。
フリーズ状態でVCのブレークを実行すると、CToolBar::SizeToolBarやらCToolBar::CalcSizeで無限ループに陥っているのかなぁ、というように思えます。
各関数にvirtualがついていないので、単純にオーバーライドして値をTRACEさせるという技も使えず＾＾；

こちらもMFC側の不具合のような気もするのですが、もしそうであっても直したい部分ではあります。

（追記）
CToolBar::CalcDynamicLayoutがvirtualになっていましたので、オーバーライドし、その中で使用されている関数などをMFCのソースからコピペ、問題を探ったところ、
CMyToolBar::SizeToolBarの中で無限ループに陥っていることが解りました。

無限ループにならないように、勝手にreturnしてみたのですが、これで良いのやら・・・
→修正後のプロジェクトファイルはこちら

        while (sizeMin.cx < sizeMax.cx)
        {
            sizeMid.cx = (sizeMin.cx + sizeMax.cx) / 2;
            WrapToolBar(pData, nCount, sizeMid.cx);
            sizeMid = CalcSize(pData, nCount);

// ここの判定分を追加してみた by takabo soft
#if 1
            if (sizeMax == sizeMid) {
                return;
            }
#endif

            if (nLength < sizeMid.cy)
            {
                if (sizeMin == sizeMid)
                {
                    WrapToolBar(pData, nCount, sizeMax.cx);
                    return;
                }
                sizeMin = sizeMid;
            }
            else if (nLength > sizeMid.cy)
                sizeMax = sizeMid;
            else
                return;
        }

（20:00 追記）
きよのさんからメールを頂きまして（ありがとうございます）、MSのサポートサイトにて解決策があると教えていただきました！
http://support.microsoft.com/default.aspx?scid=kb;ja;190501
すっきりです(笑)

• Dot+s（ドット絵）

このサイトの管理人さんであるウォーターさんから
相互リンクの依頼メールを頂いていたのですが、
トップページ３回連続リンク更新のみってのは寒いな（＆多忙）って事で
「明日やろう」の無限ループに突入。

昨日再度メールを貰ってしまったのでbreakしました（＾＾；
気が付けば最初に依頼されたときから2週間も経ってました・・・早っ。
可愛そうな事をしてしまってごめんなさい＿|￣|○＞ウォーターさん

最近仕事でシューティングゲームっぽいものを作っているのですが(MFCで)、
「あたり判定」処理を

CRect rcMy; // 自機の矩形とする
CRect rcBullet; // 弾の矩形とする
if (!(rcMy & rcBullet).IsRectEmpty()) {
（当たっている）
}

なんて書いて横着っぷり（？）を発揮しています。
最近のCPUパワーなら無駄も無視出来ると思い込んでマス。