WPF(.NET, WinUI) GUIプログラミング Part26

**デフォルトの名無しさん** · 2021/06/20(日) 17:04:18.66

Windows Presentation Frameworkについて語るスレ。

前スレ
WPF(.NET4.x, .NET Core) GUIプログラミング Part25
https://mevius.5ch.net/test/read.cgi/tech/1612522463

関連スレ
Windows 10 UWPアプリ開発 Part 2
http://mevius.2ch.net/test/read.cgi/tech/1499658092/

コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/

**デフォルトの名無しさん** · 2021/09/13(月) 18:29:40.64

>>851
それを実装した汎用valueクラスを作ってそれを使う。

>>858
それが当たり前だよね。
完全にMVVMするのが目的になってしまった
なれのはて

**デフォルトの名無しさん** · 2021/09/13(月) 20:22:16.87

>>857
VMの書き方はだいたい同じだが、Viewでx:Bindが使えるからインテリセンスが効くし型のチェックもコンパイル時にやってくれる
あと、Viewから右クリックの「定義へ移動」でVMの変数定義に移動できる

**デフォルトの名無しさん** · 2021/09/13(月) 21:03:21.49

しょぼいプログラムほどMVVMでの実装も楽だからINotifyPropertyChangedを避ける理由がよくわからない

**デフォルトの名無しさん** · 2021/09/13(月) 21:18:47.94

しょぼいから
スケールメリットでねーーんじゃね？

**デフォルトの名無しさん** · 2021/09/13(月) 21:21:14.98

バインドしない人は文字－数値の変換も自分で書くの？

**デフォルトの名無しさん** · 2021/09/13(月) 21:46:08.83

>>860
VとVMの分離はべつにデザイナーとの分業だけが目的じゃあないが。というか重要度としては低い。
WPF知らない人にありがちな典型的な誤解。

**デフォルトの名無しさん** · 2021/09/13(月) 22:02:18.04

いまだにMVVMに親を殺されたようなのがいるね
イベントハンドラしこしこ書くのはもういやだよ
でもWPFはFrameをもっとMVVMフレンドリーに作ってほしかたよ

**デフォルトの名無しさん** · 2021/09/13(月) 22:10:10.87

いや、知ってるからなんだけどw
ボダン押したら押したら更新する、同期性も何もない。

APIを呼ぶだけ。
大きくなる予定なし。

こんなのすらさえWVVMしだすっていうw

**デフォルトの名無しさん** · 2021/09/13(月) 22:41:51.00

INotifyPropertyChangedとINotifyCollectionChangedの違いを知りたいです。
このサイトを参考に話します（Xamarinですけど）：
https://qiita.com/furugen/items/18bd2a521d1fa9927212
これは
public class MemoData
{
public string Title
{
get;
set;
}
}
のTitleがプロパティだから、
public class MemoData : INotifyPropertyChangedなんですか？
もし、上のが
public class MemoData
{
public List<string> Title
{
get;
set;
}
}
だったら、
public class MemoData : INotifyCollectionChangedになりますか？
それとも、この場合はListからObservableCollectionに変更するだけで解決ですか？
ObservableCollectionが元々INotifyCollectionChangedを含んでいるのは知っています。
また、public class MemoData : INotifyCollectionChangedと書くケースは皆無ですか？

**デフォルトの名無しさん** · 2021/09/13(月) 23:16:04.60

何をしたいかによる

**デフォルトの名無しさん** · 2021/09/13(月) 23:44:39.21

>>869
Mvvmじゃなくて通知の問題ね。
WPFのMvvm以前はこんな問題は発生してないねーー

**デフォルトの名無しさん** · 2021/09/14(火) 05:34:23.96

>>861
冗長。
コード側の6行は不要。XAML側の1行だけでOK。

**デフォルトの名無しさん** · 2021/09/14(火) 08:22:12.46

>>868
まだまだ初心者だな。
アプリに合わせて最適な実装方法を選択できるようにならなきゃ駄目だそ。道具は素材に合わせて使い分ける。
MVVMはあくまで道具の一つ。

**デフォルトの名無しさん** · 2021/09/14(火) 08:31:12.46

MVVMは目的じゃない

**デフォルトの名無しさん** · 2021/09/14(火) 10:03:00.45

>>873
ケースを想定せずにOKも何もないでしょうに

**デフォルトの名無しさん** · 2021/09/14(火) 12:11:35.18

コードビハインド禁止ゲームとか
アホの極み！

**デフォルトの名無しさん** · 2021/09/14(火) 13:51:43.59

今はPrismだけ使ってるけど、みんなReactiveProperty使ってるの？便利？

**デフォルトの名無しさん** · 2021/09/14(火) 19:55:37.76

>>874
もちろん、ポトペタやりたい人にとってはFormsがベストだしずっとそれを使い続けていればいい。

**デフォルトの名無しさん** · 2021/09/14(火) 20:32:08.68

この辺は変な布教をした奴のせいでずっと尾を引いてるな

**デフォルトの名無しさん** · 2021/09/14(火) 21:59:50.08

>>874
WPF使うならMVVMが常に最適解
MVVMイヤならWinForm使えばええねん

**デフォルトの名無しさん** · 2021/09/14(火) 22:01:29.25

>>878
俺の個人的好みだとPrismは中小規模だと大げさすぎる
ReactivePropertyはもう手放せないレベル
でもいまだにBindingの .Valueを書き忘れてハマるｗ

**デフォルトの名無しさん** · 2021/09/14(火) 22:05:51.96

俺なんかWinFormsでやるときでさえReactiveProperty使ってMVVMやるようになってしまったよ

**デフォルトの名無しさん** · 2021/09/15(水) 01:05:39.31

ポトペタやりたいならノーコードローコードでいい

**デフォルトの名無しさん** · 2021/09/15(水) 06:31:36.42

>>879
そう考えるってことはWPFを全然使いこなせていないってことだぞ。
WPFはFormsと比べればMVVMとの親和性が高いが、MVVMで作りやすいってのはWPFのメリットのごく一部。

>>881
全然違う。
日本語もWPFも勉強しなおし。
MVVM使うな、じゃなくて使うべきものに使えって書いてある。
思考停止してWPFだから必ずMVVM、は技術者として恥ずかしいぞ。

>>883
FormsにMVVMは馴染まない。
ちゃんとフレームワークに合った設計をしないと。

**デフォルトの名無しさん** · 2021/09/15(水) 11:37:21.40

煽り屋は下痢便食わせて多摩川にでも流すぞ

**デフォルトの名無しさん** · 2021/09/15(水) 12:22:16.17

君にはすべてのクラスに
void Update(bool force = true)
を書く事を許可しよう、頑張りたまえ

**デフォルトの名無しさん** · 2021/09/15(水) 12:50:15.43

言っている事は正しいしただの指摘、煽りではないだろ

**デフォルトの名無しさん** · 2021/09/15(水) 14:58:00.53

>>885
>FormsにMVVMは馴染まない。
お前の感覚以外にちゃんとした理由があるならぜひ

**デフォルトの名無しさん** · 2021/09/15(水) 15:46:29.15

理由もクソも、MVVMはそもそもWPFのデータバインディングを活用するために考案されたデザインパターン
双方向バインディングを使用しないなら定義上MVVMではない

**デフォルトの名無しさん** · 2021/09/15(水) 15:57:04.37

やったこと無いけどFormsでもデータバインディングできるんじゃ？

**デフォルトの名無しさん** · 2021/09/15(水) 16:02:38.01

>>890
Forms+ReactivePropertyで双方向バインディングやってるけど

**デフォルトの名無しさん** · 2021/09/15(水) 17:02:45.49

>>890
お前の言うMVVMの定義を教えてくれ

**デフォルトの名無しさん** · 2021/09/15(水) 17:05:49.55

業界アキーテクチャ的には
双方向バインディングはバッドパターンだ
糞認定済み

**デフォルトの名無しさん** · 2021/09/15(水) 17:09:11.47

react等の先端frameworkに比べると
思想的にかなり見劣りする

**デフォルトの名無しさん** · 2021/09/15(水) 17:28:11.46

次はMVUだったっけ？

**デフォルトの名無しさん** · 2021/09/15(水) 18:32:29.56

実行ファイル(.exe)が出力できて将来性のある
プラットフォームってやっぱりWPFしかないのかな？

**デフォルトの名無しさん** · 2021/09/15(水) 18:36:43.11

将来性はないです

**デフォルトの名無しさん** · 2021/09/15(水) 18:36:44.91

最先端はなんだろうAvaroniaとか？
SilverlightもWindows Phoneも、昔はいろいろあったよね

**デフォルトの名無しさん** · 2021/09/15(水) 18:47:44.45

>>897
WPFやるぐらいなら今後はWinUI3じゃ?

**デフォルトの名無しさん** · 2021/09/15(水) 19:00:42.07

WPFに将来性はあまりないのか

>>900
ありがとう。ちょっと調べてみる

**デフォルトの名無しさん** · 2021/09/15(水) 20:53:25.10

>>885
日本語勉強するのはあんただよ

>

**デフォルトの名無しさん** · 2021/09/15(水) 21:01:46.66

>>890
バインディングはあまり関係ないな。どっちかというと依存の方向がV→VM→Mだというのが重要。
そういう意味でFormsで真似しても似て非なるもの。

**デフォルトの名無しさん** · 2021/09/15(水) 21:09:50.88

すでに10年以上過ぎてて将来性とか言われても
枯れてる方に分類されると思うんだけど、一体どんな期待してるんだ

**デフォルトの名無しさん** · 2021/09/15(水) 21:13:29.91

>>903
その方向の連携もFormsでできますけど

**デフォルトの名無しさん** · 2021/09/15(水) 21:43:58.90

>>905
その「連携」ってどういう意味で使ってる？
一般に依存の方向と制御の方向は別物だがここで重要なのは依存の方向。

**デフォルトの名無しさん** · 2021/09/15(水) 22:43:25.21

>>906
もちろんVの表示はVMとMに依存してるよ

**デフォルトの名無しさん** · 2021/09/15(水) 23:04:57.93

依存っていうからてっきり依存関係プロパティの話かと思ったら、全然違ってた

**デフォルトの名無しさん** · 2021/09/15(水) 23:17:22.66

>>907
やっぱりなんか理解してない。ここではいわゆるSOLID原則のDで言う依存性のこと。
MVVMでVが直接Mに依存することはない。

**デフォルトの名無しさん** · 2021/09/15(水) 23:30:44.49

Vで必要なMを作るんだから依存しないわけがない

**デフォルトの名無しさん** · 2021/09/15(水) 23:49:11.29

>Vで必要なMを作るんだから依存しないわけがない

「依存」の意味が通じてないとそもそも会話にならんな。

**デフォルトの名無しさん** · 2021/09/15(水) 23:50:13.08

>>882
ReactivePropertyはメンテナーが実質ひとりだからなぁ。
その.Valueも意外と面倒くさいんだよね。

**デフォルトの名無しさん** · 2021/09/15(水) 23:54:05.43

ObservableCollectionがAddRangeに対応して、
主要なWPFコントロールがAddイベントにてe.NewItemを同時に複数受け付けてくれれば神アプデなんだけどMSやってくれないかな。

ObservableCollection関連は、各ItemへのProperyChangedの登録／解除が超絶に面倒臭いんだけど、ReactivePropertyだとお手軽になる？

**デフォルトの名無しさん** · 2021/09/16(木) 00:20:59.60

>>911
なんかFormsでMVVMできないことにするために適当な理屈をウダウダ後付けで言ってんな

**デフォルトの名無しさん** · 2021/09/16(木) 00:38:24.68

|\/| Ｗ（

**デフォルトの名無しさん** · 2021/09/16(木) 01:24:47.16

>>912
今はokazukiがメインメンテナ？
彼がやめたら俺がやるわ

**デフォルトの名無しさん** · 2021/09/16(木) 01:54:46.93

>>913
極力簡易記述できるようにしてると思うよ

**デフォルトの名無しさん** · 2021/09/16(木) 03:51:43.21

おまえら酒どんくらい飲んでる？

**デフォルトの名無しさん** · 2021/09/16(木) 08:50:08.52

MVVMはXAMLやFXMLといったマークアップ言語があって初めて実現する
XAMLを信じないものに未来はありません
XAMLは偉大にして唯一神と3回唱えるのです

**デフォルトの名無しさん** · 2021/09/16(木) 12:17:15.94

ObservableCollectionで個々のItemのPropertyChangedを取りたいときって、
NotifyCollectionChangedAction.Add・RemoveにPropertyChangedのイベント購読を登録・解除
しますよね？

その配列をClear()しちゃったら、Removeでの解除を通らないと思うのですが、
この場合、メモリリークしますか？

**デフォルトの名無しさん** · 2021/09/16(木) 12:57:51.05

>>920
NotifyCollectionChangedAction.Reset飛んでこない？

**デフォルトの名無しさん** · 2021/09/16(木) 13:30:05.34

>>921
自分も最初はReset飛んできたとき解除すればいいと思ったんですが、配列がすでに消去済みなので解除できないことに気づきました。
各ItemのコンストラクタとDisposeに登録解除を書くしかないのかな。

**デフォルトの名無しさん** · 2021/09/16(木) 14:17:14.99

>>903
向いてるかどうかは別にして、
FormをVとしてVMとM作ってバインディングすればMVVMできると思うんだが
>似て非なるもの
どこが異なるんだよ？
お前の言う本当のMVVMってなんだよ

**デフォルトの名無しさん** · 2021/09/16(木) 14:20:02.81

ああ、バインディングはMVVMの構成要件じゃないのね
ますますお前の意見がわからんわ

**デフォルトの名無しさん** · 2021/09/16(木) 14:31:38.92

>>922
ObservableCollectionに
protected override void ClearItems()
ってのがあるから
ObservableCollectionの派生クラス作ってClearItems()をオーバーライド
ClearItemsが呼ばれたタイミングで購読解除すればいいと思う。

**デフォルトの名無しさん** · 2021/09/16(木) 14:37:43.93

>>922
public class MyCollection<T> : ObservableCollection<T>
{
protected override void ClearItems()
{
//ここで購読解除
base.ClearItems();
}
}

**デフォルトの名無しさん** · 2021/09/16(木) 15:14:51.39

>>926うおーすごい。stack overflowでもそこまでドンピシャな回答無かったです。
ありがとうございました。

**デフォルトの名無しさん** · 2021/09/16(木) 15:50:04.83

コレクションをオーバライドして
改良するってアーキテクチャ知らない人多いね

**デフォルトの名無しさん** · 2021/09/16(木) 18:38:42.38

結論としては、超絶に面倒臭いって事か

**デフォルトの名無しさん** · 2021/09/16(木) 19:41:02.61

仮にオーバライドしないで出来るならその方がずっと楽だしな

**デフォルトの名無しさん** · 2021/09/16(木) 22:04:26.97

>>923
クリーンアーキティクチャのあの同心円の図を想像するとわかりやすい。一番外側がVで中心がM。
その依存性逆転のためにバインディングという仕組みを使っているだけに過ぎない。

**デフォルトの名無しさん** · 2021/09/16(木) 23:23:17.08

https://docs.microsoft.com/en-us/archive/blogs/johngossman/introduction-to-modelviewviewmodel-pattern-for-building-wpf-apps
バインディングが関係ないとか言ってる奴はこのMVVMの原典を読んでおくように
> Model/View/ViewModel also relies on one more thing: a general mechanism for data binding.

**デフォルトの名無しさん** · 2021/09/17(金) 01:51:24.22

In practice however, only a small subset of application UI can be data bound directly to the Model, especially if the Model is a pre-existing class or data schema over which the application developer has no control.
モデルが既存のクラスで開発者がコントロールできない場合は、UIの一部のみを直接モデルにバインドできます。
ってあるけど、既存のクラスなんてINotifyPropertyChanged実装してるわけないし、どういう意図なんだろ？
OneTimeならそりゃできるだろうけど。

**デフォルトの名無しさん** · 2021/09/17(金) 02:13:01.71

>>931
バインディングが単なる手段に過ぎないという意見は分かった
で、
>Formsで真似しても似て非なるもの。
はどういうことなんだ？
お前の言う真のMVVMとはどういったものなんだ？

**デフォルトの名無しさん** · 2021/09/17(金) 07:24:25.96

滅茶苦茶な機械翻訳を鵜呑みにして混乱してる初心者あるある
また断続的な絞首刑が発生しちゃうね

**デフォルトの名無しさん** · 2021/09/17(金) 08:29:29.04

>>935
正しい翻訳と意図を教えてください。

**デフォルトの名無しさん** · 2021/09/18(土) 11:02:29.85

>>935
正しい翻訳と意図を教えてください。

**デフォルトの名無しさん** · 2021/09/18(土) 13:27:50.51

Microsoft Silverlightがオープンソース化、「OpenSilver」ベータ版リリース
https://news.mynavi.jp/article/20210916-1974193/

**デフォルトの名無しさん** · 2021/09/18(土) 14:29:04.75

>>938
MSはどっち行きたいねん？
一つがっちりしたのを標準で出せや！

**デフォルトの名無しさん** · 2021/09/18(土) 14:42:52.80

Silverlightは救済策だろう
メインストリームはWinUI

**デフォルトの名無しさん** · 2021/09/18(土) 14:59:53.94

ActiveXじゃなくてWASMベースになったってのが興味深いな。
デスクトップ版も用意したうえでBlazorと組み合わせてほしい。

**デフォルトの名無しさん** · 2021/09/18(土) 15:32:32.42

ソースジェネレーターでバインディング周り上手い事オーバーヘッド無しに出来んかな

**デフォルトの名無しさん** · 2021/09/18(土) 15:59:37.03

>>939
まだわからんの
オープンソースだよMSは

**デフォルトの名無しさん** · 2021/09/18(土) 16:06:02.78

MSとどういう関係があるのか読んでも分からん

**デフォルトの名無しさん** · 2021/09/18(土) 16:46:49.61

>>944
タイトルが悪いと思う
オリジナルのSilverlightをMSが作ったってだけで、MSはほぼ無関係だな
UserwareがWebAssemblyで動作するようにSilverlightを実装しなおしたものをオープンソースでリリースしただけ

**デフォルトの名無しさん** · 2021/09/18(土) 16:50:07.13

Userwareって会社ね
既存のSilverlightアプリをSilverlightからOpenSilverに移行するソリューションを売るみたい

**デフォルトの名無しさん** · 2021/09/18(土) 18:33:51.64

お
オープンソースSilverlightか
光ちゃんも引っ張ってこい

**デフォルトの名無しさん** · 2021/09/18(土) 19:08:58.03

>>945
タイトルが悪いと言うかわざとだろ、これ
UserwareがMicrosoftからソース譲渡してもらったならわかるけど "reimplementation of Silverlight" だから要するに互換ソフトをオープンソースで作ったって話でしかない

**デフォルトの名無しさん** · 2021/09/19(日) 04:13:06.67

あれ？
さっき思ったんだけど、
C#でしかできないことってあるよね？
ループで回して同じものを複数表示するとか

逆にXAMLでしかできないことってあったっけ？
無い気がする・・・

そんでMVVMもXAMLなしで出来るんでしょ？
そしたらXAML要らんじゃん・・・

**デフォルトの名無しさん** · 2021/09/19(日) 04:34:10.41

世の中のDSL全部C言語で書けよ的な話か？

**デフォルトの名無しさん** · 2021/09/19(日) 06:24:30.46

>>949
画面をXAMLで書けるのがWPFの一番のメリットなんだが

**デフォルトの名無しさん** · 2021/09/19(日) 10:50:54.04

XAMLは筋の悪い技術だよ
ループ等を無理矢理バインディングで実装しなきゃいけないために複雑怪奇になってる
普通に文字列のテンプレートエンジンか、Reactみたいにコードでよかった
MVUでは結局コードになったね

**デフォルトの名無しさん** · 2021/09/19(日) 12:01:27.73

XAML Styler必須だよな、なぜVisual Studioに標準搭載しないのか

**デフォルトの名無しさん** · 2021/09/19(日) 13:28:03.13

ループって何言ってるか分からんがリストのことならコレクションバインディングするだけでしょ
違うならすまん

**デフォルトの名無しさん** · 2021/09/19(日) 13:52:08.27

ObservableCollectionとListViewをバインドするだけとちゃうの？

**デフォルトの名無しさん** · 2021/09/19(日) 14:12:08.70

>>951
画面をXAMLで書けることの何がメリットなの？

**デフォルトの名無しさん** · 2021/09/19(日) 14:13:52.23

>>952
禿同
Viewと分けるにしても、XAMLなんか使わずにコードでいいじゃんね

**デフォルトの名無しさん** · 2021/09/19(日) 14:17:30.11

>>950 >>954-955
スマソ、確認だけど、
XAMLで出来ること　＝　コードビハインドで出来ること
なん？
すべての機能が一対一で相互互換性あるの？

**デフォルトの名無しさん** · 2021/09/19(日) 14:25:03.65

別にMVVMは強要されてる分けじゃない
使いたくなければ使わなくていいよ

**デフォルトの名無しさん** · 2021/09/19(日) 14:26:01.77

MVVMじゃなくてxamlか
xaml無しでUI書くこともできるだろう、好きにすればいい

**デフォルトの名無しさん** · 2021/09/19(日) 14:27:02.36

メリットは宣言的なところ
jsさえあればDOMでdocumentを構築できるがやる奴なんかいないのと同じ