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

2019/12/09(月) 12:36:14.49

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

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

関連スレ
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

2019/12/09(月) 19:14:28.20

通知領域常駐アプリ整備士
「80パーセント？冗談じゃありません。現状でアプリの性能は100パーセント出せます」

シャア
「ウィンドウは付いていない」

通知領域常駐アプリ整備士
「あんなの飾りです。偉い人にはそれがわからんのですよ」

2019/12/09(月) 19:50:30.13

>>5
ごめんどういう意味？

2019/12/09(月) 20:11:09.42

あーウゼー

2019/12/10(火) 00:36:14.25

UWPやろうや

2019/12/12(木) 20:59:06.07

どうぞ

2019/12/13(金) 04:00:46.58

>>8
Win7で動くならやってるわ

2019/12/13(金) 12:00:42.74

現行なのにWPFより過疎なUWPスレ

2019/12/13(金) 12:35:12.03

ユニバーサルデバイスがないからな

2019/12/13(金) 14:55:27.23

人脈が無いから手を出さない
https://livedoor.blogimg.jp/hihannoarashi/imgs/f/f/ff355dd9.jpg

2019/12/13(金) 16:58:51.22

WPFもWindows 7 SP1 .NET Core 3.1(LTS)の最終環境に到達したな

2019/12/13(金) 17:13:42.09

>>8
MSは、UWP から、Win32アプリの方に戻ってきていると書いている人がいた。

2019/12/13(金) 17:31:14.87

>>13
MSの取り巻きって内輪ノリが酷くてキモいんだよなあ
MS系スタックはなまじ一貫性があるから変な空気が醸成されやすい

2019/12/15(日) 00:43:16.96

結局、今 windowsのexeアプリを作る時、UIは何で作ればいいの？
wpfは機能追加全然ないし。プレースホルダー付きのテキストボックスすら無いし(追加されたらすまん)

2019/12/15(日) 00:58:47.00

https://github.com/Microsoft/Xaml-Controls-Gallery
これとか落としてみたけど、相変わらずスマホで使って欲しいのかmenu itemやボタンとかのテキストにことごとくマージンついてるし
マウスで操作したいからマージン0でいいし、表示のアニメーションも全部いらん

2019/12/15(日) 12:53:15.46

OSSが主流の時代になって各陣営はどれだけ優秀な貢献者を集められるかのがキモなんだが
windowsのGUI は全然人が集まらないので全然何も進まない

WPFはコントロールを提供するのがめんどくさいのでこれからも流行らない

2019/12/15(日) 13:16:55.46

その各陣営って、MS以外はどこ想定？

2019/12/15(日) 13:32:41.59

その他すべての陣営
react.js vue.js python PHP　ruby RonR

2019/12/15(日) 17:17:17.03

べつにWindowsデスクトップが特に好きなわけじゃないけどJavascriptは無茶苦茶嫌いなのでGUI全部がHTML5で動くような世界にはならないでほしい
MSはほどほどに頑張れ

2019/12/15(日) 18:17:50.79

vue.jsとかのjavascript系フレームワークはwpfのMVVMの影響をかなり受けてるよ。

2019/12/15(日) 18:49:53.72

そうなんだすごいね

2019/12/15(日) 21:21:15.09

>>17
楽したいならWebでやりなはれ
工数いくらでもかけられるならWPFでもUWPでも、できないことはほぼない

2019/12/15(日) 21:37:00.35

>>23
Javascriptそのものが嫌いなんだよ
MVVMであろうがなかろうがJavascript死んでも触りたくない

2019/12/15(日) 21:55:45.59

今だとUWPもWin32もWindows UI Libraryにまとめてく方針なのかねえ
まああれもﾁｶﾞｳｿｳｼﾞｬﾅｲ感凄いけど

2019/12/15(日) 22:15:01.76

同位

2019/12/15(日) 23:11:14.59

コントロールをWinUIにまとめてくれることはいいことじゃね？OSSにしてOSのアップデートと切り離して、更新とか頻繁にしてくれてるし。
少なくとも前よりマシじゃないかな。
　

2019/12/15(日) 23:34:06.18

>>17
Windows だけなら、.NET じゃないの？

web 系なら、HTML, CSS, JavaScript で、

VSCode は、Electron 製
Redmine は、Ruby on Rails

2019/12/16(月) 00:11:15.63

>>29
いかにプロダクトの思想が正しかろうが、思いつきでUIフレームワークを量産して次々に見捨てていくことこそが最低最悪の害悪

2019/12/16(月) 00:11:16.01

Blazor流行ったらいいけどセキュリティ的にActiveXの二の舞になりそう

2019/12/16(月) 00:52:30.46

>>32
昔、ネスケとMSが法廷で争ったとき、MSの懸念の1つはブラウザがOSの支配的地位を奪ってしまうことだったらしい。
ブラウザが有れば、どのOSでも同じ結果が得られてしまうため、どのOSを使っても差がなくなってしまう。
それはちょうど、WindowsOSをインストールしてしまえば、アプリ環境としては、PC-9801とPC/AT機の差がなくなってしまうので、オープン化で安くなったPC/AT
機が売れてしまったことと似ている。つまり：
・Win/Mac/Linux/iOS/Android とブラウザの関係
・PC・AT/PC-9801 と Windows の関係
に対応関係がある。
何が言いたいかというと、Blazorが普及してしまえば、Windowsが必要なくなってしまうため、MSの安定収益が1つ無くなってしまう。
そうなれば、Googleは検索エンジンが安定収益になっているのと対照的だから、Googleに負けてしまうことになる。

2019/12/16(月) 00:56:16.26

>>33
一つ考え忘れていることがあった。それは：
Blazorアプリを動かすにはWindowsは必要ないが、Blazorアプリを開発するにはWindows(またはMac?)が必要だということ。
これがあるのでBlazorの発展はMSには問題にならないかもしれない。

2019/12/16(月) 01:10:04.54

>>34
ただ、Blazorアプリの開発がWindowsでしかできなくても一般人には全く関係ないが、プログラマの数と一般人の数は、1:50 位なので、Blazorアプリの普及はWindows離れを起こす可能性はある。

2019/12/16(月) 01:11:12.58

>>35
1:50 ではなく、1:300 くらいかもしれない。

2019/12/16(月) 08:07:06.72

>>32
なぜ？

2019/12/16(月) 08:08:30.99

>>34
WindowsとMacでほぼカバーできてるだろ
別にLinuxでも開発できるし

2019/12/16(月) 10:04:54.54

BlazorをWebに乗りそこねたドットネッター達の救世主みたいに持ち上げてる人多いけど、
BlazorってReact系のプログラミングモデルでHTMLもCSSもバリバリ書くんやで
これ使える人なら普通にReactやVue使えるだろうし、単にそこに選択肢が一つ増えただけのことでしかないよ

2019/12/16(月) 12:38:30.30

>>39
javaScript書かなきゃいけない量は格段に減るっしょ。それが何より。

2019/12/16(月) 12:48:32.60

>>40
君にとってはJSを書かないことが重要なんだろうね、それを否定する気はない
・HTMLやCSSはバリバリ書ける
・しかも出来合いのJS製のコンポーネントに頼らなくても余裕なハイスキルフロントエンダー
・しかしJSやTSは絶対書きたくない
・だがC#は得意
こんな君みたいな奴がどれだけいるだろうねw

2019/12/16(月) 13:14:21.17

あとBlazorでJS書く量が減るのって、クライアントコードをC#に置き換えたからというよりは仮想DOM技術の恩恵が大きいと思うよ
Blazorが多くのドットネッターにとって革新的に感じるのは、
彼らが仮想DOM系フレームワークに始めて触れたのがBlazorだったからじゃないかな
SPAだから全部JSで書かなければならないとでも思ってるなら別だが

2019/12/16(月) 19:39:57.10

>>41
javaScript絶対書きたくないとか誰も言ってないやろ

2019/12/16(月) 20:28:50.09

Blazor に親でも殺されたんだろ
すでに拗れてるみたいだしスルーしといた方がいいよ

2019/12/16(月) 21:22:56.92

今のBlazorのプレゼンテーション層はRazorのままだから仕方がないが、Blazorに期待してる人は
WPFまで移植してくれることを夢見てるんだろう。
ClickOnceが使えなくなる前になんとかしてほしい、と俺も思う。

2019/12/16(月) 21:26:19.20

>>45
msix

2019/12/16(月) 21:49:37.96

JavaScriptは絶対悪だからな
それを根絶できるという理由でBlazorに限らずWebAsm由来言語は期待されてる

2019/12/16(月) 21:51:23.70

>>47
現状だと根絶はできないけどマシにはなるよねって感じ

2019/12/16(月) 21:53:25.47

うん根絶は言い過ぎね

2019/12/16(月) 22:58:22.69

jsに触れた途端いろんなものが腐りだす
それを正そうとしたtsですらすでに腐れがとまらない

2019/12/16(月) 23:05:42.40

WPFもjsも死にプロパティ多くない？

あ、これもあのクラスと同じプロパティあるじゃん
よし、じゃこうやってセットして・・・アレ？効かないよ？
？？？：ブブー、このクラスはそれじゃできませーん

↑作った奴、腹、切れ

2019/12/16(月) 23:55:59.55

そう思うのはお前だけかも

2019/12/17(火) 01:14:45.87

WPFのオリジナルの開発チームはとっくに全員クビにされてそう
WPFのCore移植でも作業してたのほとんど外注だったから、実際には外に丸投げしてたのかもしれないけど

2019/12/17(火) 01:25:01.50

>>52
なんでだよ
htmlもそうだけど
存在するにも関わらず死にプロパティ多すぎだろ
せめて効かないやつ削除しろや

2019/12/17(火) 01:36:41.97

いまさら効くように修正しろは無理なんだろうな。

2019/12/17(火) 06:09:29.39

>>54
継承で存在してるから消すのは無理だ

2019/12/17(火) 07:10:51.99

>>56
ダッセ

2019/12/17(火) 08:33:37.96

>>57
親の因果が子に報いって知ってるか

2019/12/17(火) 08:59:07.59

言語にそういう機能があればいいんじゃね？
って思うけどね

2019/12/21(土) 13:44:35.77

https://prismlibrary.com/docs/index.html　の　+WPF の下がほとんど空っぽなのは工事中ってことか?

2019/12/21(土) 21:17:25.11

この前まで6のドキュメント置いてあっただけだから
見出し書くていどのやる気は出たってことかなｗ

2019/12/21(土) 21:23:58.75

バカにはみえないってネタじゃないの？

2019/12/22(日) 11:49:33.83

メルヘンだね～

WPF, Prismの情報が少ないのに本家までこれじゃぁハードル高いわ

2019/12/23(月) 12:38:17.86

複数のVisualBrushで重ね塗りする方法を教えてください

2019/12/23(月) 12:44:38.80

同じ図形を重ねろ

2019/12/23(月) 12:47:40.54

VisualBrushの足し算みたいなことはできないということですかorz

2020/01/05(日) 11:21:43.18

google playにあるUno platform製の電卓アプリUIが重すぎ。xamarinと同じで絶対流行らん

2020/01/05(日) 14:51:30.39

そういう流行らんもんがいっぱい出てきて淘汰されて良いもんが出てくる
良いもんだけを出すことは不可能
だから糞が出てくること自体を否定する意味はない
業務でその糞を使えと言われないことを祈るのみ

2020/01/08(水) 06:25:42.21

ためそうかとしてたがUno重いのか……
まぁいらってみるか

2020/01/12(日) 21:53:57.39

みんないつかは、Brazorに行ってしまうん？　WPF捨てて

2020/01/12(日) 22:41:13.37

WPFよりBlazorのほうが未来あるしそうなったほうがいい

2020/01/12(日) 22:52:27.55

WPFとBlazorは排他的なものじゃないと思うが。Razorのことか？

2020/01/12(日) 23:57:44.80

Blazorは結局Webのスキルセットが必須だからWPFの比較対象にはならんだろう
この期に及んでクライアントアプリに固執してるような奴がBlazorのためにCSSの勉強とかすると思うか？
百歩譲って勉強するとしても、だったら普通にWebへ行くだろ

2020/01/13(月) 02:18:01.65

>>73
Blazor for Native次第だね

2020/01/13(月) 16:12:25.49

Blazorっていうかデスクトップアプリは捨ててWebアプリに移行するよ。

2020/01/13(月) 16:31:47.39

10年くらい前からそんなこと言われていてずっと環境が揃うのを待っているんだが、あと何年かかるのかね。

2020/01/13(月) 17:07:59.03

WPFは15年経っても流行らなかったがまだこれから来るとか抜かしてる奴がいるし
言い続けている限りは負けじゃないのさ(彼らの中では)

2020/01/13(月) 19:44:22.74

Browser+RazorなのにBlazorっておかしくね？　Brazorと呼ぶべきなんじゃ？

2020/01/13(月) 20:46:56.54

>>78
Lの方がかっこいいやろーとか言ってなかったっけ？

2020/01/13(月) 21:40:22.16

>>73
C#案件が広がりを見せるという結果が期待されてるんでしょう

2020/01/13(月) 22:34:27.16

C#で全部やりたいとかのニッチ向けに感じる
Webに移行するならコミュニティ、情報などの面からもクライアント側は素直にJS/TSでやった方がいいし
デスクトップGUIに価値を見出すならブラウザ上ってだけで欠点になる

2020/01/13(月) 22:36:00.19

ブラウザーでCAD作れる？

2020/01/13(月) 22:45:25.48

>>82
作れる。世界最大(?)のCADメーカー AutoCadがWasmを使ってWebアプリとして移植したとされている。
Wasmの例：
https://yutakaaoki.github.io/

2020/01/13(月) 22:59:14.64

>>82
バックエンドは要るけど
https://www.autodesk.co.jp/products/autocad-web-app/overview

2020/01/13(月) 23:01:22.84

>>83
毎度思うがもうちょいマシな見た目のサンプル紹介したれ

2020/01/13(月) 23:23:09.14

photshopもあるし3Dもブラウザでできる
逆にブラウザでできない分野ってある？

2020/01/13(月) 23:31:28.82

>>84
どんなバックエンド？

2020/01/13(月) 23:37:19.84

>>86
実は、ローカルPCのファイルシステムに上手くアクセスすることがデフォルトでは出来ない。
ローカルPCにファイルを保存することは出来るのだが、ブラウザ(Chrome)の特殊な
データ領域に保存されてしまい、c:\ のディレクトリ内容を取得したりすることはブラウザを特殊なオプションで起動しない限りできないようになっている。
>>83 でdemo1などを起動してファイルメニューのOpenやSave As は少しトリッキーな特殊な方法でやっているが、自由自在にファイルを読み書きできるわけではない。

2020/01/13(月) 23:39:32.88

>>87
それはさすがに

2020/01/13(月) 23:40:24.07

>>87
すまん、途中で書き込んでしまった

それは流石にautodeskに聞いてくれ

2020/01/13(月) 23:49:04.68

>>90
「バックエンドが必要である」ことは正しい情報？？

2020/01/13(月) 23:57:41.45

>>91
すまんがそれもautodeskに聞いてくれ
とりあえず単体では動かないみたいなので何ら名のバックエンドはあるはず
ライセンス認証だけかも知れんが

2020/01/14(火) 00:03:44.99

>>92
もしかしたら、それとは意味がずれるかもしれないけど、少なくとも、データ保存のためには、クラウドというか、リモートのサーバーにデータを渡す必要があるかもしれない。それはWebアプリはローカルPCのファイルシステムには容易にデータを保存できないから。

2020/01/14(火) 01:46:16.97

>>88
DTMのようなリアルタイムかつ低レイテンシーが重要な分野は厳しいんじゃないかな

2020/01/14(火) 03:38:34.54

ローカルPC に、Node.js, Ruby などのサーバーを立てれば、保存できる

VSCode は、Electron 製 = Node.js + Chrome。
Redmine は、Ruby on Rails 製

2020/01/14(火) 04:56:00.11

クラサバ→シンクラときて結局ダム端末に戻るのか

2020/01/14(火) 08:09:41.30

>>95
ElectronはNode.jsのモジュールとしてChromiumエンジンを組み込んでおり、決してHTTPサーバーを立てている訳ではない
あとRedmineみたいなゴミとVSCodeを一緒にするな

2020/01/14(火) 18:24:44.38

cgiが使えるLocalServerを起動していれば、cgiの仕組みを使ってローカルファイルシステムに自由にアクセスできるようにはなる。
また、この仕組みを使えば、WebアプリからローカルOSのあらゆる機能が使えるようになる。

2020/01/14(火) 18:26:25.39

それはセキュリティーホールと言う奴だねｗ

2020/01/14(火) 18:31:55.23

RubyやPython, node.jsなどはどれも cgi server として起動することも出来て、
さらに、cgiを書くスクリプト言語としても使える。
そしてほぼあらゆるプラットフォームで動作する。
だからそれらを利用すれば、理論上は1つのcgiスクリプトであらゆるプラットフォームでOS固有のファイルシステムにアクセスすることが出来る。

>>99
まあ、悪用すればそうなんだけども。

2020/01/14(火) 18:54:53.44

linuxなどではルートフォルダを自由に指定してある階層から出られなく出来るけど
winはそれがないからちゃんとフォルダ指定内容をチェックしてないと単なるセキュリティーホールになる

2020/01/14(火) 18:56:14.18

cgi serverとWebアプリを組み合わせたツールキットを作れば、それだけでnativeアプリと同様の機能を持ったマルチプラットフォームツールキットになるかも。

2020/01/14(火) 18:57:57.56

>>101
native アプリではそもそもどんなフォルダにもアクセスできますので、それを持ってセキュリティーホールとは言えないと思います。

2020/01/14(火) 21:07:10.83

>>92
悪いが、個人でAutodesk規模の開発
をする気は無い。っうか無理だ

ライブラリーも含めてそういうものを
開発出来るベースが無いという事で納得した。

2020/01/14(火) 22:14:43.86

ブラウザで動作するCADソフト開発する上でのベースが無い
という納得？
ブラウザアプリもデスクトップアプリも変わらんと思うけど