MFC相談室 mfc23d.dll [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
質問しろ〜 なんでも答えてやんぜって思ったら、俺c++できないんだったw 最新のMFCはコンストラクタでメンバ変数初期化サボってるクラスないよね いつの間にかMFCでもDirect2Dがサポートされてたんだね ちょっとサンプル見たけどGDIと比べると複雑だな CStdioFile::ReadStringでshiftjisのファイルをバッファに読み込んだんですが、 テキストファイルの内容は「あ」のみ バッファの内容は 82 00 A0 00 でした。 unicodeなら 30 00 42 00 か 00 30 00 42 になると思うのですが、なにか勘違いしていますかね? >>23 テキストファイルをUTF-16にするか、UTF-8にしてUTF-16に変換する。 setlocaleしてないからascii-8bitとして読み込まれたと予想。 >>25 setlocaleしたら 42 30 となっちゃいました >>26 そう書いていますが?・・・ >unicodeなら >30 00 42 00 >か >00 30 00 42 てのがおかしい。 プロセスが起動した状態で、 ツールバーのツールチップの文字列を取得、変更したいのですが ちょっと手こずっています。アドバイスお願いします 以下の方法ではツールチップではなくボタン文字列が対象になるようです TBBUTTONINFO bi = {sizeof(bi), TBIF_STYLE}; m_wndToolBar.GetToolBarCtrl().GetButtonInfo(9999, &bi); ::MessageBox(NULL, bi.pszText, bi.pszText, MB_OK); 以下はまだ使い方がよくわかってないけど目的がちょっと違うように思われます CToolTipCtrl* tt = m_wndToolBar.GetToolBarCtrl().GetToolTips(); tt->UpdateTipText(...); >>34 動的な変更は、やった事ないけど、このあたりでは? ttp://home.att.ne.jp/banana/akatsuki/doc/mfc/mfc22/ アプリを普通に作っていれば、取得はボタンのリソースIDと同じIDを持つSTRINGリソース ちょっとiconの相談です MFCでプロジェクト作った際、アプリのicon(IDR_MAINFRAME)にいろんなイメージタイプ (サイコロ3つ)が作られるけど私は全部設定するの面倒なので32x32 8bit bmpだけ 作って他全部消すようにしてます。皆さんはどうしてます? いろんな環境に対応するためにあ-いうことしてるのかなーとは思うんだけど.. >>37 アイコンのイメージ作成にはInkscapeを使ってるよ。 お金に余裕があればAdobe Illustrator使えばいいんじゃないかな。 32x32だけだとユーザーに汚い画像を見せることになる。 > 32x32だけだとユーザーに汚い画像を見せることになる。 解像度を変えてのテストはある程度してるけどあまり気になったことないなー 私の想定を超えたデバイスだと汚くなるのかな?Inkscapeは落とした。勉強してみます。 片山博士は大きく&色彩豊かなicon作った後でInkscape使って縮小/減色してるの? Inkscapeで256x256ピクセル(Vistaサイズ)にしてから図形を描いてとりあえず保存すればSVG形式ファイルになる。 「ファイル」メニューの「PNG形式でエクスポート」を選べばPNG画像が吐き出される。 それを16x16,32x32,48x4864x64に縮小して、見辛いピクセルを細かく補正してからアイコン作成ソフトに取り込むとアイコンができる。 Inkscapeは図形の合成などの強力な編集機能があるが、 図形が足りなければワード、エクセルの図形をコピペすればいい。 時間がないときは文字アイコンだね。1文字をアイコンにするだけで インパクトあるかもしれない。 「アンチエイリアス」がかかると、どうしても細部がぼやけてしまう。 小さいアイコンでは、ユーザーにはっきり見えるように微細な加工をした方がいい。 片山先生はアイコン一つにも手を抜かないんだな。 お前らも見習うべき CListView(LVS_OWNERDATA style指定)で特定の行の選択を禁止したいのですが LVN_ITEMCHANGINGはOWNERDATAの場合は送られない様です。by msdn 何か良い方法は無いでしょうか。 クリックやENTERを潰すしかないんでしょうか? 選択禁止は諦めました。 選択された後、近くの行を強制的に選択状態にするようにししたら、あまり違和感がなかったので、これでごまかします。 CArrayの質問なんですが、 CArray<int> test; test.SetSize(10); とやった場合、test[0]〜test[9]までの値は、 0で初期化されていることは、前提として良い動作ですか? ソースを見たところ、SetSize()で確保したバッファをいったんゼロクリアして、 その後、各要素に対してコンストラクタが呼ばれるようなので、 C++のintのコンストラクタが「なにもしない」という仕様なら大丈夫そうですが。 intのようなプリミティブな型にもコンストラクタってあるの? 知らなかった MFCでリボンアプリケーション組もうとしてるんですけど、 リボンデサイナでダイアログボックス起動ツールのボタンは 付けられないのでしょうか? 例えばWORDとかでフォントグループの右下にある小さい四角いボタンです。 MFCでCEditをサブクラス化したいと思うのですがうまくいきません サブクラス化時にFromHandlePermanetと言う関数が呼ばれてそこでASSERTに引っ掛かってしまいます MSDNによると「SubclassWindowを呼び出す時、ウィンドウがMFCオブジェクトに結びつけられていないようにしろ」とあります 馬鹿で申し訳ないのですが、ウィンドウがMFCオブジェクトに結びつけられるのはどのタイミングなのでしょうか? 今はCEdit::Create後にサブクラス化を試みています >>53 ああ、あの2ミリ角くらいの小さな四角ね。 >>54 CEditをダイアログエディタで作成したなら、すでにMFCの管理下にある。 サブクラス化する必要はない。作成したCEditメンバーを使えばいい。 >>56 ありがとうございます しかしながらCEditから派生させたクラスをnewを使用して動的に作成しています newによりインスタンスを動的に作成 ↓ Createメンバ関数を呼び出しコントロールを作成 ↓ サブクラス化 ↓ ASSERT 途中で送信してしまいました 現状はこんな感じでアサートに引っ掛かってしまいます デバッガで追うとウィンドウのMAP(?)にサブクラス化対象のウィンドウが既に存在しているとアサートされるようなのですが、このウィンドウマップにどこで登録されるのかが解りません マップに登録される=MSDNの言う「ウィンドウをMFCオブジェクトに結び付ける」と言うことなのかと推測しています その工程ならサブクラス化はいらないはず でもウィザードを使わずにクラスを作ったら おまじないマクロがついてこないんじゃないかな 後始末のときにオブジェクト開放が先かウインドウ破棄が先かってのも迷う >>59 ありがとうございます 説明不足で申し訳ありません そもそも何故エディットボックスをサブクラス化したいかというとエディットボックスのコンテキストメニューを改造したいためなのです エディットボックスにくるWN_RBUTTONDOWNをトラップするため、サブクラス化が必須になっている次第です Createするから既存になってしまうんじゃないの? >>57 でいうサブクラス化ってSubclassWindow? SubclassDlgItem? CEditのサブクラスは時々使うけどSubclassWindow経由では使ってないので 外してたらスマソ 自分でサブクラス化したときはDDX_Controlを削らないとうまく動いてくれなかったような気がする。 正解は知らんが。 >>60 mfcは昔やっててもう忘れかけだが マウスボタンをトラップする程度なら サブクラス化なんて不要なんじゃないか? >>62 ありがとうございます SubclasDlgItemを使っています ですがデバッガで追うと結局は内部でSubclassWindowをを呼び出しているのは確認しています >>64 ありがとうございます DDXは使っていません リソースにエディットボックスコントロールを貼りつけてはおらず、プログラム中でCEditクラスを派生したクラスを動的に作成しています >>65 エディットボックスのマウス右クリックはサブクラス化が必要なようです でも確かになにかコンテキスト〜というメッセージがあったような気もしないでもないのですが… WEBで調べた限りですと右クリックメッセージをフックしているのしか出てきませんでした 回答ではなく代替案ですが 1. CEditのサブクラスでOnContextMenuをオーバーライドしてメニュー処理を記述。 2. https://support.microsoft.com/ja-jp/help/403856 中の また、CDialog::DoDataExchange() で DDX を使用して.. のやりかたで CEditをCYourEditに変更。 で独自のコンテキストメニューは出ますよ。 >>69 おおおお!!! ありがとうございます! 早速試してみます! と思いましたが、今日はもう事務所が閉まるそうです… 早速明日試してみます! ありがとうございました! 明日もあさっても過ぎたんだけど、どうなったんだろうね。 >>71 これは失礼しました 解決しましたのでご報告致します 結果的にはサブクラス化出来ました 動的にCEditを生成した際、実際のコントロールをCriateメソッドで生成すると思いますが一旦生成してしまうとサブクラス化できないようです CMyEdit pualic CEdit として派生 CMyEdit lpCMyEdit = new CMyEdit; lpCMyEdit->SubclassWindow(...←ここでサブクラス化 lpCMyEdit->Crate(...←コントロール作成 上記の手順でサブクラス化できましたのでWM_CONTEXTやWM_CHARに対してメッセージトラップが可能になりましたので全て実現できました MFCのいう、ウィンドウの関連付けというのは恐らくコントロール作成時にWindowMapというMFCのクラスに登録されることかと思われます 改めて色々と相談に乗っていただき有り難うございました また何かありましたら質問させて頂きます >>72 間一髪間に合いました >>73 リソースにエディットがないのに、SubclassWindow()を呼び出したって… 一体何をサブクラス化したんだろう… リソースにエディットがなければ Create() だけでいい リソースにエディットがあるなら SubclassWindow() だけでいい (この場合は、69さんの2のやり方が普通だと思う) 改めてよく読んだらおかしいねw SubclassWindowのパラメータに何を渡したんだろう 本人が解決したって言ってるんだから別にいいけど >>75 MFC使い方がよくわかってなくて混乱させているようで誠に申し訳ないです… CEditをnewにて動的に作っていますのでリソースは一切使っていないです 具体的にはエクセルのシートの様な格子形のグラフィックを描画し、そのカラムをクリック等された際にエディットボックスを動的にカラムの座標に作っています >>76 SubclassWindowにはCEdit派生の独自クラスを渡しています 自分は普段SDKしか使わないためSDKの感覚なのですが、ウィンドウのサブクラス化とは、サブクラス化したいウィンドウハンドルのウィンドウプロシジャのアドレスを別途作成した独自ウィンドウプロシジャのアドレスと差し替える事と認識しています ですのでSubclassWindowに渡すハンドルはサブクラス化したいウィンドウのハンドルと思っていましたが何か別のパターンがあるのでしょうか? >>78 > CMyEdit public CEdit として派生 > CMyEdit* lpCMyEdit = new CMyEdit; ここでは、まだウィンドウは無い (コンストラクタに小細工がなければ) > lpCMyEdit->SubclassWindow(...←ここでサブクラス化 もし以下のように書いたとしても、ハンドルは NULL だからサブクラス化できない lpCMyEdit->SubclassWindow(lpCMyEdit->GetSafeHwnd()); > lpCMyEdit->Create(...←コントロール作成 この中で、ウィンドウが作成されサブクラス化される なので SubclassWindow() の明示的な呼び出しは不要 >>78 CEditをどういう風にカスタマイズしたいのかわからんが >CEdit派生の独自クラス の段階でそれを実装できないの? 通常サブクラス化を必要とするのは(通常の手段では)派生クラスを置けないダ イアログ上のコントロールに対しての場合のみで、そうで無い場合は必要な機 能を実装したCEdit派生クラスをCreate()するだけで実現できると思うんだが・・ MFCでは(メッセージマップの仕掛けによって)ほぼ全てのメッセージを派生ク ラスで独自処理を行えるので、サブクラス化は必要ないはずです。 >>77 >具体的にはエクセルのシートの様な格子形のグラフィックを描画し… これ自分もやったなー 作り込んで思い通りに動いたときは気持ちいいよね >>79 なるほど、確かに仰る通りです MFCだと定義済みコントロールを作成したタイミングでサブクラス化が自動的に行われているんですか…知らなかった… SubclassWindowの戻り値を確認してみます >>80 はい、とりあえずは、WM_CHARとWM_CONTEXTMENUをトラップしたいのです どうも私の勘違いでサブクラス化は不要なんですかね… >>81 そうなんです 失敗が多い分、成功の歓びがあります >>85 はい、SubclassWindowは失敗していました みなさんの言う通りコントロール作成時に暗黙にサブクラス化が行われているようです とても勉強になりました 有り難うございます そもそもなぜサブクラス化って言うの? クラスとは関係ないと思うんですが サブクラス化というネーミングはイマイチだとずっと思ってた。 APIの名称から来てるから翻訳者に罪はないが、、 VS2017入れてみたけど_MFC_VERは変化なし。 残念だ。 >>87 多分ウィンドウクラスを横取りするからじゃないかな? 実際クラスとは関係ないと思う ファーストクラスとかも全然クラス関係ないし 英語にそういうニュアンスがあるんじゃないの Windows1.0のときからあるし、オブジェクト指向の用語とは別路線で発生したもんだしなあ GUI自体がオブジェクト指向の影響下で発展してきたわけで、別路線ってことはないだろう。 ウィンドウクラスごとにそれぞれ異なるWinProcを指す仕組みなんてほとんどv-tableだし。 確かWin32APIはsmalltalk由来のメッセージパッシング式オブジェクト指向を意識して作られたとかなんとか。 んで、C++はメッセージパッシング意識して作られてなかったから、言語自体を拡張されたのがC++Builderで、言語は拡張せず、メッセージテーブル作って無理くり対応したのがVCのMFCって何かで読んだ。 そう考えるとMFC以前はCでどうにかオブジェクト指向と言うより、メッセージパッシングを実現しようとしてWin32APIが出来たんだろね。 生まれてなかったんで。 そう言えばWin16sとの互換性のためとか勉強した覚えある。 win32sならやったけど、Win16sは知らないなあ。 IT業界を離れて10数年経つ者です。 いまどき高速なアプリを手軽に作りたい場合、現役の方はどういう環境で作っています? 当時は主にMFC、たまにC++Builderでやってました。重くても良い場合はVBも使いました。 出来れば今後10年使えそうな奴をお願いします。今もたまに簡単なツールを作る機会が ありますが、その際はMFCで作っています。多少勉強する覚悟はあります。 よろしくお願いします。 >>98 >出来れば今後10年使えそうな奴をお願いします。 ない。 WPFやUWPは廃れても、C#とXAMLは残ってそう。 C++とMFCも地味に残ってるだろうけど。。。 MFCで印刷プレビューのリボンバーってどうやってカスタマイズするの?? >>107 CDocument::GetFirstViewPosition CDocument::GetNextView > CCriticalSection オブジェクトの使用方式は、2 とおりあります。 > スタンドアロン方式、およびクラスに埋め込む方式です。 > > スタンドアロン方式 > CCriticalSection オブジェクトをスタンドアロンで使うには、 > 必要が生じたときに CCriticalSection オブジェクトを構築します。 > コンストラクタから正常に戻った後、Lock を呼び出してオブジェクトを明示的にロックします。 > クリティカル セクションへのアクセスが完了したら、Unlock を呼び出します。 > この方法はソース コードを読んだ人にはわかりやすいのですが、 > アクセスの前後でクリティカル セクションをロック、アンロックすることを > 覚えておかなければならないため、エラーを引き起こす傾向があります。 > より望ましいのは、CSingleLock クラスを使う方法です。 > この場合も Lock メソッドおよび Unlock メソッドを使いますが、 > 例外が発生したときにリソースのロックを解除する必要はありません。 > > 埋め込み方式 > CCriticalSection 型のデータ メンバをクラスに追加し、 > 必要に応じてロックすると、複数のスレッドでクラスを共有することもできます。 MSDNのCCriticalSectionの説明には、上のように書かれているのですが、 このスタンドアロン方式って、どういう意図なのでしょうか。 普通に読めば、関数の内部でローカル変数として宣言するように思えるのですが、 それだと全く排他制御になっていないのでは? Mutexみたいに名前付きなら上のスタンドアロン方式も理解できるけど名前ないからなー わかんね CCriticalSectionインスタンスが同期オブジェクトなわけではないよ。 クリティカルセクションは名前の通りクリティカルな区間のこと。Win32APIのEnterCriticalSection()からLeaveCriticalSection()の区間。 CCriticalSectionはこれのラッパー。 クリティカルセクションに入るスレッドはプロセスで一つだけになる。 プロセス間排他はできない代わりに軽い。 同期オブジェクトがプロセスで一つだけになのと同義。 マルチコア・マルチスレッドでロック待ちが無視できなくなるようなら他の使う。 >>111 クリティカルセクションという用語は>>111 の言う様に元々「クリティカルな区間」のことだが、Win32では スレッド間排他処理のための同期オブジェクトとして"CRITICAL_SECTION"があり、CCriticalSectionはこのラッパー。 ( https://msdn.microsoft.com/ja-jp/library/cc429052.aspx にも"「クリティカル セクション」は、Win32の基本的な同期オブジェクトの1つです。"と書かれている) >>109 確かにその説明はチンプンカンプンだねえ。 推測だけど、たとえばCStringをスレッド間排他制御するために CString strFoo ; CCriticalSection csForFoo ; // 非AUTO : csForFoo.Lock() ; strFoo += strBar ; csForFoo.Unlock() ; : みたいに書く(定義上はcsForFooはstrFooと結びついていない)のが、「スタンドアロン方式」で class CThreadSafeString : public CString { private: CCriticalSection csForMe ; public: void ThreadSafeAppend( LPCSTR p ) { csForMe.Lock() ; *this += p ; csForMe.Unlock() ; } } ; みたいに書く(クラスに排他処理を埋め込む)のが「埋め込み方式」じゃないかなあ。 で、いずれの方式でも上記のような記述では「クリティカルな区間」で例外が発生するとUnlock()が実行されないので、これを避けるため、CSingleLockクラスを使えと。 >>110-112 解説ありがとうございます。 > CCriticalSection csForFoo ; // 非AUTO > : > csForFoo.Lock() ; > strFoo += strBar ; > csForFoo.Unlock() ; この使い方が当初の疑問だったのですが、 このローカル変数としての使い方って、意味ありますか? 試しに同じような処理を作って、複数のスレッドから同時に呼んでみても、 全く排他制御されているように見えなかったのですが。 >>113 >>112 >CCriticalSection csForFoo ; // 非AUTO ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q12140841977?__ysp=QVVUT%2BWkieaVsA%3D%3D >>109 >普通に読めば、関数の内部でローカル変数として宣言するように思えるのですが、 思えない ローカル変数にも、ブロックローカル・関数ローカル・ファイルローカルがあり、 ブロックローカル・関数ローカルにも非静的変数と静的変数がある。 >>114 > CCriticalSection csForFoo ; // 非AUTO > : > csForFoo.Lock() ; ああ、このcsForFooは関数内の自動変数ではなくて、 関数外なり静的変数なりで定義されているものいうことでしたか。 > 普通に読めば、関数の内部でローカル変数として宣言するように思えるのですが の「ローカル変数」は、「自動変数」の意味でした。 失礼しました。 >>109 の原文(MSDN)には construct the CCriticalSection object when it is needed. と書かれているからCCriticalSection objectはオート変数と解釈してもおかしくは無い気がする。 staticならあらかじめになってしまう。 >>116 「コンストラクタから正常に戻った後、Lock を呼び出して」 とも書いてあるので、普通に読めば自動変数ですよねぇ。 でも、自動変数のCCriticalSectionをロックしても排他制御になっていないはずだし、 これはどういう意図なんだろうか、という質問でした。 MFC MDIで2つのメニューを出したいので、mainframeにCMFCMenuBarを2つ作って、2つCreateすると、2つ目のCreateはAssertでとまってしまいます。2つのメニューを表示させる方法はありませんか? >>118 「Method should be called once!」 なんてコメントが入ってるくらいだから、メニューは一つという設計なんだろう。 CMFCToolBarにCMFCToolBarMenuButtonを並べたほうが早いかも。 見た目を完全にメニューと合わせるなら、派生クラスを作ってオーバーライドする必要もあるだろうけど。 menuボタンを並べるのは良いアイデアだと思います。IEdemoというサンプルを見ていたら、LinkBarというクラスを作って使っていました。2つのメニューは、やはり初期化しないのが良さそうです。1つは別の物にしてみます。ありがとうございます! IEDEMOのMFCコード、なかなか思い道理に動きません。MDIでサンプルを作って、CLinksBarとCLinksButtonを移植しようとしましたが、表示がバグります。バグっているけれどマウスカーソルをあてると、TOOLTIPが表示されます。何かが足りないようです。難しい >>121 >>121 実際に見ていないからわからないけど、 ツールバーの情報は標準でレジストリに保存されてしまうから、 開発中は定期的にレジストリを消さないといろいろ原因不明の現象は起こる。 一度消してみたらどうかと。 ちなみに、m_wndToolBar.LoadToolBar()のあとに以下の処理を入れたら、 とりあえずツールバーにメニューを出すサンプルにはなる。 (これも一度レジストリの削除は必要) CMenu menu; menu.LoadMenu(IDR_MAINFRAME); for (UINT i = 0; i < menu.GetMenuItemCount(); i++) { CString strText; menu.GetMenuString(i, strText, MF_BYPOSITION); m_wndToolBar.InsertButton(CMFCToolBarMenuButton(-1, menu.GetSubMenu(i)->GetSafeHmenu(), -1, strText)); } >>122 さんのおかげで先に進めました。 下記のようにしたら、思い通りのメニューが出て、しっかり動いてくれました。 /* if (!m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) || !m_wndToolBar.LoadToolBar(theApp.m_bHiColorIcons ? IDR_MAINFRAME_256 : IDR_MAINFRAME)) { TRACE0("ツール バーの作成に失敗しました。\n"); return -1; // 作成できない場合 } */ m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC); CMenu menu; menu.LoadMenu(IDR_MENU_2); for (UINT i = 0; i < menu.GetMenuItemCount(); i++) { CString strText; menu.GetMenuString(i, strText, MF_BYPOSITION); int menuID; menuID = menu.GetMenuItemID(i); m_wndToolBar.InsertButton(CMFCToolBarMenuButton(menuID, menu.GetSubMenu(i)->GetSafeHmenu(), -1, strText)); } Toolbarはとても難しいですね。私だけではとても思い通りの物は作れませんでした。>>122 さんありがとう! MDIで色々ウインドウを出すと、チャイルドウィンドウのタイトルバーが:1 :2になったり、消えてしまったりします。特に後ろになったチャイルドウィンドウのタイトルバーが書き換わって、タイトルが消えてしまう問題に頭を痛めております。 CWNDクラス内などにウインドウタイトルの情報を保持していて、時々その保持している情報で書き換えているように思うのですが、保持している情報がどれなのか、書き換えられるのかわかりません。 今の所OnPaint内でGetParent()->SetWindowTextで書き換えているのですが先のようにチャイルドウインドウが後ろに回るとタイトル表示が消えたりします。なにか良いタイトルバーテキストの書き換え方法は有りませんでしょうか? 124が消したり書き換えているんだと思う。 素のMDIプロジェクト作ってもそういう動きになる? 素のMDIプロジェクトだとなりません。素のままだとタイトルバーがチャイルドウインドウの数に応じてプロジェクト名+1,2,3と表示されてしまいます。 チャイルドウインドウのFormView別にチャイルドウインドウのタイトルを変化させたいのですが、うまくいきません。 タイトルバーをもっと思うように書き換える方法を探しております。 CDocumentのサブクラスでSetTitle(LPCTSTR lpszTitle)をオーバーライドして独自のタイトルを付けるのはどうかな。 よく覚えてないけど独自のタイトルじゃなくlpszTitleを加工しようとすると嫌な感じにハマった記憶が、、 >>124 CMDIChildWnd::OnUpdateFrameTitle()をオーバーライドしてみては。 何科変化するたびにこの関数が呼ばれるし、 デフォルトの処理だと、ここで":1"とか追加している。 >>127 さん CDocumentのサブクラスCDocumentExを作ってSetTitleをオーバーライドしてみました。 その他、ドキュメントクラスはCDocumentからの継承ではなくCDocumentExから継承させるようにしてみたのですが、CDocumentEx::SetTitle関数は呼ばれないようです。 CDocumentクラスのオーバーライドではだめかもしれません。 >>128 さん ちょっと試してみます! >CMDIChildWnd::OnUpdateFrameTitle()をオーバーライドしてみては。 OnUpdateFrameTitleをオーバーライドして、親クラスのメソッドをよびにいく時のパラメーターをfalseにしてみたところ、チャイルドウインドウのタイトルが書き換わらなくなりました。 ありがとうございます! mfcで見た目の良い(テーマを適用した)ラジオボタンを出したいと思っています。ところが、ラジオボタンのクラスとして、CMFCRadioButtonというクラスがありません。 恐らくCMFCButtonクラスのインスタンスを生成してラジオボタンとして用いるのかなと悩み、CMFCButtonクラスの継承でCMFCRadioButtonクラスが作れないものか、考えています。 CMFCRadioButtonクラスは作ってみた物の、CMFCRadioButtonクラスのOnDrawが呼び出されません。CMFCタイプのラジオボタンを生成する良い方法はございませんか? >>132 virtual void OnDraw(CDC* pDC, const CRect& rect, UINT uiState); をオーバーライドしたら、ちゃんと呼ばれているように見えるけど。 リソースではラジオボタンを定義しておいて、DDXCONTROLからCMFCRadioButtonクラス(CMFCButtonクラス派生)とひもづけると、外観がボタンになってしまいます。 外観はボタンですが、確かにCMFCRadioButtonクラスのOnDrawは呼び出されます。 外観がボタンではなく、ラジオボタンにする方法をご教示下さい。 >>134 CMFCButtonの標準の描画処理がボタン前提になっているので、 ラジオボタンの見た目を表現したいなら、 OnDraw()などをオーバーライドして自分で完全に描画するしかないかと。 そもそも、CMFCButtonではなくCButtonにしてしまえば、 Windowsのテーマに従ったものは描画されるけど、 そうではなく、CMFCVisualManagerのテーマのことでいいんだよね? 最新のMFCは知らないけど、2008で導入されたときのMFCは、 ダイアログや内部のコントロールのテーマ描画は対応してない。 ライブラリの元となったBCG社が、機能を別売りしている。 ttps://www.bcgsoft.com/featuretour/tour240.htm 2008年にMSがBCGを買収してCommunityEditionにこれが入っていたら、、と思う。 CMFCVisualManagerでたぶんあっています。 mfcのコンパイルオプションをUnicodeモードにすると、ラジオボタンの見た目が変わることは分かったのですが、ANSI(ShiftJIS)モードでコンパイルしたいのです。 今気になっているのは、manifestファイルを追加してみようと思います。 http://gurigumi.s349.xrea.com/programming/visualcpp/sdk_luna.html >>137 それはCMFCVisualManagerではないぞ。 Windowsのテーマのほうだ。 マルチバイト文字モードでコンパイルした場合の見た目の違いです。DDXControlで左はCButton右はCMFCButtonとひもづけました。 https://i.imgur.com/4qA7an3.jpg やはりmanifestファイルのようです。マニフェストファイルでラジオボタンは変化しました。 マニフェスト適用後 https://i.imgur.com/JqRoqH4.jpg マニフェスト適用前 https://i.imgur.com/lC9fLyO.jpg このスレはVisualStudioの使い方、 質問はアプリケーションの作り方 微妙に違うといえば違う。 かといって誘導出来る適当なスレは見当たらない MFCのスレくらいかな mfcのスレでmfcのクラスに関する質問をしていますよ。 Excelでキャレットの無い状態から日本語入力をするとテキストボックス?が現れて文字が未確定状態で表示されますが 同様な動きををCViewとCEditでやろうとしています。 以前はViewのOnCharからCEditにWM_CHARをポストすることで普通に動いていたのですが、OSの仕様が変わったのか 最初の1文字が確定状態で表示されてしまいます。ATOKもMS-IMEも同じです。 何かヒントがあれば教えてください。 excelでキャレットの無い状態というのがわかりません。^が無い状態で入力を開始するのでしょうか? >>144 レスありがとうございます。 Excelを起動した直後、あるいはセルへのキーボード入力が完了した直後など、矢印キーでカーソルが動く状態のことです。 文字入力時に点滅する「I」のような記号がキャレットです。 回答になっているかどうか分からないのですが、CViewクラスではない場合でCListCtrlクラス内にCEditを貼り付けて、そのCEdit上で編集をする例は有ります。 CView上にCEditを張り付けているような応用にもかなるかもしれませんので、例を上げます。 http://www.softist.com/programming/listctrl-edit/listctrl-edit.htm >>147 レスありがとうございます。 ダブルクリックでCEditを出して〜という動作は当方でも問題なく出来ています。 すみませんお助けください 親ウインドウにテキストボックスとボタン、ボタンを押すとdomodalでウインドウが呼び出されます その子ウインドウにはリストボックスがあって、そこには親のテキストボックスに入力された文字が表示される そういうものを作ろうとしています 親テキストボックスの変数名がm_input setvalueでプライベートにしてるリストボックス変数にそれを格納しています ですがこれですとウインドウは表示されてもリストボックスはからっぽです。 一体何が悪いのでしょうか void 親ウインドウクラス名::OnBnClickedButton1() { PopupDlg pdlg; UpdateData(TRUE); pdlg.setValue(m_input); pdlg.DoModal(); UpdateData(FALSE); } >>149 setValueの引数の型や、それをPopupDlgがどのように扱っているのかを見せないと、 それだけではなにもわからないよ。 すっかり遅くなったけど申し訳ない oninitdialogに処理書いたらなんとかなりました MDIウィンドウの場合で、メニューのフォントとフォントサイズは変えられますか? ツールバーの右端に出てくるボタンの表示非表示を無くすことは出来ますか? >>152 MFC Feature Packのメニューやツールバーのことなら、 > メニューのフォントとフォントサイズ CMFCMenuBar::SetMenuFont > ボタンの表示非表示 CMFCToolBar::EnableCustomizeButton あれ? CListViewなくなったん? ウイザードにないw SDIかMDIを選んでいれば、ウイザードの最後の項目でViewを選択できるはずです。選ぶ中にCListViewは有るはずです。 そんなわけ無いだろうと思ったけど、無いね.. CListViewは存在するけどウィザードでは選択できなくなったのか 結構便利なクラスだと思うんだけどな 確かに2017communityでは、無くなっています。2013Communityには有るようです。 まぁこのへんの仕組みはもう変わらないだろうし、 適当なものを選んでから書き直しても問題ないけどな。 ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の 両院で、改憲議員が3分の2を超えております。 『憲法改正国民投票法』、でググってみてください。国会の発議は すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ >>153 > >>152 > MFC Feature Packのメニューやツールバーのことなら、 > > > メニューのフォントとフォントサイズ > CMFCMenuBar::SetMenuFont > > > ボタンの表示非表示 > CMFCToolBar::EnableCustomizeButton 使い方がよくわかりません。適当なパラメーターがよくわからず、CMainframe内で呼び出してはみた物の、うまくフォントのサイズは変わりません。 ボタンの追加も消せませんでした。 >>166 とりあえずこんな感じで書けば変わる。 ただ、あまり大きくすると、縦にドッキングしたときに文字が欠ける。 最新バージョンなら直っているのかもしれないけど、 自分のアプリではメニューは上部固定なので、深くは調べていない。 > メニューのフォントとフォントサイズ NONCLIENTMETRICS metrics; metrics.cbSize = sizeof(metrics); SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(metrics), &metrics, 0); LOGFONT lfMenu = metrics.lfMenuFont; _tcscpy_s(lfMenu.lfFaceName, _T("MS P明朝")); lfMenu.lfHeight = -24; CMFCMenuBar::SetMenuFont(&lfMenu); lfMenu.lfOrientation = 900; lfMenu.lfEscapement = 2700; CMFCMenuBar::SetMenuFont(&lfMenu, FALSE); > ボタンの表示非表示 m_wndToolBar.EnableCustomizeButton(TRUE, -1, _T(""), FALSE); もしくは、EnableCustomizeButtonを呼ばない。 軽く煽ると答えを書いてくれるこのスレはチョロいよねw 質問に答えると負けなんだろうか。 他のスレでも、質問に「答えない」ってだけのしょうもないマウントとりにくる人を見かけるね。 >>168 ありがとうございます。メニューのフォントサイズを変更でき、ボタンの追加・削除を消せました。 私ではとても考え付かない設定です。ありがとう!! 温度情報などをグラフにしてFormView上に描画できないか考え込んでいます。自前でCDCに描いていくのではなく、描くのに適しているmfcのライブラリは無いものか、探しています。どなたか目盛りのついたグラフ描画に良いクラスはご存じないでしょうか? 昔の話で何ですが、DOSの時代にはMSCなどにグラフ描画ライブラリが付いてきていたような記憶があります。mfcには無さそうですよね。 >>179 最新版は知らないが、昔のMFCには無かったと思う。 (昔の) MSDN Library をよく見ているが、発見してない。 でも、グラフ描画って、LineTo() だけでも大体いけると思うんだけど。 OLE2使ってExcel呼べばいいんじゃね? MFC関係ないのでスレチだけど >>180 MSC = Microsoft CというDOS用のコンパイラです。1990年代のお話です。 >>174 >>177 matplotlib の python 用 dll を c/c++ から使う手がある .NETのChartコントロールをユーザーコントロールに置いてMFCダイアログでホストってのをやったことあるよ。 MFCビューでのやり方もMSDNに書いてあるからその通りやればできると思う。 MFC、Windowsフォーム、辺りで検索すれば見つかるはず。 .netはちょっと重いです。それでも参考になります。ありがとうございます。。 mfcとexcelの連携が全然分かんない……COM?何それ?みたいな msdnとかstackoverflowとかいろいろ漁ってもだめ。っていうかそもそもmfc、windowsってよくわかんないクラスとか変数とか多すぎじゃない もっと簡単にプログラミングさせてよ!って思う 昔、MFCに慣れてきた頃、趣味でMACのプログラミング勉強しようとして挫折したことがある。 Excel連携なら、その箇所だけでもVBでやるのがお勧め。 折れ線グラフをMovetoとLinetoで描くことにしました。線分を引くに当たって、GDI+とGDIでの描画速度を検証してみました。 32bit win7 corei5で24×1,024本の線分を描きましたところ GDI+ drawLine 7300ms GDI Moveto Lineto 350ms という結果になりました。 mfcのMoveto Linetoは速いですよね。画面のサイズによって速度はだいぶ変わるようです。 c#などのASP.net環境では、グラフを生成するAPIが有るようですね。サーバ上で簡単にグラフを生成し、クライアントのブラウザから見られます。 >>195 検証おつ。少数派かもしれませんがこういうの好きです。 CFormView内でOnMouseWheelを使っていたのですが、コンボボックスを配置したところ、OnMouseWheelのイベントに飛んでこなくなりました。 今のところ、コンボボックスを継承して、コンボボックス内のOnMouseWheelイベント内で、親クラスへSendMessage(WM_MOUSEWHEEL )する事で動かせるようにしました。 この先、ほかのコントロールが追加されたら、またOnMouseWheelイベントを拾えなくなると思い、もっと良い方法があればと思っています。どなたか良い解決策をご存じですか? >>198 CFormView派生クラスのPreTranslateMessage()で横取りしてしまうのが簡単かと 確かに横取りで解決できました。ありがとうございます。 コンボボックスをドロップダウンリストに設定した場合のフォーカスについても伺いたいのですが、 CFormViewクラス内にドロップダウンリスト型のコンボボックスを配置すると、キーボードのフォーカスがコンボボックスに設定されてしまいます。 CFormViewに対してSetFocus()を呼び出しても、フォーカスがコンボボックスから外れません。 コンボボックスが青く塗りつぶされて選択状態になっているのを解除する方法をご存知ないですか? >>200 CFormViewのソースを見るとわかるけど、SetFocus()を呼んでも、 OnSetFocus()の中で最後の位置に復元される。 その動きを別なものにしたいのなら、 OnSetFocus()をオーバーライドして、なにかしらの対応が必要かと。 なにもしないようにしてフォーム自身がフォーカスを持ってしまうとか、 サイズ0のダミーのボタンでも置いておいて、毎回そこにフォーカスを移すとか。 ダブルバッファリングについて質問しても良いですか? ピクチャーコントロールのダブルバッファリングを行いたいと思っているのですが、画面のサイズを大小いじられ続けると、GDIリソースを食いつぶして、アプリケーションが落ちます。 色々試して、画面サイズ変更イベント内のCreateCompatibleBitmapのところで確保したGDIリソースが DeleteObject();されるときに、GDIリソースを一つ多く確保し続けるようです。 CBitmap test; test.CreateCompatibleBitmap(ピクチャーコントロールのdc,-,-); //GDIリソースが+2される test.DeleteObject(); //GDIリソースがー1される 差し引きGDIリソースの確保量が+1になります。 そのうち線を書けなくなり、アプリケーションがクラッシュします。 使い方がどこか良くないのだと思うのですが、パラメータ等が良くないのかな。などと考え込んでいます。解決策をご存知ないですか?GDIリソースの確保量はタスクマネージャの設定でGDIリソースを表示できるようにして確認しています。 CreateCompatibleBitmapの前後5行ぐらいに原因がありそうな気がする >>203 自分で開放しないといけないのを忘れてるだけじゃないかな リソースの解放はDeleteObject();ではないのですか? CreateCompatibleBitmapの前は、CreateCompatibleDCを呼び出しています。 CreateCompatibleDCのDCパラメータをNULLに設定すると、GDIリソースの浪費は無くなりますが、今度は出てくる画面が白黒になってしまいます。 >>206 ピクチャーコントロールのDCをGetDC()で取得してしてるのでは スタック上でCBitmap test;とやった場合 関数を抜けるときに勝手にデストラクタでDeleteObjectされると思う。 もう少しコード晒さないと判らない。 CreateCompatibleDCでは、ピクチャーコントロールのDCを取得させています。 ピクチャーコントロールのDCを渡すと、CreateCompatibleBitmap時にGDIリソースを消費する量が2となるようです。 CreateCompatibleDCにNULLを指定した場合(確か)CreateCompatibleBitmap時のGDIリソース消費量ばかり1となります(以後の描画は白黒になります)。 今しばらく書いているコードをみられません。 CreateCompatibleDCやCreateCompatibleBitmapをOnSize時に破棄させてはサイズを変えて再生成させると、GDIリソースが消費されて減っていくので、 アプリケーション生成時に画面の最大サイズでCreateCompatibleDCさせておき、あとはCreateCompatibleDCしないように変更することも考えております。 アプリケーション生成時に画面のサイズ分のCreateCompatibleDCさせるようにすると、マルチモニタ環境の時などの動作が正常に動作しないかもしれないと思い、 可能ならOnSize内でDeleteObject();させてCreateCompatibleDCさせたいと思っています。 なお、OnSizeから抜けてもGDIリソース消費量は下がってくれないようです。 207が言っているのは bitmap.CreateCompatibleBitmap(pict->GetDC(), rc.Width(), rc.Height()) してるんじゃないかって事。これだとリークします。 >>212 > 207が言っているのは > bitmap.CreateCompatibleBitmap(pict->GetDC(), rc.Width(), rc.Height()) > してるんじゃないかって事。これだとリークします。 しています。その上でどのように直すべきか察しが付きません。やはりReleaseDCで直りますか? ReleaseDCで直る。 私なら 解放不要なCDC::FromHaqndleを使う。 >>212 CClientDCを使うのが一番簡単だけど、 CreateCompatibleDC()のほうは引数はなにを渡しているんだ? >>213 CDC::FromHandle()はHDCがわかっているときに使うもので、 今回のDCを取得すること自体には使えない。 >>216 CompatibleDCの引数はピクチャーコントロール内のDC memDC.CreateCompatibleDC(ピクチャーコントロール.GetDC(),ピクチャーコントロールのx,y); だったと思います。 GetDC()でピクチャーコントロールのDCを取得していたか、GetSafeDCでピクチャーコントロールのDCを取得していたかちょっと思い出せません。 CreateCompatibleDCのパラメータはDC一つだけでしたね。ごめんなさい。 GetDCの返り血はReleaseDCしないといけない。 ReleaseDCではGDIリソースがー1になりますが、createCompatibleBitmapで+2消費したぶんのすべては解放されてくれません。 releaseDCはおこなっていますが、GDIリソースの消費量は依然として+1になってしまいます。 原因わかりました。 memBmp.CreateCompatibleBitmap(picctrl.GetDC(),x,y); が良くなかったようです。 GetDC()でGDIリソースを1消費し、解放出来なくなります。 CDC *pDC; pDC->picctrl.GetDC(); memBmp.CreateCompatibleBitmap(pDC,x,y); DeleteObject(memBmp); ReleaseDC(pDC); に直したところ、ちゃんとGdIリソースが戻りました。 pDC=picctrl.GetDC(); に修正します。 解答いただいた方々、ありがとうございます。 >>222-223 最初からみんなそう言ってたのに > CDC *pDC; > pDC=picctrl.GetDC(); > ReleaseDC(pDC); picctrl.GetDC()したものを親がReleaseDC()しているのが気持ち悪いが、 これでも正しく動くのか? GetDC()したらReleaseDC()する必要があるのだと思う。CDC*はデストラクタ処理に入れないからReleaseDCする必要がある。 VC++.net CLRとかなら自動でやってくれるのだろう。 >>226 picctrl.ReleaseDC(pDC); とするべきではということなんだが。 そもそもCClientDCを使えばGetDC()なんて自分で呼ぶ必要はないが。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 HQL0Y バイナリデータ(buf)を受け取ってピクチャーコントロール(m_picture)に 描画したいのですがBitBltのところで "Debug Assertion Failed!" が発生してしまいます。 何が悪いのか教えていただけないでしょうか? PAINTSTRUCT ps; CBitmap bitmap; CImage image; CDC *pDC; pDC = m_picture.BeginPaint(&ps); pDC->SetBkMode(TRANSPARENT); pDC->SetStretchBltMode(COLORONCOLOR); bitmap.CreateBitmap(width, height, 1, 8, (void*)&buf); HBITMAP hBitmap = HBITMAP(bitmap.GetSafeHandle()); image.Attach(hBitmap); image.BitBlt(pDC->GetSafeHdc(), CRect(0, 0, image.GetWidth(), image.GetHeight()), CPoint(0, 0)); image.Detach(); image.ReleaseDC(); m_picture.EndPaint(&ps); ASSERT(IsWindow(m_picture)); してみれ。 >>232 連絡ありがとうございます。 やってみましたがプログラムが止まらないので問題ないみたいです。 まず"Debug Assertion Failed!" が出ているのならちゃんと再試行を押そうよ。 それだけで原因そのものはわかる。 CListCtrでレポート表示のFullRowSelectをカスタムドローを弄ってます。 マウスがアイテムの上に来たら色を変えたいけど、カスタムドローのイベントハンドラだけできますか? OnMouseMoveでどこにあるか判定してカスタムドローで描画が必要? ビットマップを3番目のSubItemだけに貼るとか、16x16のSmallサイズ以外だとうまくいかないとか、癖が凄い。 tooltipの表示内容を一つのピクチャコントロール内で変更したいのですが、マウスカーソルが一端ピクチャコントロールから外れないと、ツールチップの内容が更新されないようです。onmousehoverなどを使わないと駄目でしょうか? Tooltipの件ありがとうございます。 おかげさまで何とか解決できました。 datを生成するMFCプログラムがありまして、そのdatからデータを読み込んでexcelの形式に合わせて出力するダイアログベースのMFCプログラムがあります 最初のプログラムから呼び出されて処理をするだけなので、ウインドウの表示とかしないです。ただただ処理して終わりです それで問題なんですが通常のダイアログを使ったプログラムのように読み込み・変換処理を全部ダイアログ部分に書いてあるんです ダイアログ使いもしないのにここに書くのおかしくないですか?と聞いたら表示されないんだしいいでしょと。画面表示を行わないMFCプログラムの場合、コードはどこに書くのが自然なんでしょうか? あーすいませんわかりにくかったですね メインプログラムがあってその内部でdatを生成するんですよ で、そのdatのパスをコマンドライン引数で別のプログラムに渡すんですね スレッドというかそもそも2つのプログラムですわ MFC関係ないのにここで聞くのおかしくないですか? 事情が見えない。 どーーしても別プログラムにする事情があると仮定すれば DialogやConsoleで構わないと思う。 冗長さを排除したいなら_tWinMainから書く手もあるけど 体感できるような差は出ないかと。表示されないんだしいいでしょw >>241 >ダイアログ使いもしないのにここに書くのおかしくないですか? じゃぁどこに書けばいいの? >>241 MFCの仕組みを使いつつ、まったくウィンドウ表示が不要なものなら、 アプリケーションクラスのInitInstance()の中で処理して、 FALSEを返してすぐ終了するという流れでよいのでは。 >>247 結局それにしました。 あとは処理を分担するふっつーのC++クラスいくつか作ってダイアログは完全に使わない感じで 横から失礼します InitInstanceの場合は標準出力にメッセージを出せますか? 標準出力に出すmfcプログラムだとすると、_twinmainを使うとどうでしょう。 どちらもやったことありませんが可能だと思います。 私なら _tmain 使うとおもいますが。 CListViewがウィザードに帰ってきた!! やほーい MFCというかプログラミング姿勢に関しての質問かもしれないんですけど CやC++で標準的に実装されてる機能とMFCクラスで実装されてる機能、どちらを使っても 同じことが実現できる場合、どちらを優先して使っていくべきなんでしょうか 要するに文字列ならchar*かstringかCStringか ファイル操作ならfopenかstreamかCfileかみたいな >>254 そうでもない。 >>253 文字列は、単に文字列を保持したい場合や、文字列連結を行いたいような場合は、CStringが便利だと思う。 パーサーなんかを自作する時は、char *が便利。 >>253 ファイル操作は、経験上は、fopen()が便利かな。 CFileは意外と不便だった気がする。 stringは、敢えて使う必要は無いと思う。CStringで十分。 機能が同等なら好みでいいと思うけど、ファイル操作みたいにOS依存が強い機能は 標準ライブラリじゃ足りない場合が多いかな。 MFCのGUI特化した本ないのかねー 大概が初心者向けでポインタやら構造体やらMFCと関係ないことが大半を占めてて知りたいことはうすーくしか書いてないのばっか >>259 20年も前の本だが、お奨めは ttps://calil.jp/book/475611749X >>260 ありがと 1万くらいなら買うんだけどなぁ 本でなくて申し訳ないけど ヘルプ。 クラスも大幅に拡張されてしまい昔の良書だとツリービュー、リストビュー位まで 最近のリッチな所はヘルプからサンプルソースにたどるのが早いかと カーネルという意味では、ないやろな。性能面の要求はそんなに甘くないよ。 周辺の付加的モジュールでは、ATLとかは使ってるかも Windows7のペイントとかワードパッドとかをSpy++で見ると、 Afx〜の付くウィンドウクラス名が使われてるから、 このあたりはまだMFCで作られてたんじゃないだろうか。 「コンピューターの管理」なんかも、AfxWnd42やAfxFrameOrView42uが出てくる。 VC++6.0で作っています。 MFCです。 普通にSDIを作りますが、そこからメニューバー等からダイアログボックスをモードレスで起動します。 すると、ダイアログを起動しながらメインウインドウも触れるようになるのですが、そのフォーカスを モードレスダイアログとメインウインドウとをマウスを使わずにキーボードで切り替えることって出来ませんか MSのWindowsOSのAlt+Tabではこれらはひとつとして認識されているようでこれでは切り替えられません ちなみに、Windows7です >>271 メインウインドウからモードレスダイアログを起動するのですが、すると、Alt+Tabではこれらはひとつとして 認識されますよ >>273 Ctrl+TABでは、ダイアログ上のコントロールのフォーカスが変わっていきます ウインドウの切り替えはできません >>275 やってみましたが、Alt+Tabでアプリを変えていけますが、そこに出てくるアプリの数が減っているのを 除いて、同じ動作です。 アプリが変わります モードレスの親がメインウィンドウなら切り替えできず、親がない(デスクトップ)なら切り替えできるのでは。 親がメインウィンドウの場合でも、PreTranslateMessageでTABキーを補足してSetForegroundWindowとかすればいいと思う デフォルトでは用意されていないのかな PreTranslateMessageを使えばなんでもできますが、 メインウインドウとダイアログと両方に書かないといけないからなあ。しょうがないのかな PreTranslateMessageで書きますか。 キーは何をあてるのが自然でしょうか Ctrl+Tabあたりかな タブコントロールは、Tab だけと Shift+Tabで動きますからね vista、vs.net2003 vc++の組み合わせだが ALT+TABでアプリがきりかわりながら ふつうにSDIとモードレスのダイアログでトグルする >>280 わざわざありがとう。私と環境がちがうからなのかな PreTranslateMessageを利用して、Ctrl+Tabでプログラムを作りました。これでうまく行きました >>281 ダイアログをCreateする時、親ウィンドウ(省略時=NULL)を指定していないから、 アプリケーションのメインウィンドウ(=AfxGetMainWnd())が、親ウィンドウが になっているからでは? CDialog::Create(CWnd::GetDesktopWindow()) とかでいけるはず。 MFCとは関係なく、Windows APIでは、所有ウィンドウ (Owner Window)と、親ウィンドウ(Parent Window)は別管理。 MSDN見ても解決しないのでお願いします。 CMFCColorDialogで作成した色選択ダイアログの動きが少しおかしいです。 どれかの色(六角形)を選択すると[OK]ボタンのフォーカスが当たり、再度 別の色を選択するとフォーカスが外れるんですが、仕様でしょうか?? >>284 VS2008のNewControlsサンプルではそういう動作は見られないけど、 再現できるサンプルでもありますか? >>285 わざわざ試していただいてありがとうござます! こちらの環境、Windows10、VisualStudio2017なのでこれが原因っぽいです。 古いVisualStudioで試してみます。 業務アプリなのでサンプルは出しにくいです。申し訳ないです。 >>282 おお、今頃ですが、ありがとうございました これでAlt+Tabでもモードレスウインドウが出てくるようになりました ! 今まで、VC++6.0でずっとやってきました。特にそれで問題なかったからですが、意を決して、 Visual Studio 2017をインストして、古いソースコードを移植しようと思っています VS2017に古いVC++6.0のdswファイルを読ませたのですが、うまくj変換できないようですが、どうしたら良いでしょうか VC++6.0からの変換は出来ませんか ワークスペースはソリューションに変わった。新しくソリューションファイルを作って、そこにC/C++のファイルを追加してビルドだ。 インクルードファイルとかいろいろエラーがたくさん出てきたよ これ相当無理っぽい??? 取りあえず、簡単に比較するために、VC++6.0でMFCのSDIのデフォルトを作りました それと比較するため、VS2017でC++のWindowsデスクトップのデスクトップアプリケーションのデフォルトを作りました すると、VS2017の方はMFC自身を使わないバージョンなのかな、CMainFrmとかIMPLEMENT_DYNCREATEとかなくて VC6.0++のMainFrm.cppとかを2017の方に持ってきてコンパイルしたらCMainFrmが定義されてないとか ずらっとたくさん出てきます MFCに対応したプロジェクト/ソリューション設定じゃないとダメかも >>293 VS2017で、それを探してるのですが見つからないのですよ MFCには対応してるのですよね。2015かそれ以前にはすでに対応してると聞いていたのですが MFCを使ったデフォルトのコード生成はしてくれないとか??? w Visual C++の中にMFCがある。Visual C++という項目がなければ、インストールが間違っている。 >>295 メニューのファイルから新規作成、プロジェクトを選ぶと、その中にVisual C++はちゃんとありますよ で、そこでWindowsデスクトップアプリケーションを選んでデフォルトを作ると、コードはSDKみたいなコードを吐きます で、Windowsデスクトップウィザードってのがあったので、今これを選択してみたのですが、 アプリケーションの種類をコンソールにすると、その右にあるMFCのチェックボックスが有効になるのですが 続き Windowsアプリケーションってのを選ぶと、MFCのチェックボックスが使用不可になってしまいます MFCアプリが作れないなら、インストールで追加するしかないぜ。 おいおい、なんだこれ VS2017で、新規作成、プロジェクトで、Windowsデスクトップウィザードで コンソールアプリケーションでMFCをチェックしてデフォルトのコードを自動生成してみました そしてソリューションのビルドしたら、CWinAppが定義されてないとかエラーがわんさか出てきたぞ おいおい、デフォルトの自動生成コードもビルド出来ないじゃん >>299 おや、そこが違う。 私のは、 visual C++の下に Windowsデスクトップ クロスプラットフォーム MFC/ATL テスト その他 Extensibility ってなってて、 MFC/ATLのところは ATLプロジェクト ってのだけがあります 何かインストを失敗してるのかなあ。 あるいはインストするときに何をインストするのかチェックがあったんだが それを間違えてるのか。 でも俺がチェックをしなかったのはモバイル関係のところくらいだったんだよねえ VS2017は頻繁に変更されるもんだから、ちょっと混乱してるみたい。 >>304 ありがとう。 右側の概要ってとこが、私のでは、インストールの詳細になっていて、 MFCとATLのサポート ってのが私のでは、 x86用とx64用のVisualC++ATL x86用とx64用のVisualC++MFC ってわかれていて、ATLの方にだけデフォルトではチェックが入っていてMFCの方のチェックは デフォルトでは外れていました。 チェックして再インストしてみますねw ただいま、 再インスコ中です みなさん、 VS2017をインスコするときは、 MFC はデフォルトでは入らない !!! ことがわかりました VS2017をインスコするときは、注意しましょう インスコするとき、オプションをチェックすると入ります、 多分。今やってるところ Qiitaの記事、結構役に立ってるじゃん。責任ある情報技術者なら、Qiitaに記事を書ける程になってもらいたいね。 出来ました。 MFCのインストがちゃんとできて、 MFCアプリケーションでデフォルトのMDI作ってみたら、 あら、すげえ クラスビューなんかが出てくるのねw おや、新しいバージョンだと、 strcpy( a, b ) で、b に CSringとか出来ないんだね。 前の古いバージョンでは出来たのに CString で返す関数も、char a[10] とかで宣言したのを、古いバージョンでは、retuen a って出来たんだが、新しいバージョンではエラーになる。 一旦 CString ret; ret = a; ってやって、return ret; ってやったらエラーが消えた いろいろと細かい修正しないとダメみたいだねえ 暗黙の型キャストのあいまいさが嫌いな人が存在するらしい。 >>314 いろいろとありがとう。 今日はとりあえずここまでにしておきます >>317 これありがとう。LPCWSTRの関係で、めっちゃ詰まってました >>313 そもそも、CStringはTCHARを扱うクラスなのに、 _tcscpyではなくstrcpyを使っていたのが間違い >>319 今は、_tcscpyを使ってもエラーが出るけどな >>320 それはエラーではなくてセキュリティ上の警告では >>321 そうです。 _sを付けたのを使えって 警告の設定を変更しないとエラーになってコンパイルが通りません それをプロパティの設定で、Unicodeからマルチバイトに切り替えてコンパイルしたんだけど、どうも Unicodeのままでうまく切り替わらないようなんですよねえ。 どうなってるのか。 今は時間がないので またあとでやってみますが >>322 警告だから、それに関してはコンパイルは通る。 他の場所がコンパイルエラーになっているだけかと。 VS2017ですが、新規作成で、MFCアプリケーションで作った時、 新規作成途中に出てくるSDLのチェックをつけて作成したときと、はずして作成したときと両方してみました すると、SDLつきの時は、_tcscpyはエラーになってコンパイルできませんが、 SDLをはずして新規作成したのものは、エラーにならずにコンパイルできて実行できます デフォルトはSDLつきなので、コンパイルできません 次に、新規作成して出来上がったプロジェクトで、 メニューのプロジェクトから一番下のプロパティに入って、構成プロパティ、C/C++の全般にある SDLチェックというところで、はい(/sdl) いいえ(/sdl-)を切り替えてやってみると、 この切り替えが動作せず、SDLのオン、オフが効きません。 プロジェクトの新規作成のときに設定したものが 残っていて、あとからここのプロパティで変更ができないようです 同じように、プロパティの構成プロパティの全般で、文字セットがデフォルトではUnicode文字セットを使用する になってるのですが、これをマルチバイト文字セットを使用するにしても Unicodeのままでマルチバイトにならないようです バグですかねえ? >>324 VisualStudioCommunity2017で試したが、普通に設定が反映されたぞ。 DebugとRelease、x86とx64で設定が別なのに気づいてないとかじゃないか? >>326 できました。多分それです。ありがとうございました コードの編集画面の上にあるコンボボックスを見ると、Debugとx86になってるのですが、 その状態でプロパティを開くと、なぜか、x64になってました。 なのでプロパティ画面で、上にあるプラットフォームをアクティブ(Win32)に変えると、画面がおかしくなって びっくりしましたが、画面の再描画ができなかっただけなようで、再びプロパティ画面を出して アクティブ(Win32)を確認してから、マルチバイトやSDLの変更をしたら、ちゃんと動いたようです プロパティ画面を開くときは、連動してないので必ず確認してから変更しないといけないということですね ちなみになんとか誤魔化せないかと思って、 stdafx.h の最初に #undef UNICODE #undef_UNICODE ってやってみたら、コンパイルまでは全部のcppファイルで出来たのですが、リンクで未解決エラーが出て 出来ませんでした さすがにそれはおかしいのでVS2017再インストール推奨 >ちなみになんとか誤魔化せないかと思って 略 >リンクで未解決エラー MessageBoxA と MessageBoxW とかを自分で書き分けてみると解決するはず MFCのツールバーって、リバーのように、「ツールバーを固定する」の動作はできませんかね。 ユーザーがコマンドを選択したら、その場所から動かすことができなくなるようにしたいのですが。 subclass化してメッセージループトラップしてmoveをにぎりつぶす HWND hWnd はできるけど、 HDC hDC って、別アプリ(別プロセス)に渡して、書き込ませることは出来ないの? HDC の識別番号が、プロセスごとに別の「名前空間」みたいなことになってるのかな。 GDI objects support only one handle per object. Handles to GDI objects are private to a process. That is, only the process that created the GDI object can use the object handle. ↑によれば、HDC は、プロセス・プライベートだって、書いてるけど、 たまたますごいことみつけちゃったんだ・・・実は。 みんな知ってる? 実は、PrintWindow(HWND hWnd, HDC hDC, DWORD flag) API を使うと、HDC をプロセスの 垣根を越えて渡せるんだ。プロセスA からプロセス B に HDC を渡す場合、 プロセスA で、PrintWindow() API を呼び出す。hWnd にはプロセスBで作成した Window の HWND を、hDC には、プロセスAに所属している HDC を渡す。 MFCを使って実験してみると、この場合、プロセスBの hWnd にWM_PRINT メッセージが 来るが、OnPrint() ハンドラが BeginPaint(), EndPaint() を使わずに、メッセージから受け取った hDC を CDC *pDC に入れて、WM_PAINT の時と同じ OnDraw() を呼び出すらしい。 らしいと言ったのは、もしかしたら、MFCが途中で何らかの手を加えている可能性があるから。 で興味深いのは、この時の pDC->m_hDC の値は、プロセスA のオリジナルの値とは 数値的には異なっていると言うこと。 推定ではあるが、PrintWindow() API を使うと、Windows System が、プロセスA での hDC の 識別番号とは異なる識別番号を、WM_PRINT メッセージのの hDC に与える。 これは、>>337 で書いているとおり、HDC は、process private だから、プロセスごとに 「名前空間」が異なるため、プロセスの垣根を越えるときには、同じ値をそのまま使うことは 出来ないため。 でも、結局、「番号」が変わっているだけで、同じ Device Context を「指している」ので、 効率よく 描画動作を行える。 この API を使えば、プロセスA で用意した実DC や メモリーDC に、プロセスB の OnDraw() によって直接書き込ませることが出来ることを確認済み。 この話には続きがある。 Ubuntu Linux の Wine Emulator 3.2 で実験してみると、PrintWindow() が上手くいかないらしい。 なので、誰かに直して欲しい、と言うこと。 直してクレクレ。 >>338 さらに実験してみたところ、プロセスA から、プロセスB の HWND に対して、 PrintWindow() した場合、プロセス B には、WM_PRINT も WM_PRINTCLIENT も送られることなく、WM_PAINT、WM_NCPAINT が送られる。 興味深いことに、MainFrame のような、OVERLAPPEDWINDOW には、 メッセージキューを介すことなく、WM_PAINT、WM_NCPAINT が送られるが、 EditBox などの CHILD WINDOW には、メッセージキューに WM_PAINT が 格納された後、EditBox の WndProc に WM_PAINT、WM_NCPAINT が送られる。 もっと実験してみたところ、普段、PrintWindow() を使うことなく、Winow のサイズ 変更などをして再描画が必要な場合、(スレッド)メッセージキューには ポストされることなく、直接 WndProc に WM_PAINT、WM_NCPAINT が 送られてくる。 また、PrintWindow() に渡す プロセスA の HDC を、MemoryDC にして、 常に固定のハンドル値を渡してみた。すると、興味深いことに、 プロセスB では、ほぼ毎回異なる値の HDC が渡されることが分かった。 ただし、時々連続して同じ値の HDC が渡されてくる。連続回数は、 2回〜10回くらいまでの開きがある。 なお、PrintWindow() の速度は思ったより遅く、プロセスB側が(敢えて)何も 描画しない場合でも、なぜか、1.3x10^(-4) 〜7.1 x 10^(-3) (sec) 程度かかる。 つまり、50万クロック程度かかってしまう。ただし、有る程度の大きさの グラフィックを書いても、余り速度は変わらない印象を受けた。環境は書かないが、 余り速くはない 3.0GHz の Dual CPU のマシンでの話。 ウインドウを2枚用意して、片方を表に(上に)表示して、もう片方は裏にして見えないようにしている。で、裏の見えない方を 書き換えて、表のウインドウと入れ替えて、新しい描画のウインドウを出すということをしたいのです 裏メモリに書き込んで一瞬でモニターに出すという普通のやつをウインドウでします 裏でウインドウで書き込むとき、HIDE状態では書き込めないので、MINIMIZEの状態では出来ることがわかったので そうしているのですが、問題はそれを最大化するときに、どうしても描画に時間がかかるというか、一瞬では出来ないのです なので、アクティブ化せずに裏で最大化、あるいは、RESTOREする方法を探しているのですが、 APIのShowWindowとかだと、RESTOREもMAXIMIZEも必ずアクティブ化してしまうのですがいい方法はないでしょうか いろいろとやってみて、2枚のウインドウに違う絵をかいておいて、片方をHIDE、片方をSHOWして、このHIDEと SHOWと切り替えるってのが一番きれいに切り替わるようなのですが、書き込むとき、HIDEでは書き込めずに MINIMIZEして書き込まないといけないので、MINIMIZEして書き込んだウインドウを表に出さずに大きくしてHIDE状態に出来れは いいのですが MFCのSDIアプリケーションで、PCを一定時間操作しなかったときに、 「更新中」のダイアログをDoModal()で出して、内部の情報を更新する動作を作っています。 更新処理はダイアログの中で別スレッドで行っていて、 タイマーで定期的にスレッドを監視して、終わっていたらEndDialog()で閉じます。 他の操作を不可にした上でキャンセルは可能にするために、このように作りました。 ここまでは問題なく動いているのですが、 アプリケーションがアクティブでないときにこの更新処理が走ると、 「更新中」のダイアログが閉じられた後に、アクティブ表示になってしまいます。 表示がアクティブになるだけで、フォーカスまでは奪いません。 二つのアプリケーションがアクティブ表示になってしまう状態です。 不思議に思ってMFCのソースを追いかけたところ、 CFrameWndのOnEnable()やOnActivate()やOnNcActivate()で WF_STAYACTIVEのフラグを使ってアクティブ表示を強制するような仕組みがあり、 この中の処理を通った結果、アクティブ表示になってしまうようでした。 どうしてWF_STAYACTIVEに引っかかるのかなど、細かい流れは追い切れていませんが、 アクティブでないときに裏でダイアログが出て、その後自動で閉じるような動きを、 CFrameWndは想定していないということになりますでしょうか。 見た目のだけの問題ではありますが、CFrameWndの仕組みを保ったまま、 この現象を回避する方法はありませんでしょうか。 ダイアログの前にアクティブだったウィンドウをアクティブにしてから閉じる VS2019のリリースノートでのMFCへの言及は、廃止予定の機能一覧中にいくつかあるのみ。 MFCをバリバリ使っているわけではないけど、なんか悲しい。 空のソリューションを作って既存のAとBのMFCダイアログベースのプロジェクトを追加して、リソースビューでAにBのダイアログをコピペしたらIDが同じという警告が出た。 AのダイアログからBのダイアログをDoModalで呼び出す内容なんですが、ビルドも実行させても問題ないように見えるが大丈夫なんでしょうか? 数年前に作ったダイアログのコンボボックスの初期値が反映されなくなってたんだが CComboBox:: SelectStringの第一引数nStartAfterを0から-1にしたら動作した でもなんでやろ?0でよさげなのに いまやCDCといえばアメリカ疾病対策センター(Centers for Disease Control and Prevention)だね ローカルディスクの中で、MFCのCWinやCViewなどのソースは見られるのですが、 AfxGetApp()のソースコードだけが見つかりません。 どこにあるのでしょうか? デバッグすれば見つかると思う。 多分inline だからヘッダにあると。 >>358 拡張子を指定せずに、MFCのソースを含んだ全てのファイルを検索にかけたけど、 AfxGetApp()の定義だけは見つからなかった。 見落としは有るかもしれないが、当然、*.c, *,cpp, *.h, *.inl は全てチェックした。 >>359 afxwin1.inlのアタマにあるぞ。 afxCurrentWinAppを返してるだけだが。 >>360 GUIのgrepで、ファイルマスク欄に *.imp と入れたつもりが *,imp になってました。 orz KillTimer() という Win32 APIは、MSDN によれば、 The KillTimer function destroys the specified timer. The KillTimer function does not remove WM_TIMER messages already posted to the message queue. つまり、既にメッセージキューにポストされてしまった WM_TIMER は、「除去されない」とあります。 ところが、MFC の CWnd::KillTimer() は、MSDN によれば、 Kills the timer event identified by nIDEvent from the earlier call to SetTimer. Any pending WM_TIMER messages associated with the timer are removed from the message queue. つまり、どんな pending 状態の WM_TIMER メッセージも、メッセージキューから除去される、 とあります。 となれば、MFC の KillTimer() は、何か自分で処理を付け加えているのかと思って、 MFC のソースを grep検索してみると、AFXWIN2.INL に _AFXWIN_INLINE BOOL CWnd::KillTimer(int nIDEvent) { ASSERT(::IsWindow(m_hWnd)); return ::KillTimer(m_hWnd, nIDEvent); } となっているだけで、単に Win32 の KillTimer() を m_hWnd に対して呼び出している に過ぎません。 これはどういうことでしょうか?? そりゃ発行済でキューに入ったメッセージはそのままになる罠 自分で読んでしまえば消えるだけのこと >>363 ただ、WM_PAINT や WM_TIMER は、他のメッセージとは異なる処理を されています。 Win32のメッセージキューは、1つのキューに見えるものが、OSの内部では 複数本持っているか、描画のDirtyフラグなどでなんらかの特殊な扱いを しているようです。 WM_PAINTは優先度最も低いので常に後ろに行くってどっかで観た 実際には、WM_TIMER は、WM_PAINT以上に優先順位が低いです。 なので、PeekMessage()しても、他のメッセージがあれば WM_TIMERメッセージを 拾えるかどうかは余り定かではないと思います。 もしかすると、その場合には KillTimer()の処理に置いては、WM_TIMERが メッセージキューに「ポストされて無い」とみなされるのかもしれません。 解釈が難しいです。 いやー仕事でいじることになったんだけどぜんっぜんわからんわなんじゃこりゃ 独自定義の型山盛りでおまけにドキュメントも少ない。いやこれめちゃくちゃ難易度高くない 俺は昨年からC#のwinformに移行してメチャ楽勝です。 もうMFCに戻りたくないです。 でもthreadで動かすのはこっちの方が分かりやすい。 >>368 仕事でってことだがMFCで書かれた既存のプログラムの更新とかなのかな? そうで無いなら今更MFCなんか使わないことを強く薦める。 MFC必須と言う事ならお奨めの本は、 「MFCによるWindowsプログラミング」ISBN 475611749X なんだが、古本でもAmazonで\36,000とかしてる。 https://www.amazon.co.jp/s?k=475611749X 東京在住なら国会図書館にあるみたい https://iss.ndl.go.jp/books/R100000002-I000002930291-00 自分は、これの前の版の 「MFCによるWindows95プログラミング 」ISBN 4756119158 を今でも使ってる。 だめだー格闘したけどビルドすらできない どうもvc++6.0以前のやつはvc2005以降とだいぶ違う?変換でエラー出るどころか文法もエラー出まくりでどうしようもならん。古い開発環境なんて無いし 無視したら、当時の脆弱性を認めることにはなるけどな。 あと forのカッコの中で宣言したループ変数のスコープとかも、6の時代とは違ったと思う。 判らないなら VC6 使うべき 上位互換でも VC6 モードにするべき MSDN なら XP も VS6 も入手してるはず えぇこんなサイトあるのと思ってググったけど著作権的にグレイゾーンというかブラックでは 要するにmicrosoftが黙認というか放置してるだけというか 権利を放棄してないのは確かだから使うならこっそりやりなさいよくらいのレベルなのかね いずれにせよグレーなのは間違いない。仕事じゃ使えないね 仕事に使うって発想はなかったw MSDNのCDをiso化して保存してるからな 仕事につかえないっ(キリっ)て話なら 純正のVC6でももう使うなよωって思うωωω 仕事で使うなら再現可能性は大切だからな 従業員が違法行為をしていたら、懲戒免職で済めば良い方で 損害賠償請求されたっておかしくはない MFC保守なんていう面白そうな案件を当時を知らない若者にやらせるとかどうかしてる。 隔離VMで昔を懐かしむなんて楽しみ方はしてるよ 今のハードウエアなら神速かと思いきや期待ほどではない mfcのコードってどれもこれもハンガリアンな印象なんだけど新し目のmfcコードだとその悪習から脱却されてたりする? 前世紀から連綿と受け継がれてきたようなのしかまだ見たことがないんだけど。いやそもそも新し目のmfcなんて存在するのかという問題もあるが べつにハンガリアンが嫌なら自分のコードでは使わなきゃいいだけ。 使うライブラリのネーミングルールが気に入らないとか言うのは相当偏屈な奴だろう。 型が分からなくても平気な人はプログラマに向いてない。 UNIX勢のGUIが不安定だった頃、 MFCアプリが高機能てんこ盛りで安定してたのはハゲリアンのおかげである。 APIのリファレンスの記述用としては秀逸だと思うけどなあ MFC製アプリはMSに数兆円の利益をもたらした。 ハゲリンは100害あっても兆利あった。 > 安定してたのはハゲリアンのおかげ 関係ないと思うが 理由も書かずに否定した気になってるという謎の万能感の持ち主w >>404 変数名と高機能てんこ盛り安定は関係ない そんなこともわからんのかバカ 90年代に書かれたのを最新のvisual studioで動くようにしてという仕事が降ってきて絶望している 90年台のVCだとfor文の初期化式のスコープでまず引っかかりそう 自分の作ったプログラム(MFC使用)でVC++4.0からVC++2008の移行を行ったけど、 (文法的に)エラー・ワーニングが出るところを機械的に修正していくだけで、プログラ ムのアルゴリズムや構造を変えなければならないようなところは無かったから、 それほど手間はかからなかったよ。 >>409 はマジ 信じられない工数がかかるなら きちんと比例する費用をもらうことが 今後の仕事の単価を守ることでもある >>414 うちでメインに使ってるのはまだVC2015だけど、2008ならもう それ以降の最新VCに上げたからと言ってCソースの修正が 必要になる事ってほとんど無いやろ IE用の古いCHtmlViewで表示されているページを拡大縮小することは可能でしょうか? MFCIEというサンプルもビルドしてみたのですが、CTRL+ + などは効かないようです。 プログラムからコントロールできるのでしょうか? MFCでAppWizardでひな形を作って色々試してるのですが、ツールバーのアイコンって どうすればいいのでしょうか?? visual studio imaging libraryのアイコンを試しにツールバーのボタンに追加(コピー&ペースト)しようとしても背景がおかしくなります。 imaging libraryのアイコンが32bppのBGRAで、ツールバーのアイコンが24bpp。 >>419 ツールバーのエディタではビットマップのままで作っておいて、 それと同じ並びのPNG画像を用意して、ソースコードで指定する。 なんか、ツールバーエディタが32bppに対応してないっぽいですね... >>420 ありがとうございます。試してみます。 ツールバーエディタ使えないの死ねるな... エディタ上でボタンの位置D&Dでかえれば、ビットマップも変わってくれるに これを手動でしょうやるのか.. みんなさんどんなツール使ってるんでしょうか >>422 個人的には ToolBar のクラスを独自に改造したり、似たものを独自に作ったりしてる。 >>423 自分もちょっとしたツール作って対応してみます 32bpp?のイメージリストをpngか32bppで書き出せるツールあたりを作ればいいのか? もちろんイメージリストにイメージの追加とD&Dで移動 ありがとうございます >>424 今のツールバーは、グレー化の状態とか、メニュー用の小サイズとか、 一つのツールバーに対して複数の画像を持たせられるので、 そのへんも想定した方がよいかと >>424 ちなみに、MFCが買い取ったBCGのライブラリには、 32bitのPNGやSVGに対応したツールバーエディタも入ってるみたい https://www.bcgsoft.com/doc/ToolbarEditor.htm >>424 昔から、MFCのToolBarには色々な問題点があったので、 仕組みの簡単さから言えばCToolBarクラス自体を自分で作り直したほうが 便利。 とりあえず、上手くいくかわかりませんが Delphi/C++Builderの方に32bppのImageListをD&Dで移動など編集できる機能があるので、 そこでビットマップ管理して、後はPNGもしくは32bppのBMPで書き出すコードを 追加して、それをMFCの方で利用 >>427 そうなんですか。でも、その場合、ツールバーの移動とかカスタマイズ機能を付けるとなると 大変? >>428 そういえば、移動というか、Docking機能の実装は結構難しかったな。 MFCのバージョンによって容易さは違ってくると思う。 恐らく、新しいMFCはだいぶ楽になってる気がする。 >>429 それなんですね。ツールバーやウィンドウのドッキング機能がほしかったので、とりあえず、MFCを使ってる次第です。 QtやDelphi/C++Builderの方にもウィンドウのドッキング機能があるっぽいですが、MFCが一番良さそうだったので 後、今どきHigh DPIは必須なので、ちゃんとMFCのドッキングがHigh DPIで動くのか...AppWizardで造った雛型はデフォルトで、アプリのレイアウトの復元を行ってくれますが そこら辺を考慮して最終的にMFCにするかQtにするかはたまたDelphi/C++Builderにするか ちょっと聞きたいんだけどMFCを使用してCUIアプリを書くことってある? メインのプログラムがMFCでそれに関連するC++のCUIアプリ書いて言われて純C++で書いたらMFC使えって CUIにMFC使うって発想がまったく無かったんだけどありえなくもないんかな >>433 コンソールでMFC使うのはアホだろ。メリットが一つでもあるのか? >>433 自分はCUIアプリでもMFC使う事が多いね。 MFCはGUI関連以外でも汎用的な処理がクラス化されていて便利な物が多数あるからね。 CUIアプリでも良く使うのはCStringとかCxxArrayとかCFileFindとかかなあ。 これらの大部分はATLでも実現できるけど、普段GUIアプリをMFCで作ってるからCUIでも ATLよりMFCを好んで使ってる。 >>433 あと、企画・開発から保守まで自分一人で行う物なら何をどう使っても良いけど、大き なアプリの一部の開発なら、使うライブラリや記述・処理の作法なんかを他の人が作る 部分に合わせておくことは非常に重要。 >>433 CString受け以外では使わないなあ APIのラッピングは結局APIのリファレンスも読まないとだめだし MFCは糞 もちろんGTKは糞だが GTKよりも糞 C++Nativeの今風なGUIライブラリ作って欲しいわ そこ得意分野のはずなのにな もうC++には興味ないのか .netでc#でって感じで、俺らの欲しいものじゃない奴を作っては消えていく 未だにMFCの方が安泰な気がするんだけどなあ TuneBrowserとか見ると、MFCも捨てたもんじゃないと思うけどな C++/CLIをもっと延命してくれればよかったんだがなぁ >>442 C#側の都合を押し付けられる予感しかしない C#やクロスプラットフォームとは縁を切って欲しい fluent designが問題なんだよ。タッチフレンドリなアプリ作るならfluent designでもいいが、もっとマウス入力前提のデスクトップアプリ作る場合なfluentだとスペースが多すぎてダサくなる もっと、Visual Studio IDEみたいな情報密度のアプリにFluent Design(WinUI)が対応してくれれば Tunebrowser見てみたけど、おしゃれやな こういうの簡単に..っていうかMFCのビジュアルテーマもっと用意しろよって... >>446 その路線windows8で失敗してるのにまた蒸し返すのかよって思ったな 本当は実用性とデザイン性は相反することが多いんだよ。 なぜかというと今まで見たことも無いものが良いデザインに見えるからだ。 人間は見たことも無いことに驚く。そして驚きこそが良いデザイン本質だからだ。 便利だったり識別し易いものは既に多くある。それが実用性が高いものだ。 ところがよくあるものは陳腐に見えるため、良いデザインに見えない。 だからSF映画の世界では実用性のないUIを持ったコンソールパネルが宇宙船や ロボットの中に描かれている。 見たことが無いのでかっこよく見えるのだ。 Windowのデザインも、4隅を丸くしたりするとかっこよく見えるが、 面積が無駄になるので実用性には乏しい。 だから、Windowの中の境界線を見えなくするものが流行っているが、めったに採用されてこなかった ために驚きがあるため一部の人にはデザイン性が高く見える。 ところが、採用されてこなかったのは実用性が無いからであって、結局使いにくい。 IT掲示板群 ttp://x0000.net/forum.aspx?id=15 学術の巨大掲示板群 - アルファ・ラボ ttp://x0000.net 数学 物理学 化学 生物学 天文学 地理地学 IT 電子 工学 言語学 国語 方言 など simulationライブラリで純粋な関数式プログラミングをする ttp://x0000.net/topic.aspx?id=3631-0 UIライブラリ (C#, 2D) を作ったよ ttp://x0000.net/topic.aspx?id=3688-0 連続と離散を統一した! ttp://x0000.net/topic.aspx?id=3709-0 4Dエンジン(画像有り) ttp://x0000.net/topic.aspx?id=3677-0 matrixのライブラリ ttp://x0000.net/topic.aspx?id=3711-0 ある強力なFor関数 ttp://x0000.net/topic.aspx?id=3630-0 SQLライブラリ ttp://x0000.net/topic.aspx?id=3675-0 PS malloc / free を実装してみた (C#) ttp://up.x0000.net/files/TMallocTest.zip MFCのせいでC++/CLIのGUIが衰退したのは本当ですか? C++/CLIのGUIはもう終わりなのですか? MFCはC++98すら未制定の時代に作られたライブラリだけど C++17前提で作り直すとどんな感じになるかな たとえば RUNTIME_CLASS(hogehoge) ↓ typeid(hogehoge) みたいに >>453 どっちかというと逆だと思う。C++/CLIがこけたせいでMFCが延命した。 >>455 なるほど。C++/CLIだと、C++言語の高速性が活かせなかったのかな? 最近MSが出したTerminalのソースみたらゴリゴリのモダンなC++の中でWindows API使ってて震えたね 何とかしてくれよ本当 >>457 なんで?、Win32 API 使っても別に問題ないじゃない。 >>459 と言ってもC++のクラスライブラリがこれしかない現実 APIの極薄ラッパーなところが有り難いんだよ 余計なことを押しつけずAPIを使いやすくすることに徹してくれていて MFCもFeature Packの後 更にBCGSoft買収して全部無料にするとか、 WPFもどっかのライブラリ買収して無料にするとかカッコいいアプリ作れるようにすれば開発者の意欲も沸くのにな xamarinとか糞は買収するくせに 使い安くなってるか? 余計な手間が増えてるだけだろ? >>458 GUIを作るにはあまりに低レベルなAPIしかなくて 今の時代にそこから書くのは辛すぎる もう一段上の抽象化レイヤーなりMFCみたいなクラスライブラリが欲しいところ Win32APIに対してのMFCは一段上に行ってない 抽象レイヤですらない 「東京版CDC」設立準備と小池都知事 https://this.kiji.is/652740458292626529 2020/7/6 14:16 (JST) MFCの勉強する前にWindows SDKの勉強した方がいいってまじ? 物理を学ぶ前に数学を学んだ方がいい、という程度には。 MFCとAPIは同時に憶えられるよ MFCはAPIの極薄ラッパーだかんね MFC独自の概念、シリアル化とかドキュメントビューとか APIあんまり関係ないのもあるけどね Win32 APIという超レガシーを今更勉強する気が起きるかどうか 昔はこれしかなかったからみんな頑張って勉強したけど 昔からあるというだけ それで済む用事をわざわざ難しくする必要はない 勉強って言ったって、一々全部覚える必要はない 昔はgoogleとかないから名前覚えないと探せない問題はあったけど 今はよく使うものはなんとなく名前を覚えてしまう程度で充分だ どうせエラーが発生したら調べることになるんだし 頑張るような要素はないと思うが >>469 むしろMFCの勉強はしない方が良い というかMFCの勉強はしてはいけない MFCやWin32APIの勉強なんてさほど必要ないよ。 英単語の暗記のようなものだから。 電話帳を勉強する必要ないのと同じ。 公式ドキュメントに書かれていない問題点や誤解しやすい点など、 先人の労苦をネットで調べるのは意味がある。 MFCに関わることで起きる問題は MFCと関わらなければ回避可能 女に関わることで起きる問題は 女と関わらなければ回避可能 だろ? おまえの人生は 本当にそう思ってるやつがこんなとこに来るのは荒らし目的 うちの会社新人に研修でMFCやらせるんだけど大丈夫かな……多分創業当初から同じ課題渡してるんじゃないかな…… 本番で使ってたらおぞましいが 研修なら反面教師に最適 C++使いがMFC使いたくないのは理解できるが、JavaとかPythonのようなモダン言語使ってる層ならわかりやすくて良いんじゃないの。 >>485 みたいなのはMFCすら使いこなせなかった人だし、 >>484 の会社は潰れてないんだから問題ないのでは? ほかのC++のGUIライブラリ、例えばATL/WTLが MFCに比べてそこまで使い勝手いいわけでもないけどな 些細なレベルで文句言ってただけ OWL>>>越えられない壁>>>MFC だったよな どうしてこうなった これからはWinUI 3が標準になっていきそうだな C++/CLIとC++/MFCのどちらがいいのだろうか? C++/CLIはあまりメンテナンスされていないと聞くが その2つは比べるようなものでもないが?C++/CLIはFormsとMFCどちらも使える。 ただしC++/CLIでGUIアプリケーション作るのはもう推奨されなくなった。 >>493 Σ( ̄ロ ̄lll) ガビーン C++/CLIでMFCも使えるのですか!? >ただしC++/CLIでGUIアプリケーション作るのはもう推奨されなくなった。 これってMSが推奨していないのですか? 今からMFCを勉強する方法ってありますか? 古い情報で学習しようとしても今と違いすぎていて無理ゲー http://www.kumei.ne.jp/c_lang/indexmfc.html 無駄 tcl/tk とか Qt とか wxWidgets やれ >>495 そんなに違うか? 俺、win95時代にmsuセミナーで憶えたけど 大筋は変わってないぞ >>496 そ・・・そんな・・・ C++で書いたコマンドラインツールをGUIにしたいので、MFCがいいと思ったんですけど tcl/tkはC++で使えないみたいなので、Qt とか wxWidgets がいいのですか? しかし、長生きするのはMFCってことはないでしょうか >>497 最初のサンプルからしてVS2019で全然ビルドできないのですけど >>497 つーかWindows95の時代って何年前ですか? 今の話をしているのですよ? >tcl/tkはC++で使えないみたい 誰がそんな事言ったの? 使えるよ MFC は無駄 >>501 そうだとしても何を使えばいいのかわからないよ このサイトの「Win32 Application」でMFCを使うという例はいくらなんでも古すぎるのでは。 Unicodeも一切想定されていないから、標準設定ではコンパイルエラーになりそうだし。 >>503 他に良いMFCの教材があればいいのですが >>505 まず、VS2019で、MFCのHello World的なものはビルドできる。 そっかっら後は、MSDN の英語版を読むといい。 日本語版は駄目。 >>506 そうだとすると学習コストが尋常じゃなくなりそうですね Windows SDKで作るのは大変だし、MFCは学習が辛いし、どうしたものか >>503 MFCがWin32のラッパなのだから、別に不適切ではない。 afxwin.h などのヘッダファイルが、新しいMFCでは名称変更になっているが。 >>507 Windowsプログラムとはそういうもの。 結構大変なんだぞ。 MFC は、unmanaged だろ。 まだ、存在するのか VC++ か何かで、managed(.NET)から、unmanaged(.NET以外)を呼び出す機構があったような。 .NETのunmanaged拡張(C++/CLI) C++/CLI は、非推奨か 最近のWindows では、C/C++ を、どうやってプログラミングするのだろう? >>511 コマンドラインならいくらでもC++を使える。 C++のGUIは選択肢が少なくなっている。 MFCも将来性なさそうだからWindows SDKしか残らなくなるかもね。 あるいは上の方に書かれているサードパーティのGUIを使うか。 Windowsの主要言語はC#やVBになってしまった。 >>510 それ用のDLLが用意されていて、MFCのアプリケーションがほんの少しの変更で C++/CLIでビルドできたよ。 C++/CLI は非推奨でも、本物の C++ は非推奨な訳ではないだろう。 >>511 C++は普通にMFCをVS2019と共に使ってプログラミングすればよい。 .NET のアプリで定番のものって何があるかな よく使うアプリはネイティブなのばかり MFC 使ってるのか Win32 直叩きかは知らんけど WindowsでC++アプリの定番はWin32ではなくMFC。 日本ではMFCが普及すべき時期に無料のVS Expressが出てきて、 それがWin32のみでMFCには対応してなかった状態で、後から 無料のVS Communityが出てきて、今度は、C++よりC#が 前面に押し出されてしまったため、C++使いがMFCでプログラム する機会を逃してしまっただけ。 なお、C++の場合、VSの力が最大に生かせるのはMFCであって、Win32ではない。 メニューを処理する関数の作成なども、MFCだとVSによって自動化されているが、 Win32だとされていない。 ダイアログで文字列や数値を扱うDDEも、MFCではVSのサポートを得られるが、 Win32では得られない。 WM_CREATE, WM_SIZE, WM_LBUTTONDOWNなどのメッセージのハンドラ作成も、 MFCだとVSのサポートを得られるが、Win32だと得られない。 >>507 VSで、MFCのプロジェクトを新規作成すれば、HelloWorld的な アプリは出来ているのだから、>>495 で入門することも可能なはず。 今のMFCと違いがあるなら、それをGoogle検索で調べる。 たとえば、#includeされているヘッダファイルの名前が違っていると思ったら、 二つのファイル名とMFCというキーワードを半角スペースで区切って入れて、 英語モードのGoogleで検索すれば出てくる。 英語モードで検索して出てきたページを、Chromeの右クリックメニューで 出てくる日本語翻訳機能で日本語にして読み、意味が分かりにくければ、 URL欄の右隣に有るボタンから英語に戻して、辞書を引きながら読めばよい。 >>522 VS2019のウィザードを使うとかなり大層なアプリが生成されるぞ Hello world的なアプリってどうやって生成するんだ? >>524 「新しいプロジェクトの作製」で 「MFC アプリ」を選ぶと、「新しいプロジェクトを構成します」が出てくるので、右下の「作製」ボタンを押すと「MFC アプリケーション - アプリケーションの種類のオプション」 のダイアログが出てくるので、 プロジェクト形式: の場所が、デフォルトでは、「Visual Studio」になっているので 「MFC standard」に直す。こうすると、昔ながらの MFC の Hello World アプリになり、 入門サイトなどは大体これが基本になっている。デフォルトのままだと、入門には適さない。 アプリケーションの種類: は、デフォルトのままでも良いが、昔から作りたいものによって、 よく変更されていたものだから、変えて試して見るといい : ・単一のドキュメント : SDI アプリケーション ・複数のドキュメント : MDI アプリケーション (default) ・ダイアログベース : ダイアログベースアプリケーション >>525 MDIって推奨されてなかったのでは? それが今でもデフォルトなのか? 推奨されてないね、太古の昔から 俺が参加したmsuセミナーで既にそう言ってた タブのアプリだって、やってることはMDIなのでは? >>525 VS2019でそれをやってもさほど変わらないのだが? Hello worldと比べると比較にならないくらい複雑なプログラムが生成される >>528 それを言ったらこのスレッドが不要ってことになるw >>530 最初にソースを見ると複雑に見えるが、慣れてくるとそんなに複雑ではなく、 >>495 のような解説サイトは、それで理解できるはず。 >>529 MDIの悪いところを学んで改善したのがタブ >>511 最近だとC++ WinUIに持っていきたい感じはするね そのためかMSの中でC++の地位が上がってるような気がする MFCはこのまま廃れていくんじゃないか >>535 C++/WinRTのことかな? これってまだ普及していないのはなぜ? >>537 別物かよwww Windows上のC++開発環境っていくつあるんだ? UWPはオワコンだろうがWinRT自体は普通のデスクトップアプリでも使えるはずだしな。 >>540 Win/UIが登場したらWin/RTがオワコンにならないの? よーわからん 今後はWinUI一択だろうね 流行るかどうか次第だと思うけど C++をまともにサポートしてるのは大きい fzf をコマンドプロンプトにネイティブ対応したほうがはるかに幸せになれる。 >541 完全にUWPの時代になるよ .NET Frameworkが始まった時ってC++がおまけの扱いされてけど、 今回はWindows上にC++のアプリ作ってもらおうとしてる感じがする 乗り遅れるなよ 方向転換したことに気付かないままMFCを使い続ける人も多いだろう 情報を拡散する人がいないのかな >>545 その方向転換がされたらMFCとWinRTと別の環境ができるのかな? トグルボタンよりもチェックボックス、という猛者はいないのか WindowsのC++開発環境 Win32 : 情報はそこそこあるけど扱いが面倒 MFC : 今から勉強すると時間をドブに捨てる可能性あり C++/CLI : 死亡 C++/CX : 死亡 WRL : 死亡 C++/WinRT : MSはこれを推奨しているが、UWPの開発環境なので人気なし C++ で、GUI は作れない DLL しか作れない いくらMFCの設計がいまいちだからといってもさすがに素のwin32でGUIやる方がよっぽど時間の無駄だわ。 けっきょくC++だと消去法でMFCになるんだよな。 >>551 しかし、今からMFCを勉強するのも現実的なのか? 相当な時間がかかるのではないか? 今ならより軽量なWTLって手もある。MFCはC++コンパイラのtemplate対応が不十分だった時代の遺産だから。 >>552 だから消去法だよ。いまさらwin32でやろうとする方がもっと非現実的。 まあ、知っておいて損は無いけどな。 じゃないと議論が出来ないからな。 Win32は古典のようなもんだからWindowsアプリ開発初心者なら少しはやっておかないと。 ほんの少しでいい。電話帳を暗記する必要ないのと同じだから。公衆電話のかけ方を学ぶ感じ。 >>552 Win32 の WM_KEYDOWN が、MFC の OnKeyDown Win32 の WM_CHAR が、MFC の OnChar Win32 の WM_SIZE が、MFC の OnSize Win32 の WM_PAINT が、MFC の OnPaint() や OnDraw() Win32 の WM_CREATE が、MFC の OnCreate() Win32 の WM_DESTROY が、MFC の OnDestroy() に対応しているので、Win32 の知識は、MFCとほぼ対応している。 その上で、VSのIDEの機能がMFCの方が10倍有って、開発効率は格段に上がる。 >>557 他にも、 WM_LBUTTONDOWN が、OnLButtonDown() WM_MOUSEMOVE が、OnMouseMove() WM_NCPAINT が、OnNcPaint() または、OnNcDraw() に対応している。 WM_COMMANDは、OnCommand()も有ったかも知れないが、 メッセージマップと言う仕組みで、IDEと組み合わせてもっと効率よく ハンドラを作製できるようになっている。 >>549 Win32より、MFCの方が後発で、C++でWindowsアプリを作るには、後者の 方が定番で、開発効率も高い。 MFCは未だに改良が進んでいる。 たとえば、ドッキング、自動レイアウト関連、リボンなどは、Win32にはなく、 MFC独自。 また、Windowsアプリらしいアプリは、Win32より、MFCの機能を使っている。 商用やプロが作るnativeアプリは、ほとんどがWin32ではなくMFC製。 >>553 軽量かもしれんがWTLも全然お手軽ではない 何十年も期間はあったのにMFCの代わりにATL/WTL使うようにはなってない ってかこんな書き込みあるスレじゃなかったけど なにが紛れ込んだんやろか? ATL/WTLのスレは2年ほど書き込みないがあっちが正常やで >>559 自分の場合、MFCを始めようとしても何から始めればいいのか分からないし、もはやMFCをちゃんと解説した本もない。勉強する時間もない。 Win32の方がある意味わかりやすい。オブジェクト指向ではないので、クラス構成を把握する必要もない。小規模な開発なら何とかなると思う。 今からだと WTL/ATL の情報はあまり拾えないのでは wxWidgets のようなクロスプラットフォーム狙うか、 いっそ C++ から離れるか >>561 最後に書き込んだの私だった(笑) 324 自分:デフォルトの名無しさん[] 投稿日:2018/12/02(日) 09:05:18.31 ID:pHBSzoap 最近、頻繁にWTL10のmasterブランチが更新されているね。 https://sourceforge.net/p/wtl/git/ci/master/tree/ >>562 MFCの場合、まず、IDEを使って、MFCプロジェクトを作るところから始める。 後は、Menuリソースに1つメニュー項目を追加して、それに対するハンドラを作成し、 中でAfxMessageBox()などを使って、ハンドラが呼び出されるのを確認する。 画面は、OnDrawの中でpDC->MoveTo(), pDC->LineTo()で直線を描いてみる。 それが出来たら、さっきのハンドラの中で、Invalidate()を呼び出すテスト。 Invalidate()を呼び出すと、メッセージがメッセージキューにたまりまくっている 場合以外は、比較的即座にOnDraw()が呼び出される。 それで色々いじって試してみるといい。 そもそも、もうWindows専用アプリを新しく作る事自体、ほとんど需要ないだろ・・ だから、メインとしてAndroid/iOS向けに開発したクロスプラットフォーム向けのアプリで Windows向けもビルドできるというおこぼれをもらうしかない。 >>554 いや、そんなでもないよ Win32の手順や概念をクラス化なんて秒殺でできるからな 普通にCで書いてる感覚でクラス化したほうがいいところがあればひょいと んで、毎度おなじみのコードが出てきたら再使用できるように括り出しておく それだけのことで非現実的というほど大変なことではない Windowsアプリの需要がないって話はエンドユーザー向けパッケージソフト市場しか見てないんじゃないかな。 ごめん。そうだな。一般消費者向けの事しか考えてなかった。で、それ以外向けのWindowsアプリの需要はどれくらいあるのか知らんが。 CADツールとかオープンソースのもいれたら いまだに新しいものが出てきてるからね Webだとパフォーマンス出ない分野のツールはまだまだ有効 本板のWin32API質問箱スレがいまも活発であることがすべてを物語っているね。 MFC とか、Jeffrey Richter とか、何十年前の話 今でも、医療用・産業用ソフトなどは、Windows 限定かも >>573 年寄りのマウント合戦で盛り上がっているようにしか見えないが。 一太郎やPowerDirectorは、今でもMFCアプリだな 昔から大して変わっていないとも言えるが MSがOfficeやVisioみたいなもので、大半の需要を独り占めしてしまっているので desktopアプリを食っていくために作ることが難しくなった。 MSが手を出してない分野では、ぎりぎりなんとかなっていることもある。 でも2DグラフィックはAdobe、3DはAutoDeskなんかが強い。 最近は、3Dは、OSSのBlenderもあるから生半可には参入できないが。 でも、たとえ、有名ソフトと「かぶっていても」、欲しくなるソフトはある。 でも、有名ソフトが無料化してる場合は辛い。 本等は、完全なダンピングだから、法的な取締りの対象にならなければならないのだが。 Visual Studio Communityはダンピングだから、罰するべきだ。 そんなこといったらAndroid StudioやEclipseもダンピングにならないか? Win32は非効率というが、自分には一番理解しやすかった。 C言語なので、Windowsの知識がなくても地道に積み上げながら理解できる。 他の開発環境だとC++クラスライブラリなので、クラスの役割の全体像を把握するまで何もできない。しかもWindowsの前提知識が必要。 >>581 実は、MFCは、Win32の知識がないと深く理解できないので、 MFCを理解するのは、意外と難しい。 しかし、IDE(VS)の支援を豊富に受けられるのはWin32ではなくMFC。 1. メニューリソースをVisual的に作った後、MFCだとハンドラ関数を自動的に作れる。 BEGIN_MESSGE_MAP()〜END_MESSAGE_MAP()の中に、 ON_COMMAND()やON_UPDATE_CMD_UI()みたいなものを自動的に入れてくれて、 対応する関数の雛形を、*.cppと*.hの両方に生成してくれる。 Win32でこれに相当する作業を手作業でするのはとても効率が悪い。 2. OnSize, OnLButtonDown, OnMouseMove, OnChar, OnKeyDown などのハンドラも、ClassWizardなどから効率よく自動生成できる。 これも、Win32でこれに相当する作業を手作業でするのはとても効率が悪い。 >>582 Win32+MFCを習得するのに何年かかるんだ? 俺はこんなだった win32: Petzoldの本で1ヶ月 mfc: msuセミナーで2週 win32は少しでもかじってれば、あやふやでもmfcは何とかなる Win32API Cの理解が先に出来てたから イベントドリブンとかメッセージループとか 典型的な描きかただけなら1日で充分理解出来た 全体理解なんて今でもムリポ MFCも秒 C++とWin32APIを理解してたらそもそも勉強の必要すら無い >>583 何を持って習得と言うかわからないが、 1. HelloWorldは、IDEが作ってくれる。 2. Menu項目の作り方と、ハンドラの作り方は、ネットで検索すると 解説されたものがいくつかあるはず。 3. OnDraw()の中の書き方は、Win32のGDIとCとC++の書き方程度の違い で、基本的に変わらない。 4. WM_LBUTTONDOWNとOnLButtonDown()などは一対一に対応しているだけで、 Win32と同じ。 5. Dialogのデータ交換DDEは、チュートリアルを読まないと難しい。 解説サイトを読むのは人によるが、速い人は20分とかでも読めるのではないか。 >>585 MFCは、習得すれば効率は良いが、IDEとの連携を習得するのに時間が掛かる。 IDEは、かなり使い込んでも、知らない機能は多い。 >>586 今のVSはMFCのHello worldを作ってくれない 最新情報じゃないと意味ないよ >>585 >C++とWin32APIを理解してたらそもそも勉強の必要すら無い 俺はVS2019が新規作成で生成した複雑なプログラム(VS2019はHello worldを生成しない。いきなり複雑なものを生成する)を見て途方にくれたがなー 何から始めればいいのか全く理解できない >>589 MFCプロジェクトを作る際、「Visual Studio」となっているところを、 「MFC Standard」に変えれば MFC の Hello Worldが出来るぞ。 >>591 VS2019でその通りにやってみたけどできなかったよ ID:TREPbbxK の脳内にあるHello Worldアプリが何を指すのか次第な気がする mfcは単純にwin32の極薄ラッパーかというとそうでもない ドキュメントビューとかシリアル化、DDX/DDVなんてのは独自の概念だ MFCを新たに勉強するのが無理とか言っているような人は他のどの開発環境・ 言語でも使えるようになるのは無理だろうし、プログラミングに限らず何をやっても ダメな人間だと思う。 今さら公衆電話の使い方なんて覚える必要ないでしょ(キリッ >>593 少なくともHello Worldは表示できなかった 非常に複雑なものが生成された >>595 今まで組み込みのプログラミング(電子回路と測定器の知識必須)をしてきたけど、C/C++でずっと仕事をしてきたし、仕事もちゃんとできているよ。 どうしてMFCができないと仕事ができないの? Windowsだけがプログラミングなの? ただ急にWindowsでプログラミングをしないといけなくなって困っているだけだが? 組み込みのプログラミングと違ってフレームワークが全てを支配するというのが苦手なので仕方がない。 >>597 プログラマがすべてを把握する責任を負わなくていい。それがフレームワークの恩恵。 WindowsだろうがmacOSだろうがスマホだろうがこれは同じ。 >>592 できた結果を書いている。 Hello Worldというのは、なにも、Hello Worldと表示するプログラムの事を 意味しているわけではなく、最初に学習し易いサンプルの事だぞ。 >>592 できた結果を書いている。 Hello Worldというのは、なにも、Hello Worldと表示するプログラムの事を 意味しているわけではなく、最初に学習し易いサンプルの事だぞ。 >>597 ちゃんと「Standard MFC」に変えた場合、 Hello World という文字は表示されないが、MFCにとっては、それ以上減らせない 程度にシンプルなサンプルが作製される。 オイラもアセンブラでプログラムしていた口だから、人が勝手に用意した 型枠を使うのは余り好きではなかったし、気持ちは分かる。 しかし、MFCでは、原則的にはあれ以上は減らせない。 開発環境が勝手に作った数々のファイルに埋もれてしまう体験は、なにもMFCに限った話じゃないだろう。 Hello Worldの問題点は、出力しか試せないところだね。 ユーザーからの入力がプログラムに反映されるところまで試さないと プログラマとしてはひと安心できないはず。 そもそもGUIアプリでHello,worldって何?w SDI形式で、ドキュメント・ビューの仕組みは使わない方が、よりわかりやすいとは思うけどな C#でアプリを作ろうものなら、意味不明なXMLファイルが一緒に生成される気持ち悪さに耐えなければならない。 気持ち悪いのはMFCだけじゃないってこと。こういうもんだと慣れるしかない。 C# も普通のテキストエディタと csc だけ使えば hoge.cs と hoge.exe しか造られないからすっきり CrystalDiskMark はMFC採用で独自コントローラー(Project Priscilla)まで実装しとる MFCバリバリ現役じゃん ライブラリの新旧だけで優劣だと思っちまう 浅はかなやつってライブラリで仕事してる人の 苦労が何も解ってないんだろうな MFCの衰退を見守るスレ MFCの最期を暖かく見送るスレ MFC利用者をdisるスレ 必死に現役アピールするからおもちゃにされてしまっているw >>608 現役なのは確かだけどオワコンでもあるんだよね 良くない側面も持っているが、C++でWindowsプログラムをしようと思ったら、MFCが一番良い選択肢だと思う。 仮にMFCを使わないとなると、VisualStudio を使うとなれば、Win32とC#しか選択肢がなくなる。 それは困る。 もっと情報収集しよ? こんなんだからMFCじゃなくてMF爺って呼ばれてるんだぞ >>616 でも実例は挙げないで、訊かれても「自分で調べろ」一点張り >>621 Visual Studioが使えなくなる。 Visual Studio で造れるもの Tcl/Tk wxWidgets Qt その他 「かんたんVisual C++ 改定2版」という本を見つけたのだが、ダイアログベースのアプリの説明がほとんどでSDIとMDIの説明はちょっとだけ。 MFC Tutorial https://www.tutorialspoint.com/mfc/index.htm 上の海外のページでもダイアログベースの説明なんだよなあ。 SDIやMDIを好きに変更できるようにならないと業務に使えないのだが。 もしかしたらCMultiDocTemplateクラスのせいで自由にレイアウト変更できないの? 結論的に言えば、以下の本を買えば、昔ながらのMFCのSDI/MDIプログラムは学べるはず。 他にも、4種類くらいの本があり、ダイアログベースのプログラミングなどに詳しい本もあるので そっちもあわせて見れば、かなりの事が分かるはず。 かんたん Visual C++ [改訂2版] (プログラミングの教科書) (日本語) 単行本(ソフトカバー) Visual C++の基本の文法を完全網羅。イラスト図解でやさしく解説したMFCの教科書です 2017年10月13日発売, 堀義博 著, A5判/560ページ, 定価(本体2,980円+税) 技術評論社のページに以下の様な目次が出ている : https://gihyo.jp/book/2017/978-4-7741-9259-8#toc 11章 SDI/MDIアプリケーション 11-01 SDI/MDIアプリケーション 11-02 MDIプロジェクトを作成する 11-03 MDIで画像ファイル表示アプリケーションを作成する もあるし、 10-01 ダイアログデータエクスチェンジ 10-02 メッセージの処理 10-03 ダイアログデータバリデーション もあり、見てみたら、MFCの基本的な使い方はかなりちゃんと書いてあるようだ。 5章 コードウィザード 5-01 クラスウィザード 5-02 メンバー関数の追加 5-03 メンバー変数の追加 6章 デバッグ 7章 MFCの基本的なクラス 8章 コモンコントロール 9章 デバイスコンテキスト >>628 この本は、ちゃんと、1つの章を割いているので、別の本のことかと思った。 そもそも、MFCのSDI/MDIは、そんなに高機能ではないので、質問者は勘違いしている かも知れない。 MFCは、ダイアログベースにすると、割とIDEの機能が強く働いて、 C#のWinFormsと似たようなポトペタ的なプログラミングに近くなるが、 SDI/MDIは、メニュー以外には余り支援が無い。 SD/MDIでも、ダイアログを使えば、ポトペタ的になる。 というか、「Win32 Control」と呼ばれているものは、もともと、 ダイアログに入れた場合にちょうどよく機能するように設計されている。 だから、「ダイアログリソース」なるものがあるが、それ以外では、 独自に全て座標やサイズを指定して出すしかない。 >>629 普通、どのアプリを見ても分かるが、メインメニューとツールバーがあり、 一行のテキストフィールド(EditBox)や、ボタン、チェックボックス、 コンボボックスなどは、全てダイアログの中に収められていることが多い。 だから、SDI/MDIアプリも、IDEの支援は、ダイアログ以外は、 メニューとツールバーが中心で、後は関数の作製・削除、検索、置換、 デバッグなどに限定される。 というわけで、SDI/MDIプログラムを学ぶと言っても、ポトペタ的な ものは、ダイアログの部分を学べばよいだけ。 そしてそれに関係するのが、ダイアログデータエクスチェンジ(DDE)。 >>629-630 625です。 その本を立ち読みしたのですが、SDI/MDIの部分は本当にペラペラです。 ダイアログベースだとメニューがないので、あれは実用にならないのではないでしょうか? 自分的にはSDI/MDIが実用アプリの基礎であれを改造しないと実用にならないと思っていたのですが、違うのですか? 個人的にはメニューがあって、ウィンドウにツリービューが表示されているようなものを作りたいのですけど、調べてもちっとも分からないんですよね。 最悪、Win32で作るしかないとは思っていますが。 >>631 >個人的にはメニューがあって、ウィンドウにツリービューが表示されているようなものを作りたいのですけど、調べてもちっとも分からないんですよね。 VS2019だと、MFC-Projectを作成する際に「Visual Studio」を選ぶと最初から サンプルとして利用できるプロジェクトが作られる。 Windowsプログラムでは、作り方は、サンプルを参考にして、そこをヒントに 分からない部分をネットで検索して調べるのが基本。 全くサンプルが無いと作るのはほとんど不可能な場合があり、 「SDK」と呼ばれているものの意味や目的の50%は、サンプル集であると言っても 過言ではない。 >>631 >ダイアログベースだとメニューがないので、あれは実用にならないのではないでしょうか? >自分的にはSDI/MDIが実用アプリの基礎であれを改造しないと実用にならないと思っていたのですが、違うのですか? ダイアログベースアプリも結構見かけて、C#のWinFormsアプリとMFCのダイアログアプリ は、言語が違うだけで理念はほぼ同じ。 しかし、本格的な「アプリ」を作りたければ、SDI/MDIプロジェクトをベースに作るのが基本。 「ダイアログベース」にしなくても、ダイアログベースアプリの作り方で学んだ知識は、 SDI/MDIアプリでも生かせる。 SDI/MDIアプリの中で、ダイアログを生成することが出来、その時に、ダイアログベースアプリ と同様の作法が使えるから。 ウィンドウにツリービューを入れたい場合、CTreeViewまたは、CTreeCtrlを使う。 >>634 >ウィンドウにツリービューを入れたい場合、CTreeViewまたは、CTreeCtrlを使う。 CTreeViewは知っているけど、VSが生成したプログラムにどうやって入れるのかがわからないんですよ。 検索してもちっとも出てこない。英語で検索しても出てこない。 日本語でも英語でもダイアログベースの解説しか出てこないので、ツールボックスからツリービューをダイアログにドラッグ・ドロップしてしか出てこない。 こんなのじゃ役に立たない! >>635 VSが生成する前のアプリケーションウィザードのところで 基本クラスをCViewからCTreeViewに変更できる >>636 できましたけど、VIEW/DOCモデルを選択した時しかできないですよね。 VIEW/DOCモデルを使うと、ファイル読み込みと書き込みの対称関係が強制されるので、これも困るというか。 自分が作りたいアプリは、メモリに絶対入らない巨大なファイルを少しずつ処理してエクスポートするものなので、読込・保存の概念がない。 やはりMFCは使わない方がいいのだろうか。Win32にした方がいいかもしれない。 どうしてMFCはWin32みたいに部品を組み合わせていくように作れないのだろう。 class設計がタコだから class library と名乗るのがそもそも詐欺 ただの win32api wrapper あるいは劣化版 >>638 それは一般的な見解なのでしょうか? ここだと「Win32は手間がかかりすぎる。MFCにしないとだめ」的な書き込みも多々見かけるので混乱します。 >>637 別に、ドキュメント/ビューの仕組みを使ったら ファイル全体をメモリ上に読み込まないといけないわけではないけど、 そうなると、MFCの標準の処理をいろいろオーバーライドすることになるので、 内部の仕組みを理解する必要が出てくる。 ドキュメント/ビューが抵抗あるなら、使わずにSDIを作成して、 CChildViewの中にCTreeCtrlを載せたりすることもできるけど。 >>637 Doc,Viewモデルは、MFCを使うと必ず伴うが、個人的にはほとんど無視してプログラム している。 無視すると言うのは、Docではなく、全てViewの中にデータを入れたらいい。 イベントを受けるのを、View,Doc,Appのうちから選べるようになっているが、 原則的には全てViewで受けると便利。 MFCは、Doc,Viewモデルで設計されていると言うが、実際には余り使い勝手がよくなくて、 1つのDocに対して複数のViewなどをしたくても多分、設計上は出来ない。 なので、無視していい。 また、プロジェクトを作成後、ClassWizardで、Viewを作れるがその際、 どのViewを作るかを選べるようになっていてTreeViewも作れる。 Win32が使える人はMFCも使える。 MFCは、IDEと連携では便利なだけなので、自分で好きなようにWin32と混ぜて使っていい。 MFC自体、Win32のとても軽いラッパーに過ぎないから。 MFCはソースが付いてくるので、それを見れば、Win32との対応関係が分かる。 >>639 MFCは、Win32の軽いラッパーであることは、標準見解。 ただし、IDEとの連携がWin32より上手くできているので開発効率は上がる。 理解するのは、実はWin32より難しくなってしまっている部分もある。 しかし、イベントハンドラやメニューハンドラをどんどん追加していく場合の 効率がとても良い。 また、新しいWindowを作る際も、ClassWizardから作るとWin32で自分で 作るより速いことが多い。 メニューにチェック記号を付けたり、グレイ表示にしたい場合も、 MFCは、CCmdUI や、ON_UPDATE_COMMAND_UI()などを自動生成できるので、 効率が良い。 また、Win32だとswitch文でメニューを処理するが、MFCだと、自動生成された関数 で処理するので、大規模なアプリの場合、コードが整理される。 >>637 MFCの読み込み、保存の概念は、はっきり言って、型にはめられすぎていて MSが想定した典型的なアプリ以外だと不便だから、実は無視してもいい。 それから、DocTemplateを理解するのがまた難しいが、それはなかなか避けて 通れないこともある。 基本的には、フレームワークが想定しているファイルオープンの概念を、 如何に無視して自分流にしていけるかが、MFCを使う上での重要なポイントになる。 最初は難しいが、MFCはソースがあるので、それをおっていくと、何をやっている かが分かるので、「安全に無視する方法」を探るといい。 Docを無視してViewだけ使うってのは俺もよくやるw >>640-644 うーむ・・・ 結局、MFCが提供する仕組みを無視しないと自由にプログラムを組めないのか。 しかも安全に無視するにはMFCの仕組みを熟知しないといけないと。 そんなこと組込一筋の自分にはできそうにないなあ。 今作りたいプログラムを作ったらMFCを使うことは二度となさそうだし、やはりMFCは回避するべきだろうか・・・ 頭痛いよ >>645 というか、「Doc,Viewは かくあるべき」という設計思想が難しいし、 それを守っても余り良いこと無いので、無視してよい、ということ。 なにも、アメリカ人の考えた思想に従う必要は無いのだから。 その当時の彼らはそれが理想だと考えたかも知れないが、それも どんどん変化しているし、別の勢力はまた別の設計思想を持っているのだから。 >>645 いやいや、別に邪道なことをしているわけではない Docを使う/使わないを任意に選べるようになっているというだけ >>645 無駄に覚えることが増えるし しかもバッドノウハウで 他に何の役にも立たん 深入りする意味が無い >>646-647 >>640 に「そうなると、MFCの標準の処理をいろいろオーバーライドすることになるので、内部の仕組みを理解する必要が出てくる。」と書かれているので、難しいはずです。簡単に無視できないはず。 そもそも組み込みの技術者なので、PCのプログラミングは「ついで」的にしないといけない。 PCのプログラミングに力を入れると評価が下がってしまう。 そうなると知識量が必要なMFCは避けないといけない。やはりWin32にするべきか。 >>648 バッドノウハウ=MFCってことですか? >>649 > SDIやMDIを好きに変更できるようにならないと業務に使えないのだが。 こう言ってた人が > PCのプログラミングに力を入れると評価が下がってしまう。 > そうなると知識量が必要なMFCは避けないといけない。やはりWin32にするべきか。 こう言い出す意味がよくわからんのだが 組み込みが本業の人がMFCを何に使うんだろう 基板から送られてくるデータを可視化とか? シミュレーションや回路設計は専用ソフト使うだけだし >>650 要は力を入れないで業務で使えるGUIのプログラミングをしないといけないということです。 何も分かっていない上司に言われてやっているので、仕方がないのです。 >組み込みが本業の人がMFCを何に使うんだろう 企業秘密なので、詳細は書けない。 データの可視化の一種と言っておく。 >>651 でも、プロジェクト作成時に「Visual Studio」を選ぶと、プロジェクトを作製した直後から、TreeViewが既に出ているよね。 それをいじくれば、TreeViewは制御できる。 後はメニューに対するハンドラの書き方さえ分かれば、アプリは作れる。 個人的にはGUIは不要だと思っているのですけどね。 現場で働く派遣社員や外注などのレベル低下でCUIのツールが受け入れられなくなっているってだけでGUIのプログラミングをやるはめになった。 >>653 裏でCUIツールを起動するだけ、みたいのだとダイアログベースで充分じゃね? いちおーSDI用のスケルトンを使って 内容的にはダイアログベースなやつにするとか ログを記録したり終了時に使用状態をファイルに記憶させるのにDoc使いましたよって >>657 そこまでは知識不足で判断できません。 どちらにしても>>640 の言うように使わない機能を無視するのも簡単ではないようですが。 ダイアログベースがダメだと言うなら、>>640 の言うように、 Doc/Viewを使わないSDIで、CChildViewに処理を全部入れてしまうのが一番シンプルでは? >640の前段は「ドキュメント/ビューの仕組みを使ったら」だ ドキュメント/ビューを一切使わないのは簡単 使わないだけ ダイアログにメニューも普通に付く 「ダイアログ メニュー」でggr そんなにWin32API直でやりたいならそうすればいいけど どっちにしろ、猫でものWindows SDK編でも一通りやっといた方がいいよ MFC使うにしても、「ドキュメント/ビュー」とかのMFC独自のとこ以外は よく言われるようにWin32APIの薄いラッパだから >>659 そこまで判断する知識はまだなくて >>660 >ダイアログにメニューも普通に付く そんなことが可能なのですね。 https://www.kazetest.com/vcmemo/dialogmenu/dialogmenu.htm それならダイアログベースでも可能かもしれません。 Win32についてはそこである程度勉強したのですが、部品を組み立てるような感覚で自由にできるので、下手にMFCに手を出すよりはマシかと思ったわけです。 >>658 別に、Doc/Viewモデルを使っていても、ファイルは好き勝手に読み書きできるよ。 勝手にfopen()して、一部だけ読み込んだりとか普通にやってる。 Doc/Viewモデルを使うとしても、 CDocument::OnOpenDocument(const char *pszFilename) が呼び出されたときに、fopen()して、fread()して、どこか好きな場所に データを読み込めばよい。 CDocumentの中に読み込まなくても、グローバル変数に読み込んでも、 CViewの中に読み込んでも、好きなクラスの中に読み込んでも良い。 本当に読み込んだかどうかは、MFCのフレームワークは全く感知しないので、 好き放題出来る。 >>661 MFCも、本等は好き放題出来る。 個人的には、大改造して使ってる。 >>662 >>663 お二人のようになれればいいのですけどね >>641 単一ドキュメント複数ビューはできないわけじゃないよ。 DocTemplateを派生させる必要があるというだけ。 >>664 「MFCによるWindowsプログラミング」ISBN 475611749X 首都圏在住なら国会図書館で見てこい ttps://iss.ndl.go.jp/books/R100000002-I000002930291-00 田舎住まいなら尼(ISBNで検索)で\32,580で売ってるから上司に頼んでこれ買ってもらえ >>641 > 1つのDocに対して複数のViewなどをしたくても多分、設計上は出来ない。 CDocumentには、UpdateAllViews()という名前の関数があるように、 複数のビューを関連付けられるぞ。 >>662 わざわざDoc/Viewを選んでおいてDocクラスを放置するくらいなら、 印刷プレビューでも使わない限り、Doc/Viewを使わない形式で CMainFrameとCChildViewだけを使うほうが楽だと思うけどな。 MFC は、数十年前w Jeffrey Richter とかの時代 Win32 API を、クラスにまとめたもの。 メニューバーも作れる MFCって、まだ存在するのか WindowsでC++とVisual Studioを使ってデスクトップのプログラムするなら、 今でもMFC以外の選択肢はほぼ無いはずだが、 かんたん Visual C++[改訂2版]、堀義博、2017 この本では、.net か、managed C++ か、interop か何かを使っていた。 でも結局、このやり方も、流行らなかったのか MFC ではなかった気がする >>667 > > 1つのDocに対して複数のViewなどをしたくても多分、設計上は出来ない。 >CDocumentには、UpdateAllViews()という名前の関数があるように、 >複数のビューを関連付けられるぞ。 スマソ。記憶違いがあった。 1つのDocに対して複数のViewは、一応は関連付けられる。 しかし、それはどれも1つのCFrameWndの中に入れておかないといけなくなって しまっているため、WzEditorの「テキストの二重化」のように、 1つのテキストファイルの別の場所を複数のFrameWndの中に表示するという ようなことが、MFCでは基本的に出来ないハズ。 CTreeCtrlクラスでツリー表示の文字色を部分的に変えたいけど、Windows SDKみたいにカスタムドローしないと無理ゲー? 実際にウィンドウ上に表示している画面をBitmapに画像保存するんじゃなくて、 表示させないで、データだけを元に、連続的に画像保存するってどうやるのかな? 例えば、ボタン1つで、円の位置を連続的に動かしたデータを、 それらをわざわざ画面に表示させないで、連続的に画像に保存したいんだけど、 やり方がわからない。 >>674 CreateCompatibleDC(NULL)とCreateDIBSectionだろう。DIBビットマップオブジェクトを作成し、DCでそれを選択し、DCで描画する形になる。 >>675 ありがとう、教えてもらったキーワードをググってみます。 DialogにCMFCFontComboBoxを張り付け プロパティの「フォントを使用して描画」をTrueにすると コンボボックスの行の高さを無視して大きく描画されます。 XX明朝とXXゴシックが縦に重なって描画される感じです。 (ディスプレイ設定で拡大表示している場合のみ) 以前は普通に表示されていた気がするのですが。 良いアイデアがあればお願いします。 >>439 > C++Nativeの今風なGUIライブラリ作って欲しいわ 禿しく同意 WinUI3ってc++で書かれてるからc++ nativeじゃね?? >>679 それだけのことなのにそれをやらないマイクロソフト 昔あったCFrameWndのLoadBarStateとSaveBarStateは 何に置き換わったのでしょうか? CMF…系のツーツバーやステータスバーでは保存&復元されないようです。 MFCより先進的なGUIフレームワークを使いたいならQtとかwxWidgetsを使えってことなのかねえ? >>683 m_pszProfileNameを初期化してる? >>685 レスサンクス 明示的には初期化はしていませんが CWinApp::SetRegistryKey(... を呼んでるのでその中でm_pszAppNameがセットされているようです。 >>683 CWinAppEx::LoadStateやCWinAppEx::SaveStateが勝手に呼ばれるはずだけど 解決しました VS2005で作ったソースをVS2019に移植する際 CWinAppをCWinAppEx CToolbarをCMFCToolBar のような作業をやったんだけど CMainFrameからCFrameWnd::(Exなし)の関数を呼んでたのが原因でした お恥ずかしい。レスくれた方、ありがとうございました。 >>684 WinUI 3がネイティブ XAMLの部分はC++コードになる bamlになるだけでコードを吐いたりはしないと思うが?.xaml.cs と混同してる? BCGのほうはダイアログや埋め込みスクロールバーもダークテーマにできるんだよなぁ BCGはロシアのセンペテロブルグだったね。 ドル建てで売ってるからウクライナ侵攻の対ロ経済制裁の影響を受けて倒産とかはなさそうだな。 >>697 VisaやMasterのカード決済ができなくて、売れないのでは? ロシア国外のWeb サイトで決済して、ドルをロシアへ送金しようにも、SWIFTからの排除で銀行間 送金もできないし。 >>698 それもそうか〜。次の更新料支払いまで10ヵ月近くあるけど、どうなるのかなぁ。 BCGライブラリはMFCでアプリ作るならやっぱり便利だし、メンテ続けてほしい。 BCGは次のバージョンでPer Monitor DPIに対応すると予告していて、ちょっと興味ある BCGは新バージョンのベータ版アナウンスしたし、経済制裁の影響は大してないのかも。 マイクロソフト社がフライドチキン業界に進出したらどんな略称になるんだろう? mfcのactivexコントロールの良書教えて下さい MFCで画像閲覧ソフトを作成しています。 ウィンドウのサイズを変更すると画像が消えてしまいます。 なぜなのかさっぱり検討が付きません。 https://ideone.com/Gn0AsK ウィンドウのサイズを変更したときにOnPain()が呼ばれることは確認済みです。 また、OnPaint()内の cbmp = CBitmap::FromHandle(m_image); の部分を CImage image; image.Load("画像データ"); cbmp = CBitmap::FromHandle(image); のように決め打ちで画像データを表示すると画面サイズを変更しても画像が消えません。 なにか良い手はないかご提示宜しくお願い致します。 すいません、環境を書くのを忘れていました。 Windows 10 Home 22H2 (64bit) Microsoft Visual Studio Community 2019 Version 16.11.20 何卒宜しくお願い致します。 「mfc onpaint WM_PAINT」で検索してみれば? MFC とか、こういうのは初心者がやるものじゃない。 たぶん、仕組みを理解するだけでも、10年以上掛かる 良い手も何も、そういうものだと思うしかない OnPaint()で描けばいいだけ いつウインドウがinvalidateされるのか、アプリケーションプログラマが完璧に把握することはたぶんできないし しても意味はあまりない >>708 ->>10 レスありがとうございます。 そういうものなのですね。 そういうものだと思って諦めます。 ありがとうございました。 >>706 そもそも、 cbmp = CBitmap::FromHandle(m_image); で取得したものを cbmp->DeleteObject(); で破棄しているのが原因では。 これだと1回目の描画のときにm_imageが破棄されて、 2回目以降は描画されないかと。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる