◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:WPF(.NET, WinUI) GUIプログラミング Part26 ->画像>1枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1624176258/ ヒント： 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やらなくてもいいのにプライドが高い老害が多いんだろうな
どっちかというと、
XAMLが特級のクソなだけだよ
クソだと思うなら関わらなきゃいい
>>5 でもHTMLやXAMLよりむしろ便利なことも多いが。
HTMLから入った人は、それが母国語の用になっているので、WinFormsやSwing
まぁ、宣言的な記述が受け入れられなくて、なんでも逐次的・手続き的に処理されないと理解できない人は一定数いるね。
WinFormsが人気ある？
>>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はとてつもなく生産性が低いですね。
それWPFでも出来るんだができないと思ってるのかな
>>24 WPFの生産性が悪いのではなく
WPFのBlendフレームワークの生産性が酷いだけ
デザイナーとの協業など見たこともなし
>WPF化に5年も
>実際winFormsの生産性は非常に低い。
って言うかそんなにWPFの生産性が高いのであればとっくの昔に普及してるって。
>>28 言い訳が苦しすぎるww
vbおじいさん、winformおじいさんは勉強嫌いだろ。
生産性を高めようと思っていたらこんなものにしがみついていない。
WPFってSilverlightと同じく失敗productだろ
>>29 Silverlight時代からなんで
そこそこ普及はしてると思うが、
実装方法は糞評価だね。
早い段階でflutterに食われるでしょ。
ビヘイビアとコマンドなんてそんなものあったなあって感じ
俺もWinFormsからWPFに乗り換えた人間だが、明らかに開発は早くなったと感じる
まあWPFの良し悪しは置いておいても、マークアップ言語でのGUI構築には慣れておいた方が良いことは間違い無いと思う
WPF以降だとサムネイル表示とか一瞬で作れるもんな
>>10 jsとかの他のMVVMは確かにそんなもんつかってねーな
Livetやprism使ってありがたいと思ってたけどそもそもがそんなもん使わせるなよよｗ
割と最近になってMVVM Toolkit for .NET(Microsoft.Toolkit.Mvvm)なんて出してきた
べつにだれもマークアップ言語でのGUI構築にケチつけてないだろ
>>38 それに関しては禿同。
外部に頼る前提のフレームワークって何なんだよとw
MSが吸収したりしないもんかね
今更何を言おうが、WPFはメンテナンスモードなので未来永劫改善されることはない
WPF自体はそのままだけど
>>41 Microsoftの名前空間が付いたMVVMライブラリが出たし、これでいいでしょ。
WPFが普及しなかったのはWPFの出来とは関係ない
新規Windowsアプリの重要が急激になくなってwindowsアプリ作る人いなくなったのにWPFが普及しないとどうこういう以前の問題
Prismは6から7のときのだけ破壊的変更が有ったけど、それ以外のバージョンアップは後方互換性も悪くなかったけどな
>>43 VS2019が出るまで、我々はあのコンソール画面と睨めっこしながらバグを潰していたのか…
ｵﾞｪﾞｯ
業務アプリとかならWinFormsでもいいかもしれんけど、今風なおしゃれな見た目のアプリ作るとなるとWPFというか、WinUIになっちゃうからな
WPFは初期だけ盛り上がってしばらくしたら誰もいなくなった
>>50 俺はバックエンドがメインになって(Web含め)GUIアプリ自体仕事では全く作らなくなったな
画面作るのは好きだがツールに振り回されるのはアホらしいわ
>>46 スマホやWebのせいじゃなく、アメリカの独占企業たちが、検索エンジンやOS
やハードウェアで儲けた金で無料でプログラムを配りだして、彼ら以外に
はWindowsアプリ作っても一線も設けることができなくなったこと、
Blenderや無料Office、GRUB、Apache、gccなどのGPLな無料アプリの台頭、
などがあるのではないか。
AndoridやiOSはMSの息が掛かってなかったから、売れるチャンスがあった。
アプリ作っても無料アプリに負けることが多くなったと思う。
WPFで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軍団
ここの人たちはわかってるんだな
デスクトップの人はMAUIよりWinUI行くんじゃね？
ざむるか久しぶりだな
>>70 なるほど。
WinFormsのGUIパーツは、Win32のControlを使っているから、OSの
内臓コンポーネントであるC/C++で記述されている。
一方、WPFのGUIパーツは C#で作られているはずで、その速度はC#の
良い実例。それが遅いということはC#が遅いということ。
リフレクションを多用するアーキテクチャがそもそも遅い
このスレでバインディング遅いって書くとバインディング遅くないよマンがでてくるんだよなあ
>>77 むかし遅い遅いって現場で揉めて
外部のコンサルとか乱入してきて大変でしたよ
しかもそのコンサルは非.NET系の...
笑
UWPでコンパイル時バインディングx:Bind使っても速度的な違いわからねぇし、
>>73 flutterでFluent システムを実装してほしい
Material DesignをWindowsデスクトップで動かした時のデザインのダサさときたら..
>>79 何系よ？
MSC++,MFC,VB,JAVA,Delphi,BCC
最近は、そう遅くも感じない。
>>82 javaかな
最初はいろいろきつかったね
Winデスクトップオンリーなら.NET6 + WinUI + WPF
WINUIでどの程度パフォーマンス改善されるんだろ
>>66 XAMLはいいぞ(´・ω・`)Petzoldさんも本書いて勧めている
でもストアアプリはハードルが高い（特に個人で出す場合
ストアアプリは誰にもメリットなかったよね…
ストアのハードルは別に高くない。
UWPは
嫌うってより開発者としてではなく消費者としてどうなの??
20レスくらいさかのぼってみたけどUWPのセキュリティが嫌だって話をしてる奴はいなかった
>>94 UWPのセキュリティが嫌だ、なんて
>>93 にも書いてないよ
開発者が何を嫌ってようとセキュリティはUWPの方が優れてるからそっちを選べよって指摘だ罠。
まあ単体アプリを配布する分にはサンドボックスの有用性が生きるな
>>93 消費者としても受け入れらえなかった。
exeひとつを自分の好きな場所に配置して実行できる自由さには勝てない。
そもそもセキュリティのメリットを理由にUWPを入れたがる消費者なんてほぼゼロに近い。
会社だとストア無効化、サイドロードの設定も有効化できないようにされてるところが多いから
UWPは使い物にならない。
ストアの画面とか開くことすらないからストアに何があるのかすら知らないわ
UWPの問題は
ストアでインストールしたのはWSLくらいっすかねえ
Formsがオワコンかと思ったら.NET5で再び生き残ってるっぽい
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でもどれも互換重視で圧倒的シェア獲得してきたのに、
32bit CPU（32bit OS）サポート外とした、ってことでしょ。
64bitと言ってもAMDが作ったx86互換の64bitもどきだからな
バカだから無理だわ
>>133 「クラス名が長いから嫌だ」って…
まさかメモ帳で書いてるんじゃなかろうな
失敗プロジェクトの連続
本気で馬鹿しかいないと思うよ
VSCodeとか新生Edgeとか他所のフレームワーク使う時のMSは伸び伸びしとりますなあ
>>137 ブラウザはGoogleの露骨な妨害があったから泣く泣く断念した経緯がある。
どこも同じゃないの？
WPFを使うとプロジェクト全体の作業効率がアップするのか甚だ疑問だな。本当に良いものならもっと普及してる筈なのだが
ここ最近WPFが善か悪かの議論しかしてないよな
WPF : 記事数1,123, フォロワー625
>>117 MSは社内ですら方針統一できてないのがなあ
CairoやLonghornがコケた頃から何も変わってない
>>145 Windows Forms で検索すると、1513
WinForms:258
Forms:4412
WPF : 1903
Xamarinで検索: 1726
Qiitaではなく、Quoraだと、
Google Trendsだと、WPF,MFC,Flutter,Qtが互角くらいで、WinFormsとUWPは低迷。
Flutterは上昇中。MFC,WPFは徐々に下がってきている。
>>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リポジトリ数
githubは特殊性が有ると思う。
>>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
フレームワークにフレームワークが必要ってのは言語やプラットフォーム関係なく根っこが腐ってるからそうなるんだと思う
グリッドコントロール使うアプリケーションの大半はゴミだけどな。
>>162 伝票入力なんかは表イメージのまま入力できる方が喜ばれるんだよ
WPFでやるならグレープシティのやつとか使った方がいいけど
罫線付けたListViewでよくね？
>>142 昔は普及はまだかの話しかなかったが、
今はもう普及は絶望的なのに評価しても仕方ないよな
データグリッド使わなくて済むようにカスタムリストアイテム作れるようにしたのがWPFとXAMLでしょ
その普及普及って話がピンとこないんだな。うちの周りじゃ普通にみんなWPFなんだが。
UWPのDataGridは高速って話だが、WinUI３も期待できるんじゃね？
>>164 テスト用のアプリならStackPanelかWrapPanelに必要なコントロールをドラッグ&ドロップしていく大雑把なマウス操作だけで画面完成。
超簡単でそれでいて最低限のレイアウト変更に対応できてる。
“一度WPFを知ってしまうとWinFormsに戻りたくなくなる”ってよく言われるのは
それだけWPFの方が画面作りが楽ちんだから。
コードからWPF並みのレイアウトを構築できるだけのWinformsをくれ
イヤじゃイヤじゃC++なんて使いとうない
よし、Delphiを導入しよう
DelphiのVCLをコピったのがwinformなんだが。
誤解を与えたようなので説明しよう。
昔のホームページビルダーとかExcelみたいに作れればええやろ
>>185 そういえばDelphiはGUI部分が大人気で、その開発チームがMSに移って作った
のがWinFormsだったのか。
どうりでWPFより設計が美しく感じるはずだ。
後発でも駄目なものはダメなんだよ、ここの信者が何を言っても。
>>187 MFCよりもVCLのほうが断然使いやすかったもんな
C#の言語仕様部分に主にかかわってる。
@ahejlsbergには終わりかかってるような環境よりTypeScriptに注力してもらった方が世の中のためになる
reunionの名前が変わってる
Webを見ても、UI設計はマークアップ言語でやるっていうのが正解
WinFormの肩を持つ気はさらさら無いけど、あの時代はそれがスタンダードだったでしょ
マークアップ言語なら同じってのはウンコとショートケーキを同列に扱うがごときだよ
他のマークアップ言語と比べてXAMLが優れてるなんて誰も言ってないんじゃないか？
そもそも何が悲しくてマークアップ言語でUIを記述せなあかんのか
>>195 まあ、他のショートケーキ環境と比較してみればXAMLがいかにウンコかよくわかるかもね。それって例えばどれ？
データ記述言語としてのXMLもほとんどの用途はJSONに置き換わっとるし
Formsの臭いものに蓋をしたような裏のコードを見て
うだうだ言ってもWPFが普及しなかったという事は事実
普及するかどうかと優れたアーキテクチャかどうかは
ユーザー目線では遅い重い
古代UNIX時代のマークアップ技術をなぜ未だに引っ張り出さなあかんねん。
ウダウダと文句を垂れ流しておられる皆様方の理想のUI記述言語はどのようなものでございましょうか？
>>200 jsonでUI記述するC#Framewoek作れ
誤解されそうなので補足しとくが
それはちょっと語弊があるだろ
>>205 ユーザー目線:
WinForms:遅い・重い・応答なし・見づらい・使いづらい
WPF:速い・使いやすい
開発者目線:
WinForms:低機能・手の施しようがない・バグ地獄
WPF:必要なものが一通り揃っていて現代の開発に耐えられる
WPF程度を難しいなんて言っているレベルは転職をお勧めする。
趣味でやってる人だろ
>>212 技術者としてそういう捏造するようになったり終わり。人間のクズ。
>>204 優れていなかったから普及しなかったのでは？単純に
だよね
×優れている
>>216 MVVMでやろうとした時の教育コストがネックかな。
俺一人でやるなら問題ないけど、プロジェクトの都度人集めてやるような会社だときつい。
winFormsって重いの？
C++=Delphi > VB6 >>> WinForms >>Java Swing
>>215 逆。vbから続くwinデスクトップ界隈では優れている人の方が少ないから
低レベルな人でも使える低機能なものの方が普及しやすい。
>>218 それもWPFが普及しなかった要因。
必ずMVVMで作らなきゃいけないかのような圧力に
怯えて技術力の低い多数の人達が逃げ出してしまった。
まずはMVVM禁止で何個かプロジェクトやってメンバーの大半がWPFに十分なれてから次のステップに移ったほうがいい。
>プロジェクトの都度人集めてやるような会社
>>212 WPFの方が遅いと言うのを良く聞くが。
セレロン、MEM:2GBがノーマルお仕事環境だからな
>>218 選択肢が多すぎるのも欠点だよね
VBぐらい選択肢がないほうが同じ事の再教育しなくて済む
雑談スレじゃないのにここまで雑談で埋まってるスレは他にあるまい
WPFコントロール作ってるライブラリメーカーのガチプロは
>>231 そもそもMVVMってコントロールの内部で使うもんじゃないと思うが。
>>223 Windows Formsのグラフィックシステムでは、最終的な描画のタイミングをアプリケーション自身が握っているため、
描画途中でディスプレイ更新が行われると意図していない崩れた描画が表示されてしまうことがあります。
一方、WPFのグラフィックシステムでは、最終的な描画のタイミングはWPFの描画エンジンが握っているため、
意図していない描画がディスプレイに表示されることはありません。
そのため、大量のコントロールを高速でスクロールしても滑らかに表示できます。
>>231 プロジェクトの種類に応じて開発手法を選ぶのは当たり前。
MVVMを使うのは端的に言えば開発スピードを上げるため。性能を上げるためじゃない。
(真のガチプロはMVVM使いつつ性能も担保するかもね)
gdiとか完全排除してdirect2dに置き換えたら良いのに
2021年にもなってWinFormsにしがみついてる馬鹿がいるってマ？
MVVMで開発スピードを上げるってネタだろｗ
MVVMはともかく、高DPIとか要素のスケーリング対応はWinFormsでやりたくないな
Formsおじさんはスケーリングなんて概念知らないよ
スケールはマニフェストファイルにドットバイドットで起動するように
>>238 テストや仕様追加・変更などトータルで見てもかなり差が出てくるぞ
>>242 それぼやけるやつじゃないの？
それともレイアウト崩れる方？
>>234 コントローラー部品はMVVMのVの部分だからね
>>234 グラフ、ガントチャート、スケジューラーとか
一個コンポーネントだけでも
業務系アプリより小便チビるぐらいのガチの大規模アプリだぞ。
まあ開発者もCOMとかActiveX時代を経験しとる猛者だらけだが
まったく関係ない。規模が大きかろうがコントロールをMVVMで設計する必要なんてあるわけがない。
本家 Microsoft でさえ使っていないフレームワークだしな。Visual StudioのGUI部分くらいか？
MVVMで設計する必要が無いとは思わんが、
xamlのUI自体が起動時JITだししゃーない
>>244 ぼやけないし崩れないよ
ただしデメリットは4Kなどの高解像度ディスプレイを使っていると
ソフトを実行した時に文字やウィンドウが非常に小さく描画されると思う
場合によってはぼやけた方が使いやすいまであるかもしれない
>>248 グラフィックスデバッガのPIXとか現役で更新されてる小物じゃちょくちょく使ってる
COMをマスターできたならその後の新技術もキャッチアップできるだろう。
>>254 まあ難しいかもね
でもDCOMとかおもろいで
他人のPCにオブジェクトがnewできるwww操作もwww
>>251 スケーリングを無視して拡大せずに表示って
スケーリングから逃げてるだけで何の解決にもなってない
今時WinFormsやWPFで作られるようなアプリなんて基本的に決まった環境で決まった操作ができればいいだけなんだから画面の美しさなんて誰も問題にしない
>>240 海外サイトでは有用なサイトとかあるの？
>>258 逃げてるだけやん。
画面の美しさなんかどうでもいいが
見やすさ、操作しやすさは品質チェックされる。
フォントサイズぐらいは変えられるようにしといたほうがいい。
たいした手間じゃないんだから。
>>260 その「しといたほうがいい」程度のためにWPFやるの？さすがに費用対効果が悪すぎないか
そらみんなWebへ流れるわな
>>262 そりゃwebが要件に合うならそっちの方がいいけど
デスクトップでやらなきゃいけない場合、
winFormsは生産性もアプリの品質も論外だから現実的な選択肢の候補としてWPFは有力。
費用対効果はwinFormsなんかを選ぶよりはWPFの方がずっと上。
WPFよりwinformsがいいなんて言ってる奴いないのに何無駄なこと言い続けてるの？
WPFで作るだけで品質も生産性も向上、よかったよかったw
* WinFormsの方が優れてるよ派
彼はずっと頑張ってるんだけど
馬鹿はwinformsはスケーリングがっていうけど事実上使用環境は2k固定
他人がすばらしいと思おうが糞と思うがどうでもいいだろ
4Kモニター使う客は見たことないけど、13インチFHDノートとかでスケーリング150パーで使う客はざらにいる。
WinFormsはバグが多いみたいな話は聞いたが踏んだことないな
>>271 最近問題になってるのはFHDのノートPC＋老眼
拡大しないと見えないって言われるけどWinFormだとだいぶ面倒
老眼ならボケててもわかんねえしDPI Unawareでご提供じゃあ！
>>275 winformは仕組み的にバグを作り込みやすい。
SOLID原則に則った作りがしづらいから。
DataGridのヘッダの結合かベータ行カラムの分割をしたいんだけどxamlだけじゃできないんだねこれ
>>277 オーナードローに手を出すぐらいならWPF使った方が簡単だし楽だぞ
今時windowsアプリ作るならflutterでしょ
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を順守するには一般にレイヤの多い方が有利だから、むしろイベントハンドラの方がやりやすいまである
>>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簡単チュートリアルテンプレートないの
言語よりAccessのがいいんじゃね？
今時ローカルのDBなんて個人の小遣い帳にすら使い物になりません
>>315 なにいってんの
サーバーに接続して利用すんの
一時期業務系の開発でよく見られた方式よ
>>302 欲しいサンプルがさ、なかなか見つかんないんだよね
決め打ちできるほど選べないという・・・
その唯一見つかったサンプルたちが別々の書き方してると苦労する
自分はMVVMから学んで、あとでイベントドリブンを知った
>>304 > ひのきの棒
> 剣・槍・斧・弓の欲張りセット
> どっちかくれるって言うなら普通は後者を選ぶだろ?
ディスるつもりはまったくなくけど、
なんか喩えがよろしくない気がする
どっちかくれるって、それは学習コストも含めて言ってる？
使いこなせること前提なのかな？
コンビニに行くのにヘリコプターは要らないでしょ？
WPFは使ってみて手に馴染まなかった
>>319 徒歩しか選べないのと、ヘリコプターも徒歩も選べるのは全然違うよ。
WinForms的作り方でWPFを使えばいい。
バインディングもほとんど使わない。
それなら学習コストはほとんどかからない。
柔軟なレイアウトシステムとか
スタイルによるコントロールのプロパティ一括指定とか
学習コストが低くて便利なところだけつまみ食いすればいい。
結局邪悪だったのは
>>318 あとはもう書籍に頼るしか無いな
WPF関連の参考書は古いのばっかりだけど
WPF自体があんまり進化してないから2010年くらいのでも結構参考になる
取っ付きにくい→普及しない→資料が無い→
>>318 そりゃ酷い
普通こんな変態的なコード書かないよ
同じMSでもBlazorのMVVMの方がまともだ。
プロも考えてるなら
js覚えてReactとかやってみたら？
仕事多いよ。
>>304 実際には、WinFormsが少し前の高級車で、WPFは、バックカメラを
搭載した軽自動車みたいな感じだろう。
速度が違うし、どっちがいいとも言えないような状態。
>>325 もとい。
バックから見たいな画期的なものはWPFには付いてない。
せいぜい、短波ラジオが追加された軽自動車みたいな印象。
WPFってWindowsメッセージドリブンなアプリを作れないよね
>>325 実際にはWinFormsがリヤカーでWPFがステーションワゴン
WinFormsは、レンブラントやミケランジェロの作品の様に万人から一定の評価を
いつまでWinForms vs WPFやってんの
10年以上続けてる習慣にいい加減にしろだって！？
>>320 やってみようかなという気持ちと
そっちの道も蛇の道では、または
それならWinFormsでいいんではないかという気持ちがある
WPFの扱いをユーザー側でどうこうするより、
MS側でバインディングを簡素化してくれた方が嬉しいかな
自分が知ってるOSSでWPF使ってるのはEDCBぐらい
>>322 ここ3年ぐらいで出版されたのを一冊買ってある
アマゾンで高評価だった奴
でも、欲しかった情報とちょっとズレてるんだよね・・・
もちろん有用な情報もあったけど
>>324 > js覚えてReactとかやってみたら？
あら、今、正にそこ
そうだね、その方向性で行こう
今ならWindows Runtime系の本でC#バージョン新しめのやつ探したほうが良い、あるのかは知らん(´・ω・`)
マジか。WPF今から頑張ろうと思って色々調べているけど
今WPFを使う必要に迫られているのではなく将来を考えて勉強しようとしているなら、
今ネイティブアプリを作る理由は鯖を用意しなくて良いぐらい…
ネイティブアプリで自前ブラウザーを構成し、
>>339 趣味なら良いんじゃない？
慣れれば使いやすいから
フリーランスとかで案件が欲しいんだと微妙
>>339 WPFのxamlは多機能すぎるしとりあえず最低限でもいいから適当にやればいい
ただ、MVVMは他でも使ったりするからこっちを重点的にやればいい
俺が勉強した時は最初はxamlに深入りしないで他でもいきるMVVMの方に力入れてモチベーションを維持した
MVVM技術は袋小路で他に流用できないし思想も実装によって違う
MVVMが向いてるのは個人などの小規模アプリ
andorid開発でもDataBinding+MVVMだし
>MVVM技術は袋小路で他に流用できないし思想も実装によって違う
MVVMは基本、単に責務ごとにMとVとVMに分けて、オブザーバーパターンで状態変化通知して、xamlみたく組み込みのデータバインディングあればなおさらいいてだけじゃん
MVVMは副作用がわかりにくいので更新順序などで結果が違うなどバグの温床になる
むしろMVVMのV差し替えで別フレームワークに切り替えた実例見たことないけど何かある？
誰もさすがにコード共有までは言ってない
MSもMAUIではMVU採用したみたいだけど
>>353 そういうこともあるけどナレッジが蓄積されるとバグのパターンと修正ポイントがすぐわかるようになる
大昔イベントドリブンの黎明期にも同じような事が言われて
古参が「ほらやっぱり逐次制御で書かないと分かんなくなる」と騒いだけど
その時も同じように解決されていった
たぶんだけどmauiのMVUっても二つに分けてかんがえないと
.NET MAUIでUIがxaml使わずにコードで宣言的にUIかけるように
なっても、UIのイベントをどこに流すかでMVVMにもほかのMVホゲホゲの何かにもなるし
ただそれだけ
俺が
>>350 のjetpack composeでやろうとしてることと同じ
想像だけどね
React Nativeはオワコン、PWAも手を出す価値なし？
VMとMをバインディングするからいろいろイビツになったり複雑になったりするんだと常々思う
いや違わない
変更即時反映のUIって最近流行りじゃん、スマホでもWebでも最近ではWindowsの設定画面でも
>>364 ごめん
読み間違えてた
コードビハインドの件は同意
あれはBlendでポトペタするため
>>365 optimisticなuiって奴か？
俺あれ嫌いや
ああ違う
DataGridのColumnHeaderのボーダーがCellのそれと比べてほんの少し右にズレてるのは仕様？
>>369 仕様 回避コード書いてるサイトあったな
>>365 変更即時反映が悪いわけじゃない。
直近で変えた項目の色を変える、設定変更のアンドゥをできるようにする等
いくらでも改善できる。
設定を他人に伝えるとき即時のほうがありがたい
>>371 仕様か
昔の立体Win32スタイルの名残でズレてるってことなんだろうな
>>373 大体、そういう説明が理解出来ない人は低IQか初心者。
慣れた人には適用ボタンが有った方が便利で安心。
Windowsは少し高IQな人に向いている。
モバイルは万人向けなので、普通IQや低IQの人が使える様になっているが、
むしろ機能としては不便になっている。
既存のモデルにコンソールのガワを被せるためにMVVMを採用
個人的にはせっかくバインドする仕様にしたんだから、デフォルトをリアクティブに寄せれば良かったのにと思う
>>376 典型的な低IQ無能プログラマ。
そんな甘ったれた考えだといつまでたっても底辺から上がってこれないぞ。
>>379 何か作り方おかしくないか？
UIそのものやUIフレームワークを除外した残りがモデルなんだから。
>>381 ReactiveUI+乱立してるMVVMフレームワークから1つ決めて公式実装にしてほしいわ
というかぶっちゃけAvaloniaの方向性で良いので、買収して開発リソースぶちこんでくれ…
>>383 それがUIの都合で汚染されるのがイヤだって言う話
>>374 変更即時反映がUXとして後退と主張するから違うと指摘したまで。
例えばVSCodeの設定UIはデフォルトから変えた部分は印が付く。
>>376 みたいな人間がUXを語るべきじゃないな
感性も腐ってそう
開発者のエゴイズム丸出しでいかにもWPF好きらしくていいじゃん
WPFって見た目がカラフルでもUIデザインの基本的なプロトコルはクラシックなWinアプリのままなんで、
>>388 バインディングの都合を満たすのはVMの仕事で、Mの独立を保つ為に犠牲になる係でしょ？
しかし、Modelの一部をINotifyPropertyChangedやReactivePropertyに変えるなど
INotifyPropertyChangedなんてWinFormでも使うだろうに
>>394 手間の問題じゃなくて
なんでUIフレームワークの都合でモデルをいじらなきゃならんのかって話
WPF使う場合はやはりモデルから対応しなければならない
>>394 なんで
INotifyPropertyChanged
ReactivePropert
みたいのがmodelにあんの？(;´д｀)
MVVMで作ればINotifyPropertyChanged実装しなきゃいけないのはUIとバインドするViewModelだけだぞ
つか、要件としてModelをObservableにするならUIフレームワーク関係なく
そのへんフィールドをプロパティにするだけで全部やってくれてたらもっとユーザー増えただろうな
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の仕組み乗っかるの??
>>406 だからバインディングはVVMまででいいって言ってんじゃん
これでいいじゃん。using追加してAnnotation付けるだけだよ
https://www.reactiveui.net/docs/handbook/view-models/boilerplate-code [Reactive]
public string Name { get; set; }
まあ他の言語の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>
ここからまたプロパティで書くべきかどうかみたいな話になるのだろうか
>>404 実はWPFでもstaticだけはObservableの実装無しでいけたりします。
なのでModelの直バインドも可能です。
更新はコントロールを強制再描画すれば良い。
case: WPF(static only)
<TextBox Text={x:static viewModel.value1}/>
なんでView-ViewModelのバインディングの事例を並べてるの?
person.Nameみたいなのにバインディングされていて
だから、「WPFも同じことできてWPFも当てはまる」から
>>417 ,
>>419 全部間違っているっていってんのに
何いってのお前？アホ？？
ちなみにWPFの場合は
<TextBox Text={Binding Path=viewModel.value1}/>
>>428 その通り
>>402 をうけての
>>403 だから、
「変更時に通知をする仕組みを一切実装する必要なくフレームワーク側で全部かってにやってくれる
」ようなこと
>>403 が言い出すからそういうフレームワークがあるならあげろっていってんのに
なんでどれも変更時に通知する仕組みを実装する必要あるフレームワークあげてんだよ
変更通知しないなら、WPFだって
>>429 で書いたようにINPC実装する必要ないしそんなフレームワーク
を挙げろっていってない
person.Name見たいのはいつ変更したかなどはわかりやすいが
とりあえず、
やったじゃん
まぁ「俺の言いたいことを理解してくれない奴」は多いよな、いつでも。
>>変更時に通知する仕組み
MをPOCOで作りたがる人いるよね。通知を実装するのも嫌がる。
個人的には
>>440 それは世界の常識
WPFのMがおかしい
>>442 いや、WPFのMもPOCOで作るのが常識。
ふーん
Modelで変更通知なんかしない。
>>447 Modelの変更はどうやってViewModelやViewに反映されるの?
PODのようなものと混同してんのかな。
>>449 Reduxならプロパティ変更イベントは必要ないよ
>>451 例じゃなくて仕組みを知りたい
VM側からポーリングでもしてるの
M自身が能動的に処理を行うことは無い。
VとVMで1つのプロジェクト（UI担当）
>>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寄りの処理だよね
>>464 ルーティングの責務をM自体ではなくその外で持つことで、M自体を汚さなくて済むようになった
メタ情報を外出しするという点ではEFのPOCOなんかも似たような仕組みだな
>>462 フレームワークはMが更新されたことをどうやって知るの？
>>466 ああ、わかったただのMVVMの変種か
今までだって、MVVMで作ってた時はModelでimmutableなのをあったけど、
イメージとしてModelを全部immutableにして、ViewModelのほうに全部押し込めって話か
極端な話Modelを全部immutableにして、後のつじつまあわせは全部ViewModel(Store)で全部やれってことww
負荷が全部ViewModel(Store)にいくってことじゃね??
今までだって例えばMVVMでTwitterアプリを作るとき
だからそもそも今までだってどこのModelか知らんが(A)の部分は汚染されてないけどな..
もちろん、Modelをmutableにしてもいいけど、ViewModel(Store)内でModelを直接更新するからModelの変更通知機能は全く必要なくて、更新後ViewModel(Store)がViewに状態が変わりましたよって通知できればいい
mvcやらmvvmやらに全てあてはめようとして考えて、
>>470 これが何も知らない新人君でもやる普通の実装なんだがな
>>470 そうすると複数のビューで一つのモデルを参照しているようなときは
ひとつのVMだか何だかが複数のビューと対話するん？
オブザーバーでも
>>470 それは間違いだよｗ
VMにM更新のロジックを書くなよとｗ
VMごとにロジック書いて不整合があってバグ発生するだけ
VMからMにはメッセージのみ送る
WPFで本気でMVVMやりたいならMに通知もみんな書くんだよ
>>479 >WPFで本気でMVVMやりたいならMに通知もみんな書くんだよ
MVVMの話でいいならそれはrigaya?が勝手に言ってるだけだぞ
別に正解の定義なんてないだろうしどっちが正解とは言
言わんが
Modelのメソッドは結果を返さず、メソッドの呼び出しの結果、自身の状態(プロパティ)を変更するだけってやつだろ
フレームワークの方法論は
違うよ
馬鹿が自分が馬鹿でないと思って偉そうに何年もクソコードを書いてMVVM最高と言ってるだけだ
>>484 うがやじゃなくてお前ともう一人が馬鹿なんだ
やっと理解できましたじゃねーよ
modelとviewModelの責務分けは
外人でrigayaと同じ主張してる人見たことない
Modelで通知をするのが普通とか言ってるのはお前が勝手に思ってるだけ
>>481 でMVVMを本当に作った人が特定できるならまずそれを特定してくれ。で、Modelで変更通知を実装するのが普通ってどこに書いてあるか教えてくれ
もちろん、ViewModelはビューの状態を保持し、Modelに対してはModelのメソッドを呼んで
フレームワークつかうと
>>478 「メッセージのみ送る」と「いじる」の違いはこいつの頭の中にしか無いんだろうな。
MVVMでViewModelの責務は
>>488 なだけ
Modelが変更通知を実装するしないかは関係ない
MVVM黎明期、rigaなんとだけが日本で声上げたからあいつの馬鹿信者が増えたんだろう
しかも日本だけ笑い
だから
>>362 で最初からバインディングはVVMまででいいって言ってるじゃん
何をそんな喧嘩腰で議論する必要があるのか
“model” と “view、viewModel” の開発者は
>>492 バインディングの話じゃないって分かってない？
>>494 え？変更通知なんだから要はバインディングの話でしょ？
例えば、ModelがImuutableでINPCを実装しないとするよ。で、Modelの更新はModelのメソッドを呼んで、
もちろん、MVVMの厳格な定義なんて知らないし、極論すれば言葉の問題になるから
悪いけど売られた喧嘩で言わしてもらうが
>>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を操作すると通知が飛んで画面更新通知を自分でしなくて良いところ
>>512 これは自分がホームラン級のバカと気づいていないバカ
オブザーブバブルコレクション使ってモデル読み込むだけだよね
VMVもUserControl以外全部Xamlにしてバッチグーなローコードだ
昨日の話を一人で長文書いて続きやろうとしてる必死さが笑える
一人でINPCって言ってる馬鹿が勝手にコテンパンにされてるだけだろう
>>514 オウム返しするだけじゃなくてちゃんと反論してくれ
あおり合いじゃなくて議論が見たい
凡俗法則って言葉知らんかったわ
この外資系社員が凡俗法則を説明してんだが、例に出してるコイツ自身の資料がダメだわ
https://www.daijob.com/crossculture/takashi/20120207.html UIへの変更通知と
数量、単価、金額のプロパティがあるとしてどういう実装する？
>>531 基本的な.NETのオブジェクトだけで構成されているもの。
そこは気にしなくていい。
View→UI
ViewModel→UIフレームワークの都合上必要な部分
Model→その他全部
これだけ覚えておけば十分。
POCO : Plain Old CLR Object
Model層へのアクセスは RESTful API で行う事が最近は多いとおもうから、
>>529 素でこういう人が多いんだろうなあと思う
でもPOCOをラッピングしてPropertyChanged付けるとVMになるんですよね？
>>529 こいつ一人が馬鹿なんだ
いい加減にあきらめろよ
>>528 >>534 一番の馬鹿はこいつ
お前のやってる業務の現場の話じゃないWPFの話をしてるのにどんどん話をすり替えていく
土方業務話をしたいならどこかよそでやれよ
まだ恥の上塗りを繰り返すの？
ここには誰も味方はいない
WPFのモデル層へのアクセスをRESTful API でやってるやつを教えて欲しい
>>542 もう恥の上塗りはやめなよ
モデルのソースがWebAPIって話でしょ
なんでWPFのモデル層の話をしていたのに
>>544 なんで分からんのやろ？
ものすごいバカの壁を感じる
>>545 そちらが馬鹿の壁を超えられないサルだからだろ
WPFのモデル層は他のフレームワークのようなPOCO（単なる入れ物）としてコーディングするだけでは通知が抜けており
MVVMの本来のメリットを享受できないという話だったのに
なぜかwebAPI使ったりロジックをVMに書いたりする話にすり替わっている
WPFではVMでロジック書いて通知が一般的だと言われても納得する人はいないんじゃないの？
旗色が悪くなると相手が理解できないと勘違いして業務の話を出してドヤってるけど誰でもわかるわ
負けられない病にかかってるのかもしれないけど
>>528 MVVMアプリ的にはクライアント・サーバーのやり取りなんざまとめてMの範疇だろうに
そこの実装がプッシュだろうがポーリングだろうがどうでもいい話
POCOがあったらそこになんちゃらRepositoryやらなんちゃらServiceがあるわけじゃん
なんでPOCOとDTOをゴッチャにしてんだ
MVVMのMには当然DTOが内包されるよね
>>534 >実際は POCO は DTO と同義で用いられる事が多いかな。
そう思ってる人と正しく使ってる人とで話が噛み合ってない感じだよな。
あのさ
>>528 は例えば特に
>>495 対するレスで、単にUIとは関係ない一般的な
通知論を言っただけで、
>>541 の言いたい事を否定してるように見えないんだけど
むしろ君の味方だと思うんだが、
>>541 は全員敵に見えてるの??
ああ、ごめん俺が間違ってたww
>>555 エコシステムの話をしてるんじゃなくてWPFアプリの話をしてるので
MVVMのMをWPFアプリでどう実装するかが論点なのよ
一応はWPFなりMVVMなりを前提として話してるもんだと思ったらまさかのUIは関係ない宣言
いや、やっぱ
>>556 取り消すわ
やっぱ、
>>528 は単に
>>495 に対するレスにしか見えないな
>>557 論点はそこにあると思うけど
>>528 は通知の一般論話しただけかもしれん
俺は土曜日までは会話に主な論点わかってたけど
だってWPFと関係ない話になってんだもん
VMに相当する部分にビジネスロジックをガッツリ書くのはアプリ設計としてありだが、それはMVVMじゃないな
>>547 は最悪の性格だと思うww
>>528 に勘違いでぶきちれてる
>>565 そんな設計はもうViewModelなんて言葉を使うべきじゃねえわ
MVCでもMVVMでもないどころか関心の分離すら無視した全く別の何かじゃん
どんなプログラミングパラダイムを採用しようと
変更を通知するサービス
通知機能のあるMをVMのObservableCollectionでVに公開すると
>>571 何とは?
MVVMの役割のことを言っているのあれば、どれでもない
Mの中で使用される機能と言うだけ
Amazon SNS（Simple Notification Service）は、
>>570 >しかしモデルにUIのための通知機能を入れた途端にそれは破綻する
そこに依存性逆転パターンを使うのが常套手段。
>>572 Collectionの要素に変更があるのを監視する必要がなければそれでOK
別に反則じゃないと思う
今日は勝ちたい病のVMにビジネスロジック実装する君は来てないの？
こないと
>>547 の馬鹿みたく関係ない人攻撃しだすからなww
自分がそれで見られるからって
ロジックはコマンドに書いてるけどコマンドってVMの仲間じゃないの？
>>585 原理主義通すならその通りなので止めた方が良い
大規模プロジェクトで規約作る段階とかならあなたの言う通り
そうでないなら工数とのバーター
そういやコレクションでもしっかりVM挟めって人がWPF出来て直ぐの頃は言う人いたよな
なんか人によってVMの定義が違うのかねぇ？
>>589 ListViewなどでも、内部的にListViewItemのDataContextにコレクションのアイテムがセットされるから何も変わらないよ
それにVM挟めというやつが昔はわりといた
ビジネスが破綻する大半の原因は、 ”ビジネスを始める人の大半が、真の意味での
>>590 それは問題なくて、逆にDataContextと関係ないものまでVMと言っている人がいるような気がしたんで。
>>593 それでも0.5と違ってreunion0.8は、そこそこ安定しているよ
なんでtextblockってこんな中途半端に作ってあるのかな
ｒｉｃｈtextboxの上下のスペースなら気になった
>>601 1.0が出てから触ってみるつもりだから分からん。
UWPが見向きもされなかった欠点が解消されてるなら移行するし、
駄目ならWPFとWinUIのミックスになるかもしれない。
基本的にGUIはUWPが基本でほんの一部異なる程度
俺はカラー絵文字が普通に使えさえすればもうWPFで十分なんだけど
備品管理のために配置図作成プログラムを作るために下の二つを使いたい
マップ描画用
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パターンで実現するときのネックは、逆方向への操作を綺麗に実装出来るかどうか
doに新しい状態でundoに古い状態を入れたらいいんでしょ
Undo可能クラスも実装出来んの？
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を試した。
xamlはhtmlと同じようにタグをエディターで入力するしかないって気づいたところから使えるようになっていったな
タグ書いて完璧な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版、死亡。
コード簡略のためにawait 使いまくってるサンプルが世に広まってるのが良くないのかね(´・ω・`)
MahAppsでGUI作っていたけど今更Metro(Modern) UIというのもアレなんで
>>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を使うのが一番簡単だと思うね
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パターンを使ったレシピがネットに転がってなくて困る。
旧版にあたる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 こっちは見た事ないからちょっと勉強させてもらいます。
こういうの見て正義に成ったと勘違いして
>>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は従来のWindowを幾つも開くタイプのアプリじゃなくて、1つのフレームにページを読み込むWebページのような動作をするアプリに最適なアーキテクチャで
うん、あんまり関係ないね
>>689 あなたが苦労して作ったのは大半が MVVM 部分じゃなくて
MVVM + α の α の部分
VMのプロパティとXAMLのプロパティ(Text="Hello World"のTextがプロパティ)をバインディングして組んでいくのがWPFのMVVM
個人ツール作るだけだと設計が自由でDIで困るような事態にならないので
とにかく楽してMVVMしたい人向けならCaliburn.Micro一択
>>694 自分それだわ
バインドバインドぉ！mvvm？こんなのでいいの？動くからおｋ
ReactivePropertyでVM作るのパズル組んでるみたいで楽しい
viewのイベントを全部vmで拾えれば楽なのに
bland用のframeworkを
MVVMでイベントが使いたいときはMicrosoft.Xaml.Behaviorsを使おう
>>699 慣れたらReactivePropertyは手放せない罠
Prismはそれほどでもない
ReactivePropertyはナシだな
ReactivePropertyやPrism相当のものをMicrosoftが用意しないのがダメすぎる。
っ Microsoft.Toolkit.Mvvm (MVVM Toolkit)
これ来るの遅すぎた
>>705 多くのオープンソースライブラリが使えなくて大変な職場だねー
まあガチガチな所はそうでしょう
リスクがあるのは事実だからねえ
>>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 っていうデザイナーアプリが同時期にリリースされていて
Prismは元々MSが作ったサンプルコード集で、MSがメンテを終了しコミュニティに移管された
皆さん、ありがとうございます。
>>719 一応、MS公式と考えてもいいんですね。
他のと比較すると軽量らしいですね。
>>720 なるほど、勉強になります。
ちなみに、そのBlendのドラッグ＆ドロップでUIを設計出来る機能は
Microsoft.Toolkit.Mvvmに引き継がれていそうですか？
>>721 へぇ、Prismも元々はMS製だったんですね。
それなら標準に入れてほしかったですね…。
同じ運命を辿るなら将来性はありますね。
勉強してみます。
>>724 VS 使わなくなって長いからわからんね
VS 使えれば、Blendもライセンス的に付属していたとい思うので、
試してくださいな
デスクトップアプリとウェブアプリ一緒にしてるあたり理解度低そうだな
Electronしたいけど
Blendはそのうち消えるだろ。
JavaアプリケーションとJavaアプレットは同一で作れたんじゃ
>>725 BlendはVSに抱き合わせで入っていたんですが、速攻で消しました（笑）。
Microsoft.Toolkit.Mvvmでできるか試してみます。
Microsoft.Toolkit.Mvvmを覚えるには、今の所Windows Template StudioというVSの拡張を入れてから
>>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オブジェクトをデリゲートに変換できないのかな？
>>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使ってるけどwindow開いていってるわ・・・
本質というか、周回遅れすぎる感じ
WPFの周辺技術にオワコンでないものなんて存在しないんだから好きなの使えばいいよ
WPFとUWPオワコンなの気づかずにまた2つを合体させようと頑張ってるMSってなんか哀れだよね
WPFとかUWPとか関係ない
まぁ、win11でandroidアプリの実行環境が用意されるから、もうこうやってアプリ増やすしかない
そもそもソフトウェア自身が儲けにくくなってきてる気がするよ。
Wordの新機能なんて興味ないから全く知らないんだが
今時Windowsのソフト開発なんてほとんどがB2Bでしょう
C#でWeb系やるとしたらASP.NETしか無いですか？
>>765 そういう会社もあるかもしれんけど、たとえば奉行なんか使っている大多数の企業はなってない
>>767 大手、中堅どころの企業なら
システム開発はほとんどWebだよ
業界の人なら営業が持ってる案件表見てみるがいい
もしクライアントアプリがそこに有るとすれば
スマホ位しかない
大体運用やメンテナンスし辛いクライアントアプリとか
情室が嫌がる
業務系のエンジニアなら
C#はクロスプラットゲーム向けと、
デスクトップアプリからWebに移ってまたデスクトップに回帰する流れもあるところはあるけどな
WebやるならVueがWPFに似てるから良さそうだな
業務系の開発現場にいたらわかるけど、
ReactかSvelteかな
>>774 “MVVMで色々変なクラス捏ねくり回してやろうとしてたのは”
過剰なまでの疎結合だよ
意味的にもMVVMとはちと違う指向
そういえば、１年位まえに期間限定で（３カ月〜半年？）b
Web系はガキのお遊び感があるからな。
flutterも数年かなという印象やな。
Googleだけでも、少なくとも Go, Kotlin, Dart の3つの言語作ってしまったし。
どれか一つの言語だけに集中させないことにはどうにもならないということ。
Cはまだ、どの言語からも呼び出せる方法が存在していることが多いし、また、
>>773 購買や経費管理といった、昔ならクラサバでやっていたような「業務システム」は10年どころか
20年くらい前からWeb化されていたけど、業務で使うソフトウェアってそればかりじゃないわけで。
そのへんは業種業態によって変わるだろう。うちはメーカーだけど内製のツールはまだまだ
スタンドアロンが多いな。つか、そういうのはわざわざWeb化するメリットも少なかったり。
>>768 うちはパッケージ屋が本業だからうちのパッケージしか案件表にないんだ
すまんなｗ
けど大手企業とかもいまだにパッケージ頼りのところ結構あるぜ
比率は知らんけど
確かに、パッケージ屋は個別業務開発とは趣きが違うから想像はできるけど、
クラウド化が何を指してるのか分からんが
>>780 Kotlinはgoogleじゃないような
Formsなのですが、FileStreamで一つのファイルの更新って難しいですか？
>>790 ありがとうございます！
一時ファイルを複製して対応します
試してないけど読み込み側FileStreamのコンストラクタでFileShare指定すればいいんじゃないの
>>792 ありがとうございます
何かできそうな気がします！
StreamReader/Writerのコンストラクタに渡せん？（あんま覚えてない
つうか、
読み込むファイル自体に、書き込む香具師は、頭おかしい。
追記されていくだけのログとかならFileShare.Readつけても大丈夫だけどな
>>795 元ファイル削除しないで新規ファイルをリネームで上書きできない？
>>803 Xamarin.Formsの発展形がMAUIなんだし、xamlが基本になるんじゃね？
XAMLもIntellisenseで自動で埋めてくれんかな
d:DataContext="{d:DesignInstance ...
VS2022でマウスポインタを上に載せたら型が表示されたけど
>>809 スニペットddc使えよ
ちゃんと補完するぞ
>>809 UWPとWinUIのx:Bindはインテリセンス効くよ
終わったプラットフォームと始まる前のプラットフォームの話してるやつなんなの？
署名なしの野良配布で開発モードONはなしで、
名前を変えただけの悪名高きxamarinに何を期待してるんだか
Xamarinと違って一からMSが開発するから期待してる
>>814 じゃあ終わってないプラットフォームの話して。
このスレで扱うのが適切な、始まっててかつ終わってないプラットフォームって実は存在しないのでは？
MSのコードプラットフォームの主力がVSCodeに移ってもう長いし、
>>810-813 ♪あ〜〜〜〜〜〜り〜がと〜〜〜〜う
♪あ〜〜〜〜〜〜り〜がと〜〜〜〜う
XAMLでIntellisenseできました
スニペットでddcも行けました
UWPとWinUIはまた今度で
このスレ見てる時点でWindowsに絞ってる人間なんだから先にあるのはMAUIじゃなくてWinUI 3だよね
>>821 WPF。
UWPは始まりもしないまま終わったけどな。
MAUIとWinUIって開発工程においてはどれくらい違うの？
XAMLの
>>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を参照してソフトを開発しているのですが、
>>829 全然違いました。
>>830 訂正、ありがとうございました。
それを使います。
>MicrosoftのWin UI 3はUWPを捨ててWin32に集中
>>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あるけど
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なんかより、ひたすらイベントパンドラで書いた方が見通しもいいし実は修正もしやすいよ。
Caliburn.MicroならPropertyChangedBaseが実装済み、例を示すと
>>851 それを実装した汎用valueクラスを作ってそれを使う。
>>858 それが当たり前だよね。
完全にMVVMするのが目的になってしまった
なれのはて
>>857 VMの書き方はだいたい同じだが、Viewでx:Bindが使えるからインテリセンスが効くし型のチェックもコンパイル時にやってくれる
あと、Viewから右クリックの「定義へ移動」でVMの変数定義に移動できる
しょぼいプログラムほどMVVMでの実装も楽だからINotifyPropertyChangedを避ける理由がよくわからない
バインドしない人は文字−数値の変換も自分で書くの？
>>860 VとVMの分離はべつにデザイナーとの分業だけが目的じゃあないが。というか重要度としては低い。
WPF知らない人にありがちな典型的な誤解。
いまだにMVVMに親を殺されたようなのがいるね
いや、知ってるからなんだけど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は馴染まない。
ちゃんとフレームワークに合った設計をしないと。
君にはすべてのクラスに
言っている事は正しいしただの指摘、煽りではないだろ
>>885 >FormsにMVVMは馴染まない。
お前の感覚以外にちゃんとした理由があるならぜひ
理由もクソも、MVVMはそもそもWPFのデータバインディングを活用するために考案されたデザインパターン
やったこと無いけどFormsでもデータバインディングできるんじゃ？
>>890 Forms+ReactivePropertyで双方向バインディングやってるけど
業界アキーテクチャ的には
react等の先端frameworkに比べると
実行ファイル(.exe)が出力できて将来性のある
最先端はなんだろうAvaroniaとか？
>>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に対応して、
>>911 なんかFormsでMVVMできないことにするために適当な理屈をウダウダ後付けで言ってんな
>>912 今はokazukiがメインメンテナ？
彼がやめたら俺がやるわ
>>913 極力簡易記述できるようにしてると思うよ
MVVMはXAMLやFXMLといったマークアップ言語があって初めて実現する
ObservableCollectionで個々のItemのPropertyChangedを取りたいときって、
>>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.
>>931 バインディングが単なる手段に過ぎないという意見は分かった
で、
>Formsで真似しても似て非なるもの。
はどういうことなんだ？
お前の言う真のMVVMとはどういったものなんだ？
滅茶苦茶な機械翻訳を鵜呑みにして混乱してる初心者あるある
Microsoft Silverlightがオープンソース化、「OpenSilver」ベータ版リリース
https://news.mynavi.jp/article/20210916-1974193/ >>938 MSはどっち行きたいねん？
一つがっちりしたのを標準で出せや！
Silverlightは救済策だろう
ActiveXじゃなくてWASMベースになったってのが興味深いな。
ソースジェネレーターでバインディング周り上手い事オーバーヘッド無しに出来んかな
>>939 まだわからんの
オープンソースだよMSは
>>944 タイトルが悪いと思う
オリジナルのSilverlightをMSが作ったってだけで、MSはほぼ無関係だな
UserwareがWebAssemblyで動作するようにSilverlightを実装しなおしたものをオープンソースでリリースしただけ
Userwareって会社ね
お
>>945 タイトルが悪いと言うかわざとだろ、これ
UserwareがMicrosoftからソース譲渡してもらったならわかるけど "reimplementation of Silverlight" だから要するに互換ソフトをオープンソースで作ったって話でしかない
あれ？
>>949 画面をXAMLで書けるのがWPFの一番のメリットなんだが
XAMLは筋の悪い技術だよ
XAML Styler必須だよな、なぜVisual Studioに標準搭載しないのか
ループって何言ってるか分からんがリストのことならコレクションバインディングするだけでしょ
ObservableCollectionとListViewをバインドするだけとちゃうの？
>>951 画面をXAMLで書けることの何がメリットなの？
>>952 禿同
Viewと分けるにしても、XAMLなんか使わずにコードでいいじゃんね
>>950 >>954-955 スマソ、確認だけど、
XAMLで出来ること ＝ コードビハインドで出来ること
なん？
すべての機能が一対一で相互互換性あるの？
別にMVVMは強要されてる分けじゃない
MVVMじゃなくてxamlか
メリットは宣言的なところ
>>960 全然答えになってない
XAMLでやってることすべてをコードビハインドで出来るのかって訊いてる
>>961 コードでうまいこと宣言的にできないもんかね？
>>963 目的と手段が逆転してるぞ
そのためにXAMLがあるんだろうが
ReactのあれはReactだけのやり方だから好きじゃないな
>>962 何でそんな失礼なん？
全部できるかどうかなんて証明でいないわ
MSに訊け
>>956 ・画面イメージそのままに階層構造で表現できるからXAMLを見ただけで画面イメージを把握できる。つまり画面デザイナが無くても困らないからVSCodeでも開発できる。
・diffで差分を確認しやすい。
・スニペット登録しておけばEmmetみたいに爆速で画面作成できる。
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#コードより速くなるよ
>>984 それは単純ケースだけじゃ？
MSの公式のパフォーマンス改善の手引きに
バインデイングを止めるようにとあったと思うが...
とにかく俺のプロジェクトじゃ
双方向バインディングをやめてOneWay等も使えって書いてあった気がする
WPFのBindingは全部レイトだから遅いのは宿命だわな
とにかく、
WPFはバインディングよりも描画が重かったイメージだな
>>985 逆だね
単純なケースでは生xamlでも速いのでbamlの利点が生きてこない
VisualStudioで描画が重いと思ったことないので（軽いと思ったこともないけど）
WPFそのものにはポテンシャルは十分にあるんだろう
ただWPFみたいた終わったテクノロジーでそんなレベルの開発者集められるのはそれこそVSの開発チームくらいだろうね
>>982 そういう複合コントロールはユーザーコントロールで作るからデータの出し入れは依存関係プロパティーを使いMVVMは使わず
処理もコードビハインドに思いっきり書く
で、出来たものをページなりウインドウに貼り付けて使用します
x:bind 速度の違いが全くわからないので使うのやめた
>>993 WPFは遅くて同時は叩かれましたよ
そのあと改良されて大部分巻き返しましたが
同時かなり高度な描画デバックキットがリリースらされましたので
それを駆使して対処してましたが
XAMLとバインデイングから
どのようなコードが生成されてるのか
予測が付かなくて
地獄見ましたよ
つかさ、winuiもいいんだけださ
>>990 WPFにはx:Bind無いので直接比較はできんけど
UWPで同じようなもん作ったとき、Binding連発してるところで
WPFだと頻繁に見られるタメみたいなのがなかったね
まじで?
このスレッドは１０００を超えました。
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
ID:s2SIGsrqのレス一覧： 今時ローカルのDBなんて個人の小遣い帳にすら使い物になりません
>>315 なにいってんの
サーバーに接続して利用すんの
一時期業務系の開発でよく見られた方式よ
>>302 欲しいサンプルがさ、なかなか見つかんないんだよね
決め打ちできるほど選べないという・・・
その唯一見つかったサンプルたちが別々の書き方してると苦労する
自分はMVVMから学んで、あとでイベントドリブンを知った
>>304 > ひのきの棒
> 剣・槍・斧・弓の欲張りセット
> どっちかくれるって言うなら普通は後者を選ぶだろ?
ディスるつもりはまったくなくけど、
なんか喩えがよろしくない気がする
どっちかくれるって、それは学習コストも含めて言ってる？
使いこなせること前提なのかな？
コンビニに行くのにヘリコプターは要らないでしょ？
WPFは使ってみて手に馴染まなかった
>>319 徒歩しか選べないのと、ヘリコプターも徒歩も選べるのは全然違うよ。
WinForms的作り方でWPFを使えばいい。
バインディングもほとんど使わない。
それなら学習コストはほとんどかからない。
柔軟なレイアウトシステムとか
スタイルによるコントロールのプロパティ一括指定とか
学習コストが低くて便利なところだけつまみ食いすればいい。
結局邪悪だったのは
>>318 あとはもう書籍に頼るしか無いな
WPF関連の参考書は古いのばっかりだけど
WPF自体があんまり進化してないから2010年くらいのでも結構参考になる
取っ付きにくい→普及しない→資料が無い→
>>318 そりゃ酷い
普通こんな変態的なコード書かないよ
同じMSでもBlazorのMVVMの方がまともだ。
プロも考えてるなら
js覚えてReactとかやってみたら？
仕事多いよ。
>>304 実際には、WinFormsが少し前の高級車で、WPFは、バックカメラを
搭載した軽自動車みたいな感じだろう。
速度が違うし、どっちがいいとも言えないような状態。
>>325 もとい。
バックから見たいな画期的なものはWPFには付いてない。
せいぜい、短波ラジオが追加された軽自動車みたいな印象。
WPFってWindowsメッセージドリブンなアプリを作れないよね
>>325 実際にはWinFormsがリヤカーでWPFがステーションワゴン
WinFormsは、レンブラントやミケランジェロの作品の様に万人から一定の評価を
いつまでWinForms vs WPFやってんの
10年以上続けてる習慣にいい加減にしろだって！？
>>320 やってみようかなという気持ちと
そっちの道も蛇の道では、または
それならWinFormsでいいんではないかという気持ちがある
WPFの扱いをユーザー側でどうこうするより、
MS側でバインディングを簡素化してくれた方が嬉しいかな
自分が知ってるOSSでWPF使ってるのはEDCBぐらい
>>322 ここ3年ぐらいで出版されたのを一冊買ってある
アマゾンで高評価だった奴
でも、欲しかった情報とちょっとズレてるんだよね・・・
もちろん有用な情報もあったけど
>>324 > js覚えてReactとかやってみたら？
あら、今、正にそこ
そうだね、その方向性で行こう
今ならWindows Runtime系の本でC#バージョン新しめのやつ探したほうが良い、あるのかは知らん(´・ω・`)
マジか。WPF今から頑張ろうと思って色々調べているけど
今WPFを使う必要に迫られているのではなく将来を考えて勉強しようとしているなら、
今ネイティブアプリを作る理由は鯖を用意しなくて良いぐらい…
ネイティブアプリで自前ブラウザーを構成し、
>>339 趣味なら良いんじゃない？
慣れれば使いやすいから
フリーランスとかで案件が欲しいんだと微妙
>>339 WPFのxamlは多機能すぎるしとりあえず最低限でもいいから適当にやればいい
ただ、MVVMは他でも使ったりするからこっちを重点的にやればいい
俺が勉強した時は最初はxamlに深入りしないで他でもいきるMVVMの方に力入れてモチベーションを維持した
MVVM技術は袋小路で他に流用できないし思想も実装によって違う
MVVMが向いてるのは個人などの小規模アプリ
andorid開発でもDataBinding+MVVMだし
>MVVM技術は袋小路で他に流用できないし思想も実装によって違う
MVVMは基本、単に責務ごとにMとVとVMに分けて、オブザーバーパターンで状態変化通知して、xamlみたく組み込みのデータバインディングあればなおさらいいてだけじゃん
MVVMは副作用がわかりにくいので更新順序などで結果が違うなどバグの温床になる
むしろMVVMのV差し替えで別フレームワークに切り替えた実例見たことないけど何かある？
誰もさすがにコード共有までは言ってない
MSもMAUIではMVU採用したみたいだけど
>>353 そういうこともあるけどナレッジが蓄積されるとバグのパターンと修正ポイントがすぐわかるようになる
大昔イベントドリブンの黎明期にも同じような事が言われて
古参が「ほらやっぱり逐次制御で書かないと分かんなくなる」と騒いだけど
その時も同じように解決されていった
たぶんだけどmauiのMVUっても二つに分けてかんがえないと
.NET MAUIでUIがxaml使わずにコードで宣言的にUIかけるように
なっても、UIのイベントをどこに流すかでMVVMにもほかのMVホゲホゲの何かにもなるし
ただそれだけ
俺が
>>350 のjetpack composeでやろうとしてることと同じ
想像だけどね
React Nativeはオワコン、PWAも手を出す価値なし？
VMとMをバインディングするからいろいろイビツになったり複雑になったりするんだと常々思う
いや違わない
変更即時反映のUIって最近流行りじゃん、スマホでもWebでも最近ではWindowsの設定画面でも
>>364 ごめん
読み間違えてた
コードビハインドの件は同意
あれはBlendでポトペタするため
>>365 optimisticなuiって奴か？
俺あれ嫌いや
ああ違う
DataGridのColumnHeaderのボーダーがCellのそれと比べてほんの少し右にズレてるのは仕様？
>>369 仕様 回避コード書いてるサイトあったな
>>365 変更即時反映が悪いわけじゃない。
直近で変えた項目の色を変える、設定変更のアンドゥをできるようにする等
いくらでも改善できる。
設定を他人に伝えるとき即時のほうがありがたい
>>371 仕様か
昔の立体Win32スタイルの名残でズレてるってことなんだろうな
>>373 大体、そういう説明が理解出来ない人は低IQか初心者。
慣れた人には適用ボタンが有った方が便利で安心。
Windowsは少し高IQな人に向いている。
モバイルは万人向けなので、普通IQや低IQの人が使える様になっているが、
むしろ機能としては不便になっている。
既存のモデルにコンソールのガワを被せるためにMVVMを採用
個人的にはせっかくバインドする仕様にしたんだから、デフォルトをリアクティブに寄せれば良かったのにと思う
>>376 典型的な低IQ無能プログラマ。
そんな甘ったれた考えだといつまでたっても底辺から上がってこれないぞ。
>>379 何か作り方おかしくないか？
UIそのものやUIフレームワークを除外した残りがモデルなんだから。
>>381 ReactiveUI+乱立してるMVVMフレームワークから1つ決めて公式実装にしてほしいわ
というかぶっちゃけAvaloniaの方向性で良いので、買収して開発リソースぶちこんでくれ…
>>383 それがUIの都合で汚染されるのがイヤだって言う話
>>374 変更即時反映がUXとして後退と主張するから違うと指摘したまで。
例えばVSCodeの設定UIはデフォルトから変えた部分は印が付く。
>>376 みたいな人間がUXを語るべきじゃないな
感性も腐ってそう
開発者のエゴイズム丸出しでいかにもWPF好きらしくていいじゃん
WPFって見た目がカラフルでもUIデザインの基本的なプロトコルはクラシックなWinアプリのままなんで、
>>388 バインディングの都合を満たすのはVMの仕事で、Mの独立を保つ為に犠牲になる係でしょ？
しかし、Modelの一部をINotifyPropertyChangedやReactivePropertyに変えるなど
INotifyPropertyChangedなんてWinFormでも使うだろうに
>>394 手間の問題じゃなくて
なんでUIフレームワークの都合でモデルをいじらなきゃならんのかって話
WPF使う場合はやはりモデルから対応しなければならない
>>394 なんで
INotifyPropertyChanged
ReactivePropert
みたいのがmodelにあんの？(;´д｀)
MVVMで作ればINotifyPropertyChanged実装しなきゃいけないのはUIとバインドするViewModelだけだぞ
つか、要件としてModelをObservableにするならUIフレームワーク関係なく
そのへんフィールドをプロパティにするだけで全部やってくれてたらもっとユーザー増えただろうな
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の仕組み乗っかるの??
>>406 だからバインディングはVVMまででいいって言ってんじゃん
これでいいじゃん。using追加してAnnotation付けるだけだよ
https://www.reactiveui.net/docs/handbook/view-models/boilerplate-code [Reactive]
public string Name { get; set; }
まあ他の言語の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>
ここからまたプロパティで書くべきかどうかみたいな話になるのだろうか
>>404 実はWPFでもstaticだけはObservableの実装無しでいけたりします。
なのでModelの直バインドも可能です。
更新はコントロールを強制再描画すれば良い。
case: WPF(static only)
<TextBox Text={x:static viewModel.value1}/>
なんでView-ViewModelのバインディングの事例を並べてるの?
person.Nameみたいなのにバインディングされていて
だから、「WPFも同じことできてWPFも当てはまる」から
>>417 ,
>>419 全部間違っているっていってんのに
何いってのお前？アホ？？
ちなみにWPFの場合は
<TextBox Text={Binding Path=viewModel.value1}/>
>>428 その通り
>>402 をうけての
>>403 だから、
「変更時に通知をする仕組みを一切実装する必要なくフレームワーク側で全部かってにやってくれる
」ようなこと
>>403 が言い出すからそういうフレームワークがあるならあげろっていってんのに
なんでどれも変更時に通知する仕組みを実装する必要あるフレームワークあげてんだよ
変更通知しないなら、WPFだって
>>429 で書いたようにINPC実装する必要ないしそんなフレームワーク
を挙げろっていってない
person.Name見たいのはいつ変更したかなどはわかりやすいが
とりあえず、
やったじゃん
まぁ「俺の言いたいことを理解してくれない奴」は多いよな、いつでも。
>>変更時に通知する仕組み
MをPOCOで作りたがる人いるよね。通知を実装するのも嫌がる。
個人的には
>>440 それは世界の常識
WPFのMがおかしい
>>442 いや、WPFのMもPOCOで作るのが常識。
ふーん
Modelで変更通知なんかしない。
>>447 Modelの変更はどうやってViewModelやViewに反映されるの?
PODのようなものと混同してんのかな。
>>449 Reduxならプロパティ変更イベントは必要ないよ
>>451 例じゃなくて仕組みを知りたい
VM側からポーリングでもしてるの
M自身が能動的に処理を行うことは無い。
VとVMで1つのプロジェクト（UI担当）
>>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寄りの処理だよね
>>464 ルーティングの責務をM自体ではなくその外で持つことで、M自体を汚さなくて済むようになった
メタ情報を外出しするという点ではEFのPOCOなんかも似たような仕組みだな
>>462 フレームワークはMが更新されたことをどうやって知るの？
>>466 ああ、わかったただのMVVMの変種か
今までだって、MVVMで作ってた時はModelでimmutableなのをあったけど、
イメージとしてModelを全部immutableにして、ViewModelのほうに全部押し込めって話か
極端な話Modelを全部immutableにして、後のつじつまあわせは全部ViewModel(Store)で全部やれってことww
負荷が全部ViewModel(Store)にいくってことじゃね??
今までだって例えばMVVMでTwitterアプリを作るとき
だからそもそも今までだってどこのModelか知らんが(A)の部分は汚染されてないけどな..
もちろん、Modelをmutableにしてもいいけど、ViewModel(Store)内でModelを直接更新するからModelの変更通知機能は全く必要なくて、更新後ViewModel(Store)がViewに状態が変わりましたよって通知できればいい
mvcやらmvvmやらに全てあてはめようとして考えて、
>>470 これが何も知らない新人君でもやる普通の実装なんだがな
>>470 そうすると複数のビューで一つのモデルを参照しているようなときは
ひとつのVMだか何だかが複数のビューと対話するん？
オブザーバーでも
>>470 それは間違いだよｗ
VMにM更新のロジックを書くなよとｗ
VMごとにロジック書いて不整合があってバグ発生するだけ
VMからMにはメッセージのみ送る
WPFで本気でMVVMやりたいならMに通知もみんな書くんだよ
>>479 >WPFで本気でMVVMやりたいならMに通知もみんな書くんだよ
MVVMの話でいいならそれはrigaya?が勝手に言ってるだけだぞ
別に正解の定義なんてないだろうしどっちが正解とは言
言わんが
Modelのメソッドは結果を返さず、メソッドの呼び出しの結果、自身の状態(プロパティ)を変更するだけってやつだろ
フレームワークの方法論は
違うよ
馬鹿が自分が馬鹿でないと思って偉そうに何年もクソコードを書いてMVVM最高と言ってるだけだ
>>484 うがやじゃなくてお前ともう一人が馬鹿なんだ
やっと理解できましたじゃねーよ
modelとviewModelの責務分けは
外人でrigayaと同じ主張してる人見たことない
Modelで通知をするのが普通とか言ってるのはお前が勝手に思ってるだけ
>>481 でMVVMを本当に作った人が特定できるならまずそれを特定してくれ。で、Modelで変更通知を実装するのが普通ってどこに書いてあるか教えてくれ
もちろん、ViewModelはビューの状態を保持し、Modelに対してはModelのメソッドを呼んで
フレームワークつかうと
>>478 「メッセージのみ送る」と「いじる」の違いはこいつの頭の中にしか無いんだろうな。
MVVMでViewModelの責務は
>>488 なだけ
Modelが変更通知を実装するしないかは関係ない
MVVM黎明期、rigaなんとだけが日本で声上げたからあいつの馬鹿信者が増えたんだろう
しかも日本だけ笑い
だから
>>362 で最初からバインディングはVVMまででいいって言ってるじゃん
何をそんな喧嘩腰で議論する必要があるのか
“model” と “view、viewModel” の開発者は
>>492 バインディングの話じゃないって分かってない？
>>494 え？変更通知なんだから要はバインディングの話でしょ？
例えば、ModelがImuutableでINPCを実装しないとするよ。で、Modelの更新はModelのメソッドを呼んで、
レス：1-200 201-400 401-600 601-800 801-1000 ALL
このスレへの固定リンク： http://5chb.net/r/tech/1624176258/ ヒント： 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プログラミング Part32 WPF(.NET, WinUI) GUIプログラミング Part27 プログラミングにはMacやLinuxが良いって言うけど具体的に何が良いんだ？慣れ親しんだWindowsを捨てる価値あるのかよ？ WPF(.NET4.x, .NET Core) GUIプログラミング Part24 WPF(.NET4.x, .NET Core) GUIプログラミング Part23 MenuetOS 64bit版 アセンブリ言語 プログラミング Windows Azure プログラミング 総合スレ2 Gtkプログラミング on Windows！！！ ［エディタ一つ］Windowsで無料プログラミング WindowsならVisual StudioのC#が1番素晴らしいよな、新参の新しいプログラミング言語とか要らないんだよ 【朗報】Switch「はじめてゲームプログラミング」 ユーザースコア9.8点www プログラミング業界に異変、SwiftとJavaが不人気、スマホアプリ開発までJavaScriptという時代に 結局プログラム作るのってWinとLinuxどっちがいい？ プログラミング言語 Kuin Part 16#01 俺「プログラミングの勉強するか」 教材「i = i + 1」 俺は諦めた お前らプログラミング言語どうやって覚えたんや？ [転載禁止]©2ch.net (635) 【Lisp】プログラミング言語 Clojure ＃4【JVM】 [無断転載禁止]&＃169;2ch.net (89) プログラミングにはMac OpenMPプログラミング OCIプログラミング 自動プログラミング プログラミング飽きた 雑談 プログラミング プログラミング始めたいんだが プログラミングをしたい件 プログラミングを教えてくれ 七行プログラミング part6 プログラミングにはMac 未来のプログラミング言語 プログラミングをやりたいんだが プログラミングで何か書く プログラミングを教えて下さい Webプログラミング出張所 プログラミング始めたいんやが プログラミングにおける偉大な発明は？ 競技プログラミング総合スレ 65 プログラミング言語、次は何を学ぶ？ プログラミングを始めてみたい ニート、プログラミングを学ぶ ゲームのプログラミングできる人募集 Macでプログラミング{11} なんJプログラミング＆電子工作部 プログラミング始めようと思う 線形代数ってプログラミングに使う？ 初心者向けのプログラミング言語 プログラミングを勉強したいんだけど プログラミング言語ってなにがいいの！？ AIプログラミングでIT業界人員削減 安価でプログラミングの教科書を作るスレ 今日のプログラミングスレ プログラミング言語 Rust 3 男向けのプログラミング言語 プログラミング始めたいんやが プログラミング詳しい奴ちょっとこい プログラミングでの武勇伝語ろうぜｗ お前らとプログラミングの勉強したい プログラミングしか趣味がなくてワロタ プログラミングに自信あるやつきて プログラミングの勉強始めようと思うんだけど Q# 【量子プログラミング】 プログラミングがわからなすぎる プログラミング超初心者の質問 就職以外でプログラミングで稼ぐ方法 UNIXプログラミング質問すれ Part10 職業訓練校プログラミング終了後
02:22:34 up 12 days, 17:44, 2 users, load average: 82.67, 78.05, 70.00
in 0.078141927719116 sec
@[email protected] on 110416
ブックマークへ