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
探検
MFC相談室 mfc23d.dll [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2016/09/21(水) 00:20:48.44ID:OfO+mYkd319デフォルトの名無しさん
2018/11/05(月) 10:35:49.97ID:cQLaagjN320デフォルトの名無しさん
2018/11/05(月) 12:07:09.35ID:iQgkSIfQ >>319
今は、_tcscpyを使ってもエラーが出るけどな
今は、_tcscpyを使ってもエラーが出るけどな
321デフォルトの名無しさん
2018/11/05(月) 12:15:02.40ID:mvX3Qu15 >>320
それはエラーではなくてセキュリティ上の警告では
それはエラーではなくてセキュリティ上の警告では
322デフォルトの名無しさん
2018/11/05(月) 12:20:01.12ID:iQgkSIfQ >>321
そうです。 _sを付けたのを使えって
警告の設定を変更しないとエラーになってコンパイルが通りません
それをプロパティの設定で、Unicodeからマルチバイトに切り替えてコンパイルしたんだけど、どうも
Unicodeのままでうまく切り替わらないようなんですよねえ。 どうなってるのか。 今は時間がないので
またあとでやってみますが
そうです。 _sを付けたのを使えって
警告の設定を変更しないとエラーになってコンパイルが通りません
それをプロパティの設定で、Unicodeからマルチバイトに切り替えてコンパイルしたんだけど、どうも
Unicodeのままでうまく切り替わらないようなんですよねえ。 どうなってるのか。 今は時間がないので
またあとでやってみますが
323デフォルトの名無しさん
2018/11/05(月) 12:26:42.35ID:mvX3Qu15324デフォルトの名無しさん
2018/11/05(月) 16:42:29.67ID:Lc5ZfJaA VS2017ですが、新規作成で、MFCアプリケーションで作った時、
新規作成途中に出てくるSDLのチェックをつけて作成したときと、はずして作成したときと両方してみました
すると、SDLつきの時は、_tcscpyはエラーになってコンパイルできませんが、
SDLをはずして新規作成したのものは、エラーにならずにコンパイルできて実行できます
デフォルトはSDLつきなので、コンパイルできません
次に、新規作成して出来上がったプロジェクトで、
メニューのプロジェクトから一番下のプロパティに入って、構成プロパティ、C/C++の全般にある
SDLチェックというところで、はい(/sdl) いいえ(/sdl-)を切り替えてやってみると、
この切り替えが動作せず、SDLのオン、オフが効きません。 プロジェクトの新規作成のときに設定したものが
残っていて、あとからここのプロパティで変更ができないようです
同じように、プロパティの構成プロパティの全般で、文字セットがデフォルトではUnicode文字セットを使用する
になってるのですが、これをマルチバイト文字セットを使用するにしても
Unicodeのままでマルチバイトにならないようです
バグですかねえ?
新規作成途中に出てくるSDLのチェックをつけて作成したときと、はずして作成したときと両方してみました
すると、SDLつきの時は、_tcscpyはエラーになってコンパイルできませんが、
SDLをはずして新規作成したのものは、エラーにならずにコンパイルできて実行できます
デフォルトはSDLつきなので、コンパイルできません
次に、新規作成して出来上がったプロジェクトで、
メニューのプロジェクトから一番下のプロパティに入って、構成プロパティ、C/C++の全般にある
SDLチェックというところで、はい(/sdl) いいえ(/sdl-)を切り替えてやってみると、
この切り替えが動作せず、SDLのオン、オフが効きません。 プロジェクトの新規作成のときに設定したものが
残っていて、あとからここのプロパティで変更ができないようです
同じように、プロパティの構成プロパティの全般で、文字セットがデフォルトではUnicode文字セットを使用する
になってるのですが、これをマルチバイト文字セットを使用するにしても
Unicodeのままでマルチバイトにならないようです
バグですかねえ?
325デフォルトの名無しさん
2018/11/05(月) 17:14:38.42ID:o5QGnfIr 新規のプロジェクトにマルチバイト使うのやめようぜ
326デフォルトの名無しさん
2018/11/05(月) 20:46:10.49ID:fgA77wSW327デフォルトの名無しさん
2018/11/05(月) 21:22:43.21ID:Lc5ZfJaA >>326
できました。多分それです。ありがとうございました
コードの編集画面の上にあるコンボボックスを見ると、Debugとx86になってるのですが、
その状態でプロパティを開くと、なぜか、x64になってました。
なのでプロパティ画面で、上にあるプラットフォームをアクティブ(Win32)に変えると、画面がおかしくなって
びっくりしましたが、画面の再描画ができなかっただけなようで、再びプロパティ画面を出して
アクティブ(Win32)を確認してから、マルチバイトやSDLの変更をしたら、ちゃんと動いたようです
プロパティ画面を開くときは、連動してないので必ず確認してから変更しないといけないということですね
ちなみになんとか誤魔化せないかと思って、 stdafx.h の最初に
#undef UNICODE
#undef_UNICODE
ってやってみたら、コンパイルまでは全部のcppファイルで出来たのですが、リンクで未解決エラーが出て
出来ませんでした
できました。多分それです。ありがとうございました
コードの編集画面の上にあるコンボボックスを見ると、Debugとx86になってるのですが、
その状態でプロパティを開くと、なぜか、x64になってました。
なのでプロパティ画面で、上にあるプラットフォームをアクティブ(Win32)に変えると、画面がおかしくなって
びっくりしましたが、画面の再描画ができなかっただけなようで、再びプロパティ画面を出して
アクティブ(Win32)を確認してから、マルチバイトやSDLの変更をしたら、ちゃんと動いたようです
プロパティ画面を開くときは、連動してないので必ず確認してから変更しないといけないということですね
ちなみになんとか誤魔化せないかと思って、 stdafx.h の最初に
#undef UNICODE
#undef_UNICODE
ってやってみたら、コンパイルまでは全部のcppファイルで出来たのですが、リンクで未解決エラーが出て
出来ませんでした
328デフォルトの名無しさん
2018/11/05(月) 22:12:55.20ID:fgA77wSW さすがにそれはおかしいのでVS2017再インストール推奨
329デフォルトの名無しさん
2018/11/05(月) 22:23:54.08ID:Lc5ZfJaA >>328
マジですか。 再インストしようかな
マジですか。 再インストしようかな
330デフォルトの名無しさん
2018/11/05(月) 23:46:35.28ID:2AHpASAJ _T() ?
331デフォルトの名無しさん
2018/11/06(火) 11:56:33.16ID:rqFrnjhJ >ちなみになんとか誤魔化せないかと思って
略
>リンクで未解決エラー
MessageBoxA と MessageBoxW とかを自分で書き分けてみると解決するはず
略
>リンクで未解決エラー
MessageBoxA と MessageBoxW とかを自分で書き分けてみると解決するはず
332デフォルトの名無しさん
2018/11/11(日) 14:34:30.31ID:vUUak6BF333デフォルトの名無しさん
2018/11/11(日) 17:52:29.57ID:96wp+TZd しねNG
334デフォルトの名無しさん
2018/12/07(金) 17:05:15.69ID:meFvbPH8 MFCのツールバーって、リバーのように、「ツールバーを固定する」の動作はできませんかね。
ユーザーがコマンドを選択したら、その場所から動かすことができなくなるようにしたいのですが。
ユーザーがコマンドを選択したら、その場所から動かすことができなくなるようにしたいのですが。
335デフォルトの名無しさん
2018/12/08(土) 16:28:45.38ID:S81QsiH/ subclass化してメッセージループトラップしてmoveをにぎりつぶす
336デフォルトの名無しさん
2018/12/17(月) 19:07:24.59ID:Fq49NMNr HWND hWnd はできるけど、
HDC hDC って、別アプリ(別プロセス)に渡して、書き込ませることは出来ないの?
HDC の識別番号が、プロセスごとに別の「名前空間」みたいなことになってるのかな。
HDC hDC って、別アプリ(別プロセス)に渡して、書き込ませることは出来ないの?
HDC の識別番号が、プロセスごとに別の「名前空間」みたいなことになってるのかな。
337デフォルトの名無しさん
2018/12/17(月) 19:18:47.70ID:Fq49NMNr 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 は、プロセス・プライベートだって、書いてるけど、
たまたますごいことみつけちゃったんだ・・・実は。
みんな知ってる?
That is, only the process that created the GDI object can use the object handle.
↑によれば、HDC は、プロセス・プライベートだって、書いてるけど、
たまたますごいことみつけちゃったんだ・・・実は。
みんな知ってる?
338デフォルトの名無しさん
2018/12/18(火) 08:47:01.21ID:G1V4hdx+ 実は、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()
によって直接書き込ませることが出来ることを確認済み。
垣根を越えて渡せるんだ。プロセス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()
によって直接書き込ませることが出来ることを確認済み。
339デフォルトの名無しさん
2018/12/18(火) 08:56:36.56ID:G1V4hdx+ この話には続きがある。
Ubuntu Linux の Wine Emulator 3.2 で実験してみると、PrintWindow() が上手くいかないらしい。
なので、誰かに直して欲しい、と言うこと。
直してクレクレ。
Ubuntu Linux の Wine Emulator 3.2 で実験してみると、PrintWindow() が上手くいかないらしい。
なので、誰かに直して欲しい、と言うこと。
直してクレクレ。
340デフォルトの名無しさん
2018/12/18(火) 11:55:37.33ID:/M0/bFGF341デフォルトの名無しさん
2018/12/20(木) 16:21:01.93ID:IGyhJ3NX >>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 のマシンでの話。
さらに実験してみたところ、プロセス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 のマシンでの話。
342デフォルトの名無しさん
2018/12/20(木) 17:27:58.15ID:t8x/0UH1 なお予告なく変更されることがあります
343デフォルトの名無しさん
2019/02/01(金) 14:28:07.62ID:Y7K3gTaF MFC アプリケーションのツールバーを移動すると、ツールバーの移動枠とマウスカーソルの位置が離れる
https://social.msdn.microsoft.com/Forums/ja-JP/b47f8e8c-318b-4e7b-a81e-b97f26bffdc0/mfc
https://social.msdn.microsoft.com/Forums/ja-JP/b47f8e8c-318b-4e7b-a81e-b97f26bffdc0/mfc
344デフォルトの名無しさん
2019/02/20(水) 12:07:37.06ID:6ZQ0VW2w スタティックビルドがうまくできたらうれしかった
345デフォルトの名無しさん
2019/03/04(月) 21:22:00.31ID:w7LKY+n1 ウインドウを2枚用意して、片方を表に(上に)表示して、もう片方は裏にして見えないようにしている。で、裏の見えない方を
書き換えて、表のウインドウと入れ替えて、新しい描画のウインドウを出すということをしたいのです
裏メモリに書き込んで一瞬でモニターに出すという普通のやつをウインドウでします
裏でウインドウで書き込むとき、HIDE状態では書き込めないので、MINIMIZEの状態では出来ることがわかったので
そうしているのですが、問題はそれを最大化するときに、どうしても描画に時間がかかるというか、一瞬では出来ないのです
なので、アクティブ化せずに裏で最大化、あるいは、RESTOREする方法を探しているのですが、
APIのShowWindowとかだと、RESTOREもMAXIMIZEも必ずアクティブ化してしまうのですがいい方法はないでしょうか
いろいろとやってみて、2枚のウインドウに違う絵をかいておいて、片方をHIDE、片方をSHOWして、このHIDEと
SHOWと切り替えるってのが一番きれいに切り替わるようなのですが、書き込むとき、HIDEでは書き込めずに
MINIMIZEして書き込まないといけないので、MINIMIZEして書き込んだウインドウを表に出さずに大きくしてHIDE状態に出来れは
いいのですが
書き換えて、表のウインドウと入れ替えて、新しい描画のウインドウを出すということをしたいのです
裏メモリに書き込んで一瞬でモニターに出すという普通のやつをウインドウでします
裏でウインドウで書き込むとき、HIDE状態では書き込めないので、MINIMIZEの状態では出来ることがわかったので
そうしているのですが、問題はそれを最大化するときに、どうしても描画に時間がかかるというか、一瞬では出来ないのです
なので、アクティブ化せずに裏で最大化、あるいは、RESTOREする方法を探しているのですが、
APIのShowWindowとかだと、RESTOREもMAXIMIZEも必ずアクティブ化してしまうのですがいい方法はないでしょうか
いろいろとやってみて、2枚のウインドウに違う絵をかいておいて、片方をHIDE、片方をSHOWして、このHIDEと
SHOWと切り替えるってのが一番きれいに切り替わるようなのですが、書き込むとき、HIDEでは書き込めずに
MINIMIZEして書き込まないといけないので、MINIMIZEして書き込んだウインドウを表に出さずに大きくしてHIDE状態に出来れは
いいのですが
346デフォルトの名無しさん
2019/03/05(火) 03:38:03.26ID:VDry4yCP MemoryDCに書き込め
347デフォルトの名無しさん
2019/03/07(木) 10:13:48.09ID:wL/Z2Jw6 MFCのSDIアプリケーションで、PCを一定時間操作しなかったときに、
「更新中」のダイアログをDoModal()で出して、内部の情報を更新する動作を作っています。
更新処理はダイアログの中で別スレッドで行っていて、
タイマーで定期的にスレッドを監視して、終わっていたらEndDialog()で閉じます。
他の操作を不可にした上でキャンセルは可能にするために、このように作りました。
ここまでは問題なく動いているのですが、
アプリケーションがアクティブでないときにこの更新処理が走ると、
「更新中」のダイアログが閉じられた後に、アクティブ表示になってしまいます。
表示がアクティブになるだけで、フォーカスまでは奪いません。
二つのアプリケーションがアクティブ表示になってしまう状態です。
不思議に思ってMFCのソースを追いかけたところ、
CFrameWndのOnEnable()やOnActivate()やOnNcActivate()で
WF_STAYACTIVEのフラグを使ってアクティブ表示を強制するような仕組みがあり、
この中の処理を通った結果、アクティブ表示になってしまうようでした。
どうしてWF_STAYACTIVEに引っかかるのかなど、細かい流れは追い切れていませんが、
アクティブでないときに裏でダイアログが出て、その後自動で閉じるような動きを、
CFrameWndは想定していないということになりますでしょうか。
見た目のだけの問題ではありますが、CFrameWndの仕組みを保ったまま、
この現象を回避する方法はありませんでしょうか。
「更新中」のダイアログをDoModal()で出して、内部の情報を更新する動作を作っています。
更新処理はダイアログの中で別スレッドで行っていて、
タイマーで定期的にスレッドを監視して、終わっていたらEndDialog()で閉じます。
他の操作を不可にした上でキャンセルは可能にするために、このように作りました。
ここまでは問題なく動いているのですが、
アプリケーションがアクティブでないときにこの更新処理が走ると、
「更新中」のダイアログが閉じられた後に、アクティブ表示になってしまいます。
表示がアクティブになるだけで、フォーカスまでは奪いません。
二つのアプリケーションがアクティブ表示になってしまう状態です。
不思議に思ってMFCのソースを追いかけたところ、
CFrameWndのOnEnable()やOnActivate()やOnNcActivate()で
WF_STAYACTIVEのフラグを使ってアクティブ表示を強制するような仕組みがあり、
この中の処理を通った結果、アクティブ表示になってしまうようでした。
どうしてWF_STAYACTIVEに引っかかるのかなど、細かい流れは追い切れていませんが、
アクティブでないときに裏でダイアログが出て、その後自動で閉じるような動きを、
CFrameWndは想定していないということになりますでしょうか。
見た目のだけの問題ではありますが、CFrameWndの仕組みを保ったまま、
この現象を回避する方法はありませんでしょうか。
348デフォルトの名無しさん
2019/03/07(木) 11:03:18.49ID:MaxgRiSY ダイアログの前にアクティブだったウィンドウをアクティブにしてから閉じる
349sage
2019/03/12(火) 23:39:31.92ID:5NMUaJ/A VS2019のリリースノートでのMFCへの言及は、廃止予定の機能一覧中にいくつかあるのみ。
MFCをバリバリ使っているわけではないけど、なんか悲しい。
MFCをバリバリ使っているわけではないけど、なんか悲しい。
350デフォルトの名無しさん
2019/09/19(木) 20:20:47.92ID:h0nmK2Rt 空のソリューションを作って既存のAとBのMFCダイアログベースのプロジェクトを追加して、リソースビューでAにBのダイアログをコピペしたらIDが同じという警告が出た。
AのダイアログからBのダイアログをDoModalで呼び出す内容なんですが、ビルドも実行させても問題ないように見えるが大丈夫なんでしょうか?
AのダイアログからBのダイアログをDoModalで呼び出す内容なんですが、ビルドも実行させても問題ないように見えるが大丈夫なんでしょうか?
351デフォルトの名無しさん
2019/11/12(火) 03:43:11.18ID:dQMkkNV/ 数年前に作ったダイアログのコンボボックスの初期値が反映されなくなってたんだが
CComboBox:: SelectStringの第一引数nStartAfterを0から-1にしたら動作した
でもなんでやろ?0でよさげなのに
CComboBox:: SelectStringの第一引数nStartAfterを0から-1にしたら動作した
でもなんでやろ?0でよさげなのに
352デフォルトの名無しさん
2020/02/27(木) 02:47:52.87ID:HQmHUU7r いまやCDCといえばアメリカ疾病対策センター(Centers for Disease Control and Prevention)だね
353デフォルトの名無しさん
2020/02/27(木) 03:05:08.52ID:CxyJejD6 >>349
MSは傲慢になっているだけ。
MSは傲慢になっているだけ。
354デフォルトの名無しさん
2020/02/27(木) 15:15:55.59ID:G6pyHvdg355デフォルトの名無しさん
2020/03/18(水) 18:37:21.32ID:7DDJtRdm ローカルディスクの中で、MFCのCWinやCViewなどのソースは見られるのですが、
AfxGetApp()のソースコードだけが見つかりません。
どこにあるのでしょうか?
AfxGetApp()のソースコードだけが見つかりません。
どこにあるのでしょうか?
356デフォルトの名無しさん
2020/03/18(水) 18:37:49.10ID:7DDJtRdm357デフォルトの名無しさん
2020/03/18(水) 22:20:02.18ID:rOcYLXbY あなたの心のなかに
358蟻人間 ◆T6xkBnTXz7B0
2020/03/18(水) 22:54:37.77ID:k3A1kOjX デバッグすれば見つかると思う。
多分inline だからヘッダにあると。
多分inline だからヘッダにあると。
359デフォルトの名無しさん
2020/03/19(木) 02:54:18.48ID:VRFqiqhe >>358
拡張子を指定せずに、MFCのソースを含んだ全てのファイルを検索にかけたけど、
AfxGetApp()の定義だけは見つからなかった。
見落としは有るかもしれないが、当然、*.c, *,cpp, *.h, *.inl は全てチェックした。
拡張子を指定せずに、MFCのソースを含んだ全てのファイルを検索にかけたけど、
AfxGetApp()の定義だけは見つからなかった。
見落としは有るかもしれないが、当然、*.c, *,cpp, *.h, *.inl は全てチェックした。
360デフォルトの名無しさん
2020/03/19(木) 16:23:04.81ID:iZLxCMVs361デフォルトの名無しさん
2020/03/22(日) 02:44:03.68ID:HvrypJyW362デフォルトの名無しさん
2020/04/16(木) 02:46:25.76ID:EfWE4HPw 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 に対して呼び出している
に過ぎません。
これはどういうことでしょうか??
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デフォルトの名無しさん
2020/04/16(木) 10:10:01.52ID:przIFznP そりゃ発行済でキューに入ったメッセージはそのままになる罠
自分で読んでしまえば消えるだけのこと
自分で読んでしまえば消えるだけのこと
364デフォルトの名無しさん
2020/04/16(木) 10:35:53.84ID:midwC3ZA >>362
https://docs.microsoft.com/ja-jp/cpp/mfc/reference/cwnd-class?view=vs-2019#killtimer
こっちには削除されないと書いてあるので、昔のMFCの説明が間違っているのでは
https://docs.microsoft.com/ja-jp/cpp/mfc/reference/cwnd-class?view=vs-2019#killtimer
こっちには削除されないと書いてあるので、昔のMFCの説明が間違っているのでは
365デフォルトの名無しさん
2020/04/16(木) 14:17:36.18ID:EfWE4HPw >>363
ただ、WM_PAINT や WM_TIMER は、他のメッセージとは異なる処理を
されています。
Win32のメッセージキューは、1つのキューに見えるものが、OSの内部では
複数本持っているか、描画のDirtyフラグなどでなんらかの特殊な扱いを
しているようです。
ただ、WM_PAINT や WM_TIMER は、他のメッセージとは異なる処理を
されています。
Win32のメッセージキューは、1つのキューに見えるものが、OSの内部では
複数本持っているか、描画のDirtyフラグなどでなんらかの特殊な扱いを
しているようです。
366デフォルトの名無しさん
2020/04/16(木) 14:26:57.93ID:przIFznP WM_PAINTは優先度最も低いので常に後ろに行くってどっかで観た
367デフォルトの名無しさん
2020/04/16(木) 14:46:13.29ID:EfWE4HPw 実際には、WM_TIMER は、WM_PAINT以上に優先順位が低いです。
なので、PeekMessage()しても、他のメッセージがあれば WM_TIMERメッセージを
拾えるかどうかは余り定かではないと思います。
もしかすると、その場合には KillTimer()の処理に置いては、WM_TIMERが
メッセージキューに「ポストされて無い」とみなされるのかもしれません。
解釈が難しいです。
なので、PeekMessage()しても、他のメッセージがあれば WM_TIMERメッセージを
拾えるかどうかは余り定かではないと思います。
もしかすると、その場合には KillTimer()の処理に置いては、WM_TIMERが
メッセージキューに「ポストされて無い」とみなされるのかもしれません。
解釈が難しいです。
368デフォルトの名無しさん
2020/04/28(火) 14:27:43.22ID:lEsMK9s4 いやー仕事でいじることになったんだけどぜんっぜんわからんわなんじゃこりゃ
独自定義の型山盛りでおまけにドキュメントも少ない。いやこれめちゃくちゃ難易度高くない
独自定義の型山盛りでおまけにドキュメントも少ない。いやこれめちゃくちゃ難易度高くない
369デフォルトの名無しさん
2020/04/28(火) 16:08:22.11ID:rYh8BUkN 俺は昨年からC#のwinformに移行してメチャ楽勝です。
もうMFCに戻りたくないです。
でもthreadで動かすのはこっちの方が分かりやすい。
もうMFCに戻りたくないです。
でもthreadで動かすのはこっちの方が分かりやすい。
370デフォルトの名無しさん
2020/04/28(火) 22:00:28.21ID:jwgdFc00 >>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
を今でも使ってる。
仕事でってことだが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
を今でも使ってる。
371デフォルトの名無しさん
2020/05/08(金) 00:23:39.44ID:IXHJYCls だめだー格闘したけどビルドすらできない
どうもvc++6.0以前のやつはvc2005以降とだいぶ違う?変換でエラー出るどころか文法もエラー出まくりでどうしようもならん。古い開発環境なんて無いし
どうもvc++6.0以前のやつはvc2005以降とだいぶ違う?変換でエラー出るどころか文法もエラー出まくりでどうしようもならん。古い開発環境なんて無いし
372デフォルトの名無しさん
2020/05/08(金) 09:59:42.32ID:oIDbptWL _s 使えとかいっぱいでてうざいのは判る
373デフォルトの名無しさん
2020/05/08(金) 12:48:05.49ID:IXHJYCls それは確かプロパティで無視するようにできたよーな
374デフォルトの名無しさん
2020/05/08(金) 13:09:30.80ID:V0PZ5eCc 無視したら、当時の脆弱性を認めることにはなるけどな。
あと forのカッコの中で宣言したループ変数のスコープとかも、6の時代とは違ったと思う。
あと forのカッコの中で宣言したループ変数のスコープとかも、6の時代とは違ったと思う。
375デフォルトの名無しさん
2020/05/08(金) 16:54:57.20ID:iOEjZYuS 判らないなら VC6 使うべき
上位互換でも VC6 モードにするべき
上位互換でも VC6 モードにするべき
376デフォルトの名無しさん
2020/05/08(金) 22:24:15.90ID:kRmZw1lO >>374
はぁ?
はぁ?
377デフォルトの名無しさん
2020/05/09(土) 05:00:08.42ID:TVkAIoUw MSと契約してたらVS6は手に入るはずだが。
378デフォルトの名無しさん
2020/05/09(土) 05:13:30.06ID:wZuQoznS XPまでしかインストールできなかった気がする
379デフォルトの名無しさん
2020/05/09(土) 06:25:10.22ID:J9L1oHhf 仮想使えば?
380デフォルトの名無しさん
2020/05/09(土) 07:40:51.77ID:TBKnesgm 古いWindowsならここにあるぞ
https://winworldpc.com/library/operating-systems
https://winworldpc.com/library/operating-systems
381デフォルトの名無しさん
2020/05/09(土) 09:44:57.53ID:3rxWY8lS MSDN なら XP も VS6 も入手してるはず
382デフォルトの名無しさん
2020/05/09(土) 09:47:30.21ID:3rxWY8lS383デフォルトの名無しさん
2020/05/09(土) 13:24:52.80ID:740LYA9f えぇこんなサイトあるのと思ってググったけど著作権的にグレイゾーンというかブラックでは
384デフォルトの名無しさん
2020/05/09(土) 16:09:17.18ID:TBKnesgm ちゃんと線引きしてるよ
https://winworldpc.com/product/windows-xp/final
https://winworldpc.com/product/windows-xp/final
385デフォルトの名無しさん
2020/05/09(土) 19:31:34.01ID:740LYA9f 要するにmicrosoftが黙認というか放置してるだけというか
権利を放棄してないのは確かだから使うならこっそりやりなさいよくらいのレベルなのかね
いずれにせよグレーなのは間違いない。仕事じゃ使えないね
権利を放棄してないのは確かだから使うならこっそりやりなさいよくらいのレベルなのかね
いずれにせよグレーなのは間違いない。仕事じゃ使えないね
386デフォルトの名無しさん
2020/05/09(土) 21:03:53.55ID:TBKnesgm 仕事に使うって発想はなかったw
MSDNのCDをiso化して保存してるからな
MSDNのCDをiso化して保存してるからな
387デフォルトの名無しさん
2020/05/09(土) 23:05:48.18ID:VZmAPRaM 仕事につかえないっ(キリっ)て話なら
純正のVC6でももう使うなよωって思うωωω
純正のVC6でももう使うなよωって思うωωω
388デフォルトの名無しさん
2020/05/09(土) 23:40:20.22ID:TVkAIoUw 仕事したことない子供かよw
389デフォルトの名無しさん
2020/05/10(日) 00:08:40.31ID:lS9VwhWL 仕事で使うなら再現可能性は大切だからな
従業員が違法行為をしていたら、懲戒免職で済めば良い方で
損害賠償請求されたっておかしくはない
従業員が違法行為をしていたら、懲戒免職で済めば良い方で
損害賠償請求されたっておかしくはない
390デフォルトの名無しさん
2020/05/10(日) 08:12:18.17ID:HcnV9o5e MFC保守なんていう面白そうな案件を当時を知らない若者にやらせるとかどうかしてる。
391デフォルトの名無しさん
2020/05/10(日) 08:30:33.92ID:Pcmn53iK 隔離VMで昔を懐かしむなんて楽しみ方はしてるよ
今のハードウエアなら神速かと思いきや期待ほどではない
今のハードウエアなら神速かと思いきや期待ほどではない
392デフォルトの名無しさん
2020/05/10(日) 08:46:41.09ID:B13Er8N9 でもネットに情報一杯あるから苦労でもないね。
393デフォルトの名無しさん
2020/05/10(日) 15:21:27.47ID:JjPR8mXC 過疎スレなのに無駄に伸びすぎ
394デフォルトの名無しさん
2020/05/10(日) 16:01:33.51ID:nv4IBqVl 若かった頃を思い出すノスタルジースレ
395デフォルトの名無しさん
2020/05/10(日) 18:00:45.83ID:Pcmn53iK OS/2 1.0なんか楽しくて仕方なかった
396デフォルトの名無しさん
2020/05/11(月) 22:03:48.97ID:qSq1/7+a mfcのコードってどれもこれもハンガリアンな印象なんだけど新し目のmfcコードだとその悪習から脱却されてたりする?
前世紀から連綿と受け継がれてきたようなのしかまだ見たことがないんだけど。いやそもそも新し目のmfcなんて存在するのかという問題もあるが
前世紀から連綿と受け継がれてきたようなのしかまだ見たことがないんだけど。いやそもそも新し目のmfcなんて存在するのかという問題もあるが
397デフォルトの名無しさん
2020/05/11(月) 22:19:49.49ID:lKGFrGqg べつにハンガリアンが嫌なら自分のコードでは使わなきゃいいだけ。
使うライブラリのネーミングルールが気に入らないとか言うのは相当偏屈な奴だろう。
使うライブラリのネーミングルールが気に入らないとか言うのは相当偏屈な奴だろう。
398デフォルトの名無しさん
2020/05/14(木) 05:37:45.19ID:IJMYY156 型が分からなくても平気な人はプログラマに向いてない。
399デフォルトの名無しさん
2020/05/14(木) 09:52:03.18ID:tvxDWcUo ハンゲリアンは百害あって一利なし
400デフォルトの名無しさん
2020/05/14(木) 10:26:21.35ID:IJMYY156 UNIX勢のGUIが不安定だった頃、
MFCアプリが高機能てんこ盛りで安定してたのはハゲリアンのおかげである。
MFCアプリが高機能てんこ盛りで安定してたのはハゲリアンのおかげである。
401デフォルトの名無しさん
2020/05/14(木) 18:37:36.49ID:8JWtj6XY APIのリファレンスの記述用としては秀逸だと思うけどなあ
402デフォルトの名無しさん
2020/05/15(金) 07:34:00.84ID:QqRlTuRs MFC製アプリはMSに数兆円の利益をもたらした。
ハゲリンは100害あっても兆利あった。
ハゲリンは100害あっても兆利あった。
403デフォルトの名無しさん
2020/05/15(金) 11:29:35.02ID:QE59VEMD > 安定してたのはハゲリアンのおかげ
関係ないと思うが
関係ないと思うが
404デフォルトの名無しさん
2020/05/15(金) 18:17:59.73ID:sHW7IJmG 理由も書かずに否定した気になってるという謎の万能感の持ち主w
405デフォルトの名無しさん
2020/05/15(金) 19:43:56.07ID:mq4q1sRg アンガリアン
406デフォルトの名無しさん
2020/05/16(土) 06:06:50.03ID:VIJekRbB407デフォルトの名無しさん
2020/05/16(土) 06:23:09.44ID:Os/XxFcn >>406
何の話をしてんの?
何の話をしてんの?
408デフォルトの名無しさん
2020/05/18(月) 10:37:08.40ID:pyEiFhlF 90年代に書かれたのを最新のvisual studioで動くようにしてという仕事が降ってきて絶望している
409デフォルトの名無しさん
2020/05/18(月) 10:39:08.65ID:XEI7YtdQ 全面的に描き治しになりますって見積もり出せ
410デフォルトの名無しさん
2020/05/18(月) 15:47:40.36ID:0/z3ChKA 普通に動くんじゃないの?
411デフォルトの名無しさん
2020/05/18(月) 16:40:43.57ID:E4/AoY55 90年台のVCだとfor文の初期化式のスコープでまず引っかかりそう
412デフォルトの名無しさん
2020/05/18(月) 18:08:37.98ID:u5vOaLys ソースコードの量より多いワーニングが出そう
413デフォルトの名無しさん
2020/05/18(月) 19:31:30.34ID:knarOBVn 自分の作ったプログラム(MFC使用)でVC++4.0からVC++2008の移行を行ったけど、
(文法的に)エラー・ワーニングが出るところを機械的に修正していくだけで、プログラ
ムのアルゴリズムや構造を変えなければならないようなところは無かったから、
それほど手間はかからなかったよ。
(文法的に)エラー・ワーニングが出るところを機械的に修正していくだけで、プログラ
ムのアルゴリズムや構造を変えなければならないようなところは無かったから、
それほど手間はかからなかったよ。
414デフォルトの名無しさん
2020/05/18(月) 20:32:49.43ID:u5vOaLys 2008はな。
でも今や2008もサポート停止。
でも今や2008もサポート停止。
415デフォルトの名無しさん
2020/05/19(火) 18:02:40.68ID:kOq4o5Tk416デフォルトの名無しさん
2020/05/19(火) 20:37:52.56ID:AC8jjF95417デフォルトの名無しさん
2020/05/20(水) 14:51:41.59ID:Mh8h++lf >>406
ハゲリン
ハゲリン
418デフォルトの名無しさん
2020/05/23(土) 20:13:33.99ID:a3FMTFIp IE用の古いCHtmlViewで表示されているページを拡大縮小することは可能でしょうか?
MFCIEというサンプルもビルドしてみたのですが、CTRL+ + などは効かないようです。
プログラムからコントロールできるのでしょうか?
MFCIEというサンプルもビルドしてみたのですが、CTRL+ + などは効かないようです。
プログラムからコントロールできるのでしょうか?
419デフォルトの名無しさん
2020/05/24(日) 05:40:28.33ID:J6IYypHJ MFCでAppWizardでひな形を作って色々試してるのですが、ツールバーのアイコンって
どうすればいいのでしょうか??
visual studio imaging libraryのアイコンを試しにツールバーのボタンに追加(コピー&ペースト)しようとしても背景がおかしくなります。
imaging libraryのアイコンが32bppのBGRAで、ツールバーのアイコンが24bpp。
どうすればいいのでしょうか??
visual studio imaging libraryのアイコンを試しにツールバーのボタンに追加(コピー&ペースト)しようとしても背景がおかしくなります。
imaging libraryのアイコンが32bppのBGRAで、ツールバーのアイコンが24bpp。
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【前橋市】小川晶前市長とラブホテルで打ち合わせをした54歳男性職員を停職処分 今月末で依願退職するという [シャチ★]
- 【おこめ券】鈴木農相 米価維持の意図「一切ない」★2 [ぐれ★]
- 【埼玉】「無免許で高速道路で事故」トラックの追突事故で10代男性死亡 無免許過失運転致死の疑いでトルコ国籍の男(22)逮捕 戸田市 [ぐれ★]
- 【日銀総裁】賃金に上昇圧力 人手不足で労働市場逼迫 [蚤の市★]
- バリ島で男子生徒ら集団万引きか、防犯カメラ映像が拡散 京都の大谷中学・高校が「窃盗行為」謝罪★7 [七波羅探題★]
- レーダー照射問題で日本のホットライン呼びかけに中国応じず…2023年3月に開設も機能せず [♪♪♪★]
- 高市早苗「竹島は日本領土」 [834922174]
- (´・ω・`)おならっていろんな音出るよね
- 【悲報】ユーロ円182円突破 史上最高値更新 [115996789]
- 俺は人間国宝
- 【速報】1ポンド210円で日英GDP逆転(残り1.5円)...世界6位の経済規模に転落 [237216734]
- おさかなさんあつまれえ
