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

レス数が1000を超えています。これ以上書き込みはできません。
2021/06/20(日) 17:04:18.66ID:7UVkl7BZ
Windows Presentation Frameworkについて語るスレ。

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

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

コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/
2021/06/20(日) 17:12:38.99ID:Gtwxv8wt
>>1
おつ
3デフォルトの名無しさん
垢版 |
2021/06/20(日) 18:11:48.19ID:0gGUIuE2
>>1
たておつー
2021/06/20(日) 18:16:37.49ID:rLhrk+Fq
>>1
前スレのまとめ

XMLは糞
2021/06/20(日) 18:21:49.81ID:akuykRB/
SwingやFormsみたいにUIをコードで書かせる世界には戻りたくないなぁ。
2021/06/20(日) 19:37:49.51ID:Gtwxv8wt
まあ理解できないうちはXAMLとか糞に見えるもんな
俺もそうだったけどなれたら簡単になるから早く慣れたほうが良いよ
7デフォルトの名無しさん
垢版 |
2021/06/20(日) 19:41:41.54ID:Zphs/5+o
MVVMが理解できないならMVVMやらなくてもいいのにプライドが高い老害が多いんだろうな
それで十数年廃れるって言い続けてる
2021/06/20(日) 20:03:15.61ID:IOfHBDeH
mvvm = WPF って思ってるの多すぎ
2021/06/20(日) 20:05:13.57ID:IOfHBDeH
どっちかというと、
mvvmアーキのフレームワークで
ぶっちぎりに最悪なのがWPFってかんじ
10デフォルトの名無しさん
垢版 |
2021/06/20(日) 22:08:58.85ID:5dugBd6b
XAMLが特級のクソなだけだよ
冗長なBinding式やBehaviorやCommandなど、他のMVVMフレームワークが大量に生まれた中で誰が採用した
挙げてみろ
Javaで言うところの検査例外相当のクソ
11デフォルトの名無しさん
垢版 |
2021/06/20(日) 22:14:56.41ID:Zphs/5+o
クソだと思うなら関わらなきゃいい
なぜ理解できないものに粘着するのか
2021/06/20(日) 22:47:51.64ID:X7PAuK/l
>>5
でもHTMLやXAMLよりむしろ便利なことも多いが。
2021/06/20(日) 22:49:47.76ID:X7PAuK/l
HTMLから入った人は、それが母国語の用になっているので、WinFormsやSwing
方式よりXAMLの方が便利に見えるのだろう。
MVCやMVVMもそういう人のために有るといわれている。
ところが、人気が有るのは、WinForms方式であることもまた事実だ。
なぜなら、そのほうがコントロールし易く、プログラムのソースコードから
見てもわかり易いから。
2021/06/20(日) 23:00:26.10ID:akuykRB/
まぁ、宣言的な記述が受け入れられなくて、なんでも逐次的・手続き的に処理されないと理解できない人は一定数いるね。
15デフォルトの名無しさん
垢版 |
2021/06/20(日) 23:49:25.07ID:Zphs/5+o
WinFormsが人気ある？
GUIはマークアップ言語でやるのが主流だと思うが
2021/06/21(月) 00:03:57.42ID:ZafEWlbz
>>10
WinUI3とPrismなどのMVVMライブラリ使えばだいたい解決できる話ですね
2021/06/21(月) 00:12:54.72ID:85An+spJ
>>10
Javaの検査例外の問題って、例外機構自体が内在している問題を検査例外で静的にチェックしたせいで
白日の下に晒されてしまったに過ぎないのよな。
2021/06/21(月) 00:16:47.60ID:DBAAgUVQ
>>10
それXAMLじゃなくて
XAMLの上に作ったBehaviorとかの糞ライブラリ群ね

XAMLはそんなに悪くない
2021/06/21(月) 00:21:15.41ID:DBAAgUVQ
>>16
そんなの使ったって
いろいろ肥大化して更に糞まみれになるだけですよ

ダイアログ一つ表示するだけなのに
見通しの悪い糞まみれコード書かなきゃならないのは変わらないんですから
20デフォルトの名無しさん
垢版 |
2021/06/21(月) 00:50:53.72ID:KYdCJjvS
冗長君は何年もWPFに粘着してるWinForms信者です
2021/06/21(月) 01:24:30.80ID:PP3lMGGZ
>>15
C#の中ではWinFormsが一番人気。
2021/06/21(月) 04:35:36.83ID:3t67Nua5
>>15
30年前からGUIは頬杖つきながらマウスでD&Dしてプロパティをポチポチするのが主流ですよ。
2021/06/21(月) 07:01:52.54ID:NDZaXBVn
>>21
人気なんじゃなくて技術レベルが低くてWinFormsしか使えない底辺PGが多いだけ

>>22
生産性の低い地獄の作業だな
2021/06/21(月) 08:26:44.33ID:3t67Nua5
WPFはとてつもなく生産性が低いですね。
最高の技術者が集まってるVSチームでさえWPF化に5年もかかったのですから。

自分でどれだけWPFが糞か言ってて草生えますwwww
> 人気なんじゃなくて技術レベルが低くてWinFormsしか使えない底辺PGが多いだけ

このスレの当初からこんなゴミは普及しないと言われ続け、その通りになった上に、
WPFだからこそ実装できるようなキラーアプリは何一つ存在しないだけでなく、
MSのPGからも嫌われ碌なサポートもなく放置され続けた。

あなただけがはいつか普及するはず、ビッグウェーブはすぐそこまできてる、
WPFを批判してるはスキルが低い底辺PGだと念仏のように唱えてる。
25デフォルトの名無しさん
垢版 |
2021/06/21(月) 08:27:39.85ID:KYdCJjvS
それWPFでも出来るんだができないと思ってるのかな
2021/06/21(月) 08:33:47.23ID:DBAAgUVQ
>>24
WPFの生産性が悪いのではなく
WPFのBlendフレームワークの生産性が酷いだけ
デザイナーとの協業など見たこともなし
2021/06/21(月) 08:54:00.98ID:Y1XruxkF
>WPF化に5年も
それはつまりWPFの前が変更に弱い、生産性が低いってこと。
酷い作りのゴミコードを近代化するのが大変な作業なのは多くの開発者が実感してるだろう。

実際winFormsの生産性は非常に低い。
WPFで作っておけば半分の工数で済んだのにってことが何度もあった。

普及≒簡単・誰でも使える⇒代わりはいくらでもいる⇒単価下がる
2021/06/21(月) 12:50:18.82ID:/bfDvgWv
>実際winFormsの生産性は非常に低い。
使いこなせて無いだけ。
2021/06/21(月) 12:52:20.96ID:/bfDvgWv
って言うかそんなにWPFの生産性が高いのであればとっくの昔に普及してるって。
2021/06/21(月) 13:41:38.72ID:NDZaXBVn
>>28
言い訳が苦しすぎるww


vbおじいさん、winformおじいさんは勉強嫌いだろ。
生産性を高めようと思っていたらこんなものにしがみついていない。
2021/06/21(月) 14:32:57.76ID:QSvmLdyv
WPFってSilverlightと同じく失敗productだろ
2021/06/21(月) 14:56:36.21ID:DBAAgUVQ
>>29
Silverlight時代からなんで
そこそこ普及はしてると思うが、
実装方法は糞評価だね。

早い段階でflutterに食われるでしょ。
2021/06/21(月) 15:26:16.45ID:wnQSc3ge
ビヘイビアとコマンドなんてそんなものあったなあって感じ
10年くらいWPF書いてるけどその2つを使ったのって最初の1年くらいｗ
無くても困らないｗ
34デフォルトの名無しさん
垢版 |
2021/06/21(月) 18:33:02.80ID:Nu/+E6/O
俺もWinFormsからWPFに乗り換えた人間だが、明らかに開発は早くなったと感じる

まあ小っさいの作るならWinFormsの方が楽だろうけどね。MVVMの骨格を整備するの面倒だし。
GUIとロジックを分けて書ける有難みはそこそこ複雑なものを作って分かったよ
35デフォルトの名無しさん
垢版 |
2021/06/21(月) 18:38:34.44ID:Nu/+E6/O
まあWPFの良し悪しは置いておいても、マークアップ言語でのGUI構築には慣れておいた方が良いことは間違い無いと思う
なんせ今はWebアプリが強い時代だからね。それでも俺はデスクトップに残り続けるがw
2021/06/21(月) 19:07:10.23ID:SD9Vy51I
WPF以降だとサムネイル表示とか一瞬で作れるもんな
formならこうは行かないと思うけど
効率重視のformの人はformのリストビューみたいなので我慢できる人なの？
2021/06/21(月) 19:20:34.66ID:jqlm888h
>>10
jsとかの他のMVVMは確かにそんなもんつかってねーな
2021/06/21(月) 19:24:32.35ID:jqlm888h
Livetやprism使ってありがたいと思ってたけどそもそもがそんなもん使わせるなよよｗ
これ以外何も思わない
そのPrismですらコロコロ内容が変わる
2021/06/21(月) 19:55:49.41ID:1n0nC/ay
割と最近になってMVVM Toolkit for .NET(Microsoft.Toolkit.Mvvm)なんて出してきた
2021/06/21(月) 20:02:52.09ID:ZPTvRcij
べつにだれもマークアップ言語でのGUI構築にケチつけてないだろ
41デフォルトの名無しさん
垢版 |
2021/06/21(月) 20:08:46.88ID:Nu/+E6/O
>>38
それに関しては禿同。
外部に頼る前提のフレームワークって何なんだよとw
MSが吸収したりしないもんかね
2021/06/21(月) 20:13:51.82ID:A6ZWHwGn
今更何を言おうが、WPFはメンテナンスモードなので未来永劫改善されることはない
2021/06/21(月) 20:19:00.04ID:1n0nC/ay
WPF自体はそのままだけど
VS2019で実行時にバインドエラーを専用ウィンドウで表示できるようになったり
開発環境は地味に改良されてたりする
2021/06/21(月) 20:39:33.26ID:NDZaXBVn
>>41
Microsoftの名前空間が付いたMVVMライブラリが出たし、これでいいでしょ。
2021/06/21(月) 20:41:17.43ID:jqlm888h
>>43
それは15年前に必要だったものでは？
2021/06/21(月) 21:08:15.72ID:mqD8ibJ4
WPFが普及しなかったのはWPFの出来とは関係ない

WPFがこれからって時に、Webアプリやらスマホの台頭で
WindowsプログラマがWPFを学ぶ前にほとんどweb,android,iosに流れてしまった

単にwindowsアプリの需要がないだけ
2021/06/21(月) 21:12:55.51ID:mqD8ibJ4
新規Windowsアプリの重要が急激になくなってwindowsアプリ作る人いなくなったのにWPFが普及しないとどうこういう以前の問題
2021/06/21(月) 21:18:34.16ID:b32VLmjg
Prismは6から7のときのだけ破壊的変更が有ったけど、それ以外のバージョンアップは後方互換性も悪くなかったけどな
7の変更のおかげでUnityからDryIocにDIコンテナを変えても、モジュール入れ替えてusing変更だけでほぼ動く
49デフォルトの名無しさん
垢版 |
2021/06/21(月) 21:27:15.04ID:Nu/+E6/O
>>43
VS2019が出るまで、我々はあのコンソール画面と睨めっこしながらバグを潰していたのか…
ｵﾞｪﾞｯ
2021/06/21(月) 21:28:25.72ID:mqD8ibJ4
業務アプリとかならWinFormsでもいいかもしれんけど、今風なおしゃれな見た目のアプリ作るとなるとWPFというか、WinUIになっちゃうからな
諦めるしかない
つか、お前らどうせ新しくWinアプリ作ってねぇだろ??w

俺は4年前にUWPアプリ2つ作ってから、もうずっとスマホアプリだけだわ
2021/06/21(月) 22:03:56.86ID:jqlm888h
WPFは初期だけ盛り上がってしばらくしたら誰もいなくなった
外人のスタープログラマが持ち上げてたけどそいつらもすぐにいなくなった
コードを書く以外の時間も長いし
相対的なコード量も増える


WPFの学習効率の悪さ
開発環境の劣悪さ
MVVMによるコードの長大化
MVVMのデバッグの難しさ
など

winformsでは起こりえないいくつのマイナスポイントがあった
2021/06/21(月) 22:22:38.53ID:A6ZWHwGn
>>50
俺はバックエンドがメインになって(Web含め)GUIアプリ自体仕事では全く作らなくなったな
画面作るのは好きだがツールに振り回されるのはアホらしいわ
53デフォルトの名無しさん
垢版 |
2021/06/21(月) 22:45:13.59ID:RsRWwffr
>>46
スマホやWebのせいじゃなく、アメリカの独占企業たちが、検索エンジンやOS
やハードウェアで儲けた金で無料でプログラムを配りだして、彼ら以外に
はWindowsアプリ作っても一線も設けることができなくなったこと、
Blenderや無料Office、GRUB、Apache、gccなどのGPLな無料アプリの台頭、
などがあるのではないか。
AndoridやiOSはMSの息が掛かってなかったから、売れるチャンスがあった。
2021/06/21(月) 22:54:34.53ID:RsRWwffr
アプリ作っても無料アプリに負けることが多くなったと思う。
55デフォルトの名無しさん
垢版 |
2021/06/21(月) 23:58:30.48ID:mqD8ibJ4
WPFでMVVMを学んで、
今はandroidでもkotlin+MVVM
今はflutterでも開発してるがこれもMVVMで作ってる
MVVM最高!!
2021/06/22(火) 00:51:13.35ID:/hzWR5hC
>>51
学習高率の悪さねえ…
VB2〜6でイベントドリブン入門した層がWinFormに移行して
(奴らはこの時もオブジェクト指向だの.NET Frameworkだのでかなり苦労した)
その成功体験と開発方針を金科玉条のごとく大事にしていて
新しいパラダイムに対応できなかったことを指すならその通りだね
デスクトップアプリの開発者はWebアプリと違って新しい事にチャレンジするモチベーションが無いからな
2021/06/22(火) 01:19:42.36ID:/xD272cm
笛吹けど踊らず。パラダイムシフトとならなかったのが今の状況
2021/06/22(火) 01:33:19.95ID:/hzWR5hC
>>57
もちろんWPFは失敗だったし
失敗の原因はMSが色々と読み間違えたことにある
そのひとつがWinForm開発者のレベルの低さなのは間違いない
2021/06/22(火) 01:52:54.59ID:y59U06XH
B層に愚民愚民言い続けてたら選挙で大負けした人達みたいっすね
60デフォルトの名無しさん
垢版 |
2021/06/22(火) 02:02:53.23ID:/hzWR5hC
>>59
この場合B層が何を指すのか知らんしどの選挙の事を言っているのか不明だが
MSが支持層のレベルを読み違えていたのは間違いない
WPFはWinFormの開発者がスムーズに以降できるスキームを用意できなかった
2021/06/22(火) 02:04:10.32ID:/hzWR5hC
このスレﾜｯﾁｮｲ無いのなｗ
2021/06/22(火) 02:06:29.19ID:y59U06XH
あれ、前のスレはあったのに
2021/06/22(火) 02:45:32.55ID:p6tBruNL
>>57-60
この流れが正しいだろう

まるで「自分の教えてる生徒は落ちこぼれが多くてね・・・」と嘆いている教授みたいだ
確かに、生徒のレベルが低いという事実はあるかもしれない
だが、そのレベルに対するあんたの教授法はどうなんだ、と
2021/06/22(火) 02:50:59.28ID:hVWHiksC
その頃、.net framework懐疑派もいてc++ Win32/MFCやらdelphi軍団
WinForms開発者はVBからの移行組多くてWinForms+VB.net??
だったら、WinForms開発者のレベルが低いのはしょうがない
65デフォルトの名無しさん
垢版 |
2021/06/22(火) 06:11:16.58ID:Aeo9kDkU
ここの人たちはわかってるんだな
WinForms止まりの人たちは成長しない人間だということを
66デフォルトの名無しさん
垢版 |
2021/06/22(火) 07:44:38.48ID:Xn56/PVc
XAMLは一生関わりたくないでござる
67デフォルトの名無しさん
垢版 |
2021/06/22(火) 07:51:15.99ID:jruG6CnM
じゃあ成長を促してあげようぜ
.NET MAUIの公式ドキュメントできてたんだな

https://docs.microsoft.com/en-us/dotnet/maui/
2021/06/22(火) 08:05:17.77ID:7Ks2gqqv
デスクトップの人はMAUIよりWinUI行くんじゃね？
2021/06/22(火) 08:19:50.21ID:7j121Wmb
ざむるか久しぶりだな
遊びでWindowsPhoneのガワ作って以来だわ
当時はMVVMがまだ浸透していなくて
何それ美味しいの状態だったって覚えてる
2021/06/22(火) 09:53:59.29ID:TtlGiyRY
>>51
そしてなによりWPFは遅かった。
2021/06/22(火) 12:09:06.38ID:lNl6Rhk5
>>67
MAUIはXamarinだから地雷
2021/06/22(火) 12:52:20.11ID:v8vBbrXJ
>>71
だよな。
2021/06/22(火) 12:53:14.61ID:v8vBbrXJ
もうflutterでいいよな
MSも関与してるし
2021/06/22(火) 12:56:43.65ID:P9tLBTwV
>>70
なるほど。
WinFormsのGUIパーツは、Win32のControlを使っているから、OSの
内臓コンポーネントであるC/C++で記述されている。
一方、WPFのGUIパーツは C#で作られているはずで、その速度はC#の
良い実例。それが遅いということはC#が遅いということ。
2021/06/22(火) 13:12:45.67ID:v8vBbrXJ
リフレクションを多用するアーキテクチャがそもそも遅い
バインディンク構文使わないと早くなる
2021/06/22(火) 13:58:58.57ID:MIKkQrwG
このスレでバインディング遅いって書くとバインディング遅くないよマンがでてくるんだよなあ
2021/06/22(火) 16:13:02.61ID:bYopypDX
遅すぎず速すぎず程よい速度
2021/06/22(火) 16:32:17.27ID:p6tBruNL
速過ぎて困ることあんのか？
2021/06/22(火) 16:33:15.01ID:v8vBbrXJ
>>77
むかし遅い遅いって現場で揉めて
外部のコンサルとか乱入してきて大変でしたよ

しかもそのコンサルは非.NET系の...

笑
2021/06/22(火) 17:03:11.34ID:hVWHiksC
UWPでコンパイル時バインディングx:Bind使っても速度的な違いわからねぇし、
そもそも、AOTコンパイルだっけ?のUWPもつまりxaml??重いんだよな...
そりゃデスクトップPCで動かせば気にならんけど、当時はatomタブレットでバッテリーにも関わるから気になったわ

今のパワフルになった?SoCなら大丈夫そうだが??
2021/06/22(火) 17:07:39.26ID:hVWHiksC
>>73
flutterでFluent システムを実装してほしい
Material DesignをWindowsデスクトップで動かした時のデザインのダサさときたら..
82デフォルトの名無しさん
垢版 |
2021/06/22(火) 18:29:12.84ID:nJBLTJzV
>>79
何系よ？
MSC++,MFC,VB,JAVA,Delphi,BCC
2021/06/22(火) 18:53:39.20ID:kB1tp0oO
最近は、そう遅くも感じない。


それなりにテクニックはいるけどね。
2021/06/22(火) 19:16:18.55ID:nj/DGDzB
>>80
UWPはネイティブだよ。
2021/06/22(火) 19:30:55.75ID:v8vBbrXJ
>>82
javaかな
最初はいろいろきつかったね
2021/06/23(水) 05:51:06.75ID:jt9dD4ot
Winデスクトップオンリーなら.NET6 + WinUI + WPF
モバイル主体のマルチプラットフォームならFlutter
ってところかな
2021/06/23(水) 12:22:19.83ID:d23QmeSO
遠い未来ではそうかもな
2021/06/23(水) 17:51:22.42ID:nH+qDmUa
WINUIでどの程度パフォーマンス改善されるんだろ
2021/06/23(水) 19:46:25.93ID:B+S84JMM
>>66
XAMLはいいぞ(´・ω・`)Petzoldさんも本書いて勧めている
でもストアアプリはハードルが高い（特に個人で出す場合
2021/06/23(水) 21:33:34.09ID:O7LWJ7Ln
ストアアプリは誰にもメリットなかったよね…
Windows Phone の残した亡霊
2021/06/23(水) 21:37:53.44ID:hKNB6M+8
ストアのハードルは別に高くない。
ハードルがいくつもあるだけ。
92デフォルトの名無しさん
垢版 |
2021/06/23(水) 22:49:51.77ID:KJ8ZVKXN
UWPは
・Win10以外非対応
・拡張子がexeじゃない
この辺りが原因で、特に古参中心に初めから嫌われていた印象　俺の周りだけかもしれないが
2021/06/23(水) 23:53:15.80ID:AWn9dTRx
嫌うってより開発者としてではなく消費者としてどうなの??
iOSやandroidのサンドボックスによるセキュリティに慣れたら、普通に非UWPアプリをインストールするの嫌なんだけど

有名どころのアプリやUWPの制限じゃ無理なアプリなら仕方ないけど

例えば,SNS系のアプリとかフルアクセスできるデスクトップアプリとか嫌やな
2021/06/24(木) 01:09:57.50ID:ZhZSLtyl
20レスくらいさかのぼってみたけどUWPのセキュリティが嫌だって話をしてる奴はいなかった
93は誰に対する発言なんだ？
発作でも起きたか？
2021/06/24(木) 01:37:57.30ID:lYiTQMLE
>>94
UWPのセキュリティが嫌だ、なんて>>93にも書いてないよ
96デフォルトの名無しさん
垢版 |
2021/06/24(木) 01:48:41.02ID:UNoTdpdl
開発者が何を嫌ってようとセキュリティはUWPの方が優れてるからそっちを選べよって指摘だ罠。
選ばねえよバカｗｗ
97デフォルトの名無しさん
垢版 |
2021/06/24(木) 02:35:57.56ID:u9KwmiVH
まあ単体アプリを配布する分にはサンドボックスの有用性が生きるな
Windowsの生命線ともいえる業務アプリとはこの上なく相性が悪い
iPhoneで業務アプリシステムを構築しにくいのと一緒
結局Webアプリに逃げられてしまう
2021/06/24(木) 06:21:07.27ID:PTf3B3xq
>>93
消費者としても受け入れらえなかった。
exeひとつを自分の好きな場所に配置して実行できる自由さには勝てない。
そもそもセキュリティのメリットを理由にUWPを入れたがる消費者なんてほぼゼロに近い。

会社だとストア無効化、サイドロードの設定も有効化できないようにされてるところが多いから
UWPは使い物にならない。
2021/06/24(木) 06:45:20.03ID:KjDgyD5o
ストアの画面とか開くことすらないからストアに何があるのかすら知らないわ
VS2022とかストアで扱えるようにすればいいのに
2021/06/24(木) 08:36:15.96ID:NLbTIuex
>>99
MS謹製のpythonがあったな
2021/06/24(木) 09:42:23.93ID:6hf93Vdb
UWPの問題は
・Win10専用
・DataGridが当初無かった
・EF Coreが当初SQLiteしか使えなかった
・インストーラがプライベートストア構築からとハードル高杉
辺りが問題だったね

今ならインストール以外はだいたい解決しているから使えないこともないが
2021/06/24(木) 12:54:03.18ID:j4shFytl
ストアでインストールしたのはWSLくらいっすかねえ
2021/06/24(木) 17:08:34.96ID:7n0FYJDV
Formsがオワコンかと思ったら.NET5で再び生き残ってるっぽい
リユニオンプロジェクトとかWinAPIも復活するし
分断させたいのかくっつけたいのか、終わらせたいのか復活させたいのかよく分からない体制だな
2021/06/24(木) 17:14:36.89ID:KjDgyD5o
APIは死んでないだろｗ
APIは使いやすく整備するだけじゃなかったっけ？
2021/06/24(木) 17:40:38.06ID:6t03e9bV
>>103
いやそれはWPFも同じw
タマがないんやw
2021/06/24(木) 18:35:32.72ID:gqYKtk29
APIはOSのコアDLLだから無くならないだろ
2021/06/24(木) 20:08:03.68ID:9uMGIASm
Macと違って膨大なエンタープライズ資産が世界のユーザーにあるから簡単に切り捨てられんよ。
2021/06/24(木) 20:23:54.02ID:2cVfXV/f
iOSは他に方法が無いからみんな渋々ストアに登録してんのに、なんでWindows開発者が
ストアアプリに流れてくれると思ったんだろ。
2021/06/24(木) 22:07:33.10ID:PTf3B3xq
>>103

Formsがオワコンなのは変わらんよ。
「VB6をまだサポートします」と言われても一般的な開発者は喜ばないのと同じ。


>そもそもマイクロソフトがWindows 8でデスクトップ環境とモダン環境を“分断”しなければ、
>REUNIONは必要なかったからだ。つまり、
>自分で2つに分けちゃっておきながら、今になって再結合って言い出しているわけで、
>例えて言えば、「花瓶割っちゃったので接着剤で付けました」的な話である。
2021/06/24(木) 22:13:34.45ID:VGtS8JPG
マック過去のAPIや資産をバンバン切り捨てまくってるけど、客は怒らねーのかね
2021/06/24(木) 22:22:13.21ID:rge7Ftvr
>>110
?ヴェルタース オリジナルのCMのようにマカーの人たちは自分たちは特別な存在だと思ってるので
appleに何をされても怒らない
2021/06/24(木) 22:35:54.47ID:aX40sl0U
https://iphone-mania.jp/news-348098/
iOSならともかくmacなんてシェア10パーセント弱だし
怨嗟の声が上がってても聞こえるほどじゃなかろうな
俺はAPIに無告知で破壊的変更を入れてくるから嫌い
2021/06/25(金) 01:41:00.98ID:SBWjOd/p
簡単なテストアプリをサクッと作る時なんかは WinFormが捗る
114デフォルトの名無しさん
垢版 |
2021/06/25(金) 03:15:26.19ID:qqEJCDPW
>>103
終わらせる必要はないと思うけど足手まといにはなってそうだな
2021/06/25(金) 05:48:06.07ID:ifkxfXVo
ストアテコ入れとは聞いてたけどまさかAmazonアプリと合体するとはなｗ
2021/06/25(金) 05:54:42.48ID:zVVssHd/
>>113
いや、テストアプリでもWPFの方がはかどるよ
2021/06/25(金) 06:51:18.97ID:AhNzrASB
>>115
MS社内でもUWPは期待されてない香りがプンプンするぜ
2021/06/25(金) 07:52:51.65ID:NwX/yPma
>>115
ようは敗北宣言じゃね？
Windows8で糞使いにくくしたりストアアプリ/UWP注力でデスクトップ放置とか全部失敗だったな。
2021/06/25(金) 07:57:29.12ID:lVANw6EN
もういい加減32bit切ってくれ
2021/06/25(金) 10:46:21.59ID:6KbKcl9Y
>>119
Windows11で切るんじゃなかったっけ？
2021/06/25(金) 10:54:16.88ID:ifkxfXVo
32bitどころか俺のPCが１１で切り捨てられそうなんだけど
2021/06/25(金) 10:59:16.69ID:A4FvZdNB
定期的に湧くよな、マカー並の低能馬鹿、切り捨て厨。
2021/06/25(金) 11:07:47.58ID:ifkxfXVo
>>122
なにこいつキモいんだけどｗ
2021/06/25(金) 11:08:04.57ID:eijvgSCB
>>120
切られたね
MSもApple並のド低脳になってしまった…
まあ32bit切り捨てよりTPM2.0未満切り捨ての方が影響でかいけど
2021/06/25(金) 11:12:48.81ID:MeOG8FMO
>>117
というかUWPは終了が確定している。
UI部分はWinUIに分離され、こっちが更新されていく。
残りカスのUWPはフェードアウト。
2021/06/25(金) 12:02:45.75ID:FVtxn09p
万が一Amazonアプリストアで軌道に乗っちゃったら、
そっちとの親和性開発の流れになるから、またリセットされるな
2021/06/25(金) 12:07:54.36ID:A4FvZdNB
言語でもハードでもOSでもどれも互換重視で圧倒的シェア獲得してきたのに、
後から乗っかってきた頭の悪い新参者はすぐ切り捨てしろと言うから困る。
そういう歴史を知らない馬鹿がMSの経営陣に多くなったということ。MSも落ちぶれたものだ。ゲイツはやはり偉大だったのだ。
2021/06/25(金) 12:25:33.63ID:e/bo9MqG
32bit CPU（32bit OS）サポート外とした、ってことでしょ。
今32bit OS使う理由って25年近く前の16bitプログラムの何か使ってるか、
15年ほどデバイス更新せず古いまま使ってるか。
いいかげん更新しろよって感じでしょ。

64bit OS内での32bitの実行ファイルはもちろんwin11でも動作するわけで、互換性としては十分だろ。
2021/06/25(金) 12:47:49.60ID:A4FvZdNB
ほんと切り捨てろ連呼してる奴は馬鹿ばかりだ。
130デフォルトの名無しさん
垢版 |
2021/06/25(金) 13:56:45.31ID:NV5/Ahkd
64bitと言ってもAMDが作ったx86互換の64bitもどきだからな
インテルのIA64が勝っていたらx86アプリは今頃残っていなかっただろう
2021/06/25(金) 14:13:52.60ID:/3glHUNQ
wpfくっそむずすぎ
こんなんやっとれんわ
132デフォルトの名無しさん
垢版 |
2021/06/25(金) 14:25:50.32ID:Wd+wOk9Z
馬鹿には無理
2021/06/25(金) 14:34:50.27ID:/3glHUNQ
バカだから無理だわ
datagridとかのドキュメントも長ったらしいし、
reactivecollectionやらobservablecollectionやらがやたら長ったらしくて冗長だし、
画面に複数のデータをリアクティブにするだけで長ったらしいコードが溢れるし、
他の言語のwebなら数十行のコードもxamlまで含めて何百行となるし、
実行したらしたで重いし、保守なんてさせられんわ

linqくらいだわいいの
仕事ならしゃあないだろうけど
134デフォルトの名無しさん
垢版 |
2021/06/25(金) 15:37:06.01ID:PQH5rdUP
XAMLは使わなければWPF最強
135デフォルトの名無しさん
垢版 |
2021/06/25(金) 16:22:42.63ID:BnS8egAD
>>133
「クラス名が長いから嫌だ」って…
まさかメモ帳で書いてるんじゃなかろうな
2021/06/25(金) 17:19:49.38ID:djQjn/cE
失敗プロジェクトの連続
MSには馬鹿しかいないのか
2021/06/25(金) 17:36:50.94ID:ifkxfXVo
本気で馬鹿しかいないと思うよ
ブラウザさえまともに作れずに結局Chrome互換
検索エンジンもゴミ
WPFとUWP分離したりくっつけたり
dependency propertyなんかみてもひどいしな
褒めるところが全く無いのがすごい
2021/06/25(金) 18:15:45.87ID:wfTcV3LX
VSCodeとか新生Edgeとか他所のフレームワーク使う時のMSは伸び伸びしとりますなあ
2021/06/25(金) 19:07:24.25ID:zVVssHd/
>>137
ブラウザはGoogleの露骨な妨害があったから泣く泣く断念した経緯がある。
2021/06/25(金) 20:01:38.14ID:buVq68wJ
どこも同じゃないの？
仕事で作らされてもろくなもん出来ないよ。
2021/06/25(金) 21:12:58.06ID:/vwepKGE
WPFを使うとプロジェクト全体の作業効率がアップするのか甚だ疑問だな。本当に良いものならもっと普及してる筈なのだが
142デフォルトの名無しさん
垢版 |
2021/06/25(金) 21:36:11.44ID:BnS8egAD
ここ最近WPFが善か悪かの議論しかしてないよな
何か他に話題は無いん？

…まぁ、無いかw
2021/06/25(金) 21:38:17.66ID:zVVssHd/
>>144
https://qiita.com/tags/wpf
https://qiita.com/tags/winforms
2021/06/25(金) 21:38:53.51ID:zVVssHd/
>>141
>>143
2021/06/25(金) 21:41:33.62ID:zVVssHd/
WPF : 記事数1,123, フォロワー625
WinForms : 記事数78, フォロワー6

これが現実
146デフォルトの名無しさん
垢版 |
2021/06/25(金) 21:42:58.30ID:595fcDMG
>>117
MSは社内ですら方針統一できてないのがなあ
CairoやLonghornがコケた頃から何も変わってない
2021/06/25(金) 22:13:07.08ID:i6/+pAU6
なぜそのタグで検索して比較したw
2021/06/26(土) 03:46:23.80ID:XXzuMEQx
>>145
Windows Forms で検索すると、1513
WinForms:258
Forms:4412
WPF : 1903
2021/06/26(土) 03:50:38.30ID:XXzuMEQx
Xamarinで検索: 1726
タグのXamarin:968記事、906フォロアー。

如何にQiitaの読者層が信用ならないかが垣間見えるような。
2021/06/26(土) 03:56:28.35ID:XXzuMEQx
Qiitaではなく、Quoraだと、
C++: Follow 1M
C#: Follow 382K
Java: Follow 1.3M
つまり、人気は、
Java > C++ >> C#
2021/06/26(土) 04:39:37.06ID:XXzuMEQx
Google Trendsだと、WPF,MFC,Flutter,Qtが互角くらいで、WinFormsとUWPは低迷。
2021/06/26(土) 04:46:05.20ID:XXzuMEQx
Flutterは上昇中。MFC,WPFは徐々に下がってきている。
Xamarinは横ばいで低迷。
QtやFlutterはマルチプラットフォームなのに対し、MFCは古くからありWindows
専用な割には未だにかなり強い。
2021/06/26(土) 06:35:43.77ID:ZRPAi/RT
>>150
人気言語なら
Rust > TypeScript > Python > Kotlin > Go > Julia > Dart > C# >
Swift > JavaScript > SQL > Bash/Shell/PowerShell > HTML/CSS > Scala > Haskell > R > Java > C++

習得したい言語なら
Python > JavaScript > Go > TypeScript > Rust > Kotlin > Java > C++ > SQL > C# >
Swift > HTML/CSS > Dart > R > Ruby > C > Scala

糞な言語なら
VBA > Objective-C > Perl > Assembly > C > PHP > Ruby > C++ > Java > R > Haskell > Scala >
HTML/CSS > Bash/Shell/PowerShell > SQL > JavaScript > Swift > C# > Dart


by SO 2020調べ
2021/06/26(土) 06:53:11.90ID:ZRPAi/RT
GitHubリポジトリ数

Flutter(21,854) > WPF(5,679) > Xamarin(3,434) > WinForms(3,373) > UWP(1,630) > MFC(355)
2021/06/26(土) 11:27:25.79ID:TqdTR7t2
Flutterの人気がスゴいってのは分かった
2021/06/26(土) 11:54:16.49ID:XXzuMEQx
githubは特殊性が有ると思う。
vue.jsは、185k star、29.4k fork で、スポンサー(ほぼ知らない企業ばかり)も大量に
付いているが、実際の使用例はとても少ないと聞いてるし。
逆に、qtなんかは、1.4k star, 680 fork だけど、ウェブではないところで
結構使われていることが分かってる。
2021/06/26(土) 12:09:15.30ID:XXzuMEQx
>>145
Qiitaは、Webにちゃんとまとまって書いてないことを、自分で調べた人が
書く場所。だから、Webに情報が少ない事が書かれる傾向がある。
いくつかの調査で、WinFormsはWPFより使われていることが分かってる。
2021/06/26(土) 12:16:53.81ID:XXzuMEQx
2020/07/26 の時点で、マウスイベントで頻繁に更新される多くのDatagridviewsを使った
ビジネスアプリは、古いPCだと、WinFormsはマウスの反応が即時だがWPFはマウス
をクリックしてからUIが反応するまで数秒掛かると書いてある。

https://stackoverflow.com/questions/19642320/is-there-a-performance-difference-between-wpf-and-winforms

Great piece of advice here. I attempted a wpf business app with a number of
Datagridviews that were frequently updated by mouse events, and on older
production pcs, the app would take as long as a second between mouse click,
and ui response. Winforms version response time is practically immediate.
– c jk Jul 26 '20 at 23:49
2021/06/26(土) 12:21:32.22ID:w6j9gBE1
WPFのDatagridがゴミなのはもう常識だろ
2021/06/26(土) 13:01:58.02ID:+M0IgX5j
フレームワークにフレームワークが必要ってのは言語やプラットフォーム関係なく根っこが腐ってるからそうなるんだと思う
2021/06/26(土) 13:16:45.55ID:gzd4bl1h
(;´д｀)
2021/06/26(土) 14:45:30.68ID:E0lcRfGC
グリッドコントロール使うアプリケーションの大半はゴミだけどな。
一覧画面と編集画面の2画面構成の方がほとんどのケースは使いやすい。
使いにくいしバグの元なんだからセル内で編集させるなよ。
2021/06/26(土) 15:24:13.20ID:TqdTR7t2
Readonlyで使うけどな
164デフォルトの名無しさん
垢版 |
2021/06/26(土) 15:26:27.93ID:hHYOAEGk
>>116
変人現るw
2021/06/26(土) 16:58:10.29ID:E0lcRfGC
ListView使えよ
2021/06/26(土) 17:03:12.16ID:KFUgiKj4
>>162
伝票入力なんかは表イメージのまま入力できる方が喜ばれるんだよ
WPFでやるならグレープシティのやつとか使った方がいいけど
2021/06/26(土) 17:10:24.36ID:E0lcRfGC
罫線付けたListViewでよくね？
ListBoxでもいいが。
2021/06/26(土) 17:12:42.88ID:zteDreFe
>>142
昔は普及はまだかの話しかなかったが、
今はもう普及は絶望的なのに評価しても仕方ないよな
2021/06/26(土) 17:33:33.64ID:SFjxv/Ip
データグリッド使わなくて済むようにカスタムリストアイテム作れるようにしたのがWPFとXAMLでしょ
(´・ω・`)おしゃれするんやで
2021/06/26(土) 18:35:14.18ID:Gmvay1qu
って言うかDataGridViewで事足りる
2021/06/26(土) 18:50:13.30ID:8sPnjTqa
その普及普及って話がピンとこないんだな。うちの周りじゃ普通にみんなWPFなんだが。
2021/06/26(土) 19:10:48.38ID:zteDreFe
Win11の前にビッグウェーブきたか!!
2021/06/26(土) 20:11:30.33ID:pEKyLLkA
UWPのDataGridは高速って話だが、WinUI３も期待できるんじゃね？
2021/06/27(日) 06:35:24.56ID:WZv5A4P4
>>164
テスト用のアプリならStackPanelかWrapPanelに必要なコントロールをドラッグ&ドロップしていく大雑把なマウス操作だけで画面完成。
超簡単でそれでいて最低限のレイアウト変更に対応できてる。

“一度WPFを知ってしまうとWinFormsに戻りたくなくなる”ってよく言われるのは
それだけWPFの方が画面作りが楽ちんだから。
2021/06/27(日) 09:27:21.88ID:TSKhpmUU
コードからWPF並みのレイアウトを構築できるだけのWinformsをくれ
2021/06/27(日) 09:36:27.68ID:aF9t9MTl
QTでも使ってください
2021/06/27(日) 09:53:59.32ID:TSKhpmUU
イヤじゃイヤじゃC++なんて使いとうない

まあC#のGUIフレームワークがうんこなのとネイティブとの相互運用がめんどくなって
毎度C++に戻っていくの繰り返しなんだけどね
要因がどっちかひとつならまだ我慢もできるんだが…
2021/06/27(日) 10:48:35.35ID:WZv5A4P4
WinFormsにXAMLを採用すればいいだけ
2021/06/27(日) 11:12:50.09ID:NJoLUHcc
ポトペタ出来るほうが楽じゃ
2021/06/27(日) 11:51:59.67ID:WIKfglo6
よし、Delphiを導入しよう
Qtよりはマシだろ?
2021/06/27(日) 12:02:07.47ID:f3id7Upp
DelphiのVCLをコピったのがwinformなんだが。
2021/06/27(日) 12:04:17.06ID:NX2lsBQd
>>179
じゃあWPFだな
2021/06/27(日) 13:39:52.48ID:jQhpCryR
>>181
コピーじゃなく本家が移った
2021/06/27(日) 14:28:53.00ID:me9wSnu9
181はBorlandの回し者か？
2021/06/27(日) 15:20:54.70ID:f3id7Upp
誤解を与えたようなので説明しよう。

世界的に実績のあるPGが開発→Winform→大人気
どこの馬の骨か分からんPGが開発→WPF→不人気

こういうことです。
2021/06/27(日) 15:22:04.21ID:8VL1opuX
昔のホームページビルダーとかExcelみたいに作れればええやろ
2021/06/27(日) 17:06:36.35ID:toTJDPNF
>>185
そういえばDelphiはGUI部分が大人気で、その開発チームがMSに移って作った
のがWinFormsだったのか。
どうりでWPFより設計が美しく感じるはずだ。
後発でも駄目なものはダメなんだよ、ここの信者が何を言っても。
2021/06/27(日) 17:28:14.85ID:bJFlr767
>>187
MFCよりもVCLのほうが断然使いやすかったもんな
2021/06/27(日) 17:35:16.09ID:WZv5A4P4
C#の言語仕様部分に主にかかわってる。
それは設計に関わっていないWinFormsの酷さを見れば分かるだろ？
WinFormsは生産性が低いし品質も低くなりがちなのは事実。信者が何を言っても。
2021/06/27(日) 17:42:49.35ID:HfXxTqRR
@ahejlsbergには終わりかかってるような環境よりTypeScriptに注力してもらった方が世の中のためになる
2021/06/27(日) 22:04:13.11ID:6ow+jL0/
reunionの名前が変わってる
Windows App SDKだってさ

検索殺しだわ
192デフォルトの名無しさん
垢版 |
2021/06/28(月) 00:59:55.07ID:mF8S9I5g
それはMSの得意技なので…ｗ
193デフォルトの名無しさん
垢版 |
2021/06/28(月) 01:12:00.97ID:nwjsCynN
Webを見ても、UI設計はマークアップ言語でやるっていうのが正解
それはソフトウェア開発においても同じだった
WinFormsは完全に不正解
2021/06/28(月) 01:34:40.12ID:mF8S9I5g
WinFormの肩を持つ気はさらさら無いけど、あの時代はそれがスタンダードだったでしょ
JavaのSwingだってそっちに行ってたし
Delphiを神のごとくあがめる人がいるけど、そういう先見の明はなかったよね
2021/06/28(月) 02:48:41.32ID:JBMsD7o3
マークアップ言語なら同じってのはウンコとショートケーキを同列に扱うがごときだよ
もちろんXAMLがウンコでね
2021/06/28(月) 06:21:29.97ID:zyIZLp3R
他のマークアップ言語と比べてXAMLが優れてるなんて誰も言ってないんじゃないか？
WinFormsがウンコすぎてXAMLの方が数倍マシってだけで。
2021/06/28(月) 07:18:41.45ID:czRIvr8g
そもそも何が悲しくてマークアップ言語でUIを記述せなあかんのか
それに加えてあのクソバインディングの仕様

思想に拘泥しすぎて使いづらいことになっとる
C#の言語仕様の方向性とはまったく真逆
2021/06/28(月) 08:00:53.90ID:cZa6zFVz
>>195
まあ、他のショートケーキ環境と比較してみればXAMLがいかにウンコかよくわかるかもね。それって例えばどれ？
2021/06/28(月) 08:19:26.68ID:ajvVSSfT
冗長くんの言葉のチョイスが小学生だなｗ
2021/06/28(月) 08:33:12.98ID:czRIvr8g
データ記述言語としてのXMLもほとんどの用途はJSONに置き換わっとるし
Webだって生HTMLの記述を避けていかに楽するかにみんな試行錯誤しとる結果がフレームワークの乱立なわけで
もうマークアップがダメなのよ、XAMLというアイデアが生まれた瞬間からダメ
201デフォルトの名無しさん
垢版 |
2021/06/28(月) 08:48:33.34ID:nwjsCynN
Formsの臭いものに蓋をしたような裏のコードを見て
コレジャナイって気付かないもんかねえ
2021/06/28(月) 08:52:45.03ID:+h03On/r
>>160
2021/06/28(月) 08:55:18.72ID:yki3tuNE
うだうだ言ってもWPFが普及しなかったという事は事実
2021/06/28(月) 10:23:14.06ID:+h03On/r
普及するかどうかと優れたアーキテクチャかどうかは
全く別の話なのも事実
205デフォルトの名無しさん
垢版 |
2021/06/28(月) 10:28:27.83ID:2Oa7bDPq
ユーザー目線では遅い重い
開発者目線では面倒くさい難しい
MS目線ではやめたい捨てたい
206デフォルトの名無しさん
垢版 |
2021/06/28(月) 11:23:45.55ID:7XtL7Dy7
>>175
wxWidgets
2021/06/28(月) 11:38:04.11ID:yLrQOr5w
古代UNIX時代のマークアップ技術をなぜ未だに引っ張り出さなあかんねん。
2021/06/28(月) 11:46:36.50ID:kyJYPXM1
ウダウダと文句を垂れ流しておられる皆様方の理想のUI記述言語はどのようなものでございましょうか？
209デフォルトの名無しさん
垢版 |
2021/06/28(月) 11:57:00.05ID:bIZ7S0Sd
>>200
jsonでUI記述するC#Framewoek作れ
210デフォルトの名無しさん
垢版 |
2021/06/28(月) 12:00:01.72ID:bIZ7S0Sd
誤解されそうなので補足しとくが
漏れはjsonもxmlもxamlもうんこだと思ってる
2021/06/28(月) 12:09:14.53ID:MUa2ipuR
それはちょっと語弊があるだろ
どんなに優れたマークアップ言語の上にでも汚物のようなスキーマは構築できるってのが正しい
クソDSLを設計して喜んでていいのってそれこそ小学生までだよねーｗｗ
2021/06/28(月) 12:38:19.33ID:zyIZLp3R
>>205
ユーザー目線:
WinForms:遅い・重い・応答なし・見づらい・使いづらい
WPF:速い・使いやすい
開発者目線:
WinForms:低機能・手の施しようがない・バグ地獄
WPF:必要なものが一通り揃っていて現代の開発に耐えられる

WPF程度を難しいなんて言っているレベルは転職をお勧めする。
2021/06/28(月) 12:40:21.87ID:TdjQ7qGS
趣味でやってる人だろ
さすがにプロでそんな馬鹿はいないと信じたい
2021/06/28(月) 13:02:13.72ID:yLrQOr5w
>>212
技術者としてそういう捏造するようになったり終わり。人間のクズ。
2021/06/28(月) 13:12:45.57ID:yki3tuNE
>>204
優れていなかったから普及しなかったのでは？単純に
2021/06/28(月) 13:16:23.14ID:DPgYMhor
だよね
必死にWPFを持ち上げるよりもどこがダメなのか議論するほうが建設的
WPFマンセー厨の人達は黙っておいたほうがいい
2021/06/28(月) 13:20:14.01ID:x0F/IlHt
×優れている
○ある面では優れている

糖質だって探せばいいところの一つくらいはある
2021/06/28(月) 13:39:01.27ID:gSJxewSh
>>216
MVVMでやろうとした時の教育コストがネックかな。
俺一人でやるなら問題ないけど、プロジェクトの都度人集めてやるような会社だときつい。
2021/06/28(月) 13:59:28.09ID:BZRfVYEc
winFormsって重いの？
まあSQLseverの大量のデータを扱う場合はそうかもしれないけど
2021/06/28(月) 14:43:55.35ID:ajvVSSfT
C++=Delphi > VB6 >>> WinForms >>Java Swing
速度だけならVB6の方が早かったからな
2021/06/28(月) 14:44:45.33ID:C7ospGa2
>>215
逆。vbから続くwinデスクトップ界隈では優れている人の方が少ないから
低レベルな人でも使える低機能なものの方が普及しやすい。

>>218
それもWPFが普及しなかった要因。
必ずMVVMで作らなきゃいけないかのような圧力に
怯えて技術力の低い多数の人達が逃げ出してしまった。
まずはMVVM禁止で何個かプロジェクトやってメンバーの大半がWPFに十分なれてから次のステップに移ったほうがいい。
222デフォルトの名無しさん
垢版 |
2021/06/28(月) 15:32:52.13ID:21xV/8JF
>プロジェクトの都度人集めてやるような会社

日本終わってるωωω
2021/06/28(月) 15:37:52.28ID:NB7SrI88
>>212
WPFの方が遅いと言うのを良く聞くが。
224デフォルトの名無しさん
垢版 |
2021/06/28(月) 15:40:40.25ID:2Oa7bDPq
セレロン、MEM:2GBがノーマルお仕事環境だからな
225デフォルトの名無しさん
垢版 |
2021/06/28(月) 15:49:46.29ID:2Oa7bDPq
>>218
選択肢が多すぎるのも欠点だよね
VBぐらい選択肢がないほうが同じ事の再教育しなくて済む
2021/06/28(月) 15:52:23.31ID:D8GEhOn7
wpfスレッド大人気だな
2021/06/28(月) 15:55:45.51ID:JBMsD7o3
雑談スレじゃないのにここまで雑談で埋まってるスレは他にあるまい
2021/06/28(月) 16:17:13.79ID:HVgpozoE
ほとんど同じことを繰り返してるだけだしな
2021/06/28(月) 17:21:27.52ID:NB7SrI88
>>227
フフフ。Flutterスレがあるぞ。
2021/06/28(月) 17:22:15.07ID:NB7SrI88
あと、Rustスレも。
2021/06/28(月) 17:27:03.04ID:+NMrGGDR
WPFコントロール作ってるライブラリメーカーのガチプロは
はなから内部はMVVMとか使っとらんぞ
それが真実
一般向けに皮だけIF定義して対応させてる次第
製品で遅いのとか使えんからな
すまんの
2021/06/28(月) 18:29:08.91ID:TdjQ7qGS
質問スレにしたらマシになりそう
2021/06/28(月) 18:39:14.79ID:kyJYPXM1
質問者放置してのマウント合戦になるだけやろｗ
2021/06/28(月) 18:46:52.11ID:cZa6zFVz
>>231
そもそもMVVMってコントロールの内部で使うもんじゃないと思うが。
2021/06/28(月) 18:52:48.08ID:zyIZLp3R
>>223
Windows Formsのグラフィックシステムでは、最終的な描画のタイミングをアプリケーション自身が握っているため、
描画途中でディスプレイ更新が行われると意図していない崩れた描画が表示されてしまうことがあります。
一方、WPFのグラフィックシステムでは、最終的な描画のタイミングはWPFの描画エンジンが握っているため、
意図していない描画がディスプレイに表示されることはありません。
そのため、大量のコントロールを高速でスクロールしても滑らかに表示できます。

>>231
プロジェクトの種類に応じて開発手法を選ぶのは当たり前。
MVVMを使うのは端的に言えば開発スピードを上げるため。性能を上げるためじゃない。
(真のガチプロはMVVM使いつつ性能も担保するかもね)
2021/06/28(月) 19:00:07.66ID:TdjQ7qGS
gdiとか完全排除してdirect2dに置き換えたら良いのに
2021/06/28(月) 19:32:24.45ID:hSv3zN64
2021年にもなってWinFormsにしがみついてる馬鹿がいるってマ？
2021/06/28(月) 19:51:21.64ID:v/5H91nJ
MVVMで開発スピードを上げるってネタだろｗ

リスト出てくるとイラっとする
239デフォルトの名無しさん
垢版 |
2021/06/28(月) 19:51:47.71ID:uDpGdBC4
>>231
>>234が正解だから...
240デフォルトの名無しさん
垢版 |
2021/06/28(月) 20:07:50.55ID:9VZBfvKN
MVVMはともかく、高DPIとか要素のスケーリング対応はWinFormsでやりたくないな

ただまぁ、敷居が高すぎるとは思う
書籍はロクに見当たらないし、日本語でそこそこまとまったフレンドリーな解説が載ってるサイトほとんどないのは痛い
関連ワードで検索してもかずきか妖精しか出てこないでしょ
（この2つも途中からRxが入り込んできたりMVVM前提になってくるから脱落者多いと思う）
とほほとかdobonとかufcppレベルに噛み砕いた説明が欲しいのよ初心者は
241デフォルトの名無しさん
垢版 |
2021/06/28(月) 20:23:36.59ID:nwjsCynN
Formsおじさんはスケーリングなんて概念知らないよ
2021/06/28(月) 20:49:37.76ID:BZRfVYEc
スケールはマニフェストファイルにドットバイドットで起動するように
設定すれば問題ない
2021/06/28(月) 22:13:28.65ID:zyIZLp3R
>>238
テストや仕様追加・変更などトータルで見てもかなり差が出てくるぞ
244デフォルトの名無しさん
垢版 |
2021/06/28(月) 23:05:46.97ID:mF8S9I5g
>>242
それぼやけるやつじゃないの？
それともレイアウト崩れる方？
2021/06/28(月) 23:12:16.18ID:LklTdgPg
>>234
コントローラー部品はMVVMのVの部分だからね
2021/06/28(月) 23:20:59.79ID:+NMrGGDR
>>234
グラフ、ガントチャート、スケジューラーとか
一個コンポーネントだけでも
業務系アプリより小便チビるぐらいのガチの大規模アプリだぞ。

まあ開発者もCOMとかActiveX時代を経験しとる猛者だらけだが
2021/06/29(火) 00:00:20.95ID:MxyOwUyS
まったく関係ない。規模が大きかろうがコントロールをMVVMで設計する必要なんてあるわけがない。
2021/06/29(火) 01:16:51.07ID:cxwm0a1D
本家 Microsoft でさえ使っていないフレームワークだしな。Visual StudioのGUI部分くらいか？
2021/06/29(火) 01:24:48.79ID:88YgLK/8
MVVMで設計する必要が無いとは思わんが、
WPFはレイトバインディングオンリーだから性能を考えたら無いな
2021/06/29(火) 03:41:15.15ID:CE8RCsWG
xamlのUI自体が起動時JITだししゃーない
ユーザー編集や内部動作がオブジェクト〜UI間で速攻反映されるのがMVVM的とすると今時のやつほとんどそれにならんか？
やっぱいるか？
2021/06/29(火) 07:02:11.80ID:kZFmQOUI
>>244
ぼやけないし崩れないよ
ただしデメリットは4Kなどの高解像度ディスプレイを使っていると
ソフトを実行した時に文字やウィンドウが非常に小さく描画されると思う
場合によってはぼやけた方が使いやすいまであるかもしれない
2021/06/29(火) 07:23:16.58ID:7mrphVrK
>>246
×猛者
〇時代に取り残された老害
2021/06/29(火) 07:40:42.45ID:qRDQTSiV
>>248
グラフィックスデバッガのPIXとか現役で更新されてる小物じゃちょくちょく使ってる
2021/06/29(火) 08:18:17.69ID:MxyOwUyS
COMをマスターできたならその後の新技術もキャッチアップできるだろう。
当時COMについていけなかったような人が今WPFについてこれていないという感じじゃね。
2021/06/29(火) 08:44:28.90ID:ODoOJffm
>>248
WinFormsも使われていない件
2021/06/29(火) 09:01:08.59ID:SmSl8CvY
>>254
まあ難しいかもね
でもDCOMとかおもろいで
他人のPCにオブジェクトがnewできるwww操作もwww
2021/06/29(火) 09:56:34.25ID:sa7Hb+w6
>>251
スケーリングを無視して拡大せずに表示って
スケーリングから逃げてるだけで何の解決にもなってない
2021/06/29(火) 10:01:47.81ID:bpKPj1F0
今時WinFormsやWPFで作られるようなアプリなんて基本的に決まった環境で決まった操作ができればいいだけなんだから画面の美しさなんて誰も問題にしない
文字が小さすぎるなら解像度下げたらいいだけ
2021/06/29(火) 10:33:35.90ID:uY+Pqtpp
>>240
海外サイトでは有用なサイトとかあるの？
2021/06/29(火) 11:33:47.61ID:idc7ChZX
>>258
逃げてるだけやん。
画面の美しさなんかどうでもいいが
見やすさ、操作しやすさは品質チェックされる。
フォントサイズぐらいは変えられるようにしといたほうがいい。
たいした手間じゃないんだから。
2021/06/29(火) 13:36:43.26ID:sps6wUNa
>>259
英語読めないから知らない
2021/06/29(火) 14:15:00.34ID:bpKPj1F0
>>260
その「しといたほうがいい」程度のためにWPFやるの？さすがに費用対効果が悪すぎないか
そらみんなWebへ流れるわな
2021/06/29(火) 15:16:50.08ID:fjM4NkMz
>>262
そりゃwebが要件に合うならそっちの方がいいけど
デスクトップでやらなきゃいけない場合、
winFormsは生産性もアプリの品質も論外だから現実的な選択肢の候補としてWPFは有力。
費用対効果はwinFormsなんかを選ぶよりはWPFの方がずっと上。
2021/06/29(火) 16:30:43.80ID:m0EoJlPu
WPFよりwinformsがいいなんて言ってる奴いないのに何無駄なこと言い続けてるの？
なんでもかんでもxamlで書かせようとしたWPFはバカっていってるだけなのに
2021/06/29(火) 16:33:32.55ID:PN4ZOAJQ
いやこのスレにはいっぱいいるぞ？
2021/06/29(火) 17:52:19.00ID:S91QebJL
WPFで作るだけで品質も生産性も向上、よかったよかったw
2021/06/29(火) 17:52:53.44ID:SOQ8GKtA
* WinFormsの方が優れてるよ派
* XAMLは糞だよ派

自由に追加してってくれ
2021/06/29(火) 17:54:06.03ID:R64mVEcr
糞なのはMVVM派やぞ
2021/06/29(火) 18:06:05.47ID:wewaPA3V
彼はずっと頑張ってるんだけど
一向に何がどう上なのか提示しないのが笑える
2021/06/29(火) 18:14:53.74ID:SmSl8CvY
XAMLとMVVMの違いが解っとらん時点で...
2021/06/29(火) 18:41:43.87ID:d9qF3Zj0
馬鹿はwinformsはスケーリングがっていうけど事実上使用環境は2k固定
4k環境なんて企業ではほぼ出てこない

何かあればすけーりんぐがああああって言いたいだけだろ

そんなもの弱点でもなんでもない
4K環境でアプリを使いますかと聞いたら何それとかいいえってすぐに答えが出る
winformsの弱点はそれとは別にあるだろ
2021/06/29(火) 19:29:56.93ID:IWxlvq96
>>271
それ以外の弱点は余り聞かん。
2021/06/29(火) 19:34:10.99ID:D8AMOp4b
他人がすばらしいと思おうが糞と思うがどうでもいいだろ
そんな他人の意見気になるのかよ
このネタしつこすぎ
2021/06/29(火) 19:39:00.69ID:MZAvi10Y
4Kモニター使う客は見たことないけど、13インチFHDノートとかでスケーリング150パーで使う客はざらにいる。
2021/06/29(火) 21:06:07.80ID:uY+Pqtpp
WinFormsはバグが多いみたいな話は聞いたが踏んだことないな
2021/06/29(火) 21:50:16.02ID:88YgLK/8
>>271
最近問題になってるのはFHDのノートPC＋老眼
拡大しないと見えないって言われるけどWinFormだとだいぶ面倒
2021/06/29(火) 22:21:04.01ID:cxwm0a1D
そこで全てOwnerDrawですよ
2021/06/29(火) 22:44:16.86ID:SOQ8GKtA
>>273
15年やってるネタにしつこいだと！？
2021/06/29(火) 22:57:19.14ID:vxJRxXrh
老眼ならボケててもわかんねえしDPI Unawareでご提供じゃあ！
2021/06/30(水) 06:20:20.65ID:fPKzNzZo
>>275
winformは仕組み的にバグを作り込みやすい。
SOLID原則に則った作りがしづらいから。
2021/06/30(水) 10:33:14.92ID:ZQ555E+g
>>280
具体的にどうぞ
2021/06/30(水) 15:27:43.63ID:x8wFy7G1
DataGridのヘッダの結合かベータ行カラムの分割をしたいんだけどxamlだけじゃできないんだねこれ
2021/06/30(水) 21:16:42.52ID:HGlM55pW
>>277
オーナードローに手を出すぐらいならWPF使った方が簡単だし楽だぞ
2021/06/30(水) 21:43:59.63ID:YqdW0y/d
今時windowsアプリ作るならflutterでしょ
その次はcompose for desktop

シリコンバレーに住んでるけど周りだいたうそうだぞ
2021/06/30(水) 22:23:18.20ID:mq4i3ovj
MayaみたいなGUI作りたいんだがFlutterで問題ない？
2021/06/30(水) 22:49:25.75ID:dbpUo6lf
Visual Studioで作れるなら
2021/07/01(木) 00:50:28.07ID:cUgiTPJy
>>281
具体的も何もイベントハンドラしこしこ書いてたらそうなっちゃうでしょ
2021/07/01(木) 01:41:15.75ID:quMFgJi9
>>287
イベントドリブンだからハンドラは書くだろ
289デフォルトの名無しさん
垢版 |
2021/07/01(木) 02:25:59.60ID:3s4V0XuS
>>284
私のシリコンバレーではWinForms一強だがね
2021/07/01(木) 02:41:38.58ID:g7pLzwL6
WPFを推してる人に質問。

https://teratail.com/questions/45592
でベストアンサーの人がDataContextを
XAML
<OrigUI:OrigButton x:name="MyButton" DataContext="{Binding MyButton, Mode=TwoWay}" />
と
コードビハインド
MyButton.DataContext = myClass.MyButton;
の両方の例を見せているが、
両方で書けることのメリットは何？

自分はどっちか（この例だとXAML）だけあれば充分だと思ってる。
291デフォルトの名無しさん
垢版 |
2021/07/01(木) 03:48:23.98ID:3s4V0XuS
WPFにおいてXAMLは必須のものではない
2021/07/01(木) 05:03:15.49ID:DKvr+prV
ListViewとかの仮想化だけはデータテンプレート使わないと駄目そうだけどね
2021/07/01(木) 07:09:44.32ID:79OH3ZpR
>>288
それがformsの限界。

>>290
別にWPF推しじゃないけど、
XAMLはビルドの過程でC#コードに変換されるから
両方で書けるのは自然なことでは？
UIに関することはなるべくXAMLに書いた方がいいと思うけどね。
2021/07/01(木) 07:14:56.37ID:Yl2LhZPg
>>287
SOLIDなんて何も理解してなさそう
2021/07/01(木) 07:58:52.76ID:zoA/qoUb
>>290
後から動的に生成したい場合とか、コードで書けないと出来ないじゃん
2021/07/01(木) 09:03:54.60ID:BtHdEiN6
XAMLに記述すると横にびろーんと長くなって見づらい
2021/07/01(木) 09:06:48.81ID:jSC3+/HL
SRPやOCPを順守するには一般にレイヤの多い方が有利だから、むしろイベントハンドラの方がやりやすいまである
MVVMはVからMへイベントを伝播したりMの状態変化をVに反映したり依存関係を管理したりと、VMの役割が多くなりがちなんだよね
そのへんReduxなど後発の亜種ではより役割が整理されている
2021/07/01(木) 09:21:41.82ID:Z6twYu4c
>>296
xaml stylerというvisual studio拡張を入れなさい。
xaml保存時にいい感じに改行入れてくれるに適当な所で折り返してくれるパッシブスキルだ。
2021/07/01(木) 14:39:45.82ID:LLiHzSna
>>290
同じように見えるが依存関係プロパティ(xaml)とC#のプロパティは別々に定義しないといかんのだ（参照しているDataContext自体は同じ)
xamlUIクラスはDependencyObjectを継承しているのだ
2021/07/01(木) 19:04:08.19ID:g7pLzwL6
>>293
サンクス
なるほど、確かに両方で書けること自体は自然か

> UIに関することはなるべくXAMLに書いた方がいいと思うけどね。
そうだね
自分としては「両方で書けるけれども、こっちでしか書いちゃいけない」ってしてくれるといいんだけどな
複数のサンプルプログラムのいいとこどりをしようとした時に、それぞれが別々の書き方をしていると非常に面倒臭い、DataContextに限らず

以前、「全部コードビハインドで書く」っていうサンプルコードがあって、走らせるとちゃんと動作した
この調子だと、結局、毎回両方の書き方を覚えていかんなるんじゃない、特にいいとこどりするなら？
∴学習カーブが急だという説は正しい、というのも単純計算で覚えることが二倍だから

間違ってると思ったら気軽に指摘してくれ
2021/07/01(木) 19:09:07.26ID:g7pLzwL6
>>295
> 後から動的に生成したい場合とか、コードで書けないと出来ないじゃん

サンクス
入力が変わる度にDataContextを動的に切り替えるってことね
でも、XAMLじゃできなかったっけ？
（DataContextじゃやったことないけど、XAMLでListなんかの要素の変化した分も表示できるから出来るのかなーと類推してるだけだけど）
2021/07/01(木) 22:32:47.80ID:cUgiTPJy
>>300
サンプル見るときに何を参考にするか決め打ちするしかないね
俺はそうしていた
WPF始めたばっかりの頃はWinFormから移行を進めたくてイベントドリブン中心(これは結局失敗)
その後学習を進めてMVVM中心に切り替えた
MSのサンプルがイベントドリブンだらけなのが良くないよな
2021/07/01(木) 23:00:00.74ID:j2ilzMEK
>>302
そっちが基本なんだが...
2021/07/02(金) 11:38:56.90ID:VsUUVKi+
機能が豊富な分、全部覚えようとしたらそりゃ大変だ。
でも
ひのきの棒
剣・槍・斧・弓の欲張りセット
どっちかくれるって言うなら普通は後者を選ぶだろ?
まず手に馴染むものを使って
少しずつ他のものも触れてみるといい。
最初から全部に手を出す必要はないし、
最終的にも全部使えるようになっている必要はない。
2021/07/02(金) 11:50:23.46ID:Ngk5hsML
的外れな例え話は頭悪く見えるぞw
2021/07/02(金) 12:28:28.82ID:lSX3jk7y
おや？後ろに隠してるのは、棒かな？

www
2021/07/02(金) 12:40:53.27ID:Xm/bZCrF
>>304
先ずは初期装備のひのきの棒でスタートするだろw
2021/07/02(金) 13:05:21.63ID:VsUUVKi+
>>307
もらった装備は後から追加できないんだぞ
2021/07/02(金) 13:28:40.79ID:Egj0Aifo
そこで魔法でスキルアップだ
2021/07/02(金) 13:32:17.26ID:Vj99qG3J
もうやだ
2021/07/02(金) 14:04:17.52ID:KVWZHoQG
ここまでワテの自演
2021/07/02(金) 14:39:21.48ID:Qeilx2mY
wpf簡単チュートリアルテンプレートないの

DBとクエリだけ指定すればDataGridに出力してくれるとか
ボタンが配置してあってイベントに印刷とかExcel出力がすでにインプットされてるとか
2021/07/02(金) 15:38:08.34ID:VsUUVKi+
>>312
ほとんどwpf関係なくね？
2021/07/02(金) 16:32:41.92ID:Ir1tg0Tf
言語よりAccessのがいいんじゃね？
レポートは最強レベルの性能だし
2021/07/02(金) 19:19:58.89ID:s2SIGsrq
今時ローカルのDBなんて個人の小遣い帳にすら使い物になりません
2021/07/02(金) 19:42:12.79ID:Ir1tg0Tf
>>315
なにいってんの
サーバーに接続して利用すんの
一時期業務系の開発でよく見られた方式よ
2021/07/02(金) 19:49:38.81ID:9L+w52dS
SQLiteは使い勝手が良いのだが
2021/07/03(土) 04:36:22.66ID:DAcib8Yu
>>302
欲しいサンプルがさ、なかなか見つかんないんだよね
決め打ちできるほど選べないという・・・
その唯一見つかったサンプルたちが別々の書き方してると苦労する
自分はMVVMから学んで、あとでイベントドリブンを知った
2021/07/03(土) 04:59:48.16ID:DAcib8Yu
>>304
> ひのきの棒
> 剣・槍・斧・弓の欲張りセット
> どっちかくれるって言うなら普通は後者を選ぶだろ?

ディスるつもりはまったくなくけど、
なんか喩えがよろしくない気がする
どっちかくれるって、それは学習コストも含めて言ってる？
使いこなせること前提なのかな？
コンビニに行くのにヘリコプターは要らないでしょ？

WPFは使ってみて手に馴染まなかった
2021/07/03(土) 07:36:49.79ID:5NjsOhPI
>>319
徒歩しか選べないのと、ヘリコプターも徒歩も選べるのは全然違うよ。

WinForms的作り方でWPFを使えばいい。
バインディングもほとんど使わない。
それなら学習コストはほとんどかからない。

柔軟なレイアウトシステムとか
スタイルによるコントロールのプロパティ一括指定とか
学習コストが低くて便利なところだけつまみ食いすればいい。
2021/07/03(土) 09:09:34.76ID:WFYQtiF3
結局邪悪だったのは
WPFといったらMVVMみたいな記事を書いてたMicrosoftのブログとかMVP、なんだよね
山師みたいなもので
2021/07/03(土) 10:25:40.00ID:SKBAEND3
>>318
あとはもう書籍に頼るしか無いな
WPF関連の参考書は古いのばっかりだけど
WPF自体があんまり進化してないから2010年くらいのでも結構参考になる
2021/07/03(土) 11:00:07.13ID:IVHyImvm
取っ付きにくい→普及しない→資料が無い→

負のスパイラルだね
2021/07/03(土) 11:51:17.43ID:/7aEvID4
>>318
そりゃ酷い
普通こんな変態的なコード書かないよ

同じMSでもBlazorのMVVMの方がまともだ。

プロも考えてるなら
js覚えてReactとかやってみたら？
仕事多いよ。
2021/07/03(土) 13:31:50.48ID:xrPgyhkt
>>304
実際には、WinFormsが少し前の高級車で、WPFは、バックカメラを
搭載した軽自動車みたいな感じだろう。
速度が違うし、どっちがいいとも言えないような状態。
2021/07/03(土) 13:51:45.16ID:xrPgyhkt
>>325
もとい。
バックから見たいな画期的なものはWPFには付いてない。
せいぜい、短波ラジオが追加された軽自動車みたいな印象。
2021/07/03(土) 14:03:08.22ID:+Y9Mw3Lc
WPFってWindowsメッセージドリブンなアプリを作れないよね
2021/07/03(土) 14:03:10.68ID:SKBAEND3
そんなにWinFormが好きなのかｗ
2021/07/03(土) 14:22:06.46ID:+F8p4M2+
>>325
実際にはWinFormsがリヤカーでWPFがステーションワゴン
2021/07/03(土) 14:22:33.63ID:xrPgyhkt
WinFormsは、レンブラントやミケランジェロの作品の様に万人から一定の評価を
受けるようなものだが、WPFはピカソの絵みたいに人を選ぶ。
支持者には画期的で先鋭的なものらしいが。
2021/07/03(土) 16:12:05.88ID:kc73fFDc
いつまでWinForms vs WPFやってんの
ネタが尽きて妙な例えになってるし、いい加減にしろ
2021/07/03(土) 16:51:53.62ID:bc4tv4Cc
10年以上続けてる習慣にいい加減にしろだって！？
お前こそいい加減に止めることはできないって現実を理解しろよ
2021/07/03(土) 18:06:40.40ID:DAcib8Yu
>>320
やってみようかなという気持ちと
そっちの道も蛇の道では、または
それならWinFormsでいいんではないかという気持ちがある

WPFの扱いをユーザー側でどうこうするより、
MS側でバインディングを簡素化してくれた方が嬉しいかな
2021/07/03(土) 18:07:36.50ID:yLRyBVvw
自分が知ってるOSSでWPF使ってるのはEDCBぐらい
MVVMは使ってないようだけど
2021/07/03(土) 18:27:49.11ID:DAcib8Yu
>>322
ここ3年ぐらいで出版されたのを一冊買ってある
アマゾンで高評価だった奴
でも、欲しかった情報とちょっとズレてるんだよね・・・
もちろん有用な情報もあったけど
2021/07/03(土) 18:30:13.91ID:DAcib8Yu
>>324
> js覚えてReactとかやってみたら？

あら、今、正にそこ
そうだね、その方向性で行こう
2021/07/03(土) 19:20:53.81ID:l02BKdxs
今更、WPFを覚えるってのもね。
2021/07/03(土) 19:52:56.77ID:ApVtA7Dx
今ならWindows Runtime系の本でC#バージョン新しめのやつ探したほうが良い、あるのかは知らん(´・ω・`)
Xamlまでやるなら素直にPetzoldくんの6版
2021/07/03(土) 20:10:39.49ID:PF+2QSJm
マジか。WPF今から頑張ろうと思って色々調べているけど
正当進化のUWP?がズッコケてるのみるとこの技術に未来はないのかなとも思う
ただWPFのFormsにはない先端で綺麗なコントロールがあるからほっとけない
2021/07/03(土) 21:19:34.25ID:aubZqG39
今WPFを使う必要に迫られているのではなく将来を考えて勉強しようとしているなら、
さすがにそれはWebかスマホをやったほうがいいぞ
2021/07/03(土) 22:02:27.73ID:/7aEvID4
Reactの次のステップが
React Native for windowsでのwinアプリ作りだね

https://docs.microsoft.com/ja-jp/windows/dev-environment/javascript/react-overview#does-react-work-on-windows

https://microsoft.github.io/react-native-windows/
2021/07/03(土) 22:03:35.57ID:yLRyBVvw
今ネイティブアプリを作る理由は鯖を用意しなくて良いぐらい…
2021/07/03(土) 22:10:03.29ID:/7aEvID4
ネイティブアプリで自前ブラウザーを構成し、
本体アプリはReactで作成する
344デフォルトの名無しさん
垢版 |
2021/07/03(土) 22:13:34.86ID:yhsKzI36
>>339
趣味なら良いんじゃない？
慣れれば使いやすいから

フリーランスとかで案件が欲しいんだと微妙
345デフォルトの名無しさん
垢版 |
2021/07/03(土) 23:34:47.12ID:gAHM5nnh
>>339
WPFのxamlは多機能すぎるしとりあえず最低限でもいいから適当にやればいい
ただ、MVVMは他でも使ったりするからこっちを重点的にやればいい
2021/07/03(土) 23:35:31.59ID:yLRyBVvw
MVVMは他でも使うというのは語弊があるかと
2021/07/03(土) 23:36:48.07ID:gAHM5nnh
俺が勉強した時は最初はxamlに深入りしないで他でもいきるMVVMの方に力入れてモチベーションを維持した
2021/07/03(土) 23:38:42.00ID:yLRyBVvw
MVVM技術は袋小路で他に流用できないし思想も実装によって違う
MVVM自体はこれから捨てられる技術

開発＆テストしづらいのでFaceBookはMVVM否定してReactでFluxを使ってる
2021/07/03(土) 23:40:38.59ID:yLRyBVvw
MVVMが向いてるのは個人などの小規模アプリ
中〜大規模だと相互の関係が分かりづらくバグの温床になるので敬遠される
2021/07/03(土) 23:44:15.93ID:gAHM5nnh
andorid開発でもDataBinding+MVVMだし
flutterでもMVVMで作ってるし
最新のjetpack composeでもMVVM使う予定だけど

ただ、flutterなどデータバインディングない環境は自前でVとVMを接合しないといけないけど

すげぇ便利
2021/07/03(土) 23:46:01.95ID:f2jJT3fK
>MVVM技術は袋小路で他に流用できないし思想も実装によって違う

そもそもその手のアーキティクチャで他に流用できるものなんてどんだけあるかねぇ。
結局フレームワークごとそれぞれの考え方を習得しなきゃsならんように思うが。
2021/07/03(土) 23:55:56.96ID:gAHM5nnh
MVVMは基本、単に責務ごとにMとVとVMに分けて、オブザーバーパターンで状態変化通知して、xamlみたく組み込みのデータバインディングあればなおさらいいてだけじゃん

フレームワークによらず、アプリ全体をMVVMで設計できて
フレームワークによって違うのは主にVとVMと接合部分だけで
むしろ新しく覚えるのがそれだけなんだが?
2021/07/04(日) 00:12:28.55ID:YIai1OGN
MVVMは副作用がわかりにくいので更新順序などで結果が違うなどバグの温床になる
状態を考慮せず実装できるような気がするが実は隠れた状態があり
その状態自体が見えづらく制御しづらい
2021/07/04(日) 00:12:35.78ID:scRQ4YdL
むしろMVVMのV差し替えで別フレームワークに切り替えた実例見たことないけど何かある？
2021/07/04(日) 00:14:23.32ID:YIai1OGN
VとVMの切り替えはセット
2021/07/04(日) 00:20:28.59ID:pwN2nm3/
誰もさすがにコード共有までは言ってない
MVVMというアーキテクチャでUIフレームワーク変わっても同じように設計、実装できるといってるだけ

別にUIフレームワーク変えて一方向のデータフローが好きなら新しくfluxも覚えればいい
357デフォルトの名無しさん
垢版 |
2021/07/04(日) 01:13:39.87ID:arSMsrRy
MSもMAUIではMVU採用したみたいだけど
WinUIはどうすんのかな
358デフォルトの名無しさん
垢版 |
2021/07/04(日) 01:16:05.43ID:arSMsrRy
>>353
そういうこともあるけどナレッジが蓄積されるとバグのパターンと修正ポイントがすぐわかるようになる
大昔イベントドリブンの黎明期にも同じような事が言われて
古参が「ほらやっぱり逐次制御で書かないと分かんなくなる」と騒いだけど
その時も同じように解決されていった
2021/07/04(日) 06:27:35.14ID:pwN2nm3/
たぶんだけどmauiのMVUっても二つに分けてかんがえないと
まず、flutterなど今どきっぽく、UIをxmalではなくコードで宣言的に書けるってことだろ
で、おそらくjetpack composeみたくコードで書いた部分の状態を参照する部分は
オブザーバブルな状態の変更通知の購読、キャンセルはコンパイラサポートでコード自動生成？
flutterはここ自前でやらなきゃいけないので面倒

で、UIでイベントが発生したら、あとはそのイベントをどこに流すかだけでしょ

イベント発生時にViewModelのメソッド呼べばMVVMになるし
他の何かにしてデータの流れを一方向にすればMVUになるし

ただそれだけの話
2021/07/04(日) 06:30:16.24ID:pwN2nm3/
.NET MAUIでUIがxaml使わずにコードで宣言的にUIかけるように
なっても、UIのイベントをどこに流すかでMVVMにもほかのMVホゲホゲの何かにもなるし
ただそれだけ

俺が>>350のjetpack composeでやろうとしてることと同じ

想像だけどね
2021/07/06(火) 07:06:29.25ID:Mov0te+3
React Nativeはオワコン、PWAも手を出す価値なし？
2021/07/06(火) 09:51:25.64ID:RV/aERgl
VMとMをバインディングするからいろいろイビツになったり複雑になったりするんだと常々思う
2021/07/06(火) 09:58:12.53ID:1wxKYJ6u
違うだろ
2021/07/06(火) 11:18:59.50ID:xnJqtZB6
いや違わない
コードビハインドを使うなというアホまで出る始末
2021/07/06(火) 11:34:57.19ID:RV/aERgl
変更即時反映のUIって最近流行りじゃん、スマホでもWebでも最近ではWindowsの設定画面でも
あれUXとしては後退だと思うんだよね
でもMVVMから見ると素直に作れるんだよね

プログラマやってる俺ですら
あれ？ミスタッチしたんじゃね？
どこ変えたかわかんなくなったからキャンセルしたいんだけど？
って度々思うもん
2021/07/06(火) 12:07:19.74ID:1wxKYJ6u
>>364
ごめん
読み間違えてた
コードビハインドの件は同意
あれはBlendでポトペタするため
2021/07/06(火) 12:31:13.78ID:paV/EiqB
>>365
optimisticなuiって奴か？
俺あれ嫌いや
2021/07/06(火) 12:32:33.09ID:paV/EiqB
ああ違う
いちいちSaveとか押さんでも保存される奴か
あれは確かにデータフローに引っ張られてる面あると思う
2021/07/06(火) 16:37:57.56ID:ScK6t+pL
DataGridのColumnHeaderのボーダーがCellのそれと比べてほんの少し右にズレてるのは仕様？
2021/07/06(火) 21:30:26.20ID:YzLUI9DG
blenderおじさんまだいるのかｗ
371デフォルトの名無しさん
垢版 |
2021/07/06(火) 21:43:25.19ID:8gON5+RN
>>369
仕様　回避コード書いてるサイトあったな
2021/07/07(水) 06:26:07.20ID:mc7eJwPZ
>>365
変更即時反映が悪いわけじゃない。
直近で変えた項目の色を変える、設定変更のアンドゥをできるようにする等
いくらでも改善できる。
373デフォルトの名無しさん
垢版 |
2021/07/07(水) 07:59:44.80ID:aJu+QZ75
設定を他人に伝えるとき即時のほうがありがたい
適用ボタンを押す指示はないほうがいい
2021/07/07(水) 10:28:43.71ID:Q3P1Rq1L
>>372
やってないじゃん
2021/07/07(水) 12:02:11.13ID:Lzprbr4S
>>371
仕様か
昔の立体Win32スタイルの名残でズレてるってことなんだろうな
2021/07/07(水) 14:14:24.07ID:8DbHlE2J
>>373
大体、そういう説明が理解出来ない人は低IQか初心者。
慣れた人には適用ボタンが有った方が便利で安心。
Windowsは少し高IQな人に向いている。
モバイルは万人向けなので、普通IQや低IQの人が使える様になっているが、
むしろ機能としては不便になっている。
377デフォルトの名無しさん
垢版 |
2021/07/07(水) 15:07:54.70ID:49748z4f
>>376
++
2021/07/07(水) 15:28:42.41ID:oUueiKD3
>>376
☆★★★★
2021/07/07(水) 15:35:09.52ID:Q3P1Rq1L
既存のモデルにコンソールのガワを被せるためにMVVMを採用
バインディングのためにモデルをバインディング仕様に改造

もうこれがイビツ極まりない
UIフレームワークの都合に合わせてモデルを変更するとか気持ち悪すぎる
2021/07/07(水) 16:51:39.11ID:tPYXmU6j
>>379
★★★★★
2021/07/07(水) 18:05:12.08ID:AWE9BvFy
個人的にはせっかくバインドする仕様にしたんだから、デフォルトをリアクティブに寄せれば良かったのにと思う
webのJSフロントエンドフレームワークとかみたいに感覚的じゃないんだよね
2021/07/07(水) 18:20:21.95ID:mc7eJwPZ
>>376
典型的な低IQ無能プログラマ。
そんな甘ったれた考えだといつまでたっても底辺から上がってこれないぞ。
2021/07/07(水) 18:24:35.65ID:mc7eJwPZ
>>379
何か作り方おかしくないか？
UIそのものやUIフレームワークを除外した残りがモデルなんだから。
384240
垢版 |
2021/07/07(水) 18:36:42.16ID:OWcilrjN
>>381
ReactiveUI+乱立してるMVVMフレームワークから1つ決めて公式実装にしてほしいわ
というかぶっちゃけAvaloniaの方向性で良いので、買収して開発リソースぶちこんでくれ…
2021/07/07(水) 18:39:51.64ID:Q3P1Rq1L
>>383
それがUIの都合で汚染されるのがイヤだって言う話
2021/07/07(水) 18:56:02.35ID:mc7eJwPZ
>>374
変更即時反映がUXとして後退と主張するから違うと指摘したまで。
例えばVSCodeの設定UIはデフォルトから変えた部分は印が付く。
2021/07/07(水) 18:59:32.38ID:mc7eJwPZ
>>385
なぜVMに書かない
2021/07/07(水) 19:37:01.71ID:Q3P1Rq1L
>>387
？
389デフォルトの名無しさん
垢版 |
2021/07/07(水) 19:54:05.96ID:aJu+QZ75
>>376みたいな人間がUXを語るべきじゃないな
感性も腐ってそう
2021/07/07(水) 20:56:03.54ID:85qcEXGX
開発者のエゴイズム丸出しでいかにもWPF好きらしくていいじゃん
2021/07/07(水) 21:01:06.97ID:opTZ3hwS
WPFって見た目がカラフルでもUIデザインの基本的なプロトコルはクラシックなWinアプリのままなんで、
画面遷移とか作り込んで完全にWebやスマホ風にしてしまうのでもない限りは即時反映はかえって混乱を招くと思う
392デフォルトの名無しさん
垢版 |
2021/07/07(水) 21:03:20.07ID:aJu+QZ75
彼はむしろWPFアンチだよ
冗長くんだもん
2021/07/07(水) 22:28:03.79ID:SoF9c5HC
>>388
バインディングの都合を満たすのはVMの仕事で、Mの独立を保つ為に犠牲になる係でしょ？
2021/07/07(水) 23:12:07.60ID:1XrHuH3i
しかし、Modelの一部をINotifyPropertyChangedやReactivePropertyに変えるなど
規模にもよるが小一時間の仕事だろうに

使いたくない理由を無理やり探しているんだろうね
2021/07/07(水) 23:14:24.01ID:O/p4KsNN
INotifyPropertyChangedなんてWinFormでも使うだろうに
何のためのモデルクラスだったんだろう
2021/07/08(木) 07:47:22.54ID:/EVL8M+q
>>394
手間の問題じゃなくて
なんでUIフレームワークの都合でモデルをいじらなきゃならんのかって話
2021/07/08(木) 07:53:01.19ID:0NJb5JqL
WPF使う場合はやはりモデルから対応しなければならない
それが嫌なので躊躇してしまう

モデルが依存関係を除去したところでINotifyPropertyChanged実装しないといけない
2021/07/08(木) 07:57:14.43ID:hcvY/pCa
>>394
なんで
INotifyPropertyChanged
ReactivePropert
みたいのがmodelにあんの？(;´д｀)
2021/07/08(木) 11:13:00.38ID:h5za3xa1
MVVMで作ればINotifyPropertyChanged実装しなきゃいけないのはUIとバインドするViewModelだけだぞ
ModelをObservableにしたければ、独自のObservableインターフェース使えたければ使えばいいじゃん
Modelは無理にINotifyPropertyChanged使う必要はない
2021/07/08(木) 11:17:20.04ID:h5za3xa1
つか、要件としてModelをObservableにするならUIフレームワーク関係なく
何かしらのObservableインターフェースが必要になってくるんだが

他のフレームワーク、言語使っても同じなんだが頭大丈夫??
401デフォルトの名無しさん
垢版 |
2021/07/08(木) 11:40:47.13ID:dQrLp+p1
そのへんフィールドをプロパティにするだけで全部やってくれてたらもっとユーザー増えただろうな
2021/07/08(木) 11:43:27.90ID:h5za3xa1
INotifyPropertyChangedの実装がWPF特有の問題だと思ってるあたりが頭おかし

他のUIフレームワークでもモデルの変更に応じてUI変えるなら、Observeする仕組みが必要でINotifyPropertyChangedに相当する機能をどのみち実装しなきゃいけないのに

>>396,397
君は他のUIフレームワーク使ったときにどうやって実装するわけ??
2021/07/08(木) 12:47:08.14ID:hcvY/pCa
>>402
明示的なコード書かなくても
フレームワーク側でバインド解決できるのが
普通のMVVM
2021/07/08(木) 12:57:43.95ID:h5za3xa1
そういうフレームワークの具体例を1個上げて
2021/07/08(木) 13:10:14.80ID:/EVL8M+q
>>402
WPFみたいなバインディングはしません
406デフォルトの名無しさん
垢版 |
2021/07/08(木) 13:15:55.68ID:h5za3xa1
>>405
WPFみたいなバインディングしなくてもモデルをObservableにするならどの道何らかのインターフェースが必要になるって話をしてるんですけど理解してますでしょうか??
2021/07/08(木) 13:26:17.14ID:UhDpZcYs
>>398
通知のためだけのインターフェースがボコボコ増えてくのが嫌だからさ
全てRxのIObservableならよかったな
つかWPFもバインディングエンジンの部分をプラガブルにしろよな
なんでINotifyPropertyChangedみたいなクソにしがみついてるのか理解しかねるね
2021/07/08(木) 13:27:17.81ID:UhDpZcYs
てか今後新しい通知インターフェースを宣言した奴は死刑でいいよ
殺す
2021/07/08(木) 13:31:44.36ID:WFCJSrYx
趣味でやってるだけだからよくわからんけど同じプロパティー２回書かせるのやめてくれ
めんどくさい
2021/07/08(木) 13:37:39.15ID:hcvY/pCa
>>407
メリットは外だしなんで
カスタマイズして
オレオレ仕様に出来る以外ない
2021/07/08(木) 13:43:42.57ID:h5za3xa1
.net mauiのMVUってINotifyPropertyChangedの仕組み乗っかるの??
ブログの例ではState<T>とかあるけど
State<T>ならjetpack composeと同じやん
2021/07/08(木) 13:52:37.12ID:/EVL8M+q
>>406
だからバインディングはVVMまででいいって言ってんじゃん
413デフォルトの名無しさん
垢版 |
2021/07/08(木) 13:54:52.32ID:icewyiWh
これでいいじゃん。using追加してAnnotation付けるだけだよ
https://www.reactiveui.net/docs/handbook/view-models/boilerplate-code

[Reactive]
public string Name { get; set; }
2021/07/08(木) 13:55:12.53ID:Y0QirsOb
まあ他の言語のFWはばかでも書けるけど、
ことWPF含めMS主導のは一部の細かい主張に答えるためか、
やることが回りくどいんだよな
FW使ってるのに書くことが多いと言うか
415デフォルトの名無しさん
垢版 |
2021/07/08(木) 14:00:41.26ID:h5za3xa1
>>412
じゃあ、モデルでは好きなObservableインターフェース使えばいいじゃん
独自でもRxでもご自由に
2021/07/08(木) 14:05:52.94ID:/EVL8M+q
>>415
うわ頭悪そう
2021/07/08(木) 14:35:39.28ID:zQs4IMMf
>>404
case: knockout.js

<span data-bind="text: viewModel.value1"></span>
418デフォルトの名無しさん
垢版 |
2021/07/08(木) 14:48:13.57ID:h5za3xa1
>>417
それ全然違うから...
2021/07/08(木) 14:51:52.72ID:zQs4IMMf
>>404
case: React

<span>viewModel.value1</span>
2021/07/08(木) 14:57:32.77ID:h5za3xa1
>>419
>>417と同じのりで挙げてるならこれも違う
2021/07/08(木) 16:00:11.32ID:zQs4IMMf
>>420
おお、すまん
訂正

>>404
case: React

<span>{viewModel.value1}</span>
2021/07/08(木) 18:03:12.85ID:hcvY/pCa
>>404
case: Vue.js

<span>{{viewModel.value1}}</span>
2021/07/08(木) 18:32:35.94ID:0NJb5JqL
h5za3xa1は世間知らずのWPF至上主義者なんだ

許してやれとは言わないが冷たい目で見ればいいよ
2021/07/08(木) 18:33:09.06ID:hcvY/pCa
>>404
case: Blazor

<span>@viewModel.value1</span>
2021/07/08(木) 18:35:59.60ID:0NJb5JqL
ここからまたプロパティで書くべきかどうかみたいな話になるのだろうか

recordの仕様と実装が中途半端だから解決法にならない
2021/07/08(木) 18:45:37.60ID:hcvY/pCa
>>404
実はWPFでもstaticだけはObservableの実装無しでいけたりします。
なのでModelの直バインドも可能です。
更新はコントロールを強制再描画すれば良い。

case: WPF(static only)

<TextBox Text={x:static viewModel.value1}/>
2021/07/08(木) 19:30:36.43ID:3cBmXvB1
なんでView-ViewModelのバインディングの事例を並べてるの?
Modelの話じゃなかったっけ
2021/07/08(木) 19:48:49.81ID:0NJb5JqL
person.Nameみたいなのにバインディングされていて
Name変更時に通知する仕組みはモデルの責任じゃないけどそれが必要になる

他のフレームワークのように別の仕組みが通知するのが普通
WPFは普通じゃないし劣っている
2021/07/08(木) 20:03:20.69ID:h5za3xa1
だから、「WPFも同じことできてWPFも当てはまる」から
>>417,>>419全部間違っているっていってんのに
何いってのお前？アホ？？
ちなみにWPFの場合は
<TextBox Text={Binding Path=viewModel.value1}/>
2021/07/08(木) 20:04:13.12ID:h5za3xa1
>>426宛ね
2021/07/08(木) 20:26:48.87ID:/EVL8M+q
引っ込みつかなくなって可哀想
2021/07/08(木) 20:35:30.05ID:h5za3xa1
>>428
その通り

>>402をうけての>>403だから、
「変更時に通知をする仕組みを一切実装する必要なくフレームワーク側で全部かってにやってくれる
」ようなこと>>403が言い出すからそういうフレームワークがあるならあげろっていってんのに

なんでどれも変更時に通知する仕組みを実装する必要あるフレームワークあげてんだよ

変更通知しないなら、WPFだって>>429で書いたようにINPC実装する必要ないしそんなフレームワーク
を挙げろっていってない
2021/07/08(木) 20:42:51.18ID:0NJb5JqL
person.Name見たいのはいつ変更したかなどはわかりやすいが
普通のクラスなどはいつどこで更新したのかが非常に追いにくい

目視でバグが確認できたとしてそれがどこで変更されてるのかがわかりにくい
バグがつぶしにくい
2021/07/08(木) 20:51:56.44ID:h5za3xa1
とりあえず、

読解力ないバカが多すぎってのだけはわかった
2021/07/08(木) 21:02:34.08ID:/EVL8M+q
やったじゃん
俺以外みんなバカ宣言して精神的勝利だ
2021/07/08(木) 21:07:38.15ID:FRcNf1lv
まぁ「俺の言いたいことを理解してくれない奴」は多いよな、いつでも。
2021/07/08(木) 21:17:18.89ID:UhDpZcYs
真の天才は死んでから評価されるのさ
2021/07/08(木) 22:41:40.59ID:j2+tCvGN
Mに変更通知機能無いって大変そうだな
2021/07/08(木) 23:02:26.20ID:hcvY/pCa
>>変更時に通知する仕組み

MVVMだから変更を監視する巧妙な仕組みがあって
（フレームワークによって思想が違う）
その仕様にのっとって適時勝手にバインドが動作する
のでコードは増えない
2021/07/08(木) 23:53:25.76ID:SSutR7CK
MをPOCOで作りたがる人いるよね。通知を実装するのも嫌がる。
2021/07/09(金) 00:11:25.67ID:hwC1YyL2
個人的には
(client: view, view-model)~network~(service: model)
としてる
入力バリデーションもmodelのみだ
へんかな？
2021/07/09(金) 00:39:31.73ID:fR2pG3Vk
>>440
それは世界の常識
WPFのMがおかしい
2021/07/09(金) 07:02:13.37ID:/l05Ymia
>>442
いや、WPFのMもPOCOで作るのが常識。
2021/07/09(金) 16:02:03.33ID:pQ/i3/CL
朕はPOCOなり
2021/07/10(土) 01:49:25.85ID:Is4zF1A7
ふーん
POCOでModel変更感知するのって面倒じゃない？
2021/07/10(土) 01:58:32.76ID:ZqXyUc92
POCOってなーに？
2021/07/10(土) 06:16:51.11ID:321/A5HW
Modelで変更通知なんかしない。
VMとMの区分けすらできないならMVVMで作らなきゃいいのに。
2021/07/10(土) 09:14:28.45ID:nAGZi/ZP
田舎者がなんか言ってるぞ
2021/07/10(土) 09:27:48.37ID:Rzopl14C
>>447
Modelの変更はどうやってViewModelやViewに反映されるの?
2021/07/10(土) 09:43:48.41ID:16vz6VAu
PODのようなものと混同してんのかな。
POxOから外部に何らかの通知をするのは別に普通だろ。依存の方向とか強くなりすぎるなとか一般的な注意をするだけ。
2021/07/10(土) 10:05:00.92ID:9ZKehVN0
>>449
Reduxならプロパティ変更イベントは必要ないよ
2021/07/10(土) 10:17:17.62ID:Rzopl14C
>>451
例じゃなくて仕組みを知りたい
VM側からポーリングでもしてるの
2021/07/10(土) 10:21:20.73ID:Cpxz5fTv
M自身が能動的に処理を行うことは無い。
Mに対してはVMから変更かける。通信やDB操作は外部プログラム（dll等）の役目だし、
ちょっと規模が大きいアプリなら外部通信などの処理は別プロジェクト（dll）にまとめられてるはずだろ？
外部プログラムが何らかの処理してMを変更し、外部プログラムの処理結果はVMでイベントハンドリングして
UIを更新する
2021/07/10(土) 10:29:02.22ID:Cpxz5fTv
VとVMで1つのプロジェクト（UI担当）
Mと通信処理などをまとめて1つのプロジェクト（System.Windowsを参照しなければ汎用ライブラリ）として
.net core等でも使用可能）
もちろんVMからSQL文を発行することもある

日曜大工レベルのアプリならVMの中で通信処理などビジネスロジックを全て含める
2021/07/10(土) 10:37:32.94ID:16vz6VAu
>>452
更新されたMが自発的にイベントを発火するか、VからMを更新するアクションが発生する毎に更新後のMの値を取りに行くかの違い。
flux/reduxのような一方向データフローでモデル更新がシリアライズされているから実用になること。
2021/07/10(土) 10:54:10.61ID:Rzopl14C
V以外からMが更新される場合は、Mを更新した処理とVMが強く結合されるってことね
2021/07/10(土) 10:56:13.18ID:KTvmhX8f
Mの発火をVMが受け取りまた発火、Vが描画とか手間かかるしチームで案件やってると教育コストもかかる。
技術に疎いマネージャーだとクリックイベントに全部書けやとか言ってくるんだよね。
2021/07/10(土) 11:07:48.66ID:16vz6VAu
>>456
flux/reduxについて言えばアクション自体への結合は不要。
基本的にMは全部単一のストアにまとめられていて、どこかが更新されるアクションが発生したら全員でMの更新を見に行くような感じ。
2021/07/10(土) 11:09:30.03ID:owBtnLy3
>>456
モデルにぶら下がってるVMはフレームワークが把握しているから、フレームワークにMの更新メッセージを投げるだけだよ
2021/07/10(土) 11:13:06.20ID:owBtnLy3
なおMのどのプロパティが更新されるかの特定も不要で、VMはあくまでMの現在の状態に対する関数として更新後のV全体を出力するだけでいい
あとはフレームワークがよしなに差分を取って変更を反映してくれる
2021/07/10(土) 11:14:26.03ID:Is4zF1A7
Mへの更新は全部フレームワーク経由で実施するってことか
フレームワーク君頑張るなｗ
2021/07/10(土) 11:17:08.14ID:2DdNTqcD
>>461
更新されたMをフレームワークに通知するだけだ
フレームワークの責務はメッセージのルーティングに過ぎなくて、Mがフレームワークの配下にいなきゃいけない訳じゃないよ
2021/07/10(土) 11:26:26.12ID:uwFcR1va
ちなみに>>453,454はただのMVVMだよね??
2021/07/10(土) 11:28:40.75ID:Rzopl14C
V以外でのMの更新自体はM寄りの処理だよね
Mの各プロパティから個別に更新通知が行くか、代表して更新通知が行くかの違いであって
Modelからの変更通知が無いってのはちょっと違うな
2021/07/10(土) 11:35:14.88ID:owBtnLy3
>>464
ルーティングの責務をM自体ではなくその外で持つことで、M自体を汚さなくて済むようになった
メタ情報を外出しするという点ではEFのPOCOなんかも似たような仕組みだな
466デフォルトの名無しさん
垢版 |
2021/07/10(土) 11:43:48.27ID:Is4zF1A7
>>462
フレームワークはMが更新されたことをどうやって知るの？
2021/07/10(土) 12:19:02.06ID:uwFcR1va
>>466
ああ、わかったただのMVVMの変種か
今までだって、MVVMで作ってた時はModelでimmutableなのをあったけど、
イメージとしてModelを全部immutableにして、ViewModelのほうに全部押し込めって話か

極端な話Modelを全部immutableにして、後のつじつまあわせは全部ViewModel(Store)で全部やれってことww

負荷が全部ViewModel(Store)にいくってことじゃね??
2021/07/10(土) 12:32:05.86ID:uwFcR1va
今までだって例えばMVVMでTwitterアプリを作るとき
まず、汎用的なTwitterAPIを叩いてPOCOを返すだけのライブラリを作って(A)

(A)を内部で使ったModelを作る
必要ならここでINPCの変更通知を実装(B)

で、後はViewModelをつくるだけど、

(B)をすっとばして、ViewModelで(A)を使ってここですべてやる

こんな感じ??
2021/07/10(土) 12:35:43.17ID:uwFcR1va
だからそもそも今までだってどこのModelか知らんが(A)の部分は汚染されてないけどな..
二つ似たようなの作ってるが..
2021/07/10(土) 12:52:18.73ID:uwFcR1va
もちろん、Modelをmutableにしてもいいけど、ViewModel(Store)内でModelを直接更新するからModelの変更通知機能は全く必要なくて、更新後ViewModel(Store)がViewに状態が変わりましたよって通知できればいい

やっと理解できました
ありがとう
2021/07/10(土) 15:15:27.78ID:xJQjD86t
mvcやらmvvmやらに全てあてはめようとして考えて、
訳わかんない考えに染ってるのばっかだな
2021/07/10(土) 15:53:06.08ID:fmB/UGP2
まあデザインパターン病と同じ。
2021/07/10(土) 16:12:10.43ID:xJQjD86t
>>470
これが何も知らない新人君でもやる普通の実装なんだがな
2021/07/10(土) 18:17:59.49ID:Is4zF1A7
>>470
そうすると複数のビューで一つのモデルを参照しているようなときは
ひとつのVMだか何だかが複数のビューと対話するん？
2021/07/10(土) 18:34:12.08ID:X6uqNK3l
というかこれって答えあるのか？
2021/07/10(土) 18:37:01.39ID:yemPkoko
オブザーバーでも
イベントでも
好きなパターンで実装すればよろし
2021/07/10(土) 18:52:36.88ID:T1N+jIqA
>>470
それは間違いだよｗ

VMにM更新のロジックを書くなよとｗ
VMごとにロジック書いて不整合があってバグ発生するだけ
2021/07/10(土) 18:54:15.71ID:T1N+jIqA
VMからMにはメッセージのみ送る

馬鹿はVMからMをいじる
2021/07/10(土) 18:57:20.02ID:T1N+jIqA
WPFで本気でMVVMやりたいならMに通知もみんな書くんだよ
これがモデル汚染

最近はビジネスロジック層を作ってお茶を濁してるけどそれも結局通知はどこなのか普通に迷うところ
2021/07/10(土) 19:16:41.13ID:uwFcR1va
>>479
>WPFで本気でMVVMやりたいならMに通知もみんな書くんだよ
MVVMの話でいいならそれはrigaya?が勝手に言ってるだけだぞ
別に正解の定義なんてないだろうしどっちが正解とは言
言わんが

Modelのメソッドは結果を返さず、メソッドの呼び出しの結果、自身の状態(プロパティ)を変更するだけってやつだろ
2021/07/10(土) 19:28:32.13ID:xJQjD86t
フレームワークの方法論は
その開発者が一方的に押し付けてる理屈なのに
気づけない馬鹿
2021/07/10(土) 19:35:48.59ID:T1N+jIqA
違うよ
知性の問題だ
それが理解できない馬鹿がバグを量産する
2021/07/10(土) 19:36:54.45ID:T1N+jIqA
馬鹿が自分が馬鹿でないと思って偉そうに何年もクソコードを書いてMVVM最高と言ってるだけだ
2021/07/10(土) 19:38:06.79ID:uwFcR1va
うん、rigayaは開発者じゃないしね
2021/07/10(土) 19:40:04.65ID:T1N+jIqA
>>484
うがやじゃなくてお前ともう一人が馬鹿なんだ

やっと理解できましたじゃねーよ
2021/07/10(土) 19:43:32.20ID:xJQjD86t
modelとviewModelの責務分けは
馬鹿には出来んよなーー
2021/07/10(土) 19:47:15.76ID:uwFcR1va
外人でrigayaと同じ主張してる人見たことない
Modelで通知をするのが普通とか言ってるのはお前が勝手に思ってるだけ

>>481でMVVMを本当に作った人が特定できるならまずそれを特定してくれ。で、Modelで変更通知を実装するのが普通ってどこに書いてあるか教えてくれ
2021/07/10(土) 19:52:15.95ID:uwFcR1va
もちろん、ViewModelはビューの状態を保持し、Modelに対してはModelのメソッドを呼んで
ビューに関するロジックを書くだけだぞ

Modelに変更通知機能あるかないかは全く関係ない話

勝手にModelに変更通知があるのが普通と思ってのはお前
2021/07/10(土) 19:52:27.91ID:xJQjD86t
フレームワークつかうと
やっぱ宗教じみた変なのが誕生するなーー

まずはプリミティブなライブラリのみ使用して
デザインパターンとか理解してみる事をおすすめする
2021/07/10(土) 20:01:26.66ID:16vz6VAu
>>478
「メッセージのみ送る」と「いじる」の違いはこいつの頭の中にしか無いんだろうな。
2021/07/10(土) 20:06:44.05ID:uwFcR1va
MVVMでViewModelの責務は>>488なだけ

Modelが変更通知を実装するしないかは関係ない

MVVM黎明期、rigaなんとだけが日本で声上げたからあいつの馬鹿信者が増えたんだろう
しかも日本だけ笑い
2021/07/10(土) 20:17:00.58ID:MxfUHgdm
だから>>362で最初からバインディングはVVMまででいいって言ってるじゃん
何をそんな喧嘩腰で議論する必要があるのか
2021/07/10(土) 20:23:04.54ID:xJQjD86t
“model” と “view、viewModel” の開発者は
分けた方がいいかもな

modelだけで業務が回せるようになってればいいだろ
実際modelはpythonで実装するの増えて
担当者も異なる事が多いわ
2021/07/10(土) 20:43:24.78ID:Is4zF1A7
>>492
バインディングの話じゃないって分かってない？
2021/07/10(土) 20:55:14.46ID:MxfUHgdm
>>494
え？変更通知なんだから要はバインディングの話でしょ？
2021/07/10(土) 21:06:48.12ID:o3oxPhaH
今日だけで50レスも進んでるのか
ヒマすぎだな
2021/07/10(土) 21:45:12.95ID:uwFcR1va
例えば、ModelがImuutableでINPCを実装しないとするよ。で、Modelの更新はModelのメソッドを呼んで、
メソッドの戻り値として新しいインスタンスを返すとする
class Model {　// ImmutableなINPCを実装しない
　public Task<Model> UpdateAsync() <-　新しいインスタンスを返す
}

で、ViewModelから更新かけるとき、更新後、最新の情報に更新する必要あるなら、それは
あくまで表示の都合だから、ViewModelにそのロジックを書いて問題ないだろ？？

class ViewModel {
　public void Hoge() {
　　var result = await model.updateAsync()
　　// resultの結果を元にViewModel更新
　}
}

ModelがINPCを実装するかなんて本来はMVVMには関係なく俺にはこれも立派なMVVMにしか見えねぇわww
2021/07/10(土) 21:59:07.18ID:uwFcR1va
もちろん、MVVMの厳格な定義なんて知らないし、極論すれば言葉の問題になるから
どっちが正解なんて言うつもりはないが、

rigaなんとか的に
「ModelはINPCを実装して、Modelのメソッドは戻り値は返さないで、
メソッドの呼び出しの結果自身の状態を変更し、INPC経由でViewModelに通知する」
で

おまえらこれだけがMVVMだと思ってるだけじゃんw
2021/07/10(土) 22:07:37.44ID:321/A5HW
>>497
うん、これが王道の作り方
2021/07/10(土) 22:14:04.55ID:uwFcR1va
悪いけど売られた喧嘩で言わしてもらうが
>>485,486,490

はバカ三兄弟だわww
2021/07/10(土) 22:54:51.35ID:x1ppTpnc
ID:uwFcR1va
この人のサーバーサイドには
何が実装されてるのだろうか...
2021/07/10(土) 22:55:10.24ID:16vz6VAu
>>500
なりほど、お前さん>>478の言う「メッセージのみ送る」と「いじる」の違いが理解できるならちょっと説明してみてくれないか。
2021/07/10(土) 23:07:03.07ID:uwFcR1va
>>502
あ、ごめんひょっとして間違ってたら謝るわ

>>490って俺に対するあてつけ？じゃなかった？？
ただの>>478へのレスなら謝るわ。すみませんでした。

つか、あとrigaじゃなくてググるとugaだったw
2021/07/10(土) 23:59:12.78ID:Wb8JMrdb
awaitはasyncが必要だろう。
2021/07/11(日) 00:15:04.56ID:BeeJLMuH
読みづらいからよ
続けるなら名前欄にスタンスを書いてくれないか
2021/07/11(日) 01:46:58.32ID:2ghBsept
やっぱりWPFはめんどくさいなw
507デフォルトの名無しさん
垢版 |
2021/07/11(日) 02:11:56.24ID:vIt/TVMn
>>495
そこまで話を広げるとMに通知機能があろうが無かろうが全部バインディングだろうよ
今問題になってんのはVはVMに依存してる前提で
VMとMの問題だと思うんだが違うんかな
508デフォルトの名無しさん
垢版 |
2021/07/11(日) 02:13:20.15ID:vIt/TVMn
>>506
WPFはめんどくさいっていうのが他の後発フレームワークとの比較なら分かるけど
WinFormと比較するんだったら比べものにならないくらい簡単だぞ
2021/07/11(日) 02:52:00.72ID:OgOa7vqd
>>508
ほんまかいな
2021/07/11(日) 02:59:38.37ID:bArpP16/
楽⇔面倒
簡単⇔難しい
単純⇔複雑
区別できない奴多すぎでは
2021/07/11(日) 08:40:13.02ID:x50DSKku
>>501
予想
ID:uwFcR1va 氏の構成

(client)
View
ViewModel
Model
Database Client Library


↑↓

(server)
Database Server
2021/07/11(日) 12:56:04.27ID:qjFfZwWG
一人ホームラン級の馬鹿がずっとレスしてるだけだな

MVVMでMから変更通知出すのは当たり前
VMでモデル変更して通知と言うけどモデル内で変更が生じた場合VMが変更通知出してるのかｗ？

VMは画面ごとに作るけどMに対応した処理はどこに書かれるんだ
まさか画面ごとか？
2021/07/11(日) 13:02:33.38ID:qjFfZwWG
MVVMが便利なのはMを操作すると通知が飛んで画面更新通知を自分でしなくて良いところ
それをVMで自分でやると言うのだから無意味なMVVMに感じる

VMで手作業の通知忘れるとバグが出る
Mに通知機能があれば通知忘れバグはない
2021/07/11(日) 15:05:54.19ID:otJ/Srhp
>>512
これは自分がホームラン級のバカと気づいていないバカ
515デフォルトの名無しさん
垢版 |
2021/07/11(日) 15:56:42.82ID:F24huBET
ここまで全部おれ
2021/07/11(日) 16:21:58.99ID:BeeJLMuH
マジカヨ死んでくれ
517デフォルトの名無しさん
垢版 |
2021/07/11(日) 17:09:03.43ID:WA0GzHcp
オブザーブバブルコレクション使ってモデル読み込むだけだよね
Mは単なるデータでいい
2021/07/11(日) 18:49:50.97ID:HaMWdASV
VMVもUserControl以外全部Xamlにしてバッチグーなローコードだ
2021/07/11(日) 19:22:59.17ID:qjFfZwWG
馬鹿が必死になってるのが痛い
2021/07/11(日) 19:37:13.31ID:lnDzPe6P
昨日の話を一人で長文書いて続きやろうとしてる必死さが笑える
2021/07/11(日) 20:23:07.63ID:r2mSMqWr
コテンパンにされた通知馬鹿w
2021/07/11(日) 20:29:52.86ID:qjFfZwWG
一人でINPCって言ってる馬鹿が勝手にコテンパンにされてるだけだろう
2021/07/11(日) 21:47:14.35ID:vIt/TVMn
>>514
オウム返しするだけじゃなくてちゃんと反論してくれ
あおり合いじゃなくて議論が見たい
2021/07/11(日) 21:58:06.58ID:x50DSKku
>>523
ここじゃあとてもとても無理だ
2021/07/11(日) 22:15:44.15ID:vIt/TVMn
>>524
なら黙ってて
2021/07/12(月) 06:31:59.34ID:n+s+RpIK
凡俗法則の実例
2021/07/12(月) 10:14:37.67ID:UFEp8oQ1
凡俗法則って言葉知らんかったわ

この外資系社員が凡俗法則を説明してんだが、例に出してるコイツ自身の資料がダメだわ
https://www.daijob.com/crossculture/takashi/20120207.html
528デフォルトの名無しさん
垢版 |
2021/07/12(月) 11:29:09.25ID:B/Smfxyl
UIへの変更通知と
Modelの購読をごっちゃにしてるのがそもそもの間違い。

前者はUIフレームワークで良く扱っているやつだが、
後者は一般的にはPush等で知られる通知処理だ。

で通知処理（Modelの購読が必要になるケース）なんてほぼほぼ無くて、
業務系システムだと株価のリアルタイム表示、チャット位なもんだ。
実装方法としてポピュラーなのはWebPush、WebSocket 、SignalRとか。

それ以外でどうしても必要になっても、通知処理みたいな面倒な機能は設けずに
通常はクライアント側でタイマー回してポーリングして凌ぐのが定石だし手堅いし
どこでもその方式でやってる。
529デフォルトの名無しさん
垢版 |
2021/07/12(月) 12:00:20.06ID:QRdBsraN
数量、単価、金額のプロパティがあるとしてどういう実装する？

VMで掛算してMはPOCOだよな
2021/07/12(月) 12:34:29.39ID:EMnZux7N
計算ロジックは当然Mでしょ。
2021/07/12(月) 12:44:59.03ID:0lrYCdZ4
POCOってなんですか？
おしえてよ
2021/07/12(月) 12:50:37.95ID:EMnZux7N
>>531
基本的な.NETのオブジェクトだけで構成されているもの。
そこは気にしなくていい。

View→UI
ViewModel→UIフレームワークの都合上必要な部分
Model→その他全部

これだけ覚えておけば十分。
2021/07/12(月) 12:57:16.22ID:0lrYCdZ4
>>532
ありがとう
ついていくぜ、旦那
534デフォルトの名無しさん
垢版 |
2021/07/12(月) 13:20:29.38ID:B/Smfxyl
POCO : Plain Old CLR Object
DTO : Data Transfer Object

現場では必ずしも正しい意味では使われておらず、
実際は POCO は DTO と同義で用いられる事が多いかな。

（というか、自分の現場じゃ DTO と言う事が圧倒的に多い）

で、DTO の意味だが
アプリケーションの各層（ViewModel層、Model層、DA層）の
データのやり取りをする単純な入れ物クラスを指す。

class Xxxx
{
public int ID { get; set; }
public string Name {get; set; }
public string Address { get; set; }
}

こんなクラス。（あ！別にクラスでなくても良い）
ここに基本ロジックは無い。
（まあ、getterとかを足す場合もあるけどね）
で現場では、WebAPI等のIF実装から自動的に生成したりする事が多い。
2021/07/12(月) 13:24:45.35ID:0lrYCdZ4
>>534
なにこの丁寧な説明！
もう抱いて！！
536デフォルトの名無しさん
垢版 |
2021/07/12(月) 13:26:43.36ID:B/Smfxyl
>>535
♀？
537デフォルトの名無しさん
垢版 |
2021/07/12(月) 13:34:36.87ID:B/Smfxyl
Model層へのアクセスは RESTful API で行う事が最近は多いとおもうから、
APIの仕様書を OpenAPI形式の APIドキュメントでもらって、
そこから自動生成するのが定石だよ。

まあ、イケてる現場なら普通やってたり検討したりするはず。
正直いって DTO とか POCO とか自動生成の最右翼コードだ。
2021/07/12(月) 15:17:10.90ID:P5SgcPEZ
>>529
素でこういう人が多いんだろうなあと思う
539デフォルトの名無しさん
垢版 |
2021/07/12(月) 16:19:35.12ID:zhwkz6A9
でもPOCOをラッピングしてPropertyChanged付けるとVMになるんですよね？
2021/07/12(月) 19:40:53.71ID:mV+dJaVa
>>529
こいつ一人が馬鹿なんだ
いい加減にあきらめろよ
2021/07/12(月) 19:48:49.64ID:mV+dJaVa
>>528 >>534
一番の馬鹿はこいつ

お前のやってる業務の現場の話じゃないWPFの話をしてるのにどんどん話をすり替えていく
土方業務話をしたいならどこかよそでやれよ

まだ恥の上塗りを繰り返すの？
ここには誰も味方はいない
2021/07/12(月) 19:50:31.26ID:mV+dJaVa
WPFのモデル層へのアクセスをRESTful API でやってるやつを教えて欲しい

馬鹿の世界では当たり前らしいけどｗ
2021/07/12(月) 19:51:48.31ID:P5SgcPEZ
>>542
もう恥の上塗りはやめなよ
モデルのソースがWebAPIって話でしょ
2021/07/12(月) 19:54:08.90ID:mV+dJaVa
なんでWPFのモデル層の話をしていたのに

誰かの業務のWebAPIの話をしてドヤってんの？
知能レベル低すぎ
2021/07/12(月) 19:56:53.06ID:P5SgcPEZ
>>544
なんで分からんのやろ？
ものすごいバカの壁を感じる
2021/07/12(月) 20:02:52.66ID:mV+dJaVa
>>545
そちらが馬鹿の壁を超えられないサルだからだろ

WPFのモデル層は他のフレームワークのようなPOCO（単なる入れ物）としてコーディングするだけでは通知が抜けており
MVVMの本来のメリットを享受できないという話だったのに

なぜかwebAPI使ったりロジックをVMに書いたりする話にすり替わっている
WPFではVMでロジック書いて通知が一般的だと言われても納得する人はいないんじゃないの？

旗色が悪くなると相手が理解できないと勘違いして業務の話を出してドヤってるけど誰でもわかるわ
2021/07/12(月) 20:10:18.98ID:mV+dJaVa
負けられない病にかかってるのかもしれないけど

そちらの主張どおりWPFではM層はみなiNotifyPropertyChangedの実装なしで書くのが一般的で
VMで通知が当然ですと書かれて納得すると言うのはおかしな話

本筋をねじ曲げて勝利したいのかがわからない

勝利病なの？
2021/07/12(月) 20:28:01.38ID:Yv2DGcH3
>>528
MVVMアプリ的にはクライアント・サーバーのやり取りなんざまとめてMの範疇だろうに
そこの実装がプッシュだろうがポーリングだろうがどうでもいい話
2021/07/12(月) 20:32:07.25ID:EMnZux7N
まずPOCOが単なる入れ物って認識が間違い
2021/07/12(月) 20:34:47.17ID:P5SgcPEZ
POCOがあったらそこになんちゃらRepositoryやらなんちゃらServiceがあるわけじゃん
Modelはそれらを内包した概念なわけで
もうその辺から認識がズレてるから擦り合わせようがないんだと思う

話がどんどん後退していってる
2021/07/12(月) 20:36:41.56ID:LswkHmLx
なんでPOCOとDTOをゴッチャにしてんだ
WPFでMVVMやるならDTOはMの更に先にあるもんだぞ
そっかだからやたらポコポコ言ってんのか
申し訳ないがWebに例えないと話ができない人はNGに入れとくわ
2021/07/12(月) 20:39:06.39ID:P5SgcPEZ
MVVMのMには当然DTOが内包されるよね
更にその先って何？w
2021/07/12(月) 21:02:09.50ID:Gt7PpS3W
>>534
>実際は POCO は DTO と同義で用いられる事が多いかな。

そう思ってる人と正しく使ってる人とで話が噛み合ってない感じだよな。
2021/07/12(月) 21:30:46.04ID:EMnZux7N
>>540-541
これ、自演に失敗したのかな
2021/07/12(月) 22:04:12.08ID:0kBd/ns6
あのさ>>528は例えば特に>>495対するレスで、単にUIとは関係ない一般的な
通知論を言っただけで、>>541の言いたい事を否定してるように見えないんだけど
むしろ君の味方だと思うんだが、>>541は全員敵に見えてるの??
2021/07/12(月) 22:19:19.66ID:0kBd/ns6
ああ、ごめん俺が間違ってたww
>通知処理（Modelの購読が必要になるケース）なんてほぼほぼ無くて
ここでちゃんと否定してたねw
2021/07/12(月) 22:20:11.65ID:LswkHmLx
>>555
エコシステムの話をしてるんじゃなくてWPFアプリの話をしてるので
MVVMのMをWPFアプリでどう実装するかが論点なのよ
2021/07/12(月) 22:22:33.14ID:e9fWYKI2
一応はWPFなりMVVMなりを前提として話してるもんだと思ったらまさかのUIは関係ない宣言

U I は 関 係 な か っ た ！

そら誰とも話通じんわw バカ同士仲良くしてくれ
2021/07/12(月) 22:25:45.89ID:0kBd/ns6
いや、やっぱ>>556取り消すわ
やっぱ、>>528は単に>>495に対するレスにしか見えないな

>>557
論点はそこにあると思うけど>>528は通知の一般論話しただけかもしれん
2021/07/12(月) 23:41:05.62ID:B/Smfxyl
なんじゃこりゃ！
561デフォルトの名無しさん
垢版 |
2021/07/12(月) 23:46:26.66ID:B/Smfxyl
WPFに限らず一般的な話してるだけじゃん
2021/07/12(月) 23:57:26.60ID:0kBd/ns6
俺は土曜日までは会話に主な論点わかってたけど

昼間に君のレス見て、UIと通知を結びつける人がいて気になってたから、その人向けにUI関係ない通知の一般論言ってるんだろうと納得してたら

夜みて、通知の一般論言ってるだけなら全く関係ない人が怒り出してから草
って感じ
2021/07/13(火) 00:56:18.26ID:xjJDoKS2
だってWPFと関係ない話になってんだもん
むしろ論点ずらししてるっしょ
2021/07/13(火) 05:46:23.04ID:fhfe26+M
頭ひろゆきかよ
2021/07/13(火) 08:46:15.95ID:Pw5n0ID3
VMに相当する部分にビジネスロジックをガッツリ書くのはアプリ設計としてありだが、それはMVVMじゃないな
MVVMはModelにビジネスロジックを書くのが本来の定義だ
2021/07/13(火) 08:51:29.18ID:+zVQ74um
いやあ皆性格わるいねえw
醜いもんだよw
2021/07/13(火) 09:07:04.94ID:xejzJ7TX
>>547は最悪の性格だと思うww
>>528に勘違いでぶきちれてる
2021/07/13(火) 09:08:01.98ID:xejzJ7TX
ぶちきれてるねw
2021/07/13(火) 09:18:27.78ID:DZCKnpMT
>>565
そんな設計はもうViewModelなんて言葉を使うべきじゃねえわ
MVCでもMVVMでもないどころか関心の分離すら無視した全く別の何かじゃん
2021/07/13(火) 09:23:04.37ID:DZCKnpMT
どんなプログラミングパラダイムを採用しようと
UIの変更にモデルは影響されないのが原則だと思ってる

例えばWPFで作ったものをASP.netでWebインターフェイスに変更することになったとしてもモデルには一切触れなくて済むのが本来あるべき姿
しかしモデルにUIのための通知機能を入れた途端にそれは破綻する
別にモデル通知機能があったって動くから良いだろと言う話ではない

そこがモデルに通知機能を実装する違和感の根源
571デフォルトの名無しさん
垢版 |
2021/07/13(火) 10:32:02.27ID:2EC2vCMH
変更を通知するサービス

たとえばみんなが知ってる gmail（いわゆるPushメール）とかは
クライアントを WPF でも Flutter でも React でも作れると思いますが、
ではこの機能は何に相当するのでしょうか？
572デフォルトの名無しさん
垢版 |
2021/07/13(火) 10:53:55.72ID:s3qWh6Np
通知機能のあるMをVMのObservableCollectionでVに公開すると
このMはVMになりますか？
MVVMでは反則でしょうか？
2021/07/13(火) 10:55:02.74ID:t7skZb6/
>>571
何とは?
MVVMの役割のことを言っているのあれば、どれでもない
Mの中で使用される機能と言うだけ
2021/07/13(火) 11:08:48.39ID:dtNqNBdW
Amazon SNS（Simple Notification Service）は、

そのためだけにサーバーを用意しなくても、
アプリケーションからの通知を可能にするサービスです

ユーザーが何かを行ったタイミングで通知する
「イベントドリブン」なメッセージングを手軽に実現します
2021/07/13(火) 20:50:38.25ID:b1BrGGh1
>>570
>しかしモデルにUIのための通知機能を入れた途端にそれは破綻する

そこに依存性逆転パターンを使うのが常套手段。
2021/07/13(火) 22:05:10.54ID:xjJDoKS2
>>572
Collectionの要素に変更があるのを監視する必要がなければそれでOK
別に反則じゃないと思う
2021/07/14(水) 19:37:54.90ID:Ftj7Gfdw
今日は勝ちたい病のVMにビジネスロジック実装する君は来てないの？
2021/07/14(水) 21:01:12.91ID:FWHo5b9L
どうした、恋しいか？
2021/07/14(水) 22:40:50.82ID:UYQRt03E
こないと>>547の馬鹿みたく関係ない人攻撃しだすからなww
2021/07/14(水) 22:48:26.38ID:Ftj7Gfdw
え？
ID:B/Smfxylは馬鹿だよ
2021/07/14(水) 23:03:29.16ID:UYQRt03E
久しぶりにみたわ
必死過ぎて全員敵に見える病ww
2021/07/14(水) 23:13:04.52ID:wjhDeS6u
家に鏡がないのか？
鏡を買えば毎日見られるぞ
2021/07/15(木) 02:12:58.55ID:rXkSqNZ0
自分がそれで見られるからって
他人が同じことして見られると思ってるあたりが馬鹿だよね
2021/07/15(木) 08:43:28.31ID:erbvpp8v
みんな皮肉が上手だなあ(鼻ホジ)
585デフォルトの名無しさん
垢版 |
2021/07/15(木) 10:10:56.93ID:Gu3XCrlD
>>576
いやMの通知をVが監視する状態だよ
586デフォルトの名無しさん
垢版 |
2021/07/15(木) 14:23:21.77ID:VeQWWe0f
ロジックはコマンドに書いてるけどコマンドってVMの仲間じゃないの？
2021/07/15(木) 19:55:28.67ID:yhXjFIIz
>>585
原理主義通すならその通りなので止めた方が良い
大規模プロジェクトで規約作る段階とかならあなたの言う通り
そうでないなら工数とのバーター
2021/07/15(木) 20:40:50.25ID:yPgIH8DR
そういやコレクションでもしっかりVM挟めって人がWPF出来て直ぐの頃は言う人いたよな
2021/07/15(木) 23:20:18.67ID:twFSqmod
なんか人によってVMの定義が違うのかねぇ？
WPFだとDataContextにセットするのがVMだと認識しているが。
2021/07/15(木) 23:31:38.36ID:yPgIH8DR
>>589
ListViewなどでも、内部的にListViewItemのDataContextにコレクションのアイテムがセットされるから何も変わらないよ
それにVM挟めというやつが昔はわりといた
2021/07/16(金) 19:02:18.73ID:tbXedaSH
ビジネスが破綻する大半の原因は、 ”ビジネスを始める人の大半が、真の意味での
「起業家」ではなく、 起業したい、という熱に浮かれた「職人」として働いているに過ぎない。”
という事実にあります。
「職人」によって運営されているビジネスは、ビジネスが働くのではなく、彼ら自身が毎日働くこと
によって、成り立っています。
彼らは毎日、自分がやり方を知っている仕事を一生懸命にこなしていますが、「起業家」としての
視点が無いために、成長に限界が生まれます。
そして、生計を立てるために、彼ら自身がずっと働き続けないとならないのです。

誰もが必ず陥る罠
私が見ている限り、起業熱にうなされる人たちは、必ずと言ってもよいほど誤った
「仮定」を置いてしまうようだ。実は、のちに彼らが苦難の道を歩むことになるのは、
この、「仮定」が致命的に間違っているからなのである
致命的な仮定とは・・・「事業の中心となる専門的な能力があれば、事業を経営する能力は
十分に備わっている」ということである
私がこの仮定を致命的だと書いたのは、この仮定が間違っているからにほかならない
事業の中で専門的な仕事をこなすことと、その能力を生かして事業を経営することは
全く別の問題である。高い専門能力を持つ人にとって、独立は他人の為に働くという苦痛から
解放されるということを意味していた。それにもかかわらず、前提となる「仮定」が致命的とも
いえるほど間違えているために、彼らは自由になるどころか、自分が始めた事業に苦しめ
られるようになってしまうのである
マイケルEガーバー「はじめの一歩を踏み出そう」P28~29
2021/07/16(金) 20:45:27.50ID:nOgfrdpb
>>590
それは問題なくて、逆にDataContextと関係ないものまでVMと言っている人がいるような気がしたんで。
2021/07/21(水) 18:44:02.13ID:za3x9XY8
年末まで動きはなしか
2021/07/21(水) 21:28:05.11ID:0TrBhSUB
>>593
それでも0.5と違ってreunion0.8は、そこそこ安定しているよ
2021/07/22(木) 05:38:57.11ID:fbsqHODV
なんでtextblockってこんな中途半端に作ってあるのかな
作ってるときに上下のスペース気にならなかったのか
2021/07/22(木) 17:25:19.02ID:lRm6lFPm
なんのこと？
2021/07/22(木) 18:31:15.26ID:vwDpdZeF
ｒｉｃｈtextboxの上下のスペースなら気になった
馬鹿が作ったんだろうなとニヤニヤした
2021/07/22(木) 20:01:46.34ID:PV0Y3pfC
全角半角混在バカ
2021/07/23(金) 06:59:12.37ID:F886/8HL
WinUI早くソース公開してくれ
2021/07/23(金) 12:50:01.83ID:YjvHno2g
そーっすね
2021/07/23(金) 19:10:22.48ID:LsYzUOc/
そこでWPF完全終了？
2021/07/24(土) 15:09:24.06ID:B0+KuVSr
>>601
1.0が出てから触ってみるつもりだから分からん。
UWPが見向きもされなかった欠点が解消されてるなら移行するし、
駄目ならWPFとWinUIのミックスになるかもしれない。
2021/07/24(土) 17:27:17.07ID:XrMlrlks
WinUIってWPFよりUWPのほうが近くない？
2021/07/24(土) 18:17:14.05ID:jHuzu2oV
基本的にGUIはUWPが基本でほんの一部異なる程度
売りはファイルアクセスなどの制限のない.netのクラスや
C言語のライブラリが普通に使えること

残念なのは.net nativeは対応していないからUWPほど高速にはならないところだな
2021/07/24(土) 19:31:02.40ID:m9/tzZBE
これがreunionちゃんか？
ttps://docs.microsoft.com/ja-jp/windows/apps/desktop/modernize/xaml-islands
ttps://docs.microsoft.com/ja-jp/windows/apps/desktop/modernize/host-standard-control-with-xaml-islands
2021/07/24(土) 20:52:35.53ID:PoLbY2rq
俺はカラー絵文字が普通に使えさえすればもうWPFで十分なんだけど
それってUWPのコントロールが使えるようになるとかいうnugetパッケージ入れりゃ簡単にできるもんなの？
2021/07/25(日) 12:45:55.14ID:KYDDSoJA
備品管理のために配置図作成プログラムを作るために下の二つを使いたい

マップ描画用
https://noitalog.tokyo/wpf-excel-shape/

UndoRedo機能用
https://qiita.com/nossey/items/c59910558d5501f03ad0


Undo機能でマップ描画のキャンセルをしたいんだけど
Record(() => { /＊do＊/ }, () => { /＊undo＊/ });のところに何を入れればいいのか分からない
何を入れれば実現するのか教えてください

もしくはもっといいライブラリがあれば教えてください
2021/07/25(日) 15:14:28.53ID:NdwY3sWp
>>607
そういうツール作ったことあるけど、Undo/Redoは状態そのものを記録する方式の方が楽だよ
操作ごとに描画したモデルをスタックに積む感じでとっておいて
Undoでポインタを遡る、Redoされたらポインタを進める
2021/07/25(日) 15:39:24.67ID:KYDDSoJA
つまり別のライブラリを使った方がいいってことですね
探してみます
2021/07/25(日) 15:50:45.11ID:UpcvNBvN
>>609
608が言ってるのはstateをスタックに積むだけなので、Stack<T>を使えばライブラリは不要。
考えるべきはstateを表現する方法かと。
2021/07/26(月) 13:34:11.89ID:if+3GvI0
undo/redoをcommandパターンで実現するときのネックは、逆方向への操作を綺麗に実装出来るかどうか
たとえば、0から1増やす操作は可逆性があるので簡単だが、0を1に変更する操作は可逆性がないので元の値を必要な分だけcommandに設定しておかないといけない
必要な分が広範囲になると、丸ごと状態を記録するのと変わらなくなってしまい、ただ実装が複雑になる
stateパターンの場合は、実装が簡単というメリットの代わりに、状態をうまく独立させないとリソースを大量に消費するというデメリットがある
commandパターンで、直接状態を変更するcommandを作るのではなく、状態の差分を算出して適用できるように実装出来れば、両者の問題を解決できる
612デフォルトの名無しさん
垢版 |
2021/07/26(月) 15:01:38.67ID:sA+3cpxO
doに新しい状態でundoに古い状態を入れたらいいんでしょ
規模も不明なんで丸ごと記録でいいんじゃない
613デフォルトの名無しさん
垢版 |
2021/07/26(月) 18:39:34.76ID:HAWagkhF
Undo可能クラスも実装出来んの？
(例)
var val1 = new Undoable<int>(0);
val1.Set(1);
val1.Undo();
val1.Commit();
if (val1.Value == 0) {
}
614デフォルトの名無しさん
垢版 |
2021/07/26(月) 18:41:04.91ID:HAWagkhF
UndoableクラスのValueプロパティーをInotifyPropertyChangedで実装しとけ！
2021/07/26(月) 21:06:01.64ID:if+3GvI0
>>613
これ足し算するときは
val1.Set(val2.Value+val3.Value)
って書かせるのか？
616デフォルトの名無しさん
垢版 |
2021/07/26(月) 22:19:37.90ID:HAWagkhF
getter位実装しろや
617デフォルトの名無しさん
垢版 |
2021/07/26(月) 22:28:38.74ID:HAWagkhF
setter ...(; ･`д･´)！
618デフォルトの名無しさん
垢版 |
2021/07/26(月) 22:34:21.59ID:rgsHaqle
>>613
その実装をどうしようって話だと思うんだけど
2021/07/26(月) 22:40:13.03ID:HAWagkhF
どこまでおんぶにダッコよ(>_<｡)！
2021/07/26(月) 22:46:07.45ID:FJAlPqYb
編集するタイプごとのenum作って復旧／削除用のバッファ・位置情報を持つクラスを作るのだ
通常の編集処理に渡せるようにできるかがあんきも
2021/07/26(月) 23:08:38.92ID:rgsHaqle
>>619
元の質問読んでなさすぎだろｗ
622デフォルトの名無しさん
垢版 |
2021/07/26(月) 23:14:37.82ID:HAWagkhF
ゴミと判断した
2021/07/27(火) 13:29:46.95ID:/oZqPjm8
>>607ですがC#ほとんど素人です
stack<t> にcanvasを入れてみてpushやpopしても上手く変更されず
2021/07/27(火) 18:46:15.06ID:KMLdgMbQ
>>623
参照型が理解できてないっぽい。
残念だが初心者スレでは無いのでここまで。
625デフォルトの名無しさん
垢版 |
2021/07/28(水) 09:34:26.66ID:m3dX+aIk
>>623
確かどっかにC#初心者スレがあったはずだから
2021/07/29(木) 12:37:19.54ID:VxNcNDZg
こっちクローズして初心者スレ行きます
2021/08/01(日) 18:11:43.70ID:tzaLBmjr
c#に慣れてきてWPFに挑戦しようかなと公式チュートリアルのHello Goodbyeを試した。
1.まずはxamlの名前を変えましょうでエラー。
1時間ほどなら悩みまくってチュートリアルページ遥か下にデバッグの項目で意図的なバグだとわかった時はキレそうになった。
引き続き学習しようと思ってるんだけど、参考になるサイトある？
2021/08/01(日) 18:45:22.56ID:BCtBnKvQ
かずき
2021/08/01(日) 20:21:17.09ID:ovUX7fTa
xamlはhtmlと同じようにタグをエディターで入力するしかないって気づいたところから使えるようになっていったな
Formsみたくコントロールをマウスで並べようとして挫折しかけた
630デフォルトの名無しさん
垢版 |
2021/08/01(日) 21:11:07.02ID:zuqV0aN+
タグ書いて完璧なUIを作るのが楽しい
グラフィカルなエディターってチラ見するだけのものだな
2021/08/01(日) 21:17:10.83ID:zRRMy60W
公式チュートリアルにHello Goodbye(world?) なんてあったっけ
2021/08/01(日) 22:31:27.62ID:tzaLBmjr
>>631
チュートリアル: C# で単純なアプリケーションを作成する 2021/02/10
ttps://docs.microsoft.com/ja-jp/visualstudio/get-started/csharp/tutorial-wpf?view=vs-2019

Hello Worldレベルでつまづいたのは初めてでショック。
wpf tutorialで検索したら良さげなサイト見つけられたからもういいんだけどね。
2021/08/01(日) 22:31:58.77ID:hLrbx4IS
ハロー！そしてグッドバイ！
2021/08/02(月) 01:14:13.50ID:GLNJH6H3
>>632
StartupUriを変更してないから実行時エラーになる件？
チュートリアルを手順通りやってれば悩むようなことなくね？
2021/08/02(月) 12:27:13.51ID:cBPUjued
>>629
Formsと同じような作り方してると結局Formsと同じくサイズ変更やレイアウト変更に脆い画面になっちまうんだよな。
GUIから貼り付けると余計なプロパティも追加されてごちゃつくし。
XAML用のコードスニペット用意して爆速コーディングがお勧め。
636デフォルトの名無しさん
垢版 |
2021/08/02(月) 17:35:01.31ID:OwNzYS4q
縦にズラーと並べてご満悦ですか
2021/08/03(火) 06:02:09.33ID:YKUXzg3a
WrapPanelもあるでよ
2021/08/05(木) 12:08:27.09ID:LnW659PN
winui触ってるけど非同期メソッド多すぎてイライラする
慣れたら気にならなくなるのかな
2021/08/05(木) 12:48:41.25ID:qCKYnrg6
むしろ非同期メソッドが用意されていない方がイライラするだろ。
640デフォルトの名無しさん
垢版 |
2021/08/05(木) 21:46:17.56ID:iyi+GUtj
>>638
WinUIまだ触れてなくて分からないんだが、もうDispatcher.Invokeしなくて良くなるの？
2021/08/05(木) 22:11:14.99ID:hAnk8QxE
きっちりMVVMしてりゃDispatcher.Invokeなんて出番ないんだが。
2021/08/05(木) 22:41:02.46ID:szLnk8N0
>>640
https://docs.microsoft.com/en-us/dotnet/api/microsoft.toolkit.uwp.DispatcherQueueExtensions?view=win-comm-toolkit-dotnet-7.0

こんなクラス使ってUIスレッド呼び出すんだわ
2021/08/06(金) 00:49:06.65ID:y474vaxZ
最近のアプリはクリックしたあとすぐに反応しないアプリ多すぎ。というかWindows10。

馬鹿に非同期の実装は無理ということ。
2021/08/06(金) 18:59:51.04ID:gqafcbP7
OneNote UWP版、死亡。
着実に脱UWPしていってるな、よしよし。
2021/08/08(日) 10:59:54.62ID:CLpDwXEd
コード簡略のためにawait 使いまくってるサンプルが世に広まってるのが良くないのかね(´・ω・`)
2021/08/10(火) 10:09:01.90ID:l4gp57RE
MahAppsでGUI作っていたけど今更Metro(Modern) UIというのもアレなんで
最近出たらしいWinUI 3.0で組もうとしているけど、ウィンドウサイズを変えることができない。

なんか、いい方法ない？

あと、WPFで使っているからかもしれないが、Windows.Storage.FilePickerの動作がなんか不安定だ。
PickSingleFileAsyncは動くのにPickMultipleFilesAsyncだとコケる。
2021/08/10(火) 10:50:56.88ID:WgvQ9Z8W
>>646
User32でハンドル拾ってメソッドを呼び出すと色々出来ます
いろいろ調べたけど、現状だとこうするしかない模様
2021/08/10(火) 11:07:37.44ID:l4gp57RE
非同期じゃないとUIロックしちゃうじゃないですかーっ。（キャンセルボタンが押せない進捗ダイアログとかできてしまう）

>>647
ハンドルかぁ。
なんか以下の４種類ぐらい取得する方法あるっぽいけど違いがよくわからない・・・。

１：
[DllImport("user32.dll", ExactSpelling = true, CharSet = CharSet.Auto, PreserveSig = true, SetLastError = false)]
private static extern IntPtr GetActiveWindow();

IntPtr hwnd = GetActiveWindow();

２：
[ComImport, Guid("EECDBF0E-BAE9-4CB6-A68E-9598E1CB57BB"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IWindowNative
{
IntPtr WindowHandle { get; }
}

IntPtr hwnd = WindowHandle();

３：
IntPtr hwnd = new WindowInteropHelper(Application.Current.MainWindow).Handle;

４：
IntPtr hwnd = WinRT.Interop.WindowNative.GetWindowHandle(Application.Current.MainWindow);
2021/08/10(火) 12:38:45.38ID:WgvQ9Z8W
>>648
microsoft shell controls and automation　ってのをcom参照すればOK

それでWindowがアクティブな状態で
m_windowhandle = PInvoke.User32.GetActiveWindow();
な具合でOK
2021/08/10(火) 15:18:02.31ID:Zfr/tHwz
WinAPI使うならPciker使うこと自体避けてしまえば
https://docs.microsoft.com/en-us/windows/win32/api/commdlg/ns-commdlg-openfilenamew
2021/08/10(火) 16:38:59.72ID:3CW5QVj8
WINUIってコントロールにハンドルないの？
2021/08/10(火) 17:46:08.05ID:l4gp57RE
うーん、今更Windows7時代のAPIを叩くWindows API Code PackやOokiiDialogを使うのは微妙だなってことで。
Windows11になったときに浮いてしまうんじゃないかとというのはさておき、複数のファイルやディレクトリを選択できるのがいいかなと。
いつの時代なんだよといわんばかりのデザインのMessageBoxもまた然り。

>>651
ハンドルのとり方に違いはあるにせよ、だいたい以下のようなコードを使うみたいなことが書いてある。
これはとりあえず動いているコード。
[ComImport, Guid("3E68D4BD-7135-4D10-8018-9FB6D9F33FA1"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IInitializeWithWindow
{
void Initialize([In] IntPtr hwnd);
}

// ダイアログを定義
FileSavePicker picker = new()
{
SuggestedFileName = "text",
SuggestedStartLocation = PickerLocationId.PicturesLibrary,
FileTypeChoices = { { "Text File", new List<string>() { ".txt" } } }
};
// ウィンドウバンドルを取得
IntPtr hwnd = new WindowInteropHelper(Application.Current.MainWindow).Handle;
IInitializeWithWindow withWindow = picker.As<IInitializeWithWindow>();
withWindow.Initialize(hwnd);
// ファイルダイアログを表示
StorageFile file = await picker.PickSaveFileAsync();

まぁ、上のコードはちゃんと動くけど、
IReadOnlyList<StorageFile> files= await picker.PickMultipleFilesAsync();
のように複数選択にすると動かない不思議。
参考：https://qiita.com/okazuki/items/227f8d19e38a67099006
2021/08/10(火) 18:43:48.86ID:3CW5QVj8
>>652
帰ったら試してみます
どうもありがとう
654おじさん(*'▽')
垢版 |
2021/08/10(火) 19:13:20.91ID:/fr9b65w
GUIプログラムは、Electronを使うのが一番簡単だと思うね
ちなみにおじさん(*'▽')はJavascriptはあんまり得意じゃないな
655おじさん(*'▽')
垢版 |
2021/08/10(火) 19:18:23.47ID:/fr9b65w
C言語は、競技プログラミングでしか使ったことないな
2021/08/10(火) 19:42:06.18ID:l4gp57RE
652の問題はWindowsAppSDK側の報告済みのバグだった模様。
https://github.com/microsoft/WindowsAppSDK/issues/467

>>654
まぁね〜。VueとTypeScriptでいくつか作っているけど、ブラウザに用意されているOSの機能（ファイル添付とか）以外を叩かないのであれば楽。（むしろそっちのほうが得意である）

DiscordみたいなWebでもディスクトップでもってアプリを作る場合は便利だし、速度的な問題もWebAssemblyで遜色ない程度の速度で動くけど、OSの機能を叩く場合IPCRendererの知識がいるし、CのライブラリをWebAssemblyにしてJavaScriptから叩けるようにする場合は、Emscriptenの知識がいるよ。
npmで配布されているwasmなライブラリで、ブラウザでは動くのにElectronでは動かないってトラブルが結構あった。

かつてのJScriptみたく、直接COM基盤やDLLを叩けるとか、WPFを操作するのにC#の代わりにTypeScriptで組めるとかできればいいんだけどね〜。
2021/08/10(火) 19:59:56.48ID:pB3MREYf
そのへんはEdgeエンジンのWebViewに期待したいところだなぁ。
658デフォルトの名無しさん
垢版 |
2021/08/11(水) 12:43:37.02ID:dnSnLDjM
Electron互換でwebview2使ったhta並のファイルサイズのexeかできれば覇権取れるよな
2021/08/11(水) 13:03:17.24ID:SyYdmIb8
WebViewってホストがC#ってだけで、内側からOSや.NETフレームワークの機能が
アクセスしやすくなっているわけじゃないよな。
660656
垢版 |
2021/08/16(月) 10:46:18.07ID:H7Gaa2kS
>>658
https://docs.microsoft.com/ja-jp/microsoft-edge/webview2/get-started/wpf#step-7---communication-between-host-and-web-content
を見る限り、postMessageで通信って書いてあるから、WebWorkerのWorker部分をC#で実装するみたいなイメージだと思う。

WebWorkerは以下のようにJavaScriptで並列処理する目的でよく使われるけど、DOMにアクセスできなかったりselfになるなど結構特殊だからねぇ。

呼び出す側：
var worker = new Worker('worker.js');
worker.addEventListener('message', (e) => {
console.log(e.data); // Workerから送られてきたデータ
}, false);
worker.postMessage('workerに送るデータ');

worker.js：
self.addEventListener('message', function(e) {
//なんかの処理

//処理結果を送信
self.postMessage(e.data);
}, false);

C#ではこのworker.jsに相当する部分を[webView].CoreWebView2.WebMessageReceivedで待ち受けるっぽい。
2021/08/19(木) 08:23:07.44ID:NViLy9VH
期待

WPF 入門
https://zenn.dev/okazuki/books/windows-presentation-foundation
2021/08/19(木) 08:50:27.44ID:DS/L8+OC
>>661
分かりにくいなあ
初心者向けのチュートリアルなのかと思ったら突然妙に細かい概念の説明が入ったりWPF独自用語がロクな説明もなしに多用されてたり、
何がしたいのかよくわからん
MS技術は概念から入りがちでわかりにくいとよく言われるけど、社員もこんな感じならそらそうなるわな
2021/08/19(木) 09:51:56.00ID:3QyxcYYx
今から始めるもんでもないような
2021/08/19(木) 10:31:22.37ID:oZ+vhOv+
そのサイトは読んでないけどkazukiのWPF連載は実際的だったけどなあ
2021/08/19(木) 11:07:01.91ID:3B3dleWs
そりゃまだHello WorldにWPFの概要説明が載ってるだけだし
ただの難癖早漏
2021/08/19(木) 11:44:55.48ID:B78SxsT8
WINUI入門お願いします
2021/08/19(木) 11:46:09.64ID:IgpDwdm7
>>664
リンク先はkuzuki氏のサイトなのだが
2021/08/19(木) 15:01:24.51ID:9SGe/4Ie
WPFでも使えるプレイグラウンドってある？
2021/08/19(木) 18:05:18.10ID:pPr2+R/k
>>662
本書の対象者を見るに
2021/08/19(木) 18:11:13.58ID:pPr2+R/k
誤送信すみません

>>662
本書の対象者を見るに入門とは言ってもそこそこC#に触れてる人向けっぽいよ
2021/08/20(金) 07:31:12.77ID:RlHkksrv
そりゃC#入門じゃなくてWPF入門だからね
2021/08/21(土) 20:12:33.02ID:3/tZrvXL
中身を見て見たけどあらかじめ知識のある人向けの入門書だから初心者には難しい
データバインディングとか普通に意味が分かる人じゃないと

入門と言うより再入門に近いかな
2021/08/21(土) 20:13:15.10ID:3/tZrvXL
WPF再入門でC#についていくら知っててもなんの意味もない
2021/08/21(土) 20:23:29.65ID:K2WIpt9a
WPFについて知りたいのにC#入門からやられてもウザいだけだわな
2021/08/21(土) 20:36:08.76ID:xRCh69hJ
秘伝のタレなんか知らんがWPFのMVVMパターンを使ったレシピがネットに転がってなくて困る。
プログラマーならフワッとした概念と、あの3つの四角形が矢印で繋がってるのだけ見て「なるほど、そういう事ね」と作り始められるの？
2021/08/21(土) 20:36:30.51ID:sxt2sGHA
旧版にあたるWPF4.5入門（https://www.slideshare.net/okazuki0130/wpf45-38048141）と
見比べてみれば、まだまださわりの部分だわな
つか、現状に合わない部分を削除してるだけに近いかね
まだ加筆が必要な部分じゃないからだろうけど
677デフォルトの名無しさん
垢版 |
2021/08/21(土) 21:03:06.13ID:7GAoG1Iq
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html


Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ
ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
2021/08/21(土) 22:01:00.51ID:K2WIpt9a
>>675
こういうのじゃないの？
https://zenn.dev/apterygiformes/articles/79a7c9e7e15106
2021/08/21(土) 22:05:08.07ID:K2WIpt9a
>>675
https://emu2021makuake.github.io/MVVM-Samples-Index/
2021/08/21(土) 23:02:56.36ID:xRCh69hJ
>>678
これは参考にしたけど途中でモデルがない？ってなったやつだわ。
>>679
こっちは見た事ないからちょっと勉強させてもらいます。
2021/08/22(日) 04:37:08.19ID:L9R2hvxM
こういうの見て正義に成ったと勘違いして
糞コード量産タイプになんだろな

reactとかだと1/10以下のコード量だぞおい
2021/08/22(日) 08:24:41.03ID:Y053yx43
>>680

>例えば計算機レベルのサンプル
>
>厳密に3つの責務(View, ViewModel, Model)に分けた所でPDSの冗長さが目立つだけです。
>計算機程度の小規模であるならば、ViewModelをModelと統合するのは大抵の場合あるべき姿です。

https://slidesplayer.net/slide/11235164/
2021/08/22(日) 10:06:31.28ID:hhuNowTY
>>681
趣味で盆栽的にやってるもんだから特に発信する気もないし誰にも迷惑かけんから勘弁してよ。

>>682
数日前にこのスライド読んで、今はMVCやMVPから調べ直してるところだわ。
684デフォルトの名無しさん
垢版 |
2021/08/22(日) 13:08:52.90ID:0Cz6ueFz
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴 バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412


Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
2021/08/22(日) 20:28:25.21ID:A59qHoiu
>>684
隔離スレから出てこないように
686デフォルトの名無しさん
垢版 |
2021/08/23(月) 04:16:34.70ID:7m4C54nZ
>>675
自分もそれは思ってたな
でも結局MVVMの基礎部分はこのインターフェースを使ってこの通りに実装するみたいな感じの決まり事だった
687デフォルトの名無しさん
垢版 |
2021/08/23(月) 04:16:35.32ID:7m4C54nZ
>>675
自分もそれは思ってたな
でも結局MVVMの基礎部分はこのインターフェースを使ってこの通りに実装するみたいな感じの決まり事だった
688デフォルトの名無しさん
垢版 |
2021/08/24(火) 15:32:26.18ID:WZMj7UxV
秘伝のへたれ
2021/08/24(火) 20:56:36.64ID:nOPW+Wx/
>>687
たった1週間程度だけど調べてサンプル写経して、WPFで用意されたデータバインドと各インターフェースを用いてオブジェクト指向で作ったのがMVVMになんのかなと、とりあえず理解した。
WPFでMVVMって秘伝のタレというより、作り手の匙加減で決まるお袋の味みたいなもんか。
2021/08/24(火) 21:49:09.60ID:3M+O79CU
MVVMは従来のWindowを幾つも開くタイプのアプリじゃなくて、1つのフレームにページを読み込むWebページのような動作をするアプリに最適なアーキテクチャで
MVVMのベースとなるｐｒｉｍｓやMVVM Toolkitなどのライブラリはそっちで必要なDIやマルチキャストのイベントなどの機能も盛り込まれています
Windows template studioというMSによるVSの拡張機能でこれらを使った雛形でアプリを作れるけど、生成されたアプリを眺めていけば見えてくるんじゃないかな
2021/08/24(火) 21:58:06.93ID:NErefsYh
>MVVMは従来のWindowを幾つも開くタイプのアプリじゃなくて、1つのフレームにページを読み込むWebページのような動作をするアプリに最適なアーキテクチャで

逆に、MFCやFormsと比べてもその違いを意識することが少ないと思うが。
トップレベルの要素が<Window>かそうじゃないかの違いくらいしかないし。
692デフォルトの名無しさん
垢版 |
2021/08/24(火) 22:00:09.91ID:Fpbrw/6U
うん、あんまり関係ないね
むしろマルチページアプリをコードビハインドを最小にする純粋MVVMで作ろうとすると苦労する
2021/08/24(火) 22:01:39.27ID:XRxvSkOV
>>689
あなたが苦労して作ったのは大半が MVVM 部分じゃなくて
MVVM + α の α の部分
694デフォルトの名無しさん
垢版 |
2021/08/25(水) 03:57:42.90ID:J/1+/EUy
VMのプロパティとXAMLのプロパティ(Text="Hello World"のTextがプロパティ)をバインディングして組んでいくのがWPFのMVVM
オブジェクト指向がどうとか難しいこと考えなくていい
695デフォルトの名無しさん
垢版 |
2021/08/25(水) 07:05:02.51ID:J/1+/EUy
個人ツール作るだけだと設計が自由でDIで困るような事態にならないので
何もわからない状態のときに、よく見るPrismって何だとか必須なのかとか思って調べてた時間が無駄だった
入門者がMVVMを理解しようとする上で邪魔な情報が多い
今のところ手間削減のために使ってみたいと感じさせてくれるものはReactivePropertyだな
2021/08/25(水) 07:50:46.77ID:H6wiA6E4
とにかく楽してMVVMしたい人向けならCaliburn.Micro一択
2021/08/25(水) 16:32:19.70ID:efp5szRf
>>696
caliburnはもう死んだだろ
2021/08/25(水) 16:40:02.69ID:jUUODgwG
>>694
自分それだわ
バインドバインドぉ！mvvm？こんなのでいいの？動くからおｋ
2021/08/25(水) 16:54:38.02ID:rhTS1cJX
ReactivePropertyでVM作るのパズル組んでるみたいで楽しい
700デフォルトの名無しさん
垢版 |
2021/08/25(水) 17:57:25.18ID:eN7VzoDp
viewのイベントを全部vmで拾えれば楽なのに
コードビハインドからvmのコマンドつかったら疎結合ガーとか面倒くさい
2021/08/25(水) 19:13:09.36ID:acmPLHd8
疎結合おじさん

笑
2021/08/25(水) 19:17:59.52ID:acmPLHd8
bland用のframeworkを
mvvmと称して流布した？？だれ？(･･;)
の罪は重いな
703デフォルトの名無しさん
垢版 |
2021/08/25(水) 19:48:43.46ID:J/1+/EUy
MVVMでイベントが使いたいときはMicrosoft.Xaml.Behaviorsを使おう
これ公式WPF拡張パッチみたいなもんだよね
704デフォルトの名無しさん
垢版 |
2021/08/25(水) 20:24:15.90ID:rgXi1H5Z
>>699
慣れたらReactivePropertyは手放せない罠
Prismはそれほどでもない
2021/08/25(水) 20:56:38.65ID:NVjF9CjI
ReactivePropertyはナシだな
個人作成のは業務で使えんわ
Prismもサードパーティ扱いだからギリNG
2021/08/25(水) 21:21:12.91ID:8WeB8rUa
ReactivePropertyやPrism相当のものをMicrosoftが用意しないのがダメすぎる。
ライブラリでもプラットフォームでも各自で勝手にやってくれがひどすぎる。
2021/08/25(水) 21:25:29.69ID:w4zcDk6l
っ Microsoft.Toolkit.Mvvm (MVVM Toolkit)
2021/08/25(水) 21:45:37.63ID:NVjF9CjI
これ来るの遅すぎた
名前空間にMicrosoftが付いてればどこの現場でも文句言われずに使えるのに
2021/08/25(水) 21:47:59.78ID:OX0ngrMb
>>705
多くのオープンソースライブラリが使えなくて大変な職場だねー
2021/08/25(水) 22:07:43.44ID:rgXi1H5Z
まあガチガチな所はそうでしょう
遅れてるとしか思わんが
2021/08/25(水) 22:12:40.48ID:hCSs42Ld
リスクがあるのは事実だからねえ
JSON.NETの作者に悪意があれば明日にも.NETは崩壊するんだよ
2021/08/25(水) 22:16:18.43ID:4eXJCyoq
>>711
気になるならSystem.Text.Jsonに移行すればいいんじゃないの？
2021/08/25(水) 22:21:02.62ID:w4zcDk6l
Json.NETはMITライセンスでソースが公開されているからどうとでもなるような
2021/08/25(水) 22:23:12.71ID:rhTS1cJX
ReactivePropertyもMITライセンスだね
2021/08/25(水) 22:43:32.24ID:H6wiA6E4
そんなおいらはLitJSON
ただし日本語の扱いにちょいと問題あって自分で直す必要あるんよ
2021/08/25(水) 23:13:06.54ID:9vnK5UYj
ReactivePropertyってコレクションと双方向バインドできないよね？
2021/08/26(木) 07:18:08.68ID:uYrXn854
できますん
2021/08/27(金) 11:29:58.61ID:RLcNjb1t
MVVMスレが過疎ってるんでこちらで質問させてください。（>>8 その通りです）

Microsoft.Toolkit.Mvvmは、Prismなんかの外部のMVVMフレームワークに対抗して、Microsoft内で作ったMVVMフレームワーク、という認識で合っていますか？
Prismの使い方を知らないんですが、これからはMicrosoft.Toolkit.Mvvmを勉強すればいいですか？
2021/08/27(金) 12:35:53.57ID:+WAf4pLi
コミュニティツールキットの一部だけど、MS公式と考えていいと思う。
自分の使いたい機能だけピックアップして使えるし、将来性もあるし、軽量だからお勧め。
720デフォルトの名無しさん
垢版 |
2021/08/27(金) 12:47:47.66ID:Vf27KQAk
wpf と同時期に Bland っていうデザイナーアプリが同時期にリリースされていて

wpf ： dotNet標準ライブラリ（プレーンな mvvm 機能のみ）
Bland(デザイナー) ： Bland SDK（mvvmを拡張してドラッグ＆ドロップでUIを設計出来る機能を追加）

ってすみ分けだったんだよ
dotNet標準ライブラリにはプレーンな mvvm 機能のみしか導入しないという意志に思えた
そもそも wpf ＝ mvvm 必須でもないし、
以前のFormsアプリのようにイベントハンドラー（コードビハインド）でも実装出来る

Bland SDK は Bland(デザイナー)を購入しなくてもダウンロード出来たし、
配布も自由だったから、
必要ならdotNet標準ライブラリと Bland SDKを組み合わせて使えって感じ

wpfの登場時からずっと追っかけてる俺からすると、
（wpf → Xamarin → Vue.js → React で Xaml系列は数年前に捨てた）

Bland SDK → Microsoft.Toolkit.Mvvm

に見える（Bland SDK は終了）
標準ライブラリに入るものではなく、
これらの機能はあくまでオプション扱いという事かな
2021/08/27(金) 12:49:05.65ID:Y9IwEnSW
Prismは元々MSが作ったサンプルコード集で、MSがメンテを終了しコミュニティに移管された
まず確実にMicrosoft.Toolkit.Mvvmも同じ運命を辿る
2021/08/27(金) 13:04:11.97ID:7dOJ0Fee
>>720
Blendでしょ
723デフォルトの名無しさん
垢版 |
2021/08/27(金) 13:48:17.67ID:Vf27KQAk
>>722
(;´Д｀)
2021/08/27(金) 15:03:57.58ID:RLcNjb1t
皆さん、ありがとうございます。

>>719
一応、MS公式と考えてもいいんですね。
他のと比較すると軽量らしいですね。

>>720
なるほど、勉強になります。
ちなみに、そのBlendのドラッグ＆ドロップでUIを設計出来る機能は
Microsoft.Toolkit.Mvvmに引き継がれていそうですか？

>>721
へぇ、Prismも元々はMS製だったんですね。
それなら標準に入れてほしかったですね…。
同じ運命を辿るなら将来性はありますね。
勉強してみます。
725デフォルトの名無しさん
垢版 |
2021/08/27(金) 17:11:23.78ID:Vf27KQAk
>>724
VS 使わなくなって長いからわからんね
VS 使えれば、Blendもライセンス的に付属していたとい思うので、
試してくださいな
726デフォルトの名無しさん
垢版 |
2021/08/27(金) 17:18:03.70ID:ahqxLAuM
デスクトップアプリとウェブアプリ一緒にしてるあたり理解度低そうだな
727デフォルトの名無しさん
垢版 |
2021/08/27(金) 17:21:57.98ID:Vf27KQAk
そんなあなたにElectron！
2021/08/27(金) 18:22:27.64ID:SHdBUDHT
Electronしたいけど
作り方がよくわからん・・・
2021/08/27(金) 19:16:29.04ID:7eXWtuz7
Blendはそのうち消えるだろ。
覚える必要なし。

Electronは1アプリごとに新しくブラウザを追加インストールするようなアホアホマンだからやめとけ。
2021/08/27(金) 19:26:17.01ID:Q47YKSur
JavaアプリケーションとJavaアプレットは同一で作れたんじゃ
2021/08/27(金) 19:36:53.91ID:RLcNjb1t
>>725
BlendはVSに抱き合わせで入っていたんですが、速攻で消しました（笑）。
Microsoft.Toolkit.Mvvmでできるか試してみます。
2021/08/27(金) 19:39:16.57ID:XVCMVrJv
Microsoft.Toolkit.Mvvmを覚えるには、今の所Windows Template StudioというVSの拡張を入れてから
WInUI3かWpfの雛形を自動生成して、そのコードをMSのドキュメント見ながら学習した
ライブラリの中でもMessengerは便利でお薦め
733デフォルトの名無しさん
垢版 |
2021/08/27(金) 22:23:27.21ID:Vf27KQAk
>>728
そんなに難しくないですよー−
ＵＩ/ＵＸに凝りたいならWebの数多あるUIライブラリーが使えるのでおすすめ
一応、Web系はなんでも動く、React, Vueに
ASP.NET Razorとかでもクライアントアプリ作れます

ローカルリソースにあんまアクセスしななら、
PWAとかでもデスクトップアプリ作れますよー−
OS問わずマルチプラットフォームで動きます
734デフォルトの名無しさん
垢版 |
2021/08/27(金) 22:29:33.81ID:Vf27KQAk
そういえば、Messengerパターンって自分が
いろいろ方向性を変えたきっかけでしたね
2021/08/27(金) 23:24:12.33ID:Pcfxrq+u
>>733
Electronで
ユニバーサルスタンドアロンデスクトップアプリケーションの作成方法
Win10pro64bit環境で具体的手順を誘導お流いします
736デフォルトの名無しさん
垢版 |
2021/08/27(金) 23:50:29.03ID:Vf27KQAk
早くにVSからVS Codeに脱却する事をお勧めするが
（いつまでたってもオープンソース世界に行けなくなるので）
手っ取り早くVS使って、派生.NET版のElectron.NETこのあたりで入門できへん？
Blazor使うやつと、ASP.NET MVC Razor のやつ C#で書けるからやりやすいでしょ
https://qiita.com/minoura_a/items/6361a213fdb86343c441
https://qiita.com/nqdior/items/d21d67624d893225762c
2021/08/28(土) 00:01:20.25ID:t/0aPppO
>>736
サンクスや鳥会えず見てハロワで基礎かしらねば如何もです
738デフォルトの名無しさん
垢版 |
2021/08/28(土) 00:09:05.90ID:5cd2kTad
>>737
最初のはBlazorだからデバック面倒なのでやめといたほうが良いね

ASP.NET CORE MVC の方が良いでしょ
動けば、ローカルリソースを使う部分以外のUI的なのは普通のWebアプリと同じ

一応、Electron.NETは派生なので、元のElectronとは少し違う、似てるけど、
.NETな人が雰囲気つかむ目的なら最適かな
739デフォルトの名無しさん
垢版 |
2021/08/28(土) 00:15:46.06ID:5cd2kTad
記事のリンク先にあった、こっちのが素のElectonだ
https://qiita.com/nqdior/items/091200c9f01e8827fdbd

この場合、ローカルアクセス部分をＣ＃で書きたいなら、
Edge.js という便利なのがある
https://github.com/agracio/edge-js
これは js <-> C# ブリッジだ！

では、貴殿の検討を祈る！
2021/08/28(土) 00:20:01.51ID:U4nd98Cv
>>738
ASPとか素人なのでLinuxのコマンドみたいなのはよくわからない
Windowsの黒い画面にコピればいいのかな？
エラーの嵐これは場違いなようだワ出直してくらぁ
でもあーざーした
2021/08/28(土) 01:37:37.38ID:iKEKAWV9
スレチと自分語りしかいなくなってしまったなｗ
2021/08/28(土) 02:57:21.18ID:5qToFZIh
>>732
Windows Template Studio、さっそくインストールして試してみました。
いいですね。Navigation Paneのテンプレートもすぐに試せました。

でも、その参考にしたサイトがPrism推しで、
良いチュートリアルがあるみたいなんで
Prismでもいいのかなとまだ少し迷っています。
ああいうサイトがもう少し前にあったらPrismやってたんですけどね。
2021/08/28(土) 06:38:54.70ID:hybb9KOp
信者がｷﾓｲからElectronはやめておこうっと…
2021/08/28(土) 11:56:24.12ID:Ft/jS/XE
Prismは複雑怪奇だったんだが、Ver７で破壊的更新をやって前との互換性は失ったけど
機能は整理されて格段に使いやすくなっているんだよな
昔触った人が二度と使いたくないと思う気持ちはわかるし、
互換性を犠牲にしたバージョンアップで他所に移った人もいるだろうが
今のやつは言うほど酷いものじゃない
2021/08/28(土) 20:09:03.92ID:VSJ2s/IQ
prismは途中から路線変更してフレームワーク的なライブラリみたいなのになったところで切った
2021/08/28(土) 21:00:05.63ID:gUcQvnZZ
なんで？
2021/08/28(土) 21:04:04.97ID:/sXnGLY7
Webview2ってClearScriptみたいにJSのFunctionオブジェクトをデリゲートに変換できないのかな？
UIだけReact、それ以外の層を.NETで実装してて詰まった
素直にmessage使うしかない？
2021/08/28(土) 21:57:39.12ID:5oeB/yz3
>>745
切らないでも便利なライブラリだけ使えばよくね？
2021/08/28(土) 22:09:34.58ID:2IM7P+Sb
>>720
BlendはXAMLの拡張だしMicrosoft.Toolkit.Mvvmと比べるようなものではないだろ
XAML=MVVMだと思っているのか
2021/08/28(土) 22:34:13.14ID:5cd2kTad
>>747
素直にElection.NETじゃね？
2021/08/29(日) 08:10:20.00ID:Fm6ljTvP
>>748
だからPrismみたいに図体の大きい融通の利かないのじゃなくて
他の便利なライブラリに移ったんだろ
752デフォルトの名無しさん
垢版 |
2021/08/29(日) 12:47:48.75ID:HULgazpW
>>751
DLLのサイズ確認したけど
Prism.dll : 90KB
Microsoft.Toolkit.Mvvm.dll :73KB
大してサイズ変わらないと思う
Prism.Coreだけnugetしたら特別図体が大きいわけじゃないね
2021/08/29(日) 12:55:35.31ID:V85oGWwE
本質のわからないの登場！
2021/08/29(日) 14:40:31.76ID:iwrRkutN
もう頑張らなくていいのよ。
Prismはオワコンだもの。
2021/08/29(日) 15:02:04.81ID:4bz4iTJn
prism使ってるけどwindow開いていってるわ・・・
2021/08/29(日) 15:25:31.85ID:jvopQfa6
本質というか、周回遅れすぎる感じ
すでに表彰式終って解散してるのに、これからマラソン始める人いるよ
2021/08/29(日) 15:28:39.38ID:ik0U7t7o
WPFの周辺技術にオワコンでないものなんて存在しないんだから好きなの使えばいいよ
2021/08/29(日) 15:35:30.15ID:LTWMhyi3
WPFとUWPオワコンなの気づかずにまた2つを合体させようと頑張ってるMSってなんか哀れだよね
759デフォルトの名無しさん
垢版 |
2021/08/29(日) 16:12:15.50ID:dtCWmxdj
でWinUI3は使い物になるのかねエロい人
2021/08/29(日) 19:14:54.89ID:9Pk8AgqG
WPFとかUWPとか関係ない
Windowsがオワコンなだけ
WPF、UWPに変わる優れたシングル環境のフレームワーク出てきてもwindowsアプリ増えないから

flutterなどのクロスプラットフォームに寄生して、ついでにWindows向けをビルドしてもらうしかない
2021/08/29(日) 19:20:15.34ID:9Pk8AgqG
まぁ、win11でandroidアプリの実行環境が用意されるから、もうこうやってアプリ増やすしかない
LOBとかならまだしも一般向けのアプリのwindows専用に作る人なんてわずかだろ
2021/08/29(日) 21:53:04.96ID:pAl4bTqC
そもそもソフトウェア自身が儲けにくくなってきてる気がするよ。
検索エンジンで儲けた金で大量のプログラマに作らせたソフトを無料で配布される
ようになってしまったり、MS Officeみたいに独占禁止法違反してそれ以外のものが
入っていく余地がほとんど無くなったり。作っても作っても、MS Wordなどに
真似されて実装されるから自分が作ったものがまともに売れることは無い。
763デフォルトの名無しさん
垢版 |
2021/08/29(日) 22:37:23.02ID:Gp+if449
Wordの新機能なんて興味ないから全く知らないんだが
なんかひどいことしてんの？
764デフォルトの名無しさん
垢版 |
2021/08/29(日) 22:42:34.76ID:Tc6fsQ2f
今時Windowsのソフト開発なんてほとんどがB2Bでしょう
2021/08/29(日) 23:17:01.60ID:V85oGWwE
業務システムはほぼWebになったよ
2021/08/30(月) 00:08:17.14ID:SBazV8cv
C#でWeb系やるとしたらASP.NETしか無いですか？
C#とJavaScriptとの組み合わせも可能ですか？
それをやるんだったらNode.jsとの組み合わせの方が楽ですか？
767デフォルトの名無しさん
垢版 |
2021/08/30(月) 01:57:25.98ID:N02FEXFE
>>765
そういう会社もあるかもしれんけど、たとえば奉行なんか使っている大多数の企業はなってない
2021/08/30(月) 02:20:34.86ID:IRMGlM4T
>>767
大手、中堅どころの企業なら
システム開発はほとんどWebだよ

業界の人なら営業が持ってる案件表見てみるがいい
もしクライアントアプリがそこに有るとすれば
スマホ位しかない

大体運用やメンテナンスし辛いクライアントアプリとか
情室が嫌がる
2021/08/30(月) 02:24:16.67ID:IRMGlM4T
業務系のエンジニアなら
10年以上前からその流れになってたから
殆どのエンジニアはWebに流れたよ
仕事先細りして食ってけないから
2021/08/30(月) 06:08:05.56ID:ptT0Gy37
C#はクロスプラットゲーム向けと、
内部GUI/CUIツール向きかな。
2021/08/30(月) 06:20:07.92ID:GR8G5Ywb
デスクトップアプリからWebに移ってまたデスクトップに回帰する流れもあるところはあるけどな
772デフォルトの名無しさん
垢版 |
2021/08/30(月) 06:40:21.81ID:xlSOQRHN
WebやるならVueがWPFに似てるから良さそうだな
773デフォルトの名無しさん
垢版 |
2021/08/30(月) 09:03:38.02ID:IRMGlM4T
業務系の開発現場にいたらわかるけど、
（自分は独立してて、あちこちの開発現場に出入りしてた）
10年以上前から Web開発者 > クライアントアプリ開発者 になってた
今じゃ、クライアントアプリの開発なんて保守しかないし
会議にも呼ばれなくなって立ち位置がどんどん低くなってんだよ
（俺も専門は元々クライアント側だったけど、web系に完全シフトした
WPFもXamarinももう依頼されても仕事受けない）

それでも、サーバーサイドはまだC#は残ってる
ASP.NETの新規開発はまだあるし
ただWeb開発担当者の口癖は、
３年位前は次はAngularで、
２年位前は次はVue.jsで、
１年位前から絶対React！！になってる 笑
世界的に見ても、React一強の情勢になってしまったからね

あと、クライアントアプリの新規開発はFlutter激増してる
これはデスクトップからスマホにWebアプリまで作れる
しかも新機能のリリースがめちゃくちゃ早い
笑うぐらいに死角が無いし、開発者ならすぐ仕事みつかる
2021/08/30(月) 09:42:39.49ID:txgJXV1k
ReactかSvelteかな
MVVMの本来の目的を意識低く実現していて、ああ、MVVMで色々変なクラス捏ねくり回してやろうとしてたのは結局こんなくだらないことだったんだなあと
Vueは所詮MVVMなのでアーキテクチャ的にはあまり学びはないかな
775デフォルトの名無しさん
垢版 |
2021/08/30(月) 10:11:13.12ID:IRMGlM4T
>>774
“MVVMで色々変なクラス捏ねくり回してやろうとしてたのは”
過剰なまでの疎結合だよ
意味的にもMVVMとはちと違う指向
776デフォルトの名無しさん
垢版 |
2021/08/30(月) 10:15:37.52ID:IRMGlM4T
そういえば、１年位まえに期間限定で（３カ月〜半年？）b
blazorは良く話題に出たね
もう半年以上前から全く聞かなくなったけど、
流行が早い早い
2021/08/30(月) 10:43:57.17ID:VJCtgJu8
Web系はガキのお遊び感があるからな。
オモチャを取っ換え引っ換えして非生産的なことしてんなーって。
業種によってはC/C++もここ数十年見たことも聞いたことない、とっくに滅んだっしょっ、て認識のところもあるしなー。
2021/08/30(月) 10:45:00.65ID:ptT0Gy37
flutterも数年かなという印象やな。

ぼっと作ってはWebエンジニアが飛びついて、
2、3年で古くしていくってもうアホなのカスなのって感じ。
あんなのと無縁で幸せだわ。
779デフォルトの名無しさん
垢版 |
2021/08/30(月) 14:12:46.83ID:a7szkEqk
ほんそれ
2021/08/30(月) 15:19:24.77ID:q7ZGBIFp
Googleだけでも、少なくとも Go, Kotlin, Dart の3つの言語作ってしまったし。
GoogleDriveやOneDriveなどの多数のOnlineStorageをまとめて制御できるライブラリ
がGoogle自らGoで書いているが、Flutterでそれを使いたくても橋渡しが
難しいだろうし、全部推進という訳には行くまい。
2021/08/30(月) 15:21:53.98ID:q7ZGBIFp
どれか一つの言語だけに集中させないことにはどうにもならないということ。
2021/08/30(月) 15:23:45.62ID:q7ZGBIFp
Cはまだ、どの言語からも呼び出せる方法が存在していることが多いし、また、
Wasm化しても小さいしまだいい。
Goで書かれたライブラリはWasm化したらサイズも大きいし、多言語から
の呼び出し方も自明では無いし困る。
2021/08/30(月) 20:52:43.38ID:0LjWH8LC
>>773
購買や経費管理といった、昔ならクラサバでやっていたような「業務システム」は10年どころか
20年くらい前からWeb化されていたけど、業務で使うソフトウェアってそればかりじゃないわけで。
そのへんは業種業態によって変わるだろう。うちはメーカーだけど内製のツールはまだまだ
スタンドアロンが多いな。つか、そういうのはわざわざWeb化するメリットも少なかったり。
784デフォルトの名無しさん
垢版 |
2021/08/30(月) 21:22:51.90ID:N02FEXFE
>>768
うちはパッケージ屋が本業だからうちのパッケージしか案件表にないんだ
すまんなｗ
けど大手企業とかもいまだにパッケージ頼りのところ結構あるぜ
比率は知らんけど
785デフォルトの名無しさん
垢版 |
2021/08/30(月) 22:23:36.00ID:IRMGlM4T
確かに、パッケージ屋は個別業務開発とは趣きが違うから想像はできるけど、
クラウド化は推進してないの？
ちょっと前に出入りしたパッケージ屋さんだと、昔はオンプレで運用してたらしいけど、
今はデフォがクラウドでマルチテナントで運用してたねー−
オンプレとかデスクトップクライアントとかは個別対応になる感じだったかな
786デフォルトの名無しさん
垢版 |
2021/08/31(火) 00:30:57.16ID:FDZ2966r
クラウド化が何を指してるのか分からんが
AzureもAWSも使ってバーチャルデスクトップ運用してるところが多いよ
今後はAzure Ｖｉｒｔｕａｌ DesktopだかでiPadとかChromeBookがクライアントの案件増えるっぽい
2021/08/31(火) 01:12:13.43ID:CVnDLQG8
使いにくそう
2021/08/31(火) 12:18:58.46ID:T79gwdP9
>>780
Kotlinはgoogleじゃないような
789デフォルトの名無しさん
垢版 |
2021/08/31(火) 12:36:05.84ID:OM0KfKDz
Formsなのですが、FileStreamで一つのファイルの更新って難しいですか？

今、壁になっていることは

ファイルを読み込む
↓
読み込んだファイルがロック状態になる
↓
書き込もうとしても書き込めない

読み込むファイルと書き込むファイルが違えば可能なのですが、
これってよくあるテンポラリーファイルなどを複製して対応するしかないのでしょうか
2021/08/31(火) 12:43:21.40ID:obbXOwAL
>>789
streamはそういう仕様。
791デフォルトの名無しさん
垢版 |
2021/08/31(火) 12:49:11.17ID:OM0KfKDz
>>790
ありがとうございます！
一時ファイルを複製して対応します
2021/08/31(火) 12:51:16.63ID:8qO1h2Cp
試してないけど読み込み側FileStreamのコンストラクタでFileShare指定すればいいんじゃないの
793デフォルトの名無しさん
垢版 |
2021/08/31(火) 13:05:05.10ID:OM0KfKDz
>>792
ありがとうございます
何かできそうな気がします！
2021/08/31(火) 17:02:54.56ID:0Y8XnIWp
StreamReader/Writerのコンストラクタに渡せん？（あんま覚えてない
2021/08/31(火) 18:21:02.48ID:b4XuI4dD
つうか、
１．元ファイルを読みながらテンポラリファイルに書き込む
２．元ファイルを削除
３，テンポラリファイルを元ファイルの名前にリネーム

この手順が定番だが、これをやらないと書き込みエラーでファイルを失うよ
2021/08/31(火) 20:42:24.00ID:S8r07VdU
読み込むファイル自体に、書き込む香具師は、頭おかしい。
エンジニアじゃない

安全配慮義務違反
2021/08/31(火) 21:01:42.89ID:jRAzxqNw
不正アクセス禁止法で逮捕されるぞ
2021/08/31(火) 22:46:50.56ID:521GQ/2f
追記されていくだけのログとかならFileShare.Readつけても大丈夫だけどな
2021/09/01(水) 01:06:46.56ID:bQ9HbNuf
どれもこれも全部サクラエディタって奴が悪いんだ
2021/09/01(水) 04:15:02.36ID:4UYQNKo4
>>795
元ファイル削除しないで新規ファイルをリネームで上書きできない？
2021/09/01(水) 05:21:00.61ID:Vv+SLpMR
WPF関係ある？
2021/09/02(木) 07:06:57.92ID:t5Xnv5c8
Windows App SDK 0.8.3
2021/09/08(水) 11:42:39.52ID:txwdym3f
MAUIもxamlなの？
2021/09/08(水) 11:55:27.04ID:YKU1gQn9
>>803
Xamarin.Formsの発展形がMAUIなんだし、xamlが基本になるんじゃね？
2021/09/08(水) 13:52:14.51ID:txwdym3f
>>804
ふーん
C#はもう諦めるわ
2021/09/08(水) 15:47:04.39ID:AltSwm2n
>>805
イミフ
2021/09/08(水) 16:46:08.35ID:ZH44DFyL
>>805
雑魚ww
2021/09/08(水) 21:07:13.93ID:4MNBog85
>>805
意味わかってなさそう
2021/09/08(水) 22:37:10.46ID:2xQeb5pF
XAMLもIntellisenseで自動で埋めてくれんかな
ItemsSource{Binding = Data}
とか書いた時点でDataがどんな型か読み取って適当に表示してくれればいいのに
例えばList<int>だったら自動で要素まで分解して表示するとかさ
例えばList<List<int>>だったら自動で2×2で要素まで分解して表示するとかさ
ComboBoxやListBoxだって適当に良きに計らえよ

いちいち打つ側が指定してやらんのが面倒くさい
2021/09/08(水) 23:02:45.97ID:cN4s0i9P
d:DataContext="{d:DesignInstance ...

で行けたような。
811デフォルトの名無しさん
垢版 |
2021/09/09(木) 04:15:16.01ID:J/vtDPz0
VS2022でマウスポインタを上に載せたら型が表示されたけど
2021/09/09(木) 08:56:30.61ID:QA/522jQ
>>809
スニペットddc使えよ
ちゃんと補完するぞ
2021/09/09(木) 09:26:45.67ID:1R8XfWJw
>>809
UWPとWinUIのx:Bindはインテリセンス効くよ
2021/09/09(木) 13:08:42.17ID:2xcgEBdF
終わったプラットフォームと始まる前のプラットフォームの話してるやつなんなの？
2021/09/09(木) 13:19:26.52ID:We0c3TJB
MSのUIプラットフォームは始まる前に終わるので
816デフォルトの名無しさん
垢版 |
2021/09/09(木) 14:43:39.58ID:W15P/1XI
署名なしの野良配布で開発モードONはなしで、
mauiは普通に野良配布できるの？
2021/09/09(木) 16:01:43.06ID:o5mbqb9U
名前を変えただけの悪名高きxamarinに何を期待してるんだか
2021/09/09(木) 16:10:33.92ID:mXrNvNu+
Xamarinと違って一からMSが開発するから期待してる
2021/09/09(木) 20:46:17.54ID:lJRSMQ7p
何でもいいから一つにまとめろや
2021/09/09(木) 21:10:08.64ID:q0TKbS94
>>814
じゃあ終わってないプラットフォームの話して。
2021/09/09(木) 22:20:16.73ID:wRnzaYRw
このスレで扱うのが適切な、始まっててかつ終わってないプラットフォームって実は存在しないのでは？
822デフォルトの名無しさん
垢版 |
2021/09/09(木) 22:43:15.68ID:d4+NBsbj
MSのコードプラットフォームの主力がVSCodeに移ってもう長いし、
そもそもMSがオープンソースに舵切ってから相当たってるのに、
MSからまともなライブラリのが出てくる見込みはねえぞ。
823809
垢版 |
2021/09/09(木) 23:45:47.17ID:RORfDysf
>>810-813
♪あ〜〜〜〜〜〜り〜がと〜〜〜〜う
♪あ〜〜〜〜〜〜り〜がと〜〜〜〜う

XAMLでIntellisenseできました
スニペットでddcも行けました
UWPとWinUIはまた今度で
824デフォルトの名無しさん
垢版 |
2021/09/10(金) 01:39:42.95ID:7ibsVcuq
このスレ見てる時点でWindowsに絞ってる人間なんだから先にあるのはMAUIじゃなくてWinUI 3だよね
2021/09/10(金) 03:37:48.26ID:QQ5PLj0w
>>821
うん、存在しないね
2021/09/10(金) 06:02:04.48ID:Lruqlpqj
>>821
WPF。
UWPは始まりもしないまま終わったけどな。
2021/09/10(金) 11:27:22.51ID:RmQ4ECJ8
MAUIとWinUIって開発工程においてはどれくらい違うの？
2021/09/10(金) 11:37:57.48ID:mLV+UlPw
XAMLの
<ListBox ItemsSource="{Binding MyItems, ElementName=MyWindow}"/>
をコードビハインドで書くとどうなりますか？

this.listBox.ItemsSource = MyItems;
のようになるのは分かっても、ElementNameの指定方法が分かりません。
2021/09/10(金) 11:59:06.77ID:L+jftwLU
>>828
なんかおもいっきり違うな...
2021/09/10(金) 12:13:47.11ID:Lruqlpqj
>>828

<StackPanel>
<ListBox x:Name="list1" Height="100"/>
<Button Content="押しやがれ" Click="Button_Click"/>
</StackPanel>

private void Button_Click(object sender, RoutedEventArgs e)
{
list1.Items.Add("aaa");
}
2021/09/10(金) 12:55:58.47ID:Q+a9aIEQ
DirectXのDLLを参照してソフトを開発しているのですが、
開発環境ではちゃんと動作するものの別のPCだと参照エラーになる
調べてみると普通のPC(Windows10)にはDLLがインストールされていなくてこうなっているみたい

DLLを実行ファイルと同じ階層に置いてそれを参照するように設定すると
どの環境でも動くのですが、実行ファイルごとMSが作ったDLLを勝手に
配布したりするとダメらしい

たった2つのDLLのために2つも大きなランタイムファイルを
インストールしてもらうのも億劫なので、どうするべきか(T_T)
2021/09/10(金) 14:53:58.46ID:hSrIzeXT
>>829
全然違いました。

>>830
訂正、ありがとうございました。
それを使います。
833デフォルトの名無しさん
垢版 |
2021/09/10(金) 15:03:18.84ID:7ibsVcuq
どうするかは利用者が決めることだろ
2021/09/10(金) 15:37:55.55ID:I2sJLr90
>>831
DirectXのバージョンは？
2021/09/10(金) 16:08:35.11ID:G+HVY4K2
>MicrosoftのWin UI 3はUWPを捨ててWin32に集中

MSもようやく学習したかな?
2021/09/10(金) 16:21:51.87ID:cwpfUPcV
>>835
笑

まじでアホなのか、
コード書けないマネージャークラスが
非IT的な裁定を下してるかだな

それにもうMSもオープンソースに任せてんだろ
オープンソースはガチで良いものしか
上がって来れないからね
2021/09/10(金) 17:01:51.06ID:Q+a9aIEQ
>>834
DirectX9c
大変だけど別のMS-PLって緩いライセンスのDLLを使って
システムを改修しようと思います
2021/09/10(金) 22:40:26.42ID:g9DWrMgK
windows10じゃランタイムをインストールしないとダメだぞ
インストーラは再配布もできる
https://www.microsoft.com/en-us/download/search.aspx?q=directx
DirectX End-User Runtimes (June 2010)
This download provides the DirectX end-user redistributable that developers can include with their product.
2021/09/11(土) 00:40:48.87ID:COtgG/wM
DirectXランタイムって色んなバージョンの雑にまとめた全部入りだから数百MBあるけど
やろうと思えばDirectSetupとか使って必要な分だけ同梱してサイレントインストールとかできるぞ
ぶっちゃけ必要なのがD3DXのDLLだけだったら横に置いて配布しても今時誰にも怒られんけどな
Chromeとか堂々とやってたし

もっともDirectXランタイムはdeprecatedされかかってるレベルのレガシー物件だし
可能ならD3D11にしてDirectXTKとか使った方がいいけど
2021/09/11(土) 03:32:20.18ID:8euuf7tr
C#
public DataTable dT { get; } = new DataTable();

XAML
<Window x:Class="WpfApp.MainWindow"
x:Name="MyWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation";
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml";
xmlns:d="http://schemas.microsoft.com/expression/blend/2008";
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006";
mc:Ignorable="d"
Title="Demo" Height="500" Width="500">
になってるとき、XAMLの
<DataGrid ItemsSource="{Binding dT, ElementName=MyWindow}/>
をコードビハインドで書くにはどうすればいいんですか？

this.DataGrid.ItemsSource = dT;
だとElementNameが指定できませんよね？
2021/09/11(土) 09:20:06.87ID:iptXMpo5
>>839
勉強になります。そうなんですよ。レガシーなDirectXはサポート終了で
廃れた技術なので、DLLを同梱して怒る人がいるとは思えません
でもライセンスはライセンスなので、無視はできません

サポート終了のランタイムをインストールしてもらうのは
考えものなので、やはり別の手段を取ることにしました
842デフォルトの名無しさん
垢版 |
2021/09/12(日) 07:46:49.64ID:nJGdH/R7
>>840
DataGridに名前を付ける
それをコードビハインドで使う
843デフォルトの名無しさん
垢版 |
2021/09/12(日) 09:30:43.37ID:x3+6FKDq
>>839
同意
2021/09/12(日) 09:31:51.33ID:PzFjh7Et
>>840
SetBinding
2021/09/12(日) 11:02:35.52ID:CGi/+BiI
>>842
できました、ありがとうございます。ただ、ElementNameは指定しなくてもいいんですか？
（今回はMyWindowだから動いているかもしれないですけど、別のに変わったら動かなくなるとかありますか？）
<Window x:Class="DataTable_CodeBehind.MainWindow"
x:Name="MyWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation";
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml";
xmlns:d="http://schemas.microsoft.com/expression/blend/2008";
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006";
xmlns:local="clr-namespace:DataTable_CodeBehind"
mc:Ignorable="d"
Title="MainWindow" Height="250" Width="400">
<Grid>
<!--<DataGrid Name="dataGrid" ItemsSource="{Binding dt, ElementName=MyWindow}" AutoGenerateColumns="True"/>-->
<DataGrid Name="dataGrid" ItemsSource="{Binding}" AutoGenerateColumns="True"/>
</Grid>
</Window>

public partial class MainWindow : Window
{
public DataTable dt { get; } = new DataTable();
public MainWindow()
{
dt.Columns.Add("MyColumn", typeof(string));
dt.Rows.Add("Row of data");
InitializeComponent();
dataGrid.DataContext = dt; // XAMLでItemsSource="{Binding dt, ElementName=MyWindow}"が指定されてたらコメントアウトしてもOK
// でも、ElementName=MyWindowは指定しなくてもいいの？
}
}
2021/09/12(日) 11:14:27.19ID:CGi/+BiI
>>844
>>845の例だと具体的にはどう書きますか？

dataGrid.SetBinding(ItemsControl.ItemsSourceProperty, dt);

と書いてもダメでした。
2021/09/12(日) 11:28:19.94ID:CGi/+BiI
しまった、連投すみません

>>842
dataGrid.DataContext = dt;
ではなくて、
dataGrid.ItemsSource = dt;
みたいにできるはずなんですがご存じないですか？
2021/09/12(日) 16:39:23.72ID:2cHj/0c+
>>846
それだとオーバーロードが別の
dataGrid.SetBinding(ItemsControl.ItemsSourceProperty, "dt");
でいけない
840と同じなら
var bind = new Binding("dt"){ElementName = "MyWindow"};
dataGrid.SetBinding(ItemsControl.ItemsSourceProperty, bind);
して呼び出してみるとか。外からなんでなんか間違えてるかも
でも目的が達成されたからいいかな

バインディング宣言の概要 - WPF .NET Framework | Microsoft Docs
https://docs.microsoft.com/ja-jp/dotnet/desktop/wpf/data/binding-declarations-overview?view=netframeworkdesktop-4.8
2021/09/12(日) 18:46:39.81ID:D2v+xufE
そういやVM使わないWPFの挙動など殆ど把握していないわ
2021/09/12(日) 20:02:22.06ID:CGi/+BiI
>>848
仰る通り、

var bind = new Binding("dt"){ElementName = "MyWindow"};
dataGrid.SetBinding(ItemsControl.ItemsSourceProperty, bind);

で行けました！
これで行けるなら{ }の中を変えていろいろ指定できそうですね。

# ちなみに、
# dataGrid.SetBinding(ItemsControl.ItemsSourceProperty, "dt");
# は、DataGridは表示されるんですけど、
# ColumnもRowも表示されませんでした。

ありがとうございました！
2021/09/13(月) 13:34:55.60ID:1pSY0+gc
INotifyPropertyChangedってもっと脳死で簡単にできないの
2021/09/13(月) 13:41:22.00ID:8KbkkNk8
それを言ったらIEnumerableの方が頻出でもっと面倒では
2021/09/13(月) 14:11:11.72ID:FY5gKLvy
>>851
INotifyPropertyChangedを使わない。
馬鹿の一つ覚えで何でもかんでもVM作る病からの脱却せよ。
2021/09/13(月) 14:41:19.39ID:OQ1a75jl
>>853
更新の通知はどうするの
2021/09/13(月) 15:04:32.55ID:F74I8HoI
>>851
VM用の基本クラス使ったら楽だと思うけど
2021/09/13(月) 15:41:03.02ID:orh3RydC
>>851
むしろあれ以上に簡単にできないやろ
自動実装プロパティにイベントも自動実装されたらパフォーマンスガタ落ちになるんじゃ
2021/09/13(月) 15:53:20.23ID:ZNdqAxbM
結局WinUI3もWPFと実装方法は大して変わらないの？
2021/09/13(月) 17:07:46.28ID:Z203dzwp
>>854
通知も何もない。
UI操作を起点にUIを直接書き換えて終わりだろ。
それで事足りるアプリケーションは山ほどある。
2021/09/13(月) 17:28:00.98ID:bEKVtUlw
>>851
propfullとタイプしてからタブキー2回押すんだ
2021/09/13(月) 17:29:13.28ID:u3iBp6jh
ハッキリ言って個人レベルとか5000行未満のアプリならMVVMなんかより、ひたすらイベントパンドラで書いた方が見通しもいいし実は修正もしやすいよ。

VとVMがわかれててもC#てデスクトップのツールじゃメリットあまりないし。
ほぼ間違いなく同じ人間が書いてんだから。
別の人間がXamlだけ編集してるとか成功ケースないでしょう。
WPFは所詮デスクトップのツール向きで、商用アプリ向きではないし。

MがGUIでもコンソールでも変わらないAPIになるよう意識してればいいだけ。
2021/09/13(月) 17:52:25.62ID:8KbkkNk8
Caliburn.MicroならPropertyChangedBaseが実装済み、例を示すと
private string _LogBox;
public string LogBox
{
get => _LogBox;
set => Set(ref _LogBox, value);
}
一方XAMLは
<TextBox x:Name="LogBox" />
これでLogBoxに何か入れるとテキストボックスに反映される
十分すぎるほど簡単に感じるけど・・・これすら無理な人いるかも知れない？
2021/09/13(月) 18:29:40.64ID:CYNkmf4m
>>851
それを実装した汎用valueクラスを作ってそれを使う。

>>858
それが当たり前だよね。
完全にMVVMするのが目的になってしまった
なれのはて
2021/09/13(月) 20:22:16.87ID:4h53lU/m
>>857
VMの書き方はだいたい同じだが、Viewでx:Bindが使えるからインテリセンスが効くし型のチェックもコンパイル時にやってくれる
あと、Viewから右クリックの「定義へ移動」でVMの変数定義に移動できる
864デフォルトの名無しさん
垢版 |
2021/09/13(月) 21:03:21.49ID:/bWkDGfh
しょぼいプログラムほどMVVMでの実装も楽だからINotifyPropertyChangedを避ける理由がよくわからない
2021/09/13(月) 21:18:47.94ID:CYNkmf4m
しょぼいから
スケールメリットでねーーんじゃね？
2021/09/13(月) 21:21:14.98ID:bEG2fzdP
バインドしない人は文字−数値の変換も自分で書くの？
2021/09/13(月) 21:46:08.83ID:9YR282N/
>>860
VとVMの分離はべつにデザイナーとの分業だけが目的じゃあないが。というか重要度としては低い。
WPF知らない人にありがちな典型的な誤解。
2021/09/13(月) 22:02:18.04ID:Dz4DY8v7
いまだにMVVMに親を殺されたようなのがいるね
イベントハンドラしこしこ書くのはもういやだよ
でもWPFはFrameをもっとMVVMフレンドリーに作ってほしかたよ
2021/09/13(月) 22:10:10.87ID:u3iBp6jh
いや、知ってるからなんだけどw
ボダン押したら押したら更新する、同期性も何もない。

APIを呼ぶだけ。
大きくなる予定なし。

こんなのすらさえWVVMしだすっていうw
2021/09/13(月) 22:41:51.00ID:FSwgcC5n
INotifyPropertyChangedとINotifyCollectionChangedの違いを知りたいです。
このサイトを参考に話します（Xamarinですけど）：
https://qiita.com/furugen/items/18bd2a521d1fa9927212
これは
public class MemoData
{
public string Title
{
get;
set;
}
}
のTitleがプロパティだから、
public class MemoData : INotifyPropertyChangedなんですか？
もし、上のが
public class MemoData
{
public List<string> Title
{
get;
set;
}
}
だったら、
public class MemoData : INotifyCollectionChangedになりますか？
それとも、この場合はListからObservableCollectionに変更するだけで解決ですか？
ObservableCollectionが元々INotifyCollectionChangedを含んでいるのは知っています。
また、public class MemoData : INotifyCollectionChangedと書くケースは皆無ですか？
2021/09/13(月) 23:16:04.60ID:Dz4DY8v7
何をしたいかによる
2021/09/13(月) 23:44:39.21ID:CYNkmf4m
>>869
Mvvmじゃなくて通知の問題ね。
WPFのMvvm以前はこんな問題は発生してないねーー
2021/09/14(火) 05:34:23.96ID:TNbC6wpH
>>861
冗長。
コード側の6行は不要。XAML側の1行だけでOK。
2021/09/14(火) 08:22:12.46ID:Xw7cSOKQ
>>868
まだまだ初心者だな。
アプリに合わせて最適な実装方法を選択できるようにならなきゃ駄目だそ。道具は素材に合わせて使い分ける。
MVVMはあくまで道具の一つ。
2021/09/14(火) 08:31:12.46ID:ix6qKsp0
MVVMは目的じゃない
2021/09/14(火) 10:03:00.45ID:O0SG+hYH
>>873
ケースを想定せずにOKも何もないでしょうに
2021/09/14(火) 12:11:35.18ID:MzGXbjCU
コードビハインド禁止ゲームとか
アホの極み！
2021/09/14(火) 13:51:43.59ID:OUZkxtLl
今はPrismだけ使ってるけど、みんなReactiveProperty使ってるの？便利？
2021/09/14(火) 19:55:37.76ID:jxlCGXSG
>>874
もちろん、ポトペタやりたい人にとってはFormsがベストだしずっとそれを使い続けていればいい。
2021/09/14(火) 20:32:08.68ID:7Ijls0Z8
この辺は変な布教をした奴のせいでずっと尾を引いてるな
881デフォルトの名無しさん
垢版 |
2021/09/14(火) 21:59:50.08ID:GpK/E3pW
>>874
WPF使うならMVVMが常に最適解
MVVMイヤならWinForm使えばええねん
882デフォルトの名無しさん
垢版 |
2021/09/14(火) 22:01:29.25ID:GpK/E3pW
>>878
俺の個人的好みだとPrismは中小規模だと大げさすぎる
ReactivePropertyはもう手放せないレベル
でもいまだにBindingの .Valueを書き忘れてハマるｗ
2021/09/14(火) 22:05:51.96ID:bJ98HSzm
俺なんかWinFormsでやるときでさえReactiveProperty使ってMVVMやるようになってしまったよ
884デフォルトの名無しさん
垢版 |
2021/09/15(水) 01:05:39.31ID:jggBe0Ff
ポトペタやりたいならノーコードローコードでいい
2021/09/15(水) 06:31:36.42ID:4HoLv0k1
>>879
そう考えるってことはWPFを全然使いこなせていないってことだぞ。
WPFはFormsと比べればMVVMとの親和性が高いが、MVVMで作りやすいってのはWPFのメリットのごく一部。

>>881
全然違う。
日本語もWPFも勉強しなおし。
MVVM使うな、じゃなくて使うべきものに使えって書いてある。
思考停止してWPFだから必ずMVVM、は技術者として恥ずかしいぞ。

>>883
FormsにMVVMは馴染まない。
ちゃんとフレームワークに合った設計をしないと。
2021/09/15(水) 11:37:21.40ID:S1ATpspQ
煽り屋は下痢便食わせて多摩川にでも流すぞ
2021/09/15(水) 12:22:16.17ID:jnuePZVr
君にはすべてのクラスに
void Update(bool force = true)
を書く事を許可しよう、頑張りたまえ
2021/09/15(水) 12:50:15.43ID:MMIM4SfG
言っている事は正しいしただの指摘、煽りではないだろ
2021/09/15(水) 14:58:00.53ID:3TKYe9Fz
>>885
>FormsにMVVMは馴染まない。
お前の感覚以外にちゃんとした理由があるならぜひ
2021/09/15(水) 15:46:29.15ID:u+gVrdUN
理由もクソも、MVVMはそもそもWPFのデータバインディングを活用するために考案されたデザインパターン
双方向バインディングを使用しないなら定義上MVVMではない
2021/09/15(水) 15:57:04.37ID:a6LjJ0wO
やったこと無いけどFormsでもデータバインディングできるんじゃ？
2021/09/15(水) 16:02:38.01ID:FpSMo0oE
>>890
Forms+ReactivePropertyで双方向バインディングやってるけど
2021/09/15(水) 17:02:45.49ID:3TKYe9Fz
>>890
お前の言うMVVMの定義を教えてくれ
2021/09/15(水) 17:05:49.55ID:QKlVFcsu
業界アキーテクチャ的には
双方向バインディングはバッドパターンだ
糞認定済み
2021/09/15(水) 17:09:11.47ID:QKlVFcsu
react等の先端frameworkに比べると
思想的にかなり見劣りする
2021/09/15(水) 17:28:11.46ID:wmRmGPP4
次はMVUだったっけ？
897デフォルトの名無しさん
垢版 |
2021/09/15(水) 18:32:29.56ID:IqGZburM
実行ファイル(.exe)が出力できて将来性のある
プラットフォームってやっぱりWPFしかないのかな？
2021/09/15(水) 18:36:43.11ID:R2NlFkLx
将来性はないです
2021/09/15(水) 18:36:44.91ID:jnuePZVr
最先端はなんだろうAvaroniaとか？
SilverlightもWindows Phoneも、昔はいろいろあったよね
2021/09/15(水) 18:47:44.45ID:EcTTP5JU
>>897
WPFやるぐらいなら今後はWinUI3じゃ?
901デフォルトの名無しさん
垢版 |
2021/09/15(水) 19:00:42.07ID:IqGZburM
WPFに将来性はあまりないのか

>>900
ありがとう。ちょっと調べてみる
902デフォルトの名無しさん
垢版 |
2021/09/15(水) 20:53:25.10ID:bT20IgU4
>>885
日本語勉強するのはあんただよ

>
2021/09/15(水) 21:01:46.66ID:u4qV17E7
>>890
バインディングはあまり関係ないな。どっちかというと依存の方向がV→VM→Mだというのが重要。
そういう意味でFormsで真似しても似て非なるもの。
2021/09/15(水) 21:09:50.88ID:jnuePZVr
すでに10年以上過ぎてて将来性とか言われても
枯れてる方に分類されると思うんだけど、一体どんな期待してるんだ
2021/09/15(水) 21:13:29.91ID:FpSMo0oE
>>903
その方向の連携もFormsでできますけど
2021/09/15(水) 21:43:58.90ID:u4qV17E7
>>905
その「連携」ってどういう意味で使ってる？
一般に依存の方向と制御の方向は別物だがここで重要なのは依存の方向。
2021/09/15(水) 22:43:25.21ID:FpSMo0oE
>>906
もちろんVの表示はVMとMに依存してるよ
2021/09/15(水) 23:04:57.93ID:jnuePZVr
依存っていうからてっきり依存関係プロパティの話かと思ったら、全然違ってた
2021/09/15(水) 23:17:22.66ID:u4qV17E7
>>907
やっぱりなんか理解してない。ここではいわゆるSOLID原則のDで言う依存性のこと。
MVVMでVが直接Mに依存することはない。
2021/09/15(水) 23:30:44.49ID:qRxK7g6Y
Vで必要なMを作るんだから依存しないわけがない
2021/09/15(水) 23:49:11.29ID:u4qV17E7
>Vで必要なMを作るんだから依存しないわけがない

「依存」の意味が通じてないとそもそも会話にならんな。
2021/09/15(水) 23:50:13.08ID:VJ+jTlKE
>>882
ReactivePropertyはメンテナーが実質ひとりだからなぁ。
その.Valueも意外と面倒くさいんだよね。
2021/09/15(水) 23:54:05.43ID:VJ+jTlKE
ObservableCollectionがAddRangeに対応して、
主要なWPFコントロールがAddイベントにてe.NewItemを同時に複数受け付けてくれれば神アプデなんだけどMSやってくれないかな。

ObservableCollection関連は、各ItemへのProperyChangedの登録／解除が超絶に面倒臭いんだけど、ReactivePropertyだとお手軽になる？
2021/09/16(木) 00:20:59.60ID:eraz+HIm
>>911
なんかFormsでMVVMできないことにするために適当な理屈をウダウダ後付けで言ってんな
2021/09/16(木) 00:38:24.68ID:tuIfCOpX
|\/| Ｗ（
916デフォルトの名無しさん
垢版 |
2021/09/16(木) 01:24:47.16ID:fPzViGfa
>>912
今はokazukiがメインメンテナ？
彼がやめたら俺がやるわ
917デフォルトの名無しさん
垢版 |
2021/09/16(木) 01:54:46.93ID:fPzViGfa
>>913
極力簡易記述できるようにしてると思うよ
2021/09/16(木) 03:51:43.21ID:x4RkoMHs
おまえら酒どんくらい飲んでる？
2021/09/16(木) 08:50:08.52ID:EaJ+z9b7
MVVMはXAMLやFXMLといったマークアップ言語があって初めて実現する
XAMLを信じないものに未来はありません
XAMLは偉大にして唯一神と3回唱えるのです
920デフォルトの名無しさん
垢版 |
2021/09/16(木) 12:17:15.94ID:jImn+LiB
ObservableCollectionで個々のItemのPropertyChangedを取りたいときって、
NotifyCollectionChangedAction.Add・RemoveにPropertyChangedのイベント購読を登録・解除
しますよね？

その配列をClear()しちゃったら、Removeでの解除を通らないと思うのですが、
この場合、メモリリークしますか？
2021/09/16(木) 12:57:51.05ID:eraz+HIm
>>920
NotifyCollectionChangedAction.Reset飛んでこない？
922デフォルトの名無しさん
垢版 |
2021/09/16(木) 13:30:05.34ID:jImn+LiB
>>921
自分も最初はReset飛んできたとき解除すればいいと思ったんですが、配列がすでに消去済みなので解除できないことに気づきました。
各ItemのコンストラクタとDisposeに登録解除を書くしかないのかな。
2021/09/16(木) 14:17:14.99ID:sOgFGA/J
>>903
向いてるかどうかは別にして、
FormをVとしてVMとM作ってバインディングすればMVVMできると思うんだが
>似て非なるもの
どこが異なるんだよ？
お前の言う本当のMVVMってなんだよ
2021/09/16(木) 14:20:02.81ID:sOgFGA/J
ああ、バインディングはMVVMの構成要件じゃないのね
ますますお前の意見がわからんわ
2021/09/16(木) 14:31:38.92ID:eraz+HIm
>>922
ObservableCollectionに
protected override void ClearItems()
ってのがあるから
ObservableCollectionの派生クラス作ってClearItems()をオーバーライド
ClearItemsが呼ばれたタイミングで購読解除すればいいと思う。
926デフォルトの名無しさん
垢版 |
2021/09/16(木) 14:37:43.93ID:eraz+HIm
>>922
public class MyCollection<T> : ObservableCollection<T>
{
protected override void ClearItems()
{
//ここで購読解除
base.ClearItems();
}
}
927デフォルトの名無しさん
垢版 |
2021/09/16(木) 15:14:51.39ID:jImn+LiB
>>926うおーすごい。stack overflowでもそこまでドンピシャな回答無かったです。
ありがとうございました。
2021/09/16(木) 15:50:04.83ID:4N92z3xf
コレクションをオーバライドして
改良するってアーキテクチャ知らない人多いね
929デフォルトの名無しさん
垢版 |
2021/09/16(木) 18:38:42.38ID:EvK5hxPz
結論としては、超絶に面倒臭いって事か
2021/09/16(木) 19:41:02.61ID:yaf4gWdF
仮にオーバライドしないで出来るならその方がずっと楽だしな
2021/09/16(木) 22:04:26.97ID:vfYN11/r
>>923
クリーンアーキティクチャのあの同心円の図を想像するとわかりやすい。一番外側がVで中心がM。
その依存性逆転のためにバインディングという仕組みを使っているだけに過ぎない。
2021/09/16(木) 23:23:17.08ID:8UT+IRDB
https://docs.microsoft.com/en-us/archive/blogs/johngossman/introduction-to-modelviewviewmodel-pattern-for-building-wpf-apps
バインディングが関係ないとか言ってる奴はこのMVVMの原典を読んでおくように
> Model/View/ViewModel also relies on one more thing: a general mechanism for data binding.
2021/09/17(金) 01:51:24.22ID:oPdLmI0u
In practice however, only a small subset of application UI can be data bound directly to the Model, especially if the Model is a pre-existing class or data schema over which the application developer has no control.
モデルが既存のクラスで開発者がコントロールできない場合は、UIの一部のみを直接モデルにバインドできます。
ってあるけど、既存のクラスなんてINotifyPropertyChanged実装してるわけないし、どういう意図なんだろ？
OneTimeならそりゃできるだろうけど。
2021/09/17(金) 02:13:01.71ID:OCPIK6qi
>>931
バインディングが単なる手段に過ぎないという意見は分かった
で、
>Formsで真似しても似て非なるもの。
はどういうことなんだ？
お前の言う真のMVVMとはどういったものなんだ？
2021/09/17(金) 07:24:25.96ID:9pvNRBKH
滅茶苦茶な機械翻訳を鵜呑みにして混乱してる初心者あるある
また断続的な絞首刑が発生しちゃうね
2021/09/17(金) 08:29:29.04ID:oPdLmI0u
>>935
正しい翻訳と意図を教えてください。
2021/09/18(土) 11:02:29.85ID:R9rxcswy
>>935
正しい翻訳と意図を教えてください。
2021/09/18(土) 13:27:50.51ID:+rKdBgY8
Microsoft Silverlightがオープンソース化、「OpenSilver」ベータ版リリース
https://news.mynavi.jp/article/20210916-1974193/
2021/09/18(土) 14:29:04.75ID:4CYZLhbb
>>938
MSはどっち行きたいねん？
一つがっちりしたのを標準で出せや！
2021/09/18(土) 14:42:52.80ID:hjEU6C9z
Silverlightは救済策だろう
メインストリームはWinUI
2021/09/18(土) 14:59:53.94ID:owvkbREO
ActiveXじゃなくてWASMベースになったってのが興味深いな。
デスクトップ版も用意したうえでBlazorと組み合わせてほしい。
2021/09/18(土) 15:32:32.42ID:kMbDjnXI
ソースジェネレーターでバインディング周り上手い事オーバーヘッド無しに出来んかな
2021/09/18(土) 15:59:37.03ID:+rKdBgY8
>>939
まだわからんの
オープンソースだよMSは
2021/09/18(土) 16:06:02.78ID:5s23uQXu
MSとどういう関係があるのか読んでも分からん
2021/09/18(土) 16:46:49.61ID:IMNNusNt
>>944
タイトルが悪いと思う
オリジナルのSilverlightをMSが作ったってだけで、MSはほぼ無関係だな
UserwareがWebAssemblyで動作するようにSilverlightを実装しなおしたものをオープンソースでリリースしただけ
2021/09/18(土) 16:50:07.13ID:IMNNusNt
Userwareって会社ね
既存のSilverlightアプリをSilverlightからOpenSilverに移行するソリューションを売るみたい
2021/09/18(土) 18:33:51.64ID:QLsNBOiE
お
オープンソースSilverlightか
光ちゃんも引っ張ってこい
2021/09/18(土) 19:08:58.03ID:+Oz1AToR
>>945
タイトルが悪いと言うかわざとだろ、これ
UserwareがMicrosoftからソース譲渡してもらったならわかるけど "reimplementation of Silverlight" だから要するに互換ソフトをオープンソースで作ったって話でしかない
2021/09/19(日) 04:13:06.67ID:/b0JgwvO
あれ？
さっき思ったんだけど、
C#でしかできないことってあるよね？
ループで回して同じものを複数表示するとか

逆にXAMLでしかできないことってあったっけ？
無い気がする・・・

そんでMVVMもXAMLなしで出来るんでしょ？
そしたらXAML要らんじゃん・・・
2021/09/19(日) 04:34:10.41ID:rCAdh0cW
世の中のDSL全部C言語で書けよ的な話か？
2021/09/19(日) 06:24:30.46ID:9XIs1/Nq
>>949
画面をXAMLで書けるのがWPFの一番のメリットなんだが
2021/09/19(日) 10:50:54.04ID:zoNPTzv8
XAMLは筋の悪い技術だよ
ループ等を無理矢理バインディングで実装しなきゃいけないために複雑怪奇になってる
普通に文字列のテンプレートエンジンか、Reactみたいにコードでよかった
MVUでは結局コードになったね
2021/09/19(日) 12:01:27.73ID:YE49AlZO
XAML Styler必須だよな、なぜVisual Studioに標準搭載しないのか
2021/09/19(日) 13:28:03.13ID:bqLn7Zqv
ループって何言ってるか分からんがリストのことならコレクションバインディングするだけでしょ
違うならすまん
2021/09/19(日) 13:52:08.27ID:dh1bYHy4
ObservableCollectionとListViewをバインドするだけとちゃうの？
2021/09/19(日) 14:12:08.70ID:/b0JgwvO
>>951
画面をXAMLで書けることの何がメリットなの？
2021/09/19(日) 14:13:52.23ID:/b0JgwvO
>>952
禿同
Viewと分けるにしても、XAMLなんか使わずにコードでいいじゃんね
2021/09/19(日) 14:17:30.11ID:/b0JgwvO
>>950 >>954-955
スマソ、確認だけど、
XAMLで出来ること　＝　コードビハインドで出来ること
なん？
すべての機能が一対一で相互互換性あるの？
2021/09/19(日) 14:25:03.65ID:bqLn7Zqv
別にMVVMは強要されてる分けじゃない
使いたくなければ使わなくていいよ
2021/09/19(日) 14:26:01.77ID:bqLn7Zqv
MVVMじゃなくてxamlか
xaml無しでUI書くこともできるだろう、好きにすればいい
2021/09/19(日) 14:27:02.36ID:k8GedCcQ
メリットは宣言的なところ
jsさえあればDOMでdocumentを構築できるがやる奴なんかいないのと同じ
2021/09/19(日) 14:39:50.67ID:/b0JgwvO
>>960
全然答えになってない
XAMLでやってることすべてをコードビハインドで出来るのかって訊いてる
2021/09/19(日) 14:41:23.81ID:/b0JgwvO
>>961
コードでうまいこと宣言的にできないもんかね？
2021/09/19(日) 14:52:46.50ID:k8GedCcQ
>>963
目的と手段が逆転してるぞ
そのためにXAMLがあるんだろうが
965デフォルトの名無しさん
垢版 |
2021/09/19(日) 15:54:38.30ID:V+8kg11o
ReactのあれはReactだけのやり方だから好きじゃないな
966デフォルトの名無しさん
垢版 |
2021/09/19(日) 16:47:23.99ID:bqLn7Zqv
>>962
何でそんな失礼なん？
全部できるかどうかなんて証明でいないわ
MSに訊け
2021/09/19(日) 16:59:45.77ID:M6A2mfW9
>>956
・画面イメージそのままに階層構造で表現できるからXAMLを見ただけで画面イメージを把握できる。つまり画面デザイナが無くても困らないからVSCodeでも開発できる。
・diffで差分を確認しやすい。
・スニペット登録しておけばEmmetみたいに爆速で画面作成できる。
2021/09/19(日) 17:48:29.61ID:k97hf5Wx
XAML直接弄ることはあったけどデザイナーで結果見ながらだ
さすがプロだ。ちがうなあ…。
2021/09/19(日) 17:56:27.98ID:nIKY40XN
xamlでやってることはすべてコードビハインドできる
xamlで書けるものはそうした方が楽で速いってだけ
2021/09/19(日) 18:23:45.11ID:dWPcIkOu
>>954
例えば要素の特定のプロパティの値に応じてスタイルを変えたいとき、HTMLのテンプレートなら値に応じてifでCSSのクラスを切り替えるだけだよね
XAMLだとどうする？いちいちConverter作る？
2021/09/19(日) 18:38:16.20ID:z/QIU9f5
いちいちというかConverterはふつうに作ってるな。ある程度作ったらあとは使いまわせるし。
2021/09/19(日) 19:16:13.86ID:cbIcUE3M
お前がXAMLをどう思うかなんてのはどうでもいいことだ
アニオタが自分はこのアニメが好きでこのアニメが嫌いって言ってるのと変わらん
2021/09/19(日) 19:19:44.56ID:iNtXNZB3
>>970
DataTriggerを設定する
2021/09/19(日) 19:25:44.86ID:E5LuOPCO
>>969
何の速度の事をいってるのか判らんが、
動作速度はコードビハインドのが早いぞ
2021/09/19(日) 19:38:38.45ID:/b0JgwvO
>>964
サンクス
とりあえずコードだと宣言的にはできないということはわかった

>>967
サンクス
裏を返せば、コードだと画面がイメージできない・しにくい、と言ってるんだな、それは分かるかも
差分はイメージできる前提でメリットにはなり得る
スニペットってどの粒度で作ってあるんだろう？
それを標準で載せてくれよと思うわ
左のリストボックスで選択すると右のリストボックスに移る奴とかさ、結構使うだろ
2021/09/19(日) 19:40:34.61ID:lTTF8pbf
たぶん、動作速度の事いってないと思う
楽でっていってるから、開発速度とかじゃね
2021/09/19(日) 20:29:08.95ID:cF49PKlA
>>975
差分は〜のあたり何言ってるのか分からんが……
とりあえず最後の複数リストボックスのそれはたぶんコードビハインド書かないと無理
フォーカスの移動はバインディングで対応できなかったはずなので
2021/09/19(日) 20:29:10.32ID:cF49PKlA
>>975
差分は〜のあたり何言ってるのか分からんが……
とりあえず最後の複数リストボックスのそれはたぶんコードビハインド書かないと無理
フォーカスの移動はバインディングで対応できなかったはずなので
979デフォルトの名無しさん
垢版 |
2021/09/19(日) 22:15:48.20ID:V+8kg11o
動作速度にこだわるなら言語選び間違ってるよね
980デフォルトの名無しさん
垢版 |
2021/09/19(日) 23:23:28.51ID:bqLn7Zqv
>>970
色を変えるとか簡単な変化ならConverter
スタイルそのものを変えるならTemplateSelector
でもこれループ云々と関係ある？
2021/09/20(月) 00:49:08.80ID:Xe9wEhiD
>>980
Webのテンプレートエンジンを使ったことあるなら、そんな疑問が出てくる方が不思議なんだが
2021/09/20(月) 00:50:49.73ID:Urg8oj7a
>>977
そうかぁ、複数リストボックスはやっぱりコードビハインドが無いと無理そうなのか
フォーカスの移動がネックね
XAMLの限界って奴かな

こういうのがあるなら最初っから腹くくってコードビハインドで書いた方がいい気がしてきた
だって、XAMLで書いててどうやるんだろう？と悩んだ挙句、
結局コードビハインドしか解決法が無い、ということにもなりかねんからね

訂正：
差分はイメージできる前提でメリットにはなり得る
↓
XAMLを見て画面がイメージできる人なら、diffで差分を確認しやすいのはメリットになり得る
まぁ、階層が増えたとか移動したとかは分かりやすいだろうな
983デフォルトの名無しさん
垢版 |
2021/09/20(月) 00:55:56.18ID:rs8t3f0k
>>981
イヤな言い方だね
あんな汚らしい記法は嫌いだわ
ループよりコレクションにバインディングする方が読みやすい(個人の感想です)
2021/09/20(月) 01:02:15.33ID:1ct4tbKZ
xamlはbamlにコンパイルされ理論上はC#コードより速くなるよ
少なくともMSのWPFチームはそう主張して
生C#にコンパイルするcamlを廃止したわけだし
なお実際に測定すると...
2021/09/20(月) 01:17:24.74ID:GKDt5rSn
>>984
それは単純ケースだけじゃ？

MSの公式のパフォーマンス改善の手引きに
バインデイングを止めるようにとあったと思うが...
2021/09/20(月) 01:19:47.53ID:GKDt5rSn
とにかく俺のプロジェクトじゃ
WPFのパフォーマンスの悪さがやり玉に上げられて
それは大変だった...
987デフォルトの名無しさん
垢版 |
2021/09/20(月) 01:25:48.63ID:nLJN3AnD
双方向バインディングをやめてOneWay等も使えって書いてあった気がする
2021/09/20(月) 01:35:10.41ID:rs8t3f0k
WPFのBindingは全部レイトだから遅いのは宿命だわな
UWPからx:Bindを逆輸入すればいいのにと思っていたけどもうWinUIに逝っちゃったからなあ
2021/09/20(月) 01:44:05.05ID:GKDt5rSn
とにかく、
バインデイングとかテンプレートのセレクターの動作をみれば、
遅くなるのは当たり前なんだよなーー
2021/09/20(月) 01:45:44.54ID:GKDt5rSn
>>988
そのx:Bindは早いの？
2021/09/20(月) 03:00:03.34ID:/wXzoW3g
最近のパソコンなら遅いとは感じないけどな。
2021/09/20(月) 04:17:47.61ID:ikLxeDh9
WPFはバインディングよりも描画が重かったイメージだな
2021/09/20(月) 08:09:56.39ID:1ct4tbKZ
>>985
逆だね
単純なケースでは生xamlでも速いのでbamlの利点が生きてこない
VisualStudioで描画が重いと思ったことないので（軽いと思ったこともないけど）
WPFそのものにはポテンシャルは十分にあるんだろう
ただWPFみたいた終わったテクノロジーでそんなレベルの開発者集められるのはそれこそVSの開発チームくらいだろうね
994デフォルトの名無しさん
垢版 |
2021/09/20(月) 08:47:58.20ID:tGJnTRCJ
グラボとメモリが無いとヤバい
2021/09/20(月) 09:31:37.18ID:E4xUszIH
>>982
そういう複合コントロールはユーザーコントロールで作るからデータの出し入れは依存関係プロパティーを使いMVVMは使わず
処理もコードビハインドに思いっきり書く

で、出来たものをページなりウインドウに貼り付けて使用します
2021/09/20(月) 12:01:41.39ID:336bYktz
x:bind　速度の違いが全くわからないので使うのやめた
コンパイル時の型エラーがうざいし
bindingに戻った

速度に関してはそりゃ開発環境入れてるメインマシンで動かせばそりゃ問題ないけどさ、ローエンドのCPU積んでるマシンで動かしたらどうなんだろう
今時のローエンドでもbaytrailのatomからは随分速くなったろうから問題ないと思うけど??
2021/09/20(月) 12:11:27.54ID:GKDt5rSn
>>993
WPFは遅くて同時は叩かれましたよ
そのあと改良されて大部分巻き返しましたが
同時かなり高度な描画デバックキットがリリースらされましたので
それを駆使して対処してましたが
XAMLとバインデイングから
どのようなコードが生成されてるのか
予測が付かなくて
地獄見ましたよ
998デフォルトの名無しさん
垢版 |
2021/09/20(月) 12:12:02.12ID:336bYktz
つかさ、winuiもいいんだけださ
そもそもwindowsを開発とかのマウス入力前提の環境でしかつかってないんだよ
だから、winuiのfluent designがタッチ入力よりすぎで微妙すぎる
2021/09/20(月) 12:16:06.20ID:si8x6YH6
>>990
WPFにはx:Bind無いので直接比較はできんけど
UWPで同じようなもん作ったとき、Binding連発してるところで
WPFだと頻繁に見られるタメみたいなのがなかったね
1000デフォルトの名無しさん
垢版 |
2021/09/20(月) 12:21:05.16ID:336bYktz
まじで?
俺はUWPのbindingとx:bindしか比較してないけど
x:phaseとかも使ってみたけど

体感で全く違いがわからなかったわw

もちろん厳密な比較はしてないけど
10011001
垢版 |
Over 1000Thread
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 91日 19時間 16分 47秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況