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

**デフォルトの名無しさん** · 2021/09/19(日) 18:43:39.82

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

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

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

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

**デフォルトの名無しさん** · 2021/09/24(金) 08:52:21.18

WebViewだろうね
WPFを使う意味があるかはともかく

**デフォルトの名無しさん** · 2021/09/24(金) 09:53:30.84

WebView2？

**デフォルトの名無しさん** · 2021/09/24(金) 10:49:48.03

>>8
https://qiita.com/marksard/items/24163ca605dc95556016
VLCのコントロールが使える模様
俺は試していないが頑張れ

**デフォルトの名無しさん** · 2021/09/24(金) 12:38:31.07

>>11
結局VLCにしたんだけどMediaUriElementで出来ていたパラメータのbindingが出来なくて結構変更することになった
なんで使いやすいプレイヤ知ってたら教えて貰おうかと

**デフォルトの名無しさん** · 2021/09/25(土) 00:57:31.87

WPF-MediaKitもVlc.DotNetも古くてLibVLCSharpが推奨なのでは、知らんけど
https://code.videolan.org/mfkl/libvlcsharp-samples

**デフォルトの名無しさん** · 2021/09/25(土) 12:26:26.31

>>13
ほー使ったことないな
今度なんかあったら試してみる

**デフォルトの名無しさん** · 2021/09/26(日) 00:59:05.90

WinUI3まだー？

**デフォルトの名無しさん** · 2021/09/27(月) 12:55:19.28

drawingContext.DrawLine(new Pen(Brushes.Black), 1), new Point(0, 0), new Point(0, 100));
drawingContext.DrawRectangleBrushes.Blacknull, new Rect(0, 0, 1, 100));

この二つって全く同じ個所に縦線引かれると思ったらDrawLineの方が左に1づれるんだけど仕様？

**デフォルトの名無しさん** · 2021/09/27(月) 14:17:54.92

DrawLineとDrawRectangleの差じゃなくてBrushとPenの差か
DrawLineのBrush版があればなぁ

**デフォルトの名無しさん** · 2021/09/27(月) 16:08:58.41

それはwindows系であるRectangleの仕様
Rectangleの場合、下、右は含まれない

**デフォルトの名無しさん** · 2021/09/27(月) 16:13:11.14

厳密には知らんがそんな感じだと思った*

**デフォルトの名無しさん** · 2021/09/27(月) 16:21:02.35

>>18
いや、DrawRectangle同士でも

DrawRectangle(Brushes.Black, null, new Rect(0, 0, 1, 100));
DrawRectangle(null, new Pen(Brushes.Red, 1), new Rect(0, 0, 0, 100));

こうするとそもそもxの起点位置が違うんよ
下の赤線の方が1つ左にズレて-1位置に描かれる

**デフォルトの名無しさん** · 2021/09/27(月) 17:35:29.70

今のwinui、バインド関連のバグ多くない？
せっかくなら新しいの覚えながらやりたいと思ってwinuiで作ってたけど、使用に耐えるものを作れそうにない
UI部分wpfに差し替えようかな

素人がプレビュー版なんて使うんじゃなかったわ自分じゃどうにも改善できねえ

**デフォルトの名無しさん** · 2021/09/27(月) 18:37:11.61

>>20
そうなんだごめんよ
>>21
でも、WPFにすると見た目がダサくならんか??
WPFにすると見た目がダサくなるが安定
WinUI3にすると見た目がおしゃれだが、ちょっと不安定

**デフォルトの名無しさん** · 2021/09/27(月) 18:39:27.60

まぁ、WinUIとか定期的に更新してくれるからバグ報告すりゃそのうち直る可能性高いけど、ユーザー少ないからバグを自分で踏んで報告する羽目になる..

**デフォルトの名無しさん** · 2021/09/27(月) 19:12:05.92

>>22
modernWpfUI使えば大体似た見た目にはできるから、もういいかなって

**デフォルトの名無しさん** · 2021/09/27(月) 19:25:35.38

21です（23も俺）

過去にWinFormで作ったソフトをWinUIで再構築しようとしてたんだけど、新しいことやってみたい気持ちだけでWinUI使ってた
正直今背伸びしてまで使うメリットが自分には見えないんだよなー

WinForm→WinUIも
WinForm→WPFも
ユーザー目線だとそんな変わんないんじゃねって思う（WPFはUIのライブラリ使って現代風の見た目にすれば）

**デフォルトの名無しさん** · 2021/09/27(月) 19:26:44.43

ごめん21,24,25が俺ね
どうでもいいことで連投すまん

**デフォルトの名無しさん** · 2021/09/27(月) 20:38:54.92

>>24
俺もmodernwpf 使ってたけど、win11スタイルはまだだし
NavigationViewとか階層メニューまだっぽいし
やっぱ、個人じゃきついよなーとか

**デフォルトの名無しさん** · 2021/09/27(月) 20:42:51.67

WPF+ModernWPF
と
WinUI
で似たアプリ２つ同時に作りながらやってるわ
最終的にWinUI一本に絞ると思うけど

**デフォルトの名無しさん** · 2021/09/27(月) 20:54:34.65

> ユーザー目線だとそんな変わんないんじゃねって思う（WPFはUIのライブラリ使って現代風の見た目にすれば）

たぶん、そうだと思うけど(とりあえず、ライトとダークあれば)

俺はそこだけは変にこだわってるから

ちょうど数時間前もWPF+ModernWPFで、CommandBarじゃなくてWPFのToolbar使いたくてでもModernWPFでToolbarはスタイリングされないから頭抱えてた

まぁ、自分でスタイリングする能力ないんで..

**デフォルトの名無しさん** · 2021/09/27(月) 22:47:47.96

>>26
1.0 Preview1も駄目？

**デフォルトの名無しさん** · 2021/09/28(火) 06:42:23.50

>>30
あー、もうそんなの出てたんだね
そういえばgithubのバグ報告のページで「1.0.0でも起こるけどまだ直ってないんか？」みたいなコメントしてた人いたわ見たときはなんのことだと思ったけど

だめっぽいけど一応試してみるかー

**デフォルトの名無しさん** · 2021/09/28(火) 12:37:34.11

>>25

>WinForm→WPFも
>ユーザー目線だとそんな変わんないんじゃ

開発者目線だとWPFのが作るのが楽（MVVM、非MVVM関係なく）だからWPF使ってる。
受け入れられやすいようにWinFormっぽい見た目に変えてる。

**デフォルトの名無しさん** · 2021/09/29(水) 08:28:02.15

悲報、WinUI3、ウィンドウのHeight, Widthプロパティ無し

ウィンドウサイズに依存したWinFormみたいな糞アプリを作れなくなるからこれはこれでいいのかも。
いやでも初期サイズぐらいは設定したい。ウィンドウサイズ固定はできなくていいけど。

**デフォルトの名無しさん** · 2021/09/29(水) 08:54:21.60

MinWidthとかもないのかな？

**デフォルトの名無しさん** · 2021/09/29(水) 09:38:32.22

前回のウィンドウ位置・サイズ・位置を記憶しておいてほしいって要望は結構あるからなー。
PInvokeでなんとかなるんだろうか。

**デフォルトの名無しさん** · 2021/09/29(水) 09:44:24.58

ライブラリはあるからそれで我慢するしかなさそう
https://github.com/dotMorten/WinUIEx/

**デフォルトの名無しさん** · 2021/09/29(水) 10:33:25.99

>>33
いちおうサイズや最大最小ボタンの無効化とかを設定できるAPIがある
実際俺が作りかけてるソフトでも初期ウインドウサイズだけ変えてるけど問題なく使えてる
今ちょっと名前は忘れたんだけど、API紹介してるマイクロソフトのページを見ながら実装したと記憶してるので、探せばでてくると思うよ

正直標準でついててほしいけどなあ

**デフォルトの名無しさん** · 2021/09/29(水) 10:34:57.02

俺が使ったのは>>36のと違うやつだけど、36のほうが使いやすそう

**デフォルトの名無しさん** · 2021/09/29(水) 13:31:20.42

winui 0.8で作ったやつそういやはじめてnull許容参照型有効にしてみたんだけど、コンパイルエラーでなく警告しかでないの?

null非許容参照型にnullf代入できちまうわ

**デフォルトの名無しさん** · 2021/09/29(水) 13:50:46.96

これかな
https://github.com/dotnet/msbuild/issues/6088

**デフォルトの名無しさん** · 2021/09/29(水) 14:34:19.08

違うかも、元々警告だった気がする。
エラーだと影響でかすぎるから。

**デフォルトの名無しさん** · 2021/09/29(水) 17:03:33.12

初期サイズこそOSに任せたほうがよくないか

**デフォルトの名無しさん** · 2021/09/29(水) 18:59:25.74

警告をエラーにするオプションは？

**デフォルトの名無しさん** · 2021/09/29(水) 20:58:16.79

winuiいまいちだな・・・

**デフォルトの名無しさん** · 2021/09/29(水) 22:03:25.40

>>44
3世代目で使い物になるのがMSのお約束

**デフォルトの名無しさん** · 2021/09/30(木) 00:17:53.55

使えるようになる頃にオワコンと言われるMS……

**デフォルトの名無しさん** · 2021/09/30(木) 00:25:47.23

WinUIは3やで

**デフォルトの名無しさん** · 2021/09/30(木) 06:03:19.53

実質WinUI 3(Windiows App SDK 1.0)がバージョン1だから。
まだストアアプリ臭が抜けてなくて、デスクトップアプリとして見ると
「は？こんなこともできないの？」ってレベル。

**デフォルトの名無しさん** · 2021/09/30(木) 07:55:01.00

使えるうんぬんより、マイクロソフトがストアで商売したがってるイメージ
また変なの考案するより鍵屋した方が手っ取り早いのに

**デフォルトの名無しさん** · 2021/09/30(木) 14:07:51.32

ストアはもう諦めてるだろ
諦めてるから開放した

**デフォルトの名無しさん** · 2021/09/30(木) 19:46:10.00

てかもうMS自身が自社フレームワーク諦めてElectronとか利用してんじゃん

**デフォルトの名無しさん** · 2021/09/30(木) 20:07:27.48

新Teamsからはelectron脱却してWebView2行くんでは？

**デフォルトの名無しさん** · 2021/09/30(木) 20:21:22.07

でも、一部のクロスプラットホームアプリだけだろ??
電卓に始まってペイントやらフォトビューワとかもろもろはelectronとか使ってないだろ??

**デフォルトの名無しさん** · 2021/09/30(木) 20:26:42.56

もうos周りのアプリだけだろうね
一般のアプリは、
Webかスマホかに二分される時代だし

**デフォルトの名無しさん** · 2021/09/30(木) 20:28:19.61

まぁ、xamarin(maui)はMicrosoftも諦めてて、microsoftの他の部門であえてこれらを使わないと思うが

**デフォルトの名無しさん** · 2021/10/01(金) 10:43:29.25

MAUI(＝Xamarin)使うぐらいなら普通はFlutter使うわな

**デフォルトの名無しさん** · 2021/10/01(金) 15:27:55.77

そうなの？

**デフォルトの名無しさん** · 2021/10/01(金) 15:58:19.68

VisualTreeHelperというのがありますが、
勉強する価値があるかないか、そしてその理由を教えて下さい。

Visual StudioのXAMLエディターでツリーが見れるようになったので、
今は無用の長物でしょうか？

**デフォルトの名無しさん** · 2021/10/01(金) 16:27:12.58

アプリって言うと
昔はデスクトップアプリを指してたんだけど、
今じゃスマホのアプリの事だもんな

さらにwindows11で
アンドロイドアプリがPCで動くようになると、
もう価値がなくなるんでは無かろうか？

**デフォルトの名無しさん** · 2021/10/01(金) 17:03:56.46

Microsoftがスマホでも勝者になってる世界線にいたら、今はみんなxaml使ってたのだろうか　ガクブル

**デフォルトの名無しさん** · 2021/10/01(金) 17:08:46.75

>>60
Androidも画面定義はXMLだから似たようなもんだよ

**デフォルトの名無しさん** · 2021/10/01(金) 17:18:42.15

>>59
自分へのレスですか？

**デフォルトの名無しさん** · 2021/10/01(金) 17:19:52.97

android系では去年からもうflutterでコードベースの宣言的UIやってるし、android/kotlinでもjetpack compose使い始めたし、今年に入ってからxml一切触ってねぇわ

**デフォルトの名無しさん** · 2021/10/01(金) 17:31:51.92

他は進化してるのに、今年正式にリリースされるUIフレームワークでもまだxaml??
絶望だろ
cometは実用になってるのか知らんが

つか、avalonia UIとUnoPlatformとか、Microsoftがしっかり方向性示さなかったからみんなで戦力分散してみんなで自滅してるよな..

**デフォルトの名無しさん** · 2021/10/01(金) 19:19:18.74

UIをXMLで記述するのは筋は良いよ。
ただツール側が大変。
だからXML止めたところは単なる妥協。

**デフォルトの名無しさん** · 2021/10/01(金) 19:24:01.74

逆だよ。XMLの方がツールは作りやすい。
でも頑張って高機能なツールを用意するより、手書きの負荷を下げてツールは最低限プレビューするだけの方が、
開発者にとってもツール側にとっても楽であることに業界が気付き始めた

**デフォルトの名無しさん** · 2021/10/01(金) 20:09:22.18

CSSのほうが次元が違うぐらい凄いぞ
XAMLじゃマシなUIは作れん
画像はるしか方法がない
そするとアニメーション出来ないけど...

**デフォルトの名無しさん** · 2021/10/01(金) 20:23:02.15

もうFlutterでよくね？

**デフォルトの名無しさん** · 2021/10/01(金) 20:28:56.74

XAMLはWYSIWYGなツールで編集することを大前提として設計されている上、GUIフレームワークのオブジェクトモデルの設計にも引っ張られるから、
処理系として出力だけしか考慮しなくていいCSSと比較するとどうしても記述性や表現力の面では劣る

**デフォルトの名無しさん** · 2021/10/01(金) 20:36:30.93

コードで書く宣言的UI方が100倍楽
普通にコードを書く延長線上でいけるし、if文使って切り替えたり、for文でループ回したり簡単に自由自在

xamlでやろうとするとコードビハインドもできるがMVVMぎちぎちに要求されるからうざいわ
ValueConverterやらTriggerやらVisualStateManagerやら色んな概念でてきていったりきたり

**デフォルトの名無しさん** · 2021/10/01(金) 21:02:00.88

MSがツール作るの得意すぎたせいで、みんなWYSIWYGなツールを使ってUIを作ることが当然で開発効率も良いと思い込まされてきたんだよ
ここにいるのはその最後の残党で、彼らは既にXAMLを手書きした方が早いと気付いているにも関わらず、
未だにツールの都合に合わせて面倒なXMLを記述しなければならないという矛盾には気付いていないんだ
もうちょっとだから優しい目で見守ってやってくれ

**デフォルトの名無しさん** · 2021/10/01(金) 21:15:45.36

可変レイアウトを前提とするかが分かれ道な気がする

**デフォルトの名無しさん** · 2021/10/01(金) 21:21:42.73

WinFormはポトペタに頼るけどWPFはWISYWIGといっても確認用くらいしか使わんなあ
慣れればXAMLべた書きでほぼ思い通りのレイアウトできるし

**デフォルトの名無しさん** · 2021/10/01(金) 23:09:37.93

>if文使って切り替えたり、for文でループ回したり簡単に自由自在

それ宣言的って言わんw

**デフォルトの名無しさん** · 2021/10/01(金) 23:17:07.18

>>74
バインディング脳だとそう思うよね
Reactとかやってみればわかるけど、データの流れが単方向になっているならちゃんと宣言的なんだよなあこれが

**デフォルトの名無しさん** · 2021/10/01(金) 23:33:34.54

>データの流れが単方向になっているならちゃんと宣言的なんだよなあこれが

「宣言的」の定義が捻じ曲がってる気がする

**デフォルトの名無しさん** · 2021/10/01(金) 23:40:23.81

今時の宣言的は違うだろ
画面更新において宣言的に書けるから宣言的なんだよ

**デフォルトの名無しさん** · 2021/10/01(金) 23:45:58.73

for文、if文とか入ろうが、それらはある一瞬のUIを記述してるから宣言的なんだよ

if文、for文で、前のUIの状態を変更してる訳じゃないんだよ

**デフォルトの名無しさん** · 2021/10/01(金) 23:46:26.37

>>76
宣言的UI、でググってみ
君の思ってるfor使ったら宣言的じゃないとかいうのは表面的なコーディングスタイルの問題でしかなくて、気に入らないならLINQ使うとかやりようはいくらでもある
UIでいう「宣言的」ってのは、画面がどうあるべきかというのを宣言したら自動的にそのようになるってこと
それがWPFではXAMLであり、React等ではコードによって生成された仮想DOMであるというわけだ

**デフォルトの名無しさん** · 2021/10/01(金) 23:59:18.68

いや全く分からん

**デフォルトの名無しさん** · 2021/10/02(土) 00:06:30.03

https://maku77.github.io/android/fw/compose.html

この最初のセクションのボタンの例を読んでみよう

**デフォルトの名無しさん** · 2021/10/02(土) 00:33:48.60

宣言的UI　この状態のときはこんな画面になるということ記述していくスタイル
if文とかfor文とか使う、使わないとか重要じゃない

というかif文,for文とかその他類似のもの使わないと宣言的UIで画面更新できん

**デフォルトの名無しさん** · 2021/10/02(土) 00:56:36.82

ifとかforとかがSGMLの中に出てくるのって美しくないから個人的には好かん
JSPとか最悪だったし

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

xamlも同じ
xamlでこの状態のときにこういうUIになるってxmlで記述してるよね
更にこれが進化して
この状態のときにこういうUIになるってifやforなどのプログラムコードで記述してるのが最新の宣言的UI

馴染みのプログラムコードで書けるから楽

制御構文をもたないxmlのようなものでUIを記述するのが宣言的UIというのは昔の話?

**デフォルトの名無しさん** · 2021/10/02(土) 02:26:37.11

XAMLでWYSIWYG使うって君WPF使ったことないでしょ

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

むしろ宣言的でないUI定義ってのを教えてくれ

**デフォルトの名無しさん** · 2021/10/02(土) 05:29:37.06

UI部にif文書くか？
ロジックが入ると面倒だから、渡されたpropsをそのまま代入しない？

**デフォルトの名無しさん** · 2021/10/02(土) 06:26:11.63

XAMLがいいからWPF使ってるんだよな

**デフォルトの名無しさん** · 2021/10/02(土) 09:22:51.66

>>66
IDEの開発元がXMLよりコードでUI書く形式の方がIDE作るのが楽だと言ってるんだが。
コードよりXMLの方が画面イメージが直感的に分かりやすいが、そのメリットはIDE開発側が楽するために捨てたいんだよ。

**デフォルトの名無しさん** · 2021/10/02(土) 09:24:55.11

>>86
WPF+MVVMの場合、宣言的なUI定義を記述する方法に関しては>>81のようなスタイルよりも宣言的といえる。コードと違い一切手続きを書いてなくて、バインディングを使った完全に静的な記述のみだからね。
じゃあ何が問題かというと、バインディングの代償としてVとVMとの結合が強くなっているために、実質的にビューが固有の状態を持ってしまっているのに近い状況になるケースが多いことだ。
たとえば>>81のボタンの例で言うと、MVVMでMの状態Aに基づいてボタンを動的に追加したいがMを直接バインドできない場合、
VMの持つコレクションを見て既にアイテムがない場合のみアイテムを追加するようなコードを書くことになる。これは明らかに宣言的ではないよね。
WPF+MVVMなら例えば変更が入るたびに毎回VMをMに基づいて新しく作ってDataContextを設定し直すようにすれば完全に宣言的にできるわけだけど、
これをやると変更の必要のないボタンまで毎回作り直しが走ってしまい、実用的ではない。
それを>>81ではフレームワーク側が自動的に差分を取って賢く画面に反映してくれるというわけ。

**デフォルトの名無しさん** · 2021/10/02(土) 09:26:25.38

>>81
・declarative（宣言的）なコード
状態 A なので、ボタンを 3 つ表示する。
・imperative（命令的）なコード
状態 A なので、ボタンを 3 つ表示する必要がある。
ただし、すでに中央のボタンを表示しているので、その左右にひとつずつボタンを追加する。

まじで意味わからんw

**デフォルトの名無しさん** · 2021/10/02(土) 09:33:52.46

>>91
>>90にも書いたけど、Mを入力としてVMを返す関数を考え、Mの更新の度に毎回VMを作り直してDataContextにセットし直すことを想像するといい
そうすることでビュー固有の状態に依存する命令的なコードを排除できる

**デフォルトの名無しさん** · 2021/10/02(土) 09:54:12.88

>>92
要するに
> 差分を取って賢く画面に反映
を誰がやるかって話なの？

**デフォルトの名無しさん** · 2021/10/02(土) 10:57:58.75

WinFormのデザイナーが吐いたコードが宣言的の良い見本

**デフォルトの名無しさん** · 2021/10/02(土) 12:22:55.97

>>91
そういう時は最初から作っておいてVisibilityで制御すんじゃないの
もうあるから追加～とか普通やらんだろ

**デフォルトの名無しさん** · 2021/10/02(土) 12:44:51.30

相変わらず本末転倒ですなあ

**デフォルトの名無しさん** · 2021/10/02(土) 13:43:37.05

>>95
それを俺に言われても困るw

**デフォルトの名無しさん** · 2021/10/02(土) 16:03:48.55

ほとんどのことはContentControl使えば動的に変更できると思う

**デフォルトの名無しさん** · 2021/10/02(土) 17:46:31.63

>>90
つまり>>78,82は間違ってるって意見ね

**デフォルトの名無しさん** · 2021/10/02(土) 17:56:52.96

このスレ、WPF、XAML知らないで語っちゃう人が居座ってるからなw
昔から知識増えてないし。

**デフォルトの名無しさん** · 2021/10/02(土) 18:42:10.72

>>90
>VMの持つコレクションを見て
WPF＋MVVMだと、VMがコレクション持たないと思うんだわ

**デフォルトの名無しさん** · 2021/10/02(土) 18:53:29.17

へぇ

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

なにかを批判する人がその批判対象のことをよくわかってないってのはよくある話。
そもそも使わんだろうしな。

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

へえ

**デフォルトの名無しさん** · 2021/10/02(土) 20:00:52.83

りゅうちぇる

**デフォルトの名無しさん** · 2021/10/02(土) 20:49:49.37

静的な記述というからStaticResourceの話かと思ったら、そんなことはなかった

**デフォルトの名無しさん** · 2021/10/03(日) 01:34:09.16

>>101
親VMが子VMのコレクションを持つことは普通にあるよ
それをItemsControlに渡す

ObservableCollectionを使って自前でやってもいいけど、ReactivePropertyのToReadOnlyReactiveCollectionを使うと楽
https://blog.okazuki.jp/entry/2015/02/15/231155

**デフォルトの名無しさん** · 2021/10/03(日) 11:13:15.32

>>103
じゃ批判するなって話だわな