05/10/18 22:07:31
>>235
>>エラーが出て、エラーメッセージ見てもググらないと理解不能なのが多いし
その通り。
だから一つずつMSDNやWeb上の情報を見ながら覚えていくのだ。
エラーメッセージも、API、クラスの使い方も。
238:名無し募集中。。。
05/10/18 22:19:28
Wizardって魔法使いって意味だからね
239:デフォルトの名無しさん
05/10/19 09:10:01
>>237
で、解決策がふつーに考えればメソッドだったりする筈だが、
色塗るにもWin32APIの力借りてカラープロパティさえ無い、と。
何このラップ出来て無いクラスライブラリ、って感じ。
240:デフォルトの名無しさん
05/10/19 16:00:58
MFCのソースを使って
Windowsのバグを回避したら訴えられるのだろうか
241:デフォルトの名無しさん
05/10/29 19:29:54
もしかしてMFCって、Windowsプログラミングを少し理解しててC++をかなり詳細に知ってる人間にとってはすごい便利なものじゃない?
242:デフォルトの名無しさん
05/10/29 19:56:35
カプセル化が中途半端なので、更にMFC自体の仕様も十分に理解してる必要がある。
243:デフォルトの名無しさん
05/10/29 20:41:17
>235
順番に抑えていくうちに、自動生成のソース全部意味分かるようになったよ。
それとともに、the APPというプログラム開始実体から、うんぬんかんぬんやってメイン呼ばれて行くかも分かったし、
ランタイムとその周辺も分かってくるようになった。
それと、今まで、インクルードやDefineやクラスやメンバなどの定義位置がいかにあやふやだったかてのが分かった。
ただ、やっぱりクラス間での参照渡しは、なかなかつらいもんがある。
244:デフォルトの名無しさん
05/10/29 20:46:23
それと、
逆に、マルチフレームやスプリッタなどのいわゆる複数画面は、
WIN32アプリの方がCALLハンドラがアミダ状態で嫌んなる。
ホント実用的な画面設計に関しては、楽だよMFCは。
245:デフォルトの名無しさん
05/10/29 21:13:27
メイン関数も無いし、どこからどういう順番でハンドラが
呼ばれるのかさっぱり分からなかったが、とりあえずそういうものだと
思うことにしてしばらく格闘したら分かるようになった。
246:デフォルトの名無しさん
05/10/29 23:21:58
>245
少し忘れかけてた部分あって、もう一度調べてみたが、
まず、メインが始まる前に見に行くものがある。(includeとかマクロとかstaticとかグローバルオブジェクトとか)
で、CREIApp the Appというのが見つかる。
そこでCREIApp::CREIAppのコンストラクタ、いやいや、これは派生クラスだから、
CWinApp::CWinAppを見に行く(CWinAppの定義はAfxWin.hにある、コンストラクタ実装はAppCore.cppにある)
そして、次にCREIApp::CREIAppを見に行くが、通常こいつは空だ
いよいよWinMainだが、MFCのWinMainは変わっていて、_tオプションがついて_tWinMainになっている(実物はAppmodule.cppにある)
そこには、
return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
とだけ書いてある。要は、AfxWinMainを暗に呼んでいる、こいつがどこにあるかというと、Winmain.cppにある)
このなかで、CWinAppのInitApplication、次にCWinThreadのInitInstanceが呼ばれている。
継承関係はCWinThread>CWinApp>CREIAPPで、どちらも仮想関数になっていて、virtual属性が付いている。
ということは、実際呼ばれるのは、たどっていくと、派生末端のCREIAPPのInitApplication、InitInstanceの順に呼ばれることになる。
ご存知の様に、InitInstanceではRunTimeが施されていて、Doc、Frame、Viewが関連付けられている。
話し戻って、その後AfxWinMainは何やっているかというと、Win32アプリと同じようにRun関数でメッセージループにして、半無限ループにしている。
247:デフォルトの名無しさん
05/10/30 00:29:39
やべーちょっと使ったら息子から我慢汁溢れてきた
これMFCマジでスゲーから
自作のウインドウライブラリなんてカスだわ
こんなすばらしいモノがあるのになんでVBやNETなんか開発したのかわからんね
248:デフォルトの名無しさん
05/10/30 02:23:02
MSDNでクラスライブラリにさらっと目を通せばあなたも今日からMFCマスター。
249:デフォルトの名無しさん
05/11/04 17:35:55
.NET で全てなかったことにされて
Windows Forms を1から用意しなおしたことからも
MFCがクソだったことはMSすら認めてる事実。
250:名無し募集中。。。
05/11/05 00:42:29
誰かさんの.netにだけMFCが付いてこなかったようだね
251:デフォルトの名無しさん
05/11/05 19:43:49
クラスとかがよくわからん俺にはMFC使う人は尊敬する
俺はSDKでごりごり書くことしか出来ないよ・・・
252:デフォルトの名無しさん
05/11/05 22:19:09
MFCが難しいのはクラスとかが原因じゃないと思う
リファレンス無しでソースだけ見ても全く理解不能なコードだったりする辺りが
253:デフォルトの名無しさん
05/11/06 21:23:48
あまり優秀な開発者を回せなかったんだろうな
JavaのSwingのコードにもそれを感じる
254:デフォルトの名無しさん
05/11/06 21:31:55
× を回せ
○ が居
255:デフォルトの名無しさん
05/11/07 11:04:17
>MFCがクソだったことはMSすら認めてる事実。
内容は正しいけど、認めてるというのは知らなかった。
表向きに認めているソースきぼんぬ。
裏的にはMFCの次にATL/WTLが出たり、
GUIライブラリとしてM$社内でMFCが使われて無いという事実だけで、
十分だけどね。
256:デフォルトの名無しさん
05/11/07 14:52:46
VC++6を使ってますが、
メモリリークの箇所とかソースファイルを特定する方法を
教えて下さい。
257:デフォルトの名無しさん
05/11/07 15:01:26
>>256
つ F4
258:名無しさん@お腹いっぱい。
05/11/08 16:11:33
MFCって処理速度はどうなん?
259:デフォルトの名無しさん
05/11/08 17:14:33
ActiveX使わなければ高速だろ。
MFCでActiveX使わないと寂しい画面になるお。
260:名無し募集中。。。
05/11/08 18:40:57
MFCでActiveX使うってダイアログベース?
261:デフォルトの名無しさん
05/11/08 19:36:11
MFCってコマンドライン専用?
確かにVC++はテストプログラムの場合ダイアログは皆無で、コマンド系ツールを良く見かける。
262:デフォルトの名無しさん
05/11/12 22:03:00
>>256
つ DevPartner for Visual C++
URLリンク(www.compuware.co.jp)
263:デフォルトの名無しさん
05/11/14 16:25:14
>スレリンク(tech板:998番)
>CArray系とCList系は直交性がないから
>最初にどっちにするかちゃんと決めておかないと後で直すのが面倒。
この場合の直交性ってどういう意味?
264:デフォルトの名無しさん
05/11/14 17:32:47
>>263
どうも、そのスレの774,777,994,998などを書いた人です。
■MFC相談室 mfc14d.dll■
スレリンク(tech板:774番)n-
774 :デフォルトの名無しさん :2005/10/21(金) 17:49:53
CArrayとCListのナントカ性がないのでCArrayからCListに直すのが面倒。
何て言うんだっけ。
777 :774さん :2005/10/21(金) 18:19:16
直交性だった。
URLリンク(www.hey-to.net)
> MFCだと、たとえばCArrayで書いてた部分をCListに取り替えたとき、
> 書き直さなければならないコードの量がすんごいです。やってらんない。
> クラスとメソッドの直交性が皆無なんだな...
> MFCコレクションの唯一のメリットといえば、
> シリアライズがちょびっと楽なことくらいでしょうか。
265:デフォルトの名無しさん
05/11/15 01:26:03
>>264
その777,774も含めてクラス間の直交性ってナニ?って質問じゃないの?
数学や物理なんかで直交性ってのはイメージとしては互いに独立で相互依存がないような関係を差す
<CArrayからCListに変えた場合に書き直すコードが多い>即ち<非直交>というのは短絡ではないかと?
コンテナなどで互いに独立性の高い要素に分解して設計する場合に直交性の話をするけど、クラス間の直交性
というと、相互に干渉しないで共用できる場合に言うような気がする。
ま、C++も最近調べ始めた人間なのではずしているかも知れないがな
266:デフォルトの名無しさん
05/11/18 07:24:12
いやーいいわMFC。
今までの努力はいったいなんだったのか
なんではじめからこれを使わなかったのか
今まで1ヶ月以上かかっていたことがMFCだとたったの3日
青空に浮かび風の趣くまま漂う白雲のような自由を私に感じさせるナイスライブラリ
MFC is 最高
267:デフォルトの名無しさん
05/11/18 07:30:15
MFCに市場価値がないならExpressに付けるがな。
268:デフォルトの名無しさん
05/11/18 10:50:08
ここ見て.NET面白そうじゃんと思って作ろうと思ったら
ノートンに「悪質なスクリプトじゃ」と怒られました。
269:デフォルトの名無しさん
05/11/18 13:10:51
旧VB6系コンパイラをV$から外したように、
MFCをユーザーからやめさせたくてもExpressから外すだろ。
というか、どっちかというとV$はそういう場合ばかり。
270:デフォルトの名無しさん
05/11/18 17:33:35
MFCってNETよりうまくできてるよ
NETは素人向けすぎてどうもいかん
271:デフォルトの名無しさん
05/11/18 18:40:04
両方使ったこと無いが、.NETとMFCって比較すべきものなの?
.NET = 言語非依存なライブラリの標準的規格(MS談)
MFC = ライブラリ
かと思ってた。
272:デフォルトの名無しさん
05/11/18 19:45:59
>>271
正確には
・C++ & MFC & Win32 API
・Managed C++/C# & .NET Framework
の比較でしょうね。
273:デフォルトの名無しさん
05/11/18 22:48:11
クラスの名前にCをつけるのが嫌い
あほの子じゃないんだからそんなことしなくてもわかるよ
274:デフォルトの名無しさん
05/11/18 23:31:55
しかもクラス名のイニシャルCを勝手に削りやがるし
うっかりするとわけのわからないヘッダファイルになってしまう。
275:デフォルトの名無しさん
05/11/19 11:58:48
あほの子じゃなければ、自分で作るクラスの名前もファイル名も自分で
設定すれば良いんじゃないのw
276:デフォルトの名無しさん
05/11/19 12:55:50
>>275
あほの子にはそれが分らんのですよ
277:デフォルトの名無しさん
05/11/19 14:40:11
>>274
突然 IDE (の Wizard) の話をし始めるとは、あなたあほの子ですね。
278:デフォルトの名無しさん
05/11/19 18:41:57
つまんねーよハゲ豚メガネどもめら
279:名無しさん@お腹いっぱい。
05/11/19 18:45:03
MFC(Microfost Fucking Class)
280:デフォルトの名無しさん
05/11/19 21:38:14
VisualC++6.0とJavaはどのような繋ぎ方があるのですか?
或いは、.NET(C++,C#)だとどうなんでしょうか?
281:デフォルトの名無しさん
05/11/19 22:36:53
280は馬鹿
282:デフォルトの名無しさん
05/11/20 00:47:26
.NETは使ったこと無かったのですが、.NETFrameworkでは全て
「IL (Intermediate Language)と呼ばれる中間コードにコンパイル」
なようですね。そして、
・C#、Manage C++、VB.Net、JavaScriptが.NETFramework上で扱える
・.NET Framework では、これらすべての言語で同じライブラリを利用できるし、異なる言語で書かれたプログラムを呼び出すことが出来る。
ということなようです。
ただ、.NETFrameworkにJavaが入ってないのですが、これからどうなるんでしょうね。
現時点でJavaScriptが入ってるということでなんとかなりますか。
脱線失礼しました。
283:デフォルトの名無しさん
05/11/20 00:56:40
それと、C++BuiderとJBuiderもお互い呼び出すことができるらしいのですが、
.NETとどちらのどの辺がいい等あったら、レスお願いします。
その前に、話が流れたとはいえ、他スレに逝けと言われそうですねw
284:デフォルトの名無しさん
05/11/20 01:06:23
>>282
>ただ、.NETFrameworkにJavaが入ってないのですが
その為にC#なんてシロモノをでっち上げたわけだが。
285:デフォルトの名無しさん
05/11/20 05:23:17
え?
J#もあるしJScript.NETもあるんですが?
286:デフォルトの名無しさん
05/11/20 07:57:43
それにしても、Managed C++はきもい。ガーベッジコレクション機能1ついれるために、
言語仕様が全体に渡って継ぎはぎだらけ。
おまけに、オブジェクトに__gc修飾 がついているかどうかを常に
気をつけなきゃいけないんだったら、いらないよそんなの。
まだ、deleteするのを忘れないようにするほうがまし。
287:デフォルトの名無しさん
05/11/20 08:42:36
なぜここkでmanagedの話題がでるのかわからんが、
入れるならきちんと標準化委員会でガベッジコレクションの仕様を定義してほしいのう
288:デフォルトの名無しさん
05/11/20 10:29:29
>>286
VC++ 2005のC++/CLIについて一言。
289:デフォルトの名無しさん
05/11/20 13:10:17
VS2005が出たら、.NETではC#からC++にメインを移そうかと考えてる。
290:デフォルトの名無しさん
05/11/20 17:06:24
いいんじゃないの?
両方使えるのが理想
291:デフォルトの名無しさん
05/11/20 18:10:52
>>286
あれは既存ソースの移植用にあるものとみたほうがいいだろ
そうじゃなきゃC# で作ったほうがハヤス
292:デフォルトの名無しさん
05/11/20 20:26:20
だからVBの代わりだってば
293:デフォルトの名無しさん
05/11/21 03:49:24
>>285
ああ、J# には驚いた。COBOL# とか Eiffel# と同程度の愚行だ。
(切り捨てて困る程、J++ ユーザなんて居たのか?)
>JScript.NET
Java の話をしている時に、それを引き合いに出す意味が判らない。
294:デフォルトの名無しさん
05/11/21 16:19:25
>>293
その辺は単に.NETの汎用性っつか言語非依存性を強調するための
プロパガンダでしょ。
295:デフォルトの名無しさん
05/11/21 16:48:04
>言語非依存性
超鳴り物入りだったのに、
ブビチュウがブビドトネトさえも使えない現状を見ると、
全く持って無意味だったね。
296:デフォルトの名無しさん
05/11/30 02:54:33
MFCを使わずにWIN32だけつくっているひとは
なぜにいつも ”ごりごり” なんて言葉つかうの?
ソースが10万行以上の中規模プロジェクトをすべてWIN32だけで
書いたのなら確かにごりごり書いている気はするが、
所詮、1,2万行程度のサンプルアプリを書いているだけでしょw
297:デフォルトの名無しさん
05/11/30 09:57:18
>>296
「MFCを使わずにWIN32だけつくっているひと」が
「いつも ”ごりごり” なんて言葉つかう」が事実かどうかも知らないし
ましてやその理由など本人に訊けと。
298:デフォルトの名無しさん
05/11/30 10:07:35
枕言葉
ごりごりとWIN32
もっさりとJava
299:デフォルトの名無しさん
05/11/30 10:44:46
最初はMFCを使っていた。
確かに初心者にはツールバーなど
便利な基本機能がついているのはうれしかった。
しかし、フリーソフトとして公開するとき、
ランタイムライブラリの問題など凡用性に問題が
いやになった。プログラム単体で動くようにしたかった。
SDKはそれが可能だし、すべて自分で作ってる感、
全処理ソースを目で確認できる爽快感。
MFC、最近は気持ち悪くて使えん。
300:デフォルトの名無しさん
05/11/30 10:51:41
MFCのソースみるといろいろと参考になる
301:デフォルトの名無しさん
05/11/30 10:53:11
>>299
スタティックリンク出来ないって事?
302:デフォルトの名無しさん
05/11/30 10:57:01
MFCのDLLぐらいで嫌がってたら
インストーラ使うソフトはもちろん.NETも使えないな
303:デフォルトの名無しさん
05/11/30 11:50:22
>>296
2万行でサンプルとは凄いな。
304:デフォルトの名無しさん
05/11/30 19:21:12
サンプルっていうかプロトタイプじゃね?
ある程度以上の規模だと最初にざっとしたものを
つくってしまう。
2万行程度ならそんな感じじゃん
305:デフォルトの名無しさん
05/11/30 22:16:29
凡用性…
306:デフォルトの名無しさん
05/12/01 16:30:05
>>299
なんでスタティックリンクしないの?
307:デフォルトの名無しさん
05/12/01 23:47:32
嫌気がさしたんだろ
308:デフォルトの名無しさん
05/12/02 05:11:59
>>299
スタティックリンク知らないの?
309:デフォルトの名無しさん
05/12/02 07:45:11
凡用性…
310:デフォルトの名無しさん
05/12/02 12:56:15
凡人なのか?
311:デフォルトの名無しさん
05/12/02 13:08:47
MFCのライブラリを添付するインストーラは結構あるね。
印象に残ってるのは、ATIのCryエンジンデモプログラム。
お前はいつ、どこでGUIを使ったのかと小一時間(ry
312:デフォルトの名無しさん
05/12/03 15:35:44
MFCをGUIの為だけと勘違いしている人がいるんですけど
スルーでOKですか?
313:デフォルトの名無しさん
05/12/03 17:52:04
>306,308
確かマルチスレッドにするとDLLにせざるを得ないじゃなかったっけか?
314:デフォルトの名無しさん
05/12/03 20:28:26
Σ(☉◇☉)
315:デフォルトの名無しさん
05/12/03 21:07:00
マジレスしよう。
>>313
ソースは?
316:デフォルトの名無しさん
05/12/03 21:14:56
>>312
GUI を使わない MFC になど
糞ほどの価値すらないと思っている俺に
是非解説して頂きたい。
317:デフォルトの名無しさん
05/12/03 22:03:33
MFCのGUIにもそれほどの価値があるとは思えんが
318:デフォルトの名無しさん
05/12/03 22:29:30
afxwin.h使わないとなると、
あの糞極まりないコレクションクラスだの、古臭いDAO/ODBCラッパーだのか……
激しくいらんわな。
319:デフォルトの名無しさん
05/12/04 00:59:01
MFCに嫌気がさした人は当のMSの人たちでしょ
320:デフォルトの名無しさん
05/12/04 10:51:46
MFCの有用性をトータルで上回るクラスライブラリがあるならねえ。
ないし。
321:デフォルトの名無しさん
05/12/04 11:17:36
.NET Framework
322:デフォルトの名無しさん
05/12/04 11:43:49
.NETは別のものだし。
323:デフォルトの名無しさん
05/12/04 13:40:17
>>320
ATL では不足だとでも?
324:デフォルトの名無しさん
05/12/04 14:15:13
>>323 COM (゚⊿゚)イラネ
325:デフォルトの名無しさん
05/12/04 14:22:32
>>324
CWindowImplなんかはWTLのメッセージクラッカと併せて使えると思うが。
326:デフォルトの名無しさん
05/12/04 14:24:27
今時C++なんてはやんねーよ
327:デフォルトの名無しさん
05/12/04 14:48:21
はやりすたりの浮草稼業じゃないし。
328:デフォルトの名無しさん
05/12/04 14:55:40
C++プログラマにすれば、むしろ流行じゃないほうが得だったりする。
329:デフォルトの名無しさん
05/12/04 16:10:44
>>326
C#厨キタ━━(゜∀゜)━━!
330:デフォルトの名無しさん
05/12/04 22:35:56
MFCでもCOMを使う、あるいは、COM使うべき状況に置かれることは多い。
よく見かけるのだが、
MFC経由でCOMを使うことには無頓着で、
ATLがCOMを使うことに拒絶反応を示す理由がわからない。
そもそもATLの基底ウィンドウクラスはCOMと関係なくビルドできる。
331:デフォルトの名無しさん
05/12/04 23:48:05
ATLでGUIを書くのは大変だろう。
332:デフォルトの名無しさん
05/12/04 23:55:07
VCL最強ってことで。
333:デフォルトの名無しさん
05/12/05 00:01:20
>>331
ハンドラ追加機能が使えないこと以外は、ほぼ遜色なく扱える。
MFCからWTLへの移植は楽とまでは言わないが、
難しいというほどでもないよ。実際に試してみ。
ATL/WTL Part3
スレリンク(tech板)l50
334:デフォルトの名無しさん
05/12/05 00:08:16
WTL使っていいなら、少しは考えるけど。
でもやっぱマンドクサ
335:デフォルトの名無しさん
05/12/05 00:38:17
俺は、Spy++とかでウィンドウクラス名を見ただけでMFC使ってるのがバレバレになるのがイヤでWTL使ってる。
336:デフォルトの名無しさん
05/12/05 00:50:18
なんだよそれwww
337:デフォルトの名無しさん
05/12/05 04:51:03
見られると恥ずかしいという点においては同意する
338:デフォルトの名無しさん
05/12/05 08:52:32
ことごとく「Afx:」のプリフィックスで始まるウィンドウクラス名。
有償アプリでこれを見てしまうとその会社のレベルを疑ってしまう自分。
ま、実際はMFCをちゃんと使いこなせてる感じだし、これをもってレベルを計るのは間違いなんだけどね。
339:デフォルトの名無しさん
05/12/05 08:54:59
しかし当たっていることが多い
340:デフォルトの名無しさん
05/12/05 11:19:54
MFC でまともに動くモノを作れてるなら
寧ろ褒めてあげて下さい。
341:デフォルトの名無しさん
05/12/05 11:47:34
んじゃ、商用のWinアプリって何で作られているのが主流なの?
VCL?
342:デフォルトの名無しさん
05/12/05 11:52:45
たまに商用系で某アイコン=VCL見るお。
某アイコンのOk/キャンセルの方が恥ずかしい。
343:デフォルトの名無しさん
05/12/05 12:06:09
>>324
#define _ATL_NO_COM_SUPPORT
344:デフォルトの名無しさん
05/12/05 13:29:58
exeのプロパティ見て、
バージョン情報のタグが出るのがMFC
出ないのが某製
であってる?
345:デフォルトの名無しさん
05/12/05 14:54:52
>>344
バージョンリソースの有無が判るだけ。
346:デフォルトの名無しさん
05/12/05 15:18:39
VC++を使っていようとBCB(/BCC)を使っていようと(もちろんそれ以外を使っていても)バージョン情報は埋め込める。
347:デフォルトの名無しさん
05/12/05 15:27:54
確か、某が公開したexeから使用しているVCLクラスを取得するツールがあった筈。
348:デフォルトの名無しさん
05/12/05 21:36:11
.NETよりはマシ。
.NETで納入してこようもんなら
即つっかえしだよねw
349:デフォルトの名無しさん
05/12/06 08:18:55
いや
漏れ的には MFC < .NET
350:デフォルトの名無しさん
05/12/06 08:36:56
結局、VCL/Win32最強、かつ、VCLドトネト使えばドトネトコンパイル。
351:デフォルトの名無しさん
05/12/06 11:37:16
WXとかFOXみたいなフリーライブラリの商用ソフトって結構浸透してるの?
当方、趣味グラマなんで、その辺かなり興味ありです。
352:デフォルトの名無しさん
05/12/09 02:31:00
フリーライブラリの商用ソフト?
353:デフォルトの名無しさん
05/12/09 12:35:36
プログラムする側からしたら .NET > MFC だが
受け取る側からしたら Native > .NET な場合が結構多い。
354:デフォルトの名無しさん
05/12/09 17:58:23
客先から .NET 環境でなんて指定されたことは一度もない。
ソースも提出しなければいけない客だとほぼ、MFCを言われる。
まぁ、使う側からすれば同じ結果を得れるプログラムがあったら
遅い方をえらぶメリットはないからな
355:デフォルトの名無しさん
05/12/09 19:19:05
通常、常駐させるようなアプリ例えばウィルス対策アプリなどを
.NETで書いたら絶対売れないw
356:デフォルトの名無しさん
05/12/09 19:27:42
>>344
バイナリエディタでクラス名見たりすればすぐわかるだろ。
357:デフォルトの名無しさん
05/12/10 04:22:38
そんな場合は、MFCなんて使わずにWin32だろ
358:デフォルトの名無しさん
05/12/10 04:38:29
大半のアプリをVB6アイコン丸出しで出荷しても平気(しかもパッケージ製品)というレベルの
職場からすると、「おっMFC使ってる。すごいね~」とか本気で思ってしまう。
359:デフォルトの名無しさん
05/12/10 08:05:40
>>358
でも真の勝ち組なのは君たちVB組の方。客・受け手問わず。いろんな意味で。断言する。
360:デフォルトの名無しさん
05/12/10 22:27:57
>>357
MFCはWin32
361:デフォルトの名無しさん
05/12/11 02:46:21
>>360
プ
362:デフォルトの名無しさん
05/12/12 11:18:02
>>357
「Win32 API」の事を「Win32」と呼ぶのは
君くらいのものです。
363:デフォルトの名無しさん
05/12/12 17:19:30
デバイスコンテキストハンドルに対して、
「誰が出歯やねん」とつっこむのは
さんまくらいのものです。
364:デフォルトの名無しさん
05/12/12 19:57:26
花紀京に対して、
「誰がカバやねん」とつっこむのは
原哲男くらいのものです。
365:デフォルトの名無しさん
05/12/31 16:23:22
全レス読んだけど、結局ここの住人はMFCの何が嫌なのかさっぱりわからん。
俺は便利だと思うけどなぁ。
366:デフォルトの名無しさん
05/12/31 16:28:53
>>365
バグ、異次元仕様、設計者の為の設計
367:デフォルトの名無しさん
06/01/01 02:05:44
あと何年持つかな?MFC
368:デフォルトの名無しさん
06/01/01 10:59:42
>>367
10年以上
369:デフォルトの名無しさん
06/01/01 12:12:05
>>367
ドトネトより寿命は長いかも。
370:デフォルトの名無しさん
06/01/03 10:03:09
>>366
>バグ、異次元仕様、設計者の為の設計
多かれ少なかれどんなものにでもあると思うんだけどなぁ。
俺はそういうもんだと割り切って使ってるし。
371:初心者
06/03/22 19:09:24
VCLってBCBのクラスライブラリのことですか?
372:デフォルトの名無しさん
06/03/22 19:40:05
そうだよ
373:デフォルトの名無しさん
06/03/23 00:31:38
MFCってCでやる
「構造体+関数ポインタテーブルによるオブジェクト指向」
の関数ポインタテーブルを見えなくしただけ、って気がしてきた。こう思うと楽だ
でもWin32APIのハンドルで隠れてる部分がわからん。Win32勉強しなきゃ・・・
374:マイク ◆yrBrqfF1Ew
06/03/23 16:00:05
今時意味不明なMFCに束縛されてる奴なんてただのチンカスですよ。
要領いい奴はQtで明瞭簡潔に終わらすよ。
375:デフォルトの名無しさん
06/03/23 19:47:44
チンカスが何かほざいているようです。
376:デフォルトの名無しさん
06/03/26 08:45:39
デメリットを挙げて「使う理由がない」というならまだしも
「意味不明」というのは、単に理解できていないだけだろう。
まあ、このコテは元々そういう奴だからな。
377:マイク ◆yrBrqfF1Ew
06/03/26 19:38:55
MFCに必死になってる奴って頭悪そうだな。
一生底辺でしょうね。
378:デフォルトの名無しさん
06/03/26 20:57:25
Qtがキモーイって言われたからといってMFCに八つ当たりしないでください。
379:デフォルトの名無しさん
06/04/11 17:09:20
MFCってサポート停止決定でしたっけ?
380:デフォルトの名無しさん
06/04/11 18:45:22
OWLってまだつかえる?つうか、まだ手にはいる?
381:デフォルトの名無しさん
06/04/11 18:57:54
OWLは手に入るお。
382:デフォルトの名無しさん
06/04/11 19:10:54
>>381
アリガト
それと何処で?見つかんないよ。
ウワ~ンヽ(`Д´)ノ
383:デフォルトの名無しさん
06/04/11 19:32:23
>>379
んにゃ、まだの筈。
384:デフォルトの名無しさん
06/04/11 20:24:25
>>382
URLリンク(www.borland.co.jp)
C++の機能を活かしたクラスライブラリObjectWindows (OWL) 5.0によって、タブ付きウィンドウやドッキングツールバーなど多くの機能を32ビットと16ビットの開発に利用できます。また、データベースアプリケーションの開発にも対応しています。
385:382
06/04/11 21:52:31
ありがとん。
386:デフォルトの名無しさん
06/05/01 18:22:13
ダイアログを1個単位でライブラリ化する方法を教えて下さい。
387:デフォルトの名無しさん
06/05/02 06:10:23
コモンダイアログを参考に
388:デフォルトの名無しさん
06/05/02 10:34:04
ダイアログ1個をライブラリ化できないようなクソライブラリを何で使うの?
389:デフォルトの名無しさん
06/05/02 11:08:36
>>388
意味不明。
「ダイアログ1個をライブラリ化できない」のは >>386 の資質に因るもの。
390:デフォルトの名無しさん
06/05/02 11:16:05
>>389
ダイアログが、1プロジェクトのrcファイルに全部入って、
他プロジェクトで使えないんですが、
どうしたら良いんですか?
とにかく回答下さい!!!!!
391:デフォルトの名無しさん
06/05/02 11:23:52
男なら、MFCなんて軟弱なもの使わないで、
Cのみでwinmainから書けよ!
392:デフォルトの名無しさん
06/05/02 11:48:20
>>391
だから、何で?
393:デフォルトの名無しさん
06/05/02 12:44:37
comdlg32.dllみたいなdllにすればできるだろ
ウイザードでMFC dll だ
394:デフォルトの名無しさん
06/05/02 13:02:39
>>393
そんなバカな作り方があるか!!!!!
普通に作れて、さらに、ライブラリ化が出来るからソフトウェアだろ。
DLL一杯作って苦労するんかよ、ドアホ
395:デフォルトの名無しさん
06/05/02 13:10:09
お前の言う普通ってなんだ?
例えばどういうライブラリを言ってる?
396:デフォルトの名無しさん
06/05/02 13:14:56
普通に開発できて、かつ、作ったダイアログを他のプロジェクトで使える、
という、物凄く超普通にやること。
それが、MFCで普通に作るとプロジェクトのrcファイルに全ダイアログ入るから、ライブラリ化できない。
ちょー^-0---ゴミMFC
397:デフォルトの名無しさん
06/05/02 13:22:59
>>392
それが男の生き様ってぇやつさ。
>>390
先ず、質問しようとしているスレがそういうスレかどうか判断しろ。
次に、検索の仕方くらい身に付けろ。
[MFC リソースファイル 分割]
398:デフォルトの名無しさん
06/05/02 13:34:27
リソース分割できたところでresource.hに連番振ってるの何ともならない。
やっぱゴミーーーーーーーーーーーーーーーーーーー
399:デフォルトの名無しさん
06/05/02 13:40:11
MFC使わないでSDKのみだって普通につくれば同じ
リソースは何も違わないけど
400:デフォルトの名無しさん
06/05/02 13:43:36
>>399
ウソ付けーーーーーーーーーーーーーーーーーーーーー
VC++のリソースエディタがリソースファイル管理するだろうが。
401:デフォルトの名無しさん
06/05/02 13:49:29
お前の言ってる普通の意味がよくわからんから
MFC以外でその普通のやりかたを解説してるサイトを出せ。
402:デフォルトの名無しさん
06/05/02 13:50:15
普通のやりかたなんだからすぐ簡単に見つかるよな
403:デフォルトの名無しさん
06/05/02 14:24:02
>>398
無知が恥の上塗りか。
リソースのインスタンスを別にするなら
ID は重複していても構わない。
404:デフォルトの名無しさん
06/05/02 14:28:44
>>402
じゃあなんで、CDialogを派生したクラスが、フリーのライブラリとしてネットととかに溢れてないわけ?????????????????????????????????????????
405:デフォルトの名無しさん
06/05/02 14:34:26
>>403
IDを振る事自体がOOPから外れてるということが分からないの?
IDを振る事自体がOOPから外れてるということが分からないの?
IDを振る事自体がOOPから外れてるということが分からないの?
IDを振る事自体がOOPから外れてるということが分からないの?
IDを振る事自体がOOPから外れてるということが分からないの?
IDを振る事自体がOOPから外れてるということが分からないの?
IDを振る事自体がOOPから外れてるということが分からないの?
IDを振る事自体がOOPから外れてるということが分からないの?
resource.hはresource1.hとか2.hとか量産するの?
406:デフォルトの名無しさん
06/05/02 14:36:06
普通はコピペするからわざわざライブラリ化なんかしない
407:デフォルトの名無しさん
06/05/02 14:36:54
× 普通はコピペするからわざわざライブラリ化なんかしない
○ MFCではライブラリ化できない
408:デフォルトの名無しさん
06/05/02 14:45:39
コピペ開発に対するアンチテーゼとかアウフヘーベンからクラスライブラリが出てきたんじゃないの?
コピペ開発に対するアンチテーゼとかアウフヘーベンからクラスライブラリが出てきたんじゃないの?
コピペ開発に対するアンチテーゼとかアウフヘーベンからクラスライブラリが出てきたんじゃないの?
コピペ開発に対するアンチテーゼとかアウフヘーベンからクラスライブラリが出てきたんじゃないの?
コピペ開発に対するアンチテーゼとかアウフヘーベンからクラスライブラリが出てきたんじゃないの?
MFCが出てきた当初から手間が減らないという不思議なライブラリでありながら、
SDKな人たちが「今までだってそうだったでしょ」と疑問を持たなかったという経緯もある。
409:デフォルトの名無しさん
06/05/02 15:04:38
だからお前の言う普通のやり方を解説してるサイトを早く出せ
お前の妄想なんか聞いたってしょうがない。
現実に存在するものを出せ
410:デフォルトの名無しさん
06/05/02 15:06:52
409=MFCでダイアログをライブラリに出来ると妄想してたゴミ
409=MFCでダイアログをライブラリに出来ると妄想してたゴミ
409=MFCでダイアログをライブラリに出来ると妄想してたゴミ
409=MFCでダイアログをライブラリに出来ると妄想してたゴミ
409=MFCでダイアログをライブラリに出来ると妄想してたゴミ
411:デフォルトの名無しさん
06/05/02 15:10:51
>>405
>>398 が誤りなのは同意して頂けたようで何より。
ところで、問題なのは「リソースインスタンス単位で一意でなければならない」という
制約であり、それと OOP との間に何の関係が?
つか、必死に見えるんでそーゆー書き方やめとけ。
412:411
06/05/02 15:13:36
>「リソースインスタンス単位で
いかん、主語が抜けている…
「ダイアログIDは、リソースインスタンス単位で
に訂正。
413:デフォルトの名無しさん
06/05/02 15:14:16
>>411
405の最後の1行解決してないよ。バカじゃないの?
405の最後の1行解決してないよ。バカじゃないの?
405の最後の1行解決してないよ。バカじゃないの?
405の最後の1行解決してないよ。バカじゃないの?
405の最後の1行解決してないよ。バカじゃないの?
414:デフォルトの名無しさん
06/05/02 15:14:52
>>412
バカな内容に訂正は要らないよ。
バカな内容に訂正は要らないよ。
バカな内容に訂正は要らないよ。
バカな内容に訂正は要らないよ。
バカな内容に訂正は要らないよ。
415:デフォルトの名無しさん
06/05/02 15:16:48
>>411
>ところで、問題なのは「リソースインスタンス単位で一意でなければならない」という 制約であり
IDEが勝手にヘッダーに連番振るからライブラリ化し難いんだろ。
416:デフォルトの名無しさん
06/05/02 15:29:27
>>413
ライブラリ化する場合、プロジェクトは別になる。
ということは、ライブラリ側の resource.h がどうなっていようと
そのライブラリの使用者に何の影響もない。
そんなことも解らないのか。頭悪いなあ。
で、OOP は何の関係が?
417:デフォルトの名無しさん
06/05/02 15:38:48
>>416
もしかしてそのライブラリってDLLのこと?
前提全然理解してないじゃん。頭悪いな。
・ダイアログ1つ1つをDLLにすると開発効率悪杉
・DLLは派生出来ないのでOOPにならない
418:デフォルトの名無しさん
06/05/02 15:48:00
>>417
>もしかしてそのライブラリってDLLのこと?
いや、DLL に限定した覚えはない。
>・DLLは派生出来ないので
誤り。
419:デフォルトの名無しさん
06/05/02 16:03:03
>>418
それって、IDEでペタペタコントロールを貼りながら、ダイアログ単位にリソースファイルを分けれるってこと?
420:デフォルトの名無しさん
06/05/02 21:08:41
DLLにせず、"*.lib"、"*.rc"を使う限り、MFC(VC)では無理な気が…。
他のBCBとか.NETとかは使ったことないんでよく分かんないんですが。
ところで、ちょっと気になったんですが、MFCの場合、動的コントロールって
どうやって実現するんでしょうか?
以前の勤務先の先輩が、そういうMFCライブラリ(動的にボタン等を配置)を作った経験が
あるという話をされてて、その時、私はVB6だったので気にも止めてなかったんですが、
今となっては結構謎です。
421:デフォルトの名無しさん
06/05/02 21:21:03
動的に配置ぐらいできる
422:デフォルトの名無しさん
06/05/02 21:28:09
コントロールはウィンドウだから移動や表示、非表示は自由にできる。
あとリソース使わないでコードでコントロールを動的に表示することも可能。
423:420
06/05/02 21:37:50
>>421
>>422
MoveWindow、ShowWindowは使ったことあるんですが、
"リソース使わないで…"が分かりませんでした。
キーワードを教えて頂けないでしょうか?
424:デフォルトの名無しさん
06/05/02 21:43:12
CreateWindow
425:デフォルトの名無しさん
06/05/02 21:47:21
MFCの場合は CButton::Create とか
426:423
06/05/02 22:33:21
>>424
>>425
ありがとうございます。試してみたらできました。フォントが妙に大きく表示されるのは、OnPaintをいじってないからかもしれませんが…。
CXXXDlg::OnInitDialog()
{
CDialog::OnInitDialog
m_pEdit = new CEdit;
CRect rc(10, 10, 110, 33);
m_pEdit->Create(WS_CHILD | WS_VISIBLE | WS_TABSTOP | ES_AUTOHSCROLL | WS_BORDER, rc, this, NULL);
return TRUE;
}
void CXXXDlg::OnDestroy()
{
CDialog::OnDestroy();
m_pEdit->DestroyWindow();
delete m_pEdit;
}
427:デフォルトの名無しさん
06/05/03 11:20:34
>>420
BCBは、1つのフォームが、Form1.h/.cpp/.dfmになっててプロジェクト情報とは完全独立。
さらにフォームの派生の派生もIDEで出来る。
イベントハンドラ内で上位イベントハンドラコールまでIDEがメンドウ見てくれる。
428:426
06/05/03 11:47:35
>>427
BCBいいですねぇ。どこかで、OWLの流れを汲むVCLのオブジェクト指向は
完全なオブジェクト指向で、MFCはWin32APIラッパとしてのためだけの
オブジェクト指向だと聞いたことがあります。BorlandのIDE事業売却は残念ですが…。
MSもMFCを見捨ててWinForms(C++/CLI)なんて.NET依存のものを作らずに、
ネイティブで真のオブジェクト指向のクラスライブラリ・IDEを作って欲しいですね。
429:デフォルトの名無しさん
06/05/03 14:55:24
問題は何を持って「真のオブジェクト指向」と見做すかと言うことだ。
430:デフォルトの名無しさん
06/05/03 16:59:51
>真のオブジェクト指向
こんなもの追求するなら、
クラスベースという中途半端なもの捨てるしかないっしょ。
誰もそんなもの望んでない。
431:デフォルトの名無しさん
06/05/03 17:02:23
>>419
それで419にとっての疑問は解決したのかな?
俺は日曜プログラマーで無茶苦茶にシロウトくさい人間だ。
そんなヘタレにとってDialogの使いまわしは非常に重要だったのでやり方を覚えた。
(カスみたいなチッポケなプログラムなのでその程度でも大変に思えるということなんですがね)
ヘタレの俺のやり方を書いてみる(貧乏臭くVC6ですヨ)
新しくプロジェクトを作った後、[ファイルを開く]で使いたいダイアログの入っているプロジェクトの
フォルダに行って***.rcをクリック、explore風の表示でDialogフォルダを開けて欲しいダイアログを
新しいプロジェクトのリソースに、まんまドラッグする。(ここで移動じゃなくコピーするを択ぶ)
ListViewとかではICONも必要なので同じようにドラッグでコピーする。
これだけでOK
あとはダイアログのクラスとか勝手に作りたがるので可能なら同じ名前で作ってしまう。
そして、今度はそのコピったダイアログクラスの*.h,*.cppの中味をザックリ入れてOK
ダイアログクラスそのものに実装は終わり。
あとは好きに料理する。
ま、これは俺と同じで日曜プログラマ用なんだろうがこれを見出すのに俺は時間が掛かったw
ので役に立つかもと書いてみた。
432:デフォルトの名無しさん
06/05/03 22:17:15
>>431
それってコピペコーディングであって、
ライブラリでも何でもねーじゃん、ダッせー。
>あとは好きに料理する。
あほか。
433:デフォルトの名無しさん
06/05/03 23:02:10
>>432
431はライブラリとは書いてない。
自分の振った話題しか見えないのはキミが低脳だからなのが解るか?
またダサくない方法も提示できないのであれば、低脳な上にカスでもあるw
わかったかいカス
434:デフォルトの名無しさん
06/05/03 23:32:24
>431はライブラリとは書いてない。
言語~開発環境で、ライブラリ化出来ないものに存在意義あるの?
435:428
06/05/03 23:50:50
荒れますね…。まぁスレタイがスレタイなのでしょうがない気もしますが…。
リソースを使わないクラス化というのであれば、こんなのもあるようです。
URLリンク(msdn.microsoft.com)
436:デフォルトの名無しさん
06/05/03 23:51:16
コードの全てはライブラリであるべきだと?
437:デフォルトの名無しさん
06/05/04 00:10:28
ちょっと読み間違い。誤解を生む文章だったかも。
ソフトウェアの開発ツールでありながらライブラリ化を上手くできないのは如何なものかと、
といいたいだけ。
438:デフォルトの名無しさん
06/05/04 00:13:19
ライブラリ化に関しては>>427-428 みたいなものもあるし、
C丼もそういうつくりになってるらしいし。
439:デフォルトの名無しさん
06/05/04 06:16:07
リソース関係は容量食うからDLLが一般的なだけで
スタティックリンクやろうと思えばできそうな気もするな
同じリソースを全部のEXEに持たせるのはアホらしいから
馬鹿以外はそうしないだけなのかも
試してからできないと言ってるんだろうか?
440:デフォルトの名無しさん
06/05/04 09:09:17
rcをインクルードしたらできた
ということで
>1-439はアホ
441:デフォルトの名無しさん
06/05/04 13:04:46
で、>>427-428 をMFCでやろうとしたらどうすれば良いの?
VC++のIDEでポトペタしながら。
442:デフォルトの名無しさん
06/05/04 13:11:34
コピペのやり方ならでてたじゃん
リソース開いてドラッグドロップ
443:デフォルトの名無しさん
06/05/04 13:15:56
コピーじゃだめ。
ソース共有したいんだから。
だって片一方のプロジェクトで拡張しても、もう片一方が古いままじゃん。
ソース共有はソフトウェアの基本!
444:デフォルトの名無しさん
06/05/04 13:33:58
#incllude すりゃいいじゃん
445:デフォルトの名無しさん
06/05/04 13:39:49
>>444
おまい、MFCがresource.hを固定で持ってることや、
rcファイルに全ダイアログリソース持ってること知らんだろ。
446:デフォルトの名無しさん
06/05/04 13:44:04
MFCじゃなくてVC++のIDEでダイアログ作ると、
resource.hが固定だったりrcファイルが1つに固定だったりするのがガンなんだな。
これが>>427-428のようになれば便利なんだが。
447:デフォルトの名無しさん
06/05/04 13:45:54
VCのリソースはrcファイルに無くても書けるんだな。
ソースファイルに。
これは、MFC以前の話だな。
448:デフォルトの名無しさん
06/05/04 13:46:37
>>443
もう一方が古いままw
あたりめーじゃねーか、完成したものにリソース改変の副作用を与えてどうする?
てかスゲー馬鹿だろオマエ
449:デフォルトの名無しさん
06/05/04 13:49:38
>>447
つ >>446
>>448
おまえは本当に馬鹿なやつだな。
そうくると思ったが、CVSでバージョン管理してるから問題無いし、
ソース共有出来ない理由が「副作用」だなんて、キチガイの中のキチガイ。
共有できない世界ってのはソフトウェアの特性が無いってこと!
それハードウェア。
450:デフォルトの名無しさん
06/05/04 13:51:14
もう一つ書いとくと、
>あたりめーじゃねーか、完成したものにリソース改変の副作用を与えてどうする?
副作用にすべきじゃない部分をベースクラス、
そのプロジェクトの固有部分を派生クラスにすんじゃね?
BCBなら完璧にそれできるぜ。
451:デフォルトの名無しさん
06/05/04 13:55:01
変なレスがきそうなんで書いとくが、
BCBではフォームに関して、
副作用にすべきじゃない部分をベースクラス、
そのプロジェクトの固有部分を派生クラスに出来る。
CDialogに関してコピペしか手が無いのが、VC++IDE/MFC。
452:デフォルトの名無しさん
06/05/04 13:57:35
何をどう言い訳しようが、
クラスライブラリである限り大前提の特性がある。
基本部分が既にあって差分を記述するだけで開発出来る。
コピペが必要なクラスライブラリは飛んでもキティのカタワライブラリ。
453:デフォルトの名無しさん
06/05/04 13:58:34
MFC使いは頭がカタワ。
454:デフォルトの名無しさん
06/05/04 14:01:13
WTLってポトペタした画面を別プロジェクトで使ったり、
さらにそれにポトペタできるんだっけ?
455:デフォルトの名無しさん
06/05/04 14:04:44
そういう考えならアイコンも継承しないとだめだな
456:デフォルトの名無しさん
06/05/04 14:06:27
455=頭がカタワ
オマ、もう不要。
別にレスしなくて良いから。
457:デフォルトの名無しさん
06/05/04 14:08:47
C++じゃないリソースを継承しろっていわれてもな
458:デフォルトの名無しさん
06/05/04 14:13:37
リソースを継承しろと逝ってるんじゃない。
i) IDEでCDialogにポトペタしたCMyDialogを他プロジェクトで使えるようにしろってこと。
ii) さらに別プロジェクトでCMySpecialDialogに継承出来たら理想だなってだけ。
で、おなじ事をBCBなら何も考えなく出来る。
フォーム単位でファイルが分かれてるからプロジェクトに組み込むだけ。
459:デフォルトの名無しさん
06/05/04 14:15:22
アイコンは.iconファイル、ツールバーならbitmapファイルでフォルダーに存在するよ。
まんまコピペできる。
.rcファイルではパスを通してやってるだけ
or
stringテーブルで名前にパスを通してやってるだけ
460:デフォルトの名無しさん
06/05/04 14:16:17
そうか、普通に出来ることをMFCで出来ないから、
MFCばっか使ってる人には何の話か皆目検討もつかないって事か。
こういうのを不自由とかカタワという。
それでアイコンを継承しる!とかイミフメなレスが出てくるんだ。
461:デフォルトの名無しさん
06/05/04 14:17:23
フォーム単位でわけて別ファイルに保存
使いたいやつをinclude
462:デフォルトの名無しさん
06/05/04 14:18:37
>>461
>フォーム単位でわけて別ファイルに保存
これが、VC++のIDEでポトペタするときに不可能だから困ってんだな。
463:デフォルトの名無しさん
06/05/04 14:21:40
MFCを廃止した方が世の中幸せになりそうだな。
M$が社内ではMFCを使ってないように。
大体、M$はC++を流行らせないことによりオプソに対抗したわけだが、
MFCみたくキチャナイもので開発者からC++から遠ざけブビ厨を大漁生産した。
464:デフォルトの名無しさん
06/05/04 14:23:08
コピーしていらないやつ消せばいいだけ
465:デフォルトの名無しさん
06/05/04 14:24:42
464=頭がカタワ
オマ、平気でループさせるな。 >>451-452
466:デフォルトの名無しさん
06/05/04 14:29:39
IDEでダイアログ単位で別ファイルに保存
これは可能
467:デフォルトの名無しさん
06/05/04 14:31:30
CDialogクラス(だけ)は独自にClassを作れるよ。
CDialogはC~AppクラスがRuntimeとは別枠で作ってるから、Doc-Viewアーキテクチャ、基い、
Runtime、のカセから逃れられる。
468:デフォルトの名無しさん
06/05/04 14:32:13
>>466
resource.hとかダイアログ単位に別ファイルに可能?
rcファイルをダイアログ単位に別ファイルに可能?
その操作を書いてるサイトきぼん。
それが出来るならその通り使うから。
469:デフォルトの名無しさん
06/05/04 14:35:30
>>463
> M$が社内ではMFCを使ってないように。
というのは違うかもしれません。VC++6.0のIDE自体はMFCで開発されています。
(少なくともSpy++、DelendencyWalkerで確認した限りでは…)
458 にあることの実現は、現状のMFC(WTL含む)では不可能ですが、C++/CLI等で
WinFormsを使用すれば、リソースファイル(*.resx)が各フォーム毎に生成されるので
多分実現できるのじゃないかと思います。
470:デフォルトの名無しさん
06/05/04 14:37:48
#include
471:デフォルトの名無しさん
06/05/04 14:38:26
>>469
古いアプリにはMFC使ってるだろうが、MFCじゃなくて別のクラスライブラリを使ってるっていう記事見たお。
ドトネトはやなんだよ。というか、使う予定0。
472:デフォルトの名無しさん
06/05/04 14:43:27
URLリンク(msdn2.microsoft.com)
473:デフォルトの名無しさん
06/05/04 14:57:48
>>472
VC6だと、
表示>インクルードファイルの設定>コンパイル時に追加するファイル
だね
474:469
06/05/04 15:05:24
>>471
> 古いアプリには…
そのとおりです。VS2003のIDEでは、MFCを使わず、Officeと同様のGUI部品を使っているようですし、
加えて、VS2005のIDEでは、.NETランタイム依存となっています。
> ドトネトは…
まぁ、それは正直、私も同感です。M$がC++/CLIを強引にISO化したところで、
私はあれをC++の進化系と認めたくはありませんし、使いたくもありません。
>>472,473
"#inlude"ってなんのことだと思ってたら…orz。失礼いたしました。
475:デフォルトの名無しさん
06/05/05 14:56:29
>>449
> CVSでバージョン管理してるから問題無いし
使用経験ゼロのヤツ
> 共有できない世界ってのはソフトウェアの特性が無いってこと!
> それハードウェア。
ハードウェアがカスタムだと思い込むシロウト(PGAとかあるにはあるがナ)
オマエ勉強しなおせよ何もかも
476:デフォルトの名無しさん
06/05/05 22:15:16
うわ、 475新生キティだわ。こりゃすげ。
>> CVSでバージョン管理してるから問題無いし
>使用経験ゼロのヤツ
ちょ、、、、日本語でおkwww
CVSでバージョン管理して >>450 のように開発していくことを教えてあげてるからね。
>ハードウェアがカスタムだと思い込むシロウト(PGAとかあるにはあるがナ)
ちょ、、、、知ったかやめれ。FPGAだがや。
それからハードウェアというのは「独自基板」でカスタム。
それに財リンクスとか組み込んでFPGAするわけ。
で、FPGAは「ソフトウェア」だから。
論理的思考も出来ないようで、存在価値のないやつ乙!
477:名無し募集中。。。
06/05/06 01:32:51
>>475-476
酷い自演を見た
478:デフォルトの名無しさん
06/05/06 01:34:25
>>477
ソース or 根拠キボン
479:デフォルトの名無しさん
06/05/10 11:06:18
>CVSでバージョン管理して >>450 のように開発していくことを教えてあげてるからね。
日本語でおk
>それからハードウェアというのは「独自基板」でカスタム。
日本語でおk
>論理的思考も出来ないようで、存在価値のないやつ乙!
日本語でおk
480:デフォルトの名無しさん
06/05/23 01:23:44
>>476
PGAで通じるんだよ。
FPGAには色々なタイプがある、WriteOnceなものは配線を切るものもあるんだ
Xilinxのようなものは低速だというやつも居る。
ボードを触った経験ぐらいしかないカスはダマットレ
あとさ、高々ダイアログ程度をライブラリなどどホザク低脳がカスタムでハードとかってのは失笑するしかないな
オマエバカな学生だろ?それも実際には何もやったことのない
481:デフォルトの名無しさん
06/05/24 10:10:39
PGAっつーとパッケージのほうを思い出すな。
ゴルフツアーでもいいがw
482:デフォルトの名無しさん
06/05/24 13:06:03
480の文って1行1行繋がりが無いのは何で?それも全行。
スレの流れに沿ってないどころじゃなくて中身が存在して無い。
統●失調?
483:デフォルトの名無しさん
06/05/31 14:31:45
480の学生時代はバカで
何もやってなかったってことだろうか。
484:デフォルトの名無しさん
06/06/01 14:30:33
また初段から落ちた…
485:デフォルトの名無しさん
06/06/01 21:28:39
最初は「なんだこりゃ?」だったけどCOMとかオートメーションとかActiveXの勉強してみると
「またむりやりC++でくっつけたなぁMSは。でも、仕方ないか」と思えるようになってきたところ
勉強始めたところだから間違ってるかもしれないし、MFCというよりもVisualStudioがすごいのかも知れないけどね
どうもATLとかWTLを使えばもっと強力なのかもしれないけどそれは次に置いておいて
MFCで勉強をすすめるかな
486:デフォルトの名無しさん
06/06/01 21:44:54
>>485
勉強するならWTLを激しくお勧め。
きれいなソースで継承関係でもっさり感が80%減(MS社比)
VC++が出力する気味の悪いテンプレートに悩まされず、VCのバグに
巻き込まれにくい。
問題はドキュメントの数と認知度の低さ。趣味グラマーならWTL。
つーかMFCに勉強する所なんて無い。バッドノウハウの温床だよ。
487:デフォルトの名無しさん
06/06/01 21:47:59
WTLはVS2005 EEで使えないんじゃなかったっけ
488:デフォルトの名無しさん
06/06/01 22:02:41
>>487
使えない?(´・ω・`)
最悪make環境でも作れるぽ。効率悪いけどl。
489:デフォルトの名無しさん
06/06/02 00:46:39
意外とフレームワーク等を自作して使っている人って少ない?
490:デフォルトの名無しさん
06/06/02 00:48:50
Expressでも使えるようにできる
つーかMFCこそ使えないし
491:デフォルトの名無しさん
06/06/02 04:31:39
MFCのソースコードはもうAPIのサンプル集と思ったほうがいい
あれがオブジェクト指向だと信じられていた時代があった・・・
492:デフォルトの名無しさん
06/06/02 17:27:41
>>486>>489
WTLはATL抜きで使えないから俺も自作した。
ATL(の少なくともWTLに必要な部分)が自由に使えるのであれば、
文句無くWTLを使うんだけど。
493:デフォルトの名無しさん
06/06/02 17:36:32
>>492
Expressで使えるぞ
ATL3だがWTLはちゃんとサポートしてる
Express+WTLはExpressの存在理由だろう
494:デフォルトの名無しさん
06/06/02 22:35:11
>>493
Visual C++以外でもWTLを使いたいの。
495:デフォルトの名無しさん
06/06/03 19:00:37
MFCは、クソマクロや定数がちりばめられなければ
まだ使おうという気にもなるんだが・・・。
496:デフォルトの名無しさん
06/06/04 23:35:59
VBerにも使えるMFCには存在価値がある
497:デフォルトの名無しさん
06/06/05 08:38:13
>>496
断言するけど使えない。
C++を10倍難しいものにするMFC。
498:デフォルトの名無しさん
06/06/05 10:15:10
MFCだとメッセージ処理、WinAPIまでつっこまない(=時間の浪費)と
まともにプログラムできない。
それと国際化対応、スレッド、コンテナの直行性、モダンでないシリアル化がいまいち。
互換性が完全に足枷になってるんだな。(VC7.1Userです。VC8ってなんか変わったの?)
.NETはSTL.NETがまだ使えないので洗練されたコンテナが...
499:デフォルトの名無しさん
06/06/05 18:15:43
つまりVCL最強って琴田
500:デフォルトの名無しさん
06/06/05 20:48:07
いっそQTとか
501:デフォルトの名無しさん
06/06/10 07:03:23
MFCつかうと一気に実行ファイルサイズが10倍に?!
502:デフォルトの名無しさん
06/06/10 11:08:26
みんな!!MFCの悪口を言うなよ!
MFCも、今にきちんとするつもりなんだよ、きっと。
503:デフォルトの名無しさん
06/06/10 13:39:28
>>502
きちんとしようとした VB が VB.NET になったように
過去の互換性を捨てて MFC on .NET に!
…わりぃ、要らんわ。
504:デフォルトの名無しさん
06/06/10 13:51:44
Win32のラッパだからWin32があるかぎりMFCも使える。
Win32がなくなればMFCも不用
505:デフォルトの名無しさん
06/06/10 21:35:36
>>501
それはVCLwww
506:デフォルトの名無しさん
06/06/12 11:15:34
>過去の互換性を捨てて MFC on .NET に!
過去の互換性があるMFC on .NETも炒りませんが、何か?
507:デフォルトの名無しさん
06/06/12 20:54:47
∧,,∧
(;`・ω・) MFC on .NET
/ o━ヽニニニニニニフ))
しー-J
508:デフォルトの名無しさん
06/06/13 07:10:06
. n T
o E
F N /|
M C //
//
∧,,∧ // |
(;`・ω・)o  ̄ |
/ / |
しー-J
ウリャァ~
509:デフォルトの名無しさん
06/06/13 17:51:31
| | |
∧,,∧
(;`・ω・) noT MEN FC.
/ o━ヽニニニニニニフ))
510:デフォルトの名無しさん
06/09/06 16:09:14
VC++使ってますが、デバッグのトレースで、
STRCORE.CPPの240行目CString::CString(LPCTSTR lpsz)の中まで入ってしまいます。
入らない方法教えて下さい。
引数にCStringが有った場合、
ステップオーバー →メソッド通り越し
ステップイン →上記
で、困ってまつ。
511:デフォルトの名無しさん
06/09/06 16:26:39
MFCに嫌気が差したのなら使わないほうがいいよ。
512:デフォルトの名無しさん
06/09/06 17:30:01
>C++の効率的な勉強方法
>スレリンク(tech板)
240 名前: デフォルトの名無しさん [sage] 投稿日: 2006/08/21(月) 22:56:44
ノシ
(Turbo)C++からいきなりはいったくちです。
Cは本(初めてのCだったけなぁ)読んで流した程度。
borland系のGUIクラスライブラリはOO的に綺麗な設計
でそれを解析しながら仮想関数とか勉強したっけ。
MFCを先にやってたらと思うと背筋が寒くなる。
513:デフォルトの名無しさん
06/09/06 17:50:37
これは痛いな。
514:デフォルトの名無しさん
06/09/06 19:49:32
俺と全く同じなんだが、そんなに痛いのか。
515:デフォルトの名無しさん
06/09/11 04:19:05
漏れも Turbo C++ で OWL 使いまくってた
あれのおかげで OOP 理解出来たし
MFC の糞さも使う前から分かったので未だに使ってない
Win32API + 自前クラスライブラリでウフフ
516:デフォルトの名無しさん
06/09/11 08:08:13
>>515
>MFC の糞さも使う前から分かったので未だに使ってない
なんだかなぁ。
>Win32API + 自前クラスライブラリでウフフ
MFCより良ければいくらか商売になるよ。
517:デフォルトの名無しさん
06/09/11 09:13:53
>漏れも Turbo C++
名前で混乱させられるね。
>MFC の糞さも使う前から分かったので未だに使ってない
ウィザードでソースコードジェネレートした時点できちゃな杉だよね。
画面の着色に関してはペンとか生成してWin32と変わらないどころか、
見通し悪いくらい。
何にせよ、MFCのメジャーバージョンうpが停止されて、
他環境に広がらなくて良かった。
518:デフォルトの名無しさん
06/09/16 19:40:15
なんかの本でMSKKの奴が必死に弁解してたな。
「MFCはあれでよかったんだ!!汚いのはねらってやってたんだ!!」って
519:デフォルトの名無しさん
06/09/16 23:42:12
あんなにCみたいなキャストさせるのはヤメテ・・・
まぁこれはWin32APIの段階からキャストは必要だといわれればそうだけど
520:デフォルトの名無しさん
06/09/20 14:14:49
CString Str1, Str2, Str3;
として、
Str1 = Str2 + Str3;
って書けたっけ?
strcat等のstr系でしか書けなかったっけ?
521:デフォルトの名無しさん
06/09/26 09:56:36
書けるけど、漏れは Str1 += Str2; Str1 += Str3; と書く。
522:デフォルトの名無しさん
06/10/02 00:57:21
MFC便利!!
APIガリガリうざい。
523:デフォルトの名無しさん
06/10/02 08:23:48
MFC苦汁の選択!!
524:デフォルトの名無しさん
06/10/02 09:16:42
APIガリガリが上手くラップされてないのがMFC
525:デフォルトの名無しさん
06/10/03 01:38:04
うまくラップされているものはあるのか?
526:デフォルトの名無しさん
06/10/03 02:25:16
なにいってんだVCLにきまってんだろぼけ
527:デフォルトの名無しさん
06/10/04 00:52:05
お決まりの回答だ。つまらん
528:デフォルトの名無しさん
06/10/04 08:59:22
VCLは良いんだけど、フリーで組み込みに使えてポトペタできるライブラリきぼん。
529:デフォルトの名無しさん
06/10/06 00:29:04
作れたら何でもいいじゃん。
MFCもVCLも、過去の遺産だろ?
530:デフォルトの名無しさん
06/10/06 08:45:07
VCLは過去からの遺産だけど今も使える。
というか、VCLの代わりが無くて困ってる。
531:デフォルトの名無しさん
06/10/07 23:08:36
>>482
いや、キミに読めないというだけのこと。
480の内容は板違いネタだが普通に読める。
532:デフォルトの名無しさん
06/10/07 23:13:21
そうは言っても480のレスなど理解する必要も無いような内容だがな
482の無知はここの板であれば罪ではない範囲
「自分に理解できない内容=統合失調」って短絡は失笑ものではあるが
533:デフォルトの名無しさん
06/10/08 02:04:47
wxWidgetsに移ろうよ。
534:デフォルトの名無しさん
06/10/10 14:32:35
今酷い自演を見た
535:デフォルトの名無しさん
06/10/15 16:51:28
FOXに移ろう
536:デフォルトの名無しさん
06/10/27 04:45:24
つATL/WTL
537:デフォルトの名無しさん
06/10/29 02:51:41
PGやめようよ
538:デフォルトの名無しさん
06/10/29 05:31:43
PG(笑)
539:デフォルトの名無しさん
06/10/29 18:59:34
どうした?
PGがそんなに面白かったか?
540:デフォルトの名無しさん
06/10/29 19:35:21
反応したw
541:デフォルトの名無しさん
06/10/29 19:37:10
どうした?
反応がそんなに面白かったか?
542:デフォルトの名無しさん
06/10/29 19:45:22
かわいそうw
543:デフォルトの名無しさん
06/10/29 19:48:38
どうした?
かわいそうなのがそんなに面白かったか?
544:デフォルトの名無しさん
06/10/31 00:29:41
>>538-543 の幼稚なやり取りに嫌気がさした人の数↓
545:デフォルトの名無しさん
06/10/31 08:37:02
↑
おまいも用地
546:デフォルトの名無しさん
06/10/31 11:22:16
入れ食いw
547:デフォルトの名無しさん
06/11/08 13:31:59
URLリンク(www.kab-studio.biz)
MFCに移ったのですがあまりの設計の悪さに「Cプログラミング診断室」
(URLリンク(www.pro.or.jp))を初めて読んだとき以上の衝撃を受けました。
kabさんはMFCを結構押しているので申し訳ありませんがMFCは最悪のクラスライブラリです。
特にウィザードの吐き出すコードは正気を疑うものです。
548:デフォルトの名無しさん
06/11/08 13:42:31
なんだ尺八郎か
549:デフォルトの名無しさん
06/11/08 22:19:15
>>547
一貫性が無いって言うのは、確かにうなずけるな
最悪では無いと思うけど
550:デフォルトの名無しさん
06/11/09 08:40:02
>>549
最悪じゃないってことは、何よりマシってことよ?
551:デフォルトの名無しさん
06/11/14 00:02:47
だが、くそもっさりした.NETよりはぜんぜんよくないか?
C#は結局C++に挫折した奴が書くスクリプト言語でしょ
552:デフォルトの名無しさん
06/11/14 01:18:30
もっさりで、.NET Frameworkが必要なことに目をつぶることができるなら、
MFCより.NET Frameworkのクラスライブラリは大分まし。
553:デフォルトの名無しさん
06/11/14 08:37:19
世の中にはドトネトじゃないまともなクラスライブラリがあるわけだから、
M$のダサダサ開発環境捨てるべきじゃね?
ネイティブ、COM、ドトネトの三つ巴の関係を考慮しながら開発なんて超変だお。
554:デフォルトの名無しさん
06/11/14 12:00:05
>>551
>C#は結局C++に挫折した奴が書くスクリプト言語でしょ
いや、実行時にコンパイルされるCモドキのVB。
555:デフォルトの名無しさん
06/11/14 12:17:19
じゃ、ドトネトは巨大なVBランタイムか。
556:デフォルトの名無しさん
06/11/14 12:22:08
C++に挫折するやつはC#も書けない気がするけどなw
557:デフォルトの名無しさん
06/11/14 13:07:10
>>555
VBのランタイムライブラリは
予めコンパイルされているだけ、まだまし。
558:デフォルトの名無しさん
06/11/14 16:56:40
.NET Frameworkのクラスライブラリはインストール時にngenをかけていると聞いたことがある。
559:デフォルトの名無しさん
06/11/16 01:27:47
使えればなんでもいいじゃん。
中の実装なんて、どうでもいいじゃん。
いやなら、VCL(古臭い)でも使ってろよ。
560:デフォルトの名無しさん
06/11/16 08:42:40
.NET Framework 2.0 廃止予定の API 一覧
URLリンク(www.microsoft.com)
( <●><●>) ドトネト1.0~2.0廃止なのは分かってます
(U )つ
u u
古臭いVCL >>>>> WinFX >>>>>> MFC
561:デフォルトの名無しさん
06/11/16 22:52:48
↑
使いにくさですよね?
562:デフォルトの名無しさん
06/11/17 15:38:27
>>561
URLリンク(www.google.co.jp)
MFC 汚い の検索結果 約 12,900 件中 1 - 10 件目 (0.03 秒)
563:デフォルトの名無しさん
06/11/17 20:44:36
URLリンク(www.google.co.jp)
MFC 綺麗 の検索結果 約 41,800 件中 1 - 30 件目 (0.21 秒)
564:デフォルトの名無しさん
06/11/17 20:51:39
URLリンク(www.google.co.jp)
MFC 美しい の検索結果 約 69,900 件中 1 - 10 件目 (0.04 秒)
565:デフォルトの名無しさん
06/11/17 21:29:53
URLリンク(images.google.co.jp)
AV女優 の検索結果 約 22,800 件中 1 - 20 件目 (0.32 秒)
566:デフォルトの名無しさん
06/11/17 22:12:13
MFCが汚いなんていってる人って結局C++が理解できていないんだよね
567:デフォルトの名無しさん
06/11/17 23:21:52
>>566
あの酷いコレクションクラス設計からしてマトモなAPIじゃないよ。
568:デフォルトの名無しさん
06/11/17 23:37:55
Doc-Viewアーキのカセ、むしろ更に、APPとFrameとDocとViewにはめられているRUNTIMEの鎖が汎用性にはネックになる部分で
慣れれば、用途によりけり抜け道と言うか、持って行き方があるけど。
自動生成のソースを全て底のクラスの意味まで理解すれば、色々応用が使えるようになってくる。
確かに特にRUNTIMEはマクロ、テンプレ、仮想関数(実行時まで型を決めずにおける)満載で、ウィンドウ用途に限って言うと、C++を存分に使い切っている。
マルチウィンドウ、例えば、ブラウザではサイトによりFormは無限だが、同様にTreeViewで開いたモノにより、画面を変えるなんてのにはMFCは最強。
.NETは使ったことは無いから分からないが、ActiveXはコンポーネントの中身が見えないのと同様のものを感ずるが、MFCはソースとしてフルに見れる、確かに大量にはあるが、元を辿るぶんには結構な量ではあるが、半端無いわけじゃない。
そして、ちまたにあるできあがったコントロールを使うなら、非常に楽にできる、できるようになるまでがたいへんだけど。
が、クライアント用途以外を考えるなら、WINDOWS以外も考えなければならないのでMFCじゃ無理。
569:デフォルトの名無しさん
06/11/17 23:46:44
Doc-Viewがカセ?
ポトペタ環境がありがたいと感じるのは最初だけ。
C#やVBはポトペタ環境がマジうぜー
570:デフォルトの名無しさん
06/11/17 23:54:53
My Favorite Class-library
571:デフォルトの名無しさん
06/11/17 23:59:02
>>569
例えば、
ファイルダイアログ>開く・保存なんてのは、MFCじゃほんの数行でできるが(注:カセに則ってる分には)、
ファイルダイアログを開かずに直接、DATなりから自分が独自に作ったクラスにserialize使うなり、archive実装するとなると、最初はつまづくでしょ。
MFCの場合は、最初に壁があって、そこを超えると使いやすさが広大に開ける、そんなのが多い。
572:デフォルトの名無しさん
06/11/18 01:38:13
MFCの文句をいうならMFCで出来たものを使うなよ~~~~~~
573:デフォルトの名無しさん
06/11/18 02:27:18
.NETもReflectorでざっと読んでみたが糞設計だな・・・
574:デフォルトの名無しさん
06/11/18 12:22:57
Doc/Viewなんて、STLでDoc実装+Viewの描画にポトペタ部品の派生が最強。
結論:ポトペタ部品の派生が簡単なVCL最強。(DelじゃなくてBCB)
575:デフォルトの名無しさん
06/11/20 09:35:40
MFCがOOPになってないところ羅列
・描画中にCBrushとか自分で生成破棄する必要がある。
576:デフォルトの名無しさん
06/11/20 09:37:42
それはOOPとは関係ないだろ
577:デフォルトの名無しさん
06/11/20 09:58:30
ウィンドウが自分を描画するブラシぐらい持つべきだろ。
持ってないならクラスにならん。
578:デフォルトの名無しさん
06/11/20 09:59:50
MFCがOOPになってないところ羅列
・ダイアログのリソースが1ファイルに収まるため、別プロジェクトがダイアログクラスを普通に共有できない
579:デフォルトの名無しさん
06/11/20 10:07:24
それはOOPとは関係ないだろ
580:デフォルトの名無しさん
06/11/20 10:23:38
CDialogクラス派生した部品が他プロジェクトの派生部品となりえない・・・アリエナス
581:デフォルトの名無しさん
06/11/20 10:25:36
MFCがOOPになってないところ羅列
・ダイアログに貼る部品がActiveXであって、C++のclass宣言でクラス派生できない
582:デフォルトの名無しさん
06/11/20 10:28:53
それはOOPとは関係ないだろ
583:デフォルトの名無しさん
06/11/20 10:40:31
クラス派生できない→OOPではない
584:デフォルトの名無しさん
06/11/20 10:41:09
MFCはOOPとは関係ないだろ
585:デフォルトの名無しさん
06/11/23 22:21:16
つか、OOPとMFCは関係ない
586:デフォルトの名無しさん
06/11/23 22:27:14
はぁ?MFCにはOOPは関係ない
587:デフォルトの名無しさん
06/11/23 22:52:30
はぁ?OOPにはMFCは関係ない
588:デフォルトの名無しさん
06/11/23 22:59:37
もうちょっと変化に工夫を付けろ
589:デフォルトの名無しさん
06/11/23 23:36:15
はぁ?OPMにはCOFは関係ない
590:デフォルトの名無しさん
06/11/24 08:37:08
はぁ?KFCにはMACは関係ない
591:デフォルトの名無しさん
06/11/24 10:13:34
麻雀格闘倶楽部かと思った
592:デフォルトの名無しさん
06/11/26 19:54:07
あそこまで妙なマクロは使ってないけど、自作のC(not C++)のライブラリに似てて鬱だ>>MFC
593:デフォルトの名無しさん
06/11/28 17:17:55
ここは麻雀格闘スレですよ
594:デフォルトの名無しさん
06/11/28 22:22:52
そんな貴方にWide Studio
595:デフォルトの名無しさん
06/12/02 20:25:03
今後、.NETが浸透してネイティブアプリなんて必要なくなるのかな?
596:デフォルトの名無しさん
06/12/02 21:11:24
アプリケーションの必要性は使用されているライブラリやアーキテクチャには無い。
その有用性にあるのだ。
597:デフォルトの名無しさん
06/12/03 05:03:07
んなこと言ったらみもふたもない。
道具として何がよいかどうかの話なんでは。
598:デフォルトの名無しさん
06/12/03 05:33:58
漏れはもう、.NET/C#で事足りるなら、わざわざC++でネイティブアプリ作る気にはならないかも。
んで、実際大抵の用途には事足りる気がする。
599:デフォルトの名無しさん
06/12/03 07:19:52
ネイティブ実行ファイルが生成出来て
使いやすいC++のRAD開発環境があればいいけどね(M$製で)。
D言語 + RADでネイティブ吐く環境のがもっといいかも(やっぱM$製で)。
600:デフォルトの名無しさん
06/12/03 09:55:24
VC++とMFCでWinのプログラミングするのはほんと大変。
ある程度まともなアプリ書ける様になるまで3年かかった。
しかし未だ分からない事は山程あるので、まだまだ一人前とは言えないし。
601:デフォルトの名無しさん
06/12/03 13:01:16
MFCはウインドウのフレームだけでペインの中は自分でバリバリ書いてねってフレームワークだから、
RAD風にコントロールを並べてというのを期待するとCFormViewしかないので戸惑う。
C++ベースでRAD系の開発ツールはサードパーティにまかせて、あえてMSは出さなかったという話を
聞いたことがあるがソースが出てこない。BC++やVisual Age C++がそうだったのだろうか。
602:デフォルトの名無しさん
06/12/04 00:48:42
RADツールでもお客の要求などからコントロールを1から書くことが結構ある。
RADツールしかつかったことないひとはちょっとした変更でもできないなんていう。
たとえば、グリッドなんかでセルにボタンを配置してくれとか、コンボを配置してくれとか
簡単なのにできませんなんて・・・
603:デフォルトの名無しさん
06/12/04 00:59:27
そういえばMFCもけっこう使ったけど、CFormViewてほとんど使ったことないかもしれん。
604:デフォルトの名無しさん
06/12/04 01:06:39
ふつう使わない
605:デフォルトの名無しさん
06/12/04 02:14:46
Office2007はMFCなんでしょうか?
これからもパッケージソフトはC++でMFCなの?
C#とVBではプログラム作れるようになったけど、VC++でMFCもやっておいた方がいいんだろうか?
などと、学生は考えてしまいます
606:デフォルトの名無しさん
06/12/04 02:23:11
C#とVBは3日あれば覚えられる
607:デフォルトの名無しさん
06/12/04 02:27:49
事前にどういう言語知ってるかによるだろ
608:デフォルトの名無しさん
06/12/04 02:30:22
はぁ?
C/C++をしらない奴みたことないぞ
609:デフォルトの名無しさん
06/12/04 02:34:51
C#にはC/C++にない概念もあるだろ。
言語だけわかってもでっかいライブラリをある程度把握しないと何も出来きないし。
そういうのは他との対比ができれば理解が速いと思うけど。
VBは知らん。
610:デフォルトの名無しさん
06/12/04 13:22:21
すまん、VBでもmainから始めてた、偽装派遣で客先いくまで
611:デフォルトの名無しさん
06/12/06 19:46:56
どうでもいい
612:デフォルトの名無しさん
06/12/06 20:29:42
MFCかどうかはともかく、当分はC++の独占場だとは思う。
613:デフォルトの名無しさん
06/12/06 20:37:27
最近までVC6.0がメインで誰もC++を知らないC言語ワールドにいました。
614:デフォルトの名無しさん
06/12/06 21:07:20
>>613
Cだけ使ってる分にはVC6は軽くていいかもな
MSVCRT.DLLなら普通の環境にはデフォで入ってることが期待できるし
615:デフォルトの名無しさん
06/12/07 08:49:30
なんだかんだ言ってもいまだにVC6はインストールしてあるw
616:デフォルトの名無しさん
06/12/07 18:04:42
MFCってVC++2005でもサポートされるんだっけ?
MFCのメジャーバージョンうpとかどうなんでしょ。
617:デフォルトの名無しさん
06/12/07 18:16:26
VC++ 2005 (Std以上)にはMFC 8が付いている。
618:デフォルトの名無しさん
06/12/07 18:26:04
>MFC 8
VC++6のMFCと互換性おk?
619:デフォルトの名無しさん
06/12/15 00:54:53
俺はWEBアプリばかり作ってたから、未だにMFC未体験。
620:デフォルトの名無しさん
06/12/15 01:36:29
WEBとMFCになんの関係があるの?
621:デフォルトの名無しさん
06/12/15 01:55:01
どちらかというと、関係がないと言ってるように見えるのだが。
622:デフォルトの名無しさん
06/12/18 14:09:11
V$ドトネトに逝行してもMFC使ってる人っています?
逝行の致命的な問題とか無いでつか?
623:デフォルトの名無しさん
06/12/19 11:17:23
>CDialog1つに対してresource.hとrcファイルがあって、
>プロジェクトをダイアログ単位の部品クラスに分割できれば、
>まだ使えたようなキガスル
他のプロジェクトにダイアログをカレントプロジェクトにコピペといった使い方しかできないおね。
MFCのパワーユーザーとか、他のプロジェクトのダイアログをクラスライブラリとして使いまわせない事をどう思ってんだろ?
624:デフォルトの名無しさん
06/12/19 11:24:20
コモンダイアログ
625:デフォルトの名無しさん
06/12/19 11:28:58
>コモンダイアログ
MFCではない。
626:デフォルトの名無しさん
06/12/19 12:12:14
ダイアログテンプレート
627:デフォルトの名無しさん
06/12/19 12:18:12
Vi$taでもMFC使い続けますか?ドトネトにコンバートしますか?
628:デフォルトの名無しさん
06/12/19 12:43:53
>>623
ダイアログのリソース関連はまったく同意だなぁ
新しいプロジェクトはDLL化して分割管理しているからまだマシだけど
ずっとメンテナンスしてるプロジェクトがダイアログリソースだけでが250くらいあって
もうどうしようも無い感じなってきてる
629:デフォルトの名無しさん
06/12/19 13:20:11
ダイアログリソースって壊れやすいから嫌い。
変なマクロもぶちまけるし。
ソースとリソースを相互変換するツール作ればいいだけじゃ?
630:デフォルトの名無しさん
06/12/19 13:49:19
>ソースとリソースを相互変換するツール作ればいいだけじゃ?
つ BCBなら1ダイアログが3ファイル(.h/.cpp/.dfm)
631:デフォルトの名無しさん
06/12/19 13:52:19
ダイアログテンプレート
632:デフォルトの名無しさん
06/12/22 02:38:35
厨な質問だと重々承知しておりますが質問します。
WindowsオンリーであればMFC使った方がいいですかね?
世間の評価が気になるのですけど、MFC?:( ´,_ゝ`)プッてな感じになりませんか?
633:デフォルトの名無しさん
06/12/22 07:38:32
>>632
お好きなように。
>MFC?:( ´,_ゝ`)プッてな感じになりませんか?
MFC でも何でも、マトモなものが作れてるなら問題ない。
634:デフォルトの名無しさん
06/12/22 08:46:43
C/C++プログラマへアドバイス
URLリンク(www.01-tec.com)
(個人的にはMFCは VC++ の唯一の汚点だとも思っています^^;)ので、Windows系のプログラムを作るならこれ↓
635:デフォルトの名無しさん
06/12/22 09:01:25
いや・・・さすがにMFCとSTLを同列で扱ってたりするような糞サイトは参考にならんと思うが・・・
636:デフォルトの名無しさん
06/12/22 09:10:27
>MFCとSTL
MFCのCStringとstd::string問題を扱ってるだろ。
635=その問題を知らないとはC++使ってるとは言えない。
637:デフォルトの名無しさん
06/12/22 09:10:45
パソコンだって箱より中身の方が大事なわけだし
それがわかってれば箱なんか気にしない
638:デフォルトの名無しさん
06/12/22 09:12:10
URLリンク(program.station.ez-net.jp)
□ Visual C++ の互換性…
Visual Studio .NET を買って早数日…。
COM コンポーネントのバージョンアップを図るべく Visual C++ 7.0 にて ATL COM のプロジェクトをコンパイルしなおすことになりました。
□ MFC 7.0 と ATL 7.0
□ 変更点の補足
□ エラーを取り除く…
□ COM 動かず…
639:デフォルトの名無しさん
06/12/22 09:13:29
意味わかんないです(><)
URLリンク(www.microsoft.com)
System.Windows.Forms.Form
ApplyAutoScaling()
メッセージ : このメソッドは非推奨になりました。
代わりに、ApplyAutoScaling メソッドを使用してください。
.NET Framework 2.0 廃止予定の API 一覧
URLリンク(www.microsoft.com)
( <●><●>) ドトネト1.0~2.0廃止なのは分かってます
(U )つ
u u
640:デフォルトの名無しさん
06/12/22 09:24:10
>>636
std::stringはSTLじゃないよ。
641:デフォルトの名無しさん
06/12/22 09:30:03
MFCもSTLもstringもC++のライブラリ。
同列に並べずどうする?
642:デフォルトの名無しさん
06/12/22 09:41:51
Windowsプログラミングを行うためのライブラリであるMFCと
標準ライブラリを同列に並べるの?libgnomeとlibcぐらい違うでしょ。
MFCのごく一部がC++標準ライブラリと被ってるのは確かだ。
だからMFCのコンテナを使うくらいならSTLのコンテナを使いましょうと言うならまだ分る。
要はMFC全体は標準ライブラリと排他的に選ぶものではないということ。
643:デフォルトの名無しさん
06/12/22 10:02:05
サイトには、
>MFC はC++のお手本として良い題材とは思いません。STL の勉強をお薦めします。
と書いてあるから、排他してなくて、勉強時にはMFCとSTL比べたらSTLを選べと言ってる。
>要はMFC全体は標準ライブラリと排他的に選ぶものではないということ。
おまいのいいがかりじゃん。
644:デフォルトの名無しさん
06/12/22 10:17:32
よく読めよ。MFCを勉強するかSTLを勉強するかではなく、
C++を勉強する時に使うべきはSTLかMFCかとおっしゃってるわけだが。
645:デフォルトの名無しさん
06/12/22 10:21:02
>C++を勉強する時に使うべきはSTLかMFC
C++を勉強するときに、STLとMFCと選ぶという行為は変じゃない。
その場合のSTLの選択も正しい。
で?
646:デフォルトの名無しさん
06/12/22 10:22:21
>STLとMFCと選ぶという
あ、ゴメンあいまいに書いちゃった。
C++勉強しよう。STLを勉強しようかな、MFCを勉強しようかな、という同列に並べた選択は変じゃない。
ごくふつー。
647:デフォルトの名無しさん
06/12/22 10:28:15
まぁ、MFC使って、
AppWizardの吐き出したコードの汚さに目が点、
画面に使えるコントロールが少ない、
それでも画面を何とかするにはActiveX使うしかない、
という流れでどうせ頓挫するさ。
という意味では、一旦MFC漬かってみれば結論でるお。
648:デフォルトの名無しさん
06/12/22 10:44:40
> C++勉強しよう。STLを勉強しようかな、MFCを勉強しようかな
作れるものが全然違うから同列に出来ないと俺は思ってる。
何かを作るのが目的でC++を勉強するってのが俺のスタンスだからだろうけど。
MFCを使ったコンソールアプリを作るのがMFCの勉強とは思えない。
堂々巡りでスレ汚しになる予感だ。
ケチ付けた方からで悪いが、この件はMFCの糞さとは関係ないからここら辺にしておこう。
649:デフォルトの名無しさん
06/12/22 12:39:33
>作れるものが全然違うから同列に出来ないと俺は思ってる。
「作るものが~」という文脈は、作るのが目的の場合。
勉強する場合作るものはある程度何でも良くて、C++文法やクラスライブラリ構造の1例理解がターゲットだったりするわけ。
650:デフォルトの名無しさん
06/12/22 16:29:04
もうObjective-CとCocoaに移行すればいいじゃん。
そうすれば糞面倒なC++とMFCにもおさらば。
651:デフォルトの名無しさん
06/12/22 17:11:43
C++が面倒(やっぱ、慣れるまではちょっと面倒)なんじゃなくて、MFCが面倒。
それから、C/C++系ライブラリは必要、MFCは必須ではない。
652:デフォルトの名無しさん
06/12/22 20:38:30
一度でいいから見てみたい。
MFCを使わずにC++とWin32APIで
クラスの概念の存在意義を見いだせる書き方をされたコード。
653:デフォルトの名無しさん
06/12/22 21:02:05
ATL/WTLはどうですか?
654:デフォルトの名無しさん
06/12/25 08:47:03
>MFCを使わずにC++とWin32APIで
C言語とC関数ライブラリでひとかたまりのように、
C++とクラスライブラリで一セット。
分離はできない。
MFCを別のクラスライブラリに差し替えるのが正しい。
655:デフォルトの名無しさん
06/12/25 11:34:32
小物を沢山作る人なんかは自分で小さいクラスライブラリを作ってる事もあるね。
漏れも昔はやってた。
656:デフォルトの名無しさん
06/12/26 04:41:55
サードパーティの有料コンポーネント使った方が速いというか
657:デフォルトの名無しさん
06/12/26 20:37:28
サードパーティの有料コンポーネントってびみょーなのが多い
なんだこの程度のコンポーネントで売り物になるんだと思うことがほとんど。
自作したほうが、早い
658:デフォルトの名無しさん
06/12/26 23:26:33
wcはcの入門書の例題によく出てくるから、まあ範疇でいいじゃない。
wc sed grep lsなど簡単なunixコマンドは大抵win32版がgnuその他のフリーウェアで
転がっているから、ググレば拾えるよ。
659:デフォルトの名無しさん
06/12/26 23:27:22
>>658
やや、誤爆った。スマソ。
660:デフォルトの名無しさん
06/12/27 09:16:40
今ってネットにフリーのクラスライブラリのソースそのまんまのコンポーネントが溢れてる時代だよね。
MFCはマジでその辺が無い。
661:デフォルトの名無しさん
06/12/27 09:20:26
漏れはCodeProjectでさんざん世話になったが・・・
662:デフォルトの名無しさん
07/01/03 15:22:16
ほっしゅ
663:本田
07/01/03 19:07:29
>>652
URLリンク(owlnext.sourceforge.net)
664:デフォルトの名無しさん
07/01/12 10:24:15
>永久プログラマー
>URLリンク(www.est.co.jp)
マイクロソフトC/C++7.0とクラスライブラリMFC1.0を使って、アプリケーションを作り始めた。
半分ほどプログラミングした時点でVisualC++1.0が米国で出荷された。
その開発環境の良さやMFC2.0の高級な機能に刺激されて、VC++に開発環境を移行した。
MFC1.0は、Win16APIにクラスライブラリの皮を被せただけの簡単なものである。
彼はこの上に、独自の高級なクラス構築していたのだが、MFC2.0が見事にそれを葬ってくれた。
MFC2.0に合わせて、モジュール構造から作り直すのに6ヵ月ほどを費やした。
665:デフォルトの名無しさん
07/01/13 13:25:12
>>664
>久遠のプログラマー
マイクロソフトC/C++7.0はMFCなどの分厚いマニュアルが何冊も付いてきて、
パッケージの幅が50cmはあったと思う。
これを抱えたまま秋葉原駅の階段で転倒。腕の骨を骨折するに至った。
666:デフォルトの名無しさん
07/01/14 02:10:59
ワロタ
667:デフォルトの名無しさん
07/01/14 03:28:18
>>660
CodeGuru
668:デフォルトの名無しさん
07/02/09 11:54:29
Vi$taでもMFC使える?
669:デフォルトの名無しさん
07/02/09 19:31:51
>668
おいしい情報を教えるよ。
僕が開発した、「馬鹿には見えないMFC」を使えば、Vistaでもツルツル動くよ。
格安で譲って上げるから、レスちょうだい。
670:デフォルトの名無しさん
07/02/09 20:50:33
ツルツルage
671:デフォルトの名無しさん
07/02/10 10:00:05
メモリーフローコントロール
672:デフォルトの名無しさん
07/03/21 03:27:23
>>665
VisualC++1.0の紙マニュアル付きを思い出す
あれ買って帰った人いるのかなぁ
673:デフォルトの名無しさん
07/04/01 18:21:49
あげあげ
674:デフォルトの名無しさん
07/05/02 11:35:58
MFCに四苦八苦しながらもようやくまともにアプリ書けるようになったと思ったら
.NETにWin64APIですか…orz
675:デフォルトの名無しさん
07/05/02 15:15:49
>>674
MFCよりゃ癖もなくて楽だと思うけどね。
676:デフォルトの名無しさん
07/05/05 23:08:13
MFCにかわるものはあるんですか?
(個人的にMFCは嫌いじゃない)
677:デフォルトの名無しさん
07/05/05 23:09:23
MFCの様にやりたいなら、MFCが一番だろw
678:デフォルトの名無しさん
07/05/08 10:40:50
MFC(GUIイマイチ) + VCL(某製) → .NET(モッサリ)
679:デフォルトの名無しさん
07/05/11 20:43:21
まぁ所詮「イジワルC++」ですから。
680:デフォルトの名無しさん
07/05/12 00:07:23
なんか、OrcasだとMFCも Vista対応されるんだな。
681:デフォルトの名無しさん
07/05/12 18:26:10
mfcはそこそこosに近い所で動きながらそこそこラクができるのが
いいんじゃないの。CWndベースで何でも作れるやん。
682:デフォルトの名無しさん
07/05/13 15:52:29
あれだなんだっけ?
メモリデバイスコンテキストとかセレクトオブジェクトで取得したもんを
開放したり確保したりかってにやってくれるのがいい
アレ、自分でやると開放していいのか悪いのかさっぱりわからん
あと、トラッカークラスとかいいw
683:デフォルトの名無しさん
07/05/14 09:36:10
>CWndベース
このクラス、Win32APIがくっついてるだけで、
変数も内部に保持しないわ、
楽にしてくれるメソッドは無いわ、
超スペシャルカス設計。
684:デフォルトの名無しさん
07/05/14 11:03:01
もともと、単なるラッパーとして設計されたクラスだもの。
685:デフォルトの名無しさん
07/05/14 11:28:42
>単なるラッパー
いや、単なるラッパーでも内部に変数保持する筈だし、
便利なメソッドが付いてる筈。
㌧デモキチガイ設計だお。
686:デフォルトの名無しさん
07/05/14 12:50:59
MFCのステートのカオス度は異常
687:デフォルトの名無しさん
07/05/14 16:51:56
え?何を内部に変数保存するの?
688:デフォルトの名無しさん
07/05/14 16:55:12
よくわかんねーけどインスタンスだろ
689:デフォルトの名無しさん
07/05/14 17:02:42
CPenとか内部に保持してくれたりリリースしてくれたりしないのは変杉。
690:デフォルトの名無しさん
07/05/14 17:33:30
設計当時、GDI上のハンドルは全てキャッシュだからなぁ。
Win16/Win95時代の設計なんだよ。
だから、どうしても変な実装になる。
691:デフォルトの名無しさん
07/05/14 17:43:37
VCLならちゃんとした設計になってるよ。
各コントロールやウィンドウがCanvasっていう抽象クラスを持ってて、
Canvasクラスがペンやメソッド持ってるお。
692:デフォルトの名無しさん
07/05/15 09:09:01
apiを直に使うのに慣れてたら違和感ないだろう
apiとやり方が全然違うとかえって使いにくいし
693:デフォルトの名無しさん
07/05/15 09:17:47
>apiを直に使うのに慣れてたら違和感ないだろう
違和感ありあり。
apiの機能を端折ることなくメソッド追加できるのが、クラスベース言語&クラスライブラリ。
クラスライブラリが無ければ、apiのラップ自体が開発となるのに、
目の前にトンでも設計便利なところ無しクラスライブラリを目の前に置かれると目が点。
694:デフォルトの名無しさん
07/05/15 13:23:55
>691
その実装も問題ありだな。
つーか、OS/2だと、DCとPSって分けられてたって知ってる?
695:デフォルトの名無しさん
07/05/15 13:27:13
何がどう問題なのか書かなきゃ意味無し。
696:デフォルトの名無しさん
07/05/15 15:01:06
ほう、ドリキャスとプレステで分けられてたのか。
三千院家の屋敷みたいだな。
697:デフォルトの名無しさん
07/05/20 12:21:41
たまにはWFCのことも思い出してあげてください…
698:デフォルトの名無しさん
07/05/22 23:20:30
ちゃんとしたものが作れるのであれば、なんでもいいよ。
MFCだろうとVCLだろうと。
699:デフォルトの名無しさん
07/05/23 00:49:16
WTL最強
700:デフォルトの名無しさん
07/05/23 13:30:19
URLリンク(www.net3-tv.net)
701:デフォルトの名無しさん
07/05/29 14:45:22
MFCで0xc0000135
URLリンク(forums.microsoft.com)
702:デフォルトの名無しさん
07/06/21 16:15:40
URLリンク(itpro.nikkeibp.co.jp)
1990年代の中頃になると,主にCプログラマを対象とする,
比較的難易度の高いMicrosoftの「Win32 API」が,
さらに難解な「Microsoft Foundation Classes (MFC)」と「ActiveX Template Library (ATL)」に取って代わられた。
これら2つのC++フレームワークは,控えめに言っても,コンピュータ・サイエンスの歴史上最悪の出来事に含まれる。
703:デフォルトの名無しさん
07/06/21 20:24:08
えー、歴史を知ってる人はそんなに簡単に史上最悪とか言わないよー。
だって、必用があったから拡張されて複雑になるわけで、それなりの理由があるんだから。
704:デフォルトの名無しさん
07/06/21 22:15:44
こいつ只のMSアンチだろw
705:デフォルトの名無しさん
07/06/22 08:36:53
>必用があったから拡張されて複雑になるわけで
MFCに関しては当初から複雑。
GUIに関してはプロジェクトを超えて使いまわし出来ない。
706:デフォルトの名無しさん
07/06/22 09:53:55
>>705
>GUIに関してはプロジェクトを超えて使いまわし出来ない。
まさか、リソースIDに整数使ってたりする?
707:デフォルトの名無しさん
07/06/22 10:13:58
そういう問題じゃなくて、
resource.hの存在自体がoop的にはトンでもキティなの。
708:デフォルトの名無しさん
07/06/22 23:25:25
歴史的にリソースは CのSDKからそのまま持ってきたんだから、oop的にキモいのは当たり前なんだよな。
MFCが当初から複雑って、16bit時代のMFCの事を指してる?
当初は簡単なモノだったさ。
709:デフォルトの名無しさん
07/06/25 08:38:39
>MFCが当初から複雑って、16bit時代のMFCの事を指してる?
いや、今現在のヤツのダイアログ作成が超サイアク。
710:デフォルトの名無しさん
07/06/25 12:34:53
>709
最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。
最初のバージョンは、SDKのダイアログエディターしかなかったんだぜ。
711:デフォルトの名無しさん
07/06/25 13:01:47
>最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。
その比較に何の意味がある。
>最初のバージョンは、SDKのダイアログエディターしかなかったんだぜ。
イラネ
712:デフォルトの名無しさん
07/06/26 22:33:20
711は昔から常駐してるクソだから放置しとけ
713:デフォルトの名無しさん
07/06/27 21:25:03
歴史を知ってれば…って話前提なんだから、最初のバージョンの比較に意味はあるだろ。
このバカ。
714:デフォルトの名無しさん
07/06/28 09:05:57
現状がサイアクなのに、
>最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。
といった内容に何の意味がある。
このバカ。
715:デフォルトの名無しさん
07/06/28 14:15:10
> GUIに関してはプロジェクトを超えて使いまわし出来ない。
MFCベースで作成した拡張DLLで、複数のプロジェクトでGUIを共有
してますが、何か?
716:デフォルトの名無しさん
07/06/28 14:47:18
あの、それDLLの共有。
OOPでいうところの、ベースダイアログと派生ダイアログっていう共有じゃないでしょ。
ちょっと処理が違うダイアログ作ろうと思って、DLL変えてるようじゃoopじゃないから。
派生クラスを増やしても他の派生クラスのバグの元とならないことが重要。
717:715
07/06/28 15:30:10
>>716
> OOPでいうところの、ベースダイアログと派生ダイアログっていう
> 共有じゃないでしょ。
それをやりたけりゃ、作成した独自ダイアログクラスを持つDLLから、
さらに別の拡張DLLなりアプリケーション側なりで、派生ダイアログ
クラスを定義すればいいだけでしょ?
そのやり方も知らないで、よくプログラマやってられるな~。それとも
口先だけの自称システムエンジニア様か、自称ITコンサル様?(w
> 派生クラスを増やしても他の派生クラスのバグの元とならないことが重要。
そんなもんクラス設計する側に依存する問題であって、MFCに依存の
問題じゃねぇだろが。
いるんだよな~。オープン厨房とか、自分のスキルや知識のなさを棚に
上げて、何か問題を起こすとWindowsやらMFCのせいにして、ひたすら
Unixの営業を始める香具師。
718:デフォルトの名無しさん
07/06/28 15:41:49
>それをやりたけりゃ、作成した独自ダイアログクラスを持つDLLから、
>さらに別の拡張DLLなりアプリケーション側なりで、派生ダイアログ
>クラスを定義すればいいだけでしょ?
これって派生したダイアログ側でVC++のGUIでコントロール足せんやん。
出来ないことを出来るように書くな。
719:デフォルトの名無しさん
07/06/28 17:28:02
>>718
>これって派生したダイアログ側でVC++のGUIでコントロール足せんやん。
無茶しようとしてできなかったからMFC糞、という結論になったんですか。
720:デフォルトの名無しさん
07/06/28 17:33:49
>>719
いや、MFC以外では出来るんだけど。
721:デフォルトの名無しさん
07/06/28 18:20:16
>>720
>>MFC以外
kwsk
722:715
07/06/28 18:28:34
> これって派生したダイアログ側でVC++のGUIでコントロール足せんやん。
> 出来ないことを出来るように書くな。
無知とは、ホント恥ずかしいな。
723:デフォルトの名無しさん
07/06/28 21:45:11
何でこのスレの住人はこんなにも攻撃的なのだろうか。
MFCの有用性よりもそっちの方が気になる。
724:715
07/06/28 21:53:13
クリエイターはS。(by 江川達也)
725:デフォルトの名無しさん
07/06/28 22:53:17
口先だけの自称ITコンサル様の俺が来ましたよ。モットーは生かさず殺さず。
726:デフォルトの名無しさん
07/06/29 00:29:29
さすがに、現状が最悪とか言って、くそみそ一緒にされてもな。
つーか、技術者のどこがクリエイター?
727:デフォルトの名無しさん
07/06/29 08:39:32
MFCってM$社内でさえ使われないくらい悪いものじゃん。
その後のWTLと共にアナウンスではメジャーバージョンうp停止。
実際にはうpされたけどさ。
しかしだ、ドトネトに逝こう汁とは、いかがなものかと。
728:デフォルトの名無しさん
07/06/29 11:18:19
C++/CLIも最悪だしねぇ。C#は体感遅いし。
結局、C++と .Netは層を分けて設計するのがベストかねぇ。
729:デフォルトの名無しさん
07/06/29 11:30:55
ドトネトは使わないのが正解らしい:
>URLリンク(capsctrl.que.jp)
実はマイクロソフトにとってはすでに「来年」が過ぎている。
我たちはマイクロソフトのプロジェクトに対する顧客(特にアメリカの顧客)の関心が著しく減少しているのに気づいた。
オーストラリアでは、.NETは顧客の地盤をまったく得られなかった。
このデータから何を受け取ればいいのかはよく分からない。
730:デフォルトの名無しさん
07/06/29 12:00:17
>>722
プログラムから追加するだけなら出来て当たり前なんだから、
>>718 はもっと凄いことを要求してんじゃね?
「基底クラスのデザインがダイアログエディタで編集できないじゃねーか!」
とかさ。