トップページ⇒tech
1001コメント292KB

WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part7

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/08/22(日) 21:11:53
一向に普及しないユーザーインターフェースシステム
Windows Presentation Frameworkについて語るスレ。
パワフルで柔軟すぎるのが敗因か？ 正直ついていけないよね…。

Visual Studio 2010
ttp://www.microsoft.com/japan/msdn/vstudio/
Microsoft .NET Framework 4 (Web インストーラー)
http://www.microsoft.com/downloads/details.aspx?familyid=9CFB2D51-5FF4-4491-B0E5-B386F32C0992&displaylang=ja
Microsoft .NET Framework 4 (スタンドアロンインストーラー)
http://www.microsoft.com/downloads/details.aspx?familyid=0A391ABD-25C1-4FC0-919F-B21F31AB88B7&displaylang=ja

関連スレ
Microsoft Silverlight その6
ttp://pc12.2ch.net/test/read.cgi/tech/1271580489/

過去スレ
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part6
http://hibari.2ch.net/test/read.cgi/tech/1274423236/
WPF(XAML, XBAP, .Net3.5)GUIプログラミング Part5
http://pc12.2ch.net/test/read.cgi/tech/1261879110/
WPF(XAML,XBAP,.NET3.5)GUIプログラミング Part3
ttp://pc12.2ch.net/test/read.cgi/tech/1245384489/
WPF(XAML,XBAP,.NET3.5)GUIプログラミング Part3
ttp://pc12.2ch.net/test/read.cgi/tech/1231506876/
WPF(XAML,XBAP,.NET3.5)GUIプログラミング
ttp://pc11.2ch.net/test/read.cgi/tech/1211453941/
【新GUI FW】WPF（XAML,AVALON,.NET3.0)【重い?】
ttp://pc11.2ch.net/test/read.cgi/tech/1162950198/

コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/
0341デフォルトの名無しさん2010/11/05(金) 21:57:22
>>337
コールバック処理とかの実装どうしてんだよ。
わざわざクラスこさえて実施するとかJava上がりのバカだけだろ。
0342デフォルトの名無しさん2010/11/05(金) 21:57:32
LINQにメソッド渡すのは嫌ずら
03433052010/11/05(金) 21:57:46
>>336
そういうこと言い出す人がいると思いましたけど
わかってるでしょ？イベントハンドラは自動で作成されるし
別にデリゲートと意識しなくても使えるということを

動的にボタンを作成する場合も必要だけど
それぐらいはわかります。

とにかく>>317はボタン追加が押せないということで
間違っているところがあるんですよね？
それにあれだけ長くて難しいコードを書かなくてはいけない理由もわからない
ただ、ボタンを追加するだけなのに・・・
WPFやってみたけど、不満しかいまのところない
IDEは異常に重いし・・・ヒントの数も少ない
入力候補などが出ず手動で書かないといけないところが多い
0344デフォルトの名無しさん2010/11/05(金) 21:58:40
コレクションを要素の型の特定のプロパティでソートしたいときはデリゲート使わないでどうやるんだろう
Comparerクラスを実装するのはデリゲートと同じだから当然理解できないだろうな
データセットとか使うんだろうか
03453052010/11/05(金) 21:59:22
>>339
>>340
>>341
そういうのをしたい、必要と思ったことはありません
その程度の小規模なツール作っているだけなんで
0346デフォルトの名無しさん2010/11/05(金) 21:59:29
ふーん
能力がないのを棚に上げて道具のせいとかついったーに書いてろよ
03473052010/11/05(金) 22:00:18
>>344
そんなソートをしたいと思ったことがないですね
0348デフォルトの名無しさん2010/11/05(金) 22:01:00
>>345
理解できなくてすいませんでしたって土下座しろよ。
クソして寝ろ、もうくんなｗ
0349デフォルトの名無しさん2010/11/05(金) 22:01:12
>>345
じゃあ今は覚えなくていいよ
必要になったらここで見たな〜くらいは覚えておけば
0350デフォルトの名無しさん2010/11/05(金) 22:01:32
視野が狭い自慢？
0351デフォルトの名無しさん2010/11/05(金) 22:03:31
>>344
from n in コレクション
orderby n.プロパティ1,n.プロパティ2
select n
0352デフォルトの名無しさん2010/11/05(金) 22:03:51
他に出たのはともかくとして>>344がいらないって一体何作ってるんだろ
スクリプト言語でちょっとした処理書くときでさえ>>344みたいなソートは使わない方が珍しいくらい
03533052010/11/05(金) 22:04:24
winformsで簡単で短いコードでできることを
WPFでは難しく長いコードになってしまうということですよ
0354デフォルトの名無しさん2010/11/05(金) 22:05:02
>>351
それデリゲート使ってるよ
03553052010/11/05(金) 22:06:34
>>352
コレクションのソート使わない方が沢山あるでしょ
0356デフォルトの名無しさん2010/11/05(金) 22:07:07
ラムダ式はいわば簡単にかけるメソッドでしょ
デリゲートにおける扱いは普通のメソッドと変わらん。
0357デフォルトの名無しさん2010/11/05(金) 22:07:25
ソート使わないプログラムの方が少ないでよ
エントロピー減らすためにPC使ってるんだで
0358デフォルトの名無しさん2010/11/05(金) 22:09:05
>>355もういいから涙拭いて布団に入れよ。
0359デフォルトの名無しさん2010/11/05(金) 22:09:52
WinFormsの方が短く書けるってのはWinFormsの方法論でWPF書いてるからですよ
当たり前
03603052010/11/05(金) 22:11:28
てか>>315の何がだめなの？
他の人も言ってたじゃない
追加するならC#で書くってさ
0361デフォルトの名無しさん2010/11/05(金) 22:11:35
俺は半分ｵﾅﾇｰ用途だが
0362デフォルトの名無しさん2010/11/05(金) 22:12:02
ウィンホームズの方が他の言語に活かせる学び方ができる
03633052010/11/05(金) 22:13:03
>>359
じゃあ>>317はなぜ長いか説明してよ
追加ボタン押せないのはなぜか教えてよ
0364デフォルトの名無しさん2010/11/05(金) 22:13:14
まあ、実際、値の変更通知を手動で管理しきれて、
ビューから状態分離しなくてもテストしきれるような小規模なら、
WinForms の方法論で全然問題ないんだけどもね。

それを超えることやってないなら WPF はオーバースペックか。
0365デフォルトの名無しさん2010/11/05(金) 22:13:34
>>327辺りが言ってると思うが
お前メクラなの？PCモニタ見るの止めれば？
0366デフォルトの名無しさん2010/11/05(金) 22:14:36
>>363
ああ、ボタン押せなくしたのはちょい蛇足。
テキスト入力されてないときに、空のテキスト追加しちゃうの？って思ったんで。

ああいう、ビュー内の状態に応じてコマンドの実行可否切り替えるとかも、
割かし GUI ではよくある要件。
03673052010/11/05(金) 22:14:52
>>365
具体的に
0368デフォルトの名無しさん2010/11/05(金) 22:15:24
>>363
同じものWinFormsで書いてから言えば？
書いたら戻ってこなくていいけどｗ
0369デフォルトの名無しさん2010/11/05(金) 22:15:52
ヒートアップしてきたな。
03703052010/11/05(金) 22:15:58
>>366
ボタン押された場合にトリガー発動させて
ボタン追加じゃだめなの？
03713052010/11/05(金) 22:17:32
>>366
文字入力してもボタン押せない状態なんだけど？
0372デフォルトの名無しさん2010/11/05(金) 22:18:28
>>371
パソコンに馬鹿にされてんだよそれ
0373デフォルトの名無しさん2010/11/05(金) 22:20:27
>>370
disable になってる理由が明白な場合には disable にしてた方がいいって感じかな。
Word とかで、クリップボードに何もないときは「貼り付け」が disable になってるでしょ。

まあ、ポイントは、実行可否がコマンドの定義の部分に書かれてるってことかな。
「ボタンが押されたときに」ってやろうとすると、ボタンのイベントハンドラー内にコード書くことになるでしょ。
1つのコマンドに対して、実行と実行可否判定の場所が離れるってのはあまりよくない。
0374デフォルトの名無しさん2010/11/05(金) 22:22:23
>>371
フォーカスはずすと切り替わるはず。
キー入力のたびに切り替えたければ、
{Binding NewText} を {Binding NewText, UpdateSourceTrigger=PropertyChanged}
に書き換えて。
0375デフォルトの名無しさん2010/11/05(金) 22:23:01
機械の分際で>>305様に楯突くなんて！
0376デフォルトの名無しさん2010/11/05(金) 22:25:24
ちなみに、>>372 の補足。

なんで disable になってるのかパッと見てわからない場合は disable にせず、
実行されたときにアラート出す方がいいらしい。
でないとユーザーは「この機能は使えないものなんだ」って思うとかで。
03773052010/11/05(金) 23:05:40
>>316さんの説明はある一定の知識のある人には丁寧で
わかりやすいんだろうけど、おれのレベルだと
何を言っているのかわからない
俺はただ、追加ボタンがクリックできない状態になっている
テキスト入力しても出来ない状態
だからずっとできる状態にしてほしいの
どこをどういじればそういう風になるのかもわからないレベルなの

初心が遠く昔の人って、知識がある前提で話すからほんとわかりにくい
0378デフォルトの名無しさん2010/11/05(金) 23:09:02
>>377
あっ、ちなみに、>>316 と >>317 は別人よ。
あれじゃわかんないと思ってコード書いた。
余裕あったら説明コメントも入れたと思う。
0379デフォルトの名無しさん2010/11/05(金) 23:14:01
オラオラ、初心者様の御通りだぞ
平伏せ下郎
03803052010/11/05(金) 23:21:49
>>378
なんだ別人かー
わからないよね？>>316の説明だと
一応これに近いことなのかなと思ってみていたけどよくわからなかった
●コレクション・オブジェクトへのバインド
http://www.atmarkit.co.jp/fdotnet/vblab/uiframework_02/uiframework_02_04.html

＞A. 自分でやること
自分？何が自分？おれのこと？ユーザー？

＞B. 勝手にされること
誰が勝手にするの？
>ObservableCollectionはデータが追加されたことをItemsControlに通知する
このやり方がわからないんですけど。

そもそも何の説明？
もうまったくわかんなかった
例えると、ため口の説明を同じ内容でただ敬語で説明されただけって感じ。

>>317は>>316の説明の通りにしたソースだよね？
いつかわかる日が来た時のために永久保存しておきます
0381デフォルトの名無しさん2010/11/05(金) 23:24:39
まだやってるのか
落ち着け
03823052010/11/05(金) 23:27:19
パソコン今日届いて初めて触る人にコピペを教えるようなもの

初「コピペって何？」
上「クリップボードを中継してデータを写す作業」
初「クリップ・・何それ？」
上「クリップボードにコピーしたデータを保存して、適当な場所にペーストすることだよ」
初「いや、だからクリップってなに？コピーって？ペーストって？それってコピペの説明？」
別の上「Ctrl+C、Ctrl+Vでできる」
初「え？それってどういう意味？」（←キーボードのキーだということすらわかっていない）

今こういうのを体験した気がするわ
0383デフォルトの名無しさん2010/11/05(金) 23:28:07
>>380
すまん、正直 >>316 は最後まで読んでない。
普通に、WPF の基本ラインで実装しただけ。

まあ、WPF に慣れた人でも、現状は Forms 時代よりはだいぶ better にはなってるけど
その代償にめんどくささも幾分かあって、まだ過渡期って認識かも。
0384デフォルトの名無しさん2010/11/06(土) 00:13:00
>>382
あるある
03853052010/11/06(土) 00:22:25
>>382
これってさプログラマにとって根幹にかかわることだと思うんだよね
自分で理解できればそれでいいってソフトを作っている人はこれでいいだろうけど
初心者でも直感的に操作できるソフトを作るというのは難しそう

現に>>317はtabでフォーカス移動しなければ使えなかった
これって初心者からしたらバグでしかない

結局機能はしょぼいけど、初心者が作った初心者のためのソフトが使いやすかったりする
上級者で初心者の気持ちもわかる人って解説サイトでも少ないよねー
0386デフォルトの名無しさん2010/11/06(土) 00:24:58
しょぼいのでいい
地道にいけ
0387デフォルトの名無しさん2010/11/06(土) 00:25:52
実際でもなぁ、それは UX デザインを専門にやってる人に任せたいというのが本音。
となると、「UX デザインが専門であってプログラミング詳しくない」って人がやれなきゃ意味ないのよね。

そこは WPF は「分業を推し進める」って方向に舵を切ってるわけだけども。
XAML 側は UX デザイナーが Blend とか使って作る、
プログラマーはビューには触れず、ビューモデルを作るっていう。
0388デフォルトの名無しさん2010/11/06(土) 00:26:01
初心者が作ったソフトは使いにくいです
拡張性0、ボタン大量、etc...
アラアラと思う…
0389デフォルトの名無しさん2010/11/06(土) 00:27:25
というか、 >>317 は、コード少ない方が理解しやすいかなって思って
Binding の記述削ってたんだけど。

その結果、バグだと言われて、
一方、「C# 側がコード量多い」って言われたのはさすがにちょっとへこむ。
03903052010/11/06(土) 00:33:47
private void button1_Click(object sender, RoutedEventArgs e)
{
Button button1 = new Button();
button1.Content = textBox1.Text;
this.wrapPanel1.Children.Add(button1);
}

だってさ、初心者でもたったこれだけでできることを
上級者がXAMLでやると、デリゲートだとか、バインドがあっちこっちにあったりして
どうしてそうなっちゃうの？って感じ
0391デフォルトの名無しさん2010/11/06(土) 00:37:01
たいていそれだけで要件収まらないから。
いいのよ、別に、ほんとにそれだけの要件ならそれで。
0392デフォルトの名無しさん2010/11/06(土) 00:40:42
コードの小分けが出来るのがいい
というかさ、winformsでもbind使ってたろ？
使ってなかったのか？もしかして…
0393デフォルトの名無しさん2010/11/06(土) 00:46:42
先日の初心者スレの人はブーブー言いつつ皆に熱心に諭され勉強し、
1日でWPF使いに変身したというのに
0394デフォルトの名無しさん2010/11/06(土) 00:47:10
>>392
そういうことだ。
多くの人が使ってないんだよ、bind。

で、不意に規模が膨らんじゃってからギャップが越えられなくなる。
03953052010/11/06(土) 00:47:59
>>392
使ったこと無いよ
ソースが変わったら、ターゲットのプロパティを書き換えるコードを書いてた
イベントハンドラ大量、更新させるためのコード

結果、ある程度の規模になると、更新一部し忘れたり、どこで更新されたかわからなくなったり
イベントハンドラが大量で一体どこで何をしているのかわからなくなった

だからそんなことにならないような簡単なユーティリティだけ作ることに
例えば、空フォルダを見つけて削除や、削除したファイルをリストアップするだけなど
ファイラーから実行できるような手軽なものを作っていた
03963052010/11/06(土) 00:49:34
>>393
それおれだから
WPF使いじゃなくてWPF始めただけだからｗ
0397デフォルトの名無しさん2010/11/06(土) 00:51:54
いやいや、Bind使おうよ…
WinFormsでもさ…
UserControlでView作ってBindで繋げて、振る舞いはインターフェイスで定義してってやるだろ…
その辺がもうちょい賢くなって便利になったのがWPFなんだし…
0398デフォルトの名無しさん2010/11/06(土) 00:54:20
イベント直書きは10年前のdelphiでもうこりごり
0399デフォルトの名無しさん2010/11/06(土) 00:54:59
>>395
もうPythonとかスクリプト言語使えば?
君はそのほうがよっぽど幸せになれると思うよ
04003052010/11/06(土) 00:57:18
>>397
使えるなら使うさ
俺は基本どぼんに乗っているコードをコピペすることしかできないさ
2001C# 発売当日に魔が差して買ったおれがさ
04013052010/11/06(土) 00:59:13
>>399
Python、Rubyとかもやったよ
でもやっぱ、GUIのかっこいいの作りたいじゃない？
0402デフォルトの名無しさん2010/11/06(土) 00:59:51
うーん、コピペ自体は悪いとは言わないんだけどね。
そうなると、古い、現代的には問題が明らかになってるコードって、人類の抱える負債だなぁ。
0403デフォルトの名無しさん2010/11/06(土) 01:00:12
空フォルダを見つけて削除するGUIユーティリティ?w
そういうのはコマンドラインで使えた方がどう考えても便利です
0404デフォルトの名無しさん2010/11/06(土) 01:00:31
>>401
かっこよくねぇよｗｗ
かっこいい人が作った GUI がかっこいいだけだよ。
0405デフォルトの名無しさん2010/11/06(土) 01:03:31
こういう技術の根底にある考え方って敷居高いのかなぁ
うーむ…
0406デフォルトの名無しさん2010/11/06(土) 01:04:14
スレがのびてると思ったら…
まぁ宗教議論よりはいいか
04073052010/11/06(土) 01:06:09
>>403
文脈理解しろよ
今作ろうとしているのは動画ソフトのフロントエンド的なものを作ろうとしているの
多分完成したら新しい時代がくる

アイデアだけはすばらしいんだよおれって
そこらのフリーソフトを超える使い易いソフトをいくつも妄想してきたが
プログラミングができない
0408デフォルトの名無しさん2010/11/06(土) 01:09:27
>>407
なんか急に口調変わったぞｗ騙り？ｗ
0409デフォルトの名無しさん2010/11/06(土) 01:12:29
他の言語でもフレームワーク触った事あるならすぐ理解出来ると思うけどね
名前は違えどやってる事は一緒だし
0410デフォルトの名無しさん2010/11/06(土) 01:20:14
ただでも、でかいフレームワークだと、その裏にある要求とかモデルとかを簡潔に説明した文章って少ないからねぇ。
0411デフォルトの名無しさん2010/11/06(土) 02:53:26
WPFがダメなのはIDEの至れり尽くせりサポート大前提で設計してるくせに
肝心のサポートが話にならないチープさなところ
こう書くと老害が「HTMLだって手書きでやってきた」とかほざくんだがナンセンス
今時のCSS&JavaScriptごちゃごちゃに入り交じってる案件メモ帳でやってみろってんだ
0412デフォルトの名無しさん2010/11/06(土) 02:57:54
Blendは敷居高いと思うが
windowsFormで作る程度のならVisualStudioでドラッグ＆ドロップで行けるだろ
0413デフォルトの名無しさん2010/11/06(土) 04:02:01
>>411
こういうの見ると
あぁ、この人ってWPF使った事ないのに批判してるんだな　と哀れに思うわ。

実際は>>412なのにまるで分かってない。
0414デフォルトの名無しさん2010/11/06(土) 04:04:14
否定だけなら子供でもできる
反論があるなら根拠を述べよ
0415デフォルトの名無しさん2010/11/06(土) 04:05:49
>>414
日本語がわからないとは
0416デフォルトの名無しさん2010/11/06(土) 07:30:20
>>411のほうが老害くさいよな
どうせVB6のクラサバみたいなのしか作ったこと無いくせにｗ
0417デフォルトの名無しさん2010/11/06(土) 08:11:04
TabControlの複数のページでListViewを表示していて、
GridViewの列の並びや幅などを同期させたいのですが、どのようにすればいいのでしょう

今はページを切り替える際に、列を作り直してるんですが、非常に無駄なことをしている気がします
GridView.Columnsあたりに、共通のソースをバインディングするとかできませんかね
0418デフォルトの名無しさん2010/11/06(土) 08:46:46
>>412
まあ、しゃあない。
Adobe 製品とか見てみなって。
ビジュアルデザイン系のツールみんなあんな感じだから。
0419デフォルトの名無しさん2010/11/06(土) 09:17:30
バカチョンって奴ね

いいんだよ雑魚グラマが増えて仕事が尻拭い中心になったんだ
ここらで敷居をあげて少し淘汰されたほうがいい
0420デフォルトの名無しさん2010/11/06(土) 11:08:22
>>412
その程度のモンをわざわざWPFで作る意味ってなんだよwwwww
不自由環境に快感を見出すマゾなのか?
0421デフォルトの名無しさん2010/11/06(土) 11:11:12
その程度のモンならWPFだから特別難しいってことはないだろ
デザイナでコントロール貼り付けてプロパティ弄ってダブルクリックしてイベントハンドラ書くだけ
WinFormsと何が違う?
04224202010/11/06(土) 11:16:41
>>421
怖いんだ・・
とにかくwpfが怖いんだ！
0423デフォルトの名無しさん2010/11/06(土) 11:18:44
WPF ToolKitのDataGridのTemplateってどうすればいいんだすか
04243052010/11/06(土) 14:10:31
>>317
デリゲートもインターフェースもやったことなかったが
一晩かけていろいろ調べてなんとなくわかった

独自のコマンドを作るにはICommandインターフェースを使ったクラスを自作しないといけなくて
そのためにDelegateCommandクラスが作られていて、普通はここに実行する内容を書けばいいはずだけど
汎用的に使えるように、具体的な実行内容はViewModelでして、DelegateCommandクラスでは
デリゲートを宣言して実行メソッドを呼び出しているって感じかな？
もしくは、コンストラクタの引数にメソッドを変数みたいに渡したいからDelegateを使っているのか？
そこらへんはよくわからないが、なんとなくやっていることはわかった気がする

これって、メニューやボタンがクリックされたらどうするかというイベントハンドラを大量に書かないためにと、
別にボタンを作って作成ボタンとは違った振る舞いの独自のコマンドを作るときも
DelegateCommandクラスを利用することで、無駄なコードを書かないようにするため

こういうややこしいことをしているのは、こういう理由だからって理解でOK？
04253052010/11/06(土) 14:14:09
訂正

＞これって、メニューやボタンがクリックされたらどうするかというイベントハンドラを大量に書かないためにと、
ボタンを作成するために、メニューやボタンのイベントハンドラを大量に書かないためにと
0426デフォルトの名無しさん2010/11/06(土) 14:15:40
違うよ
ViewModelをViewに依存させないため。
イベントハンドラを追加するときってイベントを受ける側で送る側にイベントハンドラを登録するので
ViewModelの中でイベントハンドラをViewに結び付けるとViewModelがViewに依存してしまう。
そこで逆にViewModelでは「俺はこれだけのコマンドをサポートしている。勝手に呼び出せ」という風に
コマンドを公開するだけにして、コマンドを具体的なイベントに結び付けるのはView側で行う。
0427デフォルトの名無しさん2010/11/06(土) 14:38:49
このあたりは悩み所だよなぁ。どこで切るかケースバイケース過ぎる。

ViewModelはViewのシャドウなわけである程度依存するのは仕方ないのでは？
例えば選択状態をViewModelが知っているだけでも、
ViewModelはViewが選択機能を持つことを知っていることになる。

MVVMのそもそもの動機(自動回帰テスト、スキンに依存しない構造)を考えると、
ViewModelはViewの機能には依存しても、Viewの"インスタンスに"依存しない、が正しい気がする。
04283052010/11/06(土) 15:02:44
>>426
依存させないのは
例えばボタンクリックで作成だったのを変更して
メニューからのみボタンを作成にすることにしたときに
イベントハンドラだと書き換えたりしなければいけないから
GUIの変更がしづらくなる

だからコマンドバインディングにコマンドを登録だけして
どのコマンドをどの時点で呼ぶかは気にすることは無いという感じかな
0429デフォルトの名無しさん2010/11/06(土) 15:03:31
>>422
なりすまし乙
実に程度が知れるな
0430デフォルトの名無しさん2010/11/06(土) 15:07:18
WPFのコマンドは実装を含まず意味を表すのが基本で云々という講釈↓
0431デフォルトの名無しさん2010/11/06(土) 15:08:57
コマンドなんてpublicメソッドと同じ
ただメソッドだとXAMLにちょろっと書くだけで自動的に呼び出されるというわけにはいかないので
ちょっと回りくどい仕組みになってるだけ
0432デフォルトの名無しさん2010/11/06(土) 15:19:45
>>427
ViewがViewModelの用意する機能を使うかどうかは自由なので、
ViewModelがViewを知っているとはいえないんじゃないかな。

WPFでコマンドっていうなんか回りくどいのを推奨してるのは、
XAMLがプロパティと相性のいい言語だからということと、
実行の可否（CanExecute）を持たせることができるってことくらいかな。
ObjectDataProvider使えばXAMLで直接メソッドを指定することもできるはず（未確認）
だけどこれは記述が汚くなるよね。
04333052010/11/06(土) 15:22:40
あと、DelegateCommandクラスでデリゲート宣言して、ViewModelのメソッドを呼び出しているのはなぜかわからない
依存させたくないだけなら、DelegateCommandクラスでViewModelのExecuteの内容を書けばいいですよね？
依存させないようにするにはRoutedCommandをコマンドバインディングに登録するだけでいいのですから

ViewModel内にコマンドの実行内容Executedを書くということは、
本質は違うけど、WinformsでいうとイベントハンドラをForm1に大量に書いていくのと同じような気がするんだけど？
コマンドはコマンドで分けた方がよくないですか？
0434デフォルトの名無しさん2010/11/06(土) 15:30:04
いくらクラス分けようがコマンドの実行内容はViewModelにしっかり依存してるんだから
ViewModelとコマンドを分けても見づらくなるだけで意味ないだろ。
ViewとViewModelを分けるのは主にViewModelの単体テストやViewの変更を行いやすくするため。
ご察しの通り大規模開発向けの仕組みだから要らないと思うなら要らない。
04353052010/11/06(土) 15:32:41
>>434
そっかー、今のとこ恩恵は薄いけど
いつも規模が大きくなると途中で挫折してたから
今回はこの考え方でやってみます
04363052010/11/06(土) 15:40:26
まとめると、イベントで処理すると、VIEWの個々の部品に対して依存した実装になるので
変更耐性を強くするために、コマンドで通話する
で、コマンドの実行内容はViewModelに依存しているから、
ViewModelで実装するためにコマンドからデリゲートで呼び出す形にすると

こんな感じかな
わかってくるとちょっとおもしろくなってきた
0437デフォルトの名無しさん2010/11/06(土) 15:41:24
いいから独演会してねえではよ死ね
04383052010/11/06(土) 18:14:51
MVVSでプログラミングするのはWPFプログラマだけという
奇妙な世界ができあがるわけですね

囲い込んでるのか首を絞めてるのかわかりませんね
プログラミングシェーダの世界ですね
0439デフォルトの名無しさん2010/11/06(土) 18:25:18
MVVMはMVCの亜種で、ごくありふれた設計なんだが
04403052010/11/06(土) 18:31:01
MVC亜種でもMVVM経験者じゃないとコードの意味すら伝わらないじゃないですか
■ このスレッドは過去ログ倉庫に格納されています