◎正当な理由による書き込みの削除について: 生島英之 とみられる方へ:WPF(.NET, WinUI) GUIプログラミング Part26 ->画像>1枚
動画、画像抽出 ||
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク: http://5chb.net/r/tech/1624176258/ ヒント: 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
Windows Presentation Frameworkについて語るスレ。
前スレ
WPF(.NET4.x, .NET Core) GUIプログラミング Part25
http://2chb.net/r/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年くらいw 無くても困らないw
俺もWinFormsからWPFに乗り換えた人間だが、明らかに開発は早くなったと感じる まあ小っさいの作るならWinFormsの方が楽だろうけどね。MVVMの骨格を整備するの面倒だし。 GUIとロジックを分けて書ける有難みはそこそこ複雑なものを作って分かったよ
まあWPFの良し悪しは置いておいても、マークアップ言語でのGUI構築には慣れておいた方が良いことは間違い無いと思う なんせ今はWebアプリが強い時代だからね。それでも俺はデスクトップに残り続けるがw
WPF以降だとサムネイル表示とか一瞬で作れるもんな formならこうは行かないと思うけど 効率重視のformの人はformのリストビューみたいなので我慢できる人なの?
>>10 jsとかの他のMVVMは確かにそんなもんつかってねーな
Livetやprism使ってありがたいと思ってたけどそもそもがそんなもん使わせるなよよw これ以外何も思わない その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の方が優れてるからそっちを選べよって指摘だ罠。 選ばねえよバカww
まあ単体アプリを配布する分にはサンドボックスの有用性が生きるな Windowsの生命線ともいえる業務アプリとはこの上なく相性が悪い iPhoneで業務アプリシステムを構築しにくいのと一緒 結局Webアプリに逃げられてしまう
>>93 消費者としても受け入れらえなかった。
exeひとつを自分の好きな場所に配置して実行できる自由さには勝てない。
そもそもセキュリティのメリットを理由にUWPを入れたがる消費者なんてほぼゼロに近い。
会社だとストア無効化、サイドロードの設定も有効化できないようにされてるところが多いから
UWPは使い物にならない。
ストアの画面とか開くことすらないからストアに何があるのかすら知らないわ VS2022とかストアで扱えるようにすればいいのに
UWPの問題は ・Win10専用 ・DataGridが当初無かった ・EF Coreが当初SQLiteしか使えなかった ・インストーラがプライベートストア構築からとハードル高杉 辺りが問題だったね 今ならインストール以外はだいたい解決しているから使えないこともないが
ストアでインストールしたのはWSLくらいっすかねえ
Formsがオワコンかと思ったら.NET5で再び生き残ってるっぽい リユニオンプロジェクトとかWinAPIも復活するし 分断させたいのかくっつけたいのか、終わらせたいのか復活させたいのかよく分からない体制だな
APIは死んでないだろw 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アプリと合体するとはなw
>>113 いや、テストアプリでもWPFの方がはかどるよ
>>115 MS社内でもUWPは期待されてない香りがプンプンするぜ
>>115 ようは敗北宣言じゃね?
Windows8で糞使いにくくしたりストアアプリ/UWP注力でデスクトップ放置とか全部失敗だったな。
>>119 Windows11で切るんじゃなかったっけ?
32bitどころか俺のPCが11で切り捨てられそうなんだけど
定期的に湧くよな、マカー並の低能馬鹿、切り捨て厨。
>>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には馬鹿しかいないのか
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は高速って話だが、WinUI3も期待できるんじゃね?
>>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を設計して喜んでていいのってそれこそ小学生までだよねーww
>>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で開発スピードを上げるってネタだろw リスト出てくるとイラっとする
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みたいなクソにしがみついてるのか理解しかねるね
てか今後新しい通知インターフェースを宣言した奴は死刑でいいよ 殺す
趣味でやってるだけだからよくわからんけど同じプロパティー2回書かせるのやめてくれ めんどくさい
>>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への更新は全部フレームワーク経由で実施するってことか フレームワーク君頑張るなw
>>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 それは間違いだよw
VMにM更新のロジックを書くなよとw
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が変更通知出してるのかw? 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 でやってるやつを教えて欲しい 馬鹿の世界では当たり前らしいけどw
>>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ってこんな中途半端に作ってあるのかな 作ってるときに上下のスペース気にならなかったのか
richtextboxの上下のスペースなら気になった 馬鹿が作ったんだろうなとニヤニヤした
>>601 1.0が出てから触ってみるつもりだから分からん。
UWPが見向きもされなかった欠点が解消されてるなら移行するし、
駄目ならWPFとWinUIのミックスになるかもしれない。
基本的にGUIはUWPが基本でほんの一部異なる程度 売りはファイルアクセスなどの制限のない.netのクラスや C言語のライブラリが普通に使えること 残念なのは.net nativeは対応していないからUWPほど高速にはならないところだな
俺はカラー絵文字が普通に使えさえすればもう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
https://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 ハンドルかぁ。
なんか以下の4種類ぐらい取得する方法あるっぽいけど違いがよくわからない・・・。
1:
[DllImport("user32.dll", ExactSpelling = true, CharSet = CharSet.Auto, PreserveSig = true, SetLastError = false)]
private static extern IntPtr GetActiveWindow();
IntPtr hwnd = GetActiveWindow();
2:
[ComImport, Guid("EECDBF0E-BAE9-4CB6-A68E-9598E1CB57BB"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IWindowNative
{
IntPtr WindowHandle { get; }
}
IntPtr hwnd = WindowHandle();
3:
IntPtr hwnd = new WindowInteropHelper(Application.Current.MainWindow).Handle;
4:
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のベースとなるprimsや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?こんなのでいいの?動くからおk
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 そんなに難しくないですよー-
UI/UXに凝りたいなら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 この場合、ローカルアクセス部分をC#で書きたいなら、
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は複雑怪奇だったんだが、Ver7で破壊的更新をやって前との互換性は失ったけど 機能は整理されて格段に使いやすくなっているんだよな 昔触った人が二度と使いたくないと思う気持ちはわかるし、 互換性を犠牲にしたバージョンアップで他所に移った人もいるだろうが 今のやつは言うほど酷いものじゃない
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開発担当者の口癖は、 3年位前は次はAngularで、 2年位前は次はVue.jsで、 1年位前から絶対React!!になってる 笑 世界的に見ても、React一強の情勢になってしまったからね あと、クライアントアプリの新規開発はFlutter激増してる これはデスクトップからスマホにWebアプリまで作れる しかも新機能のリリースがめちゃくちゃ早い 笑うぐらいに死角が無いし、開発者ならすぐ仕事みつかる
ReactかSvelteかな MVVMの本来の目的を意識低く実現していて、ああ、MVVMで色々変なクラス捏ねくり回してやろうとしてたのは結局こんなくだらないことだったんだなあと Vueは所詮MVVMなのでアーキテクチャ的にはあまり学びはないかな
>>774 “MVVMで色々変なクラス捏ねくり回してやろうとしてたのは”
過剰なまでの疎結合だよ
意味的にもMVVMとはちと違う指向
そういえば、1年位まえに期間限定で(3カ月~半年?)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 うちはパッケージ屋が本業だからうちのパッケージしか案件表にないんだ
すまんなw
けど大手企業とかもいまだにパッケージ頼りのところ結構あるぜ
比率は知らんけど
確かに、パッケージ屋は個別業務開発とは趣きが違うから想像はできるけど、 クラウド化は推進してないの? ちょっと前に出入りしたパッケージ屋さんだと、昔はオンプレで運用してたらしいけど、 今はデフォがクラウドでマルチテナントで運用してたねー- オンプレとかデスクトップクライアントとかは個別対応になる感じだったかな
クラウド化が何を指してるのか分からんが AzureもAWSも使ってバーチャルデスクトップ運用してるところが多いよ 今後はAzure Virtual DesktopだかでiPadとかChromeBookがクライアントの案件増えるっぽい
>>780 Kotlinはgoogleじゃないような
Formsなのですが、FileStreamで一つのファイルの更新って難しいですか? 今、壁になっていることは ファイルを読み込む ↓ 読み込んだファイルがロック状態になる ↓ 書き込もうとしても書き込めない 読み込むファイルと書き込むファイルが違えば可能なのですが、 これってよくあるテンポラリーファイルなどを複製して対応するしかないのでしょうか
>>790 ありがとうございます!
一時ファイルを複製して対応します
試してないけど読み込み側FileStreamのコンストラクタでFileShare指定すればいいんじゃないの
>>792 ありがとうございます
何かできそうな気がします!
StreamReader/Writerのコンストラクタに渡せん?(あんま覚えてない
つうか、 1.元ファイルを読みながらテンポラリファイルに書き込む 2.元ファイルを削除 3,テンポラリファイルを元ファイルの名前にリネーム この手順が定番だが、これをやらないと書き込みエラーでファイルを失うよ
読み込むファイル自体に、書き込む香具師は、頭おかしい。 エンジニアじゃない 安全配慮義務違反
追記されていくだけのログとかなら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を書き忘れてハマるw
俺なんか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 もちろん厳密な比較はしてないけど
このスレッドは1000を超えました。 新しいスレッドを立ててください。 life time: 91日 19時間 16分 47秒
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
read.cgi ver 07.7.23 2024/12/25 Walang Kapalit ★ | Donguri System Team 5ちゃんねる
mmp lud20250218204305caこのスレへの固定リンク: http://5chb.net/r/tech/1624176258/ ヒント: 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「WPF(.NET, WinUI) GUIプログラミング Part26 ->画像>1枚 」 を見た人も見ています:・WPF(.NET, WinUI) GUIプログラミング Part29 ・WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part22 ・Windowsのソフトウェア作るのに学ぶべきプログラミング言語って何? ・Bitcoin Core ビットコインコアの重大なプログラミング欠陥 ・【IT】6月プログラミング言語人気ランキング、Kotlinが急増の傾向 ・【嫌儲プログラミング部】Kindleストアでプログラミング・IT技術書が半額セール、人気のPython機械学習の解説書も ・東大生「現実逃避でゲームはダメ。任天堂のナビつき!プログラミングをやりなさい」 ・【悲報】=LOVE 唯一のレギュラー番組『今こそ知りたい!めざせ!プログラミングスター』本日で終了w ・C++の後継を目指すプログラミング言語「Carbon Language」がGoogleによって公開される ・俺「プログラミングの勉強するか」 教材「i = i + 1」 俺は諦めた ・プログラミング言語 ・プログラミングをするゲイ ・プログラミング初心者なんだが ・プログラミング学びたい人 ・プログラミングで何か書く ・七行プログラミング part6 ・■日商プログラミング検定■ ・なんJプログラミング&電子工作部 ・プログラミングを教えて下さい ・プログラミング始めたいんだが ・プログラミングのお題スレ Part9 ・ゲームのプログラミングできる人募集 ・プログラミングのお題スレ Part21 ・プログラミングの課題ができない..... ・プログラミングって学んでどうすんの? ・プログラミングのお題スレ Part12 ・プログラミングにおける偉大な発明は? ・プログラミングの勉強始めようと思うんだけど ・安価でプログラミングの教科書を作るスレ ・スマホでプログラミングできますか? ・プログラミング言語を作るってどうやるんだ? ・普通科高校高2プログラミング系志望 ・小学校でプログラミング教えたりしたい ・プログラミングの勉強方法を30秒にまとめた ・プログラミング言語ってなにがいいの!? ・最も美しいプログラミング言語は? Part6 ・初めてのプログラミングでSolidtyってどう? ・【画像】日本のプログラミング教育が凄い ・ヒッキーの競技プログラミングするスレ ・プログラミング言語のオススメ教えてくれ ・お前らプログラミング言語どうやって覚えたんや? ・プログラミングとかアプリ開発できるやつ集まれ ・NHK教育を見て61652倍賢くプログラミング ・関数型プログラミング言語Haskell Part32 ・関数型プログラミング言語Haskell Part34 ・プログラミング1から教えてくれる方いますか ・マルチスレッドプログラミング相談室 その9 ・結局人気の高いプログラミング言語ってなに? ・なんj民オススメのプログラミング言語ってなんや? ・ネットワークプログラミング相談室 Port27 ・競技プログラミングにハマるガイジのスレ 94 ・プログラミング言語ってさ?どう覚えるべき? ・プログラミングやってると出てくるおまじないの魅力 ・この世は数学とプログラミングで構築されている ・起業のためにプログラミングスクールはアリ? ・競技プログラミングにハマるプログラマのスレ ・【IT】共通言語はプログラミング 素顔のAI世代 ・【相談】プログラミングを独学でやろうと思うんだが ・プログラミング詳しいVIPPERって意外と少ないよな ・プログラミングは独学よりスクールにすべきか? ・【社会】プログラミングで「飛び入学」千葉大が導入へ ・プログラミング出来るまともな日本企業ってあるの? ・競技プログラミングにハマるプログラマのスレ 91 ・競技プログラミングにハマるプログラマのスレ 41 ・競技プログラミングにハマるプログラマのスレ 113 ・競技プログラミングにハマるプログラマのスレ 119
11:01:43 up 52 days, 12:00, 0 users, load average: 7.21, 7.09, 6.86
in 1.9086241722107 sec
@1.9086241722107@0b7 on 060900