MVVMについて語ろう

**デフォルトの名無しさん** · 2012/06/06(水) 11:03:33.21

WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか！

**デフォルトの名無しさん** · 2012/11/20(火) 13:54:25.91

HeaderedItemsControlとかをこねくり回すのは常套手段なのか

**デフォルトの名無しさん** · 2012/11/28(水) 11:11:37.09

考え増やしたいから、
MVVM の各レイヤーの具体的な責務を教えてください

以下、テンプレ

M:
V:
VM:

**デフォルトの名無しさん** · 2012/11/28(水) 11:22:45.65

>>544
> M:
ビューに関係無いデータ構造など変更部分。いわゆるモデル。UIスレッドと分離されてる事が望ましい。
> V:
ビューの見た目。極力もらったデータを表示したりインプットを上にあげるだけで何もしない。
> VM:
その両者を繋ぐもの。そのビューに関係するコーディネーター。ユニットテストできること。スレッド間の調整をここで吸収。

**デフォルトの名無しさん** · 2012/11/28(水) 11:22:46.45

Set-Location : ドライブが見つかりません。名前 'M' のドライブが存在しません。

**デフォルトの名無しさん** · 2012/11/28(水) 11:34:44.90

一番ありそうな間違いは、WebMVCの典型的な間違った使い方のように
M: データ
VM: ロジック
としてしまうことだな
注文画面のMは注文処理クラス。VMはあくまでインターフェイスの差を吸収するだけ。

**544** · 2012/11/28(水) 11:45:53.66

>>547
まさにこれw

**デフォルトの名無しさん** · 2012/11/28(水) 12:47:28.47

使う側ならそれでいい

**デフォルトの名無しさん** · 2012/11/28(水) 14:02:32.93

Mのビジネスロジックがバックエンドに移って
結果的にMがデータだけになることはあるだろうけど
VMから見たら特に関係ない話。VMにビジネスロジックを書いてるわけじゃない。

**デフォルトの名無しさん** · 2012/11/28(水) 21:50:02.31

プレゼンテーションに関わるものとしてVMに置いとくべきデータやロジックがあるって意見も耳にするけど
自分には区別が難しいので極力Mに持たせるわ。

**544** · 2012/11/28(水) 22:50:19.03

永続化しないデータとか？

**デフォルトの名無しさん** · 2012/11/28(水) 23:14:06.28

MVVM界隈の話はVMが強調されすぎるきらいがあるよな。
本当はMの方が遥かに重要なのに。どちかか省くなら迷わずM。
VMはMVVMパターンのアイデンティティだから仕方がないけど。

**553** · 2012/11/28(水) 23:14:52.00

間違えた省くならVM

**デフォルトの名無しさん** · 2012/11/29(木) 00:02:45.23

プレゼンテーションにかかわるものはVに書くんじゃないのか

**デフォルトの名無しさん** · 2012/11/30(金) 06:22:26.73

VMは、抽象的な、表示する「ための」データだな
例えば、VでItemsSourceにバインドして表示する一連のデータのコレクションとか
特定のデータを、手段は特定しないからとにかく強調表示しろ、ということを示すプロパティとか

Vは、具体的な、表示「の仕方」だな
同じVMからでも、同じコレクションを表示させる方法はListBoxだったりDataGridだったり単なるテキストだったり
どんな形で表示するのかはVが決めることでVMは手を出せない
また、強調表示の仕方にしても、単なる色変化だったり太字だったり、その部分だけ無意味にアニメーションさせたり
表示の仕方もVに任せられててVMは手を出せない

**デフォルトの名無しさん** · 2012/12/11(火) 16:23:56.96

VBでペタポトプログラミングしか経験ない奴にパターン教えても一向に概念理解してくれない
ましてMVVMなんか到底無理無理

**デフォルトの名無しさん** · 2012/12/11(火) 18:18:42.11

そんな動けばいいという考えの奴に何をいってもダメだ。
平気でModel部分にフォームやコントロール(UI)のインスタンスを食わそうとしたりするからな。

**デフォルトの名無しさん** · 2013/01/16(水) 20:12:33.47

MVVMって従来のASP.NETやWindowsフォームに慣れた人に説明するなら、

V　　Aspxファイル/フォーム
VM　コードビハインドのcs
M　　業務ロジック
と対応してて、従来のASP.NETやWindowsフォームとの大きな違いは、
ViewとViewModelがバインディングを介すると言う制約があるので分離しやすい、
と言う理解なんだけど大体合ってるかな？

**デフォルトの名無しさん** · 2013/01/16(水) 22:46:55.45

全然

**デフォルトの名無しさん** · 2013/01/17(木) 23:06:47.49

大体合ってるみたいですね。
VB6脳なPGとJava/Struts脳なPG、どっちがMVVM覚えるのに向いてますかね？

**デフォルトの名無しさん** · 2013/01/18(金) 08:37:02.03

>>561
全然違うと言われてんだろ
概念がそもそも違うがそれが分からない人間でも
・コードビハインドは画面と同一クラスだがVMは別クラス
・コードビハインドとViewは一対一だが、View:VMは1:n
・VSでコントロールをダブルクリックしてもコマンドが作られて自動的にバインドされたりしない
・そもそもコードビハインドはコードビハインドで存在するだろ
と、上げ出したらきりが無い
MVVM使うならちゃんとMVVMの概論くらいは理解させないとあとで自分が地獄行きだぞ

**デフォルトの名無しさん** · 2013/01/18(金) 09:03:18.93

的外れな回答()キター

**デフォルトの名無しさん** · 2013/01/18(金) 14:28:02.15

いまだにVB6脳なんて他のこと何も向いてないだろ

**デフォルトの名無しさん** · 2013/01/18(金) 14:46:29.63

違うって言われてるのに合ってると受け取っちゃうのはどこにも向いてないな。

**デフォルトの名無しさん** · 2013/01/18(金) 17:07:06.64

全然合ってるかもしれない

**デフォルトの名無しさん** · 2013/01/20(日) 07:38:18.01

559は大体あってるよね？
というより562が間違いすぎｗ

・コードビハインド（各種イベントで呼び出される関数）は
　手動で設定すれば Viewとは別のクラスにすることは可能だし
・V:VM は　一つのデータを別表現で表示することがあるので V:VM = n:1
・デザイナでダブルクリックしても自動で出来ない
　　→細かい処理を行いたければデザイナに任せずに手動で操作するのは当たり前。
・そもそもコードビハインドはコードビハインドで存在するだろ
　　→別にイベントで関数呼び出しても、
　　　CommandやActionのバインディングで関数呼び出してもよくね？
　　　

**デフォルトの名無しさん** · 2013/01/20(日) 07:50:01.85

そういえば、データバインディングって
ほんの少し　MFCのValue変数とDDX_～に似てないか？

**デフォルトの名無しさん** · 2013/01/20(日) 09:40:48.58

>>568
ほんの少しな( ´Д`)y━･~~

**デフォルトの名無しさん** · 2013/01/22(火) 07:57:45.76

@Grabacr07 いままでのオレオレICommandの正しい実装基底クラス

Prismのパクリなのになんでこんなに偉そうなの？

**デフォルトの名無しさん** · 2013/01/22(火) 19:39:17.12

心底どうでもいい

**デフォルトの名無しさん** · 2013/01/22(火) 21:17:29.87

MVVMライブラリはすべてPrismのパクリだからな
いまさらだろ

**デフォルトの名無しさん** · 2013/01/25(金) 10:23:59.51

別に偉そうじゃない件について
どれだけコンプレックス感じてんだよｗ　ダッセーやつｗ　ぷげら

**デフォルトの名無しさん** · 2013/01/25(金) 23:38:53.69

実際やってみたらMVVMではなくWPFやSilverlight固有の部分でかなり躓いた
初見でXAMLを自由自在に扱える奴とかいるのか？

**デフォルトの名無しさん** · 2013/01/25(金) 23:46:59.77

固有の約束事を理解しないといけないのはWinFormsだってASP.NETだって
PHPとかのWebフレームワークだって一緒だ

**デフォルトの名無しさん** · 2013/01/26(土) 00:00:26.99

パネル使ったレイアウトに慣れてないだけじゃね？

**デフォルトの名無しさん** · 2013/01/26(土) 00:07:18.85

>>574
ちなみに躓いたのどこら編？

**デフォルトの名無しさん** · 2013/01/26(土) 00:11:58.51

ControlTemplateとか初見でMSDNだけで使いこなせたら神だわ

**デフォルトの名無しさん** · 2013/01/28(月) 10:43:39.37

Templateカスタマイズする時点で折れるな

**デフォルトの名無しさん** · 2013/01/29(火) 02:16:53.83

>>573
別にウガヤが考えたロジックじゃあないのに
まるで自分で考案したような口ぶりが臭いだけじゃろ。
特にcommandのweakeventなんてprismのアイデアそのまんまだし。
++c++やneueと違って.NETやC#(言語)の知識は薄っぺらいのに
ビックマウスだから余計に臭い。

**デフォルトの名無しさん** · 2013/01/29(火) 05:30:37.24

>>580
詳しくは知らんが咀嚼して自分のライブラリとしてまとめ上げて、それを採用してくれてるとこもあるんだから、口だけ番長のお前より遥かにまし。
リアルでフルボッコにされたの？悔しいのぅ悔しいのぅ。

**デフォルトの名無しさん** · 2013/01/29(火) 07:57:35.12

奴が自分で考案したみたいなことを言っているのは見たことないが
どの辺で言ってたのか気になるな

**デフォルトの名無しさん** · 2013/01/29(火) 08:22:09.37

別に好きでも嫌いでもないが、世の中のMVVMフレームワークは全てLivetより下と言ってるように取れる文書ならみた
MVVMが普及しないのは既存のインフラが不十分なせいで、Livetがそれを解決するんだとか
確かアンチMVVMに反論する記事だったかと思う

**デフォルトの名無しさん** · 2013/01/29(火) 08:34:30.68

現場でMVVMゴリ押しして使ったら大失敗したからアホにも使えるように作ったんだっけ？
部下も可哀想だな

**デフォルトの名無しさん** · 2013/01/29(火) 08:50:43.67

まあ既存のが不十分なのはあってるな
ただLivetが必要十分かと言うとそうでもない

**デフォルトの名無しさん** · 2013/01/29(火) 09:18:58.54

Javascriptエンジン組み込んでknockout.jsを逆移植するのがいいと思う
ビューに振る舞いを書けた方がいいのは、それを最初否定してたMVVM自身によって証明されたし
VMも静的言語で書くのは面倒な単純作業すぎる

**デフォルトの名無しさん** · 2013/01/29(火) 09:31:08.32

ReactiveExtensions絡めて作ってるがすこぶる楽だし見通し良くなってイイよ。
まぁ向き不向き有るかもしれんが。まだ試しで作ってるだけなので後でいろいろはまるのかもしれんけど。
内部の状態遷移など含めて綺麗に落とし込みたいんだけどまだそこまで出来とらん。

**デフォルトの名無しさん** · 2013/01/29(火) 10:26:40.09

MVVMとリアクティブプログラミングの相性は非常にいいね。

ただ、ReactiveExtensionsは記述が冗長になるので
人にはお勧めできないな。

async,awaitみたいにコンパイラ支援があればいいんだけど。

**デフォルトの名無しさん** · 2013/01/29(火) 10:36:58.35

>>588
非同期として扱うだけなら冗長になるかもしれんがその以上やるならあんなもんじゃない？どの変が気になる？
F#だとその辺を自分でクエリ構文を定義してよしなに出来なくもないけど。

**デフォルトの名無しさん** · 2013/01/29(火) 12:29:20.69

MVVMって何ですか？

**デフォルトの名無しさん** · 2013/01/29(火) 12:40:25.22

wwwwみたいなAAの一種

**デフォルトの名無しさん** · 2013/01/29(火) 12:51:58.26

>>588
俺は非同期についてはasync,awaitを使ってるから気にしてなくて、
リアクティブプログラミング本来の "関係性を記述する" って部分で冗長性が気になる。

例えば、
int A { get { return B ? C : D.E; } }
って単純な関係性を記述するだけでも、それなりの量になる。

> F#だとその辺を自分でクエリ構文を定義してよしなに出来なくもないけど。
F#の計算式は羨ましいね。

async, awaitがTask<T>を生成するのと同じように、
計算式で ReactiveProperty<T> を生成すると非常にすっきり書ける。

**デフォルトの名無しさん** · 2013/01/29(火) 13:51:35.91

>>592
> int A { get { return B ? C : D.E; } }
> って単純な関係性を記述するだけでも、それなりの量になる。
自分もまだそこまで突っ込んで触ってないのでなんだが、自分で用途に合わせた複数要素を取れるZipみたいな物とか作らないと記述が冗長になりそうな気はしてる。
Zip重ねてとかでもいいけど見た目的にも身微妙な気がしなくもない。

> 計算式で ReactiveProperty<T> を生成すると非常にすっきり書ける。
その辺でSelectManyとかSwitchで上手く合成出来ると綺麗に書けるんかね( ´Д`)y━･~~

**デフォルトの名無しさん** · 2013/01/29(火) 15:41:47.19

F#で計算式を使うと言っても、do!やlet!でやるのは
ReactiveProperty<T>からをT型の値を取得すると同時に値の監視を開始するだけだから
C#でも似たようなことはできるけどね。

上の int A { get { return B ? C : D.E; } } の関係性なら

ReactiveProperty<int> A
{
get { return ReactiveProperty.Create(x => x(B) ? x(C) : x(x(D).E)); }
}

と書けるReactiveProperty.Createは実装可能。

逆に言えばF#でも同程度の記述の冗長性は残るという事になる。

**デフォルトの名無しさん** · 2013/01/29(火) 16:11:47.74

>>594
自分が言ってるのはQueryExpressionsの方。
使ってる例としてはこんな感じ。
http://mnajder.blogspot.jp/2011/09/when-reactive-framework-meets-f-30.html
これはクエリ式への直接変換的な感じだけど、望みのクエリ式を追加できるので独自のDSL的に定義できる。

**デフォルトの名無しさん** · 2013/01/30(水) 18:31:22.62

従来型のほうがいいだろ
誰かさんにプレゼント

優れた言語より流行ってる言語
優れたフレームワークより使われてるフレームワーク

**デフォルトの名無しさん** · 2013/01/30(水) 18:52:28.14

アプリケーションで、各種バー表示のon/offや配置等の、GUIに関する設定がよくあると思いますが
そういう設定の保存・読み込みロジックはVMでいいんですよね?
MVVMの概念がまだあやふやで確信が持てません。

**デフォルトの名無しさん** · 2013/01/30(水) 18:55:35.45

一番使われてるフレームワークが一番、ってのなら、
一番のラーメンはインスタントラーメンだぜ？

**デフォルトの名無しさん** · 2013/01/30(水) 19:04:13.88

Haskell大流行だもんな

**デフォルトの名無しさん** · 2013/01/30(水) 19:13:05.88

>>598
フレームワークとラーメンとが置換可能であることを証明できれば完璧だな。
イグノーベル賞がんばれよ。

**デフォルトの名無しさん** · 2013/01/30(水) 20:13:22.03

COBOL最高だろうが

**デフォルトの名無しさん** · 2013/01/30(水) 20:49:05.37

>>597
Vでしょ
というかそういう作り込みが必要な画面にMVVMを適用するのは不適切だと思うよ。
大してメリットがなく面倒なだけ。使うならダイアログとかで使う。

**デフォルトの名無しさん** · 2013/01/30(水) 20:55:18.66

メニューとか(共有の)ツールバーとかウィンドウ制御のようなシェル的な部分に
MVVMを適用しようと考えてはいけない
そういうのはインフラとしてMVVMの枠外で実装して、その中で扱うドキュメントには
必要に応じてMVVM適用するのがスマート

**デフォルトの名無しさん** · 2013/01/30(水) 22:12:56.62

あくまでVの都合だしな
MVVMは本体処理とUIの組み合わせ方のパターンでしかないので、ウィンドウのサイズ保存とかはロジックとは無関係

**デフォルトの名無しさん** · 2013/01/30(水) 22:13:53.89

>>602
え？Modelじゃないの？
煽りじゃなくて、真面目な質問です

**デフォルトの名無しさん** · 2013/01/30(水) 22:14:56.02

あぁ、確かにビジネスロジックではないのか

**デフォルトの名無しさん** · 2013/01/30(水) 22:45:08.78

あえてシェルにMVVMを適用するんならMだろうな
どちらにしろGUIに閉じた話であって、ビジネスロジックの世界とは分けて考えるべき

**デフォルトの名無しさん** · 2013/01/30(水) 22:47:03.45

>>597
VMで正しいよ。

ビューモデルというのは、ドメインモデルとビューとのギャップを埋めるラッパーの役割をするもので、
まさに>>597のようなビュー固有のデータを扱うのに適している。

Vに置くのは（少なくともこのスレにおいては）間違いだから>>602は気にしなくていい。

**デフォルトの名無しさん** · 2013/01/30(水) 22:56:21.08

>>608
それこそビジネスロジックとUIがごっちゃになってね?
もともとビジネスロジックから見たらVの実装の詳細にすぎないことで、
それが少々複雑になるからMVVM適用しようってんなら
GUIの設定情報を持つためのMを使うのが適切だと思うよ

**デフォルトの名無しさん** · 2013/01/30(水) 23:00:06.22

アプリケーションモデルというやつですか。

**デフォルトの名無しさん** · 2013/01/30(水) 23:07:07.58

そもそもそんなロジックに直接関係なくてGUIに閉じた混みいった制御と
金,人間,住所,データベース,入力フォーム云々を一緒にして扱うのがおかしい
そこ明確に分けるのが一番大事だろ

**デフォルトの名無しさん** · 2013/01/30(水) 23:19:21.22

そんなめんどくさいことせんでも、VBで画面にぽちぽちボタンとか張って、
ダブルクリックしてイベント追加したら、その中に全部処理書けばええやろww

**デフォルトの名無しさん** · 2013/01/30(水) 23:22:23.10

PrismだとShellに対してVとVMがあって、ShellのVMのプロパティに
入力画面とかのVM渡して、ShellのVの中でその画面開いて、ツールバーなども
Shellが管理するようになってたはず。サンプルではShellに対するMは無かったけど、
ツールバーの細かい設定入れるとしたら当然この設計ではShellのMになるよね。
ShellのVMが本当に必要かどうかはかなり怪しいが。

**デフォルトの名無しさん** · 2013/01/30(水) 23:22:30.14

>>609
ビジネスロジックというのを定形的に捉えすぎてね？
アプリケーションシェルと言った物の実装も対象が違うだけでビジネスロジックの実装と変わらんだろ。
MVVMはロジックとビューをブリッジ介して分離する仕組みでその対象がシェルでも構わんと思うけどね。
他の実装がしやすいなら無理に適応する必要はないけど。

**デフォルトの名無しさん** · 2013/01/30(水) 23:26:54.51

>>609
ドメインモデル（ビジネスモデル）からはビューモデルに対して一切関知することはなく、完全に独立している。
ビューモデルからはドメインモデルを（継承やコンポジションなどの形で）参照することになるが、
当然ながらドメインの詳細には立ち入らないため、ごっちゃになることはない。

> GUIの設定情報を持つためのMを使うのが適切だと思うよ
ここではモデル（M）をドメインモデルとビューモデルとに明確に区別しているわけで、このGUIの設定情報と
いうのがまさに表示のためのモデルであり、ビューモデルだと>>608で書いたつもり。

なんか噛み合ってないかな？

**609** · 2013/01/30(水) 23:32:29.95

>>614-615
うん。だからシェルの抽象化がVMだしシェルのロジックやデータがMとするなら
Mじゃないかってことが言いたかった。省くならVMを省くべきじゃない?
バインディングもあんまり役に立たなそうだし。

**デフォルトの名無しさん** · 2013/02/04(月) 00:54:01.35

ViewModelHelper.ReadOnlyDispatcherCollectionのソース見てるんだけど
Dispatcher経由でViewModelのDisposeしなくていいの?

**デフォルトの名無しさん** · 2013/02/04(月) 02:17:34.63

WeakReferenceがなんとか

**デフォルトの名無しさん** · 2013/02/12(火) 00:41:05.78

だからコードビハインドのあるなしとMVVMに何の関連もないと何度言ったら。。。最近コードビハインド付のMVVMしかしてない

おがやさん以前は、コードビハインドはMVVMの癌、肯定してる人は糞みたいなニュアンスのこと言ってませんでしたっけ？
この人若年性健忘症なのかな？

**デフォルトの名無しさん** · 2013/02/12(火) 00:45:23.42

そーとー昔じゃないかな？それ

**デフォルトの名無しさん** · 2013/02/12(火) 00:59:57.57

いくら昔でも180度真反対に勘違いするほどの痴呆症を患った高齢の方には見えなかったもので。

**デフォルトの名無しさん** · 2013/02/15(金) 08:39:40.77

>>621
ようするにやせ我慢だったと。そういう事です。

コードビハインドなんて所詮MS界隈でしか使われないローカル技術仕様の用語に過ぎず
モデル云々を語る抽象的な概念にはほど遠い。
単に趣味と程度の問題を高尚っぽく語りたい人が散見されるだけ。

**デフォルトの名無しさん** · 2013/02/16(土) 04:51:33.73

>>622
MS以外でも使われてるだろ
もっと幅広い知識を持たないといかんよ。

**デフォルトの名無しさん** · 2013/02/16(土) 06:51:52.98

例

**デフォルトの名無しさん** · 2013/02/16(土) 10:39:51.16

MS以外のコードビハインドkwsk！

**デフォルトの名無しさん** · 2013/02/16(土) 11:09:58.98

>>625
knockout.js

**デフォルトの名無しさん** · 2013/02/16(土) 15:33:08.84

なんかデータバインディング持っているフレームワークなら何でもコードビハインドだとでも
言いたそうな勢いだなw

UIの画面設計の宣言的定義とUIロジックの手続き的記述を分けて書けるフレームワークなんて
MS以外にもいくらでもあるし、データバインディングもそのための定番手法の一つではあるが
knockout.js含めて「コードビハインド」という用語がMS関連以外の文脈で使われることなんて
ほとんどね～よ。手続き的記述の部分をMSが独自にそう呼んでいるだけの話。

**デフォルトの名無しさん** · 2013/02/16(土) 15:44:41.67

日本語だと分離コードになるのか。
確かにMS関連しかその言葉聞かないし、ぐぐってもMS関連しか出てこない

**デフォルトの名無しさん** · 2013/02/19(火) 01:32:44.57

似たようなものだと、コードビハインドという単語ではないけどJSFの管理ビーンとか似た雰囲気

**デフォルトの名無しさん** · 2013/02/19(火) 08:22:24.77

Adobe FlexのMXML+ActionScript3がかなり似ているというか洗練されていると思う。
MXMLでのV定義は単純にAS3でのクラス定義の別記法なので、AS3でのクラス定義と
同様に実装するinterfaceを指定出来る。VMにもinterfaceを定義してあげればVとVMが
互いの実装を知らずにinterfaceだけを通してやり取りが出来る。
VMのinterfaceの先頭にBindableとアノテーションをつければ勝手にgetter・settetが
バインド可能になるのでデータバインディングでVMの値をVにはり付けるのも簡単。

**デフォルトの名無しさん** · 2013/03/03(日) 08:33:04.94

やっぱダイアログや画面遷移はView Serviceにするのが好きだな。

**デフォルトの名無しさん** · 2013/03/03(日) 10:12:08.72

同意
共通に使えるものにメッセージ使うのはアンチパターン
というかメッセージいらない

**デフォルトの名無しさん** · 2013/03/07(木) 11:13:30.47

MVVMの意図するところはこんな認識で合ってる？
・V<->VM の依存関係はバインディングに任せましょ
・VM はデータの加工と操作 (コマンド) の提供に専念しましょ

**デフォルトの名無しさん** · 2013/03/09(土) 07:15:19.68

大雑把にはあってるんじゃないか

**デフォルトの名無しさん** · 2013/03/09(土) 19:14:13.47

MとV&VMを別プロジェクトにして問題ある？

**デフォルトの名無しさん** · 2013/03/09(土) 19:48:12.38

>>635
ないって言うかむしろしろ(´・ω・｀)　

**デフォルトの名無しさん** · 2013/03/09(土) 19:48:13.70

よっぽど小規模でない限り分けるだろ

**デフォルトの名無しさん** · 2013/03/22(金) 14:44:16.04

開幕迎える前にグッバイ・モーガンになるんか？

**デフォルトの名無しさん** · 2013/04/01(月) 12:24:22.90

livet 詳しい人いたら教えてくれ。

ttps://github.com/karno/Mystique/blob/master/Mystique/Views/Dialogs/SettingSub/ColoringConfig.xaml

ここの200行あたりにある感じで、ConfirmationDialogInteractionMessageAction を使う、MenuItem を作った。
でもこの方法だと、MenuItem の IsEnabled に ListenerCommand の CanXXXX が反映されない。
IsEnabled に反映させるにはどうしたらいいんだろうか？

**デフォルトの名無しさん** · 2013/04/01(月) 13:51:12.65

MenuItemに直接アクション持たせてIsEnabled管理も別プロパティでやるか、
CommandのCan～状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ

**639** · 2013/04/01(月) 19:20:38.99

せっかく教えてもらったが、いってることがわからんズラ
「MenuItemに直接アクション持たせて」とはどのようすればいいんだろうか？
サンプルのサイトがあったら張ってもらえないだろうか。

「CommandのCan～状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ」
これをやるためには、MenuItem の Command にバインディングする必要があるだろうが、ダイアログの表示はコード・ビハインドでやるという理解でよいでしょうか？

質問ばかりですまんです。

**デフォルトの名無しさん** · 2013/04/01(月) 19:58:53.84

MenuItemのIsEnabledにコマンドの可否状態が反映されないって言うからMenuItemにコマンドはバインドした状態で反映されないって言ってるんじゃなかったの？
それともコマンドをMenuItemにバインドせずにMenuItemに反映されないって言ってるの？

ダイアログの表示ならコマンドで叩かれたVMからVへメッセージ飛ばしてやるんだろ
そのために確認用のトリガとアクション書いたんじゃないのか

**639** · 2013/04/01(月) 23:25:33.35

質問の仕方がまずかったかな。

IsEnabled と具体的なプロパティを書くのではなくて、
MenuItem の活性・不活性に CanXXXX が反映されない
と書けばよかった。

コードはリンク先に書いてあるのとほとんど同じ。
"Interaction.Triggers"に設定していあるのであって、
MenuItem の Command にはバインドされてない。

質問をかえれば、リンク先のようなコードを書いたが、
これでは SetDefaultColorCommand の CanSetDefaultColor
が MenuItem の状態（活性・不活性）に反映されません。
どうしたらいいでしょうか？
って感じです。