それだけで原因そのものはわかる。
探検
MFC相談室 mfc23d.dll [無断転載禁止]©2ch.net
それだけで原因そのものはわかる。
マウスがアイテムの上に来たら色を変えたいけど、カスタムドローのイベントハンドラだけできますか？
OnMouseMoveでどこにあるか判定してカスタムドローで描画が必要？
ビットマップを3番目のSubItemだけに貼るとか、16x16のSmallサイズ以外だとうまくいかないとか、癖が凄い。
http://www.geocities.jp/sunayamak/study/mfctooltip.html
おかげさまで何とか解決できました。
最初のプログラムから呼び出されて処理をするだけなので、ウインドウの表示とかしないです。ただただ処理して終わりです
それで問題なんですが通常のダイアログを使ったプログラムのように読み込み・変換処理を全部ダイアログ部分に書いてあるんです
ダイアログ使いもしないのにここに書くのおかしくないですか？と聞いたら表示されないんだしいいでしょと。画面表示を行わないMFCプログラムの場合、コードはどこに書くのが自然なんでしょうか？
メインプログラムがあってその内部でdatを生成するんですよ
で、そのdatのパスをコマンドライン引数で別のプログラムに渡すんですね
スレッドというかそもそも2つのプログラムですわ
どーーしても別プログラムにする事情があると仮定すれば
DialogやConsoleで構わないと思う。
冗長さを排除したいなら_tWinMainから書く手もあるけど
体感できるような差は出ないかと。表示されないんだしいいでしょw
>ダイアログ使いもしないのにここに書くのおかしくないですか？
じゃぁどこに書けばいいの？
MFCの仕組みを使いつつ、まったくウィンドウ表示が不要なものなら、
アプリケーションクラスのInitInstance()の中で処理して、
FALSEを返してすぐ終了するという流れでよいのでは。
結局それにしました。
あとは処理を分担するふっつーのC++クラスいくつか作ってダイアログは完全に使わない感じで
InitInstanceの場合は標準出力にメッセージを出せますか？
標準出力に出すmfcプログラムだとすると、_twinmainを使うとどうでしょう。
私なら _tmain 使うとおもいますが。
やほーい
CやC++で標準的に実装されてる機能とMFCクラスで実装されてる機能、どちらを使っても
同じことが実現できる場合、どちらを優先して使っていくべきなんでしょうか
要するに文字列ならchar*かstringかCStringか
ファイル操作ならfopenかstreamかCfileかみたいな
C#
使え
そうでもない。
>>253
文字列は、単に文字列を保持したい場合や、文字列連結を行いたいような場合は、CStringが便利だと思う。
パーサーなんかを自作する時は、char *が便利。
ファイル操作は、経験上は、fopen()が便利かな。
CFileは意外と不便だった気がする。
stringは、敢えて使う必要は無いと思う。CStringで十分。
標準ライブラリじゃ足りない場合が多いかな。
大概が初心者向けでポインタやら構造体やらMFCと関係ないことが大半を占めてて知りたいことはうすーくしか書いてないのばっか
20年も前の本だが、お奨めは
ttps://calil.jp/book/475611749X
ありがと
1万くらいなら買うんだけどなぁ
ヘルプ。
クラスも大幅に拡張されてしまい昔の良書だとツリービュー、リストビュー位まで
最近のリッチな所はヘルプからサンプルソースにたどるのが早いかと
周辺の付加的モジュールでは、ATLとかは使ってるかも
Afx〜の付くウィンドウクラス名が使われてるから、
このあたりはまだMFCで作られてたんじゃないだろうか。
>>259
うちにあるよ
あやしいよな
普通にＳＤＩを作りますが、そこからメニューバー等からダイアログボックスをモードレスで起動します。
すると、ダイアログを起動しながらメインウインドウも触れるようになるのですが、そのフォーカスを
モードレスダイアログとメインウインドウとをマウスを使わずにキーボードで切り替えることって出来ませんか
ＭＳのWindowsOSのＡｌｔ＋Ｔａｂではこれらはひとつとして認識されているようでこれでは切り替えられません
ちなみに、Windows7です
メインウインドウからモードレスダイアログを起動するのですが、すると、Alt+Ｔａｂではこれらはひとつとして
認識されますよ
Ｃｔｒｌ＋ＴＡＢでは、ダイアログ上のコントロールのフォーカスが変わっていきます
ウインドウの切り替えはできません
やってみましたが、Alt+Tabでアプリを変えていけますが、そこに出てくるアプリの数が減っているのを
除いて、同じ動作です。 アプリが変わります
親がメインウィンドウの場合でも、PreTranslateMessageでTABキーを補足してSetForegroundWindowとかすればいいと思う
PreTranslateMessageを使えばなんでもできますが、
メインウインドウとダイアログと両方に書かないといけないからなあ。しょうがないのかな
Ｃｔｒｌ＋Ｔａｂあたりかな
タブコントロールは、Ｔａｂ だけと Ｓｈｉｆｔ＋Ｔａｂで動きますからね
ALT+TABでｱﾌﾟﾘがきりかわりながら
ふつうにSDIとﾓｰﾄﾞﾚｽのﾀﾞｲｱﾛｸﾞでﾄｸﾞﾙする
わざわざありがとう。私と環境がちがうからなのかな
PreTranslateMessageを利用して、Ｃｔｒｌ＋Ｔａｂでプログラムを作りました。これでうまく行きました
ダイアログをCreateする時、親ウィンドウ(省略時=NULL)を指定していないから、
アプリケーションのメインウィンドウ(=AfxGetMainWnd())が、親ウィンドウが
になっているからでは？
CDialog::Create(CWnd::GetDesktopWindow())
とかでいけるはず。 MFCとは関係なく、Windows APIでは、所有ウィンドウ
(Owner Window)と、親ウィンドウ(Parent Window)は別管理。
CMFCColorDialogで作成した色選択ダイアログの動きが少しおかしいです。
どれかの色(六角形)を選択すると[OK]ボタンのフォーカスが当たり、再度
別の色を選択するとフォーカスが外れるんですが、仕様でしょうか？？
VS2008のNewControlsサンプルではそういう動作は見られないけど、
再現できるサンプルでもありますか？
わざわざ試していただいてありがとうござます！
こちらの環境、Windows10、VisualStudio2017なのでこれが原因っぽいです。
古いVisualStudioで試してみます。
業務アプリなのでサンプルは出しにくいです。申し訳ないです。
おお、今頃ですが、ありがとうございました
これでAlt+Tabでもモードレスウインドウが出てくるようになりました ！
Visual Studio 2017をインストして、古いソースコードを移植しようと思っています
VS2017に古いVC++6.0のdswファイルを読ませたのですが、うまくj変換できないようですが、どうしたら良いでしょうか
VC++6.0からの変換は出来ませんか
これ相当無理っぽい？？？
エラー貼れ
それと比較するため、VS2017でC++のWindowsデスクトップのデスクトップアプリケーションのデフォルトを作りました
すると、VS2017の方はMFC自身を使わないバージョンなのかな、CMainFrmとかIMPLEMENT_DYNCREATEとかなくて
VC6.0++のMainFrm.cppとかを2017の方に持ってきてコンパイルしたらCMainFrmが定義されてないとか
ずらっとたくさん出てきます
VS2017で、それを探してるのですが見つからないのですよ
MFCには対応してるのですよね。2015かそれ以前にはすでに対応してると聞いていたのですが
MFCを使ったデフォルトのコード生成はしてくれないとか？？？ w
メニューのファイルから新規作成、プロジェクトを選ぶと、その中にVisual C++はちゃんとありますよ
で、そこでWindowsデスクトップアプリケーションを選んでデフォルトを作ると、コードはSDKみたいなコードを吐きます
で、Windowsデスクトップウィザードってのがあったので、今これを選択してみたのですが、
アプリケーションの種類をコンソールにすると、その右にあるMFCのチェックボックスが有効になるのですが
Windowsアプリケーションってのを選ぶと、MFCのチェックボックスが使用不可になってしまいます
https://twitter.com/5chan_nel (5ch newer account)
VS2017で、新規作成、プロジェクトで、Windowsデスクトップウィザードで
コンソールアプリケーションでMFCをチェックしてデフォルトのコードを自動生成してみました
そしてソリューションのビルドしたら、CWinAppが定義されてないとかエラーがわんさか出てきたぞ
おいおい、デフォルトの自動生成コードもビルド出来ないじゃん
おや、そこが違う。 私のは、
visual C++の下に
Windowsデスクトップ
クロスプラットフォーム
MFC/ATL
テスト
その他
Extensibility
ってなってて、 MFC/ATLのところは
ATLプロジェクト
ってのだけがあります
それを間違えてるのか。 でも俺がチェックをしなかったのはモバイル関係のところくらいだったんだよねえ
ありがとう。
右側の概要ってとこが、私のでは、インストールの詳細になっていて、
MFCとATLのサポート
ってのが私のでは、
x86用とx64用のVisualC++ATL
x86用とx64用のVisualC++MFC
ってわかれていて、ATLの方にだけデフォルトではチェックが入っていてMFCの方のチェックは
デフォルトでは外れていました。
チェックして再インストしてみますねw
みなさん、 VS2017をインスコするときは、
MFC はデフォルトでは入らない ！！！
ことがわかりました
VS2017をインスコするときは、注意しましょう
インスコするとき、オプションをチェックすると入ります、 多分。今やってるところ
qitta って査読制ですか？
MFCのインストがちゃんとできて、
MFCアプリケーションでデフォルトのMDI作ってみたら、 あら、すげえ
クラスビューなんかが出てくるのねw
詳しくは規約を。
strcpy( a, b )
で、b に CSringとか出来ないんだね。 前の古いバージョンでは出来たのに
CString で返す関数も、char a[10] とかで宣言したのを、古いバージョンでは、retuen a
って出来たんだが、新しいバージョンではエラーになる。 一旦
CString ret;
ret = a;
ってやって、return ret;
ってやったらエラーが消えた
いろいろと細かい修正しないとダメみたいだねえ
いろいろとありがとう。 今日はとりあえずここまでにしておきます
きも
http://gurigumi.s349.xrea.com/programming/visualcpp/unicode.html
これありがとう。LPCWSTRの関係で、めっちゃ詰まってました
そもそも、CStringはTCHARを扱うクラスなのに、
_tcscpyではなくstrcpyを使っていたのが間違い
今は、_tcscpyを使ってもエラーが出るけどな
それはエラーではなくてセキュリティ上の警告では
そうです。 _sを付けたのを使えって
警告の設定を変更しないとエラーになってコンパイルが通りません
それをプロパティの設定で、Unicodeからマルチバイトに切り替えてコンパイルしたんだけど、どうも
Unicodeのままでうまく切り替わらないようなんですよねえ。 どうなってるのか。 今は時間がないので
またあとでやってみますが
警告だから、それに関してはコンパイルは通る。
他の場所がコンパイルエラーになっているだけかと。
新規作成途中に出てくるSDLのチェックをつけて作成したときと、はずして作成したときと両方してみました
すると、SDLつきの時は、_tcscpyはエラーになってコンパイルできませんが、
SDLをはずして新規作成したのものは、エラーにならずにコンパイルできて実行できます
デフォルトはSDLつきなので、コンパイルできません
次に、新規作成して出来上がったプロジェクトで、
メニューのプロジェクトから一番下のプロパティに入って、構成プロパティ、C/C++の全般にある
SDLチェックというところで、はい(/sdl) いいえ(/sdl-)を切り替えてやってみると、
この切り替えが動作せず、SDLのオン、オフが効きません。 プロジェクトの新規作成のときに設定したものが
残っていて、あとからここのプロパティで変更ができないようです
同じように、プロパティの構成プロパティの全般で、文字セットがデフォルトではUnicode文字セットを使用する
になってるのですが、これをマルチバイト文字セットを使用するにしても
Unicodeのままでマルチバイトにならないようです
バグですかねえ？
VisualStudioCommunity2017で試したが、普通に設定が反映されたぞ。
DebugとRelease、x86とx64で設定が別なのに気づいてないとかじゃないか?
できました。多分それです。ありがとうございました
コードの編集画面の上にあるコンボボックスを見ると、Debugとx86になってるのですが、
その状態でプロパティを開くと、なぜか、x64になってました。
なのでプロパティ画面で、上にあるプラットフォームをアクティブ(Win32)に変えると、画面がおかしくなって
びっくりしましたが、画面の再描画ができなかっただけなようで、再びプロパティ画面を出して
アクティブ(Win32)を確認してから、マルチバイトやSDLの変更をしたら、ちゃんと動いたようです
プロパティ画面を開くときは、連動してないので必ず確認してから変更しないといけないということですね
ちなみになんとか誤魔化せないかと思って、 stdafx.h の最初に
#undef UNICODE
#undef_UNICODE
ってやってみたら、コンパイルまでは全部のｃｐｐファイルで出来たのですが、リンクで未解決エラーが出て
出来ませんでした
マジですか。 再インストしようかな
略
>リンクで未解決エラー
MessageBoxA と MessageBoxW とかを自分で書き分けてみると解決するはず
ユーザーがコマンドを選択したら、その場所から動かすことができなくなるようにしたいのですが。
HDC hDC って、別アプリ（別プロセス）に渡して、書き込ませることは出来ないの？
HDC の識別番号が、プロセスごとに別の「名前空間」みたいなことになってるのかな。
That is, only the process that created the GDI object can use the object handle.
↑によれば、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() が上手くいかないらしい。
なので、誰かに直して欲しい、と言うこと。
直してクレクレ。
chromeで開くと正常だけど
ffで開くと死ぬな
さらに実験してみたところ、プロセス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 のマシンでの話。
https://social.msdn.microsoft.com/Forums/ja-JP/b47f8e8c-318b-4e7b-a81e-b97f26bffdc0/mfc
書き換えて、表のウインドウと入れ替えて、新しい描画のウインドウを出すということをしたいのです
裏メモリに書き込んで一瞬でモニターに出すという普通のやつをウインドウでします
裏でウインドウで書き込むとき、HIDE状態では書き込めないので、MINIMIZEの状態では出来ることがわかったので
そうしているのですが、問題はそれを最大化するときに、どうしても描画に時間がかかるというか、一瞬では出来ないのです
なので、アクティブ化せずに裏で最大化、あるいは、RESTOREする方法を探しているのですが、
APIのShowWindowとかだと、RESTOREもMAXIMIZEも必ずアクティブ化してしまうのですがいい方法はないでしょうか
いろいろとやってみて、２枚のウインドウに違う絵をかいておいて、片方をHIDE、片方をSHOWして、このHIDEと
SHOWと切り替えるってのが一番きれいに切り替わるようなのですが、書き込むとき、HIDEでは書き込めずに
MINIMIZEして書き込まないといけないので、MINIMIZEして書き込んだウインドウを表に出さずに大きくしてHIDE状態に出来れは
いいのですが
「更新中」のダイアログをDoModal()で出して、内部の情報を更新する動作を作っています。
更新処理はダイアログの中で別スレッドで行っていて、
タイマーで定期的にスレッドを監視して、終わっていたらEndDialog()で閉じます。
他の操作を不可にした上でキャンセルは可能にするために、このように作りました。
ここまでは問題なく動いているのですが、
アプリケーションがアクティブでないときにこの更新処理が走ると、
「更新中」のダイアログが閉じられた後に、アクティブ表示になってしまいます。
表示がアクティブになるだけで、フォーカスまでは奪いません。
二つのアプリケーションがアクティブ表示になってしまう状態です。
不思議に思ってMFCのソースを追いかけたところ、
CFrameWndのOnEnable()やOnActivate()やOnNcActivate()で
WF_STAYACTIVEのフラグを使ってアクティブ表示を強制するような仕組みがあり、
この中の処理を通った結果、アクティブ表示になってしまうようでした。
どうしてWF_STAYACTIVEに引っかかるのかなど、細かい流れは追い切れていませんが、
アクティブでないときに裏でダイアログが出て、その後自動で閉じるような動きを、
CFrameWndは想定していないということになりますでしょうか。
見た目のだけの問題ではありますが、CFrameWndの仕組みを保ったまま、
この現象を回避する方法はありませんでしょうか。
MFCをバリバリ使っているわけではないけど、なんか悲しい。
AのダイアログからBのダイアログをDoModalで呼び出す内容なんですが、ビルドも実行させても問題ないように見えるが大丈夫なんでしょうか？
CComboBox:: SelectStringの第一引数nStartAfterを0から-1にしたら動作した
でもなんでやろ？0でよさげなのに
MSは傲慢になっているだけ。
AfxGetApp()のソースコードだけが見つかりません。
どこにあるのでしょうか？
誤：CWin
正：CWnd
多分inline だからヘッダにあると。
拡張子を指定せずに、MFCのソースを含んだ全てのファイルを検索にかけたけど、
AfxGetApp()の定義だけは見つからなかった。
見落としは有るかもしれないが、当然、*.c, *,cpp, *.h, *.inl は全てチェックした。
afxwin1.inlのアタマにあるぞ。
afxCurrentWinAppを返してるだけだが。
GUIのgrepで、ファイルマスク欄に *.imp と入れたつもりが *,imp になってました。
orz
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 に対して呼び出している
に過ぎません。
これはどういうことでしょうか？？
自分で読んでしまえば消えるだけのこと
https://docs.microsoft.com/ja-jp/cpp/mfc/reference/cwnd-class?view=vs-2019#killtimer
こっちには削除されないと書いてあるので、昔のMFCの説明が間違っているのでは
ただ、WM_PAINT や WM_TIMER は、他のメッセージとは異なる処理を
されています。
Win32のメッセージキューは、1つのキューに見えるものが、OSの内部では
複数本持っているか、描画のDirtyフラグなどでなんらかの特殊な扱いを
しているようです。
なので、PeekMessage()しても、他のメッセージがあれば WM_TIMERメッセージを
拾えるかどうかは余り定かではないと思います。
もしかすると、その場合には KillTimer()の処理に置いては、WM_TIMERが
メッセージキューに「ポストされて無い」とみなされるのかもしれません。
解釈が難しいです。
独自定義の型山盛りでおまけにドキュメントも少ない。いやこれめちゃくちゃ難易度高くない
もうMFCに戻りたくないです。
でもthreadで動かすのはこっちの方が分かりやすい。
仕事でってことだが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 モードにするべき
はぁ？
https://winworldpc.com/library/operating-systems
なるほど
https://winworldpc.com/product/msdn/vs-60
https://winworldpc.com/product/microsoft-visual-stu/60
https://winworldpc.com/product/windows-xp/final
権利を放棄してないのは確かだから使うならこっそりやりなさいよくらいのレベルなのかね
いずれにせよグレーなのは間違いない。仕事じゃ使えないね
MSDNのCDをiso化して保存してるからな
純正のVC6でももう使うなよωって思うωωω
従業員が違法行為をしていたら、懲戒免職で済めば良い方で
損害賠償請求されたっておかしくはない
今のハードウエアなら神速かと思いきや期待ほどではない
前世紀から連綿と受け継がれてきたようなのしかまだ見たことがないんだけど。いやそもそも新し目のmfcなんて存在するのかという問題もあるが
使うライブラリのネーミングルールが気に入らないとか言うのは相当偏屈な奴だろう。
MFCアプリが高機能てんこ盛りで安定してたのはハゲリアンのおかげである。
ハゲリンは100害あっても兆利あった。
関係ないと思うが
変数名と高機能てんこ盛り安定は関係ない
そんなこともわからんのかバカ
何の話をしてんの？
(文法的に)エラー・ワーニングが出るところを機械的に修正していくだけで、プログラ
ムのアルゴリズムや構造を変えなければならないようなところは無かったから、
それほど手間はかからなかったよ。
でも今や2008もサポート停止。
信じられない工数がかかるなら
きちんと比例する費用をもらうことが
今後の仕事の単価を守ることでもある
うちでメインに使ってるのはまだVC2015だけど、2008ならもう
それ以降の最新VCに上げたからと言ってCソースの修正が
必要になる事ってほとんど無いやろ
ハゲリン
MFCIEというサンプルもビルドしてみたのですが、CTRL+ + などは効かないようです。
プログラムからコントロールできるのでしょうか？
どうすればいいのでしょうか？？
visual studio imaging libraryのアイコンを試しにツールバーのボタンに追加(コピー&ペースト)しようとしても背景がおかしくなります。
imaging libraryのアイコンが32bppのBGRAで、ツールバーのアイコンが24bpp。
ツールバーのエディタではビットマップのままで作っておいて、
それと同じ並びのPNG画像を用意して、ソースコードで指定する。
>>420
ありがとうございます。試してみます。
エディタ上でボタンの位置D&Dでかえれば、ビットマップも変わってくれるに
これを手動でしょうやるのか..
みんなさんどんなツール使ってるんでしょうか
個人的には ToolBar のクラスを独自に改造したり、似たものを独自に作ったりしてる。
自分もちょっとしたツール作って対応してみます
32bpp?のイメージリストをpngか32bppで書き出せるツールあたりを作ればいいのか?
もちろんイメージリストにイメージの追加とD&Dで移動
ありがとうございます
今のツールバーは、グレー化の状態とか、メニュー用の小サイズとか、
一つのツールバーに対して複数の画像を持たせられるので、
そのへんも想定した方がよいかと
ちなみに、MFCが買い取ったBCGのライブラリには、
32bitのPNGやSVGに対応したツールバーエディタも入ってるみたい
https://www.bcgsoft.com/doc/ToolbarEditor.htm
昔から、MFCのToolBarには色々な問題点があったので、
仕組みの簡単さから言えばCToolBarクラス自体を自分で作り直したほうが
便利。
Delphi/C++Builderの方に32bppのImageListをD&Dで移動など編集できる機能があるので、
そこでビットマップ管理して、後はPNGもしくは32bppのBMPで書き出すコードを
追加して、それをMFCの方で利用
>>427
そうなんですか。でも、その場合、ツールバーの移動とかカスタマイズ機能を付けるとなると
大変？
そういえば、移動というか、Docking機能の実装は結構難しかったな。
MFCのバージョンによって容易さは違ってくると思う。
恐らく、新しいMFCはだいぶ楽になってる気がする。
それなんですね。ツールバーやウィンドウのドッキング機能がほしかったので、とりあえず、MFCを使ってる次第です。
QtやDelphi/C++Builderの方にもウィンドウのドッキング機能があるっぽいですが、MFCが一番良さそうだったので
そこら辺を考慮して最終的にMFCにするかQtにするかはたまたDelphi/C++Builderにするか
メインのプログラムがMFCでそれに関連するC++のCUIアプリ書いて言われて純C++で書いたらMFC使えって
CUIにMFC使うって発想がまったく無かったんだけどありえなくもないんかな
コンソールでMFC使うのはアホだろ。メリットが一つでもあるのか？
自分はCUIアプリでもMFC使う事が多いね。
MFCはGUI関連以外でも汎用的な処理がクラス化されていて便利な物が多数あるからね。
CUIアプリでも良く使うのはCStringとかCxxArrayとかCFileFindとかかなあ。
これらの大部分はATLでも実現できるけど、普段GUIアプリをMFCで作ってるからCUIでも
ATLよりMFCを好んで使ってる。
あと、企画・開発から保守まで自分一人で行う物なら何をどう使っても良いけど、大き
なアプリの一部の開発なら、使うライブラリや記述・処理の作法なんかを他の人が作る
部分に合わせておくことは非常に重要。
CString受け以外では使わないなあ
APIのラッピングは結局APIのリファレンスも読まないとだめだし
もちろんGTKは糞だが
GTKよりも糞
そこ得意分野のはずなのにな
もうC++には興味ないのか
未だにMFCの方が安泰な気がするんだけどなあ
winui 3...
C#側の都合を押し付けられる予感しかしない
C#やクロスプラットフォームとは縁を切って欲しい
もっと、Visual Studio IDEみたいな情報密度のアプリにFluent Design(WinUI)が対応してくれれば
こういうの簡単に..っていうかMFCのビジュアルテーマもっと用意しろよって...
その路線windows8で失敗してるのにまた蒸し返すのかよって思ったな
なぜかというと今まで見たことも無いものが良いデザインに見えるからだ。
人間は見たことも無いことに驚く。そして驚きこそが良いデザイン本質だからだ。
便利だったり識別し易いものは既に多くある。それが実用性が高いものだ。
ところがよくあるものは陳腐に見えるため、良いデザインに見えない。
だからSF映画の世界では実用性のないUIを持ったコンソールパネルが宇宙船や
ロボットの中に描かれている。
見たことが無いのでかっこよく見えるのだ。
Windowのデザインも、4隅を丸くしたりするとかっこよく見えるが、
面積が無駄になるので実用性には乏しい。
だから、Windowの中の境界線を見えなくするものが流行っているが、めったに採用されてこなかった
ために驚きがあるため一部の人にはデザイン性が高く見える。
ところが、採用されてこなかったのは実用性が無いからであって、結局使いにくい。
学術の巨大掲示板群 - アルファ・ラボ 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
C++/CLIのGUIはもう終わりなのですか？
C++17前提で作り直すとどんな感じになるかな
たとえば
RUNTIME_CLASS(hogehoge)
↓
typeid(hogehoge)
みたいに
どっちかというと逆だと思う。C++/CLIがこけたせいでMFCが延命した。
なるほど。C++/CLIだと、C++言語の高速性が活かせなかったのかな？
何とかしてくれよ本当
なんで？、Win32 API 使っても別に問題ないじゃない。
当時のMSの過学習の成果物
と言ってもC++のクラスライブラリがこれしかない現実
余計なことを押しつけずAPIを使いやすくすることに徹してくれていて
WPFもどっかのライブラリ買収して無料にするとかカッコいいアプリ作れるようにすれば開発者の意欲も沸くのにな
xamarinとか糞は買収するくせに
余計な手間が増えてるだけだろ？
GUIを作るにはあまりに低レベルなAPIしかなくて
今の時代にそこから書くのは辛すぎる
もう一段上の抽象化レイヤーなりMFCみたいなクラスライブラリが欲しいところ
抽象レイヤですらない
薄いラッパーみたいなものかねえ
https://this.kiji.is/652740458292626529
2020/7/6 14:16 (JST)
MFCはAPIの極薄ラッパーだかんね
MFC独自の概念、シリアル化とかドキュメントビューとか
APIあんまり関係ないのもあるけどね
昔はこれしかなかったからみんな頑張って勉強したけど
それで済む用事をわざわざ難しくする必要はない
昔はgoogleとかないから名前覚えないと探せない問題はあったけど
今はよく使うものはなんとなく名前を覚えてしまう程度で充分だ
どうせエラーが発生したら調べることになるんだし
頑張るような要素はないと思うが
むしろMFCの勉強はしない方が良い
というかMFCの勉強はしてはいけない
英単語の暗記のようなものだから。
電話帳を勉強する必要ないのと同じ。
公式ドキュメントに書かれていない問題点や誤解しやすい点など、
先人の労苦をネットで調べるのは意味がある。
MFCと関わらなければ回避可能
女と関わらなければ回避可能
だろ？ おまえの人生は
それを言ったら終わりだよー
研修なら反面教師に最適
>>484の会社は潰れてないんだから問題ないのでは？
MFCに比べてそこまで使い勝手いいわけでもないけどな
些細なレベルで文句言ってただけ
だったよな
どうしてこうなった
C++/CLIはあまりメンテナンスされていないと聞くが
ただしC++/CLIでGUIアプリケーション作るのはもう推奨されなくなった。
Σ(￣ロ￣lll) ｶﾞﾋﾞｰﾝ
C++/CLIでMFCも使えるのですか！？
>ただしC++/CLIでGUIアプリケーション作るのはもう推奨されなくなった。
これってMSが推奨していないのですか？
古い情報で学習しようとしても今と違いすぎていて無理ゲー
http://www.kumei.ne.jp/c_lang/indexmfc.html
tcl/tk とか Qt とか wxWidgets やれ
そんなに違うか？
俺、win95時代にmsuセミナーで憶えたけど
大筋は変わってないぞ
そ・・・そんな・・・
C++で書いたコマンドラインツールをGUIにしたいので、MFCがいいと思ったんですけど
tcl/tkはC++で使えないみたいなので、Qt とか wxWidgets がいいのですか？
しかし、長生きするのはMFCってことはないでしょうか
最初のサンプルからしてVS2019で全然ビルドできないのですけど
つーかWindows95の時代って何年前ですか？
今の話をしているのですよ？
誰がそんな事言ったの？
使えるよ
MFC は無駄
そうだとしても何を使えばいいのかわからないよ
Unicodeも一切想定されていないから、標準設定ではコンパイルエラーになりそうだし。
他に良いMFCの教材があればいいのですが
まず、VS2019で、MFCのHello World的なものはビルドできる。
そっかっら後は、MSDN の英語版を読むといい。
日本語版は駄目。
そうだとすると学習コストが尋常じゃなくなりそうですね
Windows SDKで作るのは大変だし、MFCは学習が辛いし、どうしたものか
MFCがWin32のラッパなのだから、別に不適切ではない。
afxwin.h
などのヘッダファイルが、新しいMFCでは名称変更になっているが。
Windowsプログラムとはそういうもの。
結構大変なんだぞ。
まだ、存在するのか
VC++ か何かで、managed(.NET)から、unmanaged(.NET以外)を呼び出す機構があったような。
.NETのunmanaged拡張（C++/CLI）
最近のWindows では、C/C++ を、どうやってプログラミングするのだろう？
コマンドラインならいくらでもC++を使える。
C++のGUIは選択肢が少なくなっている。
MFCも将来性なさそうだからWindows SDKしか残らなくなるかもね。
あるいは上の方に書かれているサードパーティのGUIを使うか。
Windowsの主要言語はC#やVBになってしまった。
それ用のDLLが用意されていて、MFCのアプリケーションがほんの少しの変更で
C++/CLIでビルドできたよ。
C++ は、普通に
C++は普通にMFCをVS2019と共に使ってプログラミングすればよい。
よく使うアプリはネイティブなのばかり
MFC 使ってるのか Win32 直叩きかは知らんけど
日本ではMFCが普及すべき時期に無料のVS Expressが出てきて、
それがWin32のみでMFCには対応してなかった状態で、後から
無料のVS Communityが出てきて、今度は、C++よりC#が
前面に押し出されてしまったため、C++使いがMFCでプログラム
する機会を逃してしまっただけ。
メニューを処理する関数の作成なども、MFCだとVSによって自動化されているが、
Win32だとされていない。
ダイアログで文字列や数値を扱うDDEも、MFCではVSのサポートを得られるが、
Win32では得られない。
WM_CREATE, WM_SIZE, WM_LBUTTONDOWNなどのメッセージのハンドラ作成も、
MFCだとVSのサポートを得られるが、Win32だと得られない。
VSで、MFCのプロジェクトを新規作成すれば、HelloWorld的な
アプリは出来ているのだから、>>495で入門することも可能なはず。
今のMFCと違いがあるなら、それをGoogle検索で調べる。
たとえば、#includeされているヘッダファイルの名前が違っていると思ったら、
二つのファイル名とMFCというキーワードを半角スペースで区切って入れて、
英語モードのGoogleで検索すれば出てくる。
英語モードで検索して出てきたページを、Chromeの右クリックメニューで
出てくる日本語翻訳機能で日本語にして読み、意味が分かりにくければ、
URL欄の右隣に有るボタンから英語に戻して、辞書を引きながら読めばよい。
VS2019のウィザードを使うとかなり大層なアプリが生成されるぞ
Hello world的なアプリってどうやって生成するんだ？
「新しいプロジェクトの作製」で 「MFC アプリ」を選ぶと、「新しいプロジェクトを構成します」が出てくるので、右下の「作製」ボタンを押すと「MFC アプリケーション - アプリケーションの種類のオプション」
のダイアログが出てくるので、
プロジェクト形式: の場所が、デフォルトでは、「Visual Studio」になっているので
「MFC standard」に直す。こうすると、昔ながらの MFC の Hello World アプリになり、
入門サイトなどは大体これが基本になっている。デフォルトのままだと、入門には適さない。
アプリケーションの種類: は、デフォルトのままでも良いが、昔から作りたいものによって、
よく変更されていたものだから、変えて試して見るといい :
・単一のドキュメント : SDI アプリケーション
・複数のドキュメント : MDI アプリケーション (default)
・ダイアログベース : ダイアログベースアプリケーション
MDIって推奨されてなかったのでは？
それが今でもデフォルトなのか？
俺が参加したmsuセミナーで既にそう言ってた
いまさらMFC
VS2019でそれをやってもさほど変わらないのだが？
Hello worldと比べると比較にならないくらい複雑なプログラムが生成される
それを言ったらこのスレッドが不要ってことになるw
最初にソースを見ると複雑に見えるが、慣れてくるとそんなに複雑ではなく、
>>495 のような解説サイトは、それで理解できるはず。
MDIの悪いところを学んで改善したのがタブ
MFCのMDIにもタブ機能はあるぞ
最近だとC++ WinUIに持っていきたい感じはするね
そのためかMSの中でC++の地位が上がってるような気がする
MFCはこのまま廃れていくんじゃないか
C++/WinRTのことかな？
これってまだ普及していないのはなぜ？
別物だけど...
別物かよwww
Windows上のC++開発環境っていくつあるんだ？
Win/UIが登場したらWin/RTがオワコンにならないの？
よーわからん
流行るかどうか次第だと思うけど
C++をまともにサポートしてるのは大きい
完全にUWPの時代になるよ
.NET Frameworkが始まった時ってC++がおまけの扱いされてけど、
今回はWindows上にC++のアプリ作ってもらおうとしてる感じがする
乗り遅れるなよ
https://ascii.jp/elem/000/004/014/4014034/
情報を拡散する人がいないのかな
その方向転換がされたらMFCとWinRTと別の環境ができるのかな？
Win32 : 情報はそこそこあるけど扱いが面倒
MFC : 今から勉強すると時間をドブに捨てる可能性あり
C++/CLI : 死亡
C++/CX : 死亡
WRL : 死亡
C++/WinRT : MSはこれを推奨しているが、UWPの開発環境なので人気なし
DLL しか作れない
けっきょくC++だと消去法でMFCになるんだよな。
しかし、今からMFCを勉強するのも現実的なのか？
相当な時間がかかるのではないか？
だから消去法だよ。いまさらwin32でやろうとする方がもっと非現実的。
じゃないと議論が出来ないからな。
ほんの少しでいい。電話帳を暗記する必要ないのと同じだから。公衆電話のかけ方を学ぶ感じ。
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倍有って、開発効率は格段に上がる。
他にも、
WM_LBUTTONDOWN が、OnLButtonDown()
WM_MOUSEMOVE が、OnMouseMove()
WM_NCPAINT が、OnNcPaint() または、OnNcDraw()
に対応している。
WM_COMMANDは、OnCommand()も有ったかも知れないが、
メッセージマップと言う仕組みで、IDEと組み合わせてもっと効率よく
ハンドラを作製できるようになっている。
Win32より、MFCの方が後発で、C++でWindowsアプリを作るには、後者の
方が定番で、開発効率も高い。
MFCは未だに改良が進んでいる。
たとえば、ドッキング、自動レイアウト関連、リボンなどは、Win32にはなく、
MFC独自。
また、Windowsアプリらしいアプリは、Win32より、MFCの機能を使っている。
商用やプロが作るnativeアプリは、ほとんどがWin32ではなくMFC製。
軽量かもしれんがWTLも全然お手軽ではない
何十年も期間はあったのにMFCの代わりにATL/WTL使うようにはなってない
なにが紛れ込んだんやろか？
ATL/WTLのスレは2年ほど書き込みないがあっちが正常やで
自分の場合、MFCを始めようとしても何から始めればいいのか分からないし、もはやMFCをちゃんと解説した本もない。勉強する時間もない。
Win32の方がある意味わかりやすい。オブジェクト指向ではないので、クラス構成を把握する必要もない。小規模な開発なら何とかなると思う。
wxWidgets のようなクロスプラットフォーム狙うか、
いっそ C++ から離れるか
最後に書き込んだの私だった（笑）
324 自分：デフォルトの名無しさん[] 投稿日：2018/12/02(日) 09:05:18.31 ID:pHBSzoap
最近、頻繁にWTL10のmasterブランチが更新されているね。
https://sourceforge.net/p/wtl/git/ci/master/tree/
MFCの場合、まず、IDEを使って、MFCプロジェクトを作るところから始める。
後は、Menuリソースに1つメニュー項目を追加して、それに対するハンドラを作成し、
中でAfxMessageBox()などを使って、ハンドラが呼び出されるのを確認する。
画面は、OnDrawの中でpDC->MoveTo(), pDC->LineTo()で直線を描いてみる。
それが出来たら、さっきのハンドラの中で、Invalidate()を呼び出すテスト。
Invalidate()を呼び出すと、メッセージがメッセージキューにたまりまくっている
場合以外は、比較的即座にOnDraw()が呼び出される。
それで色々いじって試してみるといい。
だから、メインとしてAndroid/iOS向けに開発したクロスプラットフォーム向けのアプリで
Windows向けもビルドできるというおこぼれをもらうしかない。
いや、そんなでもないよ
Win32の手順や概念をクラス化なんて秒殺でできるからな
普通にCで書いてる感覚でクラス化したほうがいいところがあればひょいと
んで、毎度おなじみのコードが出てきたら再使用できるように括り出しておく
それだけのことで非現実的というほど大変なことではない
いまだに新しいものが出てきてるからね
Webだとパフォーマンス出ない分野のツールはまだまだ有効
今でも、医療用・産業用ソフトなどは、Windows 限定かも
年寄りのマウント合戦で盛り上がっているようにしか見えないが。
昔から大して変わっていないとも言えるが
desktopアプリを食っていくために作ることが難しくなった。
MSが手を出してない分野では、ぎりぎりなんとかなっていることもある。
でも2DグラフィックはAdobe、3DはAutoDeskなんかが強い。
最近は、3Dは、OSSのBlenderもあるから生半可には参入できないが。
でも、有名ソフトが無料化してる場合は辛い。
本等は、完全なダンピングだから、法的な取締りの対象にならなければならないのだが。
Visual Studio Communityはダンピングだから、罰するべきだ。
C言語なので、Windowsの知識がなくても地道に積み上げながら理解できる。
他の開発環境だとC++クラスライブラリなので、クラスの役割の全体像を把握するまで何もできない。しかもWindowsの前提知識が必要。
実は、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でこれに相当する作業を手作業でするのはとても効率が悪い。
Win32+MFCを習得するのに何年かかるんだ？
win32: Petzoldの本で１ヶ月
mfc: msuセミナーで２週
win32は少しでもかじってれば、あやふやでもmfcは何とかなる
Cの理解が先に出来てたから
イベントドリブンとかメッセージループとか
典型的な描きかただけなら1日で充分理解出来た
全体理解なんて今でもムリポ
MFCも秒
C++とWin32APIを理解してたらそもそも勉強の必要すら無い
何を持って習得と言うかわからないが、
1. HelloWorldは、IDEが作ってくれる。
2. Menu項目の作り方と、ハンドラの作り方は、ネットで検索すると
解説されたものがいくつかあるはず。
3. OnDraw()の中の書き方は、Win32のGDIとCとC++の書き方程度の違い
で、基本的に変わらない。
4. WM_LBUTTONDOWNとOnLButtonDown()などは一対一に対応しているだけで、
Win32と同じ。
5. Dialogのデータ交換DDEは、チュートリアルを読まないと難しい。
解説サイトを読むのは人によるが、速い人は20分とかでも読めるのではないか。
MFCは、習得すれば効率は良いが、IDEとの連携を習得するのに時間が掛かる。
IDEは、かなり使い込んでも、知らない機能は多い。
今のVSはMFCのHello worldを作ってくれない
最新情報じゃないと意味ないよ
>C++とWin32APIを理解してたらそもそも勉強の必要すら無い
俺はVS2019が新規作成で生成した複雑なプログラム（VS2019はHello worldを生成しない。いきなり複雑なものを生成する）を見て途方にくれたがなー
何から始めればいいのか全く理解できない
作り方がこのスレッドにも出ていたぞ。
MFCプロジェクトを作る際、「Visual Studio」となっているところを、
「MFC Standard」に変えれば MFC の Hello Worldが出来るぞ。
VS2019でその通りにやってみたけどできなかったよ
ドキュメントビューとかシリアル化、DDX/DDVなんてのは独自の概念だ
言語でも使えるようになるのは無理だろうし、プログラミングに限らず何をやっても
ダメな人間だと思う。
少なくともHello Worldは表示できなかった
非常に複雑なものが生成された
>>595
今まで組み込みのプログラミング（電子回路と測定器の知識必須）をしてきたけど、C/C++でずっと仕事をしてきたし、仕事もちゃんとできているよ。
どうしてMFCができないと仕事ができないの？
Windowsだけがプログラミングなの？
ただ急にWindowsでプログラミングをしないといけなくなって困っているだけだが？
組み込みのプログラミングと違ってフレームワークが全てを支配するというのが苦手なので仕方がない。
プログラマがすべてを把握する責任を負わなくていい。それがフレームワークの恩恵。
WindowsだろうがmacOSだろうがスマホだろうがこれは同じ。
できた結果を書いている。
Hello Worldというのは、なにも、Hello Worldと表示するプログラムの事を
意味しているわけではなく、最初に学習し易いサンプルの事だぞ。
できた結果を書いている。
Hello Worldというのは、なにも、Hello Worldと表示するプログラムの事を
意味しているわけではなく、最初に学習し易いサンプルの事だぞ。
ちゃんと「Standard MFC」に変えた場合、
Hello World という文字は表示されないが、MFCにとっては、それ以上減らせない
程度にシンプルなサンプルが作製される。
オイラもアセンブラでプログラムしていた口だから、人が勝手に用意した
型枠を使うのは余り好きではなかったし、気持ちは分かる。
しかし、MFCでは、原則的にはあれ以上は減らせない。
ユーザーからの入力がプログラムに反映されるところまで試さないと
プログラマとしてはひと安心できないはず。
気持ち悪いのはMFCだけじゃないってこと。こういうもんだと慣れるしかない。
hoge.cs と hoge.exe しか造られないからすっきり
MFCバリバリ現役じゃん
浅はかなやつってライブラリで仕事してる人の
苦労が何も解ってないんだろうな
MFCの最期を暖かく見送るスレ
MFC利用者をdisるスレ
現役なのは確かだけどオワコンでもあるんだよね
それは困る。
UWP系は避けたい
こんなんだからMFCじゃなくてMF爺って呼ばれてるんだぞ
おすすめは？
でも実例は挙げないで、訊かれても「自分で調べろ」一点張り
ウィジェット・ツールキット - Wikipedia
https://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A3%E3%82%B8%E3%82%A7%E3%83%83%E3%83%88%E3%83%BB%E3%83%84%E3%83%BC%E3%83%AB%E3%82%AD%E3%83%83%E3%83%88
具体例をあげよ
Visual Studioが使えなくなる。
Tcl/Tk
wxWidgets
Qt
その他
MFC Tutorial
https://www.tutorialspoint.com/mfc/index.htm
上の海外のページでもダイアログベースの説明なんだよなあ。
SDIやMDIを好きに変更できるようにならないと業務に使えないのだが。
もしかしたらCMultiDocTemplateクラスのせいで自由にレイアウト変更できないの？
ωωω
他にも、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章 デバイスコンテキスト
>>625を読んでないなw
この本は、ちゃんと、1つの章を割いているので、別の本のことかと思った。
そもそも、MFCのSDI/MDIは、そんなに高機能ではないので、質問者は勘違いしている
かも知れない。
MFCは、ダイアログベースにすると、割とIDEの機能が強く働いて、
C#のWinFormsと似たようなポトペタ的なプログラミングに近くなるが、
SDI/MDIは、メニュー以外には余り支援が無い。
SD/MDIでも、ダイアログを使えば、ポトペタ的になる。
というか、「Win32 Control」と呼ばれているものは、もともと、
ダイアログに入れた場合にちょうどよく機能するように設計されている。
だから、「ダイアログリソース」なるものがあるが、それ以外では、
独自に全て座標やサイズを指定して出すしかない。
普通、どのアプリを見ても分かるが、メインメニューとツールバーがあり、
一行のテキストフィールド(EditBox)や、ボタン、チェックボックス、
コンボボックスなどは、全てダイアログの中に収められていることが多い。
だから、SDI/MDIアプリも、IDEの支援は、ダイアログ以外は、
メニューとツールバーが中心で、後は関数の作製・削除、検索、置換、
デバッグなどに限定される。
というわけで、SDI/MDIプログラムを学ぶと言っても、ポトペタ的な
ものは、ダイアログの部分を学べばよいだけ。
そしてそれに関係するのが、ダイアログデータエクスチェンジ(DDE)。
625です。
その本を立ち読みしたのですが、SDI/MDIの部分は本当にペラペラです。
ダイアログベースだとメニューがないので、あれは実用にならないのではないでしょうか？
自分的にはSDI/MDIが実用アプリの基礎であれを改造しないと実用にならないと思っていたのですが、違うのですか？
個人的にはメニューがあって、ウィンドウにツリービューが表示されているようなものを作りたいのですけど、調べてもちっとも分からないんですよね。
最悪、Win32で作るしかないとは思っていますが。
>個人的にはメニューがあって、ウィンドウにツリービューが表示されているようなものを作りたいのですけど、調べてもちっとも分からないんですよね。
VS2019だと、MFC-Projectを作成する際に「Visual Studio」を選ぶと最初から
サンプルとして利用できるプロジェクトが作られる。
Windowsプログラムでは、作り方は、サンプルを参考にして、そこをヒントに
分からない部分をネットで検索して調べるのが基本。
全くサンプルが無いと作るのはほとんど不可能な場合があり、
「SDK」と呼ばれているものの意味や目的の50%は、サンプル集であると言っても
過言ではない。
>ダイアログベースだとメニューがないので、あれは実用にならないのではないでしょうか？
>自分的にはSDI/MDIが実用アプリの基礎であれを改造しないと実用にならないと思っていたのですが、違うのですか？
ダイアログベースアプリも結構見かけて、C#のWinFormsアプリとMFCのダイアログアプリ
は、言語が違うだけで理念はほぼ同じ。
しかし、本格的な「アプリ」を作りたければ、SDI/MDIプロジェクトをベースに作るのが基本。
「ダイアログベース」にしなくても、ダイアログベースアプリの作り方で学んだ知識は、
SDI/MDIアプリでも生かせる。
SDI/MDIアプリの中で、ダイアログを生成することが出来、その時に、ダイアログベースアプリ
と同様の作法が使えるから。
ウィンドウにツリービューを入れたい場合、CTreeViewまたは、CTreeCtrlを使う。
>ウィンドウにツリービューを入れたい場合、CTreeViewまたは、CTreeCtrlを使う。
CTreeViewは知っているけど、VSが生成したプログラムにどうやって入れるのかがわからないんですよ。
検索してもちっとも出てこない。英語で検索しても出てこない。
日本語でも英語でもダイアログベースの解説しか出てこないので、ツールボックスからツリービューをダイアログにドラッグ・ドロップしてしか出てこない。
こんなのじゃ役に立たない！
VSが生成する前のアプリケーションウィザードのところで
基本クラスをCViewからCTreeViewに変更できる
できましたけど、VIEW/DOCモデルを選択した時しかできないですよね。
VIEW/DOCモデルを使うと、ファイル読み込みと書き込みの対称関係が強制されるので、これも困るというか。
自分が作りたいアプリは、メモリに絶対入らない巨大なファイルを少しずつ処理してエクスポートするものなので、読込・保存の概念がない。
やはりMFCは使わない方がいいのだろうか。Win32にした方がいいかもしれない。
どうしてMFCはWin32みたいに部品を組み合わせていくように作れないのだろう。
class library と名乗るのがそもそも詐欺
ただの win32api wrapper あるいは劣化版
それは一般的な見解なのでしょうか？
ここだと「Win32は手間がかかりすぎる。MFCにしないとだめ」的な書き込みも多々見かけるので混乱します。
別に、ドキュメント/ビューの仕組みを使ったら
ファイル全体をメモリ上に読み込まないといけないわけではないけど、
そうなると、MFCの標準の処理をいろいろオーバーライドすることになるので、
内部の仕組みを理解する必要が出てくる。
ドキュメント/ビューが抵抗あるなら、使わずにSDIを作成して、
CChildViewの中にCTreeCtrlを載せたりすることもできるけど。
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との対応関係が分かる。
MFCは、Win32の軽いラッパーであることは、標準見解。
ただし、IDEとの連携がWin32より上手くできているので開発効率は上がる。
理解するのは、実はWin32より難しくなってしまっている部分もある。
しかし、イベントハンドラやメニューハンドラをどんどん追加していく場合の
効率がとても良い。
また、新しいWindowを作る際も、ClassWizardから作るとWin32で自分で
作るより速いことが多い。
メニューにチェック記号を付けたり、グレイ表示にしたい場合も、
MFCは、CCmdUI や、ON_UPDATE_COMMAND_UI()などを自動生成できるので、
効率が良い。
また、Win32だとswitch文でメニューを処理するが、MFCだと、自動生成された関数
で処理するので、大規模なアプリの場合、コードが整理される。
MFCの読み込み、保存の概念は、はっきり言って、型にはめられすぎていて
MSが想定した典型的なアプリ以外だと不便だから、実は無視してもいい。
それから、DocTemplateを理解するのがまた難しいが、それはなかなか避けて
通れないこともある。
基本的には、フレームワークが想定しているファイルオープンの概念を、
如何に無視して自分流にしていけるかが、MFCを使う上での重要なポイントになる。
最初は難しいが、MFCはソースがあるので、それをおっていくと、何をやっている
かが分かるので、「安全に無視する方法」を探るといい。
うーむ・・・
結局、MFCが提供する仕組みを無視しないと自由にプログラムを組めないのか。
しかも安全に無視するにはMFCの仕組みを熟知しないといけないと。
そんなこと組込一筋の自分にはできそうにないなあ。
今作りたいプログラムを作ったらMFCを使うことは二度となさそうだし、やはりMFCは回避するべきだろうか・・・
頭痛いよ
というか、「Doc,Viewは かくあるべき」という設計思想が難しいし、
それを守っても余り良いこと無いので、無視してよい、ということ。
なにも、アメリカ人の考えた思想に従う必要は無いのだから。
その当時の彼らはそれが理想だと考えたかも知れないが、それも
どんどん変化しているし、別の勢力はまた別の設計思想を持っているのだから。
いやいや、別に邪道なことをしているわけではない
Docを使う／使わないを任意に選べるようになっているというだけ
無駄に覚えることが増えるし
しかもバッドノウハウで
他に何の役にも立たん
深入りする意味が無い
>>640に「そうなると、MFCの標準の処理をいろいろオーバーライドすることになるので、内部の仕組みを理解する必要が出てくる。」と書かれているので、難しいはずです。簡単に無視できないはず。
そもそも組み込みの技術者なので、PCのプログラミングは「ついで」的にしないといけない。
PCのプログラミングに力を入れると評価が下がってしまう。
そうなると知識量が必要なMFCは避けないといけない。やはりWin32にするべきか。
>>648
バッドノウハウ＝MFCってことですか？
> SDIやMDIを好きに変更できるようにならないと業務に使えないのだが。
こう言ってた人が
> PCのプログラミングに力を入れると評価が下がってしまう。
> そうなると知識量が必要なMFCは避けないといけない。やはりWin32にするべきか。
こう言い出す意味がよくわからんのだが
組み込みが本業の人がMFCを何に使うんだろう
基板から送られてくるデータを可視化とか？
シミュレーションや回路設計は専用ソフト使うだけだし
要は力を入れないで業務で使えるGUIのプログラミングをしないといけないということです。
何も分かっていない上司に言われてやっているので、仕方がないのです。
>組み込みが本業の人がMFCを何に使うんだろう
企業秘密なので、詳細は書けない。
データの可視化の一種と言っておく。
でも、プロジェクト作成時に「Visual Studio」を選ぶと、プロジェクトを作製した直後から、TreeViewが既に出ているよね。
それをいじくれば、TreeViewは制御できる。
後はメニューに対するハンドラの書き方さえ分かれば、アプリは作れる。
現場で働く派遣社員や外注などのレベル低下でCUIのツールが受け入れられなくなっているってだけでGUIのプログラミングをやるはめになった。
問題は>>649ですよ
裏でCUIツールを起動するだけ、みたいのだとダイアログベースで充分じゃね？
それは上司にダメって言われたんですよ
内容的にはダイアログベースなやつにするとか
ログを記録したり終了時に使用状態をファイルに記憶させるのにDoc使いましたよって
そこまでは知識不足で判断できません。
どちらにしても>>640の言うように使わない機能を無視するのも簡単ではないようですが。
Doc/Viewを使わないSDIで、CChildViewに処理を全部入れてしまうのが一番シンプルでは？
ドキュメント/ビューを一切使わないのは簡単
使わないだけ
ダイアログにメニューも普通に付く
「ダイアログ メニュー」でggr
そんなにWin32API直でやりたいならそうすればいいけど
どっちにしろ、猫でものWindows SDK編でも一通りやっといた方がいいよ
MFC使うにしても、「ドキュメント/ビュー」とかのMFC独自のとこ以外は
よく言われるようにWin32APIの薄いラッパだから
そこまで判断する知識はまだなくて
>>660
>ダイアログにメニューも普通に付く
そんなことが可能なのですね。
https://www.kazetest.com/vcmemo/dialogmenu/dialogmenu.htm
それならダイアログベースでも可能かもしれません。
Win32についてはそこである程度勉強したのですが、部品を組み立てるような感覚で自由にできるので、下手にMFCに手を出すよりはマシかと思ったわけです。
別に、Doc/Viewモデルを使っていても、ファイルは好き勝手に読み書きできるよ。
勝手にfopen()して、一部だけ読み込んだりとか普通にやってる。
Doc/Viewモデルを使うとしても、
CDocument::OnOpenDocument(const char *pszFilename)
が呼び出されたときに、fopen()して、fread()して、どこか好きな場所に
データを読み込めばよい。
CDocumentの中に読み込まなくても、グローバル変数に読み込んでも、
CViewの中に読み込んでも、好きなクラスの中に読み込んでも良い。
本当に読み込んだかどうかは、MFCのフレームワークは全く感知しないので、
好き放題出来る。
MFCも、本等は好き放題出来る。
個人的には、大改造して使ってる。
>>663
お二人のようになれればいいのですけどね
単一ドキュメント複数ビューはできないわけじゃないよ。
DocTemplateを派生させる必要があるというだけ。
「MFCによるWindowsプログラミング」ISBN 475611749X
首都圏在住なら国会図書館で見てこい
ttps://iss.ndl.go.jp/books/R100000002-I000002930291-00
田舎住まいなら尼(ISBNで検索)で\32,580で売ってるから上司に頼んでこれ買ってもらえ
> 1つのDocに対して複数のViewなどをしたくても多分、設計上は出来ない。
CDocumentには、UpdateAllViews()という名前の関数があるように、
複数のビューを関連付けられるぞ。
>>662
わざわざDoc/Viewを選んでおいてDocクラスを放置するくらいなら、
印刷プレビューでも使わない限り、Doc/Viewを使わない形式で
CMainFrameとCChildViewだけを使うほうが楽だと思うけどな。
Jeffrey Richter とかの時代
Win32 API を、クラスにまとめたもの。
メニューバーも作れる
MFCって、まだ存在するのか
今でもMFC以外の選択肢はほぼ無いはずだが、
この本では、.net か、managed C++ か、interop か何かを使っていた。
でも結局、このやり方も、流行らなかったのか
MFC ではなかった気がする
> > 1つのDocに対して複数のViewなどをしたくても多分、設計上は出来ない。
>CDocumentには、UpdateAllViews()という名前の関数があるように、
>複数のビューを関連付けられるぞ。
スマソ。記憶違いがあった。
1つのDocに対して複数のViewは、一応は関連付けられる。
しかし、それはどれも1つのCFrameWndの中に入れておかないといけなくなって
しまっているため、WzEditorの「テキストの二重化」のように、
1つのテキストファイルの別の場所を複数のFrameWndの中に表示するという
ようなことが、MFCでは基本的に出来ないハズ。
表示させないで、データだけを元に、連続的に画像保存するってどうやるのかな？
例えば、ボタン１つで、円の位置を連続的に動かしたデータを、
それらをわざわざ画面に表示させないで、連続的に画像に保存したいんだけど、
やり方がわからない。
CreateCompatibleDC(NULL)とCreateDIBSectionだろう。DIBビットマップオブジェクトを作成し、DCでそれを選択し、DCで描画する形になる。
ありがとう、教えてもらったキーワードをググってみます。
プロパティの「フォントを使用して描画」をTrueにすると
コンボボックスの行の高さを無視して大きく描画されます。
XX明朝とXXゴシックが縦に重なって描画される感じです。
(ディスプレイ設定で拡大表示している場合のみ)
以前は普通に表示されていた気がするのですが。
良いアイデアがあればお願いします。
> C++Nativeの今風なGUIライブラリ作って欲しいわ
禿しく同意
それだけのことなのにそれをやらないマイクロソフト
何に置き換わったのでしょうか？
CMF…系のツーツバーやステータスバーでは保存＆復元されないようです。
m_pszProfileNameを初期化してる？
WinUI3には期待している。
レスサンクス
明示的には初期化はしていませんが
CWinApp::SetRegistryKey(...
を呼んでるのでその中でm_pszAppNameがセットされているようです。
CWinAppEx::LoadStateやCWinAppEx::SaveStateが勝手に呼ばれるはずだけど
VS2005で作ったソースをVS2019に移植する際
CWinAppをCWinAppEx
CToolbarをCMFCToolBar
のような作業をやったんだけど
CMainFrameからCFrameWnd::(Exなし)の関数を呼んでたのが原因でした
お恥ずかしい。レスくれた方、ありがとうございました。
WinUI 3がネイティブ
XAMLの部分はC++コードになる
ドル建てで売ってるからウクライナ侵攻の対ロ経済制裁の影響を受けて倒産とかはなさそうだな。
VisaやMasterのカード決済ができなくて、売れないのでは？ ロシア国外のWeb
サイトで決済して、ドルをロシアへ送金しようにも、SWIFTからの排除で銀行間
送金もできないし。
それもそうか〜。次の更新料支払いまで１０ヵ月近くあるけど、どうなるのかなぁ。
BCGライブラリは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 とか、こういうのは初心者がやるものじゃない。
たぶん、仕組みを理解するだけでも、10年以上掛かる
OnPaint()で描けばいいだけ
いつウインドウがinvalidateされるのか、アプリケーションプログラマが完璧に把握することはたぶんできないし
しても意味はあまりない
レスありがとうございます。
そういうものなのですね。
そういうものだと思って諦めます。
ありがとうございました。
>>708-710
そもそも、
cbmp = CBitmap::FromHandle(m_image);
で取得したものを
cbmp->DeleteObject();
で破棄しているのが原因では。
これだと1回目の描画のときにm_imageが破棄されて、
2回目以降は描画されないかと。
レスを投稿する
ニュース
- 【テレ朝】斎藤ちはるアナ、ラグビー日本代表主将・姫野和樹と真剣交際 元乃木坂の“朝の顔”結婚も視野に [鉄チーズ烏★]
- 「ドンドンショボくなる」大阪万博にまたまた“ガッカリ”報道、軟弱地盤のため「乗り物型」展示ゼロ [バイト歴50年★]
- 他候補者に「おい売国奴」拡声器で罵声、「凸」と称して迷惑行為も…東京15区補選で何が起きているのか [バイト歴50年★]
- 【テレビ】宇垣美里、疲れた時に足を向けるのは上野動物園「東京の方はパンダに並んでらっしゃるわって思うと勝てた気が…」 [湛然★]
- 【鉄道】女性「電車で隣に座ってくる男キモい」SNS“炎上”…男女で《賛否》真っ二つ、それぞれの言い分とは ★3 [ぐれ★]
- 【文春】「相合い傘で自宅マンションへ…」内田理央と人気YouTuberヒカルの寿司デート＆お泊まり愛“スクープ撮 [Ailuropoda melanoleuca★]
- 新入社員「俺さん見てたら安心してきました」
- いちいちバカの相手したくないんだが
- クマムシが人間の致死量の1000倍の放射線に耐えられる理由「遺伝子を破壊されるスピードを上回る速度で修復しているから」だった
- 新入社員にさっそく「ペニスケース（笑）」ってあだ名を付けられた
- (*´ω｀*) 白 い 光 の 中 に ケ ツ 並 み は 萌 え て
- なんかのバクで彼女が出来てもトーク力が壊滅過ぎて交際を続けられる自信がない