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

**デフォルトの名無しさん** · 2022/10/29(土) 11:34:34.12

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

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

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

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

**デフォルトの名無しさん** · 2022/11/10(木) 22:01:06.12

> どうせドッキングウィンドウに対する要件も高度に特殊化されてるから標準で用意する意味はない
要件なんてたいてい一緒だろ
適当な事言いすぎ

**デフォルトの名無しさん** · 2022/11/10(木) 22:23:19.35

AvaloniaUI
https://github.com/wieslawsoltes/Dock
WPF
AvalonDock
まぁ、商用ならたくさんあるが
WinUIは3年前くらいのロードマップにもResearchかなんだかでDockingの言及あったが消えた
まぁ、WinUIもそうだが人的リソースさかないでやる気ないだけ

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

Project Reunionとかつけてたくせにやる気ないのか

**.NET MAUI HighSchool** · 2022/11/10(木) 23:20:44.15

>>171
アヴァロンドックは有名だよな
VisualStudioっぽいUI

**デフォルトの名無しさん** · 2022/11/10(木) 23:51:31.93

>>169
MVVMはWPFのが酷すぎてというのがまともな感性ですな

**デフォルトの名無しさん** · 2022/11/11(金) 07:38:09.36

WinFormsで新しいバインドとかやるのか…WPFも弄れよ…

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

>>166
しゅごい…！

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

https://devblogs.microsoft.com/dotnet/wpf-on-dotnet-7/
一方WPFはコミュニティによる簡単な性能改善とバグ修正のみか
WinFormsがHDPI対応強化とMVVM対応って、もうこのスレでよく言われてたWPFを使う理由が無くなっちゃったな
ボタンを回転させたりするくらいか

**.NET MAUI HighSchool** · 2022/11/11(金) 12:27:03.46

>>176
それReactだよ…

**.NET MAUI HighSchool** · 2022/11/11(金) 12:27:30.55

>>177
デザインも古臭くなっちゃったしな

**デフォルトの名無しさん** · 2022/11/11(金) 12:27:47.44

メタが倒産したらReact死んでしまうん？

**デフォルトの名無しさん** · 2022/11/11(金) 12:49:47.05

>>178
React万歳！！

>>180
そのときはVercelが引き継ぎそう

**デフォルトの名無しさん** · 2022/11/11(金) 13:51:03.30

WinFormsのダークモードの可能性にも言及されてるよな
一方のWPFは..

**デフォルトの名無しさん** · 2022/11/11(金) 14:16:04.72

WASDK 1.2出てた

**デフォルトの名無しさん** · 2022/11/11(金) 18:21:02.46

難解なWPFを制した君たちは新しいプラットフォームになっても
平気平気w

**デフォルトの名無しさん** · 2022/11/11(金) 18:41:31.37

WinAppSDK バグフィックスしてるのか?
クラッシュしないと直してくれない?

**デフォルトの名無しさん** · 2022/11/11(金) 19:41:02.20

GitHubのIssuesのところに書いたらいいんじゃない

**デフォルトの名無しさん** · 2022/11/11(金) 19:41:21.37

>>176
こんなの山ほどありますよ
しかもオープンソースで

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

WinFormsを使い続けた俺大勝利

**デフォルトの名無しさん** · 2022/11/11(金) 21:12:50.96

>>188
www　良かったな!。
やっぱりwpfに比べると簡単だもんな。
WINFORMS。
どっちも使ってるけどWINの方が楽だわ。

**デフォルトの名無しさん** · 2022/11/11(金) 21:15:09.63

>>177
WPFにしても高DPI対応にするには
それなりに考えないといけないと聞いたが
ホント?
それともテキトーに作っても高DPIに対応されるんか?

**デフォルトの名無しさん** · 2022/11/11(金) 21:36:21.79

ちょっとしたものならWinFormがお手軽でいいけど規模が大きくなるとxamlの方が差分がわかりやすいよね。

**デフォルトの名無しさん** · 2022/11/11(金) 21:52:43.10

ListBoxにいろいろ突っ込みたいのでWinFormsに戻ることはない

**デフォルトの名無しさん** · 2022/11/12(土) 00:31:14.01

DataTemplateはいいよねえ

**デフォルトの名無しさん** · 2022/11/12(土) 11:16:14.48

>>177
このスレで言えば

- XAMLの編集がフォームエディタ必須のFormsより楽
- UIを含む自動テストがVMを叩くだけでほぼカバーできるので楽

あたりも定番だと思うが。

**デフォルトの名無しさん** · 2022/11/12(土) 12:53:09.65

立ち位置としてはWPFはUWPに席を譲ったということになってるんだよ
ところがUWPがあまりに誰得なのでWinUIでWPFとUWPを統合しようとしてる
WPFはUWPとWinUIの不甲斐なさ故に生きてるだけでMSはできるだけ早くこいつを引退させたいわけ
理論的にはきちんとMVVMで疎結合にできてればWPFからWinUIへの移行は容易いからWPFにあまり力を入れる必要はないんだよ
winformsはそれらとはまたユースケースが違うし一世を風靡して現役の資産が山程ある
しかもRADが売りだからXAMLへの移行はコストが高い
それで見捨てるわけにはいかないんだね

**デフォルトの名無しさん** · 2022/11/12(土) 13:39:57.76

>>194
前者はともかく自動テストについてはMVVM対応したらVMのテストはWPF同様にできるでしょ

**デフォルトの名無しさん** · 2022/11/12(土) 18:05:47.38

>>195
UWPもおわってるけどな

**デフォルトの名無しさん** · 2022/11/12(土) 22:50:48.74

>>177
WPF使う理由ってXAMLでレスポンシブな画面作れることでしょ。
MVVMはあってもなくてもどっちでもいいもの。

**デフォルトの名無しさん** · 2022/11/12(土) 23:21:32.18

>>198
WPFで普通に作られたUIはいわゆる世間一般のレスポンシブデザインには全く該当しないけど、
君のいうレスポンシブってどういうものを指してる？

**デフォルトの名無しさん** · 2022/11/12(土) 23:22:28.30

おっと！

笑

**デフォルトの名無しさん** · 2022/11/13(日) 02:37:28.45

ぶっちゃけ、テスト駆動開発なんてしてるの？

**デフォルトの名無しさん** · 2022/11/13(日) 04:37:56.81

絵に描いた餅だろ

**デフォルトの名無しさん** · 2022/11/13(日) 09:39:55.13

なんで唐突にテスト駆動開発なんて話が？
GUIに対してはなかなか難しいと思うが。

**デフォルトの名無しさん** · 2022/11/13(日) 10:23:16.61

MVVMを採用するメリットはテスト駆動開発だから、それをしないのに採用する意味はあるのかな、と思って

**デフォルトの名無しさん** · 2022/11/13(日) 10:26:27.45

テストしやすいってのとテスト駆動開発はまた違う話だぞ？

**デフォルトの名無しさん** · 2022/11/13(日) 11:18:11.03

react側から見るとしづらい方ですかね

**デフォルトの名無しさん** · 2022/11/13(日) 17:56:04.29

WinUIだが、TemplateStudioが作ってくれる雛形のWindowがサードパーティー製のWinUIExに置き換わった
これでWindowの位置と場所をキープしてくれるし、スプラッシュスクリーンもサポートしているようだ
スプラッシュの方はこれから見てみるわ

**デフォルトの名無しさん** · 2022/11/13(日) 21:04:37.19

reactの場合はビューがDOMを生成する関数だから、ビューについても簡単にテスト書けるんだよね
WPFで複雑なバインディングをやるとビューの手動テストはそれなりに大変になる
WPFでビューの自動テストをやろうとするとUIオートメーション使うことになるから流石に大袈裟すぎて非現実的だよね

**デフォルトの名無しさん** · 2022/11/13(日) 21:18:59.25

>WPFでビューの自動テストをやろうとするとUIオートメーション使うことになるから流石に大袈裟すぎて非現実的だよね

オートメーションが必要なのはUIコンポーネントが内部状態を持ってしまっているFormsまでの話で、
MVVMの場合はプレゼンテーションロジックを全部VM側に持っているからそこのテストで
UIフレームワークを叩く必要がないというのが利点なわけだが。

**デフォルトの名無しさん** · 2022/11/13(日) 21:24:43.10

>>209
Vからロジックを分離してロジックのみを単体テストできるのは当然Reactも同じ
その上でVの単体テストやインテグレーションテストをする場合の話をしてる
あと、Reactの場合は仮にVからロジックを分離しないことを選択したとしても自動テストは比較的容易だ

**デフォルトの名無しさん** · 2022/11/13(日) 21:29:43.31

>>210
ほんとか？
state絡みRedux絡みは結構めんどいぞ

**デフォルトの名無しさん** · 2022/11/13(日) 22:19:25.39

>インテグレーションテストをする場合の話をしてる

Reactの場合でもそれはselenium使ったテストとかやらん？

**デフォルトの名無しさん** · 2022/11/13(日) 22:31:21.25

あと、
「WPFは非現実的」
「そんなことない」
「Reactすごい」←話が繋がってないｗ

**デフォルトの名無しさん** · 2022/11/13(日) 23:07:14.52

>>208
異常に面倒ですからねwpfのは

**デフォルトの名無しさん** · 2022/11/13(日) 23:25:16.64

>>214
だからMVVMを使うのであってな
VMはVを抽象化したものだからVMのテストをすればVのテストはシステムテストまで要らんのよ

**デフォルトの名無しさん** · 2022/11/13(日) 23:34:14.97

なんでVとVMって分かれてるんだろう
ロジックなんてMに書くからVとVMが分かれてる必要性ないと思うんだけど

**デフォルトの名無しさん** · 2022/11/13(日) 23:53:19.25

>>216
Vを抽象化したものがVMと書いただろ？
VMのプロパティに文字列を入れるのはVのテキストボックスに文字列を入れるのと同じことでVMのコマンドを実行することはVのボタンを押すことと同じなんだよ
VMにVの装飾以外の機能を移せばVはViewModelという名のModelになれる
Modelだから簡単なテストで性能を担保できるしコンパイルも早い
いちいちソース書き換えてデバッグ実行してテキストボックスに文字列書き込んでボタン押す作業を繰り返さなくても数行のテストコードで同じことが確かめられるから開発時間が大幅に短縮できる
短縮できないとしたらやり方が間違ってる

**デフォルトの名無しさん** · 2022/11/14(月) 00:05:00.33

本来INotifyPropartyChangedはVMだけに設定して、VMはVから来た命令に従ってMに司令を出して
Mが完了したら自分のPropertyなどを更新してVに通知するからですね
でも、可也面倒だからMにInotfy・・・なプロパティーをMに設置するからVMはVにリレーするだけにしたりしているから
VMの役割が半分を端折ることが多いので無駄に見えてくるね

**デフォルトの名無しさん** · 2022/11/14(月) 00:32:06.18

>>211
reduxなど使う必要性ないですね
単体テストの為に実装が増えることは基本無いのです
wpfのは余りに無駄すぎます

**デフォルトの名無しさん** · 2022/11/14(月) 00:38:25.53

>>217
そのテストコードを書くより画面で入力した方が楽じゃない？
テストコードがちゃんと書けてるかもテストしないといけないし。
どれくらいの回数のテストするかによるかもしれないけど、そういう特殊なケース以外でのメリットがわからない。

**デフォルトの名無しさん** · 2022/11/14(月) 00:42:59.00

あと、Vのコントロールで参照したいプロパティの数だけVMにもプロパティを作ってはバインドするのが辛い
VMでコントロールを参照できれば簡単だけど、それだと理念に反する感じもするし…

**デフォルトの名無しさん** · 2022/11/14(月) 02:19:45.52

まあアホに何言っても無駄だから自分の信じるやり方でゴミを作ればいんじゃね

**デフォルトの名無しさん** · 2022/11/14(月) 05:40:27.75

↑自分がそのアホだと気付いていないアホ

**デフォルトの名無しさん** · 2022/11/14(月) 06:15:26.54

テストが一回きりなら手動の方が早いだろうな

**デフォルトの名無しさん** · 2022/11/14(月) 07:20:40.36

この手のやつは半信半疑ながらも自分で手を動かして実践しないと理解できなかったりする

**デフォルトの名無しさん** · 2022/11/14(月) 07:34:36.07

WPFやWinUI3の標準テンプレートってどれよ？　PrismやCommunityKitなどいろいろあってわかんなーい。
CommunityKitでDependencyInjecttionとHostingをNuGet導入するあたりが標準なのかしら？

**.NET MAUI HighSchool** · 2022/11/14(月) 07:45:50.17

最近はCommunityToolKit何じゃないかぁ？？？

**デフォルトの名無しさん** · 2022/11/14(月) 07:57:38.88

VSにTemplate　Studioという拡張を導入してプロジェクトの雛形を作る
https://marketplace.visualstudio.com/items?itemName=TemplateStudio.TemplateStudioForWinUICs

基本はCommunityToolkitだが、不足しているものをコード自動生成してくれるし最小限のNugetも導入してくれる

**デフォルトの名無しさん** · 2022/11/14(月) 11:51:13.81

>>216
MVCという言葉を使いたくなかっただけ

**デフォルトの名無しさん** · 2022/11/14(月) 13:31:55.51

>>224
全部作り終わってから一回だけテストすることが許されてる環境とか嫌すぎる

**デフォルトの名無しさん** · 2022/11/14(月) 13:34:53.19

>>221
動作に必要なプロパティがそんなたくさんあるとかおかしいんじゃね

**デフォルトの名無しさん** · 2022/11/14(月) 13:34:59.86

あるボタンが押されたら他のあるボタンが押せなくなるみたいな簡単なロジックのやつは、xamlでコントロール同士をバインディングしているのですが、これはそうせずにCSでプロパティ変更のコードを書いた方がいいのでしょうか

**デフォルトの名無しさん** · 2022/11/14(月) 13:43:21.84

>>232
あるボタンにVMのコマンドをバインドする
VMはそのコマンドが実行されると自身のIsOtherButtonEnabledプロパティ(このプロパティは自分で作る)をtrueにする
他のボタンのIsEnabledプロパティを全てこのIsOtherButtonEnabledプロパティにバインドする
これであるボタンが押されると他のボタンが押せなくなる

**デフォルトの名無しさん** · 2022/11/14(月) 13:44:15.94

>>233
✕true
○false

**デフォルトの名無しさん** · 2022/11/14(月) 22:04:24.32

>>216
>ロジックなんてMに書くから

こういう勘違い昔から多いよな。

**.NET MAUI HighSchool** · 2022/11/14(月) 22:06:34.12

ロジックはVMに書く
たしかに最初は間違って覚えちゃうよな
俺もそうだった
モデルは情報を持つだけ

**デフォルトの名無しさん** · 2022/11/14(月) 22:10:06.97

勘違いではないでしょ
もしかしてVMで直接リポジトリを触ったりしちゃってる？

**.NET MAUI HighSchool** · 2022/11/14(月) 22:11:49.45

そういえば今日
BindingContext=this;でそのページ上、画面上にあるプロパティ全てBindingできるコンテンツとして扱えるということを勉強したこれよいね

**.NET MAUI HighSchool** · 2022/11/14(月) 22:14:11.99

>>237
してるね
.xaml.cs←VMファイルに分けなければ実質的なVMにパス書いてるわ
ただオブジェクトのモデル(プロパティ郡)はちゃんとモデルでわけてる

**デフォルトの名無しさん** · 2022/11/14(月) 22:40:55.53

MV*系のアーキテクチャでいうMはビューの上位に存在するもの全般を指しているのだけど、
モデルという言葉のせいでデータモデルとかドメインモデルなんかと混同しやすいんだよね
本来的にはそれらを弄くり回すのは「サービス」層の仕事で、VMの仕事はサービスに処理を投げて結果を反映するだけだ

**.NET MAUI HighSchool** · 2022/11/14(月) 23:07:12.03

>>240
なるほどMVVMSみたいな感じなわけですな
たしかにサービスクラスよく作りますわ
MVCだとMVCSみたいな

**デフォルトの名無しさん** · 2022/11/14(月) 23:15:51.49

>>236
ロジックはMVCどこにでも書くだろう。ビジネスロジックだけがロジックってわけじゃない。

**デフォルトの名無しさん** · 2022/11/14(月) 23:16:37.69

まちがえた。>>242は>>237な。

**デフォルトの名無しさん** · 2022/11/15(火) 07:30:18.11

MVVMでDDD するとしたらどこにアプリケーション層やらドメイン層を置くの

**デフォルトの名無しさん** · 2022/11/15(火) 08:17:54.90

どっちっもMじゃね？

**デフォルトの名無しさん** · 2022/11/15(火) 14:19:21.05

>>233
ありがとうございます。そのように変更してみます

**デフォルトの名無しさん** · 2022/11/15(火) 18:50:53.84

WinUI 3 Galleryが更新されてた

**デフォルトの名無しさん** · 2022/11/15(火) 18:55:38.96

メディアプレイヤーエレメント来てるねぇ
そういえばMAUIでも使えるようになるんだ(まだプレビュー)

**デフォルトの名無しさん** · 2022/11/15(火) 18:59:44.05

全体的にUpdateされたみたいね

**デフォルトの名無しさん** · 2022/11/15(火) 19:04:44.40

Windows10だからシステムバックドロップスのMicaやAcrylicがわからん…

**デフォルトの名無しさん** · 2022/11/15(火) 22:06:07.59

MVVM使うような巨大アプリは扱わんだろうなぁ。

**デフォルトの名無しさん** · 2022/11/15(火) 22:50:08.95

メディアプレーヤーちょっと触ってみたけど
ビデオ画面のフルスクリーンが出来ないのが残念だったわ
プロパティーあるからそのうち実装されるんだろうが

**デフォルトの名無しさん** · 2022/11/15(火) 23:30:39.77

そういえばこれと同じようなソフトでCommunityToolkitSampleAppもあるけどみんな使ってる？
色々コントロールあってWinUIでも色々できるんだなぁってなった

**デフォルトの名無しさん** · 2022/11/15(火) 23:33:13.02

これ
https://www.microsoft.com/store/productId/9NBLGGH4TLCQ

**デフォルトの名無しさん** · 2022/11/16(水) 02:12:36.05

そういえばこういうToolkit Sample AppみたいにXAML変えたら勝手にViewも変わるようにするにはどうすればいいんだろうか？
.NET MAUIとかで同じようなアプリ作りたい

**デフォルトの名無しさん** · 2022/11/16(水) 16:06:10.44

VSのWindowsAppSDKでページやユーザーコントロールの新規ファイルを作るとSJISコードで作っちまうようだ
Xamlで文字化けが起こった時はサクラエディタなどでUTF8　BOM付きに変換すれば治る

**デフォルトの名無しさん** · 2022/11/17(木) 06:38:43.37

>>254
UIがうざいな。
何するにもワンテンポ待たされる。
アニメーションにセンスがない。
操作を分かりやすくするため、操作の邪魔をしないよう最小限にという鉄則が守られていない。

**デフォルトの名無しさん** · 2022/11/17(木) 17:13:44.56

WinUI Template使ったら凄いでちゅね。　Blankでもあれよあれよとフォルダーだらけ。
MSTestまで追加されている。
とりあえず構成として足りないNuGetはMicrosoft.Extensions.DependencyInjectionぐらい。
App1.Coreライブラリブロジェクトは不要なので削除して、App1.DomainライブラリプロジェクトとApp1.Infrastructureライブラリプロジェクトは追加したが、
こんなのに初心者が付いてこれるのかね？

**デフォルトの名無しさん** · 2022/11/17(木) 17:20:59.19

最悪MSやパートナーに相談してくれりゃいいというスタンスなんでしょ
WinUIなんて、どうせ使うのはMSのエンタープライズサポートが付いてる高級客くらいなんだから

**デフォルトの名無しさん** · 2022/11/17(木) 17:48:44.99

>>259
まぁ　もう販促の時代では無いとしているんだろうが、
バリデーションやエレメントEnabledコンディションのUIロジックと単位やファインナンスルール等をドメインに入れるアーキテクチァーロジックとの区別ができない奴がVMにもロジックがあると言っているこのスレ見れば、
もう少し、DellphiなどのRAD時代のようなTemplateを用意しても良いとはオモ。
全体のTemplateをみる限り、八方ふさがりが多い。

**.NET MAUI HighSchool** · 2022/11/17(木) 19:14:41.39

>>258
テンプレートスタジオのじゃなくて既成のやつ？

**デフォルトの名無しさん** · 2022/11/19(土) 02:17:21.47

既存のWPFのプロジェクトでWinUIのコントロールを使うことってできませんか？

**デフォルトの名無しさん** · 2022/11/19(土) 07:41:53.45

xaml islands？
.net core3じゃないと使えないと聞いたけど

**.NET MAUI HighSchool** · 2022/11/19(土) 08:09:34.03

たしかにWPFでWinUI3のコントロール使えたら最強だわなw
普段と何も変わらず見た目だけおしゃれにできる

**デフォルトの名無しさん** · 2022/11/20(日) 14:23:46.53

datagrid内のtextblockのmaxlengthを設定する方法はありますでしょうか。現在は入力されたらcelleditイベントで飛ばしてパンドラ側でtextをバインドしたコレクションの文字数を調べて上限を超えていたら、上限超過文字をカットしてコレクションに入れ直しています。そもそもtextblockで上限文字以上を受け付けない方法に変えたいです。

datadrd内のtextboxをダブルクリックで編集メードにする方法はありますでしょうか。こちらであればmaxlengthを設定できるので、上記のような問題は出ないのですが、ワンクリックで選択したらいきなり編集モードになってしまい、それは避けたいというところです。

どうぞよろしくお願いいたします。

**デフォルトの名無しさん** · 2022/11/20(日) 17:52:21.57

ここに質問しても禄に回答なんてないよ。そんなレベルだから。ま、自分もそうだがw
ヤフー知恵袋などの方が良い。

**デフォルトの名無しさん** · 2022/11/20(日) 21:54:33.51

>>265
DataGridTemplateColumn じゃあかんのか？

**デフォルトの名無しさん** · 2022/11/20(日) 22:05:41.15

これじゃね？
https://stackoverflow.com/questions/1736753/datagridtextcolumn-maxlength

**デフォルトの名無しさん** · 2022/11/21(月) 04:36:19.56

ありがとうございます。スタックフローにある通り、以下の構成でダブルクリック編集ができました。
<DataGridTextColumn
<DataGridTextColumn.EditingElementStyle>
<Style TargetType="TextBox" x:Name="name"

しかし、x:Nameによる操作がcsコード側でコントロールできないのですが、何か方法はありますでしょうか。
(name.MaxLength=50とかがnameが認識できないエラーになる)

質問ばかりですみません。よろしくお願いします。