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

**デフォルトの名無しさん** · 2022/01/20(木) 05:40:40.10

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

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

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

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

**デフォルトの名無しさん** · 2022/02/13(日) 09:01:56.66

都度フォントの変更大変そうだなと思ったらResourceDictionaryにFontFamilyを指定しとくのか

**デフォルトの名無しさん** · 2022/02/14(月) 08:48:32.05

>>295
英語だとカッコイイってのがそもそも思い込み。
隣の芝が青く見える的な。
ガイジンさんから見たら漢字カッコイイって思ってるかもしれん。

**デフォルトの名無しさん** · 2022/02/14(月) 20:30:33.82

>>81

キチガイの世界へようこそ・・・
と言うか20世紀なのか今は？

**デフォルトの名無しさん** · 2022/02/14(月) 21:53:59.37

>>298
参考までに

Windows 95 最小ハードウェア仕様要求
物理メモリー、8 MB以上
ストレージ、75 MB以上

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

いくらPCが速くなってもWPF使ったソフトはクソ重い。
MSすら使いたがらないわけだ。

**デフォルトの名無しさん** · 2022/02/14(月) 23:21:43.51

>>299
たしか1998年にあまり予算をかけたくない俺は
Celeron300AでRAM256MB積んだPCを自作していた

そのころの話か？
やはり20世紀の話だろこれは？

**デフォルトの名無しさん** · 2022/02/15(火) 06:12:51.13

>>301
お前がどんなPC組んでたとか全く意味ない。その時代に普及しているPCスペックが全て。
2022年だからそれに合わせてこんな甘々な基準になっているのに
それすらクリアできないようならソフトウェア技術者向いていないから転職を勧める。

**デフォルトの名無しさん** · 2022/02/15(火) 08:57:14.52

10年前からWPFは既にあって、当時の話題とは
Windows Formsから移行とかSilverlightと比較とか
比較対象が変更されはしたが、今と大して変わらない話題だよね

**デフォルトの名無しさん** · 2022/02/15(火) 15:34:06.63

WPFは出た直後にクソ認定されて15年経ってもその評価は変わらない。
FISやIOCと違って技術者は賄賂は受け取らないし忖度もしないのだ。

**デフォルトの名無しさん** · 2022/02/15(火) 15:57:40.84

WinForms
・旧来のウィンドウズAPIの上にレイヤーを重ねたようなもので、（シンプルであるという）利点と
　（平凡なレイアウトやスタイリングオプションという）致命的な災いの両方がある。

WPF
・WinFormsからわずか4年後にリリースされたが、デザインパターンとコンセプトがより複雑であったため、
　一般に受け入れられるまでにはしばらく時間がかかった。
・大規模なデータセットに対してWinFormsよりも大幅に高速化できるが、正しく使用するにはより深い知識が必要である。
・現状は WPF on .NET 6 が一番つぶしが効く状態。

UWP
・Windows UIの未来だったが、鳴かず飛ばず、現在はメンテナンスモードになっている。
　良い点：魅力的なUIを簡単に作ることができ、マウスとタッチの両方でうまく動作する。
　悪い点：サンドボックスとパッケージングの要件が非常に厳しい。
　結論：避けるべき。

WinUI 3
・小さなチームがUWPのUIスタックからできる限りのものを救い出そうとしている。
・遅い、バグが多い、そして多くの歴史的なお荷物が重くのしかかる。
・開発体験はWPFの方が上であり、開発チームは改善に消極的である。
・1年後にまた確認したいが、私は悲観的だ。

**デフォルトの名無しさん** · 2022/02/15(火) 19:01:34.90

現状、WindowsデスクトップアプリはWPFでWinFormsのようなイベント駆動が一番マシなんですかね
レイアウトの自由度、高DPIへの対応、表示速度を争点にした場合

**デフォルトの名無しさん** · 2022/02/15(火) 19:16:29.32

winrtはどこに属すの？

**デフォルトの名無しさん** · 2022/02/15(火) 19:33:35.93

>>306
それでいいと思う。それが一番処理速度的にもファイル構成的にも無駄がない。
ただViewに依存しない処理はなるべく別クラスに切り出すことぐらいはしておいたほうがいい。

**デフォルトの名無しさん** · 2022/02/15(火) 19:36:57.71

データバインドは使わんの？
エラー表示とか便利っぽいよね

**デフォルトの名無しさん** · 2022/02/15(火) 20:18:43.19

>>309
使った方がいいと思った箇所で使えばいいんじゃね？
どちらかに縛る必要はないと思うが

**デフォルトの名無しさん** · 2022/02/15(火) 20:29:33.78

>>305
WinUI3だが、内部のWinRTは十分こなれているからバグは少ない
問題は表示系だが操作不能になるようなものは稀で回避策はある
速度に至ってはWPFより遅いことはないんだが、何処の情報なん？

**デフォルトの名無しさん** · 2022/02/15(火) 20:36:28.97

速度に関して前スレで話題になってたやろ

**デフォルトの名無しさん** · 2022/02/15(火) 20:40:31.81

>>312
1.0 Stable以前は酷いものだったが、そこから情報アップデートしていない人が多いのかね？

**デフォルトの名無しさん** · 2022/02/15(火) 20:42:15.57

https://github.com/microsoft/microsoft-ui-xaml/issues/1633
これは解決されたの?

**デフォルトの名無しさん** · 2022/02/15(火) 20:55:45.02

>>305

> ・現状は WPF on .NET 6 が一番つぶしが効く状態。
これはないかな
まず.NET6後二年も寿命がない

それは別としてつぶしが利くのはwinforms
技術的進展もなければ使えなくなる技術もない
安定

**デフォルトの名無しさん** · 2022/02/15(火) 20:58:11.37

>>313

>パフォーマンスに関する考察
>Windows App SDKのバージョン1.0では、WinUI 3アプリの起動速度、RAM使用量、インストールサイズが、UWPで見られるものより大きい/遅いです

by docs.microsoft.com

Windows App SDKのバージョン1.0では
Windows App SDKのバージョン1.0では
Windows App SDKのバージョン1.0では

**デフォルトの名無しさん** · 2022/02/15(火) 20:59:22.62

>>314
WinRT系だと自家製ビヘイビアもほとんど使わずに済むから特に気にならないバグだな
既存のコントロールは関係ないだろうし

**デフォルトの名無しさん** · 2022/02/15(火) 21:07:44.33

コンポーネントメーカーdebexpressの中の人が速度がでねぇっていってるし
community toolkitのDataGridも速度出てねぇし
つまりListViewとかで速度がWPFより遅いって話なんじゃねぇの??

**デフォルトの名無しさん** · 2022/02/15(火) 21:08:04.86

>>316
UWPの.net Nativeは極めて優秀だからそれと比較してGUIのパフォーマンスやインストールサイズが悪くなるのはしょうがない
UWPだとライブラリの中でアプリで使われていない部分を全部バッサリ切り捨てるしAOTにコンパイルされるので
WPFのUnSafeと同等のパフォーマンスだ
UWPはWPFと比べられないほどインストールサイズも小さいし速度も早い

ただUWPでもファイル操作はサンドボックス化の影響を受けていて遅いが、WinUI3はSystem.IOを使えるからそこは充分早い

**デフォルトの名無しさん** · 2022/02/15(火) 21:10:30.82

マイクロソフトの中でもフレームワーク開発チームは互いに戦ってるのかな

**デフォルトの名無しさん** · 2022/02/15(火) 21:12:07.58

>>315
WPF on .NET6の次はWPF on .NET8に乗せ換えるだけだぞ。

>技術的進展もなければ
だからそもそも採用されない。
わざわざ生産性が低いものを選ぶ理由がない。

**デフォルトの名無しさん** · 2022/02/15(火) 21:24:14.14

>>321
生産性は高いよ
時間当たりに生み出す価値が大きいほうが生産性が高いと言う

winformsで5分でできるものをWPFでは確実にそれ以上かかる
しかも学習時間も含めるとWPFの生産性が確実に低い

**デフォルトの名無しさん** · 2022/02/15(火) 21:31:14.07

WinFormとWPFは同等の手法が使えるからどっちがどっちって事はないだろ
慣れたら何かBindableObjectとReativeProperty使えばVVMでサクっと作れて見通しも良い

**デフォルトの名無しさん** · 2022/02/15(火) 21:33:48.96

>>319
そもそもUWPってGUIはWindows側のAPIを呼ぶだけだからな
WPFやWinUI3みたいに巨大なランタイムをロードする必要がない
AOTみたいな小手先の最適化を云々する以前に、ディスクIOの量が全然違う

**デフォルトの名無しさん** · 2022/02/15(火) 21:49:28.29

>>322
いや、生産性はかなり低い。
作るスピードも修正するスピードもWPFの方がずっと上。
winformsの進化版として使う分には学習時間なんてほとんどかからない。

**デフォルトの名無しさん** · 2022/02/15(火) 21:52:12.13

常に勉強し続けるのが善で正義と思うのは間違い
MVVMのパターンも変わり続けて何か正義なのかすらもわからない

これはこうしたほうがいいと絶対的に言える状況なのか
1年しないうちにいやいやこれはとか訂正されたりライブラリから削除されたり生産性が低すぎる

**デフォルトの名無しさん** · 2022/02/15(火) 21:55:34.96

MVVMの長らくの議論
ダイアログはどうやって出すかみたいな馬鹿な問題とかもうどうでもいい

**デフォルトの名無しさん** · 2022/02/15(火) 22:09:55.99

ひょっとしてWPFはMVVMで作らないといけないと勘違いしている？
MVVMを一切使わなくても問題ないよ。それでもWPF使った方が開発が楽だから。

**デフォルトの名無しさん** · 2022/02/15(火) 22:17:46.86

バインディングって単語が出るとMVVMパターンと同一視しちゃうのかな

**デフォルトの名無しさん** · 2022/02/15(火) 22:43:33.35

コードビハインド書いたらMVVMじゃないと

**デフォルトの名無しさん** · 2022/02/15(火) 22:46:16.80

個人的にはC++みたく良いとこ取りする感じかな
WinFormsの気軽さで、データバインディングするだけ

**デフォルトの名無しさん** · 2022/02/15(火) 22:49:22.58

単発アプリならVVMでじゅうぶんMは要らん
やりにくいところはコードビハインドで逃げ

**デフォルトの名無しさん** · 2022/02/15(火) 23:47:52.75

>>332
Mは普通APIの先のサーバサイドにあるだよ

**デフォルトの名無しさん** · 2022/02/15(火) 23:48:13.11

>>327
笑

**デフォルトの名無しさん** · 2022/02/16(水) 10:21:32.43

笑笑

**デフォルトの名無しさん** · 2022/02/16(水) 10:59:48.00

ダイアログに関する議論はMFCの頃から繰りかえされていてMVVM関係ない
最近の話題だと適用ボタンだよね。ダイアログに何か設定するOn/Offという項目があったと仮定して
その設定が反映されるのは(1)On/Off切り替えた瞬間(2)適用ボタンを押したとき(3)OKを押してダイアログを閉じた時
でそれぞれ異なる

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

使うコントロールも考慮する必要がある。
トグルスイッチはOn/Offを切り替えた瞬間に設定を反映することが求められる。

**デフォルトの名無しさん** · 2022/02/16(水) 14:09:37.66

その話題もMVVM関係ないんだけどな
ただのUIの問題で

**デフォルトの名無しさん** · 2022/02/16(水) 14:28:20.83

https://github.com/microsoft/microsoft-ui-xaml/issues/6360

これうちでも発生してるわ
パッケージ名を、初期値のぐちゃぐちゃなやつに戻したらきちんと動いた
パッケージ表示名だけ変えておけば問題ない？ユーザーから見える部分で影響がなければいいんだけど

**デフォルトの名無しさん** · 2022/02/16(水) 14:46:38.19

>>338
うん、だから今は設定反映の話題だよ。

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

違うんじゃね？
VとVMの対話の件だろ
結局メッセンジャーパターンで解決されたけど

MVVM界隈でもWPFだけだぞ
とにかくアホらしい

**デフォルトの名無しさん** · 2022/02/16(水) 21:54:37.14

MVVMで真っ当に実装する必要があるならダイアログ今はサービス使ってるわ
適当アプリならVMからShowDialogや！

**デフォルトの名無しさん** · 2022/02/16(水) 22:33:25.97

MVVMで御高説をのたまってるやつらも、
ダイアログだけVMがVの参照持ってるの多いと思われ

アホ過ぎ

**デフォルトの名無しさん** · 2022/02/16(水) 22:56:04.26

ケースバイケースだろ

**デフォルトの名無しさん** · 2022/02/16(水) 22:56:34.84

WinUI3のContentDialogは極自然にVMから操作可能ではある
但し厄介なバグがあるんだよな

**デフォルトの名無しさん** · 2022/02/16(水) 23:50:00.59

そういうところが最近のMSらしい

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

Windowsのシステムで設定したテーマをそのまま使うと問題ないけど
RequestedThemeでアプリ独自のテーマに変更するとContentDialogの表示がおかしくなる
黒バックに黒文字になったり白バックに白文字になったり

しかしContentDialogをページに埋め込みじゃなくて独立させて作るとと何故かうまく動く

**デフォルトの名無しさん** · 2022/02/17(木) 08:30:25.43

>>341
いや、違くない。最初にMVVMとは関係ないと断っている。
だから実装ではなくUXの話。
ちなみにメッセンジャーパターンはアンチパターンだから使うやつは馬鹿。

**デフォルトの名無しさん** · 2022/02/17(木) 08:57:01.84

>>348
どうするのが正解？

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

>>348
俺がWPFまだやってた頃、
VとVMの通信の方式でかなり揉めてて
メッセンジャーパターンの確立で
やっとWPF流MVVMのすべての問題が解決！
皆が＼(^o^)／ってなってたんだけど
その後なんか動きがあったのかい？

自分はこの頃WPFにサヨナラして
SPAに全振りする事になったんだけど

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

>>VとVMの通信
これ双方向の話ね

**デフォルトの名無しさん** · 2022/02/17(木) 14:37:01.90

WinUI3、ちょくちょくデザイナが表示されないってバグ報告あがってて笑った。
まさかデザイナが無いなんて夢にも思わないよな。正式版なのに。

**デフォルトの名無しさん** · 2022/02/17(木) 14:38:43.90

WPFに歴史的価値があるとすれば、それは
MVVMは保守性と開発効率を低下させると実証したこと。

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

既存のFormアプリにWPFのWindowを表示するため
WPFカスタムコントールライブラリのプロジェクトを追加して
WPFのWindowがダイアログで開けたのですが、なぜかFormアプリの
UIコンポーネントが全て小さくなります。
小さくならない方法はありますでしょうか？

**デフォルトの名無しさん** · 2022/02/18(金) 14:23:41.28

>>350
VでVの要素を操作するサービスクラスを生成してVMにインジェクションするのが一番楽だが
詳細を噛み砕いて説明するのは骨が折れるから誰かやってくれ

**デフォルトの名無しさん** · 2022/02/18(金) 17:40:21.19

>>355
WPF メッセンジャー MVVMでググると上位は大体10年前ぐらいの記事が出てきます
でも多分今でもメッセンジャー使ってる人はいるんだと思う

○○の寄せ集めのQiitaですら代わりの技術の紹介がない

**デフォルトの名無しさん** · 2022/02/18(金) 17:43:40.08

WPFがMVVMがクソだと証明したからな。

**デフォルトの名無しさん** · 2022/02/18(金) 17:47:22.30

他のMVVMではこんな話で盛り上がってないもんな
データの射影ぐらいの扱いなのになんでWPFじゃ状態遷移とかその他もろもろ全部MVVMでやらなければならないんだ
どうせ再利用なんかしないのに

**デフォルトの名無しさん** · 2022/02/18(金) 17:54:24.26

>>358
中途半端な初心者が「MVVMでやらないとバカにされる!」
って強迫観念に囚われてるか、意味も分からずこうやって作るものって思考停止してるか、両方か

**デフォルトの名無しさん** · 2022/02/18(金) 17:58:06.73

>>359
いやいや
熟練と言うか知り尽くしたほうが危うい

**デフォルトの名無しさん** · 2022/02/18(金) 18:26:19.18

メッセンジャーパターンまで付き合って
辞められて良かったわーー
苦労しても固有のロジックすぎて
他で全く役にたたないからな

**デフォルトの名無しさん** · 2022/02/18(金) 18:27:26.73

>>359
当時から、
MVVM至上主義って言われてたよな

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

MVVM使わないで、例えばconfigを設定する画面を想定した場合、

//configからcontrolへ
IdTextBox.Text=config.Id;

//controlからconfigへ
config.Id=IdTextBox.Text;

みたいなのをコードビハインドに書いてるの？

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

HTML/CSSなら思い通りの画面作れるけどXAMLだと作れない。
「技術的に」じゃなくて「自分のスキル的に、っていう意味だけど、
やっぱり参考となるようなsampleの絶対数の少なさがなぁ。

**デフォルトの名無しさん** · 2022/02/18(金) 22:07:10.37

WebView2でよくね？
今更こんなオワコン使わなくても

**デフォルトの名無しさん** · 2022/02/18(金) 22:20:20.27

話題がループしてるな

**デフォルトの名無しさん** · 2022/02/18(金) 22:31:21.56

>>365
WebView2をどう使うの？

**デフォルトの名無しさん** · 2022/02/18(金) 22:34:46.53

WebView2の人はUIフレームワークとツールキット何使ってる？

**デフォルトの名無しさん** · 2022/02/18(金) 23:51:16.91

あー、WebViewでローカルのhtmlとかも表示できるってこと？
だったらそれでいいのかな

**デフォルトの名無しさん** · 2022/02/18(金) 23:55:20.81

どうやって表示制御するの？

**デフォルトの名無しさん** · 2022/02/19(土) 00:12:02.32

>>370
C#のオブジェクトをWebView側に渡すことでJavaScript側からC#のメソッドを呼び出したりC#側の状態を参照したりできる
あとは普通にJavaScript側でReactとか使うだけだ

**デフォルトの名無しさん** · 2022/02/19(土) 00:22:40.12

JS側とC#のやり取りをどうやるか定番ってあるのかな。
あまり聞いたことがないがまさかRESTとかじゃないだろうし。

**デフォルトの名無しさん** · 2022/02/19(土) 00:27:02.29

WPFで自前ブラウザー&httpsサーバー作って
SPAをホストする方法ね
中身はReactとか...

自分がSPAに移行するまえに
しのぎでやってた方法
この方式でキオスク端末でまだ何台か動いてるよ

でも今はPWA有るからそっちのが楽だけどね

**デフォルトの名無しさん** · 2022/02/19(土) 00:27:35.44

>>372
websocket

**デフォルトの名無しさん** · 2022/02/19(土) 00:28:31.85

>>372
electron.NETとかみてみれば
もうWPFの要素ないけど...

**デフォルトの名無しさん** · 2022/02/19(土) 00:32:25.83

あとc#とjsの連携のedge.jsというのがある

**デフォルトの名無しさん** · 2022/02/19(土) 00:36:35.88

>>368
Svelte

**デフォルトの名無しさん** · 2022/02/19(土) 00:47:45.48

なんかいっぱいでてきたｗ
定番とかは定まってないのか。

**デフォルトの名無しさん** · 2022/02/19(土) 00:51:11.00

react

変なの選択すると開発者集めに苦労するよ
保守も

**デフォルトの名無しさん** · 2022/02/19(土) 00:59:59.59

純粋なWebアプリならもちろんReactでいいんだが。

>変なの選択すると開発者集めに苦労するよ

JS on C#ってのが現時点ではそんな気がする。
素直にWPFやFormsでいいじゃん、と。

**デフォルトの名無しさん** · 2022/02/19(土) 01:26:47.51

潮流的にクライアントサイド要員はjs(ts)必須ですね
デザイナーの成果物がhtml,css,jsですから
ダサいのは商品価値もさがりますからね

サーバサイドはjava,c#,js,ruby,python(最近は本当に増えてます)いろいろですね

言語統一したかったらjsですね
ただサーバサイドは要員も別のが多いです

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

jsは型が動的なのがなぁ…tsも実行時の型は保証してないし

**デフォルトの名無しさん** · 2022/02/19(土) 03:21:20.16

TSの処理系によって型安全レベルが違ってるからねぇ
ありえんけどブラウザがネイティブでTSに対応したら使ってもいいけど

**デフォルトの名無しさん** · 2022/02/19(土) 03:33:01.88

クライアントサイドはc#よりtypescriptのほうが書きやすくて圧勝ですね

あとUI開発にはホットリロード必須と思います
Blazorは最悪でした

**デフォルトの名無しさん** · 2022/02/19(土) 07:57:27.90

JavaScript(TypeScript含む)は絶対関わりたくない。
こんなの大規模開発に使っていい代物じゃないよ。
JavaScriptが担っていた部分はDartに置き換わってほしい。
あとReact系もさっさと滅びろ。

**デフォルトの名無しさん** · 2022/02/19(土) 07:57:48.80

>>116のMS製React Nativeがいいんでないか？
もしくは

**デフォルトの名無しさん** · 2022/02/19(土) 08:46:04.71

つか、WebView２ならC#とJSのIFは標準で用意されているのに誰も知らないのな
つまり口だけで誰も使っていないということだろ

**デフォルトの名無しさん** · 2022/02/19(土) 09:07:27.13

>>354
答えになってないかもしれんが、
FormアプリにWPFを使うなら、formのelementhostにWPFのユーザーコントロールを貼るのがいいと思う

**デフォルトの名無しさん** · 2022/02/19(土) 10:01:52.96

>>387
それマジ？

**デフォルトの名無しさん** · 2022/02/19(土) 10:14:08.32

>>389
あ、371の人は知っているようだから「誰も知らない」は間違いだな
WebView2のドキュメント見れば書いてあることだ

**デフォルトの名無しさん** · 2022/02/19(土) 10:45:05.98

.NET5 WPFのListBoxについて質問があります

VS使わずにやってるんですがBehaviorがないと言われます
名前空間もusingしてますが、そもそも無いようで…
別の機種からの投稿なので具体的な名前空間は忘れましたが、サンプル通りのやつです

やりたいことは一つのListBox内の入れ替えや複数のListBox間のD&D操作です

**デフォルトの名無しさん** · 2022/02/19(土) 10:48:21.53

C#でM書いて渡せばWebView2のJSから直接アクセスできるから、MVVMやってるならVVMの部分がそのままJSとHTML/CSSに置き換わるだけだね
つまりビジネスロジックは完全にC#で書けるわけで、これでなおJSで大規模開発辛いと思うなら、
多分そいつがMVVMだと思っているものはVMにロジック書きまくってるエセMVVMの可能性が高い

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

WebView2
ひっそりとそんなブリッジ機能あったのね
10年前にあれば良かったかな...

日曜プログラマー的に
昔みたくフロントreactでロジックc#で作ってみるかな

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

でもWebView2使った
electron相当のもうあんじゃね？
知らんけど

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

System.Windows.Interactivity.dll → Xaml.Behaviors.Wpf