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/04(金) 20:19:58.46

誰に聞いたんだか知らんがまあ自分で作ればできるっちゃできる
そもそも違うものなのになぜ同じだと思ったんだろ

**デフォルトの名無しさん** · 2022/11/05(土) 08:10:09.51

Winformsの後発なんだから今まであった便利なものは継承するのが普通。

**デフォルトの名無しさん** · 2022/11/05(土) 08:35:10.98

便利ではないからな
UI Automationというもっと便利なものが使えるからそれを使え

**デフォルトの名無しさん** · 2022/11/05(土) 14:13:04.79

>>119
あるよ
違うフレームワークなんだからそれぞれのやり方を覚えような

**デフォルトの名無しさん** · 2022/11/05(土) 14:23:18.30

そもそもViewとロジックが疎結合だから、SendKeysみたいな姑息なことをやる必要がないだろ
設計を見直すいい機会だから頑張れというほかない

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

viewとviewModelを素結合にようという
発想そのものが諸悪の根元

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

業務アプリってのは姑息なやり方も必要なんだな。

**デフォルトの名無しさん** · 2022/11/05(土) 19:00:07.74

仕様がレガシーだとそういうこともあるけど、
そんなもん蹴って作り直した方が色々捗るぞ

**デフォルトの名無しさん** · 2022/11/05(土) 20:06:45.45

それが簡単に出来るならみんなそうしてるわけで...
作った人がいるならまだしももう退職しました～なんてコードを調べて手直しなんてやる工数も期間もないのがほとんどだし

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

それでもWinFormsからWPFに乗り換えるタイミングなら少しは手間かけてもいいんじゃないかな？
COBOL時代のロジックが残っていたりすると殺意を覚える

**デフォルトの名無しさん** · 2022/11/05(土) 22:39:53.01

ユーザー子会社にいた事あったけど、基本的にみんな勉強とかしないから指示されたコードしか書けなかったな
下手に最新のフレームワークとかデザインパターン導入したら理解できなくて適当に書かれて終わる

**デフォルトの名無しさん** · 2022/11/05(土) 22:46:11.02

勝手に導入したらそらそうなるわ
導入する前にみんなで勉強会するんだぞ

**デフォルトの名無しさん** · 2022/11/05(土) 23:07:41.83

その会社には勉強会という文化はなかったな
ちょっと気になったけど、勉強会って業務時間中にやるの？

**デフォルトの名無しさん** · 2022/11/05(土) 23:17:26.78

>>130
そりゃ業務のための勉強だから業務の一部だよ

**デフォルトの名無しさん** · 2022/11/05(土) 23:51:37.49

勉強会とそのための準備の時間って貰えるもんなんだな
みんないい会社に勤めてそうだわ

**デフォルトの名無しさん** · 2022/11/06(日) 06:55:15.36

>>130
いや、定時過ぎてからだぞ。
残業代はつかない。
参加したかどうかは把握されてるから評価の判断材料にはされる。

**デフォルトの名無しさん** · 2022/11/06(日) 09:20:15.40

勝手に開催するやつは文化に組み込まれてないと難しいとは思うけど、
そうじゃなくてもフレームワーク変更にメリットがあって、ちょっと勉強が必要というなら、
説明資料つくれば業務時間内にやる許可取れると思うで。

**デフォルトの名無しさん** · 2022/11/06(日) 21:59:47.93

>>133
ブラック臭いけど、以外と一部上場とかでそういうセコいところあるよな

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

サービス残業ってことになると本当にやる気のある人がいないと、なかなか難しそう
そういう人ってその会社見切って転職するイメージあるな

**デフォルトの名無しさん** · 2022/11/07(月) 15:33:20.29

TabControlの名前をXAMLでResources.resxで変えたいのですが、以下のエラーが出ます。
エラーコードでググっても解決策が見当たらなかったのですが、Headerに直接Resources.resxを指定しているのが間違っているのでしょうか？

<Grid>
<TabControl x:Name="MainTab">
<TabItem x:Name="tab1st" Header="{x:Static lang:Resources.Tab1}">

エラー XDG0062 'WpfSample.Properties.Resources.Tab1' StaticExtension 値は、列挙値、静的フィールド、または静的プロパティに解決できません。

**137** · 2022/11/07(月) 16:17:17.03

すいません、自己解決しました。
Resources.resxを「Public」にしていませんでした。

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

WPFってx:Uid使えないんだっけ

**デフォルトの名無しさん** · 2022/11/09(水) 02:45:19.03

WPFのXAMLでコントロールの一括設定をしたいと思い、以下のような形で設定しても設定されないのですが、なぜでしょうか。

<Window.Resources>
<Style TargetType="Window">
<Setter Property="FontSize" Value="12" />
<Setter Property="HorizontalAlignment" Value="Left" />
<Setter Property="VerticalAlignment" Value="Top" />
<Setter Property="Padding" Value="0,0,0,0" />

TargetType="local:MainWindow"にしてもダメでした。

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

もう一点、リソースファイルからSystem.Stringを読み込んでフォントを変更しようとすると、stringからfontfamilyにはキャストできないとエラーになります。
解決策はありますか。

<Setter Property="FontFamily" Value="{StaticResource Window_FontFamily}" />

リソース.xaml
<ResourceDictionary>
<sys:String x:Key="Window_FontFamily">Arial</sys:String>

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

2点目は自己解決しました。sys:StringではなくてFontFamilyタグを使えばOKでした。

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

Windowのスタイルを自分に置いてもだめ
Appに置いときな

**デフォルトの名無しさん** · 2022/11/09(水) 10:05:18.20

Win11 22H2で標準の印刷ダイアログが変わったわけだけど、
このダイアログではプレビューが右に表示されるっぽいけど、
WPFアプリはどうやったらそこにプレビューを表示できるんだろう…。
アプリのユーザーから見ると、プレビュー枠あるのに、そこに出てないのは不具合に見えちゃうよ。

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

>>143
ありがとうございます。FontFamily/FontSizeはApp.xamlの下記一括設定でできたようなのですが、HorizontalAlignment、VerticalAlignment、Paddingは各コントロールで効いていないようでした。
何か、設定方法を間違えているのか、そもそも一括設定できないものなのか、それとも各コントロールで何か他のプロパティを設定してしまうと別の設定になってしまうもののか、どう理解すればよろしいでしょうか。

App.xaml
<Application.Resources>
<ResourceDictionary>
<Style TargetType="Window">
<Setter Property="FontFamily" Value="Arial" />
<Setter Property="FontSize" Value="12" />
<Setter Property="HorizontalAlignment" Value="Center" />
<Setter Property="VerticalAlignment" Value="Top" />
<Setter Property="Padding" Value="0,0,0,0" />

**デフォルトの名無しさん** · 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の役割が半分を端折ることが多いので無駄に見えてくるね