MFC相談室 mfc23d.dll [無断転載禁止]©2ch.net ->画像>4枚

Microsoft Foundation Classライブラリ専用スレです。

■MFC相談室 mfc21d.dll■
http://hibari.2ch.net/test/read.cgi/tech/1250919279/l50
■MFC リファレンス■
http://msdn.microsoft.com/ja-jp/library/d06h2x6e(v=VS.100).aspx

<　｀∀´>ﾆﾀﾞｰ

？

>>1　乙
ここは即死あるんだっけ？

1年くらい前から即死しない仕様になってる

即死なんて見たこと無い

ひでぶ

いや即死あるぞ
俺が今月立てたスレなくなってる

1000いったんでないの？、、ないかｗ

ドトネに負けたのか？

ネタくれ

質問しろ～
なんでも答えてやんぜって思ったら、俺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として読み込まれたと予想。

そのテキストファイル、シフトJISになってるぜ

>>25
setlocaleしたら
42 30
となっちゃいました

>>26
そう書いていますが？・・・

>unicodeなら
>30 00 42 00
>か
>00 30 00 42

てのがおかしい。

盛り上がってきましたw

レス番消えてる。。。荒らしか

片山ウザい氏ね

たしかにマジウゼー

嫌われ者ｗ

プロセスが起動した状態で、
ツールバーのツールチップの文字列を取得、変更したいのですが
ちょっと手こずっています。アドバイスお願いします

以下の方法ではツールチップではなくボタン文字列が対象になるようです
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
動的な変更は、やった事ないけど、このあたりでは？
http://home.att.ne.jp/banana/akatsuki/doc/mfc/mfc22/
アプリを普通に作っていれば、取得はボタンのリソースIDと同じIDを持つSＴＲＩＮＧリソース

>>35
ありがとうございます

以下で無事できました
http://nsoft.blog60.fc2.com/blog-entry-1875.html

ちょっとiconの相談です
MFCでプロジェクト作った際、アプリのicon（IDR_MAINFRAME）にいろんなイメージタイプ
(サイコロ3つ)が作られるけど私は全部設定するの面倒なので32x32 8bit bmpだけ
作って他全部消すようにしてます。皆さんはどうしてます？
いろんな環境に対応するためにあ-いうことしてるのかなーとは思うんだけど..

>>37
アイコンのイメージ作成にはInkscapeを使ってるよ。
お金に余裕があればAdobe Illustrator使えばいいんじゃないかな。
32x32だけだとユーザーに汚い画像を見せることになる。

>>38
Inkscape(笑) ダセーｗ

>>39
氏ね

> 32x32だけだとユーザーに汚い画像を見せることになる。

解像度を変えてのテストはある程度してるけどあまり気になったことないなー
私の想定を超えたデバイスだと汚くなるのかな？Inkscapeは落とした。勉強してみます。
片山博士は大きく&色彩豊かなicon作った後でInkscape使って縮小/減色してるの？

Inkscapeで256x256ピクセル(Vistaサイズ)にしてから図形を描いてとりあえず保存すればSVG形式ファイルになる。
「ファイル」メニューの「PNG形式でエクスポート」を選べばPNG画像が吐き出される。
それを16x16,32x32,48x4864x64に縮小して、見辛いピクセルを細かく補正してからアイコン作成ソフトに取り込むとアイコンができる。

Inkscapeは図形の合成などの強力な編集機能があるが、
図形が足りなければワード、エクセルの図形をコピペすればいい。

時間がないときは文字アイコンだね。１文字をアイコンにするだけで
インパクトあるかもしれない。

「アンチエイリアス」がかかると、どうしても細部がぼやけてしまう。
小さいアイコンでは、ユーザーにはっきり見えるように微細な加工をした方がいい。

片山ueeeeeeeeeeeeeeee

詳しい説明ありがとう

片山先生はアイコン一つにも手を抜かないんだな。
お前らも見習うべき

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をトラップするため、サブクラス化が必須になっている次第です

>>60
http://www.ne.jp/asahi/hishidama/home/tech/vcpp/subclsi.html

Createするから既存になってしまうんじゃないの？

>>57でいうサブクラス化ってSubclassWindow？ SubclassDlgItem?

CEditのサブクラスは時々使うけどSubclassWindow経由では使ってないので
外してたらｽﾏｿ

私がやるのは
https://support.microsoft.com/ja-jp/help/403856
の一番下のやり方。

自分でサブクラス化したときはDDX_Controlを削らないとうまく動いてくれなかったような気がする。
正解は知らんが。

>>60
mfcは昔やっててもう忘れかけだが
マウスボタンをトラップする程度なら
サブクラス化なんて不要なんじゃないか？

>>62
ありがとうございます

SubclasDlgItemを使っています
ですがデバッガで追うと結局は内部でSubclassWindowをを呼び出しているのは確認しています

>>64
ありがとうございます

DDXは使っていません
リソースにエディットボックスコントロールを貼りつけてはおらず、プログラム中でCEditクラスを派生したクラスを動的に作成しています

>>65
エディットボックスのマウス右クリックはサブクラス化が必要なようです

でも確かになにかコンテキスト～というメッセージがあったような気もしないでもないのですが…
WEBで調べた限りですと右クリックメッセージをフックしているのしか出てきませんでした

>>69
おおおお！！！
ありがとうございます！

早速試してみます！




と思いましたが、今日はもう事務所が閉まるそうです…
早速明日試してみます！
ありがとうございました！

明日もあさっても過ぎたんだけど、どうなったんだろうね。

事務所をロックアウトされて入れません

>>71
これは失礼しました
解決しましたのでご報告致します

結果的にはサブクラス化出来ました
動的にCEditを生成した際、実際のコントロールをCriateメソッドで生成すると思いますが一旦生成してしまうとサブクラス化できないようです

CMyEdit pualic CEdit として派生
CMyEdit lpCMyEdit = new CMyEdit;
lpCMyEdit->SubclassWindow(...←ここでサブクラス化
lpCMyEdit->Crate(...←コントロール作成

上記の手順でサブクラス化できましたのでWM_CONTEXTやWM_CHARに対してメッセージトラップが可能になりましたので全て実現できました

MFCのいう、ウィンドウの関連付けというのは恐らくコントロール作成時にWindowMapというMFCのクラスに登録されることかと思われます

改めて色々と相談に乗っていただき有り難うございました
また何かありましたら質問させて頂きます

>>72
間一髪間に合いました

>>73
誤字が…多かったです、すみません

>>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
そうなんです
失敗が多い分、成功の歓びがあります

>83
不要

>>85
はい、SubclassWindowは失敗していました

みなさんの言う通りコントロール作成時に暗黙にサブクラス化が行われているようです
とても勉強になりました
有り難うございます

そもそもなぜサブクラス化って言うの？
クラスとは関係ないと思うんですが

サブクラス化というネーミングはイマイチだとずっと思ってた。
APIの名称から来てるから翻訳者に罪はないが、、

VS2017入れてみたけど_MFC_VERは変化なし。
残念だ。

>>87
多分ウィンドウクラスを横取りするからじゃないかな？

実際クラスとは関係ないと思う
ファーストクラスとかも全然クラス関係ないし
英語にそういうニュアンスがあるんじゃないの

Windows1.0のときからあるし、オブジェクト指向の用語とは別路線で発生したもんだしなあ

GUI自体がオブジェクト指向の影響下で発展してきたわけで、別路線ってことはないだろう。
ウィンドウクラスごとにそれぞれ異なるWinProcを指す仕組みなんてほとんどv-tableだし。

確かWin32APIはsmalltalk由来のメッセージパッシング式オブジェクト指向を意識して作られたとかなんとか。
んで、C++はメッセージパッシング意識して作られてなかったから、言語自体を拡張されたのがC++Builderで、言語は拡張せず、メッセージテーブル作って無理くり対応したのがVCのMFCって何かで読んだ。

そう考えるとMFC以前はCでどうにかオブジェクト指向と言うより、メッセージパッシングを実現しようとしてWin32APIが出来たんだろね。

Win16の存在が消されてる...

生まれてなかったんで。
そう言えばWin16sとの互換性のためとか勉強した覚えある。

win32sならやったけど、Win16sは知らないなあ。

揚げ足どりにも程があるw

IT業界を離れて10数年経つ者です。
いまどき高速なアプリを手軽に作りたい場合、現役の方はどういう環境で作っています？
当時は主にMFC、たまにC++Builderでやってました。重くても良い場合はVBも使いました。
出来れば今後10年使えそうな奴をお願いします。今もたまに簡単なツールを作る機会が
ありますが、その際はMFCで作っています。多少勉強する覚悟はあります。
よろしくお願いします。

>>98
>出来れば今後10年使えそうな奴をお願いします。

ない。

>>98
本当に経験者ならこんな質問はしないやな

>>98
C#

C#やっときゃなんとかなる

WPFやUWPは廃れても、C#とXAMLは残ってそう。
C++とMFCも地味に残ってるだろうけど。。。

ご意見ありがとうございます。
参考にします。

Ｃ＃意外と人気なんだな・・・驚いた

MFCで印刷プレビューのリボンバーってどうやってカスタマイズするの？？

MDIの子ウィンドウのハンドルはどこですかぁ～

>>107
CDocument::GetFirstViewPosition
CDocument::GetNextView

> CCriticalSection オブジェクトの使用方式は、2 とおりあります。
> スタンドアロン方式、およびクラスに埋め込む方式です。
>
> スタンドアロン方式
> CCriticalSection オブジェクトをスタンドアロンで使うには、
> 必要が生じたときに CCriticalSection オブジェクトを構築します。
> コンストラクタから正常に戻った後、Lock を呼び出してオブジェクトを明示的にロックします。
> クリティカル セクションへのアクセスが完了したら、Unlock を呼び出します。
> この方法はソース コードを読んだ人にはわかりやすいのですが、
> アクセスの前後でクリティカル セクションをロック、アンロックすることを
> 覚えておかなければならないため、エラーを引き起こす傾向があります。
> より望ましいのは、CSingleLock クラスを使う方法です。
> この場合も Lock メソッドおよび Unlock メソッドを使いますが、
> 例外が発生したときにリソースのロックを解除する必要はありません。
>
> 埋め込み方式
> CCriticalSection 型のデータ メンバをクラスに追加し、
> 必要に応じてロックすると、複数のスレッドでクラスを共有することもできます。

MSDNのCCriticalSectionの説明には、上のように書かれているのですが、
このスタンドアロン方式って、どういう意図なのでしょうか。

普通に読めば、関数の内部でローカル変数として宣言するように思えるのですが、
それだと全く排他制御になっていないのでは？

Mutexみたいに名前付きなら上のスタンドアロン方式も理解できるけど名前ないからなー
わかんね

CCriticalSectionインスタンスが同期オブジェクトなわけではないよ。
クリティカルセクションは名前の通りクリティカルな区間のこと。Win32APIのEnterCriticalSection()からLeaveCriticalSection()の区間。
CCriticalSectionはこれのラッパー。
クリティカルセクションに入るスレッドはプロセスで一つだけになる。
プロセス間排他はできない代わりに軽い。

同期オブジェクトがプロセスで一つだけになのと同義。
マルチコア・マルチスレッドでロック待ちが無視できなくなるようなら他の使う。

>>110-112
解説ありがとうございます。

> CCriticalSection csForFoo ; // 非AUTO
> 　：
> csForFoo.Lock() ;
> strFoo += strBar ;
> csForFoo.Unlock() ;

この使い方が当初の疑問だったのですが、
このローカル変数としての使い方って、意味ありますか？
試しに同じような処理を作って、複数のスレッドから同時に呼んでみても、
全く排他制御されているように見えなかったのですが。

>>113

>>112
>CCriticalSection csForFoo ; // 非AUTO
https://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で２つのメニューを出したいので、mainframeにCMFCMenuBarを２つ作って、２つCreateすると、2つ目のCreateはAssertでとまってしまいます。2つのメニューを表示させる方法はありませんか？

>>118
「Method should be called once!」
なんてコメントが入ってるくらいだから、メニューは一つという設計なんだろう。

CMFCToolBarにCMFCToolBarMenuButtonを並べたほうが早いかも。
見た目を完全にメニューと合わせるなら、派生クラスを作ってオーバーライドする必要もあるだろうけど。

menuボタンを並べるのは良いアイデアだと思います。IEdemoというサンプルを見ていたら、LinkBarというクラスを作って使っていました。２つのメニューは、やはり初期化しないのが良さそうです。１つは別の物にしてみます。ありがとうございます！

IEDEMOのMFCコード、なかなか思い道理に動きません。MDIでサンプルを作って、CLinksBarとCLinksButtonを移植しようとしましたが、表示がバグります。バグっているけれどマウスカーソルをあてると、TOOLTIPが表示されます。何かが足りないようです。難しい

>>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プロジェクトだとなりません。素のままだとタイトルバーがチャイルドウインドウの数に応じてプロジェクト名＋１，２，３と表示されてしまいます。
　チャイルドウインドウの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社が、機能を別売りしている。
https://www.bcgsoft.com/featuretour/tour240.htm

2008年にMSがBCGを買収してCommunityEditionにこれが入っていたら、、と思う。

　CMFCVisualＭanagerでたぶんあっています。
　mfcのコンパイルオプションをUnicodeモードにすると、ラジオボタンの見た目が変わることは分かったのですが、ANSI(ShiftJIS)モードでコンパイルしたいのです。
　今気になっているのは、manifestファイルを追加してみようと思います。
http://gurigumi.s349.xrea.com/programming/visualcpp/sdk_luna.html

>>137
それはCMFCVisualＭanagerではないぞ。
Windowsのテーマのほうだ。

マルチバイト文字モードでコンパイルした場合の見た目の違いです。DDXControlで左はCButton右はCMFCButtonとひもづけました。

やはりmanifestファイルのようです。マニフェストファイルでラジオボタンは変化しました。
マニフェスト適用後

マニフェスト適用前

このスレはVisualStudioの使い方、
質問はアプリケーションの作り方
微妙に違うといえば違う。
かといって誘導出来る適当なスレは見当たらない
MFCのスレくらいかな

mfcのスレでmfcのクラスに関する質問をしていますよ。

Excelでキャレットの無い状態から日本語入力をするとテキストボックス？が現れて文字が未確定状態で表示されますが
同様な動きををCViewとCEditでやろうとしています。
以前はViewのOnCharからCEditにWM_CHARをポストすることで普通に動いていたのですが、OSの仕様が変わったのか
最初の1文字が確定状態で表示されてしまいます。ATOKもMS-IMEも同じです。

何かヒントがあれば教えてください。

excelでキャレットの無い状態というのがわかりません。＾が無い状態で入力を開始するのでしょうか？

>>144
レスありがとうございます。
Ｅｘｃｅｌを起動した直後、あるいはセルへのキーボード入力が完了した直後など、矢印キーでカーソルが動く状態のことです。

文字入力時に点滅する「Ｉ」のような記号がキャレットです。

回答になっているかどうか分からないのですが、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には有るようです。

一応、MSに連絡

まぁこのへんの仕組みはもう変わらないだろうし、
適当なものを選んでから書き直しても問題ないけどな。

TreeViewぐらいで

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

ウィザードのCListViewの話
去年にはもうあった話題やん
もうちょっと頑張ってくれよ
https://developercommunity.visualstudio.com/content/problem/135607/vs-1541-vcmfc-application-wizard-cant-select-listv.html

>>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("ＭＳ Ｐ明朝"));
lfMenu.lfHeight = -24;
CMFCMenuBar::SetMenuFont(&lfMenu);
lfMenu.lfOrientation = 900;
lfMenu.lfEscapement = 2700;
CMFCMenuBar::SetMenuFont(&lfMenu, FALSE);

> ボタンの表示非表示
m_wndToolBar.EnableCustomizeButton(TRUE, -1, _T(""), FALSE);
もしくは、EnableCustomizeButtonを呼ばない。

軽く煽ると答えを書いてくれるこのスレはチョロいよねｗ

自演じゃなければ

質問に答えると負けなんだろうか。
他のスレでも、質問に「答えない」ってだけのしょうもないマウントとりにくる人を見かけるね。

>>171
君が質問に答えてあげればいいじゃん

>>168
ありがとうございます。メニューのフォントサイズを変更でき、ボタンの追加・削除を消せました。
私ではとても考え付かない設定です。ありがとう!!

温度情報などをグラフにしてFormView上に描画できないか考え込んでいます。自前でCDCに描いていくのではなく、描くのに適しているmfcのライブラリは無いものか、探しています。どなたか目盛りのついたグラフ描画に良いクラスはご存じないでしょうか？

matlab

>>174
MFC用の有料ライブラリならこのへんがあるけど、使い勝手は知らない
https://www.bcgsoft.com/featuretour/tour270.htm
http://www.codejock.com/products/chart/

無料ならこのへんのソースを読んでみるとか
https://www.codeproject.com/KB/miscctrl/#Charting+Controls

matlabはおそらく有料ライセンスですよね。

>>176

> >>174
> MFC用の有料ライブラリならこのへんがあるけど、使い勝手は知らない
> https://www.bcgsoft.com/featuretour/tour270.htm
>
グラフとして、このようなグラフが描けると良いなとは思います。 http://www.codejock.com/products/chart/
>
> 無料ならこのへんのソースを読んでみるとか
> https://www.codeproject.com/KB/miscctrl/#Charting+Controls
ちょっと調べてみます。ありがとうございます。

昔の話で何ですが、DOSの時代にはMSCなどにグラフ描画ライブラリが付いてきていたような記憶があります。mfcには無さそうですよね。

>>179
最新版は知らないが、昔のMFCには無かったと思う。
(昔の) MSDN Library をよく見ているが、発見してない。

でも、グラフ描画って、LineTo() だけでも大体いけると思うんだけど。

OLE2使ってExcel呼べばいいんじゃね？
MFC関係ないのでスレチだけど

>>180
MSC = Microsoft CというDOS用のコンパイラです。1990年代のお話です。

>>182
知ってるけど

>>174 >>177
matplotlib の python 用 dll を c/c++ から使う手がある

.NETのChartコントロールをユーザーコントロールに置いてMFCダイアログでホストってのをやったことあるよ。
MFCビューでのやり方もMSDNに書いてあるからその通りやればできると思う。
MFC、Windowsフォーム、辺りで検索すれば見つかるはず。

.NET使いたくないって話では

.netはちょっと重いです。それでも参考になります。ありがとうございます。。

mfcとexcelの連携が全然分かんない……COM？何それ？みたいな
msdnとかstackoverflowとかいろいろ漁ってもだめ。っていうかそもそもmfc、windowsってよくわかんないクラスとか変数とか多すぎじゃない
もっと簡単にプログラミングさせてよ！って思う

>>188
VB6でも使ってろ

>>188
馬鹿には無理

昔、MFCに慣れてきた頃、趣味でMACのプログラミング勉強しようとして挫折したことがある。
Excel連携なら、その箇所だけでもVBでやるのがお勧め。

http://blog.systemjp.net/entry/20120827/p3

MFC使わなくてもCで良いのに

まずは、OleViewを起動してな。

折れ線グラフを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リソースが＋２される
test.DeleteObject(); //GDIリソースがー１される

差し引きGDIリソースの確保量が＋１になります。
そのうち線を書けなくなり、アプリケーションがクラッシュします。

使い方がどこか良くないのだと思うのですが、パラメータ等が良くないのかな。などと考え込んでいます。解決策をご存知ないですか？GDIリソースの確保量はタスクマネージャの設定でGDIリソースを表示できるようにして確認しています。

CreateCompatibleBitmapの前後5行ぐらいに原因がありそうな気がする

>>203
自分で開放しないといけないのを忘れてるだけじゃないかな

リソースの解放はDeleteObject();ではないのですか？
CreateCompatibleBitmapの前は、CreateCompatibleDCを呼び出しています。
CreateCompatibleDCのＤＣパラメータをNULLに設定すると、GDIリソースの浪費は無くなりますが、今度は出てくる画面が白黒になってしまいます。

>>206
ピクチャーコントロールのDCをGetDC()で取得してしてるのでは

スタック上でCBitmap test;とやった場合
関数を抜けるときに勝手にデストラクタでDeleteObjectされると思う。
もう少しコード晒さないと判らない。

CreateCompatibleDCでは、ピクチャーコントロールのＤＣを取得させています。
ピクチャーコントロールのＤＣを渡すと、CreateCompatibleBitmap時にGDIリソースを消費する量が２となるようです。
CreateCompatibleDCにNULLを指定した場合（確か）CreateCompatibleBitmap時のGDIリソース消費量ばかり１となります（以後の描画は白黒になります）。

今しばらく書いているコードをみられません。
CreateCompatibleDCやCreateCompatibleBitmapをOnSize時に破棄させてはサイズを変えて再生成させると、GDIリソースが消費されて減っていくので、
アプリケーション生成時に画面の最大サイズでCreateCompatibleDCさせておき、あとはCreateCompatibleDCしないように変更することも考えております。

アプリケーション生成時に画面のサイズ分のCreateCompatibleDCさせるようにすると、マルチモニタ環境の時などの動作が正常に動作しないかもしれないと思い、
可能ならOnSize内でDeleteObject();させてCreateCompatibleDCさせたいと思っています。

なお、OnSizeから抜けてもGDIリソース消費量は下がってくれないようです。

207が言っているのは
bitmap.CreateCompatibleBitmap(pict->GetDC(), rc.Width(), rc.Height())
してるんじゃないかって事。これだとリークします。

ReleaseDC

>>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(),ピクチャーコントロールのｘ,ｙ);
だったと思います。
GetDC()でピクチャーコントロールのＤＣを取得していたか、GetSafeDCでピクチャーコントロールのＤＣを取得していたかちょっと思い出せません。

CreateCompatibleDCのパラメータはＤＣ一つだけでしたね。ごめんなさい。

GetDCの返り血はReleaseDCしないといけない。

返り血こわ

ReleaseDCではGDIリソースがー１になりますが、createCompatibleBitmapで+２消費したぶんのすべては解放されてくれません。
releaseDCはおこなっていますが、GDIリソースの消費量は依然として＋１になってしまいます。

>>220
ソースきぼお

原因わかりました。
memBmp.CreateCompatibleBitmap(picctrl.GetDC(),x,y);

が良くなかったようです。
GetDC()でGDIリソースを１消費し、解放出来なくなります。

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!" が出ているのならちゃんと再試行を押そうよ。
それだけで原因そのものはわかる。

EQ8

EQ8

CListCtrでレポート表示のFullRowSelectをカスタムドローを弄ってます。

マウスがアイテムの上に来たら色を変えたいけど、カスタムドローのイベントハンドラだけできますか？
OnMouseMoveでどこにあるか判定してカスタムドローで描画が必要？


ビットマップを3番目のSubItemだけに貼るとか、16x16のSmallサイズ以外だとうまくいかないとか、癖が凄い。

tooltipの表示内容を一つのピクチャコントロール内で変更したいのですが、マウスカーソルが一端ピクチャコントロールから外れないと、ツールチップの内容が更新されないようです。onmousehoverなどを使わないと駄目でしょうか？

tooltipの解決策を見つけました。
http://www.geocities.jp/sunayamak/study/mfctooltip.html

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かみたいな

MFCはオワコン

C#
使え

>>254
そうでもない。

>>253
文字列は、単に文字列を保持したい場合や、文字列連結を行いたいような場合は、CStringが便利だと思う。

パーサーなんかを自作する時は、char *が便利。

>>253
ファイル操作は、経験上は、fopen()が便利かな。

CFileは意外と不便だった気がする。


stringは、敢えて使う必要は無いと思う。CStringで十分。

俺はできるだけ標準のほうを使うように切り替えた

機能が同等なら好みでいいと思うけど、ファイル操作みたいにOS依存が強い機能は
標準ライブラリじゃ足りない場合が多いかな。

MFCのGUI特化した本ないのかねー
大概が初心者向けでポインタやら構造体やらMFCと関係ないことが大半を占めてて知りたいことはうすーくしか書いてないのばっか

>>259
20年も前の本だが、お奨めは
https://calil.jp/book/475611749X

>>260
ありがと
1万くらいなら買うんだけどなぁ

本でなくて申し訳ないけど
ヘルプ。
クラスも大幅に拡張されてしまい昔の良書だとツリービュー、リストビュー位まで
最近のリッチな所はヘルプからサンプルソースにたどるのが早いかと

Windows本体ってMFCで作ってるの？

カーネルという意味では、ないやろな。性能面の要求はそんなに甘くないよ。
周辺の付加的モジュールでは、ATLとかは使ってるかも

Windows7のペイントとかワードパッドとかをSpy++で見ると、
Afx～の付くウィンドウクラス名が使われてるから、
このあたりはまだMFCで作られてたんじゃないだろうか。

なるほど

「コンピューターの管理」なんかも、AfxWnd42やAfxFrameOrView42uが出てくる。

>>261
>>259
うちにあるよ

>>263
あやしいよな

VC++6.0で作っています。　ＭＦＣです。
普通にＳＤＩを作りますが、そこからメニューバー等からダイアログボックスをモードレスで起動します。
すると、ダイアログを起動しながらメインウインドウも触れるようになるのですが、そのフォーカスを
モードレスダイアログとメインウインドウとをマウスを使わずにキーボードで切り替えることって出来ませんか

ＭＳのWindowsOSのＡｌｔ＋Ｔａｂではこれらはひとつとして認識されているようでこれでは切り替えられません
ちなみに、Windows7です

モードレスなら出来るやろ

>>271
メインウインドウからモードレスダイアログを起動するのですが、すると、Alt+Ｔａｂではこれらはひとつとして
認識されますよ

Ctrl+TAB

>>273
Ｃｔｒｌ＋ＴＡＢでは、ダイアログ上のコントロールのフォーカスが変わっていきます
ウインドウの切り替えはできません

Ctrl+Alt+TAB

>>275
やってみましたが、Alt+Tabでアプリを変えていけますが、そこに出てくるアプリの数が減っているのを
除いて、同じ動作です。　アプリが変わります

モードレスの親がメインウィンドウなら切り替えできず、親がない（デスクトップ）なら切り替えできるのでは。
親がメインウィンドウの場合でも、PreTranslateMessageでTABキーを補足してSetForegroundWindowとかすればいいと思う

デフォルトでは用意されていないのかな
PreTranslateMessageを使えばなんでもできますが、
メインウインドウとダイアログと両方に書かないといけないからなあ。しょうがないのかな

PreTranslateMessageで書きますか。　キーは何をあてるのが自然でしょうか
Ｃｔｒｌ＋Ｔａｂあたりかな
タブコントロールは、Ｔａｂ　だけと　Ｓｈｉｆｔ＋Ｔａｂで動きますからね

vista、vs.net2003 vc++の組み合わせだが
ALT+TABでｱﾌﾟﾘがきりかわりながら
ふつうにSDIとﾓｰﾄﾞﾚｽのﾀﾞｲｱﾛｸﾞでﾄｸﾞﾙする

>>280
わざわざありがとう。私と環境がちがうからなのかな
PreTranslateMessageを利用して、Ｃｔｒｌ＋Ｔａｂでプログラムを作りました。これでうまく行きました

>>281
ダイアログをCreateする時、親ウィンドウ(省略時=NULL)を指定していないから、
アプリケーションのメインウィンドウ(=AfxGetMainWnd())が、親ウィンドウが
になっているからでは？

CDialog::Create(CWnd::GetDesktopWindow())

とかでいけるはず。　MFCとは関係なく、Windows APIでは、所有ウィンドウ
(Owner Window)と、親ウィンドウ(Parent Window)は別管理。

MSDN見ても解決しないのでお願いします。
CMFCColorDialogで作成した色選択ダイアログの動きが少しおかしいです。
どれかの色(六角形)を選択すると[OK]ボタンのフォーカスが当たり、再度
別の色を選択するとフォーカスが外れるんですが、仕様でしょうか？？

.DoModal()を使っています。

>>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++のファイルを追加してビルドだ。

インクルードファイルとかいろいろエラーがたくさん出てきたよ
これ相当無理っぽい？？？

>>290
エラー貼れ

取りあえず、簡単に比較するために、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アプリが作れないなら、インストールで追加するしかないぜ。

https://twitter.com/katahiromz/status/1058697364821528576
https://twitter.com/5chan_nel (5ch newer account)

おいおい、なんだこれ
VS2017で、新規作成、プロジェクトで、Windowsデスクトップウィザードで
コンソールアプリケーションでMFCをチェックしてデフォルトのコードを自動生成してみました
そしてソリューションのビルドしたら、CWinAppが定義されてないとかエラーがわんさか出てきたぞ

おいおい、デフォルトの自動生成コードもビルド出来ないじゃん

左下、「探しているものが見つからないとき」

>>299
おや、そこが違う。　私のは、

visual C++の下に
Windowsデスクトップ
クロスプラットフォーム
MFC/ATL
テスト
その他
Extensibility

ってなってて、　MFC/ATLのところは
ATLプロジェクト
ってのだけがあります

何かインストを失敗してるのかなあ。　あるいはインストするときに何をインストするのかチェックがあったんだが
それを間違えてるのか。　でも俺がチェックをしなかったのはモバイル関係のところくらいだったんだよねえ

https://qiita.com/tadnakam/items/042c7a19bf115e3b096f

VS2017は頻繁に変更されるもんだから、ちょっと混乱してるみたい。

>>304
ありがとう。
右側の概要ってとこが、私のでは、インストールの詳細になっていて、
MFCとATLのサポート
ってのが私のでは、
x86用とx64用のVisualC++ATL
x86用とx64用のVisualC++MFC
ってわかれていて、ATLの方にだけデフォルトではチェックが入っていてMFCの方のチェックは
デフォルトでは外れていました。

チェックして再インストしてみますねw

インストよりもインスコの方が俗語の通りがいい。

ただいま、　再インスコ中です
みなさん、　VS2017をインスコするときは、

MFC　はデフォルトでは入らない ！！！

ことがわかりました
VS2017をインスコするときは、注意しましょう
インスコするとき、オプションをチェックすると入ります、　多分。今やってるところ

Qiitaの記事、結構役に立ってるじゃん。責任ある情報技術者なら、Qiitaに記事を書ける程になってもらいたいね。

>>309
qitta って査読制ですか？

出来ました。
MFCのインストがちゃんとできて、
MFCアプリケーションでデフォルトのMDI作ってみたら、　あら、すげえ

クラスビューなんかが出てくるのねw

最低限の審査はあると思うぞ。
詳しくは規約を。

おや、新しいバージョンだと、
strcpy( a, b )
で、b に CSringとか出来ないんだね。　前の古いバージョンでは出来たのに

CString で返す関数も、char a[10] とかで宣言したのを、古いバージョンでは、retuen a
って出来たんだが、新しいバージョンではエラーになる。　一旦
CString ret;
ret = a;
ってやって、return ret;
ってやったらエラーが消えた

いろいろと細かい修正しないとダメみたいだねえ

暗黙の型キャストのあいまいさが嫌いな人が存在するらしい。

>>314
いろいろとありがとう。　今日はとりあえずここまでにしておきます

>>313
きも

>>313
http://gurigumi.s349.xrea.com/programming/visualcpp/unicode.html

>>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
ってやってみたら、コンパイルまでは全部のｃｐｐファイルで出来たのですが、リンクで未解決エラーが出て
出来ませんでした

さすがにそれはおかしいのでVS2017再インストール推奨

>>328
マジですか。　再インストしようかな

_T() ?

>ちなみになんとか誤魔化せないかと思って
略
>リンクで未解決エラー

MessageBoxA と MessageBoxW とかを自分で書き分けてみると解決するはず

http://r2.upup.be/wV2qsULdHm

しねNG

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() が上手くいかないらしい。
なので、誰かに直して欲しい、と言うこと。

直してクレクレ。

http://dqmacro.blog.fc2.com/blog-category-5.html

chromeで開くと正常だけど
ffで開くと死ぬな

>>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 のマシンでの話。

なお予告なく変更されることがあります

MFC アプリケーションのツールバーを移動すると、ツールバーの移動枠とマウスカーソルの位置が離れる
https://social.msdn.microsoft.com/Forums/ja-JP/b47f8e8c-318b-4e7b-a81e-b97f26bffdc0/mfc

スタティックビルドがうまくできたらうれしかった

ウインドウを2枚用意して、片方を表に（上に）表示して、もう片方は裏にして見えないようにしている。で、裏の見えない方を
書き換えて、表のウインドウと入れ替えて、新しい描画のウインドウを出すということをしたいのです
裏メモリに書き込んで一瞬でモニターに出すという普通のやつをウインドウでします
裏でウインドウで書き込むとき、HIDE状態では書き込めないので、MINIMIZEの状態では出来ることがわかったので
そうしているのですが、問題はそれを最大化するときに、どうしても描画に時間がかかるというか、一瞬では出来ないのです
なので、アクティブ化せずに裏で最大化、あるいは、RESTOREする方法を探しているのですが、
APIのShowWindowとかだと、RESTOREもMAXIMIZEも必ずアクティブ化してしまうのですがいい方法はないでしょうか
いろいろとやってみて、２枚のウインドウに違う絵をかいておいて、片方をHIDE、片方をSHOWして、このHIDEと
SHOWと切り替えるってのが一番きれいに切り替わるようなのですが、書き込むとき、HIDEでは書き込めずに
MINIMIZEして書き込まないといけないので、MINIMIZEして書き込んだウインドウを表に出さずに大きくしてHIDE状態に出来れは
いいのですが

MemoryDCに書き込め

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)だね

>>349
MSは傲慢になっているだけ。

>>352

ローカルディスクの中で、MFCのCWinやCViewなどのソースは見られるのですが、
AfxGetApp()のソースコードだけが見つかりません。
どこにあるのでしょうか？

>>355
誤：CWin
正：CWnd

あなたの心のなかに

デバッグすれば見つかると思う。
多分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 に対して呼び出している
に過ぎません。

これはどういうことでしょうか？？

そりゃ発行済でキューに入ったメッセージはそのままになる罠
自分で読んでしまえば消えるだけのこと

>>362
https://docs.microsoft.com/ja-jp/cpp/mfc/reference/cwnd-class?view=vs-2019#killtimer
こっちには削除されないと書いてあるので、昔のMFCの説明が間違っているのでは

>>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以降とだいぶ違う？変換でエラー出るどころか文法もエラー出まくりでどうしようもならん。古い開発環境なんて無いし

_s 使えとかいっぱいでてうざいのは判る

それは確かプロパティで無視するようにできたよーな

無視したら、当時の脆弱性を認めることにはなるけどな。
あと forのカッコの中で宣言したループ変数のスコープとかも、6の時代とは違ったと思う。

判らないなら VC6 使うべき
上位互換でも VC6 モードにするべき

>>374
はぁ？

MSと契約してたらVS6は手に入るはずだが。

XPまでしかインストールできなかった気がする

仮想使えば？

古いWindowsならここにあるぞ
https://winworldpc.com/library/operating-systems

MSDN なら XP も VS6 も入手してるはず

>>380
なるほど
https://winworldpc.com/product/msdn/vs-60
https://winworldpc.com/product/microsoft-visual-stu/60

えぇこんなサイトあるのと思ってググったけど著作権的にグレイゾーンというかブラックでは

ちゃんと線引きしてるよ
https://winworldpc.com/product/windows-xp/final

要するにmicrosoftが黙認というか放置してるだけというか
権利を放棄してないのは確かだから使うならこっそりやりなさいよくらいのレベルなのかね
いずれにせよグレーなのは間違いない。仕事じゃ使えないね

仕事に使うって発想はなかったｗ
MSDNのCDをiso化して保存してるからな

仕事につかえないっ(キリっ)て話なら
純正のVC6でももう使うなよωって思うωωω

仕事したことない子供かよw

仕事で使うなら再現可能性は大切だからな
従業員が違法行為をしていたら、懲戒免職で済めば良い方で
損害賠償請求されたっておかしくはない

MFC保守なんていう面白そうな案件を当時を知らない若者にやらせるとかどうかしてる。

隔離VMで昔を懐かしむなんて楽しみ方はしてるよ
今のハードウエアなら神速かと思いきや期待ほどではない

でもネットに情報一杯あるから苦労でもないね。

過疎スレなのに無駄に伸びすぎ

若かった頃を思い出すノスタルジースレ

OS/2 1.0なんか楽しくて仕方なかった

mfcのコードってどれもこれもハンガリアンな印象なんだけど新し目のmfcコードだとその悪習から脱却されてたりする？
前世紀から連綿と受け継がれてきたようなのしかまだ見たことがないんだけど。いやそもそも新し目のmfcなんて存在するのかという問題もあるが

べつにハンガリアンが嫌なら自分のコードでは使わなきゃいいだけ。
使うライブラリのネーミングルールが気に入らないとか言うのは相当偏屈な奴だろう。

型が分からなくても平気な人はプログラマに向いてない。

ハンゲリアンは百害あって一利なし

UNIX勢のGUIが不安定だった頃、
MFCアプリが高機能てんこ盛りで安定してたのはハゲリアンのおかげである。

APIのリファレンスの記述用としては秀逸だと思うけどなあ

MFC製アプリはMSに数兆円の利益をもたらした。

ハゲリンは100害あっても兆利あった。

> 安定してたのはハゲリアンのおかげ

関係ないと思うが

理由も書かずに否定した気になってるという謎の万能感の持ち主ｗ

アンガリアン

>>404
変数名と高機能てんこ盛り安定は関係ない
そんなこともわからんのかバカ

>>406
何の話をしてんの？

90年代に書かれたのを最新のvisual studioで動くようにしてという仕事が降ってきて絶望している

全面的に描き治しになりますって見積もり出せ

普通に動くんじゃないの？

90年台のVCだとfor文の初期化式のスコープでまず引っかかりそう

ソースコードの量より多いワーニングが出そう

自分の作ったプログラム(MFC使用)でVC++4.0からVC++2008の移行を行ったけど、
(文法的に)エラー・ワーニングが出るところを機械的に修正していくだけで、プログラ
ムのアルゴリズムや構造を変えなければならないようなところは無かったから、
それほど手間はかからなかったよ。

2008はな。
でも今や2008もサポート停止。

>>409はマジ
信じられない工数がかかるなら
きちんと比例する費用をもらうことが
今後の仕事の単価を守ることでもある

>>414
うちでメインに使ってるのはまだVC2015だけど、2008ならもう
それ以降の最新VCに上げたからと言ってCソースの修正が
必要になる事ってほとんど無いやろ

>>406
ハゲリン

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にするか

4k非対応と明記すればOK

ちょっと聞きたいんだけど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++には興味ないのか

COMベースになるだろうな

.netでc#でって感じで、俺らの欲しいものじゃない奴を作っては消えていく
未だにMFCの方が安泰な気がするんだけどなあ

>>439
winui 3...

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掲示板群 http://x0000.net/forum.aspx?id=15

学術の巨大掲示板群 - アルファ・ラボ http://x0000.net
数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など

simulationライブラリで純粋な関数式プログラミングをする
http://x0000.net/topic.aspx?id=3631-0
UIライブラリ (C#, 2D) を作ったよ
http://x0000.net/topic.aspx?id=3688-0
連続と離散を統一した！
http://x0000.net/topic.aspx?id=3709-0
4Dエンジン（画像有り）
http://x0000.net/topic.aspx?id=3677-0
matrixのライブラリ
http://x0000.net/topic.aspx?id=3711-0
ある強力なFor関数
http://x0000.net/topic.aspx?id=3630-0
SQLライブラリ
http://x0000.net/topic.aspx?id=3675-0

PS malloc / free を実装してみた (C#)
http://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 使っても別に問題ないじゃない。

MFCはゴミ
当時のMSの過学習の成果物

>>459
と言ってもC++のクラスライブラリがこれしかない現実

APIの極薄ラッパーなところが有り難いんだよ
余計なことを押しつけずAPIを使いやすくすることに徹してくれていて

MFCもFeature Packの後　更にBCGSoft買収して全部無料にするとか、
WPFもどっかのライブラリ買収して無料にするとかカッコいいアプリ作れるようにすれば開発者の意欲も沸くのにな
xamarinとか糞は買収するくせに

使い安くなってるか？
余計な手間が増えてるだけだろ？

>>458
GUIを作るにはあまりに低レベルなAPIしかなくて
今の時代にそこから書くのは辛すぎる
もう一段上の抽象化レイヤーなりMFCみたいなクラスライブラリが欲しいところ

ココはMFCの相談室ではないのか・・

Win32APIに対してのMFCは一段上に行ってない
抽象レイヤですらない

>>466
薄いラッパーみたいなものかねえ

「東京版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と関わらなければ回避可能

女に関わることで起きる問題は
女と関わらなければ回避可能
だろ？　おまえの人生は

その発想は無かった

言い当て妙

>>475
それを言ったら終わりだよー

本当にそう思ってるやつがこんなとこに来るのは荒らし目的

うちの会社新人に研修でMFCやらせるんだけど大丈夫かな……多分創業当初から同じ課題渡してるんじゃないかな……

本番で使ってたらおぞましいが
研修なら反面教師に最適

C++使いがMFC使いたくないのは理解できるが、JavaとかPythonのようなモダン言語使ってる層ならわかりやすくて良いんじゃないの。

>>485みたいなのはMFCすら使いこなせなかった人だし、
>>484の会社は潰れてないんだから問題ないのでは？

ほかのC++のGUIライブラリ、例えばATL/WTLが
MFCに比べてそこまで使い勝手いいわけでもないけどな
些細なレベルで文句言ってただけ

OWLは良かったんだけどな

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