WPF(.NET4.x, .NET Core) GUIプログラミング Part25

2021/02/05(金) 19:54:23.73

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

前スレ
WPF(.NET4.x, .NET Core) GUIプログラミング Part24
https://mevius.5ch.net/test/read.cgi/tech/1575862574/

関連スレ
Windows 10 UWPアプリ開発 Part 2
http://mevius.2ch.net/test/read.cgi/tech/1499658092/

コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2021/05/25(火) 21:44:25.98

nugetの表示が遅いのも謎なんだな

2021/05/25(火) 21:47:45.58

VSCode使えよ

2021/05/25(火) 21:48:46.03

WPFは遅くないとか言ってる馬鹿が開発してるのだろう。

2021/05/25(火) 22:05:45.12

dotnet new

2021/05/26(水) 05:49:33.92

「Microsoft Build of OpenJDK」が一般公開

2021/05/26(水) 07:16:45.72

WMIも遅いしな

2021/05/26(水) 07:44:21.96

>>674
死ね

2021/05/26(水) 12:31:40.10

WPFは、RIA(Rich Internet Application)と関連深かったらしく、
Silverlight は、WPF/E と呼ばれていたらしい。
この意味で WPFが、MVVMを推奨したり、Web系の HTML+JSでプログラミング
する作法に似るのは当然かも知れない。
また、XAMLは、画面をデザインするデザイナーとプログラミングをする
プログラマーが共同作業を行うときに有利だとされていたらしい。

2021/05/26(水) 17:59:23.57

備忘録？
メモ帳と間違えたのかな？

2021/05/26(水) 18:04:22.56

リッチなWPFだけど、内部でWebの様なレンダリングをしてるのだろうか

2021/05/26(水) 18:26:26.83

XAMLを解するデザイナーなんて存在しない。
XAMLはプログラマーが手打ちで作るもの。

2021/05/26(水) 18:36:05.26

https://forest.watch.impress.co.jp/docs/news/1327091.html
mauiもまぁ失敗するだろう

2021/05/26(水) 19:33:48.31

XAMLでなんでもやろうとするよりレイアウトだけやって他はコメントいっぱい書かかせておくのが一番
でもコメントも書きずらいからやっぱり糞

2021/05/26(水) 21:44:17.87

>>678
ここはもうその人のチラ裏なんだよ

2021/05/26(水) 22:01:01.85

長文の人ずっといるのにまだ理解してないんだな。

2021/05/26(水) 23:41:00.89

NG推奨

2021/05/27(木) 14:28:39.62

ずっといるというか、糖質は適切に治療しないとずっと寛解しないからな

2021/05/27(木) 17:16:23.55

16.10.0のプロパティ簡単設定機能はXAML直書きの苦行から少しは解放されるん？

2021/05/28(金) 12:15:53.81

むしろXAML直書きを支援する機能を充実させてほしい

2021/05/28(金) 12:45:21.22

bindにインテリセンス効かせて欲しい

2021/05/28(金) 13:46:22.80

UWPとWIｎUI3のx:Bindはインテリセンスが効く

別件だがVSのオプションで
>テキストエディタ＞C#＞IntelliSenseで「インポートされていない名前空間の項目を表示する」を設定すると
using していないクラスもインテリセンスの候補で出てくるようになっています

2021/05/28(金) 20:51:48.31

>>688
コードビハインド書けるだろーが。

2021/05/28(金) 21:28:27.68

コードビハインドでUI記述したらWPF使う意味がない。
XAMLは画面プレビュー見なくてもそれだけで画面の構造・イメージが把握できるのがメリット。

2021/05/29(土) 03:05:07.31

>>692
XAML直書きってそういう意味の事か。
勘違いした。

2021/05/29(土) 22:34:26.11

xamlってstyleやtrigger使うとかなり階層が深くなりがちなんですけどよい解消法はありますか？

あとは深いところでちょっとだけ違うものを短く書けないかなと

似たような山が3つとか並ぶと不快です

2021/05/29(土) 23:57:41.52

そういうのはできない
XAMLの致命的とも言える大弱点

2021/05/30(日) 04:23:54.80

それはXAMLの問題ではない。
お前の問題。
普通にコードビハインドで書けばいい。

2021/05/30(日) 05:22:02.09

だよねぇ。
ペアレントを数段階遡ってサーチしDatacontext設定やってんじゃねぇ、、、　と言いたい。
ビハインド一発。

2021/05/30(日) 08:09:01.61

Styleはコードビハインド無理だろ
ResouceDictionaryで分離するくらいしか手がない

2021/05/30(日) 09:59:36.82

Resourceに切り出せば階層の深さも限定的だと思うけどね。
特定のコントロールにベタ書きしているんであればそのコントロール自体をUserControlに切り出すとか。

2021/05/30(日) 11:23:06.69

お前らもgridの設計書はexcelで作ってるの？

2021/05/30(日) 11:44:04.57

そういう後日全く役に立たない成果物という代物は整理できないものなんだろうか
この仕事が生まれてからの永遠の課題だが

2021/05/30(日) 12:58:29.27

人足仕事で案件取ってくる営業からしたら一粒で二度おいしいだろ

2021/05/30(日) 16:12:30.07

>>700
そんな資料が必要な時点で作りが悪い可能性。
普通は上手に部品化してGridとStackPanelを使っていけば
見りゃわかるレベルで構造が綺麗になるもんだけどな。

2021/05/30(日) 17:22:11.21

>>698
コントロール自作するレベルは
最初からmvvmとかつかってない。
まず遅すぎて使えない。
XAMLの美味しいとこTemplateやStyle使っても
コードビハインドから十分かける。

2021/05/30(日) 19:00:27.12

作り方が下手くそなだけなんじゃ・・・

2021/05/30(日) 19:24:27.06

>>705
誰にいってんのかな？

ちなみに複合コントロール(データグリッドとかガントチャート)とかの内部実装はそんなもんです。

それに、WPFのコントロールの開発者のほとんどは、
WinFormsのコントロールの開発者でもありますよ。

2021/05/30(日) 19:31:51.55

>誰にいってんのかな？

一人しかいないでしょう。

ちなみにプロジェクトの規則でWinForms禁止や、
発注側が（質の低い技術者を振るい落すために）WinForms禁止を指定してくることもあるよ。

2021/05/30(日) 19:34:46.09

見た目こだわらないならWinFormsでいいんじゃないの？

2021/05/30(日) 19:36:22.03

>>707
意味も理解できてないようだね。

2021/05/30(日) 21:24:30.95

見た目のカスタマイズに限った話だけど、
コードビハインドだと標準の挙動で上書きされて思い通りに動かないことがある
じゃあXAMLスタイルを部分的に入れ替えて作ろう、てやってると
段々>>694の状態になっていく
コードビハインドだけで解決できる世界じゃ無いんだよ

2021/05/30(日) 21:27:39.68

>>708
見た目こだわらなくても開発生産性や品質上げたいならWPF使うでしょ。

2021/05/30(日) 22:36:18.55

なるほど
世間では生産性や品質はMSが考えるほど重視されなかったのか
参考になる

2021/05/31(月) 05:56:53.59

>>711
ウケるww　キミ笑いの天才だよw

2021/05/31(月) 06:40:11.53

>>713
ああ、働いたことないのね

2021/05/31(月) 06:50:12.73

>>714
技術者です。MSのサポートを何度も利用してますがいつもインシデントを消費できません!!!

wwwww

2021/05/31(月) 09:51:36.96

>MSが考えるほど重視されない

むしろ「MSに期待してない」

本気で考えたらMSの製品なんて採用しない

2021/05/31(月) 19:44:30.23

横からだけど

生産性を高めるには標準コンポーネントをさらっと使えたほうが楽だからwinformの勝ちだと思うけど

2021/06/01(火) 00:27:28.76

仕様によるわな
レイアウトは崩れてもいい、という仕様ならwinformの方が工数は少ない

2021/06/01(火) 00:30:07.02

普通に作るとWPFでも崩れるよ

デスクトップでまともに表示されてもタブレットに移すとボタンが画面を占拠したりする

2021/06/01(火) 00:37:47.40

画面の解像度が同じでもdpiなどが違う場合を考慮しないと簡単に操作不能になる

2021/06/01(火) 00:43:20.58

>>719
そういう話ではなく、どちらが生産性が高いかという話だよ
当たり前だけど、そんなの仕様による

ウィンドウが小さくなったときにどう表示するかも、その仕様のひとつでしょ
スクロールバーをつけるのか、全体を縮小表示にするのか、コントロール自体を少なくするのか
または、小さいウィンドウはサポート対象外とするか

2021/06/01(火) 00:52:24.63

勘違いしてるようだけどwindowは小さくなってない
実際の画面が小さくてdpiは高くなってるけど文字とかが大きくなってるからボタンが占拠してるんだろう

やっぱりwinformsのほうが生産性が高い

2021/06/01(火) 01:06:46.93

そんなの当たり前、WPF使ってもレイアウト崩れるようにつくれるし

アダプティブにレイアウトが崩れないようにつくりやすいのはWPFで、こっちの方が生産性が高い

2021/06/01(火) 12:09:53.23

WinFormsはMFCと似ているが、WPFは作法が違いすぎる感じがする。
WPFはHtml+JSベースのアプリに似ている。

2021/06/01(火) 12:11:25.66

ただ、WinFormsもイベントハンドラの書き方がVBと似ている。
基本的にグローバル関数の様な関数でイベントを受けるところとか。
MFCは、イベントを受けるクラス毎に好きに選べる。

2021/06/01(火) 12:11:54.18

>>725
誤: MFCは、イベントを受けるクラス毎に好きに選べる。
正: MFCは、イベントを受けるクラスを好きに選べる。

2021/06/01(火) 12:14:22.03

>>717
いや、使い捨てのプログラムですらWPFのが楽だわ。

>>719
WPFの普通の作り方は
コントロールに幅や高さ、位置を指定しないでレイアウトコンテナーに流し込む
というものだけど、ちゃんとやってる？
普通の作り方していれば画面崩れなんてまず起きないよ。

2021/06/01(火) 12:32:58.68

MVVM必須にするならWinFormの方が初心者には優しいし、MVVM使わないならどっちでも大して難易度変わらないだろ。

2021/06/01(火) 12:44:34.81

WinFormでもMVVMで作ることは可能。自分はやらないけど。

2021/06/01(火) 18:45:36.84

>>727
いやいやそういうのだけでうまく行くなんて思うなよｗ

縦にボタンをスタックしてdpi高いデバイスに移ったら
ボタンがデカくなって下の方のボタンがはみ出るｗ

2021/06/01(火) 18:55:45.61

>>730
まさかとは思うが、ウィンドウサイズ固定なんて初心者丸出しの作りしてないよな？

2021/06/01(火) 19:14:27.86

もう馬鹿は黙ってた方がいいんじゃないか？
恥の上塗りだけど？

2021/06/01(火) 19:17:32.37

同じ解像度でも

PCだと全画面表示で縦にボタンが10個表示できたとしてタブレットだと縦に6個ぐらいしか表示されないと言うことがありうる

例えウィンドウサイズが変更できたとして何ができるんだ？

2021/06/01(火) 19:24:07.59

ウイドウサイズ固定ガー　レイアウトガー　DPIガー

WPFスレってずっとしょうもない話ばかりしてるよな。フレームワークが糞すぎて
PGとデザイナーの分離とか言う理想以前のレベルにまで落ちてしまった。

まあ、日本語でLinux使うとボタンが画面の外に出て押せないとかしょっちゅうだけどなw

2021/06/01(火) 19:37:25.73

>>733
スケーリング倍率の違いを考慮せずにPCの画面いっぱいにデザインして
FlowLayoutにするとかViewBoxやScrollViewerを使うとか何も対策しなきゃそうなるだろうな

OSのスケーリング倍率設定を無視して表示したければマニフェストを編集すれば簡単に出来るよ

2021/06/01(火) 19:38:08.23

>>733
最終兵器のViewBoxというものが有るよ

2021/06/01(火) 19:43:14.80

ViewBoxつかうのは下の下だろｗ
本当に使ったことがあるのか？

2021/06/01(火) 19:45:33.08

>>733
>PCだと全画面表示で縦にボタンが10個表示できたとして

えーと、ウィンドウサイズを小さくしたらボタンが隠れて使えなくなるような酷い作りって事？
VGAぐらいまで縮めても使えるように作るでしょ普通。

2021/06/01(火) 19:53:03.17

>>730
StackLayoutをScrollViewerでラップするだろうに
大丈夫か君??

2021/06/01(火) 19:53:21.20

＞ WPFの普通の作り方は
＞コントロールに幅や高さ、位置を指定しないでレイアウトコンテナーに流し込む
＞というものだけど、ちゃんとやってる？
＞普通の作り方していれば画面崩れなんてまず起きないよ。

からの～
↓

＞えーと、ウィンドウサイズを小さくしたらボタンが隠れて使えなくなるような酷い作りって事？
＞ VGAぐらいまで縮めても使えるように作るでしょ普通。

2021/06/01(火) 19:54:38.31

お前らの言う普通てなんだよとｗ
そんなもん考慮しないで作っても使えるようになれば楽なんだ

2021/06/01(火) 19:59:00.64

普通に今時アプリ作るなら、
StackLayoutをScrollViewerでラップするけど
特に設定画面とかほとんどそうするが

2021/06/01(火) 20:01:30.38

鼻くそほじりながら普通に作るアプリの要素をいちいちScrollViewerでラップしてるのか？
関心だねｗ

2021/06/01(火) 20:01:53.66

>>737
何で下の下なの？

2021/06/01(火) 20:04:07.21

これではWPFは欠陥品と言われて当然だな

2021/06/01(火) 20:04:07.93

>>744
本当の意味での本来のレイアウトと違う結果になるから
それとかなり強めの副作用が出る

2021/06/01(火) 20:05:22.76

そもそも極端にスケーリング倍率が異なるモニターに映して
どのような動作になるのがお好みなのかさっぱり分からんぞ

2021/06/01(火) 20:06:34.33

今度は鼻くそほじりながら作るとかアプリの種類もピンキリだがアプリの種類を極端なほうに持ってこうとしてて草

2021/06/01(火) 20:10:47.71

例えば地図の経路を編集できるアプリがあってデスクトップでは片側に縦に操作ボタンが並んでたとする
タブレットではタッチで操作できるからタブレットにそのまま移してみた

ボタンが画面の半分を占めてしまったりしたらどう思う？
しかも下の方のボタンを表示するにはサイズ変更やスクロールしないといけない
同じ割合で表示されていたらと思うが他の人は違うのかな？
だったら知らんけど

2021/06/01(火) 20:17:55.30

ん?話ずれてねぇか??

特定のレイアウトが使いづらいとかただのUIの話してるの??

アダプティブなレイアウトをWPFとWinFormsで作るならどっちが生産性が高いかの話だろ??

2021/06/01(火) 20:18:35.40

趣味でしか使ってないけどWPFは欠陥品でいいと思う
無駄にややこしいし

2021/06/01(火) 20:20:04.30

WPFとかWinFormsとかもはや関係なくてDPIスケーリングとUIデザインの話になってるな

>>749
>>735に書いたけど、スケーリングしないようにすれば?

2021/06/01(火) 20:21:44.36

>>750
えっ
いつから話をそらし始めたのかな？
つかさ初めからそんな話はしてない

>>740みたいなのか君も？

2021/06/01(火) 20:21:55.69

>>740
うん。
その通りに作ってればウィンドウサイズを広げても縮めてもちゃんと使えるようになってるはずだよ。

>>741
Gridで領域を区切ってその中にそれぞれScrollViewerとStackPanelをはめ込む。
これが基本。

2021/06/01(火) 20:23:18.00

病気なのか
そこに書いてある通りで上のようになるんだがｗ

2021/06/01(火) 20:24:15.15

ターゲットモニタを顧客と仕様で決められない無能SEの話でしかない。
WEBアプリ開発とかでIT音痴の顧客に、すべてのOS、ブラウザ、バージョンで動くようにしろと言われて
無理ですと答えられないアホSEだったのだろう。その手のデスマーチは何度も見てきた。

2021/06/01(火) 20:26:15.44

>>752
だよな
完全に話の中身というか論点変わってるよな

2021/06/01(火) 20:29:38.25

Aさん Gridの領域を区切って～と作ればちゃんと使える
Bさんアダプティブなレイアウトが作りやすいだけでちゃんと使えるように作る必要がある
CさんすべてのOS～で作れるようにはならん仕様が決められていない！

で？と言いたくなる

2021/06/01(火) 20:33:14.75

俺はそもそもがこれだけ言ってただけなのに仕様とか言い出すんだから困るな
同じところを勝手にお前らが堂々巡りしてる
AさんBさんCさんの意見は似てるようで似ていない

719 名前：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr8d-6ypv)[sage] 投稿日：2021/06/01(火) 00:30:07.02 ID:LVmbfPywr [1/3]
普通に作るとWPFでも崩れるよ

デスクトップでまともに表示されてもタブレットに移すとボタンが画面を占拠したりする

720 名前：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr8d-6ypv)[sage] 投稿日：2021/06/01(火) 00:37:47.40 ID:LVmbfPywr [2/3]
画面の解像度が同じでもdpiなどが違う場合を考慮しないと簡単に操作不能になる

2021/06/01(火) 20:52:37.89

ウィンドウサイズを縮小するとレイアウトが崩れるしょぽい作りのアプリが
DPIスケーリングで相対的にウィンドウサイズが縮小された場合にも
同じようにレイアウトが崩れるってだけの話だな

2021/06/01(火) 21:40:41.20

>>749
それが気になるならViewBOｘでパネルごと自動で縮小すりゃいいじゃないか
つうか、もしかしてViewBoxを他のものと勘違いしていないか？

2021/06/01(火) 21:48:42.01

無限のフィールドにどんとおいちゃうViewBox

非常に使いどころが難しい
今のやつ程度なら様子見ながら使ってもいいけど普通は使わない
あらかじめそうなるとかそうしないとどうにもならない場合でしか使わない

副作用が大きすぎるから他と絡めて使う場合普通は避けて通るのが吉だろう

2021/06/01(火) 22:02:03.20

>>746
どんな副作用よ

2021/06/02(水) 09:33:14.03

>無限のフィールドにどんとおいちゃうViewBox
どうみてもScrollViewerに対する表現だよな
WPFに関しては初心者同然でViewBoxが何かを知らない人が喚いているだけ

2021/06/02(水) 09:48:42.22

ViewBoxは画像として伸縮させてるだけだから、
スケール合わないとすぐ滲むよ

2021/06/02(水) 10:09:47.82

どんどん盛り上がてくれ
WPFのノウハウをどんどん吸収するからさ

2021/06/02(水) 13:10:52.49

レイアウトが崩れるというどうでもいい話しかしてない

**デフォルトの名無しさん** (JP 0H6b-Q5Kp) · 2021/06/02(水) 14:01:43.63

>>767
他の事に注力したいのはやまやまだがクリアしとかなきゃならない課題だ。
winformだと本当に地獄だから。

2021/06/02(水) 15:07:37.29

>>767
案件によってはどうでも良くない
レイアウトが崩れて「実行」ボタンが押せないとかw

2021/06/02(水) 16:42:44.84

>>756
程度による。
本来制限する必要のないことを技術選定ミスや設計ミス、技術力不足のせいで制限かけて客に押し付けるのは無能。