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/09(水) 15:26:49.23

各コントロールのスタイル書くしか無いんじゃないのかな
何でもかんでもWindowから引っ張ってきてるわけないと思うし
textblockみたいなのは影響が広範囲に及ぶが

**デフォルトの名無しさん** · 2022/11/09(水) 15:28:34.87

WindowのHorisontalAlighmentにCenterなんか入れても何もならんだろ

**sage** · 2022/11/09(水) 17:09:37.46

プロパティのFrameworkPropertyMetadataでInheritsが指定されてるかどうかで挙動が違う
フォント関係のは指定されてるから親コントロールの値を継承する
指定されてないプロパティは継承しないから個別に指定する
どのプロパティでInheritsが指定されてて、どれが指定されてないかはドキュメントには書いていない(なぜ?)
経験的に覚えるか、リファレンスソースを見るしかない

**デフォルトの名無しさん** · 2022/11/09(水) 17:26:32.44

みなさんありがとうございます。理解しました。

**デフォルトの名無しさん** · 2022/11/09(水) 17:35:26.54

ModernWPFの作者動き出したのか

**デフォルトの名無しさん** · 2022/11/09(水) 20:47:51.10

>>145
Windowのスタイルは定義にキー名つけてあげて、適用する側もキー指定してみて

**デフォルトの名無しさん** · 2022/11/09(水) 21:00:18.11

うまく動かない時はXAML側の問題なのかソースリスト側の問題なのか
それすらわからんから余計解決までに時間かかる。
どちらにも問題がある場合もあるし。
禄でもない設計だよな。

**デフォルトの名無しさん** · 2022/11/09(水) 22:19:32.72

>>151
こういうことですかね？これをやってもやらなくても挙動は変わりませんでした

MainWindow.xaml
<Window Style="{StaticResource WindowStyle}"
・・・

App.xaml
<Application.Resources>
<ResourceDictionary>
<Style x:Key="WindowStyle" TargetType="Window">
・・・

**デフォルトの名無しさん** · 2022/11/09(水) 23:14:57.13

https://devblogs.microsoft.com/dotnet/winforms-enhancements-in-dotnet-7/
WPFの見捨てられっぷり

**デフォルトの名無しさん** · 2022/11/09(水) 23:53:08.17

>>151
すみません。デザイナー上は変わらなかったのですが、動かしてみたら結果変わりました。キー指定しないと効かないですね

**デフォルトの名無しさん** · 2022/11/10(木) 02:53:43.49

>>154
出てきて10年以上経つのにな。
衰退するのは間違いないらしい。

**.NET MAUI HighSchool** · 2022/11/10(木) 06:17:51.76

WinUI3に移行したいんでしょきっと
WinFormおじいちゃんのための受け皿は残してるってだけで

**.NET MAUI HighSchool** · 2022/11/10(木) 06:25:29.77

Office365(これからMicrosoft365になるんだっけ？)はWinUIを彷彿とさせるUIになって来たな
単純にWindows11で動いてるだけでそう見えるだけなのかもしれんけど
まぁUIをWinUIで書いて機能面は元々のC++ってのもやろうと思えばできると思うからそうやってるのかもしれん

**デフォルトの名無しさん** · 2022/11/10(木) 16:43:51.22

WinUIはWindows 10でもmicaだなウィンドウの隅が丸くないだけで

**.NET MAUI HighSchool** · 2022/11/10(木) 18:31:35.13

へーこれマイカっていうんだ知らんかった
おしゃれだよな

**.NET MAUI HighSchool** · 2022/11/10(木) 18:33:35.32

まだ色々バグとかコンポーネントが無いとか色々あるかもだがWinUI3めっちゃおしゃれだからこれ使えるならこれ使いたいよな

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

コンポーネント作るのってそんなに時間かかるものなのかね？

**.NET MAUI HighSchool** · 2022/11/10(木) 19:07:13.91

>>162
ドッキングウィンドウとかむずそう

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

>>163
そんなのMSのエンジニアたくさんいるんだからさっさと作ればいいのに

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

今時ドッキングウィンドウなんか流行らないでしょ
そんなものが必要になるような高度なUIを必要とするアプリなら、
どうせドッキングウィンドウに対する要件も高度に特殊化されてるから標準で用意する意味はない

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

な事はない。要るだろ。
因みに俺が良く使ってるのはこれ↓
https://github.com/react-grid-layout/react-grid-layout

**.NET MAUI HighSchool** · 2022/11/10(木) 21:28:41.67

>>164
だよなぁ

**.NET MAUI HighSchool** · 2022/11/10(木) 21:29:41.07

>>166
Reactかよ…

**デフォルトの名無しさん** · 2022/11/10(木) 21:32:58.24

>>154
WindowsフォームでもMVVMパターンについて言及されてるw
MVVMが怖くてWPFから逃げてた4流PGｶﾜｲｿw

**デフォルトの名無しさん** · 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じゃね？