■MFC相談室 mfc17d.dll■
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/11/21(火) 10:38:31前スレ
■MFC相談室 mfc16d.dll■
http://pc8.2ch.net/test/read.cgi/tech/1146117893/
0076デフォルトの名無しさん
2006/12/01(金) 00:49:13であれば、Viewをdeleteする必要はない。
FrameとViewが正しく結合されていれば、exe側Frameが閉じられる際に自動で削除される。
CView::PostNCDestroy()参照。
0077デフォルトの名無しさん
2006/12/01(金) 01:11:51うん
0078デフォルトの名無しさん
2006/12/01(金) 01:18:01例えば開発時に、EXEがReleaseでDLLがDebugだとすると。
メモリ管理のランタイムが別になるんで、EXEでnewしたメモリをDLLで開放しようとすると、
当然そんなメモリは管理してないから落ちてしまうと。
0079デフォルトの名無しさん
2006/12/01(金) 01:27:38問題ないんじゃないの?
77は根拠を示すべし。
0080デフォルトの名無しさん
2006/12/01(金) 06:53:15別のアプリで確保したメモリを別のアプリで解放できるか?って話しになるんじゃない?
0081デフォルトの名無しさん
2006/12/01(金) 09:12:040082デフォルトの名無しさん
2006/12/01(金) 10:26:11バージョンが同じでも、MFCをスタティックリンクしてるとダメだよ。
0083デフォルトの名無しさん
2006/12/01(金) 14:28:49008455
2006/12/01(金) 19:42:03そんな感じです。というより全く同じですね。
VC6ではやむを得ないと思います。
>>65-67
http://www.codeproject.com/docking/
http://www.codeguru.com/cpp/w-d/docking/
スクリーンショット見た感じ、↓のが参考になるかも。
http://www.codeguru.com/cpp/w-d/docking/article.php/c1447/
http://www.codeguru.com/cpp/w-d/docking/article.php/c1451/
http://www.codeproject.com/docking/sizecbar.asp
>>62&>>72
どっかのスレで参考になる文献はないかと聞かれたから
URL貼ったんだが全く読んでないんだな。
考えられる原因の一つは、delete this;して自殺するクラスがあるということ。
CFrameWndやCViewがまさにそういうクラスなのでその可能性があるんじゃない?
76も答えてくれてる通り。
0085デフォルトの名無しさん
2006/12/02(土) 16:41:12MDIから別プロジェクトの画面を子画面として表示させたいのですが、
どういう風に作ればいいのでしょうか。
0086デフォルトの名無しさん
2006/12/02(土) 17:26:410087デフォルトの名無しさん
2006/12/02(土) 17:32:47008849
2006/12/03(日) 13:05:02やはりこういう派生になるのですね。安心しました。
VC7でも同じ問題が発生するようで、VC2005じゃないと直ってないようです。
008940
2006/12/03(日) 16:05:47の続きで、Viewの差し替えは、Viewクラスでのメニューイベントハンドラーで
CWinApp* myapp=AfxGetApp();
CDocTemplate* mydoctemp=(CDocTemplate*)RUNTIME_CLASS(CDocTemplate);
POSITION myps=myapp->GetFirstDocTemplatePosition();
mydoctemp=myapp->GetNextDocTemplate(myps);//テンプレートリストの1番目を選択するイテレータ
mydoctemp=myapp->GetNextDocTemplate(myps);//テンプレートリストの2番目を選択するイテレータ
mydoctemp->OpenDocumentFile(NULL);
でドキュメントテンプレートに入れられた2番目のViewを新規子ウィンドウで表示できたよ
0090デフォルトの名無しさん
2006/12/04(月) 13:59:24ソフトを書いていたんですが、タブに重ねたリストビューの列サイズを操作すると
リストビューの表示が乱れる現象が出てしまいました。
http://www.uploda.org/uporg604606.zip.html
サンプルプロジェクトです。VC2005で作りました。
http://www.uploda.org/uporg604603.gif
1つめのリスト。こういう感じで一番右の列境界をタブの外へ右にドラッグすると
スクロールバーが現れます。通常の動作です。
http://www.uploda.org/uporg604604.gif
2つめのリスト。1つ目と同じく一番右の列境界を右へドラッグするとスクロールバー
が現れるタイミングで表示が乱れます。
どうして2つ目のリストでのみ表示が乱れるのか悩んだ結果、ダイアログのリソース
定義ファイル中の、
> CONTROL "",IDC_LIST1,"SysListView32",LVS_REPORT | (以下略)
> CONTROL "",IDC_TAB1,"SysTabControl32",0x0,7,7,173,186
> CONTROL "",IDC_LIST2,"SysListView32",LVS_REPORT | (以下略)
を
> CONTROL "",IDC_LIST1,"SysListView32",LVS_REPORT | (以下略)
> CONTROL "",IDC_LIST2,"SysListView32",LVS_REPORT | (以下略)
> CONTROL "",IDC_TAB1,"SysTabControl32",0x0,7,7,173,186
と順番を入れ替えると表示が乱れなくなりました。逆に、タブの行をリストの先頭
に持っていくと今度は両方のタブでリストの表示が乱れるようになります。
結果オーライといえばそれまでなんですが、どうしてこれで問題が解決するのか納得が
いきません。リソース中の定義順が何に影響しているのでしょうか?
0091デフォルトの名無しさん
2006/12/04(月) 14:05:470092デフォルトの名無しさん
2006/12/04(月) 14:46:26Zオーダーの問題じゃね?
0093デフォルトの名無しさん
2006/12/04(月) 16:30:03009490
2006/12/04(月) 22:53:30リソース定義の順番がZオーダになるというのが将来にわたって保障された
仕様なのかどうかが疑問なので、コントロールを重ねる場合のZオーダは
きちんとSetWindowPosでコード中に書いておくことにします。
0095デフォルトの名無しさん
2006/12/06(水) 06:13:15HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\MUICache
に VS_VERSION_INFO の FileDescription の値が書き込まれてしまいます。
FileDescription を消しても実行ファイル名が変わりに書き込まれてしまいます。
どうしたら書き込まないように出来るでしょうか?
0096デフォルトの名無しさん
2006/12/06(水) 10:01:560097デフォルトの名無しさん
2006/12/06(水) 23:59:45PASVモードを使ったときにどのポートが使われているかというのは
どうやって取得すれば良いでしょうか?
0098デフォルトの名無しさん
2006/12/12(火) 21:25:29このリストの特定セルだけ背景色を変えるにはどうしたら良いですか?
ステータス値に応じてセルの色が変わるような機能を実現したいのですが……
0099デフォルトの名無しさん
2006/12/12(火) 21:26:36各コントロール毎に違う背景色を設定したいのですがどのようにすればよいのでしょうか?
OnCtlColor()メソッド内でコントロールの判定ができればよいと思うのですが・・・。
どなたかご教授の程よろしくお願い致します。
OSはWinXP SP2、開発環境はVC++ 2005です。
0100デフォルトの名無しさん
2006/12/12(火) 21:45:51カスタムドローじゃねぇの?
>>99
普通にウィンドウハンドル比べたらどうよ?
010198
2006/12/12(火) 21:47:33無知で申し訳ないのですが、カスタムドローとはどのようなものですか?
0102デフォルトの名無しさん
2006/12/12(火) 21:55:03http://www.google.co.jp/search?hl=ja&safe=off&c2coff=1&q=%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%83%89%E3%83%AD%E3%83%BC+CListCtrl&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
010398
2006/12/12(火) 21:57:44すみません、自分で検索するべきでした
どうもありがとうございました
010499
2006/12/12(火) 22:00:20レスありがとうございます。
if(GetDlgItem(IDC_STATIC_COLOR1) == pWnd){
AfxMessageBox(L"一番目のコントロール");
}
//以降コントロールの数分else if
試しにこんなコードでやってみたのですが引っかかりませんでした。
比較処理が悪いのでしょうか?
0105デフォルトの名無しさん
2006/12/12(火) 22:06:07まあ、駄目だったら、そもそもIDC_STATIC_COLOR1が本当にそいつの直下に配置してあるコントロールなのかどうなのか
ってところがあやしいんじゃね?
010699
2006/12/12(火) 22:22:41OnInitDialog内で
GetDlgItem(IDC_STATIC_COLOR1)->SetWindowText("あいう");
で文字は表示されたので問題はないと思うのですが・・・。
もう少し調べてみます。
010799
2006/12/12(火) 22:31:54すみません、教えていただいた
pWnd->m_hWnd == GetDlgItem(IDC_STATIC_COLOR1)->m_hWnd
でできていました。(メッセージボックスが表示されていなかったのでできていないと思っていました)
どうもありがとうございます。
0108デフォルトの名無しさん
2006/12/12(火) 22:38:020109デフォルトの名無しさん
2006/12/13(水) 16:35:12まずは、CMainFrame に MDIタブ用の CDocBar を配置したいのだが、
どこをどうオーバーライドしたらいいんだ?
CMainFrame::recalcLayout() あたり?
0110デフォルトの名無しさん
2006/12/13(水) 17:02:480111デフォルトの名無しさん
2006/12/13(水) 19:25:44なんだかこの間からぶち当たった問題をことごとく質問してないか?
0112デフォルトの名無しさん
2006/12/13(水) 19:32:030113デフォルトの名無しさん
2006/12/13(水) 19:34:02相談しようぜ。
MDIの基本的な部分はOKなん?
0114デフォルトの名無しさん
2006/12/13(水) 19:52:360115デフォルトの名無しさん
2006/12/13(水) 20:17:28MFCって結構むずいじゃん。
俺、ドキュメントビューアーキテクチャーとかいう仕組み覚えるのに何日も必要だったぞ。
まず、ドキュメントビューアーキテクチャーの構造なんて大して重要なもんだと思ってなかったし(SDIで組んでたのもあって)。
この状態でMDIプログラミング特攻すると、はっきりいってハマルじゃんw
0116デフォルトの名無しさん
2006/12/13(水) 20:57:27ダイアログをいくつか作成(このときフォントをMSゴシックの12ptに変更)し、
各ダイアログ毎にクラスを作成(CPropertyPageクラスの派生クラス)して
メインメニューに[プロパティ]項目を追加、そのイベント内で
・プロパティシートのインスタンス生成
・プロパティページをプロパティページにAddPage
・DoModalで表示
しています。
このとき、表示された各ページのフォントサイズが標準のMS UI Gothicの9pt
で表示されてしまっています。なのでCPropertySheetの派生クラスを作り、
OnInitDialog内でフォントサイズの変更を行ってみたのですが変化なしでした。
なぜこのような現象が起こるのでしょうか?
0117デフォルトの名無しさん
2006/12/13(水) 21:00:50タブコントロールなら、全ページフォントを設定する必要があるな。
プロパティシートにもそんなのあんじゃね?(適当w)
0118デフォルトの名無しさん
2006/12/13(水) 21:10:57それでも変わらないんですよ。各ページのコントロールのサイズも
ちっちゃくなってますし。全ページのコントロールの位置、サイズ、フォントを
設定しないといけないんでしょうか。
0119デフォルトの名無しさん
2006/12/13(水) 21:42:180120デフォルトの名無しさん
2006/12/13(水) 21:44:25だからおいらの相談に答えてくれよー
0121デフォルトの名無しさん
2006/12/13(水) 21:46:33あ、やっぱ、手動なんだw
0122デフォルトの名無しさん
2006/12/13(水) 21:48:25ドキュメントビューアーキテクチャ(なげぇなw)の理解は大丈夫ということでOK?
0123デフォルトの名無しさん
2006/12/13(水) 21:57:52MFCにCDocBarなんてあったけ?
0124デフォルトの名無しさん
2006/12/13(水) 22:20:15すまん CDockBar だった
CDockBar はアンドキュメンテッドなクラスで、CControlBar を配置するための滑走路みたいなものだよ
0125116
2006/12/13(水) 22:43:28SendMessageToDescendants()?でフォントは変更できましたが、
サイズとかの変更の仕方が分かりませんでした。
0126デフォルトの名無しさん
2006/12/13(水) 23:09:570127デフォルトの名無しさん
2006/12/13(水) 23:33:370128デフォルトの名無しさん
2006/12/13(水) 23:47:280129デフォルトの名無しさん
2006/12/13(水) 23:49:05まず、全体っちゅーか概要ぐらいは理解しないと
なにやるにも知ってる人間にお伺いを立てないと何もできなくなっちゃうぞ。
0130デフォルトの名無しさん
2006/12/14(木) 01:57:250131デフォルトの名無しさん
2006/12/14(木) 03:22:110132デフォルトの名無しさん
2006/12/14(木) 07:02:17そういうときもある。
0133デフォルトの名無しさん
2006/12/14(木) 09:06:58ダイアログベース単位はフォントの幅が元になってる。
だからダイアログのフォントを変えると
コントロールのサイズと位置もフォントに比例して変わる。
このフォントサイズはダイアログを作る時に指定した
ダイアログボックステンプレートに定義されている。
ダイアログを作った後でフォントを変えても
コントロールは既に作成されてしまっているから
コントロールのサイズと位置は後で指定したフォントには影響されない。
以上ここまでMFCに限らずWin32でも同様
プロパティシートがリソースで定義されたダイアログのフォントを無視しているということは
たぶんメモリ上に読み込んだダイアログボックステンプレートのフォントを書き換えてから
その変更を加えたダイアログボックステンプレートでダイアログを作っているのではないか
と推測されるけど、あとはCPropertyPageのソース等を読めばわかることだから省略
0134デフォルトの名無しさん
2006/12/14(木) 10:51:38☆ チン 〃 ∧_∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄
ヽ ___\(\・∀・)< MDIタブ実装方法 まだー?
\_/⊂ ⊂_)_ \_______
/ ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
|  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
| .|/
0135デフォルトの名無しさん
2006/12/14(木) 11:22:300136デフォルトの名無しさん
2006/12/14(木) 11:43:330137デフォルトの名無しさん
2006/12/14(木) 13:05:500138デフォルトの名無しさん
2006/12/16(土) 17:26:02SetCheck()かと思ったのですが違うようでした。。
0139デフォルトの名無しさん
2006/12/16(土) 17:46:32基本クラスのメンバEnableWindowで
0140デフォルトの名無しさん
2006/12/16(土) 18:12:46やってみます。ありがとうございました。
0141デフォルトの名無しさん
2006/12/17(日) 19:17:510142デフォルトの名無しさん
2006/12/17(日) 19:21:10ツリーリストコントロールって標準で存在しませんか?
存在しない場合はどうすれば使えますか?
MFCで作ったフリーソフトでツリーリストが使われていたので、
何らかの方法でできるのではないかと考えているのですが・・・
ちなみに、今の自分の技術力では自作は無理です
0143デフォルトの名無しさん
2006/12/17(日) 19:25:35MDI子ウィンドウのビュー(フォームビュー)でリストコントロール(CListCtrl)を使っているのですが、
他の子ウィンドウがリスト部分の前に重なった後、リスト部分をクリックしてリストがある子ウィンドウを
アクティブにすると重なっていたリスト部分だけが再描画されません
原因はまったく不明です
どのようにすれば子ウィンドウがアクティブになった時に正常に再描画されるようにできますか?
0144デフォルトの名無しさん
2006/12/17(日) 19:29:21MDI子ウィンドウのビューでリストコントロールを使っているのですが、
子ウィンドウのサイズ変更にあわせてリストのサイズを動的に変更するには
どのようにすれば良いですか?
VC#ではプロパティ画面で簡単に設定できたのですが、
VC++にはないのでとても困っています・・・
以上4つ質問させて頂きました
何かご存知の方は、ご回答をよろしくお願いしますm(_ _)m
0145デフォルトの名無しさん
2006/12/17(日) 19:37:53子ウィンドウのサイズ変更にあわせてリストのサイズを動的に変更する
0146デフォルトの名無しさん
2006/12/17(日) 19:45:000147デフォルトの名無しさん
2006/12/17(日) 19:51:360148デフォルトの名無しさん
2006/12/17(日) 19:53:22普通リードオンリーでできんじゃねぇっけ?
リソースファイルの方の設定に編集できるとかできないとかそういうプロパティあった希ガス。
0149デフォルトの名無しさん
2006/12/17(日) 20:00:56昔、俺がみたのは自力で描画してたのしかみたことないな。
今、どうなってるのかはよくわからん。
0150デフォルトの名無しさん
2006/12/17(日) 21:27:01勉強してないの丸わかりなんだけど
よくリストコントロール表示できたね
どっかからソースぱくってきた?
0151デフォルトの名無しさん
2006/12/17(日) 21:43:340152デフォルトの名無しさん
2006/12/18(月) 01:37:330153デフォルトの名無しさん
2006/12/18(月) 16:59:07点の数は数千を越えていると思うのですが かなり処理に時間がかかります。
自分なりに色々調べたところ SetPixelは遅い ということがわかりました
同時に BitBlt とか 裏画面 などと 高速化に関するワードも出てきましたが
全く分かりませんでした
この言葉で全て解決しようとするのが悪いのですが 初心者です。
しかし、時間が本当に無いので時間をかけて勉強して… ができません。
ちなみに 点は一色です。 SetPixelの遅さを解決する方法で
まだ分かり易いだろう と思う方法を教えていただけませんか?
0154デフォルトの名無しさん
2006/12/18(月) 17:15:420155デフォルトの名無しさん
2006/12/18(月) 17:27:01具体的にはループ回数が3万でそのうちの一部の点を
描画しているので、最大でも3万ですね
1万は越えているかも知れませんが…
時間は3分から5分程度でした。
0156デフォルトの名無しさん
2006/12/18(月) 17:31:20描いても0.1秒ぐらいだったよ。(裏画面とか未使用)
描画以外の部分に時間かかってるんじゃないかな。
0157デフォルトの名無しさん
2006/12/18(月) 17:35:590158デフォルトの名無しさん
2006/12/18(月) 17:39:17ループ回数を増やすと比例関数的に時間も延びたので
てっきりそこが問題だと思っていました。
そうなるとどこに時間がかかっているのか全く分かりませんね…
ランダムウォークさせているのんですが そこか
1024*768もの配列を作って その中身全てを参照(検索)するという作業を
何度かしているのも原因かもしれませんね。
mallocなんかも全く使っていませんし…
ループ回数をこれ以上にするとエラーになり途中で動作が止まってしまうのも
同じ原因から来ているのかも…
しかし ここまでくるとここで相談させてもらう内容ではなくなってしまいますね。
0159デフォルトの名無しさん
2006/12/18(月) 17:42:35それは遅いだろ...
0160デフォルトの名無しさん
2006/12/18(月) 17:57:38>初心者です
>時間が本当に無いので時間をかけて勉強して… ができません。
結論: 無理
0161デフォルトの名無しさん
2006/12/18(月) 17:57:46いちいちSetPixel使うからだよ。
0162デフォルトの名無しさん
2006/12/18(月) 18:01:51まぁ特に考えてたわけではなく、むしろ本当は描画の
様子が分かるように1回1回点を打ちたかったのですが
それができなくて 最後にだけ描画してます。
(点を打つ配列に目印をいれて最後にその部分だけ描画)
結論を言うと そのループ及び巨大な配列の中身を参照するのに
時間がかかってるというわけなんですね・・・
>>160 ってことでFAですかね。
検索の仕方や配列の使用法などを再考してみますね。
こんなくだ質に付き合ってくださってありがとうございました。
0163デフォルトの名無しさん
2006/12/18(月) 18:13:410164デフォルトの名無しさん
2006/12/18(月) 18:17:040165デフォルトの名無しさん
2006/12/18(月) 18:20:290か1を直接書き込めばいいじゃない。
その後BMPに変換すれば?
0166デフォルトの名無しさん
2006/12/18(月) 18:54:300167デフォルトの名無しさん
2006/12/18(月) 19:57:42遅いというのは一瞬じゃないということ
自分で試さずに質問するのはやめてほしい。
0168デフォルトの名無しさん
2006/12/19(火) 00:26:28そういう時は、SetPixelだけをコメントアウトしてみる。
そうすれば、それが犯人かどうか分かる。
0169デフォルトの名無しさん
2006/12/19(火) 00:53:12130万pixelなんて問題にならないぐらい強烈に早いね。
今後使う機会があるかは微妙だけど勉強になったよ。
>>170 スレ違い房乙
0170153です
2006/12/19(火) 00:55:54>>163
確かにループには入ってますね
でもループもしないで1回だけ なんて できるんですか
>>164
そのような方法がある事は調べていたときにわかったんですが
なかなか理解できなかったんですよね
>>165
今は理解できないんで ちょっと考えて見ます^^;
ありがとうございます。
>>166
ですね。 158で自分でも言ってますが。 すみませんでした。
>>167
そうなんですか。 >遅いというのは一瞬じゃない そうですね
自分で試さずに とは 何のことでしょう?
確かに SetPixelに時間がかかっていたかどうかは
自分で画面全体にSetPixelで塗りつぶしてみれば分かったんですね…
そうだ と思い込んでしまったので思いつきませんでした ごめんなさい。
0171デフォルトの名無しさん
2006/12/19(火) 01:15:49そんな方法もありますね 次回から参考にします!
>>169
スレ汚しすみませんでした。
0172デフォルトの名無しさん
2006/12/19(火) 02:51:30つーか、普通にSetPixelとGetPixelが遅い。
GDI+を使っているならこれで速くなるっぽいことが書いてある。
http://junki.lix.jp/csgr/002ColorDataAccess1.htm
0173デフォルトの名無しさん
2006/12/19(火) 08:21:41> 1万は越えているかも知れませんが…
>
> 時間は3分から5分程度でした。
描画しているのは最大でも3万で時間は3分から5分
0174デフォルトの名無しさん
2006/12/19(火) 14:48:18そこに描画してBitBltするという、昔ながらのやり方を
試すのが今後のためにいいと思うが。
■ このスレッドは過去ログ倉庫に格納されています