WPF(.NET, WinUI) GUIプログラミング Part29
レス数が950を超えています。1000を超えると書き込みができなくなります。
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/ データバインディングの勉強目的なら最初は何も使わずにINotifyChangedPropertyぐらい自前実装でいいだろ
10行未満なんだし バィンディングっていろいろ手法があるみたいでその辺も混乱の元ですね! INotifyChangedPropertyの実装に関しては、prismもmicrosoft.toolkitもほぼ同じもの
Xaml側は全く同じだからどのHPを見ても何も問題ないんだけどね
prismで勉強して、些末な違いをMSのドキュメントで補完すればいいんじゃないかな React界隈じゃ
不用なのものを徹底的に排除して突き詰めてるのに、
XAML界隈は
ライブラリー！ライブラリー！ライブラリー！
ドヤ顔ライブラリー房のこの違い... Reactに対応するのはXAMLじゃなくBlazorなので >>856
残念ながらUWPとUnoでしか使えないx:Bindはオワコンだ x:bind最新のWinUI 3で使えないんだっけ? やってみた。
x:BindはWinUI3もMAUIも使えるよ。
安心しな。 UWP作ってないしx:bind使ったこと無かったわ
その使い心地を見せて貰おうかっ >>850
今日入れてみた。試してみる。
いろいろフレームワーク大すぎ。
MSが良いもの出さないからか。
こっちでの開発ではプリズム、
異動先ではReactiveProperty使用とか。
難儀やなぁ。 x:bindはUWPでコンパイル時バインドで速いという触れ込みがあったから使ったみたが速度差体感できずコンパイル時の型チェックもうざいので俺はbindindに戻ったけど コマンドに使用可否だけじゃなくて、表示非表示も持ってほしいよな VisibleとEnabledを自己バインドすればいいだけじゃね ｘ：Bindはイベントがバインド出来てFormsのやり方MVVMででコーディングできるんだっけど
そこらへんをアピールするつもりはないようだね
ビヘイビアが難しいわけじゃないけど冗長だから使わずに済むのも大きいね どういうケースを想定してるのかわからんわ
disabledの時に消せばいいんじゃないのか？ そもそも表示しない
表示するが無効
表示するが有効
この3通りをやりたい時がある get -> そもそも ？ hidden : 表示する ？ visible : hiddem; そんなことしたいと思ったことないからわからんけどコマンドとのバインディングでしなきゃいけないなら継承するしかないな
俺ならViewModelのプロパティを使うが 例えば、ログイン機能があるアプリとかでログインしてなきゃ更新ボタンをそもそも表示しない
で、ログインして更新ボタンを押して更新中になったら一時的に無効に切り替えてとか
たまに、表示/非表示と有効/無効を別に扱いたいときがある 単純にコードビハインドでやれば良くね？ 頭悪いの？ それログインボタン以外の管理用機能が必要になった時どうすんの
管理者フラグをVMに用意して管理者用コントロールパネルごと消すべきだろ
個々のコマンドじゃなく 例えが悪いなら謝るが
別にボタンの他に、メニューにバインドされる可能性だってあるし
俺が昔必要に思った時のケースは思い出せねぇわ そりゃ初心者は理解できんかもな
大きく複雑なプログラムを作る時に威力を発揮するものだから >>879
らしいね。
みんなもそうな大きく複雑なもの作ってるんだ? そもそも世の中に転がってるシステムに疎結合なんて不要な気がするわ
設計に時間かけれる人は自己満足でやってもいいかもしれないけど WPFの主用途はゴリゴリの業務アプリだから、複雑なのはUIではなく業務フローなんだよね
ただ画面数が多いだけだ >>881
UIとロジックは疎結合にしろ、てもう聞き飽きた。
そんなに大事なんかね。 >>885
VMが出てきたせいで、コードビハインドは悪、画面に関わるコードはすべてVMに書くべきってイメージが出来ちゃったのがなぁ それ狂信者が勝手に言ってるだけだぞ
マイクロソフトはむしろコードビハインドを推奨してる >>883
しかも業務アプリって見栄えはあまり
重視せず、使い勝手や速度が優先されるからな。
ボタンが回転したりそんなのどうでもいいわ。
今まで通り非MVVM?のイベントドリブンだとボタンを
押したときの挙動はそのイベントハンドラ(だけ)に記載
されるているのは間違いない訳でソースも追いやすいし、修正、
機能追加もし易い。
自分は知識としてMVVM? 学習してるけど使うことはなさそうだなぁ。 極論かもしれないが、MV*って結局ユニットテストを作成するかどうかだと思っている。
ユニットテストが要らないような規模のプロジェクトなら好きにすればいいのではないかと。 規模といっても色々あるからね
大抵の業務アプリでは全体としてどれほど大規模で複雑なシステムでもただ画面数が多いだけで個々の画面に対する要件はシンプルなので、
UIに関するロジックのユニットテストは手動ポチポチテストと一緒にやっちゃう、でも問題なくスケールする Excelのあの膨大なコマンド全部手動テストすんの？ MVVMじゃないとテストコード書けないと思ってる○○www 書けるけどさあ
結合テストだけって結局バグ取り切れないから意味ないんだよね テストコード書くためにMVVM選択するつうのは余りにもセンスがない 知らんのか？
今の開発はテスト最優先だぞ
しつこくXAML推しして他の言語disってたやつがBlazor知ったらすぐそれかい 手動テストするって言っておきながら
テストコード書くと言われても突然前提ひっくり返すなよ MVVMだと昔自分が書いたコード見てもシンプルで理解しやすいな >>897
もしかしてロジック全部VMに書いてるの？だとしたらその方が問題だろう
普通はビュー(MVVMならVVM)とモデルの分離は大前提で、少なくともモデルはテスト書くでしょ
その上でビューのロジックの単体テストまで自動でやるかどうかというだけの話なわけだけど、なんか根本的なところを勘違いしてないかな VMをテストすればVのテストは要らんわけだがこれを分離しないならVでバグる可能性もあって面倒だぞ
MAUIとかスマホでテストすんのか いやMVVM使おうが画面と繋いで最終的な手動テストはさすがにやるだろう。
モデルの単体テスト、UIの手動テスト、そしてそれに加えてVMの単体テストを仮にやるなら、VMの単体テストで確認すべきは当然VM固有のロジックのみだ。
まあVMのロジックに対する網羅的なテストをUI経由で毎回やらなくていいから継続的な開発の効率化には寄与するだろう。
ただ、まともな組み方をしてれば一般的にはVMのロジックはかなり少ないはずで、そこまで大きな差にはならない。まともな組み方をしてればね。 ロジックっつーか、どのコマンドを発したらどのプロパティがどう変わるかくらい単体テストでできるだろ
これ手作業でやんのかよw >>886
あくまでイメージなだけで初心者がそれを信じてしまってるのがなぁ 開発工数が削られると最後のテスト工数を削るしかなくなるんだよな
全体で見積もりだしても要件定義でダラダラするから工数足りなくなることなんてザラだし 「ちょっと変だったけど納品までには何とかなるだろ。」 とりあえずシステム起動できるかどうかだけは納品前に確認しておいてくれ >>912
コーディング段階で異常系を端折る
取り敢えず正常系が動けばOK ListView等のItemTemplateにボタンなどを置いたとき
コードビハインドにイベントハンドラ置くのが一番楽だからな
頑張ってVMに置いても良いことなど一つもない ビハインドと共存できないMVVM原理主義者がいるのも事実。
一緒に仕事をした時はびっくりした思い出。 >>917
んなこたない
一つのコマンドを共有してバインドしても手間は変わらん グラフコントロールとか実装しだすと
データバインデングとか糞過ぎるからな 1つのコマンドを複数のコントロールに割り当てるってほとんどなくないか？
ゲームのUIくらいじゃない？ DataGridでわけわからなくなり、ListViewに。
ソースコピペしまくって一応動作したけど訳わからんわ。 DataGridでわけわからなくなり、ListViewに。
ソースコピペしまくって一応動作したけど訳わからんわ。 複雑なコントロール操作が必要なとき
MVVMとか持ちだすとコードが滅茶苦茶になりがち
良く発生するのが、
バインデングの実行順序 コードビハインドだと
複数のプロパティに意図した順番で値を設定できるが、
さてバインデングではどうなるか？
考えた事すらないんではないか？
昔（なんせ10年以上も前）に調べて
ネット上の資料を見つけた事があるが
もう忘れてしまったね まずそんなことする必要がない
イニシャライズ以外でプロパティの設定順序によって動作が変わるような設計が悪い
それでも糞設計でどうしても順序が大事ならワンウェイバインディングにしてコマンドから設定すべき >>928
あるコントロールの
プロパティA
プロパティB
プロパティC
にデータバインデングした
さて値が設定される順序はどう判断すればよい？ >>929
だから、そんな順番でロジックが変わるのがクソって話をしてんだがw
それでどうしても順番が大事ならコマンド使って順番に入れたらいいぞ
二回同じこと言ったけど読めるか？w プロパティABCが相互作用するのをイメージしてるんだろうけど
それをUI層で解決しようとするのが間違い MVVMは単純なレベルで破綻するという事だ
本件意外にもモデルがダイアログと対話するだけでも大騒ぎになるのよ
結局MSのホワイトペーパー漁るはめになって苦しい言い訳しなきゃならん事になる そんな順番に依存していたら、プログラミングなど出来ない
永遠にバグり続ける UIでの順序って、バリデーション時のチラ表示かな？
ビハインドでのカキコはレスポンスが大事な時と、フォーカス移動やDataGridやGridViewでの範囲選択処理ぐらいしか思いつかないが、他に何かある？
まぁ なんでもかんでもビハインドに書くのあれだし、DialogやMAUIのPopupやカスタムコントロールでもViewModelを作るMVVM教もなんかなぁーとは思う。 勉強としてWINFORMのアプリ(CSV->DataGrid)をWPFに作り替えてるけど
面倒くささ300%増し。
表示するだけなら兎も角、特定のデータがあるカラムの文字色を変えるところで
難儀中。
サイトみたらもっとも難しいコントロールで、難しさから諦める人も多い とある。
諦めていいのか?? >>937
何が難しいんだ
ItemsTemplateとValueConverter作るだけだろ >>919
ItemTemplate内のイベントはコードビハインド使わずに処理すると可也めんどいだろ 結論はWindows SDK Appに移行すれば解決だな
イベントバインディングでVMにコードビハインドと変わらない理屈でコードが書けるし
単体テストも問題なく出来る >>941
それだとsenderがobjectじゃん >>942
ビジュアルステートって数行じゃ終わらないだろ
それとWinUIだとItemTemplateの内部じゃ使えないからイベントハンドラ呼んだほうが早い >>945
なんでステート使うんだ
コンバーター作ってるんだからそれをBackGroundにバインドして数行で終わるだろ ここまで読んでわかったけど結局お前らが難しいと言ってるのはMVVMじゃなく単一責任原則と疎結合なんだよ
それはモダンプログラミングの基本だからそれが難しいと言うことは自分にプログラマの素質が無いと自分で言ってるようなもんだぞ >>946
コードビハインド使わずにイベントを拾うならビジュアルステートだろうに
コンバーターならデータの中身しか使えない >>948
データによって色を変えるんだからそれで問題ないぞ レス数が950を超えています。1000を超えると書き込みができなくなります。
