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/23(水) 12:16:35.49

WPFに真剣に取り組んでも将来仕事があるのか心配。

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

家でWPFに真剣に取り組んで
日中はコンビニでアルバイト

だいたいこういう生活スタイルになるかな

**デフォルトの名無しさん** · 2022/02/23(水) 13:22:26.22

>>446
MVVMの第一人者がWPF見限ってWebに移ってるのが全て

**デフォルトの名無しさん** · 2022/02/23(水) 13:39:30.83

>>445
ありがとうございます。.NET6はまだまだということでしょうかね。

**デフォルトの名無しさん** · 2022/02/23(水) 14:42:12.12

>>448
それいつの話よ！

**デフォルトの名無しさん** · 2022/02/23(水) 15:28:20.73

>>446
「仕事で」というのは随分ニッチ狙いだな。
WPFは個人的に使うツールを作ったりするのに便利。
WPF⇒WinUIに移行する道もあるし。
今は駄目駄目のWinUIも2〜3年後には使えるレベルになってるでしょ。

WebはFlutterに置き換えたい。
JavaScriptはVBAと同じく、プロが使うべき言語じゃない。
TypeScriptも同じ。腐った食材をラッピングしても中身は腐ったまま。

**デフォルトの名無しさん** · 2022/02/23(水) 15:30:22.63

WPFを腐った食材と言いたげだな

**デフォルトの名無しさん** · 2022/02/23(水) 15:45:07.83

腐ってるのはJavaScript。
誕生の経緯からして大規模開発に使うようなものじゃない。

WPFは頑張ってると思うよ。
Windowsデスクトップ向け開発技術の中ではバランスがいい。
これ選んでおけば困ることがない。
後発が揃いも揃ってヘボすぎる結果でもあるけど。

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

>>453
WinFormsで十分

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

腐ってると言ってもWPFは納豆なんだよ。好きな人は好きだが嫌いな人は食べない。

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

>>454
.NET FrameworkのWinFormsはスケーリング対応が腐ってるのがな
.NET6のなら改良されてマシになってるけど

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

近所にスケートリンクないんだよな

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

あいかわらずのおじさん...

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

納得くせーガキが背伸びすんなよ

**デフォルトの名無しさん** · 2022/02/23(水) 17:08:22.18

>>454
WinFormsを進化させたのがWPF。
だからWinFormsの代わりにWPFを使えばOK。

**デフォルトの名無しさん** · 2022/02/23(水) 17:35:40.25

Flutterってwebもデスクトップもまともに動くんかねぇ・・・

**デフォルトの名無しさん** · 2022/02/23(水) 17:42:10.42

flutterはデスクトップ向けに簡単にネイティブAPIつっつけないんじゃないの？
C#ぐらいデカいデスクトップ向けバッテリーがあっても結構頻繁にネイティブ必要なのに。

**デフォルトの名無しさん** · 2022/02/23(水) 18:21:05.11

flutter webはダメっぽい
CanvasKitのwebasmとか大きすぎてダウンロードが..
そこから..
flutter desktopはok

**デフォルトの名無しさん** · 2022/02/24(木) 08:38:23.23

この第一人者ってJohn Gossman？

**デフォルトの名無しさん** · 2022/02/24(木) 15:22:11.77

WPFで作成したアプリをWindows Defenderが誤検知したんだがMSふざけてんのか？
お前のとこのツールで作成したアプリだぞ

**デフォルトの名無しさん** · 2022/02/24(木) 15:53:17.31

>>465
どの開発ツールで作成したかなんて関係ないだろ、アホか?
見られてるのはどんな挙動をするか。
お前と同じ、キョドってるから職務質問されるんだよ。

**デフォルトの名無しさん** · 2022/02/25(金) 08:37:34.40

>>465
納品するソフトで同じ事があった。

**デフォルトの名無しさん** · 2022/02/25(金) 09:03:07.81

ウイルスがやりそうなことや、お行儀の良いプログラムがやらなそうなこと実装すると結構引っかかる

**デフォルトの名無しさん** · 2022/02/25(金) 09:16:53.23

Webにおくと問答無用で「人気がない」判定されて疑われる

**デフォルトの名無しさん** · 2022/02/25(金) 12:36:04.84

このスレでflutterとかrustとか知ることできて
ありがたい

**デフォルトの名無しさん** · 2022/02/25(金) 13:03:03.43

やはりGUIはFlutterで構築するのが流行るかな

**デフォルトの名無しさん** · 2022/02/25(金) 13:14:04.91

flutterはネストしたスクロール部分で欠陥があるから注意

**デフォルトの名無しさん** · 2022/02/25(金) 13:56:06.11

まあVSのC++のコンソールアプリのテンプレートのHelloWorldをデバッグビルドするだけで
マカフィーはウィルスとして判定するんやけどな...

**デフォルトの名無しさん** · 2022/02/25(金) 14:10:58.39

マカヘー「今どきC++なんか使ってるやつはウィルス作成者に違いない！ギルティ！」

**デフォルトの名無しさん** · 2022/02/25(金) 16:03:43.25

>>472
そもそもUIとしてネストしたスクロールは使いづらいし、
見た目が悪い

**デフォルトの名無しさん** · 2022/02/25(金) 17:52:46.88

ネストしたスクロールってandroidで当たり前のツールバーがコンテンツのスクロールに合わせて表示されたり消えたりするやつのこととかを含む..
まじでflutterスクロールまわり欠陥だらけ

jetpack composeはそうならないことを祈る

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

つうか、netflixとかamazonのアプリとかyoutubeとかもネストしたスクロールだろ
縦方向にスクロールさせて個別のトピックで横方向にスクロール
こういうアプリ良くみるけど

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

>>477
カルーセルでしょ
最近のUX言語ではスクロールとはまた別の概念だよ

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

ネストしたスクロールで方向が違うものを特にカルーセルっていうだと思う(想像)

**デフォルトの名無しさん** · 2022/02/25(金) 19:04:52.93

ごめん>>479はカルーセルじゃねぇな
やっぱ、>>477はネストしたスクロール方向がちがうスクロールじゃね?

**デフォルトの名無しさん** · 2022/02/25(金) 19:20:06.74

>>478
違う概念というが俺は元からスクロールについていってるんだが
横方向と縦方向と方向が違うが>>476はネストしたスクロール

UI的にカルーセルって言葉使いたいなら>>476はネストした
カルーセルじゃね

**デフォルトの名無しさん** · 2022/02/25(金) 19:54:02.28

ネストしたスクロールって親にも子にもスクロールバーが出るようなUIだぞ。
カルーセルはスクロールとは言わずにスライドとかページ切り替えと表現する。

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

それ以前にデザイン的じゃなくて技術的な観点から複数のコンポーネント間でUIイベントをやり取りしてスクロールを調整する動きをネストしたスクロールと表現してそういう前提で話を進めてたんだが
そこはわかりずらかったっぽいので悪かった
だから>>476のツールバーが消えたり隠れたりする動きも含めたり

androidならNestedScrollViewやらNestedScrollingParent

まぁ、そこらへんがflutterはくそ

**デフォルトの名無しさん** · 2022/02/25(金) 21:29:28.09

その辺は何でやってもクソな気が…(やりたくない

**デフォルトの名無しさん** · 2022/02/27(日) 02:20:45.48

いまからだとどうWPF勉強したらいいの？

**デフォルトの名無しさん** · 2022/02/27(日) 02:22:27.16

MSのドキュメント読むだけだろ。

**デフォルトの名無しさん** · 2022/02/27(日) 08:52:36.15

今からWPFなんてやっても仕事ないけどな
趣味なら好きなようにしていいが

**デフォルトの名無しさん** · 2022/02/27(日) 09:40:55.29

かずきのWPF講座読んで、あとは使うならMVVMライブラリのチュートリアルでもやってみれば

**デフォルトの名無しさん** · 2022/02/27(日) 10:20:56.98

もはやユーザーが少なすぎてベストプラクティスもクソもない状態だから、自分の好きなように使えばいいよ

**デフォルトの名無しさん** · 2022/02/27(日) 10:35:00.29

そうそう。MVVM警察気取りが幅を利かせてた痛々しい時代は過ぎ去ってアーキテクチャ固執主義は間違いだったと実証された。
コードビハインドにガンガン実装しても全然いいよ。

**デフォルトの名無しさん** · 2022/02/27(日) 10:43:34.24

それは生存バイアスってやつだ
そもそも設計の良い悪いを言い出したらMVVM以前にこんな日の目を見なかったレガシー技術を採用すること自体が明らかに悪いわけで、
そういうことを気にしない人が残ってるだけ

**デフォルトの名無しさん** · 2022/02/27(日) 10:50:36.47

かずきって懐かしいな
いまなにやってんだ？

**デフォルトの名無しさん** · 2022/02/27(日) 10:51:25.63

>>490
WPFのMVVMが基地外なだけさ

**デフォルトの名無しさん** · 2022/02/27(日) 13:45:33.61

>>487
身近なところや、「WPF 求人」で検索した結果を見ても仕事はあることはある。
他の人気のある言語と合わせて習得しておくのは悪くはないと思う。

**デフォルトの名無しさん** · 2022/02/27(日) 19:41:21.55

MVVMって誇れるほど難しい技術でもないからｗ
逆にコレがわからないとしたら転職考えたほうが良いかも

**デフォルトの名無しさん** · 2022/02/27(日) 19:44:43.16

超ブラックのIT業界いるなら、しかもPGは底辺なのでさっさと転職したほうがいい。

**デフォルトの名無しさん** · 2022/02/27(日) 21:02:08.91

>>492
日本マイクロソフト

**デフォルトの名無しさん** · 2022/02/27(日) 21:12:32.76

>>495
わからないと言うより面倒と言う側面の方が強い
後はどうしたらよいか定番みたいなパターンがなかった

**デフォルトの名無しさん** · 2022/02/28(月) 07:19:19.52

今さらDispose()まで必須になったReactivePropety使うならナチュラルに書いた方がシンプルだし分かりやすい

**デフォルトの名無しさん** · 2022/02/28(月) 08:37:02.02

自分的にはReactivePropetyは最初から眼中にない。
ほぼ個人でメンテしているようなものは業務で使うのはありえないし、
わざわざメモリリークの爆弾仕込むようなものだし。

**デフォルトの名無しさん** · 2022/02/28(月) 08:59:25.09

>>456
.NET6のWinFormsデザイナ、まだベータ版だぞ。
スケーリング対応も多少改善されてるけど問題点はまだいくつも残ってるし、
そもそも固定配置前提のUIフレームワークは生産性低すぎて辛いだろう。

**デフォルトの名無しさん** · 2022/02/28(月) 12:51:13.26

やべー奴がいたw
https://mobile.twitter.com/ohbashunsuke/status/1495900842389610498
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2022/02/28(月) 13:42:58.27

>>501
業務アプリだと1画面にビシッとハマらなければならないのでGridでいい
逆にWindowsの「設定」みたいに画面スクロールしてーーとか出したら切られる

**デフォルトの名無しさん** · 2022/02/28(月) 13:59:46.31

>>503
Webアプリで目の肥えた客「ウィンドウサイズに応じて最適な項目配置に変わってね。縦長ウィンドウにしたら縦に並べて、横長にしたら横に並べてね。」

**デフォルトの名無しさん** · 2022/02/28(月) 15:06:09.80

>>504
WinFormsでもFlowLayoutPanelてのがあった気が

**デフォルトの名無しさん** · 2022/02/28(月) 15:41:54.06

>>505
客「あっ、そうそう、文字サイズは5段階ぐらいで調節可能にしといてね」

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

>>506
それはきついかも…

**デフォルトの名無しさん** · 2022/02/28(月) 17:03:59.41

テレワークで突然解像度1366x768のノートPCとかいう人権のない環境に叩き落された人もいる
古の業務ソフトには縦800が前提かつ、全ウィンドウでサイズ変更不可とかいうクソみたいな仕様を採用してるものが多いので
最下部のボタンが押せなくて仕事にならないって話をもう数件聞いてる
レスポンシブにする必要はないが画面サイズ固定は流石に時代遅れだと思う

**デフォルトの名無しさん** · 2022/02/28(月) 17:20:47.12

>>508
それはそうなんだがWinFormsの場合はPanelを使った流動的なものでもフォントが変更されるとフォント次第ではコントロールの幅とかが変に…
かと言ってWPFはListBoxとかで工夫を加える場合面倒

**デフォルトの名無しさん** · 2022/02/28(月) 22:55:13.95

class ViewModel{
public ObservableCollection<Mail> Mails = ....
}

データグリッドでMailsをbindingして表示します。
データグリッドの各行ににチェックボックスを付けて、例えば一括して削除などの動作をしたい場合、MailクラスにIsCheckedなどのプロパティを追加する以外に良い方法はありますか？
Mailを継承した専用クラスを作ってそちらをbindingする方法も考えましたが、もっと簡単な、あるいは一般的な方法があれば教えて頂きたいです。

**デフォルトの名無しさん** · 2022/02/28(月) 23:25:29.73

UIの状態をあらわすのがViewModelなんだから、Mail用のMailViewModelを作ってそっちにIsCheckedプロパティを追加する

で

class ViewModel {
　ObservableCollection<MailViewModel> MailViewModels =
}

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

MVVM的にはViewにバインドさせるのはModelじゃなくてViewModel
Modelをそのままバインドできる要件ならViewModelを用意せず横着してもいいけど

**デフォルトの名無しさん** · 2022/03/01(火) 04:27:43.12

こんな単純なことするのにも迷うMVVMゴミすぎる
本末転倒だよ…

**デフォルトの名無しさん** · 2022/03/01(火) 08:15:49.02

そういうのはMVVMに限らない。MVCだって学んでなけりゃ迷うわな。

**デフォルトの名無しさん** · 2022/03/01(火) 10:13:10.94

ViewModelも使うけど加工する必要がないデータはModelから直接バインドしてます
最初のころは全てViewModel経由していたけど、その意味がわからなくなって

**デフォルトの名無しさん** · 2022/03/01(火) 10:17:26.44

>>515
MVVM警察だ。お前を逮捕する

**デフォルトの名無しさん** · 2022/03/01(火) 11:08:37.82

>>515
Modelってことはコードビハインド？
ざっと触ってみた感じ、ViewModelとModelは別物だね

WinFormsとかみたいな場合はイベントとかで直接View、つまりコントロールをいじってた

これをWeb系みたくデザイナーとプログラマの役割分だけするためにイベントやModelで直接コントロールをいじることを禁止する
もちろん、表示・非表示の切り替えみたいなのは別で

ViewModelを介すことで直接コントロールを操作することを防ぐ

例えばListBoxの中身をデータバインディングした場合、ViewModelを操作(配列に対する操作とか)をしたらListBoxに反映される

…って妄想してる

**デフォルトの名無しさん** · 2022/03/01(火) 11:21:43.44

デスクトップ開発にデザイナーなんて職業は存在しない。

**デフォルトの名無しさん** · 2022/03/01(火) 13:08:57.70

>>517
反映するにはオブザーバブルでないといけない
それがVM

**デフォルトの名無しさん** · 2022/03/01(火) 13:33:00.63

>>518
デザイナーが居る場合はある
XAMLは作ってくれないし、デザイナーの指定したデザインの再現に苦労するのはプログラマだが

**デフォルトの名無しさん** · 2022/03/01(火) 16:14:35.26

>>513
だな

**デフォルトの名無しさん** · 2022/03/01(火) 17:02:09.29

採用すると生産性が落ちるアーキテクチャとか存在意義なくね？
プログラマーのオナニーでしかない

**デフォルトの名無しさん** · 2022/03/01(火) 18:56:30.75

>>511
これってMailViewModelの中にMailModelを保持すると思うけど、グリッドコントロールで行を消すとMailViewModelは消えるけどMailModelは消えずに残るよね？
そこは頑張ってコード書いて同期を取るしかない？

**デフォルトの名無しさん** · 2022/03/01(火) 19:34:21.36

ストレージから削除するなら
頑張って書いたほうがいい

**510** · 2022/03/01(火) 19:37:28.19

皆さんありがとうございます。
class MailViewModel : Mail{
public IsChecked {
get => _isChecked;
set => SetProperty(ref _isChecked, value);
}
private _isChecked;
}

上記のようなクラスを作ってBindingするのが良さそうに思いました。

**デフォルトの名無しさん** · 2022/03/01(火) 19:51:58.93

>>523
グリットコントロールから行を消すことがメールの削除の操作を意味するようにしたいならMailModelも消す
単に非表示にしたいだけとか、ゴミ箱に入れておいて復活させるようにさせたいとか、色々考えられる
だからViewModelが欲しくなったのさ

**デフォルトの名無しさん** · 2022/03/01(火) 20:12:49.81

>>526
なるほど。ケースによって対処は変わるよね。
ありがとう。

**デフォルトの名無しさん** · 2022/03/02(水) 06:20:23.82

Electronの葬式準備はできたか？
https://github.com/tauri-apps/tauri#comparison-between-tauri-and-electron

**デフォルトの名無しさん** · 2022/03/02(水) 18:19:13.15

rustとか新しいのぼえとうないなぁ

**デフォルトの名無しさん** · 2022/03/03(木) 05:36:04.02

>>528
これは楽しみだな

**デフォルトの名無しさん** · 2022/03/03(木) 09:44:18.37

ここまで普及したElectronの牙城を崩すのは無理な気がする。せいぜいGoレベルだろう。
Electronがディスク使用量もメモリ使用量も超重量級なのは不満に思ってたけど。

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

viewをhtmlとcssで書けないとつまらんよ
デザインがしょぼくなる

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

WPFレベルでよければ可なのかもしれんが

**デフォルトの名無しさん** · 2022/03/03(木) 11:12:38.88

しょぼい方が評判良くて、デザイナーの自己満足全開デザインが使いづらい・分かりにくいと不評なのが現実

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

>>534
あんたがセンス無いだけ

**デフォルトの名無しさん** · 2022/03/03(木) 11:25:49.76

>>535
まあそうやって逃げるしかないよな。
お前の仕事は無意味だって認めることになるんだから。

**デフォルトの名無しさん** · 2022/03/03(木) 11:41:18.82

碌に使いもしないが権限だけは大きいエライオジサンのせいで見た目だけは派手だが使いづらいものになるのはまれによくあること

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

デザインセンス云々は置いといてhtml+cssのほうがデザインの幅が広いのは確か
予算があるならデザイナーにも頼めるしね

**デフォルトの名無しさん** · 2022/03/03(木) 23:32:59.05

WPF+MVVM+Rxの実装について勉強中です
それぞれの各機能はなんとなく掴めてきたのですが、実装する場所や通知の受け取り方がまだ分かりません
例えばObservable.Intervalで指定した時間ごとにDBアクセスし、更新があれば通知するという処理はどのクラスに書くべきなのでしょうか
なんとなくですが、Mで実装しVMに通知、Vに表示と考えています

**デフォルトの名無しさん** · 2022/03/04(金) 08:04:23.26

>>539
MVVMはあくまで、GUIの設計パターン。
DBアクセスのようなアプリの内部処理は
Mで包んでGUIの処理から隠されるので、
MVVMの処理フローには一切出てこない。

Mの原則は「GUIから見える状態に変化があれば通知する」。

この場合は、DBアクセスし、更新があり、
その結果としてGUIが更新が必要になったら、
Mに通知させるという処理になる。

**デフォルトの名無しさん** · 2022/03/04(金) 09:46:05.06

大変わかりやすい

**デフォルトの名無しさん** · 2022/03/04(金) 12:16:19.88

お気に入りのアプリがWPFで実装されてて公開されてるから古いUIをWin 11のUIに合わせたくてForkしてWinUI3.0に対応させようと思ったらWindows App SDK 1.0だとAcrylicやMicaに対応してないとかズコーだわやっぱアホだわMSやることがすべて片手落ち
結局サードパーティー製のAcrylic実装を使う羽目になったわけだがこっちもろくすっぽメンテされてなくてWin11に対応してなくてダブルでズコー
たまにやる気になってプライベートでいじろうかと思ったらこれだからMSの開発環境ってマジでどうしようもないな
誰かWin11とVS2022で使える無料のAcrylic実装しらんかね？

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

>WinUI3はまだ完成していません。

一応MSもその認識はあったのね。
あんなお粗末な出来で自信を持って1.0として出したわけじゃないのね。

**デフォルトの名無しさん** · 2022/03/04(金) 12:43:20.96

>>542
WinUI選ぶくらいならこれ。

Flutter for Windows
・fluent_uiパッケージ
・flutter_acrylicパッケージ

Windows向けはまだ出たばかりだけど、
現時点の機能・品質、
フレームワークとしての出来、
将来性、
開発者の期待度
どう考えてみてもWinUIがFlutterに蹴散らされる未来しか思いつかない。

WinUIは

「これが最新らしいし、やってみるか」
↓
「えっ？なにこれ、こんなしょぼいの？こんなこともできないの？」

って感じでちょっと触って実情に愕然として、さーっと離れていく。

**デフォルトの名無しさん** · 2022/03/04(金) 16:27:48.56

fluent_ui実際使うとちょっとアレ

modernwpfもそうだがやっぱ個人メンテじゃなー
Microsoftが手がけろよ