■MFC相談室 mfc19d.dll■

もっというと>>900は自分の状況を何も表現できてなかったってことだなｗ

いや思い出しました。
pm_CSB->Create(
直した時もCObjectのPrivateメンバにアクセスできません。でなにもエラー内容変わらなかったんです

じゃあ、これが↓嘘で

CCopyStaticButton* pm_CSB;

CCopyStaticButton pm_CSB;

ってなってたってことぐらいしか考えられないな

>>951
>出来ればnewど素人に開放の場所のアドバイスをくださいお願いします。
仕様による
最後でいいならボタン貼ってるウィンドウのデストラクタでもおｋ
Create();したからDestroyWindow();を忘れずに・・・

あれ？コントロールはいらないっけ？DestroyWindow();

vectorに実体をpush_backしようとした時点で
コピーコンストラクタとかでおかしくなりそうだけど

>>956
いらんよ。親が破棄する。


しかしまあ、>>946 も雑なコーディングだな。
＞int boxNum;
int boxNum = 0; // 初期化しないでインクリメントするな。これだと warning C4700 がでてるはずなんだがな。

＞str.Format(_T("%d"),boxNum);
＞(*(vCopyBox.end()-1))->Create((_T("CopyBox")/*+str*/, WS_CHILD

str.Format( _T("CopyBox %s"), boxNum); // こうすりゃ一度で終わるだろ。
(*(vCopyBox.end()-1))->Create( str, WS_CHILD

いけね。
str.Format( _T("CopyBox %s"), boxNum); →　str.Format( _T("CopyBox %d"), boxNum);

ソフトでデータを編集するとファイル名に＊がついて、終了するときに勝手に保存するか問い合わせてくる、
アレってどうやるんすか？

>>960
どうやるもこうやるも、ファイル名の脇に'*'を出力するのと確認ダイアログを出すだけなんだが。
まさか、コードが天から降ってくると思っているわけじゃないだろ?

Docクラスあたりにmodifyなんちゃらっていうフラグが立つから、それが立ってる場合にフレームタイトル描画する関数で*追加するだけだな
やったことあるわ

他のアプリケーションを起動させるのは出来るんですが
そのアプリケーションをダイアログみたいにウインドウに張り付けて起動させることはできないんでしょうか？

できる

まじですか。完璧じゃないですかそれ

で、やり方は？

起動される側のアプリが対応して無いと無理だろ。
無理やりやればできなくは無いだろうが、まともに動くとは思えない。

CreateProcessで起動して
インスタンスとってそのインスタンスのメインウィンドウを
取得してやれば何とかできるかもしれないけど
全部が対応できるわけねえよ

>>964
てきとうに「できる」とか言うなボケ

できるかできないか、だけなら「できる」でいいだろ。
そこまでする必要が普通はないだけで。
# 少なくともリモートデスクトップにはできるのだから。

うれしくて.NET勉強してたんですが、難しいんですか？
移行してみようかな的な、.NETのアプリを作って組み込んで切り替えて使えるようにしようかと思ったんですが。
最悪WebBrawserコントロール貼り付けてSilverlightでUI全部すませたら面白いかなーと
今後、MFCのドッキングウィンドウは絶対はずしたくない機能なんで、どうすればいいとこどりできるかを考えてたんです。
CreateProcessで他のウィンドウを操作するところから始めてみます。ありがとうです。

.NETってUI作るの簡単なんていうけど実際にお金を貰うアプリを作る場合はほとんどの
標準コントロールはつかえないから自前で用意することになるから
MFCとなんらかわりない

WPFの広告とかみてたら簡単にUI作れるみたいな印象を受けたんですが、甘いですか？
自由度なくて調整するのにMFC以上に時間かかるなら意味ないですけどそんな予感はたしかにしますｗ

ツリーコントロールのドラッグアンドドロップとか
リストコントロールの着色とか
ダイアログにダイアログを貼り付けたときのフォーカスの移動とか
リストコントロールのセルチェンジ時のコントロールの切替とか
ふつーにやらなきゃならんけどＭＦＣだとかなり困難な部分って楽になってないの？

>>972
WPFは自由度高い。
リストコントロールの各項目に別のコントロール入れたり
ボタンの中にボタン入れられたり(意味無いけど)
それらを任意の拡大率・角度に調整できたり。

MFCとWPF比べるとか、月とすっぽんもいいところ。
WPFやったらもう、MFC使ってるやつはマゾとしか思えなくなるレベル。
まあ、C++使わざるを得ないとMFCしか選択肢なくなるんだが・・・

>>974
それってほとんど実用性ないじゃん。(w

>>973 が指摘している件は、具体的にWPFでカイゼンされているの？

> C++使わざるを得ないとMFCしか選択肢なくなるんだが・・・

MFCは文字通りマイクロソフト謹製のクラスライブラリでしかない
んだが？　対してC++は汎用言語なんで、MFCを一切使わず、自前の
クラスライブラリを作ってもいいんだよ。

もっとも、それができればの話だが、MFCさえ使いこなせないヤツに、
ムリな注文だよなぁ。

>>971
>ほとんどの
>標準コントロールはつかえないから
何を言っているんだ君は。

>C++使わざるを得ないとMFCしか選択肢なくなるんだが・・・
C++/CLI はあかんの？俺使ったことないけど。

C++で.NET使うならC++/CLIだな
C++0xスレだと、C++0xで標準化しようとしている記法を馬鹿にするほどC++/CLIの記法は評判良かったりする
そこは俺も同感だが、正直.NETとC++の相性なのか結構使いにくい印象
C++の長所も捨ててるしな

C++/CLI使ってみた俺がちょっとだけ書く

[長所]
・GUIが細かい設定ができる
・GC

[短所]
・文字列変換がめんどくさい
C++/CLIオンリーならいいけど、
WindowsAPIとか、自分のC/C++なライブラリ使うんだったらこれ必要

他にも色々あるけど
結構C/C++の楽な部分ができなくなるお。

MFCは、GUIのタブ系と画面サイズ変更時の子コントロール変更がめんどくさいけど、
それ管理周りを自作したら、あと10年は戦える。

という結果になった。
俺は。

ついでに言うなら、.NETするならC#がもっと楽

数値入力専用のエディットコントロールを置いたのですが、その入力できる数値を制限したいのです。
どのようにすればいいでしょうか？

CEditとCSpinButtonを合体させたらレンジ指定出来なかったっけ？

C++0xの記述が長ったらしいのは柵のせいなんだろうな・・・
拡張性はあるだろうけど、正直勘弁

>>981
どう制限したいの？
−や少数点が無しならエディットのコントロールに番号ってのがあるからそれにチェックをいれれば
数字以外入力できない
あとはキルフォーカスの瞬間にエラーメッセージを出すとか
ＯＫボタンを押した瞬間にチェックが走ってエラーメッセージが表示されるとか
そもそも入力させないってのもあるけどこれは使う側が面倒だな

どの瞬間にどう制限したいのか？ってところでもやり方変わるけど・・・

>>983
そもそも入力させないようにしたいのです。
出来たら制限範囲よりも大きい数字が入力されたら、補正して範囲内の最大値にするといった風にしたいのです。

>>984
だからどのタイミングで？
キルフォーカス？
アップデート？

キルフォーカスでお願いします。

じゃ、やれよ！

すいません
色々と試行錯誤したところ上手くいきそうです。
くだらない質問に答えて頂いてありがとうございました。

>>988
嘘だな
SetLimitTextとか他の制限は頭に入ってなさそう

流れにﾜﾛﾀｗ
ていうかWinのマウスキャプチャーの仕様考えたの誰だよ
この辺でいつも悩んでしまう

>>984,988
CDialog::::OnChangeFileName のハンドラをEditコントロールの親ウィンドウに
追加して、そこで入力された数値を監視すればいい。
で、範囲外の数値が入力されたら CEdit::SetWindowText() を使って書き直す。
ただそれだけだ。難しく考えるな。

ちょいミス。CDialog::::OnChangeFileName()はウチで使ってる関数プロトタイプだった。
要はこれね。ON_EN_CHANGE( <id>, <memberFxn> )　 afx_msg void memberFxn( );

次スレたてた。■MFC相談室 mfc20d.dll■
http://pc11.2ch.net/test/read.cgi/tech/1230219816/

CRect rect;

rect.Width();

こう書いた方がいい？
それとも極力

rect.right;

の方がいいと思う？

>>994
同じもんか？それ？

どっちでも内容が同じでどっちでも書ける場合なんですけど
GetClientRect(&rect)の時とかで、
Width()は関数なので.rightの方がいいのではと考えながらやってたらごっちゃ混ぜで統一できてなくてひどくなってきました。
いいかげんどっちがいいのか決着をつけたいです！

>>996
rect.right　と rect.Width() の値は違うぞ。
GetWindowRect( rect)してみ。

int CRect::Width() { return rect.right - rect.left; }
関数といってもやってることはこれだけだから、rect.Width() を使うクセをつけておいたほうが、
>>997のような時にバグらなくていい。

関数の中身見れたんですね。
引き算しかしてないということで、.rightに統一しようと思います。
もっと複雑なことをしていて、.rightで大丈夫なのかと不安だったんです
GetWindow、toScreenを全てGetClientに統一したので大丈夫です。ありがとうざいました。

意味不明なほど余裕の1000

（・∀・）ﾖﾕｰﾖﾕｰ

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。