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

2024/08/20(火) 21:16:46.38

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512

WPF(Windows Presentation Foundation)について語るスレ。

前スレ
WPF(.NET, WinUI) GUIプログラミング Part32
https://mevius.5ch.net/test/read.cgi/tech/1694210576/

関連スレ
Windows 10 UWPアプリ開発Part 3
https://mevius.5ch.net/test/read.cgi/tech/1627556967/

コードを貼る場合は以下のサイトの利用をお勧め。
https://ideone.com/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2024/12/31(火) 23:18:09.38

>>406
サンクス、理解できた

2025/01/01(水) 15:48:34.59

AppleとOpenAIが提携したから何かやるつもりでネイティブにしてるんじゃないんか

2025/01/01(水) 15:54:30.70

MS「…　いや…なんでも…」

2025/01/01(水) 23:40:44.91

MS的にはCopilotで自前で自由にして良い権利を得てたのかも知れんけど、結果は散々だな
今のMSにエンドユーザー向けの気の利いたサービスを開発できる能力があるとは思えん

2025/01/02(木) 18:25:22.13

MS365 Copilotは酷いよなあ
基本的な応答の品質からしてChatGPTと同じモデル使ってるとは俄かに信じられんレベルだしOffice連携も冗談みたいなゴミ
唯一役に立つのはTeamsの要約くらいだな
近年のMSのエンタープライズ向けプロダクトの例に漏れず情シスという名のブルシットワーカー達が経営陣に「やりました」と言うためだけに作られていて、
全くユーザーの方を向いていないしプロダクトとしての思想が何も感じられない
ただ機能表に丸を記入させるためだけに開発されている

2025/01/07(火) 00:36:52.79

最初から脳内で結論が決まっている人達…

2025/01/11(土) 23:04:19.08

WPFのフレームワーク周りがよく分かってないので聞きたい
調べると CommunityToolki.MVVM, ReactiveUi, ReactiveProperty, Prism などが見つかるけど、これらはどれか一つを選んで使うようなもの？

どれもMVVMのためと聞くけど、これらは同じ目的を持った異なる設計思想のライブラリという感じなのか、それとも異なる用途のもの (組み合わせて使える) なのか
スレ民のおすすめ、好みなどもあれば教えてもらえると嬉しい

2025/01/12(日) 13:42:32.40

>>413

俺は Prism 使ってるけど、どれでもいいと思う
MVVM Toolkit は INotifyPropertyChanged の実装とかで code generator 使えるのが売り
Prism は機能が豊富なのが売りでダイアログやナビゲーション機能(Pageの代替) とか他にはないのが多い、ただしライセンスが特殊

.NET9 & C# 13 preview だと fieldプロパティ使えるから code generator 使わないでもシンプルにかけるんだよね
こっちの方が当然コンパイルも速いし、View から直接Modelにジャンプできるのが便利
.NET10 & C# 14 ではこの書き方が標準になるはず

```
# INotifyPropertyChanged
public class Model : BindableBase
{
public string Name { get; set => Set(ref field, value); }
}

# ICommand (lazy初期化)
public DelegateCommand HogeCommand => field ??= new(() =>
{
MessageBox.Show("hoge");
});

```
フレームワークは DI使えればなんでもいいかな

2025/01/14(火) 14:52:54.36

Webではフレームワークというとフレームワークが主でアプリケーションコードをその上に乗っけるようなものだが、
ああいうのを念頭に置くならWPFのはフレームワークというより単なるサンプルやツールの寄せ集めと言った方が近い
基本的に必要なものを適当に掻い摘んで使うもの、何ならソースコードをコピペしてきて自作してもいい

2025/01/14(火) 15:45:33.97

短かく簡単にしたいっていうならPropertyChanged.FodyとCaliburn.Microの組み合わせが頭おかしいレベルに省略できる。
>>414 の例によると、Set()も要らないしDelegateCommandも書かずに動作する。
だから問題なのはMVVMをどうするかではなくXAMLをどうするかに始終。

2025/01/15(水) 15:34:04.72

C#はシンタックスシュガーお化けなのにXAMLはこれっぽっちも短縮系がないのは何でなんかね
何もかもがクソ冗長で嫌になってくる

2025/01/15(水) 18:43:56.34

View側で何でもできるとそれはそれでスパゲッティになる
React がその例

Viewにロジックを極力書かないのがWPFの流儀なんでそれに従うしかない

2025/01/15(水) 19:25:58.54

なんじゃそりゃ

2025/01/15(水) 21:30:16.76

>>418
本当のスパゲッティソースを見たことがないんだな
山岡さんの気持ちがわかったような気がする

2025/01/15(水) 21:34:09.40

コード量はXAMLの方が何倍も多いよ
糞フレームワークのおかげで

2025/01/16(木) 17:15:23.31

XAMLが大成功して広く使われてたら今頃はとっくに virtual DOM & one-way data flow アーキテクチャに移行していただろうし、
C#にもJSXのようにXAMLをインラインで書けるようにする拡張が入っていただろう
そうするほどの存在感をXAMLは示せなかったというだけのこと

2025/01/16(木) 17:22:20.40

XAMLにC#書けるんだからそれで我慢しなよ

2025/01/16(木) 17:51:47.75

ReactからWPF使って快適になったんだけどこれは俺だけ？

流行ってるからいい技術って思ってんだろうけど単にWebの方が拝金主義者にとって都合がいいだけに過ぎない

2025/01/16(木) 18:18:59.08

WPFじゃ簡単な画面しか作れないよ

2025/01/16(木) 18:34:38.58

派手なコントロール作ればいいんじゃね？
スタイルのカスタムとか無視してゴリゴリ画像とか貼りまくればいい

2025/01/16(木) 18:35:56.72

>>424
どこがどのように快適になったのかを具体的に教えて

2025/01/16(木) 19:27:49.37

>>427
UIとロジックが分離してるおかげで標準コントロールをそのまま使うだけでよい
このことから生成AIとの相性が抜群

テーマはサードパーティのを入れるだけで勝手にモダンな見た目になる

>>425
デスクトップアプリはマシンリソース使えるアプリ使えたりするし
UIなんかより動作するアプリ側に価値があるものを提供できる
それができればUIなんぞどうでもいい

2025/01/16(木) 20:25:24.48

>>428
UIとロジックの分離なんてReactでも当然に実現されてる
テーマは適当なCSSフレームワーク使えば余裕
まあまともに使ってないんだろうな

2025/01/16(木) 20:41:31.65

>>429
全然分離実現されてないから、使ってないのはお前だろ

ReactはViewしか存在しない、react hooks とかいうゴミを導入したことでさらにスパゲティが悪化した
テーマもCSSフレームワークを使えばそれに強く依存することになる、それが問題だといっている
State管理もいろいろ乱立し終わってる
WPFだとViewとロジックが分離されているし、標準コントロールにテーマを適用する形になるからほとんど改修は必要ない、これが大きなメリット

フロントエンドはAngularの方が良いな
よく使われている=いいものではないのよ。

2025/01/16(木) 20:52:24.00

そんなことはどうでもいいからtextboxにプレースホルダぐらいは実装してくれよ…

2025/01/16(木) 22:25:36.62

WPF推してるやつの時代錯誤感やベェなw
ここまでとは思わんかった

2025/01/16(木) 22:35:10.45

おじいちゃんだからそっとしておいてあげて

2025/01/16(木) 22:37:23.51

既製品でよければExtended WPF ToolkitにWatermarkTextBoxがあるだろ
自作してもいいのよ

2025/01/16(木) 22:58:43.09

>>425
手間暇かければ出来ないってことはないだろう
割に合うかは別として

2025/01/16(木) 23:48:51.43

>>435
逆立ちしてもCSSに勝つのは無理だよ

2025/01/17(金) 02:03:42.02

>>436
CSSと比べるつもりは無いんだけど
WPFでは不可能な複雑な画面ってどんなのさ

2025/01/17(金) 02:05:09.48

>>437
webのデザインシステム見たこと無いのか？

2025/01/17(金) 02:44:40.96

手間暇かかってやってられないならともかく、作れないってのは分らんな
もしかしてカスタムコントロールやビヘイビア等の力業無しのXAML縛り前提の話なのかな

2025/01/17(金) 08:06:24.51

>>432
わざわざ推してないもののスレに来てるお前の方がやべぇよ
webが好きなら一生webをやってろ、俺はそれに価値を感じていないだけ
価値のあるwebアプリってのを見たことがない、価値があるのはそこに提供されるコンテンツや
ChatGPTのようなバックエンドサービスであって react だのそういった技術に価値を感じたことはない

2025/01/17(金) 11:45:29.01

生産性度外視してWPFだって出来るもんって言ってもなあ

XAMLなんて控えめに言ってもバッドノウハウの塊だろ
GridやStackの各種パネルがくんずほぐれつしてる他人の書いたXAMLなんか読めねえよ
さらにそこにリソースやテンプレートが乗っかってきたらもう死にたくなる

2025/01/17(金) 12:53:04.28

スレで繰り返されるweb

2025/01/17(金) 13:22:01.00

いい加減CSS最高君に構うからいけないんだと気づこうぜ

2025/01/17(金) 13:25:07.45

>>441
全てViewに固めてるReactの方が読めないわ
何useStateだとかuseEffectって？
JSXの中で三項演算子やら複雑なロジックが書いてあって意味わかんねーよ

大体XAMLなんてデータ表示してるだけでロジックがないんだから読む必要なんてない

読む必要があるのはロジック

2025/01/17(金) 13:28:05.39

XAMLに文句言ってる奴はqtやらWinformsでGUI作ったことがないんだろうな
ReactだのWeb技術を持ち出すのがその証拠

少なくともWindowsアプリ開発において開発生産性でWPFより右に出るものはないでしょ

2025/01/17(金) 13:46:39.82

とはいえ今時のWindowsアプリって、不特定多数向けの新規開発はMS謹製のもの含め大半がWebベースになってるからねえ
生産性は慣れやスキルセットの問題もあるから単純にどっちが上というものではないが、事実として時代は変わってしまった

2025/01/17(金) 15:45:46.58

令和のコボラー

2025/01/17(金) 15:54:14.26

やべー
最近のアプリなんて何ひとつ使っていなかったわ……

2025/01/17(金) 21:38:14.28

マイクロソフト自身もVS CodeなどはWeb系の技術で作ってるからな
Windows限定ならWPFはそれなりに有力だけど、世の中のニーズがマルチプラットフォームアプリやWebサービスに向かってる以上はWeb技術は避けられないと思う

React hookが嫌いとかはたぶん慣れの問題で、逆の立場 (React分かるけどWPFは未経験という人) から見たら同じようにWPF難しい、ってなるだけかと思う

2025/01/17(金) 22:53:47.34

>>449
WPFは最初は難しいが慣れると快適で生産性が高いと感じる、実際に自分がそうだった
Reactは最初は簡単だが、慣れるとクソに感じてくる。React Hooksも同様。
Angular の方が断然いい

人気だからよいものとは限らない

2025/01/17(金) 23:25:27.76

React Hooksとか超コードみじかいんだが...
変な状態管理のコードでもつかったからだろ
MVVMみたいな糞選択がすれば、糞な結果になるのはReactも同じって事よ

2025/01/18(土) 00:53:27.87

MSはOutlookをWebView2に移行したね
WPFの最大の敵はこんなところにいるアンチ達ではなくマイクロソフトなのだ

2025/01/18(土) 01:10:13.97

Web苦手おじさん発狂中

2025/01/18(土) 03:05:36.05

ところでクロスプラットフォームなら名前の出たQtのQMLは超いいよ
Windowsではネイティブコントロールを使ってくれないので違和感があるのが欠点だけども

2025/01/18(土) 06:43:10.38

>>452
どこ情報？

2025/01/18(土) 08:21:38.12

>>455
https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/overview-new-outlook#architecture
> The new Outlook for Windows, built upon modern service architecture, is inspired by the Outlook web experience. It operates within a streamlined Native Windows Integration Component and utilizes WebView2.

なおReactを使用している模様
https://www.neowin.net/news/microsoft-plans-to-unify-outlook-across-platforms-using-web-technologies/

2025/01/18(土) 11:43:33.23

>>452
単にアプリの要件に合わせて適切な技術を選択しているだけなのでは？
Outlookはwinネイティブの機能は何一つ使わないだろうからクロスプラットフォームにする上でWebを使いまわせるメリットが大きいんだろう

Windows11の電卓は？動画プレイヤーは？

2025/01/18(土) 11:45:44.49

>>451
コードの短さ＝保守性の良さ、高生産性と思ってる時点でレベルが知れるね

Reactなんてone wayアーキテクチャが大規模において使い物にならないからいろんなstate管理のパターンが乱立してるんだけどね

2025/01/18(土) 12:12:08.09

state管理の難解さは人間の方に問題がある気もするけど
状態の組み合わせ爆発で人間の脳では追いきれない
バグがあって当たり前

2025/01/18(土) 12:52:58.93

>>457
その例はちょっと苦しいなw
PCでの動画再生なんて今時ほとんどWebだし、電卓、、まああなたが開発しているのが電卓なんだったら何も言うまい

2025/01/18(土) 16:28:55.41

two way推しとは...笑

2025/01/18(土) 16:30:03.12

WPFデザインのメリットって何？
WindowsFormでも行けるよね？

2025/01/18(土) 18:36:44.86

>>461
one wayなFlowアーキテクチャで十分ならなぜState管理のライブラリが乱立してるの？
Angularはそうでもないけど

2025/01/18(土) 18:50:47.23

>>463
WPFのMVVMライブラリがなんで乱立してんの？を自問自答してみれば自ずとわかるのでは？w

2025/01/18(土) 18:53:03.31

>>457
>Outlookはwinネイティブの機能は何一つ使わないだろうから
これマジで言ってるの？

2025/01/18(土) 19:21:38.39

>>463
WPFしかやってないと、
Reactとかアカデミックな技術論の盛んさに腰を抜かすだろうね

2025/01/18(土) 19:27:30.06

Geminiの回答

UIのViewModelにおけるデータフローがTwo-wayからOne-wayにシフトした主な理由は、
* 複雑性の軽減: One-wayはデータの流れが単方向で、状態管理がシンプルになり、バグの発生を抑制できる。
* テストの容易性: 各コンポーネントを独立してテストでき、テストケースの作成が容易になる。
* 大規模アプリケーションへの適応性: スケーラビリティが高く、コンポーネントの再利用が容易になる。
* リアクティブプログラミングとの親和性: データの変化をリアルタイムに反映させやすく、非同期処理をサポートする。
これらのメリットから、現代のフロントエンド開発ではOne-wayが主流となっています。
より詳しい説明が必要な場合は、お気軽にご質問ください。

2025/01/18(土) 19:29:25.78

>>463
angularはフルスタックフレームワークだね
意味分かるかな？

2025/01/18(土) 19:31:08.08

ちなみに一般的な認識ではreactはライブラリー

2025/01/18(土) 21:29:39.61

Webだって競争の結果、今に至っただけなんだよなぁ
One-WayのMVVMフレームワークが良ければVueだってあるわけじゃん？
最近触ってないから、最近のVerでどんな実装が主流なのか知らないけど

2025/01/18(土) 21:30:28.55

❌OneWay->○TwoWay

2025/01/18(土) 23:40:58.23

one-way dataflowって要は
ビューはモデルの状態を反映するのが仕事
ビューはモデルに指示を出すのが仕事
状態の更新はモデルの仕事
というだけのことで、MVVMでもまともな作り方してたら基本的にそうなってるはずなんだけどな
ただ、2-way bindingしちゃうとモデルの状態を反映していたはずのVMのプロパティがビューの状態変化によって汚染されてしまう
それを考慮して適切に同期をとらなきゃいけないのは複雑だから2-way bindingはやめようということだね
しかしその辺は実装上のテクニカルな問題であって、本質的には前述の役割分担が適切に行えてさえいれば大きな違いはないのだが、
この残念な人は責務の分離が正しく理解できてなくてVMに状態更新のロジックを書いちゃってるんだろうね

2025/01/18(土) 23:42:23.90

両方触ったうえでReact糞WPF快適と言ってるんだがｗ
お前ら口だけのクズと違ってWPFで割と高度なアプリ作って1000スター持ってるからね
悔しかったらそれぐらいの実績上げてみろよ

わざわざ嫌いなもののスレにきてWPF下げてReact持ち上げる癖にReactでもWPFでも大したアプリ作ったことないんだろ
IT土方にも適用できず発狂しちゃったんだろうね

2025/01/19(日) 00:43:59.86

技術的な良し悪しとは違うけど、今からWPFを学ぼうとすると情報を探しづらい (古い情報が多い) のがつらい感じはする
人気再上昇みたいな未来は見えづらい

2025/01/19(日) 01:30:05.22

このスレ見てるとWPFを学ぶ気が失せる
特にCSS使えないってのはかなり致命的だった
MS奴隷しか使わないフレームワークなんだって事が判ったよありがとう

2025/01/19(日) 02:14:27.03

何と戦ってるんだ？

2025/01/19(日) 02:31:06.30

ReactというかFlutterでもSwiftUIでもなんでも良いんだけど、最近のFlux/コンポーネントベースのフレームワークはガチで使いまわせるが
WPFのユーザーコントロールは結局既存のコントロールの拡張を遠回しに実装するだけで
複数のアプリで使いまわせた試しがほとんどない
見た目を分離することと生産性の向上は全く関連性はない

2025/01/19(日) 08:30:40.98

>>477
じゃあCustom Control作るか、標準コントロールにtheme適用すれば？
そもそも見た目を分離するってのはユーザーコントロールの話じゃないからね
ViewとViewModelを分離することも言ってる

例えばある処理中に Spinner を実装する場合は、Reactだと Viewに状態を含むロジックをすべて書くことになっているから
非常にテストがしづらいしスパゲティになるんだけど
WPFだとプロパティとAsyncCommand を定義するだけでViewModel上でSpinnerが完結するから
完全に見た目とロジックが分離していることになる

よってViewModelだけテストすればよいし、Viewはただ表示するだけのシンプルなものになる

MVVMを叩いている馬鹿は、WinformsやらQtやらでそれなりのGUIを作ったこともなければReactやらでまともにテストを書いたことがないんだろう

2025/01/19(日) 08:44:45.64

複数アプリで使い回す？ってのをそもそもライブラリ提供者でもなくアプリ開発者が普通やるんかね。デスクトップアプリ開発は標準コントロール使うのが基本だと思うけど
俺はCustom Controlをわざわざ作りたいという状況になったことはほとんどない、ライブラリ開発者ではないから

同じアプリで1つのUserControlを複数使い回す方がよっぽどReactのコンポーネント指向に近いものだろうけど
DependencyPropertyとRoutedEvent使えば同様のことができるでしょう
DependencyPropertyの構文はひたすら冗長で確かにクソだけど慣れたら別にどうとでもなる

単にWPFに慣れてないだけに過ぎない、それでいちいち嫌いなもののスレに来てWeb技術を持ち上げるのはなぜ？
そのWeb技術を使って革新的なアプリでも作ってろよ、時間の無駄だから

2025/01/19(日) 09:10:32.89

MahApps.MetroもWPF UIもあるので好きなだけ見た目変えたらいい
標準がいいと言われてもな、ToggleButton好きなやつおる？

2025/01/19(日) 09:31:50.75

トグルボタン(トグルスイッチ)と言えばね、効果がすぐ体感できる対象でしか使うべきではないとガイドラインにもあったと思うが
OSのWindowsの設定では不要と思える箇所にもスイッチが頻出して階層の深さとも相まって相当カオスなUIになってる
OSアップデードの度に項目の場所が変わるし動的に増えたりするギミックもあるし作ってる側は楽しいかもしれんが
使う側は一体何がどこにあって何が規定の設定だったのか把握するのは困難
これってどうにかなりませんか？MS奴隷の方々

2025/01/19(日) 09:38:28.42

https://youtu.be/fBtR_Jr7jIM
DGRAMなんかで受信してリアルタイムでグラフ表示などはwebじゃ厳しい。

2025/01/19(日) 09:40:21.82

>>474
英語ならいくらでもあるね、pluralsightとか。
ドキュメントや技術本程度の英語すら読めない雑魚はそもそもエンジニア向いてないから辞めるか英語の勉強から始めた方がいいと思う

>>475
お前みたいに5chなんか見て技術を選定するような馬鹿は何もできないだろうから使わなくてもいいよ

自分の作りたいものがあれば自分に適した技術を選択して、それで開発すればいいだけ

俺はWPFで価値があるもの作れてるからそれでいいのよ

2025/01/19(日) 09:43:41.37

webスレに人がいないからな
ここに来るしかないのだ
ム板も限界集落だけども

2025/01/19(日) 09:53:05.06

正直現役世代の技術をこんなとこで話さないからね
昔話と、時代に取り残されたジジイをからかうだけの場所

2025/01/19(日) 09:55:16.62

node.jsのdgramモジュールを利用してElectronでデスクトップアプリとして作れるけど。
しかも当然MacでもLinuxでも動く。

2025/01/19(日) 10:45:51.06

別にMicrosoft.Extensions.AIの話をしてもいいんだけど、ここWPFスレだし？
ObservableCollection<ChatMessage>の使い方とかこじつけとこうか

2025/01/19(日) 10:51:43.11

>>485
20代で趣味でOSS開発してるだけですけど。それでスター数1000ありますけど。

勝手にジジイ認定して面白いか？

2025/01/19(日) 11:26:31.80

>>482
証券取引の業務クラアイアントで
アーキをWPFからWebに移行した俺が
10年以上まえからWebでやってる

2025/01/19(日) 14:00:36.23

reactなんて古式ゆかしいステートマシンがアーキテクチャのルーツだろ？
MVVM脳のままで使おうとすればそりゃぐちゃぐちゃになるわな

フレームワーク使うなら前提とするアーキテクチャには100%従うのがスタートラインだろ
そこから外れたことをやろうとするとたちまち破綻するのはどんな優れたものを使っても同じ

2025/01/19(日) 14:26:56.08

他のスレに投下してスルーされたけど
ファイラースレより
Electron製TabSpaces
Tauri製spacedrive
触ってこいって
酷いもんよ

2025/01/19(日) 15:22:20.74

>>478, 479
tailwind cssやshadcn/uiみたいなのが流行ってるのは他人やAIが書いたコンポーネントをコピペしてそのまま動くからだよ
v0なんかの生成AIサービスもそれ前提の仕組みになってるしね

2025/01/19(日) 15:25:02.25

それくらいコンポーネントベースのフレームワークは再利用性高いって話

2025/01/19(日) 15:42:10.87

俺WPFで生成AI使いまくってけどかなりコピペで済んでるけどね
標準コントロールだけ使って見た目はライブラリに任せてるだけだし

お前のメリットで言うとWPFの方が上じゃないの？標準コントロールだけ使うだけで済むけどWebはそうは行かないでしょ
ロジックとUIの分離ができないから

2025/01/19(日) 16:10:35.09

『ロジックとUIの分離ができないから』(･ω･#)？

2025/01/19(日) 16:35:13.96

たぶんVMとVの分離のことを言っているのだろうけど、それが再利用性にどう寄与すると思っているのかは謎だね
現実には再利用を前提にするならVMがセットになったコントロールなんてありえないんで、SpinnerのようなケースではWPFでもコントロール自体に局所的な状態をカプセル化してしまうのが普通だね

2025/01/19(日) 17:00:49.29

WPFは参照元が増えるときっつい
ListViewでMVVM使ってると

listviewのVM
listviewitemのVM (ItemsSourceのItem)l
listviewitemのコンテキストメニューのVM
等が合ってそれらの条件に基づいたStyleとかも適用されてどこがどこだか判りにくい場合がある

ユーザーコントロールなんかにすると外に公開するプロパティも組み合わさってめんどくさくなる

2025/01/19(日) 18:29:14.30

>>496
再利用性よりもロジックを分離することで保守性とテスタビリティと高まると言ってる
さらに生成AIとの相性も良いと言っている
俺再利用性なんて言ったか？文盲乙
ReactはViewに全てのロジックをごった煮で詰め込むから少し規模が大きくなるとまともにメンテできなくなる
JSXで三項演算子やらを乱用し、React hooksとか言うゴミで状態管理もViewと密結合になってまともにメンテできない

Reactで単体テストやろうとすると実質ブラウザテストのようなものになってしまうから意味ないんだよね

2025/01/19(日) 18:34:17.70

『ReactはViewに全てのロジックをごった煮で詰め込むから』(･ω･#)？

2025/01/19(日) 18:37:56.04

DataContextは親のを参照するからListViewItemのためにVMは要らない。
具体的には<Image Source="{Binding DataContext.UserIcon, RelativeSource={RelativeSource AncestorType=ListView}}" />という書き方をする。
詳しいことはgithub copilotがサンプルまで示して教えてくれるだろう。

2025/01/19(日) 18:48:26.94

よく読んでからレスしないとエアアドバイスになってるぞ

2025/01/19(日) 18:59:40.08

よくある例としては懐かしのダウンローダーみたいなのがあって
ダウンロード一覧で右クリックから停止させたりタスク削除したりで各モデルなどの状態に応じてメニュー表示を切り替えたりとかするの非常に判りにくい

Ancestorで辿れないvisualツリーとかめんどくさい

2025/01/19(日) 21:02:49.77

ListViewItemViewModelが作られるのは単に可視化要件に応じた変換を入れたいだけのことが多いけど、
やりたいことに対して必要なコード量増加や可読性悪化のコストが大きすぎる嫌いがあるよね
一方Reactの場合は極めてstraightforwardだけど、まあ残念な人の言うとおりtestabilityの問題はあるね
直接モデルからJSXに出力しないでViewBag的なものを間に挟むようにすりゃいいだけの話だけどな

2025/01/19(日) 21:26:11.98

ちなみに文盲とは文字自体読めない人のことなのでこの件は文盲とは違う

2025/01/19(日) 22:35:23.82

>>497
d:DataContext設定すれば補完も出るしrelativesource使っても補完出るし別にわかりづらいと思ったことないけど
Reactの配列.mapsも別にわかりやすいと思えんけど

なんかVMとModelを混同してない？なんで全てViewModelなの？

2025/01/20(月) 00:08:29.91

誰かが主張しているAIコピペで済まない例だからだよ