WPF(.NET, WinUI) GUIプログラミング Part26
レス数が1000を超えています。これ以上書き込みはできません。
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/ SwingやFormsみたいにUIをコードで書かせる世界には戻りたくないなぁ。 まあ理解できないうちはXAMLとか糞に見えるもんな
俺もそうだったけどなれたら簡単になるから早く慣れたほうが良いよ MVVMが理解できないならMVVMやらなくてもいいのにプライドが高い老害が多いんだろうな
それで十数年廃れるって言い続けてる どっちかというと、
mvvmアーキのフレームワークで
ぶっちぎりに最悪なのがWPFってかんじ XAMLが特級のクソなだけだよ
冗長なBinding式やBehaviorやCommandなど、他のMVVMフレームワークが大量に生まれた中で誰が採用した
挙げてみろ
Javaで言うところの検査例外相当のクソ クソだと思うなら関わらなきゃいい
なぜ理解できないものに粘着するのか >>5
でもHTMLやXAMLよりむしろ便利なことも多いが。 HTMLから入った人は、それが母国語の用になっているので、WinFormsやSwing
方式よりXAMLの方が便利に見えるのだろう。
MVCやMVVMもそういう人のために有るといわれている。
ところが、人気が有るのは、WinForms方式であることもまた事実だ。
なぜなら、そのほうがコントロールし易く、プログラムのソースコードから
見てもわかり易いから。 まぁ、宣言的な記述が受け入れられなくて、なんでも逐次的・手続き的に処理されないと理解できない人は一定数いるね。 WinFormsが人気ある？
GUIはマークアップ言語でやるのが主流だと思うが >>10
WinUI3とPrismなどのMVVMライブラリ使えばだいたい解決できる話ですね >>10
Javaの検査例外の問題って、例外機構自体が内在している問題を検査例外で静的にチェックしたせいで
白日の下に晒されてしまったに過ぎないのよな。 >>10
それXAMLじゃなくて
XAMLの上に作ったBehaviorとかの糞ライブラリ群ね
XAMLはそんなに悪くない >>16
そんなの使ったって
いろいろ肥大化して更に糞まみれになるだけですよ
ダイアログ一つ表示するだけなのに
見通しの悪い糞まみれコード書かなきゃならないのは変わらないんですから 冗長君は何年もWPFに粘着してるWinForms信者です >>15
C#の中ではWinFormsが一番人気。 >>15
30年前からGUIは頬杖つきながらマウスでD&Dしてプロパティをポチポチするのが主流ですよ。 >>21
人気なんじゃなくて技術レベルが低くてWinFormsしか使えない底辺PGが多いだけ
>>22
生産性の低い地獄の作業だな WPFはとてつもなく生産性が低いですね。
最高の技術者が集まってるVSチームでさえWPF化に5年もかかったのですから。
自分でどれだけWPFが糞か言ってて草生えますwwww
> 人気なんじゃなくて技術レベルが低くてWinFormsしか使えない底辺PGが多いだけ
このスレの当初からこんなゴミは普及しないと言われ続け、その通りになった上に、
WPFだからこそ実装できるようなキラーアプリは何一つ存在しないだけでなく、
MSのPGからも嫌われ碌なサポートもなく放置され続けた。
あなただけがはいつか普及するはず、ビッグウェーブはすぐそこまできてる、
WPFを批判してるはスキルが低い底辺PGだと念仏のように唱えてる。 それWPFでも出来るんだができないと思ってるのかな >>24
WPFの生産性が悪いのではなく
WPFのBlendフレームワークの生産性が酷いだけ
デザイナーとの協業など見たこともなし >WPF化に5年も
それはつまりWPFの前が変更に弱い、生産性が低いってこと。
酷い作りのゴミコードを近代化するのが大変な作業なのは多くの開発者が実感してるだろう。
実際winFormsの生産性は非常に低い。
WPFで作っておけば半分の工数で済んだのにってことが何度もあった。
普及≒簡単・誰でも使える⇒代わりはいくらでもいる⇒単価下がる >実際winFormsの生産性は非常に低い。
使いこなせて無いだけ。 って言うかそんなにWPFの生産性が高いのであればとっくの昔に普及してるって。 >>28
言い訳が苦しすぎるww
vbおじいさん、winformおじいさんは勉強嫌いだろ。
生産性を高めようと思っていたらこんなものにしがみついていない。 WPFってSilverlightと同じく失敗productだろ >>29
Silverlight時代からなんで
そこそこ普及はしてると思うが、
実装方法は糞評価だね。
早い段階でflutterに食われるでしょ。 ビヘイビアとコマンドなんてそんなものあったなあって感じ
10年くらいWPF書いてるけどその2つを使ったのって最初の1年くらいｗ
無くても困らないｗ 俺もWinFormsからWPFに乗り換えた人間だが、明らかに開発は早くなったと感じる
まあ小っさいの作るならWinFormsの方が楽だろうけどね。MVVMの骨格を整備するの面倒だし。
GUIとロジックを分けて書ける有難みはそこそこ複雑なものを作って分かったよ まあWPFの良し悪しは置いておいても、マークアップ言語でのGUI構築には慣れておいた方が良いことは間違い無いと思う
なんせ今はWebアプリが強い時代だからね。それでも俺はデスクトップに残り続けるがw WPF以降だとサムネイル表示とか一瞬で作れるもんな
formならこうは行かないと思うけど
効率重視のformの人はformのリストビューみたいなので我慢できる人なの？ >>10
jsとかの他のMVVMは確かにそんなもんつかってねーな Livetやprism使ってありがたいと思ってたけどそもそもがそんなもん使わせるなよよｗ
これ以外何も思わない
そのPrismですらコロコロ内容が変わる 割と最近になってMVVM Toolkit for .NET(Microsoft.Toolkit.Mvvm)なんて出してきた べつにだれもマークアップ言語でのGUI構築にケチつけてないだろ >>38
それに関しては禿同。
外部に頼る前提のフレームワークって何なんだよとw
MSが吸収したりしないもんかね 今更何を言おうが、WPFはメンテナンスモードなので未来永劫改善されることはない WPF自体はそのままだけど
VS2019で実行時にバインドエラーを専用ウィンドウで表示できるようになったり
開発環境は地味に改良されてたりする >>41
Microsoftの名前空間が付いたMVVMライブラリが出たし、これでいいでしょ。 WPFが普及しなかったのはWPFの出来とは関係ない
WPFがこれからって時に、Webアプリやらスマホの台頭で
WindowsプログラマがWPFを学ぶ前にほとんどweb,android,iosに流れてしまった
単にwindowsアプリの需要がないだけ 新規Windowsアプリの重要が急激になくなってwindowsアプリ作る人いなくなったのにWPFが普及しないとどうこういう以前の問題 Prismは6から7のときのだけ破壊的変更が有ったけど、それ以外のバージョンアップは後方互換性も悪くなかったけどな
7の変更のおかげでUnityからDryIocにDIコンテナを変えても、モジュール入れ替えてusing変更だけでほぼ動く >>43
VS2019が出るまで、我々はあのコンソール画面と睨めっこしながらバグを潰していたのか…
ｵﾞｪﾞｯ 業務アプリとかならWinFormsでもいいかもしれんけど、今風なおしゃれな見た目のアプリ作るとなるとWPFというか、WinUIになっちゃうからな
諦めるしかない
つか、お前らどうせ新しくWinアプリ作ってねぇだろ??w
俺は4年前にUWPアプリ2つ作ってから、もうずっとスマホアプリだけだわ WPFは初期だけ盛り上がってしばらくしたら誰もいなくなった
外人のスタープログラマが持ち上げてたけどそいつらもすぐにいなくなった
コードを書く以外の時間も長いし
相対的なコード量も増える
WPFの学習効率の悪さ
開発環境の劣悪さ
MVVMによるコードの長大化
MVVMのデバッグの難しさ
など
winformsでは起こりえないいくつのマイナスポイントがあった >>50
俺はバックエンドがメインになって(Web含め)GUIアプリ自体仕事では全く作らなくなったな
画面作るのは好きだがツールに振り回されるのはアホらしいわ >>46
スマホやWebのせいじゃなく、アメリカの独占企業たちが、検索エンジンやOS
やハードウェアで儲けた金で無料でプログラムを配りだして、彼ら以外に
はWindowsアプリ作っても一線も設けることができなくなったこと、
Blenderや無料Office、GRUB、Apache、gccなどのGPLな無料アプリの台頭、
などがあるのではないか。
AndoridやiOSはMSの息が掛かってなかったから、売れるチャンスがあった。 アプリ作っても無料アプリに負けることが多くなったと思う。 WPFでMVVMを学んで、
今はandroidでもkotlin+MVVM
今はflutterでも開発してるがこれもMVVMで作ってる
MVVM最高!! >>51
学習高率の悪さねえ…
VB2〜6でイベントドリブン入門した層がWinFormに移行して
(奴らはこの時もオブジェクト指向だの.NET Frameworkだのでかなり苦労した)
その成功体験と開発方針を金科玉条のごとく大事にしていて
新しいパラダイムに対応できなかったことを指すならその通りだね
デスクトップアプリの開発者はWebアプリと違って新しい事にチャレンジするモチベーションが無いからな 笛吹けど踊らず。パラダイムシフトとならなかったのが今の状況 >>57
もちろんWPFは失敗だったし
失敗の原因はMSが色々と読み間違えたことにある
そのひとつがWinForm開発者のレベルの低さなのは間違いない B層に愚民愚民言い続けてたら選挙で大負けした人達みたいっすね >>59
この場合B層が何を指すのか知らんしどの選挙の事を言っているのか不明だが
MSが支持層のレベルを読み違えていたのは間違いない
WPFはWinFormの開発者がスムーズに以降できるスキームを用意できなかった >>57-60
この流れが正しいだろう
まるで「自分の教えてる生徒は落ちこぼれが多くてね・・・」と嘆いている教授みたいだ
確かに、生徒のレベルが低いという事実はあるかもしれない
だが、そのレベルに対するあんたの教授法はどうなんだ、と その頃、.net framework懐疑派もいてc++ Win32/MFCやらdelphi軍団
WinForms開発者はVBからの移行組多くてWinForms+VB.net??
だったら、WinForms開発者のレベルが低いのはしょうがない ここの人たちはわかってるんだな
WinForms止まりの人たちは成長しない人間だということを デスクトップの人はMAUIよりWinUI行くんじゃね？ ざむるか久しぶりだな
遊びでWindowsPhoneのガワ作って以来だわ
当時はMVVMがまだ浸透していなくて
何それ美味しいの状態だったって覚えてる >>70
なるほど。
WinFormsのGUIパーツは、Win32のControlを使っているから、OSの
内臓コンポーネントであるC/C++で記述されている。
一方、WPFのGUIパーツは C#で作られているはずで、その速度はC#の
良い実例。それが遅いということはC#が遅いということ。 リフレクションを多用するアーキテクチャがそもそも遅い
バインディンク構文使わないと早くなる このスレでバインディング遅いって書くとバインディング遅くないよマンがでてくるんだよなあ >>77
むかし遅い遅いって現場で揉めて
外部のコンサルとか乱入してきて大変でしたよ
しかもそのコンサルは非.NET系の...
笑 UWPでコンパイル時バインディングx:Bind使っても速度的な違いわからねぇし、
そもそも、AOTコンパイルだっけ?のUWPもつまりxaml??重いんだよな...
そりゃデスクトップPCで動かせば気にならんけど、当時はatomタブレットでバッテリーにも関わるから気になったわ
今のパワフルになった?SoCなら大丈夫そうだが?? >>73
flutterでFluent システムを実装してほしい
Material DesignをWindowsデスクトップで動かした時のデザインのダサさときたら.. >>79
何系よ？
MSC++,MFC,VB,JAVA,Delphi,BCC 最近は、そう遅くも感じない。
それなりにテクニックはいるけどね。 >>82
javaかな
最初はいろいろきつかったね Winデスクトップオンリーなら.NET6 + WinUI + WPF
モバイル主体のマルチプラットフォームならFlutter
ってところかな WINUIでどの程度パフォーマンス改善されるんだろ >>66
XAMLはいいぞ(´・ω・`)Petzoldさんも本書いて勧めている
でもストアアプリはハードルが高い（特に個人で出す場合 ストアアプリは誰にもメリットなかったよね…
Windows Phone の残した亡霊 ストアのハードルは別に高くない。
ハードルがいくつもあるだけ。 UWPは
・Win10以外非対応
・拡張子がexeじゃない
この辺りが原因で、特に古参中心に初めから嫌われていた印象 俺の周りだけかもしれないが 嫌うってより開発者としてではなく消費者としてどうなの??
iOSやandroidのサンドボックスによるセキュリティに慣れたら、普通に非UWPアプリをインストールするの嫌なんだけど
有名どころのアプリやUWPの制限じゃ無理なアプリなら仕方ないけど
例えば,SNS系のアプリとかフルアクセスできるデスクトップアプリとか嫌やな 20レスくらいさかのぼってみたけどUWPのセキュリティが嫌だって話をしてる奴はいなかった
93は誰に対する発言なんだ？
発作でも起きたか？ >>94
UWPのセキュリティが嫌だ、なんて>>93にも書いてないよ 開発者が何を嫌ってようとセキュリティはUWPの方が優れてるからそっちを選べよって指摘だ罠。
選ばねえよバカｗｗ まあ単体アプリを配布する分にはサンドボックスの有用性が生きるな
Windowsの生命線ともいえる業務アプリとはこの上なく相性が悪い
iPhoneで業務アプリシステムを構築しにくいのと一緒
結局Webアプリに逃げられてしまう >>93
消費者としても受け入れらえなかった。
exeひとつを自分の好きな場所に配置して実行できる自由さには勝てない。
そもそもセキュリティのメリットを理由にUWPを入れたがる消費者なんてほぼゼロに近い。
会社だとストア無効化、サイドロードの設定も有効化できないようにされてるところが多いから
UWPは使い物にならない。 ストアの画面とか開くことすらないからストアに何があるのかすら知らないわ
VS2022とかストアで扱えるようにすればいいのに UWPの問題は
・Win10専用
・DataGridが当初無かった
・EF Coreが当初SQLiteしか使えなかった
・インストーラがプライベートストア構築からとハードル高杉
辺りが問題だったね
今ならインストール以外はだいたい解決しているから使えないこともないが ストアでインストールしたのはWSLくらいっすかねえ Formsがオワコンかと思ったら.NET5で再び生き残ってるっぽい
リユニオンプロジェクトとかWinAPIも復活するし
分断させたいのかくっつけたいのか、終わらせたいのか復活させたいのかよく分からない体制だな APIは死んでないだろｗ
APIは使いやすく整備するだけじゃなかったっけ？ >>103
いやそれはWPFも同じw
タマがないんやw Macと違って膨大なエンタープライズ資産が世界のユーザーにあるから簡単に切り捨てられんよ。 iOSは他に方法が無いからみんな渋々ストアに登録してんのに、なんでWindows開発者が
ストアアプリに流れてくれると思ったんだろ。 >>103
Formsがオワコンなのは変わらんよ。
「VB6をまだサポートします」と言われても一般的な開発者は喜ばないのと同じ。
>そもそもマイクロソフトがWindows 8でデスクトップ環境とモダン環境を“分断”しなければ、
>REUNIONは必要なかったからだ。つまり、
>自分で2つに分けちゃっておきながら、今になって再結合って言い出しているわけで、
>例えて言えば、「花瓶割っちゃったので接着剤で付けました」的な話である。 マック過去のAPIや資産をバンバン切り捨てまくってるけど、客は怒らねーのかね >>110
?ヴェルタース オリジナルのCMのようにマカーの人たちは自分たちは特別な存在だと思ってるので
appleに何をされても怒らない https://iphone-mania.jp/news-348098/
iOSならともかくmacなんてシェア10パーセント弱だし
怨嗟の声が上がってても聞こえるほどじゃなかろうな
俺はAPIに無告知で破壊的変更を入れてくるから嫌い 簡単なテストアプリをサクッと作る時なんかは WinFormが捗る >>103
終わらせる必要はないと思うけど足手まといにはなってそうだな ストアテコ入れとは聞いてたけどまさかAmazonアプリと合体するとはなｗ >>113
いや、テストアプリでもWPFの方がはかどるよ >>115
MS社内でもUWPは期待されてない香りがプンプンするぜ >>115
ようは敗北宣言じゃね？
Windows8で糞使いにくくしたりストアアプリ/UWP注力でデスクトップ放置とか全部失敗だったな。 >>119
Windows11で切るんじゃなかったっけ？ 32bitどころか俺のPCが１１で切り捨てられそうなんだけど 定期的に湧くよな、マカー並の低能馬鹿、切り捨て厨。 >>120
切られたね
MSもApple並のド低脳になってしまった…
まあ32bit切り捨てよりTPM2.0未満切り捨ての方が影響でかいけど >>117
というかUWPは終了が確定している。
UI部分はWinUIに分離され、こっちが更新されていく。
残りカスのUWPはフェードアウト。 万が一Amazonアプリストアで軌道に乗っちゃったら、
そっちとの親和性開発の流れになるから、またリセットされるな 言語でもハードでもOSでもどれも互換重視で圧倒的シェア獲得してきたのに、
後から乗っかってきた頭の悪い新参者はすぐ切り捨てしろと言うから困る。
そういう歴史を知らない馬鹿がMSの経営陣に多くなったということ。MSも落ちぶれたものだ。ゲイツはやはり偉大だったのだ。 32bit CPU（32bit OS）サポート外とした、ってことでしょ。
今32bit OS使う理由って25年近く前の16bitプログラムの何か使ってるか、
15年ほどデバイス更新せず古いまま使ってるか。
いいかげん更新しろよって感じでしょ。
64bit OS内での32bitの実行ファイルはもちろんwin11でも動作するわけで、互換性としては十分だろ。 64bitと言ってもAMDが作ったx86互換の64bitもどきだからな
インテルのIA64が勝っていたらx86アプリは今頃残っていなかっただろう バカだから無理だわ
datagridとかのドキュメントも長ったらしいし、
reactivecollectionやらobservablecollectionやらがやたら長ったらしくて冗長だし、
画面に複数のデータをリアクティブにするだけで長ったらしいコードが溢れるし、
他の言語のwebなら数十行のコードもxamlまで含めて何百行となるし、
実行したらしたで重いし、保守なんてさせられんわ
linqくらいだわいいの
仕事ならしゃあないだろうけど >>133
「クラス名が長いから嫌だ」って…
まさかメモ帳で書いてるんじゃなかろうな 失敗プロジェクトの連続
MSには馬鹿しかいないのか 本気で馬鹿しかいないと思うよ
ブラウザさえまともに作れずに結局Chrome互換
検索エンジンもゴミ
WPFとUWP分離したりくっつけたり
dependency propertyなんかみてもひどいしな
褒めるところが全く無いのがすごい VSCodeとか新生Edgeとか他所のフレームワーク使う時のMSは伸び伸びしとりますなあ >>137
ブラウザはGoogleの露骨な妨害があったから泣く泣く断念した経緯がある。 どこも同じゃないの？
仕事で作らされてもろくなもん出来ないよ。 WPFを使うとプロジェクト全体の作業効率がアップするのか甚だ疑問だな。本当に良いものならもっと普及してる筈なのだが ここ最近WPFが善か悪かの議論しかしてないよな
何か他に話題は無いん？
…まぁ、無いかw WPF : 記事数1,123, フォロワー625
WinForms : 記事数78, フォロワー6
これが現実 >>117
MSは社内ですら方針統一できてないのがなあ
CairoやLonghornがコケた頃から何も変わってない >>145
Windows Forms で検索すると、1513
WinForms:258
Forms:4412
WPF : 1903 Xamarinで検索: 1726
タグのXamarin:968記事、906フォロアー。
如何にQiitaの読者層が信用ならないかが垣間見えるような。 Qiitaではなく、Quoraだと、
C++: Follow 1M
C#: Follow 382K
Java: Follow 1.3M
つまり、人気は、
Java > C++ >> C# Google Trendsだと、WPF,MFC,Flutter,Qtが互角くらいで、WinFormsとUWPは低迷。 Flutterは上昇中。MFC,WPFは徐々に下がってきている。
Xamarinは横ばいで低迷。
QtやFlutterはマルチプラットフォームなのに対し、MFCは古くからありWindows
専用な割には未だにかなり強い。 >>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調べ GitHubリポジトリ数
Flutter(21,854) > WPF(5,679) > Xamarin(3,434) > WinForms(3,373) > UWP(1,630) > MFC(355) githubは特殊性が有ると思う。
vue.jsは、185k star、29.4k fork で、スポンサー(ほぼ知らない企業ばかり)も大量に
付いているが、実際の使用例はとても少ないと聞いてるし。
逆に、qtなんかは、1.4k star, 680 fork だけど、ウェブではないところで
結構使われていることが分かってる。 >>145
Qiitaは、Webにちゃんとまとまって書いてないことを、自分で調べた人が
書く場所。だから、Webに情報が少ない事が書かれる傾向がある。
いくつかの調査で、WinFormsはWPFより使われていることが分かってる。 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 フレームワークにフレームワークが必要ってのは言語やプラットフォーム関係なく根っこが腐ってるからそうなるんだと思う グリッドコントロール使うアプリケーションの大半はゴミだけどな。
一覧画面と編集画面の2画面構成の方がほとんどのケースは使いやすい。
使いにくいしバグの元なんだからセル内で編集させるなよ。 >>162
伝票入力なんかは表イメージのまま入力できる方が喜ばれるんだよ
WPFでやるならグレープシティのやつとか使った方がいいけど 罫線付けたListViewでよくね？
ListBoxでもいいが。 >>142
昔は普及はまだかの話しかなかったが、
今はもう普及は絶望的なのに評価しても仕方ないよな データグリッド使わなくて済むようにカスタムリストアイテム作れるようにしたのがWPFとXAMLでしょ
(´・ω・`)おしゃれするんやで その普及普及って話がピンとこないんだな。うちの周りじゃ普通にみんなWPFなんだが。 UWPのDataGridは高速って話だが、WinUI３も期待できるんじゃね？ >>164
テスト用のアプリならStackPanelかWrapPanelに必要なコントロールをドラッグ&ドロップしていく大雑把なマウス操作だけで画面完成。
超簡単でそれでいて最低限のレイアウト変更に対応できてる。
“一度WPFを知ってしまうとWinFormsに戻りたくなくなる”ってよく言われるのは
それだけWPFの方が画面作りが楽ちんだから。 コードからWPF並みのレイアウトを構築できるだけのWinformsをくれ イヤじゃイヤじゃC++なんて使いとうない
まあC#のGUIフレームワークがうんこなのとネイティブとの相互運用がめんどくなって
毎度C++に戻っていくの繰り返しなんだけどね
要因がどっちかひとつならまだ我慢もできるんだが… よし、Delphiを導入しよう
Qtよりはマシだろ? DelphiのVCLをコピったのがwinformなんだが。 誤解を与えたようなので説明しよう。
世界的に実績のあるPGが開発→Winform→大人気
どこの馬の骨か分からんPGが開発→WPF→不人気
こういうことです。 昔のホームページビルダーとかExcelみたいに作れればええやろ >>185
そういえばDelphiはGUI部分が大人気で、その開発チームがMSに移って作った
のがWinFormsだったのか。
どうりでWPFより設計が美しく感じるはずだ。
後発でも駄目なものはダメなんだよ、ここの信者が何を言っても。 >>187
MFCよりもVCLのほうが断然使いやすかったもんな C#の言語仕様部分に主にかかわってる。
それは設計に関わっていないWinFormsの酷さを見れば分かるだろ？
WinFormsは生産性が低いし品質も低くなりがちなのは事実。信者が何を言っても。 @ahejlsbergには終わりかかってるような環境よりTypeScriptに注力してもらった方が世の中のためになる reunionの名前が変わってる
Windows App SDKだってさ
検索殺しだわ Webを見ても、UI設計はマークアップ言語でやるっていうのが正解
それはソフトウェア開発においても同じだった
WinFormsは完全に不正解 WinFormの肩を持つ気はさらさら無いけど、あの時代はそれがスタンダードだったでしょ
JavaのSwingだってそっちに行ってたし
Delphiを神のごとくあがめる人がいるけど、そういう先見の明はなかったよね マークアップ言語なら同じってのはウンコとショートケーキを同列に扱うがごときだよ
もちろんXAMLがウンコでね 他のマークアップ言語と比べてXAMLが優れてるなんて誰も言ってないんじゃないか？
WinFormsがウンコすぎてXAMLの方が数倍マシってだけで。 そもそも何が悲しくてマークアップ言語でUIを記述せなあかんのか
それに加えてあのクソバインディングの仕様
思想に拘泥しすぎて使いづらいことになっとる
C#の言語仕様の方向性とはまったく真逆 >>195
まあ、他のショートケーキ環境と比較してみればXAMLがいかにウンコかよくわかるかもね。それって例えばどれ？ データ記述言語としてのXMLもほとんどの用途はJSONに置き換わっとるし
Webだって生HTMLの記述を避けていかに楽するかにみんな試行錯誤しとる結果がフレームワークの乱立なわけで
もうマークアップがダメなのよ、XAMLというアイデアが生まれた瞬間からダメ Formsの臭いものに蓋をしたような裏のコードを見て
コレジャナイって気付かないもんかねえ うだうだ言ってもWPFが普及しなかったという事は事実 普及するかどうかと優れたアーキテクチャかどうかは
全く別の話なのも事実 ユーザー目線では遅い重い
開発者目線では面倒くさい難しい
MS目線ではやめたい捨てたい 古代UNIX時代のマークアップ技術をなぜ未だに引っ張り出さなあかんねん。 ウダウダと文句を垂れ流しておられる皆様方の理想のUI記述言語はどのようなものでございましょうか？ >>200
jsonでUI記述するC#Framewoek作れ 誤解されそうなので補足しとくが
漏れはjsonもxmlもxamlもうんこだと思ってる それはちょっと語弊があるだろ
どんなに優れたマークアップ言語の上にでも汚物のようなスキーマは構築できるってのが正しい
クソDSLを設計して喜んでていいのってそれこそ小学生までだよねーｗｗ >>205
ユーザー目線:
WinForms:遅い・重い・応答なし・見づらい・使いづらい
WPF:速い・使いやすい
開発者目線:
WinForms:低機能・手の施しようがない・バグ地獄
WPF:必要なものが一通り揃っていて現代の開発に耐えられる
WPF程度を難しいなんて言っているレベルは転職をお勧めする。 趣味でやってる人だろ
さすがにプロでそんな馬鹿はいないと信じたい >>212
技術者としてそういう捏造するようになったり終わり。人間のクズ。 >>204
優れていなかったから普及しなかったのでは？単純に だよね
必死にWPFを持ち上げるよりもどこがダメなのか議論するほうが建設的
WPFマンセー厨の人達は黙っておいたほうがいい ×優れている
○ある面では優れている
糖質だって探せばいいところの一つくらいはある >>216
MVVMでやろうとした時の教育コストがネックかな。
俺一人でやるなら問題ないけど、プロジェクトの都度人集めてやるような会社だときつい。 winFormsって重いの？
まあSQLseverの大量のデータを扱う場合はそうかもしれないけど C++=Delphi > VB6 >>> WinForms >>Java Swing
速度だけならVB6の方が早かったからな >>215
逆。vbから続くwinデスクトップ界隈では優れている人の方が少ないから
低レベルな人でも使える低機能なものの方が普及しやすい。
>>218
それもWPFが普及しなかった要因。
必ずMVVMで作らなきゃいけないかのような圧力に
怯えて技術力の低い多数の人達が逃げ出してしまった。
まずはMVVM禁止で何個かプロジェクトやってメンバーの大半がWPFに十分なれてから次のステップに移ったほうがいい。 >プロジェクトの都度人集めてやるような会社
日本終わってるωωω >>212
WPFの方が遅いと言うのを良く聞くが。 セレロン、MEM:2GBがノーマルお仕事環境だからな >>218
選択肢が多すぎるのも欠点だよね
VBぐらい選択肢がないほうが同じ事の再教育しなくて済む 雑談スレじゃないのにここまで雑談で埋まってるスレは他にあるまい WPFコントロール作ってるライブラリメーカーのガチプロは
はなから内部はMVVMとか使っとらんぞ
それが真実
一般向けに皮だけIF定義して対応させてる次第
製品で遅いのとか使えんからな
すまんの >>231
そもそもMVVMってコントロールの内部で使うもんじゃないと思うが。 >>223
Windows Formsのグラフィックシステムでは、最終的な描画のタイミングをアプリケーション自身が握っているため、
描画途中でディスプレイ更新が行われると意図していない崩れた描画が表示されてしまうことがあります。
一方、WPFのグラフィックシステムでは、最終的な描画のタイミングはWPFの描画エンジンが握っているため、
意図していない描画がディスプレイに表示されることはありません。
そのため、大量のコントロールを高速でスクロールしても滑らかに表示できます。
>>231
プロジェクトの種類に応じて開発手法を選ぶのは当たり前。
MVVMを使うのは端的に言えば開発スピードを上げるため。性能を上げるためじゃない。
(真のガチプロはMVVM使いつつ性能も担保するかもね) gdiとか完全排除してdirect2dに置き換えたら良いのに 2021年にもなってWinFormsにしがみついてる馬鹿がいるってマ？ MVVMで開発スピードを上げるってネタだろｗ
リスト出てくるとイラっとする MVVMはともかく、高DPIとか要素のスケーリング対応はWinFormsでやりたくないな
ただまぁ、敷居が高すぎるとは思う
書籍はロクに見当たらないし、日本語でそこそこまとまったフレンドリーな解説が載ってるサイトほとんどないのは痛い
関連ワードで検索してもかずきか妖精しか出てこないでしょ
（この2つも途中からRxが入り込んできたりMVVM前提になってくるから脱落者多いと思う）
とほほとかdobonとかufcppレベルに噛み砕いた説明が欲しいのよ初心者は Formsおじさんはスケーリングなんて概念知らないよ スケールはマニフェストファイルにドットバイドットで起動するように
設定すれば問題ない >>238
テストや仕様追加・変更などトータルで見てもかなり差が出てくるぞ >>242
それぼやけるやつじゃないの？
それともレイアウト崩れる方？ >>234
コントローラー部品はMVVMのVの部分だからね >>234
グラフ、ガントチャート、スケジューラーとか
一個コンポーネントだけでも
業務系アプリより小便チビるぐらいのガチの大規模アプリだぞ。
まあ開発者もCOMとかActiveX時代を経験しとる猛者だらけだが まったく関係ない。規模が大きかろうがコントロールをMVVMで設計する必要なんてあるわけがない。 本家 Microsoft でさえ使っていないフレームワークだしな。Visual StudioのGUI部分くらいか？ MVVMで設計する必要が無いとは思わんが、
WPFはレイトバインディングオンリーだから性能を考えたら無いな xamlのUI自体が起動時JITだししゃーない
ユーザー編集や内部動作がオブジェクト〜UI間で速攻反映されるのがMVVM的とすると今時のやつほとんどそれにならんか？
やっぱいるか？ >>244
ぼやけないし崩れないよ
ただしデメリットは4Kなどの高解像度ディスプレイを使っていると
ソフトを実行した時に文字やウィンドウが非常に小さく描画されると思う
場合によってはぼやけた方が使いやすいまであるかもしれない >>248
グラフィックスデバッガのPIXとか現役で更新されてる小物じゃちょくちょく使ってる COMをマスターできたならその後の新技術もキャッチアップできるだろう。
当時COMについていけなかったような人が今WPFについてこれていないという感じじゃね。 >>254
まあ難しいかもね
でもDCOMとかおもろいで
他人のPCにオブジェクトがnewできるwww操作もwww >>251
スケーリングを無視して拡大せずに表示って
スケーリングから逃げてるだけで何の解決にもなってない 今時WinFormsやWPFで作られるようなアプリなんて基本的に決まった環境で決まった操作ができればいいだけなんだから画面の美しさなんて誰も問題にしない
文字が小さすぎるなら解像度下げたらいいだけ >>240
海外サイトでは有用なサイトとかあるの？ >>258
逃げてるだけやん。
画面の美しさなんかどうでもいいが
見やすさ、操作しやすさは品質チェックされる。
フォントサイズぐらいは変えられるようにしといたほうがいい。
たいした手間じゃないんだから。 >>260
その「しといたほうがいい」程度のためにWPFやるの？さすがに費用対効果が悪すぎないか
そらみんなWebへ流れるわな >>262
そりゃwebが要件に合うならそっちの方がいいけど
デスクトップでやらなきゃいけない場合、
winFormsは生産性もアプリの品質も論外だから現実的な選択肢の候補としてWPFは有力。
費用対効果はwinFormsなんかを選ぶよりはWPFの方がずっと上。 WPFよりwinformsがいいなんて言ってる奴いないのに何無駄なこと言い続けてるの？
なんでもかんでもxamlで書かせようとしたWPFはバカっていってるだけなのに WPFで作るだけで品質も生産性も向上、よかったよかったw * WinFormsの方が優れてるよ派
* XAMLは糞だよ派
自由に追加してってくれ 彼はずっと頑張ってるんだけど
一向に何がどう上なのか提示しないのが笑える 馬鹿はwinformsはスケーリングがっていうけど事実上使用環境は2k固定
4k環境なんて企業ではほぼ出てこない
何かあればすけーりんぐがああああって言いたいだけだろ
そんなもの弱点でもなんでもない
4K環境でアプリを使いますかと聞いたら何それとかいいえってすぐに答えが出る
winformsの弱点はそれとは別にあるだろ 他人がすばらしいと思おうが糞と思うがどうでもいいだろ
そんな他人の意見気になるのかよ
このネタしつこすぎ 4Kモニター使う客は見たことないけど、13インチFHDノートとかでスケーリング150パーで使う客はざらにいる。 WinFormsはバグが多いみたいな話は聞いたが踏んだことないな >>271
最近問題になってるのはFHDのノートPC＋老眼
拡大しないと見えないって言われるけどWinFormだとだいぶ面倒 老眼ならボケててもわかんねえしDPI Unawareでご提供じゃあ！ >>275
winformは仕組み的にバグを作り込みやすい。
SOLID原則に則った作りがしづらいから。 DataGridのヘッダの結合かベータ行カラムの分割をしたいんだけどxamlだけじゃできないんだねこれ >>277
オーナードローに手を出すぐらいならWPF使った方が簡単だし楽だぞ 今時windowsアプリ作るならflutterでしょ
その次はcompose for desktop
シリコンバレーに住んでるけど周りだいたうそうだぞ MayaみたいなGUI作りたいんだがFlutterで問題ない？ >>281
具体的も何もイベントハンドラしこしこ書いてたらそうなっちゃうでしょ >>287
イベントドリブンだからハンドラは書くだろ >>284
私のシリコンバレーではWinForms一強だがね WPFを推してる人に質問。
https://teratail.com/questions/45592
でベストアンサーの人がDataContextを
XAML
<OrigUI:OrigButton x:name="MyButton" DataContext="{Binding MyButton, Mode=TwoWay}" />
と
コードビハインド
MyButton.DataContext = myClass.MyButton;
の両方の例を見せているが、
両方で書けることのメリットは何？
自分はどっちか（この例だとXAML）だけあれば充分だと思ってる。 ListViewとかの仮想化だけはデータテンプレート使わないと駄目そうだけどね >>288
それがformsの限界。
>>290
別にWPF推しじゃないけど、
XAMLはビルドの過程でC#コードに変換されるから
両方で書けるのは自然なことでは？
UIに関することはなるべくXAMLに書いた方がいいと思うけどね。 >>290
後から動的に生成したい場合とか、コードで書けないと出来ないじゃん XAMLに記述すると横にびろーんと長くなって見づらい SRPやOCPを順守するには一般にレイヤの多い方が有利だから、むしろイベントハンドラの方がやりやすいまである
MVVMはVからMへイベントを伝播したりMの状態変化をVに反映したり依存関係を管理したりと、VMの役割が多くなりがちなんだよね
そのへんReduxなど後発の亜種ではより役割が整理されている >>296
xaml stylerというvisual studio拡張を入れなさい。
xaml保存時にいい感じに改行入れてくれるに適当な所で折り返してくれるパッシブスキルだ。 >>290
同じように見えるが依存関係プロパティ(xaml)とC#のプロパティは別々に定義しないといかんのだ（参照しているDataContext自体は同じ)
xamlUIクラスはDependencyObjectを継承しているのだ >>293
サンクス
なるほど、確かに両方で書けること自体は自然か
> UIに関することはなるべくXAMLに書いた方がいいと思うけどね。
そうだね
自分としては「両方で書けるけれども、こっちでしか書いちゃいけない」ってしてくれるといいんだけどな
複数のサンプルプログラムのいいとこどりをしようとした時に、それぞれが別々の書き方をしていると非常に面倒臭い、DataContextに限らず
以前、「全部コードビハインドで書く」っていうサンプルコードがあって、走らせるとちゃんと動作した
この調子だと、結局、毎回両方の書き方を覚えていかんなるんじゃない、特にいいとこどりするなら？
∴学習カーブが急だという説は正しい、というのも単純計算で覚えることが二倍だから
間違ってると思ったら気軽に指摘してくれ >>295
> 後から動的に生成したい場合とか、コードで書けないと出来ないじゃん
サンクス
入力が変わる度にDataContextを動的に切り替えるってことね
でも、XAMLじゃできなかったっけ？
（DataContextじゃやったことないけど、XAMLでListなんかの要素の変化した分も表示できるから出来るのかなーと類推してるだけだけど） >>300
サンプル見るときに何を参考にするか決め打ちするしかないね
俺はそうしていた
WPF始めたばっかりの頃はWinFormから移行を進めたくてイベントドリブン中心(これは結局失敗)
その後学習を進めてMVVM中心に切り替えた
MSのサンプルがイベントドリブンだらけなのが良くないよな 機能が豊富な分、全部覚えようとしたらそりゃ大変だ。
でも
ひのきの棒
剣・槍・斧・弓の欲張りセット
どっちかくれるって言うなら普通は後者を選ぶだろ?
まず手に馴染むものを使って
少しずつ他のものも触れてみるといい。
最初から全部に手を出す必要はないし、
最終的にも全部使えるようになっている必要はない。 >>304
先ずは初期装備のひのきの棒でスタートするだろw >>307
もらった装備は後から追加できないんだぞ wpf簡単チュートリアルテンプレートないの
DBとクエリだけ指定すればDataGridに出力してくれるとか
ボタンが配置してあってイベントに印刷とかExcel出力がすでにインプットされてるとか 言語よりAccessのがいいんじゃね？
レポートは最強レベルの性能だし 今時ローカルのDBなんて個人の小遣い帳にすら使い物になりません >>315
なにいってんの
サーバーに接続して利用すんの
一時期業務系の開発でよく見られた方式よ >>302
欲しいサンプルがさ、なかなか見つかんないんだよね
決め打ちできるほど選べないという・・・
その唯一見つかったサンプルたちが別々の書き方してると苦労する
自分はMVVMから学んで、あとでイベントドリブンを知った >>304
> ひのきの棒
> 剣・槍・斧・弓の欲張りセット
> どっちかくれるって言うなら普通は後者を選ぶだろ?
ディスるつもりはまったくなくけど、
なんか喩えがよろしくない気がする
どっちかくれるって、それは学習コストも含めて言ってる？
使いこなせること前提なのかな？
コンビニに行くのにヘリコプターは要らないでしょ？
WPFは使ってみて手に馴染まなかった >>319
徒歩しか選べないのと、ヘリコプターも徒歩も選べるのは全然違うよ。
WinForms的作り方でWPFを使えばいい。
バインディングもほとんど使わない。
それなら学習コストはほとんどかからない。
柔軟なレイアウトシステムとか
スタイルによるコントロールのプロパティ一括指定とか
学習コストが低くて便利なところだけつまみ食いすればいい。 結局邪悪だったのは
WPFといったらMVVMみたいな記事を書いてたMicrosoftのブログとかMVP、なんだよね
山師みたいなもので >>318
あとはもう書籍に頼るしか無いな
WPF関連の参考書は古いのばっかりだけど
WPF自体があんまり進化してないから2010年くらいのでも結構参考になる 取っ付きにくい→普及しない→資料が無い→
負のスパイラルだね >>318
そりゃ酷い
普通こんな変態的なコード書かないよ
同じMSでもBlazorのMVVMの方がまともだ。
プロも考えてるなら
js覚えてReactとかやってみたら？
仕事多いよ。 >>304
実際には、WinFormsが少し前の高級車で、WPFは、バックカメラを
搭載した軽自動車みたいな感じだろう。
速度が違うし、どっちがいいとも言えないような状態。 >>325
もとい。
バックから見たいな画期的なものはWPFには付いてない。
せいぜい、短波ラジオが追加された軽自動車みたいな印象。 WPFってWindowsメッセージドリブンなアプリを作れないよね >>325
実際にはWinFormsがリヤカーでWPFがステーションワゴン WinFormsは、レンブラントやミケランジェロの作品の様に万人から一定の評価を
受けるようなものだが、WPFはピカソの絵みたいに人を選ぶ。
支持者には画期的で先鋭的なものらしいが。 いつまでWinForms vs WPFやってんの
ネタが尽きて妙な例えになってるし、いい加減にしろ 10年以上続けてる習慣にいい加減にしろだって！？
お前こそいい加減に止めることはできないって現実を理解しろよ >>320
やってみようかなという気持ちと
そっちの道も蛇の道では、または
それならWinFormsでいいんではないかという気持ちがある
WPFの扱いをユーザー側でどうこうするより、
MS側でバインディングを簡素化してくれた方が嬉しいかな 自分が知ってるOSSでWPF使ってるのはEDCBぐらい
MVVMは使ってないようだけど >>322
ここ3年ぐらいで出版されたのを一冊買ってある
アマゾンで高評価だった奴
でも、欲しかった情報とちょっとズレてるんだよね・・・
もちろん有用な情報もあったけど >>324
> js覚えてReactとかやってみたら？
あら、今、正にそこ
そうだね、その方向性で行こう 今ならWindows Runtime系の本でC#バージョン新しめのやつ探したほうが良い、あるのかは知らん(´・ω・`)
Xamlまでやるなら素直にPetzoldくんの6版 マジか。WPF今から頑張ろうと思って色々調べているけど
正当進化のUWP?がズッコケてるのみるとこの技術に未来はないのかなとも思う
ただWPFのFormsにはない先端で綺麗なコントロールがあるからほっとけない 今WPFを使う必要に迫られているのではなく将来を考えて勉強しようとしているなら、
さすがにそれはWebかスマホをやったほうがいいぞ 今ネイティブアプリを作る理由は鯖を用意しなくて良いぐらい… ネイティブアプリで自前ブラウザーを構成し、
本体アプリはReactで作成する >>339
趣味なら良いんじゃない？
慣れれば使いやすいから
フリーランスとかで案件が欲しいんだと微妙 >>339
WPFのxamlは多機能すぎるしとりあえず最低限でもいいから適当にやればいい
ただ、MVVMは他でも使ったりするからこっちを重点的にやればいい 俺が勉強した時は最初はxamlに深入りしないで他でもいきるMVVMの方に力入れてモチベーションを維持した MVVM技術は袋小路で他に流用できないし思想も実装によって違う
MVVM自体はこれから捨てられる技術
開発＆テストしづらいのでFaceBookはMVVM否定してReactでFluxを使ってる MVVMが向いてるのは個人などの小規模アプリ
中〜大規模だと相互の関係が分かりづらくバグの温床になるので敬遠される andorid開発でもDataBinding+MVVMだし
flutterでもMVVMで作ってるし
最新のjetpack composeでもMVVM使う予定だけど
ただ、flutterなどデータバインディングない環境は自前でVとVMを接合しないといけないけど
すげぇ便利 >MVVM技術は袋小路で他に流用できないし思想も実装によって違う
そもそもその手のアーキティクチャで他に流用できるものなんてどんだけあるかねぇ。
結局フレームワークごとそれぞれの考え方を習得しなきゃsならんように思うが。 MVVMは基本、単に責務ごとにMとVとVMに分けて、オブザーバーパターンで状態変化通知して、xamlみたく組み込みのデータバインディングあればなおさらいいてだけじゃん
フレームワークによらず、アプリ全体をMVVMで設計できて
フレームワークによって違うのは主にVとVMと接合部分だけで
むしろ新しく覚えるのがそれだけなんだが? MVVMは副作用がわかりにくいので更新順序などで結果が違うなどバグの温床になる
状態を考慮せず実装できるような気がするが実は隠れた状態があり
その状態自体が見えづらく制御しづらい むしろMVVMのV差し替えで別フレームワークに切り替えた実例見たことないけど何かある？ 誰もさすがにコード共有までは言ってない
MVVMというアーキテクチャでUIフレームワーク変わっても同じように設計、実装できるといってるだけ
別にUIフレームワーク変えて一方向のデータフローが好きなら新しくfluxも覚えればいい MSもMAUIではMVU採用したみたいだけど
WinUIはどうすんのかな >>353
そういうこともあるけどナレッジが蓄積されるとバグのパターンと修正ポイントがすぐわかるようになる
大昔イベントドリブンの黎明期にも同じような事が言われて
古参が「ほらやっぱり逐次制御で書かないと分かんなくなる」と騒いだけど
その時も同じように解決されていった たぶんだけどmauiのMVUっても二つに分けてかんがえないと
まず、flutterなど今どきっぽく、UIをxmalではなくコードで宣言的に書けるってことだろ
で、おそらくjetpack composeみたくコードで書いた部分の状態を参照する部分は
オブザーバブルな状態の変更通知の購読、キャンセルはコンパイラサポートでコード自動生成？
flutterはここ自前でやらなきゃいけないので面倒
で、UIでイベントが発生したら、あとはそのイベントをどこに流すかだけでしょ
イベント発生時にViewModelのメソッド呼べばMVVMになるし
他の何かにしてデータの流れを一方向にすればMVUになるし
ただそれだけの話 .NET MAUIでUIがxaml使わずにコードで宣言的にUIかけるように
なっても、UIのイベントをどこに流すかでMVVMにもほかのMVホゲホゲの何かにもなるし
ただそれだけ
俺が>>350のjetpack composeでやろうとしてることと同じ
想像だけどね React Nativeはオワコン、PWAも手を出す価値なし？ VMとMをバインディングするからいろいろイビツになったり複雑になったりするんだと常々思う いや違わない
コードビハインドを使うなというアホまで出る始末 変更即時反映のUIって最近流行りじゃん、スマホでもWebでも最近ではWindowsの設定画面でも
あれUXとしては後退だと思うんだよね
でもMVVMから見ると素直に作れるんだよね
プログラマやってる俺ですら
あれ？ミスタッチしたんじゃね？
どこ変えたかわかんなくなったからキャンセルしたいんだけど？
って度々思うもん >>364
ごめん
読み間違えてた
コードビハインドの件は同意
あれはBlendでポトペタするため >>365
optimisticなuiって奴か？
俺あれ嫌いや ああ違う
いちいちSaveとか押さんでも保存される奴か
あれは確かにデータフローに引っ張られてる面あると思う DataGridのColumnHeaderのボーダーがCellのそれと比べてほんの少し右にズレてるのは仕様？ >>369
仕様 回避コード書いてるサイトあったな >>365
変更即時反映が悪いわけじゃない。
直近で変えた項目の色を変える、設定変更のアンドゥをできるようにする等
いくらでも改善できる。 設定を他人に伝えるとき即時のほうがありがたい
適用ボタンを押す指示はないほうがいい >>371
仕様か
昔の立体Win32スタイルの名残でズレてるってことなんだろうな >>373
大体、そういう説明が理解出来ない人は低IQか初心者。
慣れた人には適用ボタンが有った方が便利で安心。
Windowsは少し高IQな人に向いている。
モバイルは万人向けなので、普通IQや低IQの人が使える様になっているが、
むしろ機能としては不便になっている。 既存のモデルにコンソールのガワを被せるためにMVVMを採用
バインディングのためにモデルをバインディング仕様に改造
もうこれがイビツ極まりない
UIフレームワークの都合に合わせてモデルを変更するとか気持ち悪すぎる 個人的にはせっかくバインドする仕様にしたんだから、デフォルトをリアクティブに寄せれば良かったのにと思う
webのJSフロントエンドフレームワークとかみたいに感覚的じゃないんだよね >>376
典型的な低IQ無能プログラマ。
そんな甘ったれた考えだといつまでたっても底辺から上がってこれないぞ。 >>379
何か作り方おかしくないか？
UIそのものやUIフレームワークを除外した残りがモデルなんだから。 >>381
ReactiveUI+乱立してるMVVMフレームワークから1つ決めて公式実装にしてほしいわ
というかぶっちゃけAvaloniaの方向性で良いので、買収して開発リソースぶちこんでくれ… >>383
それがUIの都合で汚染されるのがイヤだって言う話 >>374
変更即時反映がUXとして後退と主張するから違うと指摘したまで。
例えばVSCodeの設定UIはデフォルトから変えた部分は印が付く。 >>376みたいな人間がUXを語るべきじゃないな
感性も腐ってそう 開発者のエゴイズム丸出しでいかにもWPF好きらしくていいじゃん WPFって見た目がカラフルでもUIデザインの基本的なプロトコルはクラシックなWinアプリのままなんで、
画面遷移とか作り込んで完全にWebやスマホ風にしてしまうのでもない限りは即時反映はかえって混乱を招くと思う >>388
バインディングの都合を満たすのはVMの仕事で、Mの独立を保つ為に犠牲になる係でしょ？ しかし、Modelの一部をINotifyPropertyChangedやReactivePropertyに変えるなど
規模にもよるが小一時間の仕事だろうに
使いたくない理由を無理やり探しているんだろうね INotifyPropertyChangedなんてWinFormでも使うだろうに
何のためのモデルクラスだったんだろう >>394
手間の問題じゃなくて
なんでUIフレームワークの都合でモデルをいじらなきゃならんのかって話 WPF使う場合はやはりモデルから対応しなければならない
それが嫌なので躊躇してしまう
モデルが依存関係を除去したところでINotifyPropertyChanged実装しないといけない >>394
なんで
INotifyPropertyChanged
ReactivePropert
みたいのがmodelにあんの？(;´д｀) MVVMで作ればINotifyPropertyChanged実装しなきゃいけないのはUIとバインドするViewModelだけだぞ
ModelをObservableにしたければ、独自のObservableインターフェース使えたければ使えばいいじゃん
Modelは無理にINotifyPropertyChanged使う必要はない つか、要件としてModelをObservableにするならUIフレームワーク関係なく
何かしらのObservableインターフェースが必要になってくるんだが
他のフレームワーク、言語使っても同じなんだが頭大丈夫?? そのへんフィールドをプロパティにするだけで全部やってくれてたらもっとユーザー増えただろうな INotifyPropertyChangedの実装がWPF特有の問題だと思ってるあたりが頭おかし
他のUIフレームワークでもモデルの変更に応じてUI変えるなら、Observeする仕組みが必要でINotifyPropertyChangedに相当する機能をどのみち実装しなきゃいけないのに
>>396,397
君は他のUIフレームワーク使ったときにどうやって実装するわけ?? >>402
明示的なコード書かなくても
フレームワーク側でバインド解決できるのが
普通のMVVM >>402
WPFみたいなバインディングはしません >>405
WPFみたいなバインディングしなくてもモデルをObservableにするならどの道何らかのインターフェースが必要になるって話をしてるんですけど理解してますでしょうか?? >>398
通知のためだけのインターフェースがボコボコ増えてくのが嫌だからさ
全てRxのIObservableならよかったな
つかWPFもバインディングエンジンの部分をプラガブルにしろよな
なんでINotifyPropertyChangedみたいなクソにしがみついてるのか理解しかねるね てか今後新しい通知インターフェースを宣言した奴は死刑でいいよ
殺す 趣味でやってるだけだからよくわからんけど同じプロパティー２回書かせるのやめてくれ
めんどくさい >>407
メリットは外だしなんで
カスタマイズして
オレオレ仕様に出来る以外ない .net mauiのMVUってINotifyPropertyChangedの仕組み乗っかるの??
ブログの例ではState<T>とかあるけど
State<T>ならjetpack composeと同じやん >>406
だからバインディングはVVMまででいいって言ってんじゃん これでいいじゃん。using追加してAnnotation付けるだけだよ
https://www.reactiveui.net/docs/handbook/view-models/boilerplate-code
[Reactive]
public string Name { get; set; } まあ他の言語のFWはばかでも書けるけど、
ことWPF含めMS主導のは一部の細かい主張に答えるためか、
やることが回りくどいんだよな
FW使ってるのに書くことが多いと言うか >>412
じゃあ、モデルでは好きなObservableインターフェース使えばいいじゃん
独自でもRxでもご自由に >>404
case: knockout.js
<span data-bind="text: viewModel.value1"></span> >>404
case: React
<span>viewModel.value1</span> >>419
>>417と同じのりで挙げてるならこれも違う >>420
おお、すまん
訂正
>>404
case: React
<span>{viewModel.value1}</span> >>404
case: Vue.js
<span>{{viewModel.value1}}</span> h5za3xa1は世間知らずのWPF至上主義者なんだ
許してやれとは言わないが冷たい目で見ればいいよ >>404
case: Blazor
<span>@viewModel.value1</span> ここからまたプロパティで書くべきかどうかみたいな話になるのだろうか
recordの仕様と実装が中途半端だから解決法にならない >>404
実はWPFでもstaticだけはObservableの実装無しでいけたりします。
なのでModelの直バインドも可能です。
更新はコントロールを強制再描画すれば良い。
case: WPF(static only)
<TextBox Text={x:static viewModel.value1}/> なんでView-ViewModelのバインディングの事例を並べてるの?
Modelの話じゃなかったっけ person.Nameみたいなのにバインディングされていて
Name変更時に通知する仕組みはモデルの責任じゃないけどそれが必要になる
他のフレームワークのように別の仕組みが通知するのが普通
WPFは普通じゃないし劣っている だから、「WPFも同じことできてWPFも当てはまる」から
>>417,>>419全部間違っているっていってんのに
何いってのお前？アホ？？
ちなみにWPFの場合は
<TextBox Text={Binding Path=viewModel.value1}/> >>428
その通り
>>402をうけての>>403だから、
「変更時に通知をする仕組みを一切実装する必要なくフレームワーク側で全部かってにやってくれる
」ようなこと>>403が言い出すからそういうフレームワークがあるならあげろっていってんのに
なんでどれも変更時に通知する仕組みを実装する必要あるフレームワークあげてんだよ
変更通知しないなら、WPFだって>>429で書いたようにINPC実装する必要ないしそんなフレームワーク
を挙げろっていってない person.Name見たいのはいつ変更したかなどはわかりやすいが
普通のクラスなどはいつどこで更新したのかが非常に追いにくい
目視でバグが確認できたとしてそれがどこで変更されてるのかがわかりにくい
バグがつぶしにくい とりあえず、
読解力ないバカが多すぎってのだけはわかった やったじゃん
俺以外みんなバカ宣言して精神的勝利だ まぁ「俺の言いたいことを理解してくれない奴」は多いよな、いつでも。 >>変更時に通知する仕組み
MVVMだから変更を監視する巧妙な仕組みがあって
（フレームワークによって思想が違う）
その仕様にのっとって適時勝手にバインドが動作する
のでコードは増えない MをPOCOで作りたがる人いるよね。通知を実装するのも嫌がる。 個人的には
(client: view, view-model)~network~(service: model)
としてる
入力バリデーションもmodelのみだ
へんかな？ >>440
それは世界の常識
WPFのMがおかしい >>442
いや、WPFのMもPOCOで作るのが常識。 ふーん
POCOでModel変更感知するのって面倒じゃない？ Modelで変更通知なんかしない。
VMとMの区分けすらできないならMVVMで作らなきゃいいのに。 >>447
Modelの変更はどうやってViewModelやViewに反映されるの? PODのようなものと混同してんのかな。
POxOから外部に何らかの通知をするのは別に普通だろ。依存の方向とか強くなりすぎるなとか一般的な注意をするだけ。 >>449
Reduxならプロパティ変更イベントは必要ないよ >>451
例じゃなくて仕組みを知りたい
VM側からポーリングでもしてるの M自身が能動的に処理を行うことは無い。
Mに対してはVMから変更かける。通信やDB操作は外部プログラム（dll等）の役目だし、
ちょっと規模が大きいアプリなら外部通信などの処理は別プロジェクト（dll）にまとめられてるはずだろ？
外部プログラムが何らかの処理してMを変更し、外部プログラムの処理結果はVMでイベントハンドリングして
UIを更新する VとVMで1つのプロジェクト（UI担当）
Mと通信処理などをまとめて1つのプロジェクト（System.Windowsを参照しなければ汎用ライブラリ）として
.net core等でも使用可能）
もちろんVMからSQL文を発行することもある
日曜大工レベルのアプリならVMの中で通信処理などビジネスロジックを全て含める >>452
更新されたMが自発的にイベントを発火するか、VからMを更新するアクションが発生する毎に更新後のMの値を取りに行くかの違い。
flux/reduxのような一方向データフローでモデル更新がシリアライズされているから実用になること。 V以外からMが更新される場合は、Mを更新した処理とVMが強く結合されるってことね Mの発火をVMが受け取りまた発火、Vが描画とか手間かかるしチームで案件やってると教育コストもかかる。
技術に疎いマネージャーだとクリックイベントに全部書けやとか言ってくるんだよね。 >>456
flux/reduxについて言えばアクション自体への結合は不要。
基本的にMは全部単一のストアにまとめられていて、どこかが更新されるアクションが発生したら全員でMの更新を見に行くような感じ。 >>456
モデルにぶら下がってるVMはフレームワークが把握しているから、フレームワークにMの更新メッセージを投げるだけだよ なおMのどのプロパティが更新されるかの特定も不要で、VMはあくまでMの現在の状態に対する関数として更新後のV全体を出力するだけでいい
あとはフレームワークがよしなに差分を取って変更を反映してくれる Mへの更新は全部フレームワーク経由で実施するってことか
フレームワーク君頑張るなｗ >>461
更新されたMをフレームワークに通知するだけだ
フレームワークの責務はメッセージのルーティングに過ぎなくて、Mがフレームワークの配下にいなきゃいけない訳じゃないよ ちなみに>>453,454はただのMVVMだよね?? V以外でのMの更新自体はM寄りの処理だよね
Mの各プロパティから個別に更新通知が行くか、代表して更新通知が行くかの違いであって
Modelからの変更通知が無いってのはちょっと違うな >>464
ルーティングの責務をM自体ではなくその外で持つことで、M自体を汚さなくて済むようになった
メタ情報を外出しするという点ではEFのPOCOなんかも似たような仕組みだな >>462
フレームワークはMが更新されたことをどうやって知るの？ >>466
ああ、わかったただのMVVMの変種か
今までだって、MVVMで作ってた時はModelでimmutableなのをあったけど、
イメージとしてModelを全部immutableにして、ViewModelのほうに全部押し込めって話か
極端な話Modelを全部immutableにして、後のつじつまあわせは全部ViewModel(Store)で全部やれってことww
負荷が全部ViewModel(Store)にいくってことじゃね?? 今までだって例えばMVVMでTwitterアプリを作るとき
まず、汎用的なTwitterAPIを叩いてPOCOを返すだけのライブラリを作って(A)
(A)を内部で使ったModelを作る
必要ならここでINPCの変更通知を実装(B)
で、後はViewModelをつくるだけど、
(B)をすっとばして、ViewModelで(A)を使ってここですべてやる
こんな感じ?? だからそもそも今までだってどこのModelか知らんが(A)の部分は汚染されてないけどな..
二つ似たようなの作ってるが.. もちろん、Modelをmutableにしてもいいけど、ViewModel(Store)内でModelを直接更新するからModelの変更通知機能は全く必要なくて、更新後ViewModel(Store)がViewに状態が変わりましたよって通知できればいい
やっと理解できました
ありがとう mvcやらmvvmやらに全てあてはめようとして考えて、
訳わかんない考えに染ってるのばっかだな >>470
これが何も知らない新人君でもやる普通の実装なんだがな >>470
そうすると複数のビューで一つのモデルを参照しているようなときは
ひとつのVMだか何だかが複数のビューと対話するん？ オブザーバーでも
イベントでも
好きなパターンで実装すればよろし >>470
それは間違いだよｗ
VMにM更新のロジックを書くなよとｗ
VMごとにロジック書いて不整合があってバグ発生するだけ VMからMにはメッセージのみ送る
馬鹿はVMからMをいじる WPFで本気でMVVMやりたいならMに通知もみんな書くんだよ
これがモデル汚染
最近はビジネスロジック層を作ってお茶を濁してるけどそれも結局通知はどこなのか普通に迷うところ >>479
>WPFで本気でMVVMやりたいならMに通知もみんな書くんだよ
MVVMの話でいいならそれはrigaya?が勝手に言ってるだけだぞ
別に正解の定義なんてないだろうしどっちが正解とは言
言わんが
Modelのメソッドは結果を返さず、メソッドの呼び出しの結果、自身の状態(プロパティ)を変更するだけってやつだろ フレームワークの方法論は
その開発者が一方的に押し付けてる理屈なのに
気づけない馬鹿 違うよ
知性の問題だ
それが理解できない馬鹿がバグを量産する 馬鹿が自分が馬鹿でないと思って偉そうに何年もクソコードを書いてMVVM最高と言ってるだけだ >>484
うがやじゃなくてお前ともう一人が馬鹿なんだ
やっと理解できましたじゃねーよ modelとviewModelの責務分けは
馬鹿には出来んよなーー 外人でrigayaと同じ主張してる人見たことない
Modelで通知をするのが普通とか言ってるのはお前が勝手に思ってるだけ
>>481でMVVMを本当に作った人が特定できるならまずそれを特定してくれ。で、Modelで変更通知を実装するのが普通ってどこに書いてあるか教えてくれ もちろん、ViewModelはビューの状態を保持し、Modelに対してはModelのメソッドを呼んで
ビューに関するロジックを書くだけだぞ
Modelに変更通知機能あるかないかは全く関係ない話
勝手にModelに変更通知があるのが普通と思ってのはお前 フレームワークつかうと
やっぱ宗教じみた変なのが誕生するなーー
まずはプリミティブなライブラリのみ使用して
デザインパターンとか理解してみる事をおすすめする >>478
「メッセージのみ送る」と「いじる」の違いはこいつの頭の中にしか無いんだろうな。 MVVMでViewModelの責務は>>488なだけ
Modelが変更通知を実装するしないかは関係ない
MVVM黎明期、rigaなんとだけが日本で声上げたからあいつの馬鹿信者が増えたんだろう
しかも日本だけ笑い だから>>362で最初からバインディングはVVMまででいいって言ってるじゃん
何をそんな喧嘩腰で議論する必要があるのか “model” と “view、viewModel” の開発者は
分けた方がいいかもな
modelだけで業務が回せるようになってればいいだろ
実際modelはpythonで実装するの増えて
担当者も異なる事が多いわ >>492
バインディングの話じゃないって分かってない？ >>494
え？変更通知なんだから要はバインディングの話でしょ？ 例えば、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 もちろん、MVVMの厳格な定義なんて知らないし、極論すれば言葉の問題になるから
どっちが正解なんて言うつもりはないが、
rigaなんとか的に
「ModelはINPCを実装して、Modelのメソッドは戻り値は返さないで、
メソッドの呼び出しの結果自身の状態を変更し、INPC経由でViewModelに通知する」
で
おまえらこれだけがMVVMだと思ってるだけじゃんw 悪いけど売られた喧嘩で言わしてもらうが
>>485,486,490
はバカ三兄弟だわww ID:uwFcR1va
この人のサーバーサイドには
何が実装されてるのだろうか... >>500
なりほど、お前さん>>478の言う「メッセージのみ送る」と「いじる」の違いが理解できるならちょっと説明してみてくれないか。 >>502
あ、ごめんひょっとして間違ってたら謝るわ
>>490って俺に対するあてつけ？じゃなかった？？
ただの>>478へのレスなら謝るわ。すみませんでした。
つか、あとrigaじゃなくてググるとugaだったw 読みづらいからよ
続けるなら名前欄にスタンスを書いてくれないか >>495
そこまで話を広げるとMに通知機能があろうが無かろうが全部バインディングだろうよ
今問題になってんのはVはVMに依存してる前提で
VMとMの問題だと思うんだが違うんかな >>506
WPFはめんどくさいっていうのが他の後発フレームワークとの比較なら分かるけど
WinFormと比較するんだったら比べものにならないくらい簡単だぞ 楽⇔面倒
簡単⇔難しい
単純⇔複雑
区別できない奴多すぎでは >>501
予想
ID:uwFcR1va 氏の構成
(client)
View
ViewModel
Model
Database Client Library
↑↓
(server)
Database Server 一人ホームラン級の馬鹿がずっとレスしてるだけだな
MVVMでMから変更通知出すのは当たり前
VMでモデル変更して通知と言うけどモデル内で変更が生じた場合VMが変更通知出してるのかｗ？
VMは画面ごとに作るけどMに対応した処理はどこに書かれるんだ
まさか画面ごとか？ MVVMが便利なのはMを操作すると通知が飛んで画面更新通知を自分でしなくて良いところ
それをVMで自分でやると言うのだから無意味なMVVMに感じる
VMで手作業の通知忘れるとバグが出る
Mに通知機能があれば通知忘れバグはない >>512
これは自分がホームラン級のバカと気づいていないバカ オブザーブバブルコレクション使ってモデル読み込むだけだよね
Mは単なるデータでいい VMVもUserControl以外全部Xamlにしてバッチグーなローコードだ 昨日の話を一人で長文書いて続きやろうとしてる必死さが笑える 一人でINPCって言ってる馬鹿が勝手にコテンパンにされてるだけだろう >>514
オウム返しするだけじゃなくてちゃんと反論してくれ
あおり合いじゃなくて議論が見たい 凡俗法則って言葉知らんかったわ
この外資系社員が凡俗法則を説明してんだが、例に出してるコイツ自身の資料がダメだわ
https://www.daijob.com/crossculture/takashi/20120207.html UIへの変更通知と
Modelの購読をごっちゃにしてるのがそもそもの間違い。
前者はUIフレームワークで良く扱っているやつだが、
後者は一般的にはPush等で知られる通知処理だ。
で通知処理（Modelの購読が必要になるケース）なんてほぼほぼ無くて、
業務系システムだと株価のリアルタイム表示、チャット位なもんだ。
実装方法としてポピュラーなのはWebPush、WebSocket 、SignalRとか。
それ以外でどうしても必要になっても、通知処理みたいな面倒な機能は設けずに
通常はクライアント側でタイマー回してポーリングして凌ぐのが定石だし手堅いし
どこでもその方式でやってる。 数量、単価、金額のプロパティがあるとしてどういう実装する？
VMで掛算してMはPOCOだよな >>531
基本的な.NETのオブジェクトだけで構成されているもの。
そこは気にしなくていい。
View→UI
ViewModel→UIフレームワークの都合上必要な部分
Model→その他全部
これだけ覚えておけば十分。 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実装から自動的に生成したりする事が多い。 Model層へのアクセスは RESTful API で行う事が最近は多いとおもうから、
APIの仕様書を OpenAPI形式の APIドキュメントでもらって、
そこから自動生成するのが定石だよ。
まあ、イケてる現場なら普通やってたり検討したりするはず。
正直いって DTO とか POCO とか自動生成の最右翼コードだ。 >>529
素でこういう人が多いんだろうなあと思う でもPOCOをラッピングしてPropertyChanged付けるとVMになるんですよね？ >>529
こいつ一人が馬鹿なんだ
いい加減にあきらめろよ >>528 >>534
一番の馬鹿はこいつ
お前のやってる業務の現場の話じゃないWPFの話をしてるのにどんどん話をすり替えていく
土方業務話をしたいならどこかよそでやれよ
まだ恥の上塗りを繰り返すの？
ここには誰も味方はいない WPFのモデル層へのアクセスをRESTful API でやってるやつを教えて欲しい
馬鹿の世界では当たり前らしいけどｗ >>542
もう恥の上塗りはやめなよ
モデルのソースがWebAPIって話でしょ なんでWPFのモデル層の話をしていたのに
誰かの業務のWebAPIの話をしてドヤってんの？
知能レベル低すぎ >>544
なんで分からんのやろ？
ものすごいバカの壁を感じる >>545
そちらが馬鹿の壁を超えられないサルだからだろ
WPFのモデル層は他のフレームワークのようなPOCO（単なる入れ物）としてコーディングするだけでは通知が抜けており
MVVMの本来のメリットを享受できないという話だったのに
なぜかwebAPI使ったりロジックをVMに書いたりする話にすり替わっている
WPFではVMでロジック書いて通知が一般的だと言われても納得する人はいないんじゃないの？
旗色が悪くなると相手が理解できないと勘違いして業務の話を出してドヤってるけど誰でもわかるわ 負けられない病にかかってるのかもしれないけど
そちらの主張どおりWPFではM層はみなiNotifyPropertyChangedの実装なしで書くのが一般的で
VMで通知が当然ですと書かれて納得すると言うのはおかしな話
本筋をねじ曲げて勝利したいのかがわからない
勝利病なの？ >>528
MVVMアプリ的にはクライアント・サーバーのやり取りなんざまとめてMの範疇だろうに
そこの実装がプッシュだろうがポーリングだろうがどうでもいい話 POCOがあったらそこになんちゃらRepositoryやらなんちゃらServiceがあるわけじゃん
Modelはそれらを内包した概念なわけで
もうその辺から認識がズレてるから擦り合わせようがないんだと思う
話がどんどん後退していってる なんでPOCOとDTOをゴッチャにしてんだ
WPFでMVVMやるならDTOはMの更に先にあるもんだぞ
そっかだからやたらポコポコ言ってんのか
申し訳ないがWebに例えないと話ができない人はNGに入れとくわ MVVMのMには当然DTOが内包されるよね
更にその先って何？w >>534
>実際は POCO は DTO と同義で用いられる事が多いかな。
そう思ってる人と正しく使ってる人とで話が噛み合ってない感じだよな。 あのさ>>528は例えば特に>>495対するレスで、単にUIとは関係ない一般的な
通知論を言っただけで、>>541の言いたい事を否定してるように見えないんだけど
むしろ君の味方だと思うんだが、>>541は全員敵に見えてるの?? ああ、ごめん俺が間違ってたww
>通知処理（Modelの購読が必要になるケース）なんてほぼほぼ無くて
ここでちゃんと否定してたねw >>555
エコシステムの話をしてるんじゃなくてWPFアプリの話をしてるので
MVVMのMをWPFアプリでどう実装するかが論点なのよ 一応はWPFなりMVVMなりを前提として話してるもんだと思ったらまさかのUIは関係ない宣言
U I は 関 係 な か っ た ！
そら誰とも話通じんわw バカ同士仲良くしてくれ いや、やっぱ>>556取り消すわ
やっぱ、>>528は単に>>495に対するレスにしか見えないな
>>557
論点はそこにあると思うけど>>528は通知の一般論話しただけかもしれん 俺は土曜日までは会話に主な論点わかってたけど
昼間に君のレス見て、UIと通知を結びつける人がいて気になってたから、その人向けにUI関係ない通知の一般論言ってるんだろうと納得してたら
夜みて、通知の一般論言ってるだけなら全く関係ない人が怒り出してから草
って感じ だってWPFと関係ない話になってんだもん
むしろ論点ずらししてるっしょ VMに相当する部分にビジネスロジックをガッツリ書くのはアプリ設計としてありだが、それはMVVMじゃないな
MVVMはModelにビジネスロジックを書くのが本来の定義だ >>547は最悪の性格だと思うww
>>528に勘違いでぶきちれてる >>565
そんな設計はもうViewModelなんて言葉を使うべきじゃねえわ
MVCでもMVVMでもないどころか関心の分離すら無視した全く別の何かじゃん どんなプログラミングパラダイムを採用しようと
UIの変更にモデルは影響されないのが原則だと思ってる
例えばWPFで作ったものをASP.netでWebインターフェイスに変更することになったとしてもモデルには一切触れなくて済むのが本来あるべき姿
しかしモデルにUIのための通知機能を入れた途端にそれは破綻する
別にモデル通知機能があったって動くから良いだろと言う話ではない
そこがモデルに通知機能を実装する違和感の根源 変更を通知するサービス
たとえばみんなが知ってる gmail（いわゆるPushメール）とかは
クライアントを WPF でも Flutter でも React でも作れると思いますが、
ではこの機能は何に相当するのでしょうか？ 通知機能のあるMをVMのObservableCollectionでVに公開すると
このMはVMになりますか？
MVVMでは反則でしょうか？ >>571
何とは?
MVVMの役割のことを言っているのあれば、どれでもない
Mの中で使用される機能と言うだけ Amazon SNS（Simple Notification Service）は、
そのためだけにサーバーを用意しなくても、
アプリケーションからの通知を可能にするサービスです
ユーザーが何かを行ったタイミングで通知する
「イベントドリブン」なメッセージングを手軽に実現します >>570
>しかしモデルにUIのための通知機能を入れた途端にそれは破綻する
そこに依存性逆転パターンを使うのが常套手段。 >>572
Collectionの要素に変更があるのを監視する必要がなければそれでOK
別に反則じゃないと思う 今日は勝ちたい病のVMにビジネスロジック実装する君は来てないの？ こないと>>547の馬鹿みたく関係ない人攻撃しだすからなww 自分がそれで見られるからって
他人が同じことして見られると思ってるあたりが馬鹿だよね ロジックはコマンドに書いてるけどコマンドってVMの仲間じゃないの？ >>585
原理主義通すならその通りなので止めた方が良い
大規模プロジェクトで規約作る段階とかならあなたの言う通り
そうでないなら工数とのバーター そういやコレクションでもしっかりVM挟めって人がWPF出来て直ぐの頃は言う人いたよな なんか人によってVMの定義が違うのかねぇ？
WPFだとDataContextにセットするのがVMだと認識しているが。 >>589
ListViewなどでも、内部的にListViewItemのDataContextにコレクションのアイテムがセットされるから何も変わらないよ
それにVM挟めというやつが昔はわりといた ビジネスが破綻する大半の原因は、 ”ビジネスを始める人の大半が、真の意味での
「起業家」ではなく、 起業したい、という熱に浮かれた「職人」として働いているに過ぎない。”
という事実にあります。
「職人」によって運営されているビジネスは、ビジネスが働くのではなく、彼ら自身が毎日働くこと
によって、成り立っています。
彼らは毎日、自分がやり方を知っている仕事を一生懸命にこなしていますが、「起業家」としての
視点が無いために、成長に限界が生まれます。
そして、生計を立てるために、彼ら自身がずっと働き続けないとならないのです。
誰もが必ず陥る罠
私が見ている限り、起業熱にうなされる人たちは、必ずと言ってもよいほど誤った
「仮定」を置いてしまうようだ。実は、のちに彼らが苦難の道を歩むことになるのは、
この、「仮定」が致命的に間違っているからなのである
致命的な仮定とは・・・「事業の中心となる専門的な能力があれば、事業を経営する能力は
十分に備わっている」ということである
私がこの仮定を致命的だと書いたのは、この仮定が間違っているからにほかならない
事業の中で専門的な仕事をこなすことと、その能力を生かして事業を経営することは
全く別の問題である。高い専門能力を持つ人にとって、独立は他人の為に働くという苦痛から
解放されるということを意味していた。それにもかかわらず、前提となる「仮定」が致命的とも
いえるほど間違えているために、彼らは自由になるどころか、自分が始めた事業に苦しめ
られるようになってしまうのである
マイケルEガーバー「はじめの一歩を踏み出そう」P28~29 >>590
それは問題なくて、逆にDataContextと関係ないものまでVMと言っている人がいるような気がしたんで。 >>593
それでも0.5と違ってreunion0.8は、そこそこ安定しているよ なんでtextblockってこんな中途半端に作ってあるのかな
作ってるときに上下のスペース気にならなかったのか ｒｉｃｈtextboxの上下のスペースなら気になった
馬鹿が作ったんだろうなとニヤニヤした >>601
1.0が出てから触ってみるつもりだから分からん。
UWPが見向きもされなかった欠点が解消されてるなら移行するし、
駄目ならWPFとWinUIのミックスになるかもしれない。 基本的にGUIはUWPが基本でほんの一部異なる程度
売りはファイルアクセスなどの制限のない.netのクラスや
C言語のライブラリが普通に使えること
残念なのは.net nativeは対応していないからUWPほど高速にはならないところだな これが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 俺はカラー絵文字が普通に使えさえすればもうWPFで十分なんだけど
それってUWPのコントロールが使えるようになるとかいうnugetパッケージ入れりゃ簡単にできるもんなの？ 備品管理のために配置図作成プログラムを作るために下の二つを使いたい
マップ描画用
https://noitalog.tokyo/wpf-excel-shape/
UndoRedo機能用
https://qiita.com/nossey/items/c59910558d5501f03ad0
Undo機能でマップ描画のキャンセルをしたいんだけど
Record(() => { /＊do＊/ }, () => { /＊undo＊/ });のところに何を入れればいいのか分からない
何を入れれば実現するのか教えてください
もしくはもっといいライブラリがあれば教えてください >>607
そういうツール作ったことあるけど、Undo/Redoは状態そのものを記録する方式の方が楽だよ
操作ごとに描画したモデルをスタックに積む感じでとっておいて
Undoでポインタを遡る、Redoされたらポインタを進める つまり別のライブラリを使った方がいいってことですね
探してみます >>609
608が言ってるのはstateをスタックに積むだけなので、Stack<T>を使えばライブラリは不要。
考えるべきはstateを表現する方法かと。 undo/redoをcommandパターンで実現するときのネックは、逆方向への操作を綺麗に実装出来るかどうか
たとえば、0から1増やす操作は可逆性があるので簡単だが、0を1に変更する操作は可逆性がないので元の値を必要な分だけcommandに設定しておかないといけない
必要な分が広範囲になると、丸ごと状態を記録するのと変わらなくなってしまい、ただ実装が複雑になる
stateパターンの場合は、実装が簡単というメリットの代わりに、状態をうまく独立させないとリソースを大量に消費するというデメリットがある
commandパターンで、直接状態を変更するcommandを作るのではなく、状態の差分を算出して適用できるように実装出来れば、両者の問題を解決できる doに新しい状態でundoに古い状態を入れたらいいんでしょ
規模も不明なんで丸ごと記録でいいんじゃない Undo可能クラスも実装出来んの？
(例)
var val1 = new Undoable<int>(0);
val1.Set(1);
val1.Undo();
val1.Commit();
if (val1.Value == 0) {
} UndoableクラスのValueプロパティーをInotifyPropertyChangedで実装しとけ！ >>613
これ足し算するときは
val1.Set(val2.Value+val3.Value)
って書かせるのか？ >>613
その実装をどうしようって話だと思うんだけど 編集するタイプごとのenum作って復旧／削除用のバッファ・位置情報を持つクラスを作るのだ
通常の編集処理に渡せるようにできるかがあんきも >>607ですがC#ほとんど素人です
stack<t> にcanvasを入れてみてpushやpopしても上手く変更されず >>623
参照型が理解できてないっぽい。
残念だが初心者スレでは無いのでここまで。 >>623
確かどっかにC#初心者スレがあったはずだから c#に慣れてきてWPFに挑戦しようかなと公式チュートリアルのHello Goodbyeを試した。
1.まずはxamlの名前を変えましょうでエラー。
1時間ほどなら悩みまくってチュートリアルページ遥か下にデバッグの項目で意図的なバグだとわかった時はキレそうになった。
引き続き学習しようと思ってるんだけど、参考になるサイトある？ xamlはhtmlと同じようにタグをエディターで入力するしかないって気づいたところから使えるようになっていったな
Formsみたくコントロールをマウスで並べようとして挫折しかけた タグ書いて完璧なUIを作るのが楽しい
グラフィカルなエディターってチラ見するだけのものだな 公式チュートリアルにHello Goodbye(world?) なんてあったっけ >>631
チュートリアル: C# で単純なアプリケーションを作成する 2021/02/10
ttps://docs.microsoft.com/ja-jp/visualstudio/get-started/csharp/tutorial-wpf?view=vs-2019
Hello Worldレベルでつまづいたのは初めてでショック。
wpf tutorialで検索したら良さげなサイト見つけられたからもういいんだけどね。 >>632
StartupUriを変更してないから実行時エラーになる件？
チュートリアルを手順通りやってれば悩むようなことなくね？ >>629
Formsと同じような作り方してると結局Formsと同じくサイズ変更やレイアウト変更に脆い画面になっちまうんだよな。
GUIから貼り付けると余計なプロパティも追加されてごちゃつくし。
XAML用のコードスニペット用意して爆速コーディングがお勧め。 winui触ってるけど非同期メソッド多すぎてイライラする
慣れたら気にならなくなるのかな むしろ非同期メソッドが用意されていない方がイライラするだろ。 >>638
WinUIまだ触れてなくて分からないんだが、もうDispatcher.Invokeしなくて良くなるの？ きっちりMVVMしてりゃDispatcher.Invokeなんて出番ないんだが。 最近のアプリはクリックしたあとすぐに反応しないアプリ多すぎ。というかWindows10。
馬鹿に非同期の実装は無理ということ。 OneNote UWP版、死亡。
着実に脱UWPしていってるな、よしよし。 コード簡略のためにawait 使いまくってるサンプルが世に広まってるのが良くないのかね(´・ω・`) MahAppsでGUI作っていたけど今更Metro(Modern) UIというのもアレなんで
最近出たらしいWinUI 3.0で組もうとしているけど、ウィンドウサイズを変えることができない。
なんか、いい方法ない？
あと、WPFで使っているからかもしれないが、Windows.Storage.FilePickerの動作がなんか不安定だ。
PickSingleFileAsyncは動くのにPickMultipleFilesAsyncだとコケる。 >>646
User32でハンドル拾ってメソッドを呼び出すと色々出来ます
いろいろ調べたけど、現状だとこうするしかない模様 非同期じゃないと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); >>648
microsoft shell controls and automation ってのをcom参照すればOK
それでWindowがアクティブな状態で
m_windowhandle = PInvoke.User32.GetActiveWindow();
な具合でOK うーん、今更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 >>652
帰ったら試してみます
どうもありがとう GUIプログラムは、Electronを使うのが一番簡単だと思うね
ちなみにおじさん(*'▽')はJavascriptはあんまり得意じゃないな C言語は、競技プログラミングでしか使ったことないな 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で組めるとかできればいいんだけどね〜。 そのへんはEdgeエンジンのWebViewに期待したいところだなぁ。 Electron互換でwebview2使ったhta並のファイルサイズのexeかできれば覇権取れるよな WebViewってホストがC#ってだけで、内側からOSや.NETフレームワークの機能が
アクセスしやすくなっているわけじゃないよな。 >>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で待ち受けるっぽい。 >>661
分かりにくいなあ
初心者向けのチュートリアルなのかと思ったら突然妙に細かい概念の説明が入ったりWPF独自用語がロクな説明もなしに多用されてたり、
何がしたいのかよくわからん
MS技術は概念から入りがちでわかりにくいとよく言われるけど、社員もこんな感じならそらそうなるわな そのサイトは読んでないけどkazukiのWPF連載は実際的だったけどなあ そりゃまだHello WorldにWPFの概要説明が載ってるだけだし
ただの難癖早漏 >>664
リンク先はkuzuki氏のサイトなのだが 誤送信すみません
>>662
本書の対象者を見るに入門とは言ってもそこそこC#に触れてる人向けっぽいよ 中身を見て見たけどあらかじめ知識のある人向けの入門書だから初心者には難しい
データバインディングとか普通に意味が分かる人じゃないと
入門と言うより再入門に近いかな WPF再入門でC#についていくら知っててもなんの意味もない WPFについて知りたいのにC#入門からやられてもウザいだけだわな 秘伝のタレなんか知らんがWPFのMVVMパターンを使ったレシピがネットに転がってなくて困る。
プログラマーならフワッとした概念と、あの3つの四角形が矢印で繋がってるのだけ見て「なるほど、そういう事ね」と作り始められるの？ 旧版にあたるWPF4.5入門（https://www.slideshare.net/okazuki0130/wpf45-38048141）と
見比べてみれば、まだまださわりの部分だわな
つか、現状に合わない部分を削除してるだけに近いかね
まだ加筆が必要な部分じゃないからだろうけど 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 は我々に教えてくれます >>678
これは参考にしたけど途中でモデルがない？ってなったやつだわ。
>>679
こっちは見た事ないからちょっと勉強させてもらいます。 こういうの見て正義に成ったと勘違いして
糞コード量産タイプになんだろな
reactとかだと1/10以下のコード量だぞおい >>680
>例えば計算機レベルのサンプル
>
>厳密に3つの責務(View, ViewModel, Model)に分けた所でPDSの冗長さが目立つだけです。
>計算機程度の小規模であるならば、ViewModelをModelと統合するのは大抵の場合あるべき姿です。
https://slidesplayer.net/slide/11235164/ >>681
趣味で盆栽的にやってるもんだから特に発信する気もないし誰にも迷惑かけんから勘弁してよ。
>>682
数日前にこのスライド読んで、今はMVCやMVPから調べ直してるところだわ。 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 は我々に教えてくれます >>675
自分もそれは思ってたな
でも結局MVVMの基礎部分はこのインターフェースを使ってこの通りに実装するみたいな感じの決まり事だった >>675
自分もそれは思ってたな
でも結局MVVMの基礎部分はこのインターフェースを使ってこの通りに実装するみたいな感じの決まり事だった >>687
たった1週間程度だけど調べてサンプル写経して、WPFで用意されたデータバインドと各インターフェースを用いてオブジェクト指向で作ったのがMVVMになんのかなと、とりあえず理解した。
WPFでMVVMって秘伝のタレというより、作り手の匙加減で決まるお袋の味みたいなもんか。 MVVMは従来のWindowを幾つも開くタイプのアプリじゃなくて、1つのフレームにページを読み込むWebページのような動作をするアプリに最適なアーキテクチャで
MVVMのベースとなるｐｒｉｍｓやMVVM Toolkitなどのライブラリはそっちで必要なDIやマルチキャストのイベントなどの機能も盛り込まれています
Windows template studioというMSによるVSの拡張機能でこれらを使った雛形でアプリを作れるけど、生成されたアプリを眺めていけば見えてくるんじゃないかな >MVVMは従来のWindowを幾つも開くタイプのアプリじゃなくて、1つのフレームにページを読み込むWebページのような動作をするアプリに最適なアーキテクチャで
逆に、MFCやFormsと比べてもその違いを意識することが少ないと思うが。
トップレベルの要素が<Window>かそうじゃないかの違いくらいしかないし。 うん、あんまり関係ないね
むしろマルチページアプリをコードビハインドを最小にする純粋MVVMで作ろうとすると苦労する >>689
あなたが苦労して作ったのは大半が MVVM 部分じゃなくて
MVVM + α の α の部分 VMのプロパティとXAMLのプロパティ(Text="Hello World"のTextがプロパティ)をバインディングして組んでいくのがWPFのMVVM
オブジェクト指向がどうとか難しいこと考えなくていい 個人ツール作るだけだと設計が自由でDIで困るような事態にならないので
何もわからない状態のときに、よく見るPrismって何だとか必須なのかとか思って調べてた時間が無駄だった
入門者がMVVMを理解しようとする上で邪魔な情報が多い
今のところ手間削減のために使ってみたいと感じさせてくれるものはReactivePropertyだな とにかく楽してMVVMしたい人向けならCaliburn.Micro一択 >>694
自分それだわ
バインドバインドぉ！mvvm？こんなのでいいの？動くからおｋ ReactivePropertyでVM作るのパズル組んでるみたいで楽しい viewのイベントを全部vmで拾えれば楽なのに
コードビハインドからvmのコマンドつかったら疎結合ガーとか面倒くさい bland用のframeworkを
mvvmと称して流布した？？だれ？(･･;)
の罪は重いな MVVMでイベントが使いたいときはMicrosoft.Xaml.Behaviorsを使おう
これ公式WPF拡張パッチみたいなもんだよね >>699
慣れたらReactivePropertyは手放せない罠
Prismはそれほどでもない ReactivePropertyはナシだな
個人作成のは業務で使えんわ
Prismもサードパーティ扱いだからギリNG ReactivePropertyやPrism相当のものをMicrosoftが用意しないのがダメすぎる。
ライブラリでもプラットフォームでも各自で勝手にやってくれがひどすぎる。 っ Microsoft.Toolkit.Mvvm (MVVM Toolkit) これ来るの遅すぎた
名前空間にMicrosoftが付いてればどこの現場でも文句言われずに使えるのに >>705
多くのオープンソースライブラリが使えなくて大変な職場だねー まあガチガチな所はそうでしょう
遅れてるとしか思わんが リスクがあるのは事実だからねえ
JSON.NETの作者に悪意があれば明日にも.NETは崩壊するんだよ >>711
気になるならSystem.Text.Jsonに移行すればいいんじゃないの？ Json.NETはMITライセンスでソースが公開されているからどうとでもなるような ReactivePropertyもMITライセンスだね そんなおいらはLitJSON
ただし日本語の扱いにちょいと問題あって自分で直す必要あるんよ ReactivePropertyってコレクションと双方向バインドできないよね？ MVVMスレが過疎ってるんでこちらで質問させてください。（>>8 その通りです）
Microsoft.Toolkit.Mvvmは、Prismなんかの外部のMVVMフレームワークに対抗して、Microsoft内で作ったMVVMフレームワーク、という認識で合っていますか？
Prismの使い方を知らないんですが、これからはMicrosoft.Toolkit.Mvvmを勉強すればいいですか？ コミュニティツールキットの一部だけど、MS公式と考えていいと思う。
自分の使いたい機能だけピックアップして使えるし、将来性もあるし、軽量だからお勧め。 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 は終了）
標準ライブラリに入るものではなく、
これらの機能はあくまでオプション扱いという事かな Prismは元々MSが作ったサンプルコード集で、MSがメンテを終了しコミュニティに移管された
まず確実にMicrosoft.Toolkit.Mvvmも同じ運命を辿る 皆さん、ありがとうございます。
>>719
一応、MS公式と考えてもいいんですね。
他のと比較すると軽量らしいですね。
>>720
なるほど、勉強になります。
ちなみに、そのBlendのドラッグ＆ドロップでUIを設計出来る機能は
Microsoft.Toolkit.Mvvmに引き継がれていそうですか？
>>721
へぇ、Prismも元々はMS製だったんですね。
それなら標準に入れてほしかったですね…。
同じ運命を辿るなら将来性はありますね。
勉強してみます。 >>724
VS 使わなくなって長いからわからんね
VS 使えれば、Blendもライセンス的に付属していたとい思うので、
試してくださいな デスクトップアプリとウェブアプリ一緒にしてるあたり理解度低そうだな Electronしたいけど
作り方がよくわからん・・・ Blendはそのうち消えるだろ。
覚える必要なし。
Electronは1アプリごとに新しくブラウザを追加インストールするようなアホアホマンだからやめとけ。 JavaアプリケーションとJavaアプレットは同一で作れたんじゃ >>725
BlendはVSに抱き合わせで入っていたんですが、速攻で消しました（笑）。
Microsoft.Toolkit.Mvvmでできるか試してみます。 Microsoft.Toolkit.Mvvmを覚えるには、今の所Windows Template StudioというVSの拡張を入れてから
WInUI3かWpfの雛形を自動生成して、そのコードをMSのドキュメント見ながら学習した
ライブラリの中でもMessengerは便利でお薦め >>728
そんなに難しくないですよー−
ＵＩ/ＵＸに凝りたいならWebの数多あるUIライブラリーが使えるのでおすすめ
一応、Web系はなんでも動く、React, Vueに
ASP.NET Razorとかでもクライアントアプリ作れます
ローカルリソースにあんまアクセスしななら、
PWAとかでもデスクトップアプリ作れますよー−
OS問わずマルチプラットフォームで動きます そういえば、Messengerパターンって自分が
いろいろ方向性を変えたきっかけでしたね >>733
Electronで
ユニバーサルスタンドアロンデスクトップアプリケーションの作成方法
Win10pro64bit環境で具体的手順を誘導お流いします 早くに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 >>736
サンクスや鳥会えず見てハロワで基礎かしらねば如何もです >>737
最初のはBlazorだからデバック面倒なのでやめといたほうが良いね
ASP.NET CORE MVC の方が良いでしょ
動けば、ローカルリソースを使う部分以外のUI的なのは普通のWebアプリと同じ
一応、Electron.NETは派生なので、元のElectronとは少し違う、似てるけど、
.NETな人が雰囲気つかむ目的なら最適かな 記事のリンク先にあった、こっちのが素のElectonだ
https://qiita.com/nqdior/items/091200c9f01e8827fdbd
この場合、ローカルアクセス部分をＣ＃で書きたいなら、
Edge.js という便利なのがある
https://github.com/agracio/edge-js
これは js <-> C# ブリッジだ！
では、貴殿の検討を祈る！ >>738
ASPとか素人なのでLinuxのコマンドみたいなのはよくわからない
Windowsの黒い画面にコピればいいのかな？
エラーの嵐これは場違いなようだワ出直してくらぁ
でもあーざーした >>732
Windows Template Studio、さっそくインストールして試してみました。
いいですね。Navigation Paneのテンプレートもすぐに試せました。
でも、その参考にしたサイトがPrism推しで、
良いチュートリアルがあるみたいなんで
Prismでもいいのかなとまだ少し迷っています。
ああいうサイトがもう少し前にあったらPrismやってたんですけどね。 信者がｷﾓｲからElectronはやめておこうっと… Prismは複雑怪奇だったんだが、Ver７で破壊的更新をやって前との互換性は失ったけど
機能は整理されて格段に使いやすくなっているんだよな
昔触った人が二度と使いたくないと思う気持ちはわかるし、
互換性を犠牲にしたバージョンアップで他所に移った人もいるだろうが
今のやつは言うほど酷いものじゃない prismは途中から路線変更してフレームワーク的なライブラリみたいなのになったところで切った Webview2ってClearScriptみたいにJSのFunctionオブジェクトをデリゲートに変換できないのかな？
UIだけReact、それ以外の層を.NETで実装してて詰まった
素直にmessage使うしかない？ >>745
切らないでも便利なライブラリだけ使えばよくね？ >>720
BlendはXAMLの拡張だしMicrosoft.Toolkit.Mvvmと比べるようなものではないだろ
XAML=MVVMだと思っているのか >>747
素直にElection.NETじゃね？ >>748
だからPrismみたいに図体の大きい融通の利かないのじゃなくて
他の便利なライブラリに移ったんだろ >>751
DLLのサイズ確認したけど
Prism.dll : 90KB
Microsoft.Toolkit.Mvvm.dll :73KB
大してサイズ変わらないと思う
Prism.Coreだけnugetしたら特別図体が大きいわけじゃないね もう頑張らなくていいのよ。
Prismはオワコンだもの。 prism使ってるけどwindow開いていってるわ・・・ 本質というか、周回遅れすぎる感じ
すでに表彰式終って解散してるのに、これからマラソン始める人いるよ WPFの周辺技術にオワコンでないものなんて存在しないんだから好きなの使えばいいよ WPFとUWPオワコンなの気づかずにまた2つを合体させようと頑張ってるMSってなんか哀れだよね WPFとかUWPとか関係ない
Windowsがオワコンなだけ
WPF、UWPに変わる優れたシングル環境のフレームワーク出てきてもwindowsアプリ増えないから
flutterなどのクロスプラットフォームに寄生して、ついでにWindows向けをビルドしてもらうしかない まぁ、win11でandroidアプリの実行環境が用意されるから、もうこうやってアプリ増やすしかない
LOBとかならまだしも一般向けのアプリのwindows専用に作る人なんてわずかだろ そもそもソフトウェア自身が儲けにくくなってきてる気がするよ。
検索エンジンで儲けた金で大量のプログラマに作らせたソフトを無料で配布される
ようになってしまったり、MS Officeみたいに独占禁止法違反してそれ以外のものが
入っていく余地がほとんど無くなったり。作っても作っても、MS Wordなどに
真似されて実装されるから自分が作ったものがまともに売れることは無い。 Wordの新機能なんて興味ないから全く知らないんだが
なんかひどいことしてんの？ 今時Windowsのソフト開発なんてほとんどがB2Bでしょう C#でWeb系やるとしたらASP.NETしか無いですか？
C#とJavaScriptとの組み合わせも可能ですか？
それをやるんだったらNode.jsとの組み合わせの方が楽ですか？ >>765
そういう会社もあるかもしれんけど、たとえば奉行なんか使っている大多数の企業はなってない >>767
大手、中堅どころの企業なら
システム開発はほとんどWebだよ
業界の人なら営業が持ってる案件表見てみるがいい
もしクライアントアプリがそこに有るとすれば
スマホ位しかない
大体運用やメンテナンスし辛いクライアントアプリとか
情室が嫌がる 業務系のエンジニアなら
10年以上前からその流れになってたから
殆どのエンジニアはWebに流れたよ
仕事先細りして食ってけないから C#はクロスプラットゲーム向けと、
内部GUI/CUIツール向きかな。 デスクトップアプリからWebに移ってまたデスクトップに回帰する流れもあるところはあるけどな WebやるならVueがWPFに似てるから良さそうだな 業務系の開発現場にいたらわかるけど、
（自分は独立してて、あちこちの開発現場に出入りしてた）
10年以上前から Web開発者 > クライアントアプリ開発者 になってた
今じゃ、クライアントアプリの開発なんて保守しかないし
会議にも呼ばれなくなって立ち位置がどんどん低くなってんだよ
（俺も専門は元々クライアント側だったけど、web系に完全シフトした
WPFもXamarinももう依頼されても仕事受けない）
それでも、サーバーサイドはまだC#は残ってる
ASP.NETの新規開発はまだあるし
ただWeb開発担当者の口癖は、
３年位前は次はAngularで、
２年位前は次はVue.jsで、
１年位前から絶対React！！になってる 笑
世界的に見ても、React一強の情勢になってしまったからね
あと、クライアントアプリの新規開発はFlutter激増してる
これはデスクトップからスマホにWebアプリまで作れる
しかも新機能のリリースがめちゃくちゃ早い
笑うぐらいに死角が無いし、開発者ならすぐ仕事みつかる ReactかSvelteかな
MVVMの本来の目的を意識低く実現していて、ああ、MVVMで色々変なクラス捏ねくり回してやろうとしてたのは結局こんなくだらないことだったんだなあと
Vueは所詮MVVMなのでアーキテクチャ的にはあまり学びはないかな >>774
“MVVMで色々変なクラス捏ねくり回してやろうとしてたのは”
過剰なまでの疎結合だよ
意味的にもMVVMとはちと違う指向 そういえば、１年位まえに期間限定で（３カ月〜半年？）b
blazorは良く話題に出たね
もう半年以上前から全く聞かなくなったけど、
流行が早い早い Web系はガキのお遊び感があるからな。
オモチャを取っ換え引っ換えして非生産的なことしてんなーって。
業種によってはC/C++もここ数十年見たことも聞いたことない、とっくに滅んだっしょっ、て認識のところもあるしなー。 flutterも数年かなという印象やな。
ぼっと作ってはWebエンジニアが飛びついて、
2、3年で古くしていくってもうアホなのカスなのって感じ。
あんなのと無縁で幸せだわ。 Googleだけでも、少なくとも Go, Kotlin, Dart の3つの言語作ってしまったし。
GoogleDriveやOneDriveなどの多数のOnlineStorageをまとめて制御できるライブラリ
がGoogle自らGoで書いているが、Flutterでそれを使いたくても橋渡しが
難しいだろうし、全部推進という訳には行くまい。 どれか一つの言語だけに集中させないことにはどうにもならないということ。 Cはまだ、どの言語からも呼び出せる方法が存在していることが多いし、また、
Wasm化しても小さいしまだいい。
Goで書かれたライブラリはWasm化したらサイズも大きいし、多言語から
の呼び出し方も自明では無いし困る。 >>773
購買や経費管理といった、昔ならクラサバでやっていたような「業務システム」は10年どころか
20年くらい前からWeb化されていたけど、業務で使うソフトウェアってそればかりじゃないわけで。
そのへんは業種業態によって変わるだろう。うちはメーカーだけど内製のツールはまだまだ
スタンドアロンが多いな。つか、そういうのはわざわざWeb化するメリットも少なかったり。 >>768
うちはパッケージ屋が本業だからうちのパッケージしか案件表にないんだ
すまんなｗ
けど大手企業とかもいまだにパッケージ頼りのところ結構あるぜ
比率は知らんけど 確かに、パッケージ屋は個別業務開発とは趣きが違うから想像はできるけど、
クラウド化は推進してないの？
ちょっと前に出入りしたパッケージ屋さんだと、昔はオンプレで運用してたらしいけど、
今はデフォがクラウドでマルチテナントで運用してたねー−
オンプレとかデスクトップクライアントとかは個別対応になる感じだったかな クラウド化が何を指してるのか分からんが
AzureもAWSも使ってバーチャルデスクトップ運用してるところが多いよ
今後はAzure Ｖｉｒｔｕａｌ DesktopだかでiPadとかChromeBookがクライアントの案件増えるっぽい >>780
Kotlinはgoogleじゃないような Formsなのですが、FileStreamで一つのファイルの更新って難しいですか？
今、壁になっていることは
ファイルを読み込む
↓
読み込んだファイルがロック状態になる
↓
書き込もうとしても書き込めない
読み込むファイルと書き込むファイルが違えば可能なのですが、
これってよくあるテンポラリーファイルなどを複製して対応するしかないのでしょうか >>790
ありがとうございます！
一時ファイルを複製して対応します 試してないけど読み込み側FileStreamのコンストラクタでFileShare指定すればいいんじゃないの >>792
ありがとうございます
何かできそうな気がします！ StreamReader/Writerのコンストラクタに渡せん？（あんま覚えてない つうか、
１．元ファイルを読みながらテンポラリファイルに書き込む
２．元ファイルを削除
３，テンポラリファイルを元ファイルの名前にリネーム
この手順が定番だが、これをやらないと書き込みエラーでファイルを失うよ 読み込むファイル自体に、書き込む香具師は、頭おかしい。
エンジニアじゃない
安全配慮義務違反 追記されていくだけのログとかならFileShare.Readつけても大丈夫だけどな >>795
元ファイル削除しないで新規ファイルをリネームで上書きできない？ >>803
Xamarin.Formsの発展形がMAUIなんだし、xamlが基本になるんじゃね？ XAMLもIntellisenseで自動で埋めてくれんかな
ItemsSource{Binding = Data}
とか書いた時点でDataがどんな型か読み取って適当に表示してくれればいいのに
例えばList<int>だったら自動で要素まで分解して表示するとかさ
例えばList<List<int>>だったら自動で2×2で要素まで分解して表示するとかさ
ComboBoxやListBoxだって適当に良きに計らえよ
いちいち打つ側が指定してやらんのが面倒くさい d:DataContext="{d:DesignInstance ...
で行けたような。 VS2022でマウスポインタを上に載せたら型が表示されたけど >>809
スニペットddc使えよ
ちゃんと補完するぞ >>809
UWPとWinUIのx:Bindはインテリセンス効くよ 終わったプラットフォームと始まる前のプラットフォームの話してるやつなんなの？ 署名なしの野良配布で開発モードONはなしで、
mauiは普通に野良配布できるの？ 名前を変えただけの悪名高きxamarinに何を期待してるんだか Xamarinと違って一からMSが開発するから期待してる >>814
じゃあ終わってないプラットフォームの話して。 このスレで扱うのが適切な、始まっててかつ終わってないプラットフォームって実は存在しないのでは？ MSのコードプラットフォームの主力がVSCodeに移ってもう長いし、
そもそもMSがオープンソースに舵切ってから相当たってるのに、
MSからまともなライブラリのが出てくる見込みはねえぞ。 >>810-813
♪あ〜〜〜〜〜〜り〜がと〜〜〜〜う
♪あ〜〜〜〜〜〜り〜がと〜〜〜〜う
XAMLでIntellisenseできました
スニペットでddcも行けました
UWPとWinUIはまた今度で このスレ見てる時点でWindowsに絞ってる人間なんだから先にあるのはMAUIじゃなくてWinUI 3だよね >>821
WPF。
UWPは始まりもしないまま終わったけどな。 MAUIとWinUIって開発工程においてはどれくらい違うの？ XAMLの
<ListBox ItemsSource="{Binding MyItems, ElementName=MyWindow}"/>
をコードビハインドで書くとどうなりますか？
this.listBox.ItemsSource = MyItems;
のようになるのは分かっても、ElementNameの指定方法が分かりません。 >>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");
} DirectXのDLLを参照してソフトを開発しているのですが、
開発環境ではちゃんと動作するものの別のPCだと参照エラーになる
調べてみると普通のPC(Windows10)にはDLLがインストールされていなくてこうなっているみたい
DLLを実行ファイルと同じ階層に置いてそれを参照するように設定すると
どの環境でも動くのですが、実行ファイルごとMSが作ったDLLを勝手に
配布したりするとダメらしい
たった2つのDLLのために2つも大きなランタイムファイルを
インストールしてもらうのも億劫なので、どうするべきか(T_T) >>829
全然違いました。
>>830
訂正、ありがとうございました。
それを使います。 >MicrosoftのWin UI 3はUWPを捨ててWin32に集中
MSもようやく学習したかな? >>835
笑
まじでアホなのか、
コード書けないマネージャークラスが
非IT的な裁定を下してるかだな
それにもうMSもオープンソースに任せてんだろ
オープンソースはガチで良いものしか
上がって来れないからね >>834
DirectX9c
大変だけど別のMS-PLって緩いライセンスのDLLを使って
システムを改修しようと思います 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. DirectXランタイムって色んなバージョンの雑にまとめた全部入りだから数百MBあるけど
やろうと思えばDirectSetupとか使って必要な分だけ同梱してサイレントインストールとかできるぞ
ぶっちゃけ必要なのがD3DXのDLLだけだったら横に置いて配布しても今時誰にも怒られんけどな
Chromeとか堂々とやってたし
もっともDirectXランタイムはdeprecatedされかかってるレベルのレガシー物件だし
可能ならD3D11にしてDirectXTKとか使った方がいいけど 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が指定できませんよね？ >>839
勉強になります。そうなんですよ。レガシーなDirectXはサポート終了で
廃れた技術なので、DLLを同梱して怒る人がいるとは思えません
でもライセンスはライセンスなので、無視はできません
サポート終了のランタイムをインストールしてもらうのは
考えものなので、やはり別の手段を取ることにしました >>840
DataGridに名前を付ける
それをコードビハインドで使う >>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は指定しなくてもいいの？
}
} >>844
>>845の例だと具体的にはどう書きますか？
dataGrid.SetBinding(ItemsControl.ItemsSourceProperty, dt);
と書いてもダメでした。 しまった、連投すみません
>>842
dataGrid.DataContext = dt;
ではなくて、
dataGrid.ItemsSource = dt;
みたいにできるはずなんですがご存じないですか？ >>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 そういやVM使わないWPFの挙動など殆ど把握していないわ >>848
仰る通り、
var bind = new Binding("dt"){ElementName = "MyWindow"};
dataGrid.SetBinding(ItemsControl.ItemsSourceProperty, bind);
で行けました！
これで行けるなら{ }の中を変えていろいろ指定できそうですね。
# ちなみに、
# dataGrid.SetBinding(ItemsControl.ItemsSourceProperty, "dt");
# は、DataGridは表示されるんですけど、
# ColumnもRowも表示されませんでした。
ありがとうございました！ INotifyPropertyChangedってもっと脳死で簡単にできないの それを言ったらIEnumerableの方が頻出でもっと面倒では >>851
INotifyPropertyChangedを使わない。
馬鹿の一つ覚えで何でもかんでもVM作る病からの脱却せよ。 >>851
VM用の基本クラス使ったら楽だと思うけど >>851
むしろあれ以上に簡単にできないやろ
自動実装プロパティにイベントも自動実装されたらパフォーマンスガタ落ちになるんじゃ 結局WinUI3もWPFと実装方法は大して変わらないの？ >>854
通知も何もない。
UI操作を起点にUIを直接書き換えて終わりだろ。
それで事足りるアプリケーションは山ほどある。 >>851
propfullとタイプしてからタブキー2回押すんだ ハッキリ言って個人レベルとか5000行未満のアプリならMVVMなんかより、ひたすらイベントパンドラで書いた方が見通しもいいし実は修正もしやすいよ。
VとVMがわかれててもC#てデスクトップのツールじゃメリットあまりないし。
ほぼ間違いなく同じ人間が書いてんだから。
別の人間がXamlだけ編集してるとか成功ケースないでしょう。
WPFは所詮デスクトップのツール向きで、商用アプリ向きではないし。
MがGUIでもコンソールでも変わらないAPIになるよう意識してればいいだけ。 Caliburn.MicroならPropertyChangedBaseが実装済み、例を示すと
private string _LogBox;
public string LogBox
{
get => _LogBox;
set => Set(ref _LogBox, value);
}
一方XAMLは
<TextBox x:Name="LogBox" />
これでLogBoxに何か入れるとテキストボックスに反映される
十分すぎるほど簡単に感じるけど・・・これすら無理な人いるかも知れない？ >>851
それを実装した汎用valueクラスを作ってそれを使う。
>>858
それが当たり前だよね。
完全にMVVMするのが目的になってしまった
なれのはて >>857
VMの書き方はだいたい同じだが、Viewでx:Bindが使えるからインテリセンスが効くし型のチェックもコンパイル時にやってくれる
あと、Viewから右クリックの「定義へ移動」でVMの変数定義に移動できる しょぼいプログラムほどMVVMでの実装も楽だからINotifyPropertyChangedを避ける理由がよくわからない バインドしない人は文字−数値の変換も自分で書くの？ >>860
VとVMの分離はべつにデザイナーとの分業だけが目的じゃあないが。というか重要度としては低い。
WPF知らない人にありがちな典型的な誤解。 いまだにMVVMに親を殺されたようなのがいるね
イベントハンドラしこしこ書くのはもういやだよ
でもWPFはFrameをもっとMVVMフレンドリーに作ってほしかたよ いや、知ってるからなんだけどw
ボダン押したら押したら更新する、同期性も何もない。
APIを呼ぶだけ。
大きくなる予定なし。
こんなのすらさえWVVMしだすっていうw 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と書くケースは皆無ですか？ >>869
Mvvmじゃなくて通知の問題ね。
WPFのMvvm以前はこんな問題は発生してないねーー >>861
冗長。
コード側の6行は不要。XAML側の1行だけでOK。 >>868
まだまだ初心者だな。
アプリに合わせて最適な実装方法を選択できるようにならなきゃ駄目だそ。道具は素材に合わせて使い分ける。
MVVMはあくまで道具の一つ。 >>873
ケースを想定せずにOKも何もないでしょうに 今はPrismだけ使ってるけど、みんなReactiveProperty使ってるの？便利？ >>874
もちろん、ポトペタやりたい人にとってはFormsがベストだしずっとそれを使い続けていればいい。 この辺は変な布教をした奴のせいでずっと尾を引いてるな >>874
WPF使うならMVVMが常に最適解
MVVMイヤならWinForm使えばええねん >>878
俺の個人的好みだとPrismは中小規模だと大げさすぎる
ReactivePropertyはもう手放せないレベル
でもいまだにBindingの .Valueを書き忘れてハマるｗ 俺なんかWinFormsでやるときでさえReactiveProperty使ってMVVMやるようになってしまったよ >>879
そう考えるってことはWPFを全然使いこなせていないってことだぞ。
WPFはFormsと比べればMVVMとの親和性が高いが、MVVMで作りやすいってのはWPFのメリットのごく一部。
>>881
全然違う。
日本語もWPFも勉強しなおし。
MVVM使うな、じゃなくて使うべきものに使えって書いてある。
思考停止してWPFだから必ずMVVM、は技術者として恥ずかしいぞ。
>>883
FormsにMVVMは馴染まない。
ちゃんとフレームワークに合った設計をしないと。 君にはすべてのクラスに
void Update(bool force = true)
を書く事を許可しよう、頑張りたまえ 言っている事は正しいしただの指摘、煽りではないだろ >>885
>FormsにMVVMは馴染まない。
お前の感覚以外にちゃんとした理由があるならぜひ 理由もクソも、MVVMはそもそもWPFのデータバインディングを活用するために考案されたデザインパターン
双方向バインディングを使用しないなら定義上MVVMではない やったこと無いけどFormsでもデータバインディングできるんじゃ？ >>890
Forms+ReactivePropertyで双方向バインディングやってるけど 業界アキーテクチャ的には
双方向バインディングはバッドパターンだ
糞認定済み react等の先端frameworkに比べると
思想的にかなり見劣りする 実行ファイル(.exe)が出力できて将来性のある
プラットフォームってやっぱりWPFしかないのかな？ 最先端はなんだろうAvaroniaとか？
SilverlightもWindows Phoneも、昔はいろいろあったよね >>897
WPFやるぐらいなら今後はWinUI3じゃ? WPFに将来性はあまりないのか
>>900
ありがとう。ちょっと調べてみる >>890
バインディングはあまり関係ないな。どっちかというと依存の方向がV→VM→Mだというのが重要。
そういう意味でFormsで真似しても似て非なるもの。 すでに10年以上過ぎてて将来性とか言われても
枯れてる方に分類されると思うんだけど、一体どんな期待してるんだ >>903
その方向の連携もFormsでできますけど >>905
その「連携」ってどういう意味で使ってる？
一般に依存の方向と制御の方向は別物だがここで重要なのは依存の方向。 >>906
もちろんVの表示はVMとMに依存してるよ 依存っていうからてっきり依存関係プロパティの話かと思ったら、全然違ってた >>907
やっぱりなんか理解してない。ここではいわゆるSOLID原則のDで言う依存性のこと。
MVVMでVが直接Mに依存することはない。 >Vで必要なMを作るんだから依存しないわけがない
「依存」の意味が通じてないとそもそも会話にならんな。 >>882
ReactivePropertyはメンテナーが実質ひとりだからなぁ。
その.Valueも意外と面倒くさいんだよね。 ObservableCollectionがAddRangeに対応して、
主要なWPFコントロールがAddイベントにてe.NewItemを同時に複数受け付けてくれれば神アプデなんだけどMSやってくれないかな。
ObservableCollection関連は、各ItemへのProperyChangedの登録／解除が超絶に面倒臭いんだけど、ReactivePropertyだとお手軽になる？ >>911
なんかFormsでMVVMできないことにするために適当な理屈をウダウダ後付けで言ってんな >>912
今はokazukiがメインメンテナ？
彼がやめたら俺がやるわ >>913
極力簡易記述できるようにしてると思うよ MVVMはXAMLやFXMLといったマークアップ言語があって初めて実現する
XAMLを信じないものに未来はありません
XAMLは偉大にして唯一神と3回唱えるのです ObservableCollectionで個々のItemのPropertyChangedを取りたいときって、
NotifyCollectionChangedAction.Add・RemoveにPropertyChangedのイベント購読を登録・解除
しますよね？
その配列をClear()しちゃったら、Removeでの解除を通らないと思うのですが、
この場合、メモリリークしますか？ >>920
NotifyCollectionChangedAction.Reset飛んでこない？ >>921
自分も最初はReset飛んできたとき解除すればいいと思ったんですが、配列がすでに消去済みなので解除できないことに気づきました。
各ItemのコンストラクタとDisposeに登録解除を書くしかないのかな。 >>903
向いてるかどうかは別にして、
FormをVとしてVMとM作ってバインディングすればMVVMできると思うんだが
>似て非なるもの
どこが異なるんだよ？
お前の言う本当のMVVMってなんだよ ああ、バインディングはMVVMの構成要件じゃないのね
ますますお前の意見がわからんわ >>922
ObservableCollectionに
protected override void ClearItems()
ってのがあるから
ObservableCollectionの派生クラス作ってClearItems()をオーバーライド
ClearItemsが呼ばれたタイミングで購読解除すればいいと思う。 >>922
public class MyCollection<T> : ObservableCollection<T>
{
protected override void ClearItems()
{
//ここで購読解除
base.ClearItems();
}
} >>926うおーすごい。stack overflowでもそこまでドンピシャな回答無かったです。
ありがとうございました。 コレクションをオーバライドして
改良するってアーキテクチャ知らない人多いね 仮にオーバライドしないで出来るならその方がずっと楽だしな >>923
クリーンアーキティクチャのあの同心円の図を想像するとわかりやすい。一番外側がVで中心がM。
その依存性逆転のためにバインディングという仕組みを使っているだけに過ぎない。 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. 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ならそりゃできるだろうけど。 >>931
バインディングが単なる手段に過ぎないという意見は分かった
で、
>Formsで真似しても似て非なるもの。
はどういうことなんだ？
お前の言う真のMVVMとはどういったものなんだ？ 滅茶苦茶な機械翻訳を鵜呑みにして混乱してる初心者あるある
また断続的な絞首刑が発生しちゃうね Microsoft Silverlightがオープンソース化、「OpenSilver」ベータ版リリース
https://news.mynavi.jp/article/20210916-1974193/ >>938
MSはどっち行きたいねん？
一つがっちりしたのを標準で出せや！ Silverlightは救済策だろう
メインストリームはWinUI ActiveXじゃなくてWASMベースになったってのが興味深いな。
デスクトップ版も用意したうえでBlazorと組み合わせてほしい。 ソースジェネレーターでバインディング周り上手い事オーバーヘッド無しに出来んかな >>939
まだわからんの
オープンソースだよMSは >>944
タイトルが悪いと思う
オリジナルのSilverlightをMSが作ったってだけで、MSはほぼ無関係だな
UserwareがWebAssemblyで動作するようにSilverlightを実装しなおしたものをオープンソースでリリースしただけ Userwareって会社ね
既存のSilverlightアプリをSilverlightからOpenSilverに移行するソリューションを売るみたい お
オープンソースSilverlightか
光ちゃんも引っ張ってこい >>945
タイトルが悪いと言うかわざとだろ、これ
UserwareがMicrosoftからソース譲渡してもらったならわかるけど "reimplementation of Silverlight" だから要するに互換ソフトをオープンソースで作ったって話でしかない あれ？
さっき思ったんだけど、
C#でしかできないことってあるよね？
ループで回して同じものを複数表示するとか
逆にXAMLでしかできないことってあったっけ？
無い気がする・・・
そんでMVVMもXAMLなしで出来るんでしょ？
そしたらXAML要らんじゃん・・・ >>949
画面をXAMLで書けるのがWPFの一番のメリットなんだが XAMLは筋の悪い技術だよ
ループ等を無理矢理バインディングで実装しなきゃいけないために複雑怪奇になってる
普通に文字列のテンプレートエンジンか、Reactみたいにコードでよかった
MVUでは結局コードになったね XAML Styler必須だよな、なぜVisual Studioに標準搭載しないのか ループって何言ってるか分からんがリストのことならコレクションバインディングするだけでしょ
違うならすまん ObservableCollectionとListViewをバインドするだけとちゃうの？ >>951
画面をXAMLで書けることの何がメリットなの？ >>952
禿同
Viewと分けるにしても、XAMLなんか使わずにコードでいいじゃんね >>950 >>954-955
スマソ、確認だけど、
XAMLで出来ること ＝ コードビハインドで出来ること
なん？
すべての機能が一対一で相互互換性あるの？ 別にMVVMは強要されてる分けじゃない
使いたくなければ使わなくていいよ MVVMじゃなくてxamlか
xaml無しでUI書くこともできるだろう、好きにすればいい メリットは宣言的なところ
jsさえあればDOMでdocumentを構築できるがやる奴なんかいないのと同じ >>960
全然答えになってない
XAMLでやってることすべてをコードビハインドで出来るのかって訊いてる >>961
コードでうまいこと宣言的にできないもんかね？ >>963
目的と手段が逆転してるぞ
そのためにXAMLがあるんだろうが ReactのあれはReactだけのやり方だから好きじゃないな >>962
何でそんな失礼なん？
全部できるかどうかなんて証明でいないわ
MSに訊け >>956
・画面イメージそのままに階層構造で表現できるからXAMLを見ただけで画面イメージを把握できる。つまり画面デザイナが無くても困らないからVSCodeでも開発できる。
・diffで差分を確認しやすい。
・スニペット登録しておけばEmmetみたいに爆速で画面作成できる。 XAML直接弄ることはあったけどデザイナーで結果見ながらだ
さすがプロだ。ちがうなあ…。 xamlでやってることはすべてコードビハインドできる
xamlで書けるものはそうした方が楽で速いってだけ >>954
例えば要素の特定のプロパティの値に応じてスタイルを変えたいとき、HTMLのテンプレートなら値に応じてifでCSSのクラスを切り替えるだけだよね
XAMLだとどうする？いちいちConverter作る？ いちいちというかConverterはふつうに作ってるな。ある程度作ったらあとは使いまわせるし。 お前がXAMLをどう思うかなんてのはどうでもいいことだ
アニオタが自分はこのアニメが好きでこのアニメが嫌いって言ってるのと変わらん >>969
何の速度の事をいってるのか判らんが、
動作速度はコードビハインドのが早いぞ >>964
サンクス
とりあえずコードだと宣言的にはできないということはわかった
>>967
サンクス
裏を返せば、コードだと画面がイメージできない・しにくい、と言ってるんだな、それは分かるかも
差分はイメージできる前提でメリットにはなり得る
スニペットってどの粒度で作ってあるんだろう？
それを標準で載せてくれよと思うわ
左のリストボックスで選択すると右のリストボックスに移る奴とかさ、結構使うだろ たぶん、動作速度の事いってないと思う
楽でっていってるから、開発速度とかじゃね >>975
差分は〜のあたり何言ってるのか分からんが……
とりあえず最後の複数リストボックスのそれはたぶんコードビハインド書かないと無理
フォーカスの移動はバインディングで対応できなかったはずなので >>975
差分は〜のあたり何言ってるのか分からんが……
とりあえず最後の複数リストボックスのそれはたぶんコードビハインド書かないと無理
フォーカスの移動はバインディングで対応できなかったはずなので >>970
色を変えるとか簡単な変化ならConverter
スタイルそのものを変えるならTemplateSelector
でもこれループ云々と関係ある？ >>980
Webのテンプレートエンジンを使ったことあるなら、そんな疑問が出てくる方が不思議なんだが >>977
そうかぁ、複数リストボックスはやっぱりコードビハインドが無いと無理そうなのか
フォーカスの移動がネックね
XAMLの限界って奴かな
こういうのがあるなら最初っから腹くくってコードビハインドで書いた方がいい気がしてきた
だって、XAMLで書いててどうやるんだろう？と悩んだ挙句、
結局コードビハインドしか解決法が無い、ということにもなりかねんからね
訂正：
差分はイメージできる前提でメリットにはなり得る
↓
XAMLを見て画面がイメージできる人なら、diffで差分を確認しやすいのはメリットになり得る
まぁ、階層が増えたとか移動したとかは分かりやすいだろうな >>981
イヤな言い方だね
あんな汚らしい記法は嫌いだわ
ループよりコレクションにバインディングする方が読みやすい(個人の感想です) xamlはbamlにコンパイルされ理論上はC#コードより速くなるよ
少なくともMSのWPFチームはそう主張して
生C#にコンパイルするcamlを廃止したわけだし
なお実際に測定すると... >>984
それは単純ケースだけじゃ？
MSの公式のパフォーマンス改善の手引きに
バインデイングを止めるようにとあったと思うが... とにかく俺のプロジェクトじゃ
WPFのパフォーマンスの悪さがやり玉に上げられて
それは大変だった... 双方向バインディングをやめてOneWay等も使えって書いてあった気がする WPFのBindingは全部レイトだから遅いのは宿命だわな
UWPからx:Bindを逆輸入すればいいのにと思っていたけどもうWinUIに逝っちゃったからなあ とにかく、
バインデイングとかテンプレートのセレクターの動作をみれば、
遅くなるのは当たり前なんだよなーー WPFはバインディングよりも描画が重かったイメージだな >>985
逆だね
単純なケースでは生xamlでも速いのでbamlの利点が生きてこない
VisualStudioで描画が重いと思ったことないので（軽いと思ったこともないけど）
WPFそのものにはポテンシャルは十分にあるんだろう
ただWPFみたいた終わったテクノロジーでそんなレベルの開発者集められるのはそれこそVSの開発チームくらいだろうね >>982
そういう複合コントロールはユーザーコントロールで作るからデータの出し入れは依存関係プロパティーを使いMVVMは使わず
処理もコードビハインドに思いっきり書く
で、出来たものをページなりウインドウに貼り付けて使用します x:bind 速度の違いが全くわからないので使うのやめた
コンパイル時の型エラーがうざいし
bindingに戻った
速度に関してはそりゃ開発環境入れてるメインマシンで動かせばそりゃ問題ないけどさ、ローエンドのCPU積んでるマシンで動かしたらどうなんだろう
今時のローエンドでもbaytrailのatomからは随分速くなったろうから問題ないと思うけど?? >>993
WPFは遅くて同時は叩かれましたよ
そのあと改良されて大部分巻き返しましたが
同時かなり高度な描画デバックキットがリリースらされましたので
それを駆使して対処してましたが
XAMLとバインデイングから
どのようなコードが生成されてるのか
予測が付かなくて
地獄見ましたよ つかさ、winuiもいいんだけださ
そもそもwindowsを開発とかのマウス入力前提の環境でしかつかってないんだよ
だから、winuiのfluent designがタッチ入力よりすぎで微妙すぎる >>990
WPFにはx:Bind無いので直接比較はできんけど
UWPで同じようなもん作ったとき、Binding連発してるところで
WPFだと頻繁に見られるタメみたいなのがなかったね まじで?
俺はUWPのbindingとx:bindしか比較してないけど
x:phaseとかも使ってみたけど
体感で全く違いがわからなかったわw
もちろん厳密な比較はしてないけど このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 91日 19時間 16分 47秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
