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

**デフォルトの名無しさん** · 2022/04/11(月) 05:10:34.19

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

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

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

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

**デフォルトの名無しさん** · 2022/10/25(火) 22:37:19.01

>>885
VMが出てきたせいで、コードビハインドは悪、画面に関わるコードはすべてVMに書くべきってイメージが出来ちゃったのがなぁ

**デフォルトの名無しさん** · 2022/10/25(火) 22:39:03.01

それ狂信者が勝手に言ってるだけだぞ
マイクロソフトはむしろコードビハインドを推奨してる

**デフォルトの名無しさん** · 2022/10/25(火) 23:21:20.95

>>887
まじ？
聞いた事ないけど

**デフォルトの名無しさん** · 2022/10/26(水) 05:51:47.91

>>883
しかも業務アプリって見栄えはあまり
重視せず、使い勝手や速度が優先されるからな。
ボタンが回転したりそんなのどうでもいいわ。

今まで通り非MVVM?のイベントドリブンだとボタンを
押したときの挙動はそのイベントハンドラ(だけ)に記載
されるているのは間違いない訳でソースも追いやすいし、修正、
機能追加もし易い。

自分は知識としてMVVM? 学習してるけど使うことはなさそうだなぁ。

**デフォルトの名無しさん** · 2022/10/26(水) 14:31:05.80

極論かもしれないが、MV*って結局ユニットテストを作成するかどうかだと思っている。

ユニットテストが要らないような規模のプロジェクトなら好きにすればいいのではないかと。

**デフォルトの名無しさん** · 2022/10/26(水) 14:44:53.94

規模といっても色々あるからね
大抵の業務アプリでは全体としてどれほど大規模で複雑なシステムでもただ画面数が多いだけで個々の画面に対する要件はシンプルなので、
UIに関するロジックのユニットテストは手動ポチポチテストと一緒にやっちゃう、でも問題なくスケールする

**デフォルトの名無しさん** · 2022/10/26(水) 15:16:34.54

Excelのあの膨大なコマンド全部手動テストすんの？

**デフォルトの名無しさん** · 2022/10/26(水) 15:27:00.02

MVVMじゃないとテストコード書けないと思ってる○○www

**デフォルトの名無しさん** · 2022/10/26(水) 15:29:46.56

書けるけどさあ
結合テストだけって結局バグ取り切れないから意味ないんだよね

**デフォルトの名無しさん** · 2022/10/26(水) 15:37:15.22

テストコード書くためにMVVM選択するつうのは余りにもセンスがない

**デフォルトの名無しさん** · 2022/10/26(水) 15:47:49.54

知らんのか？
今の開発はテスト最優先だぞ
しつこくXAML推しして他の言語disってたやつがBlazor知ったらすぐそれかい

**デフォルトの名無しさん** · 2022/10/26(水) 16:08:44.17

手動テストするって言っておきながら
テストコード書くと言われても突然前提ひっくり返すなよ

**デフォルトの名無しさん** · 2022/10/26(水) 16:08:54.14

MVVMだと昔自分が書いたコード見てもシンプルで理解しやすいな

**デフォルトの名無しさん** · 2022/10/26(水) 16:51:05.25

>>897
もしかしてロジック全部VMに書いてるの？だとしたらその方が問題だろう
普通はビュー(MVVMならVVM)とモデルの分離は大前提で、少なくともモデルはテスト書くでしょ
その上でビューのロジックの単体テストまで自動でやるかどうかというだけの話なわけだけど、なんか根本的なところを勘違いしてないかな

**デフォルトの名無しさん** · 2022/10/26(水) 16:56:01.50

VMをテストすればVのテストは要らんわけだがこれを分離しないならVでバグる可能性もあって面倒だぞ
MAUIとかスマホでテストすんのか

**デフォルトの名無しさん** · 2022/10/26(水) 17:03:18.84

いやMVVM使おうが画面と繋いで最終的な手動テストはさすがにやるだろう。
モデルの単体テスト、UIの手動テスト、そしてそれに加えてVMの単体テストを仮にやるなら、VMの単体テストで確認すべきは当然VM固有のロジックのみだ。
まあVMのロジックに対する網羅的なテストをUI経由で毎回やらなくていいから継続的な開発の効率化には寄与するだろう。
ただ、まともな組み方をしてれば一般的にはVMのロジックはかなり少ないはずで、そこまで大きな差にはならない。まともな組み方をしてればね。

**デフォルトの名無しさん** · 2022/10/26(水) 17:07:13.67

>>901
スレの流れ読めよ...

**デフォルトの名無しさん** · 2022/10/26(水) 17:16:08.73

だろおじさん登場

**デフォルトの名無しさん** · 2022/10/26(水) 19:10:37.06

うちの会社はテストコードなんて書かないぞ

**デフォルトの名無しさん** · 2022/10/26(水) 19:39:25.80

ロジックっつーか、どのコマンドを発したらどのプロパティがどう変わるかくらい単体テストでできるだろ
これ手作業でやんのかよw

**デフォルトの名無しさん** · 2022/10/26(水) 19:44:42.44

テスターに任せればいいだろテストなんて

**デフォルトの名無しさん** · 2022/10/26(水) 19:51:49.32

人件費使うんかい

**デフォルトの名無しさん** · 2022/10/26(水) 20:10:49.17

なんかエラーでたけど報告面倒やしOKにしとこ。

**デフォルトの名無しさん** · 2022/10/26(水) 20:12:09.59

テスト終わりました。特に問題ありませんでした。

**デフォルトの名無しさん** · 2022/10/26(水) 20:15:01.87

テスト結果を口頭報告する世界

**デフォルトの名無しさん** · 2022/10/26(水) 20:16:09.97

>>886
あくまでイメージなだけで初心者がそれを信じてしまってるのがなぁ

**デフォルトの名無しさん** · 2022/10/26(水) 20:21:04.01

開発工数が削られると最後のテスト工数を削るしかなくなるんだよな
全体で見積もりだしても要件定義でダラダラするから工数足りなくなることなんてザラだし

**デフォルトの名無しさん** · 2022/10/26(水) 20:30:31.44

「ちょっと変だったけど納品までには何とかなるだろ。」

**デフォルトの名無しさん** · 2022/10/26(水) 20:48:16.75

とりあえずシステム起動できるかどうかだけは納品前に確認しておいてくれ

**デフォルトの名無しさん** · 2022/10/27(木) 06:58:10.64

>>912
コーディング段階で異常系を端折る
取り敢えず正常系が動けばOK

**デフォルトの名無しさん** · 2022/10/27(木) 10:00:20.54

>>911
初心者というか田舎者

**デフォルトの名無しさん** · 2022/10/27(木) 10:27:57.17

ListView等のItemTemplateにボタンなどを置いたとき
コードビハインドにイベントハンドラ置くのが一番楽だからな
頑張ってVMに置いても良いことなど一つもない

**デフォルトの名無しさん** · 2022/10/27(木) 10:38:07.76

ビハインドと共存できないMVVM原理主義者がいるのも事実。
一緒に仕事をした時はびっくりした思い出。

**デフォルトの名無しさん** · 2022/10/27(木) 11:58:20.03

>>917
んなこたない
一つのコマンドを共有してバインドしても手間は変わらん

**デフォルトの名無しさん** · 2022/10/27(木) 12:14:41.44

グラフコントロールとか実装しだすと
データバインデングとか糞過ぎるからな

**デフォルトの名無しさん** · 2022/10/27(木) 14:24:40.22

1つのコマンドを複数のコントロールに割り当てるってほとんどなくないか？
ゲームのUIくらいじゃない？

**デフォルトの名無しさん** · 2022/10/27(木) 14:36:21.65

>>921
ListViewって書いてんじゃん

**デフォルトの名無しさん** · 2022/10/27(木) 18:31:17.41

DataGridでわけわからなくなり、ListViewに。
ソースコピペしまくって一応動作したけど訳わからんわ。

**デフォルトの名無しさん** · 2022/10/27(木) 18:31:17.41

DataGridでわけわからなくなり、ListViewに。
ソースコピペしまくって一応動作したけど訳わからんわ。

**デフォルトの名無しさん** · 2022/10/27(木) 18:39:17.75

複雑なコントロール操作が必要なとき
MVVMとか持ちだすとコードが滅茶苦茶になりがち

良く発生するのが、
バインデングの実行順序

**デフォルトの名無しさん** · 2022/10/27(木) 18:43:12.60

さすがにそれは設計が悪すぎる

**デフォルトの名無しさん** · 2022/10/27(木) 19:45:45.68

コードビハインドだと
複数のプロパティに意図した順番で値を設定できるが、
さてバインデングではどうなるか？
考えた事すらないんではないか？

昔（なんせ10年以上も前）に調べて
ネット上の資料を見つけた事があるが
もう忘れてしまったね

**デフォルトの名無しさん** · 2022/10/27(木) 19:50:35.80

まずそんなことする必要がない
イニシャライズ以外でプロパティの設定順序によって動作が変わるような設計が悪い
それでも糞設計でどうしても順序が大事ならワンウェイバインディングにしてコマンドから設定すべき

**デフォルトの名無しさん** · 2022/10/27(木) 20:16:29.17

>>928
あるコントロールの
プロパティA
プロパティB
プロパティC
にデータバインデングした
さて値が設定される順序はどう判断すればよい？

**デフォルトの名無しさん** · 2022/10/27(木) 20:23:58.70

>>929
だから、そんな順番でロジックが変わるのがクソって話をしてんだがw
それでどうしても順番が大事ならコマンド使って順番に入れたらいいぞ
二回同じこと言ったけど読めるか？w

**デフォルトの名無しさん** · 2022/10/27(木) 20:42:08.19

プロパティABCが相互作用するのをイメージしてるんだろうけど
それをUI層で解決しようとするのが間違い

**デフォルトの名無しさん** · 2022/10/27(木) 20:49:21.84

MVVMは単純なレベルで破綻するという事だ
本件意外にもモデルがダイアログと対話するだけでも大騒ぎになるのよ
結局MSのホワイトペーパー漁るはめになって苦しい言い訳しなきゃならん事になる

**デフォルトの名無しさん** · 2022/10/27(木) 20:50:39.55

頭悪すぎて草しか生えんw

**デフォルトの名無しさん** · 2022/10/28(金) 00:10:18.66

そんな順番に依存していたら、プログラミングなど出来ない

永遠にバグり続ける

**デフォルトの名無しさん** · 2022/10/28(金) 00:13:33.88

馬鹿だらけ？

**デフォルトの名無しさん** · 2022/10/28(金) 06:24:13.52

UIでの順序って、バリデーション時のチラ表示かな？
ビハインドでのカキコはレスポンスが大事な時と、フォーカス移動やDataGridやGridViewでの範囲選択処理ぐらいしか思いつかないが、他に何かある？
まぁ　なんでもかんでもビハインドに書くのあれだし、DialogやMAUIのPopupやカスタムコントロールでもViewModelを作るMVVM教もなんかなぁーとは思う。

**デフォルトの名無しさん** · 2022/10/28(金) 07:14:58.92

勉強としてWINFORMのアプリ(CSV->DataGrid)をWPFに作り替えてるけど
面倒くささ300%増し。
表示するだけなら兎も角、特定のデータがあるカラムの文字色を変えるところで
難儀中。
サイトみたらもっとも難しいコントロールで、難しさから諦める人も多い　とある。
諦めていいのか??

**デフォルトの名無しさん** · 2022/10/28(金) 07:52:49.62

必要ないなら諦めていいやろ

**デフォルトの名無しさん** · 2022/10/28(金) 07:57:37.89

>>937
何が難しいんだ
ItemsTemplateとValueConverter作るだけだろ

**デフォルトの名無しさん** · 2022/10/28(金) 09:28:32.67

>>919
ItemTemplate内のイベントはコードビハインド使わずに処理すると可也めんどいだろ

**デフォルトの名無しさん** · 2022/10/28(金) 09:32:40.89

結論はWindows SDK Appに移行すれば解決だな
イベントバインディングでVMにコードビハインドと変わらない理屈でコードが書けるし
単体テストも問題なく出来る

**デフォルトの名無しさん** · 2022/10/28(金) 09:38:57.28

>>940
XAML数行の何がめんどいんだよ

**デフォルトの名無しさん** · 2022/10/28(金) 09:39:49.13

ああイベントと書いてるな
なぜイベントw

**デフォルトの名無しさん** · 2022/10/28(金) 09:43:12.99

>>941
それだとsenderがobjectじゃん

**デフォルトの名無しさん** · 2022/10/28(金) 09:44:24.09

>>942
ビジュアルステートって数行じゃ終わらないだろ
それとWinUIだとItemTemplateの内部じゃ使えないからイベントハンドラ呼んだほうが早い

**デフォルトの名無しさん** · 2022/10/28(金) 09:53:18.43

>>945
なんでステート使うんだ
コンバーター作ってるんだからそれをBackGroundにバインドして数行で終わるだろ

**デフォルトの名無しさん** · 2022/10/28(金) 10:10:10.03

ここまで読んでわかったけど結局お前らが難しいと言ってるのはMVVMじゃなく単一責任原則と疎結合なんだよ
それはモダンプログラミングの基本だからそれが難しいと言うことは自分にプログラマの素質が無いと自分で言ってるようなもんだぞ

**デフォルトの名無しさん** · 2022/10/28(金) 10:11:38.46

>>946
コードビハインド使わずにイベントを拾うならビジュアルステートだろうに
コンバーターならデータの中身しか使えない

**デフォルトの名無しさん** · 2022/10/28(金) 10:15:18.37

>>948
データによって色を変えるんだからそれで問題ないぞ

**デフォルトの名無しさん** · 2022/10/28(金) 10:18:09.68

>>949
それは別件

**デフォルトの名無しさん** · 2022/10/28(金) 10:24:04.64

突然別件になったな

**デフォルトの名無しさん** · 2022/10/28(金) 10:26:46.35

まぁ　DataGridの部分選択、部分範囲状態をスキャンするめに、ViewModelからViewを参照する人もいるからな。
そこまでして、ViewModelでやる意思は凄い。
当然、SRPなどというクリーンアーキに住んでいない人の方が多い。

**デフォルトの名無しさん** · 2022/10/28(金) 10:29:40.93

>>951
レスを辿れば分かるよ
そっちの話は最初からしていない

**デフォルトの名無しさん** · 2022/10/28(金) 11:54:54.19

レスを辿るとそこに行き着くんだがw

**デフォルトの名無しさん** · 2022/10/28(金) 11:55:27.34

>>952
結局疎結合がわかってないというだけ

**デフォルトの名無しさん** · 2022/10/28(金) 11:56:51.55

DataGrid継承してオレオレDG作ればコードビハインドじゃなくなるからオススメ

**デフォルトの名無しさん** · 2022/10/28(金) 12:34:48.15

次バージョンとかで改良されたりしないの？

**デフォルトの名無しさん** · 2022/10/28(金) 12:40:36.14

どのバージョンでも疎結合を知らないプログラマは厳しいよ

**デフォルトの名無しさん** · 2022/10/28(金) 13:30:28.07

WPFはMS的には既にレガシー扱いで開発終了してるからこの先新機能が入ることはない

**デフォルトの名無しさん** · 2022/10/28(金) 14:04:09.12

かと言ってWinUIやMAUIにはすぐに置き換えられんからなあ
INotifyDataErrorInfoにすら対応してないWinUIの完成度よ

**デフォルトの名無しさん** · 2022/10/28(金) 15:41:37.26

MVVMやりたくない人にこそWinUIなんだよな

**デフォルトの名無しさん** · 2022/10/28(金) 15:52:58.93

WinUIでMVVMできるしまだそれが推奨だぞ
そのうちMVUになるから絶望しろ

**デフォルトの名無しさん** · 2022/10/28(金) 15:58:50.22

VisualStateってのがあるのか

**デフォルトの名無しさん** · 2022/10/28(金) 17:36:35.58

>>956
そこまで気が回る人なら、MVVM真理教でのたうち回っていない。
問題解決能力が全てだという事を肝に銘じていない人に何を言っても聞く耳は持たない。
クリーンアーキはMVVMの基本で、インターフェースで繋ぐ方向が全てだ教えても、10年変わらない奴は、それだけの存在。
DataGridを継承してINotifyChange含むプロパティーを追加するなどという発想がでるわけもない。

**デフォルトの名無しさん** · 2022/10/28(金) 17:56:34.47

>>936
要件が簡単すぎる

設定パネルUIに複数のインジゲータUIをバインド

表示データーはさらに別のスレッドからバインド

監視系だとこんなんザラでしょ

**デフォルトの名無しさん** · 2022/10/28(金) 18:12:41.55

>>965
それのどこが複雑なんだ？

**デフォルトの名無しさん** · 2022/10/28(金) 19:28:10.82

スレ見てると、玄人専用、馬鹿は使うなって感じするわ
こんなじゃ広まるわけないわな

**デフォルトの名無しさん** · 2022/10/28(金) 19:32:50.18

広まってるんだが

**デフォルトの名無しさん** · 2022/10/28(金) 19:33:27.99

OOPの観点から探ると、アプリの作り方はMVVMに向かうようになっている
すべてが部品で、それでもってアプリが構築されているという姿

MVVMを否定するならカプセル化だのなんだのというところまで否定してプログラム書いたほうがいい
そのほうが一貫性がある

**デフォルトの名無しさん** · 2022/10/28(金) 20:05:02.47

>>968
いやいや、そんな事はない。
検索件数でわかる。

**デフォルトの名無しさん** · 2022/10/28(金) 20:16:48.15

>>970
何を検索していくつになったんだ？

**デフォルトの名無しさん** · 2022/10/28(金) 20:18:52.86

前よりはちょっとは広まったぐらいじゃね
ただし、androidやiosのそっち方面のお陰で

**デフォルトの名無しさん** · 2022/10/28(金) 20:24:58.80

つか、jetpack composeとか最新の環境だとDialogやポップアップメニューも
visible変数どっかで持って自分で切り替えるはめになるし結構徹底してる

**デフォルトの名無しさん** · 2022/10/28(金) 21:31:48.03

winformより広まってないよな
ネットで出てくる情報の量が少なすぎるよ
そういうので更に広まらなくなってる気がするわ

**デフォルトの名無しさん** · 2022/10/28(金) 21:35:09.23

>>964
それ、コントロールの継承と言うかカスタムコントロール作るよりビヘイビア作ったほうが楽じゃね？
そういやプロパティーの順番どうのこうのも、ビヘイビア作ればコードビハインドと同じ処理が簡単にできるだろ

**デフォルトの名無しさん** · 2022/10/28(金) 21:42:15.09

>>974
wpf 1311
https://qiita.com/tags/wpf

winforms 100
https://qiita.com/tags/winforms
windowsforms 11
https://qiita.com/tags/windowsforms

圧倒的だが？

**デフォルトの名無しさん** · 2022/10/28(金) 23:10:12.60

behaviorとかできたら触りたくないなあ

**デフォルトの名無しさん** · 2022/10/29(土) 06:19:16.60

>>974
wpf:166,972 questions
https://stackoverflow.com/questions/tagged/wpf
winforms:96,622 questions
https://stackoverflow.com/questions/tagged/winforms

wpf:60,289 repository
https://github.com/search?q=wpf
winforms:17,108 repository
https://github.com/search?q=winforms

wpf:1,311 記事、654 フォロワー
https://qiita.com/tags/wpf
winforms:100 記事、10 フォロワー
https://qiita.com/tags/winforms

wpf:679 repository
https://bitbucket.org/repo/all?name=wpf
windowsform:11 repository
https://bitbucket.org/repo/all?name=windowsform

wpf:62 articles
https://zenn.dev/topics/wpf
winforms:4 articles
https://zenn.dev/topics/winforms

wpf:46 repository
https://gitlab.com/explore/projects/topics/wpf?archived=true&sort=latest_activity_desc
winforms:17 repository
https://gitlab.com/explore/projects/topics/winforms?archived=true&sort=latest_activity_desc

**デフォルトの名無しさん** · 2022/10/29(土) 06:47:12.49

TextBox c# 等で検索すると殆どがwinformsなんだよ。

**デフォルトの名無しさん** · 2022/10/29(土) 07:47:01.24

検索結果の数はともかく検索のしかたにセンスがない
場所はgoogleじゃなくlearn.microsoft.comを使え
検索したいものによって検索する場所を変えるのは基本だ
それからc#じゃなくwinformsやwpfなどのフレームワーク名を使え
一つの言語に同名のコントロールが複数あるのにそれを指定しなくてどうする
自分の欲しい情報がなかなかみつからないのはそういうとこだぞ
検索のしかたが下手でみつからない理由をを情報が少ないからと判断したんだろう

**デフォルトの名無しさん** · 2022/10/29(土) 07:47:11.21

プログラミングでいちばん大事なのって情報量だよね
特に趣味でやってる俺みたいなのにとってはチュートリアルがないときつすぎる
普及させたいならMSはもっとそういうのに金かければいいのに

**デフォルトの名無しさん** · 2022/10/29(土) 07:48:20.21

>>981
チュートリアルあるぞw
検索すればすぐみつかる

**デフォルトの名無しさん** · 2022/10/29(土) 07:52:34.61

WPFの書籍は少なすぎ。ここにいる人書いたらw

**デフォルトの名無しさん** · 2022/10/29(土) 07:57:06.61

WPFの書籍とか需要あるの？
WINUIじゃないの？

**デフォルトの名無しさん** · 2022/10/29(土) 08:02:14.32

これが情報弱者か