WPF(.NET, WinUI) GUIプログラミング Part28
レス数が1000を超えています。これ以上書き込みはできません。
WPF(Windows Presentation Framework)について語るスレ。
前スレ
WPF(.NET, WinUI) GUIプログラミング Part27
https://mevius.5ch.net/test/read.cgi/tech/1632044619/
関連スレ
Windows 10 UWPアプリ開発Part 3
https://mevius.5ch.net/test/read.cgi/tech/1627556967/
コードを貼る場合は以下のサイトの利用をお勧め。
https://ideone.com/ ご安心ください！
.NET6のサポートが切れる3年後まではサポートされます MVVMだとアプリを簡潔に書けるが、WinFormsのような設計でも書けるのがWPFやWinUIだ
WinFormsに留まる理由が何もない MVVMポリスがWPF捨てて最先端のWebやってるのに俺達は10年前から全然前に進んでないんだな… ■ WPFなプログラマの環境
オブジェクト指向、DRYを常に意識
関心の分離（MVVM/DI）
CI/CD環境構築して自動テスト
バージョン管理はGit
OSSライブラリを積極的に採用
非同期処理やRxを使用しUXや応答性を向上
設計書作成にUMLやWikiを活用
ITSで課題管理
開発マシンはミドルスペック以上
コミュニケーションの基本はチャット
業務時間内に自主勉強OK
それなりの給料
■ Winformsなプログラマの環境
手続き型、コピペコードが大量に存在（WET）
関心の集約（コードビハインドにビジネスロジックベタ書き）
テストは手動＆目視で結果チェック
バージョン管理はSVN
自社ライブラリ以外は使用禁止
UXに無頓着、asyncなにそれおいしいの？
パワポで設計書作成
Excelで課題管理
開発マシンは低スペック
コミュニケーションの基本はメール
自主勉強？業務時間外にやってね
薄給
こんな印象 WinUIで1ネタ。
WinUI 3 Controls Galleryを起動して
おもむろに aa と入力してEnter。
これだけで落ちる。 こんなけレス来てるのに内容は喧嘩だけ
Wpf使えないって主張はわかったから別でやってくれ >>8
立ち上げた直後に虫眼鏡マーク押すとそうなるね
AutoSuggestBoxのイベント処理がバグっているだけだから、WinUIじゃなくてアプリのバグだな winformもwpfも新しい環境に適応できなかったあるいは必要がない奴の墓場
winform使ってるやつは自覚してる分マシでwinformよりwpfのほうがマシとか言ってるやつは正気なのかよ >winform使ってるやつは自覚してる分マシで
たまにこういう全能の神が現れるな WPF使えないって主張してる人なんてほとんど見ないが
WPF使える主張と使ってない人を下に見下すやつは結構見るがな そうか？WPF使える自慢なんて誰もしてないだろ。
機能的に不満はいくつかあれど、消去法で一番ましなのがWPFだから仕方なく使っているって奴が大半だと思うが。
期待のWinUIも酷すぎてSDK 1.0は見送り確定だし。 >>15
WinUI+RustがVSで安定的に使えるようになったらWPFから移行するつもり
そういうやつ多いんじゃね？ このスレの住人は未だにデスクトップアプリの主流がVC++という現実を受け入れるべき 何を言ってもまともなWPFアプリが無い時点で説得力がないのよ >>15
WinUIって1.0は言うほど酷くもないんだけどね
確かに0.8までは使い物にならなかったが、今のものは表示系に不具合は目立つけど
動作自体は割と安定している
同じxamlでもWPFと微妙に違うところがあるから、そこで躓いているのかな？ ここでいくら吠えてもサジェストがこれじゃな
wpf 普及しない
wpf サポート終了
wpf 将来性 2021 ElectronやFlutterはダメなん？
XamarinはWPFの代わりにならなかったのか？
WPF使ってるならXamarinに行っても良さそうな気がするんだが サジェストで分かる通りWPFと同じレベルのクソですわ
xamarin サポート終了
xamarin 将来性
xamarin オワコン
xamarin 後継 MSですらElectronでVScode作ってるからなあ
といってもここまで肥大化するとTSで作るのも辛そう
となるとflutterがいいのか！？
flutterのデスクトップアプリって何があるんだ？ WPFよりBlink＋V8のほうが圧倒的に速いからね
Electronのが自由なアーキテクチャで開発効率もいいし
もうWPFの存在意義が無いのよ(笑) WPFで書くことが自己目的化して取り残されたおじさん達のスレと化してるのは否めない >>27
デスクトップアプリはWindows95から今までC++一択だぞ
C/C++書けないアホ共がC#に逃げてるだけで C++が使いこなせるエンジニアが簡単に集められれば苦労しないわ >>30
一応C++は使える(完璧ではないけど使う分には)
でもこれといったGUI系がないからC#でやってる
Win32 APIで組めるけど、OOP的なものじゃないからめんどくさい >>29
なんでもWebWebって言っちゃう人がまさにそれだね。 意味不明だな
何の制約もなく自由にどんなクラスでも作れるだろ
フレームワーク無いと何も出来ない赤ちゃんかよｗ >>34
米32について？
そういう意味じゃなくて、車輪の再発明的なことになるし
本処理ならいざ知らず、それ以外のButtonクラスとかを作ること自体に時間をかけるのが…
一クラスだけならいいけどガチでやるとWindow,Button,TextBox,…果てにはListView,TreeViewもそれぞれオブジェクトにしないといけないし
オレオレstringクラスを作るよりもデフォであるstd::stringを使う方が無難だし >>35
それを面倒に思うならプログラミング向いてないよｗ
独自コントロール作るのは普通のことよ
手間省きたきゃサブクラス化という手もある >>34
正解
そこまでやると、アプリ開発じゃなくコンポ開発に路線変更した方がいいな
今もテキストエディタつくりながら、コンポ開発して売ったりしてる人twitterに一人いるわww 35の続き
別に自力でWin32 APIでやってもいいけど、「家を作るためにハンマーを自作する」みたいなことになるから…
それならいっそOOP的発想の外部ライブラリで組んだ方がまし
でもそれらも情報が少なすぎるとかライセンス関係が面倒とかで…
だからC#で >>40
技術力低いのは否定しないけど、どの辺が低いと感じるの？
後学のために聞いておきたい 向いてる方向が違えばツールも変わってくるのは当然なんだよね
B2Bの業務システムだとコアには技術を結集してそれこそC++まで使うかもだけど
末端のGUIアプリは大量生産になるから底辺VBプログラマも居る
これはどんな大企業がやっても起きうること
そんな中で検討されるのがフレームワーク >>29
そんなやつはいないだろ。
C/C++しか使えない取り残されたおじいさん達のスレと化してるのは否めないがな。 入力値検証はINotifyDataErrorInfo使うのが一般的ですか？もっと良い方法があれば知りたいです。 >>23-24
利用者の立場からはそれぞれのOS用のネイティブの開発プラットフォームで作ってくれるのが一番ありがたい。
マルチプラットフォーム対応のUIフレームワークは開発者が楽をするために色々なものを犠牲にしているので。
Xamarinはどの環境向けでも使う価値なし。
モバイル向けなら今ならFlutterがベター。
Webは好きなの使って。（ただし元々メインのターゲットがあってWebにも対応しました的なやつは避けるべし。Flutter Webとか）
Windows限定かつWebが向かない領域ならWPF。 ものによるな
WPF製のブラウザやテキストエディタなんて実用に耐えないだろうし >>45
入力画面のxaml.csのボタンのclickメソッドに入力値検証のコードを書いて下さい。 >>49
バリデーションを微妙に高速化したところで体感で変わらんだろう イベント使うならTextChanged、ValueChenged等だろう キーストロークやフォーカス抜ける度に検証コードが走るのはレスポンスが著しく低下してユーザーのストレスになりますよ。 そこは要テストの部分だろう
条件が提示されていないのだから >>52
このスレでプロ1グラムの速度について議論するだけ無駄
WPFプログラマーはもっさりが当たり前の世界で生きてるから判断基準そのものが違うのよ。そもそも快適な状態を知らない
ユーザーから遅いレスポンス悪いと言われても「それがWPFだから仕方ないんですよ」で通用するヌルい世界で仕事してるから wtlとwpfだと
wpfのほうが家を作るためにハンマーを自作に近いよな 手間かかるけど高速ならわかるがもっさりなのがwpf。しかも保守まで困難。
開発意図が分からない残念すぎるGUIフレームワークだったよな。 家とかハンマーとか例えが問題の構造を捉えてなくて正直よく分かりません(笑)
ツールに踊らされてるのは滑稽ですね。何も考えず新しい物に次々飛びつく様がイナゴのようで。 >>57
新しいものに飛びつくのが滑稽ってどゆこと？
言語やライブラリ、フレームワークはあくまで技術に過ぎない
一つに固執してもそれが廃れるなりしたら何も残らない
考え無しならともかく、メリットがあるから飛びつく
VSで開発してるならwinformsとWPFの差はアレだけど、VSCで開発しているなら全然違う
新しい技術に飛びつくやつが薄っぺらいと思うのなら、コンピュータやスマホなんて使わない方がいいのでは？
それぐらい暴言でしかない 全然違う
今の環境でも60fpsと15fpsくらいの差を感じる WPFを理解せずに文句言ってるとバレてしまいますよ 【悲報】ID:g8UjYZ8eさん、WinFormsおじさんだった・・・ 【悲報】結局、ヘジおじさんが開発したwinformが最強だった・・・ >>52
どれだけ重い検証コード走らせる気だよw
本当に重い処理が必要ならそれなりの工夫をするだけだがWPFに限ったことじゃないな >>63
設計したというのは初耳。どこかにソースある？ >>40
えーと、相当技術力が低いと見える根拠…まだ…？
多少は根拠があるはずだから 【悲報】オワコンWPFさん、Electronに惨敗してしまう・・・
wpf: 52,379 repository results
https://github.com/search?q=wpf
electron: 87,360 repository results
https://github.com/search?q=electron viの使い方の解説や記事はいっぱいあるが
メモ帳の記事がないのと同じ理由だな。 react: 2,525,332 repository results
https://github.com/search?q=react
残念だけどこれが現実よ
もうWPFだのWinFormsだので争っている場合じゃないの >>36
今更で失礼だけど、もしかしてWindow用でWndProcコールバック関数、サブクラス化してbutton用にButton1Procコールバック関数…みたいにするってこと？
自分が言いたかったのはC++のクラスを組んでオブジェクトにすること
それとも、継承のことを言ってるの？
そうだとしても、サブクラス化とは言わない気がする…
自分の言い方が悪かったようだ >>76
Reactはオワコン。
誤ヒットを除外するとFlutterより少ない。 flutterはflutter webがダメそうなのががっかり ============================================================================
デスクトップアプリ最低要件（最低限これくらいは満たしてね）チェックシート2022
============================================================================
チェック用アプリ仕様:
ボタンをマウスでクリックしたらAlertメッセージ表示するだけのプログラム
(1)配布要件1：動作させるのに必要なファイル一式を任意の場所に配置して動作する
(2)配布要件2：管理者権限不要で配置できる
(3)配布要件3：動作させるのに必要なファイルが10ファイル以内に収まる ※1
(4)起動要件1：エントリファイルをダブルクリックして起動できる
(5)起動要件2：エントリファイルをPowerShellから起動できる
(6)起動要件3：管理者権限不要で起動できる
(7)起動要件4：ネットワーク切断状態（スタンドアロン）で動作する
(8)メモリ要件：
A：起動時の消費メモリが20MiB以内
B：起動時の消費メモリが40MiB以内
(9)ストレージ要件：
A：動作させるのに必要なファイルの合計が200KiB以内 ※1
B：動作させるのに必要なファイルの合計が1MiB以内 ※1
※1. OSにプリインストールされているランタイムは除く
============================================================================
(1)〜(7)はYesの場合+10, Noの場合は-100
(8)〜(9)はAの場合+10, Bの場合+5, その他は-100
合計点80以上が合格 >>52
それは常に同じ検証をするコードだからじゃないの？ >>86
>ボタンをマウスでクリックしたら
>>81
まあ一次審査としてはこんぐらい甘めの基準で雑魚をふるい落として残ったものの中でパフォーマンスとか生産性とか比較していけばいいんじゃないか? 世界で最も多くの人に使用されているデスクトップアプリ Google Chrome
(1)○ +10
(2)○ +10
(3)× -100
(4)○ +10
(5)○ +10
(6)○ +10
(7)○ +10
(8)× -100
(9)× -100
-240点で不合格でした >>87
テキストファイルのアイコンイメージをボタンにして、シングルクリックで開く設定にする >>89
開発プラットフォームのポテンシャルを見るために最小限の実装をしてるんだぞ。
それに何の意味があるんだ? 開発環境じゃなくて実行環境じゃね？
PEヘッダよりMZヘッダのほうが偉いのか？ >>90
挙げられたテストが開発プラットフォームのポテンシャルを測ることに適さないことを揶揄してる >>81
(1)〜(7)は一つでもNoの場合は不合格
(1)〜(7)が全てYesの場合は、(8)と(9)はどちらもBであっても合格
つまり、(8)と(9)は条件Aは不要でありBだけで良い
そうすると(1)〜(9)の一つでも満たさなければ不合格というシンプルな条件になる ==========================================================
デスクトップアプリ何で作る？
最低要件（最低限これくらいは満たしてね）チェックシート2022 rev.2
==========================================================
チェック用アプリ仕様:
アプリ上の"はろー"ボタンをマウスでクリックしたらメッセージボックスで"わーるど"を表示する
(1)配布要件1：動作させるのに必要なファイル一式を任意の場所に配置して動作する
(2)配布要件2：管理者権限不要で配置できる
(3)配布要件3：動作させるのに必要なファイルが10以内 ※1
(4)起動要件1：エントリファイルをダブルクリックして起動可
(5)起動要件2：エントリファイルをPowerShellから起動可
(6)起動要件3：管理者権限不要で起動可
(7)起動要件4：ネットワーク切断状態（スタンドアロン）で動作する
(8)メモリ要件：
A：起動時の消費メモリが20MiB以内
B：起動時の消費メモリが40MiB以内
(9)ストレージ要件：
A：動作させるのに必要なファイルの合計が200KiB以内 ※1
B：動作させるのに必要なファイルの合計が1MiB以内 ※1
※1. OSにプリインストールされているランタイムは除く
==========================================================
(1)〜(7)はYesの場合+10, Noの場合は-100
(8)〜(9)はAの場合+10, Bの場合+5, その他は-100
合計点80以上が合格ライン（当然点数は高ければ高いほど優秀） どう見てもレイルズくんの犯行だね
NGに放り込んでおこうと いまさらVS2008のwpfデザイナ触ってみたけど
今とは別物でとっつきにくいな
多少は進化しているようだ
WinUI3も使えるようになるまで何年かかるかな WPFねぇ。 XAMLもCSS使いの画面設計のように進化しないとね。
Styleプロパティーも少ないし、CSSデザインのように自由度か欲しい。
WinFormよりははるかにマシだが。 正直言ってwinformよりクソだな。普及しなくて当然としか。
wpf称賛してるPGってiPhoneを革新、便利だと称賛してた馬鹿と同じ臭いがする。 WinForms
・旧来のウィンドウズAPIの上にレイヤーを重ねたようなもので、（シンプルであるという）利点と
（平凡なレイアウトやスタイリングオプションという）災いの両方がある。
WPF
・WinFormsからわずか4年後にリリースされたが、デザインパターンとコンセプトがより複雑であったため、
一般に受け入れられるまでにはしばらく時間がかかった。
・大規模なデータセットに対してWinFormsよりも大幅に高速化できるが、正しく使用するにはより深い知識が必要である。
・現状は WPF on .NET 6 が一番つぶしが効く状態。
UWP
・Windows UIの未来だったが、鳴かず飛ばず、現在はメンテナンスモードになっている。
良い点：魅力的なUIを簡単に作ることができ、マウスとタッチの両方でうまく動作する。
悪い点：サンドボックスとパッケージングの要件が非常に厳しい。
結論：避けるべき。
WinUI 3
・小さなチームがUWPのUIスタックからできる限りのものを救い出そうとしている。
・遅い、バグが多い、そして多くの歴史的なお荷物が重くのしかかる。
・1年後にまた確認したいが、私は悲観的だ。 >>100
称賛まではしてないのでは
今あるWindows向けデスクトップアプリの中ではマシとかみたいな感じでは .netFramework4.8 +Winforms でしばらく様子見だな Xamarin取り扱いやってみるかと思ったらデザイナー画面が真っ白で、コントロール何を配置しても白い何かが置かれたことしかわからん状態
AndroidStudioの感覚で触って面食らった
バグなのか仕様なのかググッてもわからん
もう俺はダメなのか 流石にWinFormsはスレ違いだろ
俺たちはとっくの昔に先に行ってるんでね なぜにサポート切れ間近のxamarinに手を出そうと思った Xamarinについて調べてみたけど、サポート終了ってホントなんだな
マジでなんなんだこれ >>100
過去のいろんなスマホのUIを完全に駆逐したiPhoneは革新的で便利だろ
そう言うということは、当然スマホ使ってないんだよな？ >>101
WinUI3が遅いって一体何のことでしょうか？もしかして安定版使ったことないとか
それと言うほど酷いバグは見つからないけど、あるなら具体的に挙げて欲しい
検証してみたいわ Prismみたいなもんだろ
すぐ飽きてメンテされなくなる >>111
xamarinは元々はMSとは違う会社が作ってたものだし。
一時期xamlを統一しようとする動きはあったけど、
結局、それぞれのプラットフォームに最適化した結果だからこれでいいのだ、
ってことになった。 >>115
MVVM知らなくても使いやすいGUIは作れるし、
MVVM信者が作ったGUIアプリはなぜか操作性がクソだし。 >>122
具体的になんかある？
確かにMVVM信者がまともに動くアプリ作ってるの見たことない笑 >>122
個人的に、MVVMはtextbox1に入力された文字列をtextbox2に反映させる的な場合に使って、あとはコードビハインドでやるみたいな感じだな >>122
多分、MVVMで作ることが第一にあって、MVVMで作りやすい方にUIが引っ張られて使いづらくなってるw
1画面でページ切り替えするアプリケーションはMVVMで作りやすくて、
スマホアプリレベルの低機能なものならそれで事足りることもあるけど、
Window「s」デスクトップアプリケーションとしては強みをわざわざ殺すようなもの。 ？ MVVMなんて普通に使ってるだろ？
テスト駆動やドメイン駆動には必須だし、今やアジャイルで作る企業業務アプリの主流じゃね？ MV*は量産化のためのフレームワーク
どれだけ楽できるかはCaliburn.Microを試してみるといい、あれにはコンベンションといって
バインディングは自動、コマンド(アクション)もメソッドと紐付けてくれる仕組みが入ってる 要件と照らし合わせてMVVMで作った方がメリットが多ければMVVMにするし、メリットがなければMVVMは使わない。
思考停止して何でもMVVMなんてことはしない。 MVVMとか盲信してる下級プログラマーによくいるけど道具に踊らされすぎ。
最新技術を取り入れる俺カッコイイと思ってるのは本人ばかりで将来性無い知識に振り回され貴重な時間を浪費するアホ。
WCFやらEFなんて誰が使ってるよ？ >>131
UIが無いならそれでもいいが、そんなことはないだろ？
UIがあるならMVVM抜きにしてもWPFで作った方がずっと楽できる。 思考停止しなかったLivet(一時期流行ったMVVMライブラリ)作者はWebへ移りました MVなんかESP32組込みファームウェアでも導入しているぐらいなのに、リファクタリング考えればテストステップで進めるのに、GUIとモデルの分離は当然。
WPFに拘らずとも、今や必須スキルやがな。
バグ曲線とリリースコストの増大考えれば、当たり前。
大規模システムやったことないのか？ >>133
EF使わずにDataSetつこうてるの？ 今さらEFとかもうね、Dapperにしとけって俺口酸っぱくして言ったよね？ >>137
どっちも使わん
なんでわざわざ重くて不自由な足枷つけんねん
ドＭかｗ ウインフォーマーが何使ってるのか興味があっただけなんだけどな
StringBuilderてSQL書いたりさ 別件質問
Microsoft.Toolkit.Mvvmと
Community.Toolkit.Mvvmって
どっち使えばいいの？ >>136
UIとモデルの分離は当然なのはそうなんだが、それ＝MVVMじゃないぞ。
そんなことはWinFormsの頃から実践されてきたことだろ。 >>141
ウインフォーマー舐めるなよ。
CSVから構造体の配列に読み込んでForループで処理だ。
しかもVB.NET
>>142
Microsoft.Toolkit.Mvvm使っとけばOK.
Community.Toolkit.Mvvmは多分別名で中身は同じものな気がする。 また、MVVM 発作始まるのかよ
しつこいなおまえら
もう、他人がMVVMを上げようが下げようがどうでもいいだろ >>142
Microsoft.Toolkit.MvvmはCommunity.Toolkit.Mvvmの一部っぽい
> The Microsoft.Toolkit.Mvvm package (aka MVVM Toolkit) is a modern, fast,
> and modular MVVM library. It is part of the Windows Community Toolkit ... MVVMって呼ぶからWinFormおじさんが発狂しちゃうんだよ
バインディングって言えば大丈夫
バインディングならWinFormにもあるからネ！ >>122
>MVVM信者が作ったGUIアプリはなぜか操作性がクソだし。
MVVM信者とかリアルで出会う機会は少ないが、このサンプルは何人でアプリ何本くらいで判断した話？ WinUIだと他でCommunityToolkitの方のパッケージ使うことになったりするな 最初に要件定義して
・サーバークライアントかスタンドアロンか
・ターゲットはWindowsのみかクロスプラットフォームか
・言語はC#かそれ以外でもよいか
そんでスタンドアロン-Windows-C#ときたらWPFでいいだろ。 >>156
154(俺)宛て？
MVVMを擁護するつもりもないけど、単なる考え方だから関係ない気がする
固執するのも問題だけど みんなMはどう設計してるんだろ。
MVVMってVとVMについての設計パターンで、Mはそれ以外の領域。
だから普通は「MVVMパターンと〇〇パターンで作った」ってなるはずなんだけど、ここではあんまりそういう話が出てこないよね。 MVC は、PostgreSQLなどのデータベースを前提にしていると思っていたんだが、
MVVM もそうなの？ 個人の感想としては、RailsやDjango、LaravelなどでMVCを学んだが、
MVCを使ったからといってプログラムが分かり易くなるとは思えなかった。
むしろ、柔軟性を失ってめんどくさくなるだけではないか。 >>162
そうだよ
まあMVCと違ってクライアントアプリなんで、DB直結よりはWCFでサーバーサイドロジックをサーバーに出して分離するのがよりクールだとされていた
WCF廃止されちゃったけどね
基本的にゴリゴリのビジネスアプリケーションが前提だよ >>155
要件定義するような案件でスタンドアロンなんかほぼ無いでしょ
一般的なクラサバとスタンドアロンの定義と君の理解にズレがある気がするのだが、それぞれどういうものだと思ってるの？
ちなみに一般的な定義においては、世の中のWPFアプリケーションのほとんどはクラサバに属する >>166
別人だけど書いてみる
多分、複数人で利用してデータを管理したりする場合:
クラサバ >>166
ごめん 167は忘れて
間違って送信してしまった
多分、
複数人での利用で連携を取る:
クラサバ
ローカル環境に作用したりするだけの一括プログラム:
スタンドアロン
ってことかと >>166
要件定義の認識がずれてる気がする
> 世の中のWPFアプリケーションのほとんどはクラサバに属する
全く持って同意できないw 酷い…老害たちのゴミのような脳みその結果がこの日本の惨状なわけだ >>161
Mは何を対象にするかによって設計が変わるんだから一般的には話せないでしょ
VはWindowsでもWebでも一般的なGUIに対して共通認識があるからまだ設計条件を共有しやすいが >>161
>だから普通は「MVVMパターンと〇〇パターンで作った」ってなるはずなんだけど、ここではあんまりそういう話が出てこないよね。
何を話題にしたいのかにもよるけど、目線の違うパターン同士を絡めて語ることってあまりないんでは？
MVVM自体とMに用いるパターンは直交した概念だから、MはUIを持たないソフトウェアの設計論と同じに考えて
好きなように選べばいいかと。 >>158
起動も速いし、その他全体的に体感できるレベルで速い >>173
むしろMを完全にVと分離するためのVMだからね ＰｒｉｓｍのようなMVVMスイートには
・Event Aggregator
・DI
・ViewModel Locater
が３点セットで入っているから、それがMVVMのM(やVB)でよく使われるパターンじゃないかな？ >>176
全然違う
それらはいずれもレイヤ間のメッセージングや依存性解決の手段でしかなく、M層内での設計とは無関係 なお、MSによって発行された本来のPrismでは、Mというのは「WCFのクライアント」に他ならない
つまりリモートサーバー上に存在するWCFのサービスに対するラッパーだな
MVVMを使うのはあくまでフロント開発者であって、Mから先のビジネスロジックはフロント開発者が詳細を意識する必要すらない、
どこか別の場所にある完全にブラックボックス化された領域なんだよ 何それめっちゃ遅そうじゃん
所詮MVVMなんてその程度の浅い認識で考え出されたアーキテクチャなんだな
ゴチャゴチャ言ってるのは全部後付けで端から複雑なアプリには向いてない イベントアグリゲーターはVM同士でやり取りする時使うよ
匿名のボトルメールみたいな感覚だね、便利なんで使い方を覚えるといい M同士のやり取り？
そんなのはMの状態変化の結果として変更通知として各VMに降ってくるようにするのが筋でしょ まぁメリットが感じられないフレームワークも多いよね
MVVMフレームワーク、WCF、EF、ASP.NET MVC、各層に色々フレームワークはあるけどASP.NET以外は微妙
要求が高度なアプリほど
フレームワークの使用によって得る生産性＜フレームワークの束縛によって失う自由度
になってくる マイクロソフトのフレームワークが良くないのが多すぎた
MSなら安心という顧客や上司のために仕事でしょうがなく使うってシチュエーションしかない
結局不自由だからあれこれ回避するためにキメラのような実装になってフレームワークなんて使わないほうが良かったとなる ASP.NET APIぐらいかな？使えるのは
ここにEF入ってくると糞になるけど... EFはEF Coreや.NET 6で多少速度マシになってたりしないの??
まぁ、元々変更追跡する仕組みだから、速度面では不利だが 普通のアプリを作る場合には、Document・Viewアーキテクチャも、
MVCもMVVMも面倒なだけな気がする。
Win32のGDIも面倒。
OpenGLも、1.0は美しかったが1.2以後や、OpenGL ESやWebGLは汚く面倒に
なった。Direct3Dの駄目なところを取り入れてしまったような感じ。 この文脈ならkick-ass appsだろ
言わせんな恥ずかしい >未解決の問題が非常に多いため、何に取り組んでいるのか、どこで進歩しているのか
WinUI3、問題山積みって感じだな。
開発メンバーも離脱してごくわずかで細々作ってる感じだし。
MSも高確率で沈みそうな泥船に投資したくないんだろうなぁ。
Phoneが沈んだ時点でさっさとUWPを捨ててこっちに注力してればもっとましな結果になっただろうに。 ユニバーサル・ウインドウズ・プラットフォーム(Windows10専用)だからな
それよりWinFormsとWPFの2本立ての方が成功してたと思う
高DPIに対応したWinForms2.0とかUnityでも動作するMonoFormsとか
スゲー安っぽいけどWinUIなんかより数倍マシ さすがにWinFormsは要らない。
WinFormsでやってたことはWPFがあれば事足りる。 WPFが最初からネイティブC++で実装されてたらUWPやWinUIは生まれずWPFは統一プラットフォームとして継続的に進化して成功していただろうな
MSはなんだかんだC++大好きで、全部マネージドでいいじゃんってのは社内的に許されないんだよ 好き嫌いの問題じゃないだろ
低レイヤーの実装はC++じゃなきゃ出来ない そもそも.NETがWindowsチームから嫌われてたっていうからな >>198
MSが好きなのはC++98(03)までだろうな。
C++11はアホが好みそうな仕様になったから。 C++98はある種の透徹した美しさがあったな
11以降のも無駄に複雑だった部分がどんどんシンタックスシュガーで簡潔になってきて嫌いじゃない >>202
C++11を理解できないから嫌いなんでしょ >>204
横からレスごめん
C++11は使おうと思えば使えるけど、スマートポインタとかが美しくないかなと思う
メモリをどうこうしたいのならC#とかみたいにGCを実装して欲しかった…
ただ、randomやthreadが追加されたのはかなり嬉しい C++なんてバグ量産言語まだ使ってるのかよw
Rust使えよ低脳 >>199
低レイヤは当たり前だけど、MSの場合は高レイヤも全て快適にC++で記述できなければならない
それがWindowsの標準UIプラットフォームに求められる最低水準なんだよ
C++/WinRT知ってるか？奴等のC++に対する愛と執念は異常 C++11以後は、最低でもStroustrupの9,800円くらいの本は読まないと
話にならないから、お金が掛かる。 >>210
そんなことないぞ
言語仕様が整理されたからむしろStroustrupより薄い本でマスターできるようになってる 現在のマイクロソフトは昔に比べてC++の最新規格追随は熱心だと思うね
昔はC++愛が強かったってことはないんじゃないか >>208
C++/CLIという存在意義不明の言語もあってだな… >>219
C++/CLIはキミの手に負えるような代物じゃない
せいぜいC#とP/Invokeで遊んでなさい >>220
MFCで作られたオブジェクトをC#で使う必要があったのよ >>211
具体的にどの本の事だよ。
絶対無理だと思うぞ。 そういやC++/CLIでWPF作れるんだったね
以前やってみてすごく面倒だった WinUI3
>バグ、機能不足、パフォーマンスの遅さが問題です。
>現在、Microsoftはこれを趣味のプロジェクトとして扱っており、開発者が投資すべき重要なSDKではありません。 じゃあマイクロソフトさんはどのフレームワークに力入れていてどれで作れって言ってるの？ flutterのほうが楽しそう
もう何十年もなあなあの.Netはいらんな xamlも時代遅れだよなぁ。
CSSもflexやgridをサポートして自由自在に画面設計できるようになったんだから、Webブラウザーと同じく使えるデスクトップブラウザーを開発すべき。
HTML5+CSS3をxamlで再カキコしなければならないMVVMアプリ開発側としてはしんどい事限りなし。
blazorがそうなるかと思いきや、そうはならなかったな。 hta2でいいよ
activxの代わりにJScript.NET（死語）でさ >>228
MS的にはMAUI(Xamarin)を推したいんだろうが、こんなものに手を出すのは時間の無駄。
未だにスマホアプリに毛の生えたようなのしか作れないWinUIより
Flutterの方がずっとデスクトップアプリに求められるものは何なのか良くわかってる。
>デスクトップアプリケーションは、単に大きなスクリーンで動くモバイルアプリケーションではありません。
>キーボードやマウスなど、さまざまな入力デバイス用に設計されています。サイズ変更可能なウィンドウがあり、
>ワイドスクリーンモニタで動作することもよくあります。アクセシビリティ、入力メソッドエディター、ビジュアルスタイリングなど、
>重要な事柄についても、さまざまな慣例が存在します。デスクトップ アプリは、ファイル システム ピッカーからデバイス ハードウェア、
>Windows レジストリのようなデータ ストアまで、あらゆるものをサポートします。
・UWP→完全終了。開発側がもう使うな、はよWinUI3に移行しろと言っている。
・WinUI3→1〜2年後には業務で使えるレベルに品質・機能が上がっているかも？（しかしその頃には他のものが普及している可能性大）
・MAUI→使う価値なし（他がもっといいの出してるよね）
・WPF + .NET6→目新しさはないが安定していて間違いがない
・Flutter for Windows→注目株、Fluent Designにもしっかり対応。安定性・メモリ消費・ファイルサイズ等に問題がなければこれ一択か？
以前Dartでhello worldするコンソールアプリ試しに作ったときにやたらファイルサイズでかかったのが気がかり。 Flutter for Desktop、ちょっと触ってみたけど想像以上に良い。
ただ、まだあんまりよくわからんコンパイルエラーが起こる事があるな。
既存の自分のAndroidアプリはそう簡単には動かなさそう。 ウェブのhtml, css, jsの組み合わせをデスクトップアプリに持ってきた方が自然に思える
てかWindowsのみで動くアプリなんてシステムアプリくらいしか需要ないじゃん
そんなのCUIでも全く問題ないんだから 古田はググールだから大変だな
流行らなければ斬るから信者がんばえー >>241
ほとんどWeb系だろうし、単に新しいもの使える職場は環境がいいというだけの話だ WPF(MVVMを含む)を新しいものと見なしてるか古いものと見なしてるかで年の差感じるよな
学習コストとか今さらのように言われてもオマエ今まで何してたんだよ
10年以上前からあってとっくに枯れてるぞ WPFをいままでやってこなかったならいまさらやる必要がないってことでしょ
アプリケーションもウェブベースで作れるものならASP.NETのWebFormsやMVCに移行してただろうし >>238
jsはどんな領域でも使っちゃ駄目な欠陥言語。tsもわずかにマシって程度。
元々オモチャみたいな言語だからレガシーなクソ仕様をばっさり切り捨てないと手の施しようがない。
>Windowsのみで動くアプリ
昔と違ってWindows 1つあれば事足りるようになったからWindows 専用もそれほどデメリットにならない。 普及しないまま枯れていったMVVM葬儀会場はここでつか？ WPFが落ち目に見えるからFlutterとかWebとかこんなにキャッチセールスがやってくるのかな intellisenseがWPFに冷淡だったのが痛い >>248
落ち目なのはWinUI。まだ浮かんですらいないけど。
今の時点でデスクトップアプリ開発環境としてWinUIよりFlutterの方が完成度が上で、今後それが逆転する可能性も絶望的。
これからはWPFとFlutterを状況に応じて使い分ければいい。
WinUIがポンコツすぎて迷う必要なくなったから、かえって良かったかも。 早めにxaml捨ててMAUI＆Cometで一本化する判断しとけばここまで開発リソース分散しなかっただろうに >>252
MAUIは、XAMLによるMVVM、と書いてあるが。 MAUIには、宣言的UIを使ったMVUなるものがあって、それがCometということかいな？
でも宣言的UIもWinFormsとは全く違うよね、多分。 >>244
そんな奴はこのスレ覗きに来ないと思うんだが >>256
やっぱ、そうか。
だからMAUIはXAMLのものと、XAMLではないがXAMLに似たものの二系統作られるという
ことに過ぎないのだろう。 .Net Frameworkも4.8.1でまだまだ延命 6は2年でまた移行だからな
日本ではその度にSIerにぼったくられることになる ListBoxのItemPanelTemplateにCanvasを指定しているとき
Windowに合わせて拡大・縮小する方法教えて
ViewBoxにListBoxを入れてみたけどWrapPanelとかはスケールされるのだが
Canvasのときは表示されないみたい 次の.NETでWPFにWin11用テーマが搭載される可能性 MAUI(Xamarin)に望みが無いならWPFも先細り MAUIの正体がXamarinだって知ってる奴は
こんなもんにはなから望みなんてないってわかってるよ もういいよ
こんなゴミフレームワーク使うのやめたから
何十年まともなの作れないんだMSは すみません 教えてください
WINDOWS UI3 を使ってMVVM ってできるのでしょうか？
サンプルみたいのもないのでできるのかどうかわからないので
教えていただけますでしょうか？ MVVMが目的になってる時点で駄目ｗ
本末転倒だよ >>273
できるよ。
でもMVVMって設計手法の1つに過ぎないから
開発内容に合わせて適用するかどうか考えなきゃ駄目だよ。
徒歩10数歩で行ける隣の家にわざわざガレージから車出して行こうとする頭の悪い人になっちゃだめだよ。 >>273
WinUIはかなりヤバイよ。
公式ドキュメントに
パフォーマンス悪いです、メモリめっちゃ食います、ファイルサイズ無駄にでかいです
なんて載せて予防線張ってるぐらいだから。
SDKのバージョンは一応1.0だけど実質まだ0.5ぐらいの出来。
正式版として世に出しちゃいけないレベル。
止めはしないけどいつでも撤退できるようにしておきな。
これやるくらいならまだWPFの方がつぶしが効く。 2022年という未来の世界に生きてるのに未だにまともなフレームワークがないってどうなってんの 結局プロの使用に耐えるフレームワークはATLだけだったな
あとは全部不完全か初心者向けの不自由なものでしかない >>274
頭ごなしの否定良くない
既存のMVVMアプリがあって、Vだけ入れ替えるのを検討してるのかもしれないだろ ソフトウェアのアーキテクチャ的に
誰も議論しないぐらい
残らないアーキテクチャだったな
WPF流MVVM 枝葉の議論でゴチャゴチャ言ってるザコ共をMVWという本質を突く一言で一刀両断したのは流石だわ みんなありがとうございます。
勉強になりました。
イベントドリブン型が何となくよくわからなくって
MVVMで慣れちゃったから
本当は、 WPFでトグルスイッチが使ってみたかっただけなんだよね ToggleButtonじゃなくスマホで見かけるやつでしょ、ユーザーコントロールで作成だね
実際に作った人もいるので参考にしたり拝借してくるといい(要ライセンス確認) チェックボックスとトグルスイッチの使い分け、毎回悩むわ 見やすく使いやすいのがいい→チェックボックス
ナウなヤングにウケるカッコいいのがいい→トグルスイッチ
で悩むことないやろ 設定項目群に関連があり、「これとこれを有効」みたいなのはチェックボックス。
確認を求めるようなのや説明的な設定項目はチェックボックス。
有効/無効で表現しやすく、設定が即座に反映されるようなのはトグルスイッチ。 使いわけというかデザインセンスだね
例えば、次回から表示しない、はチェックボックスでトグルスイッチ使ってるのを見たことない 即時反映: トグルスイッチ
ダイアログの肯定応答ボタン押下で反映: チェックボックス >>284
アドバイスありがとうございます。
早速 いくつかの トグルスイッチを使ってみたのだけど
トグルスイッチのイベントの形態が２種類あることがわかって、
今まで使っていたのは、 ”状態が変化した”ことでイベントととするもの
他には
"ONorOFF"になったことをイベントとするものです。
VMでどう吸収しようか検討中です。 見た目の変更とかアニメはコントロールの中で完結する方が見通しよくなるし
他でも使えるようにライブラリ化できる
MVVMは関係なく、単に自作UIとしてトグルをどう作り込むかによる
金さえ出せばコンポーネント屋から完成しているトグルスイッチを購入できるので
自作の工賃とライセンス料を天秤にかけるわけだ >>294
サンプルだとかっこいいんだけど、
漢字や平仮名のボタンとか急にダサくなって困る。 都度フォントの変更大変そうだなと思ったらResourceDictionaryにFontFamilyを指定しとくのか >>295
英語だとカッコイイってのがそもそも思い込み。
隣の芝が青く見える的な。
ガイジンさんから見たら漢字カッコイイって思ってるかもしれん。 >>81
キチガイの世界へようこそ・・・
と言うか20世紀なのか今は？ >>298
参考までに
Windows 95 最小ハードウェア仕様要求
物理メモリー、8 MB以上
ストレージ、75 MB以上 いくらPCが速くなってもWPF使ったソフトはクソ重い。
MSすら使いたがらないわけだ。 >>299
たしか1998年にあまり予算をかけたくない俺は
Celeron300AでRAM256MB積んだPCを自作していた
そのころの話か？
やはり20世紀の話だろこれは？ >>301
お前がどんなPC組んでたとか全く意味ない。その時代に普及しているPCスペックが全て。
2022年だからそれに合わせてこんな甘々な基準になっているのに
それすらクリアできないようならソフトウェア技術者向いていないから転職を勧める。 10年前からWPFは既にあって、当時の話題とは
Windows Formsから移行とかSilverlightと比較とか
比較対象が変更されはしたが、今と大して変わらない話題だよね WPFは出た直後にクソ認定されて15年経ってもその評価は変わらない。
FISやIOCと違って技術者は賄賂は受け取らないし忖度もしないのだ。 WinForms
・旧来のウィンドウズAPIの上にレイヤーを重ねたようなもので、（シンプルであるという）利点と
（平凡なレイアウトやスタイリングオプションという）致命的な災いの両方がある。
WPF
・WinFormsからわずか4年後にリリースされたが、デザインパターンとコンセプトがより複雑であったため、
一般に受け入れられるまでにはしばらく時間がかかった。
・大規模なデータセットに対してWinFormsよりも大幅に高速化できるが、正しく使用するにはより深い知識が必要である。
・現状は WPF on .NET 6 が一番つぶしが効く状態。
UWP
・Windows UIの未来だったが、鳴かず飛ばず、現在はメンテナンスモードになっている。
良い点：魅力的なUIを簡単に作ることができ、マウスとタッチの両方でうまく動作する。
悪い点：サンドボックスとパッケージングの要件が非常に厳しい。
結論：避けるべき。
WinUI 3
・小さなチームがUWPのUIスタックからできる限りのものを救い出そうとしている。
・遅い、バグが多い、そして多くの歴史的なお荷物が重くのしかかる。
・開発体験はWPFの方が上であり、開発チームは改善に消極的である。
・1年後にまた確認したいが、私は悲観的だ。 現状、WindowsデスクトップアプリはWPFでWinFormsのようなイベント駆動が一番マシなんですかね
レイアウトの自由度、高DPIへの対応、表示速度を争点にした場合 >>306
それでいいと思う。それが一番処理速度的にもファイル構成的にも無駄がない。
ただViewに依存しない処理はなるべく別クラスに切り出すことぐらいはしておいたほうがいい。 データバインドは使わんの？
エラー表示とか便利っぽいよね >>309
使った方がいいと思った箇所で使えばいいんじゃね？
どちらかに縛る必要はないと思うが >>305
WinUI3だが、内部のWinRTは十分こなれているからバグは少ない
問題は表示系だが操作不能になるようなものは稀で回避策はある
速度に至ってはWPFより遅いことはないんだが、何処の情報なん？ >>312
1.0 Stable以前は酷いものだったが、そこから情報アップデートしていない人が多いのかね？ >>305
> ・現状は WPF on .NET 6 が一番つぶしが効く状態。
これはないかな
まず.NET6後二年も寿命がない
それは別としてつぶしが利くのはwinforms
技術的進展もなければ使えなくなる技術もない
安定 >>313
>パフォーマンスに関する考察
>Windows App SDKのバージョン1.0では、WinUI 3アプリの起動速度、RAM使用量、インストールサイズが、UWPで見られるものより大きい/遅いです
by docs.microsoft.com
Windows App SDKのバージョン1.0では
Windows App SDKのバージョン1.0では
Windows App SDKのバージョン1.0では >>314
WinRT系だと自家製ビヘイビアもほとんど使わずに済むから特に気にならないバグだな
既存のコントロールは関係ないだろうし コンポーネントメーカーdebexpressの中の人が速度がでねぇっていってるし
community toolkitのDataGridも速度出てねぇし
つまりListViewとかで速度がWPFより遅いって話なんじゃねぇの?? >>316
UWPの.net Nativeは極めて優秀だからそれと比較してGUIのパフォーマンスやインストールサイズが悪くなるのはしょうがない
UWPだとライブラリの中でアプリで使われていない部分を全部バッサリ切り捨てるしAOTにコンパイルされるので
WPFのUnSafeと同等のパフォーマンスだ
UWPはWPFと比べられないほどインストールサイズも小さいし速度も早い
ただUWPでもファイル操作はサンドボックス化の影響を受けていて遅いが、WinUI3はSystem.IOを使えるからそこは充分早い マイクロソフトの中でもフレームワーク開発チームは互いに戦ってるのかな >>315
WPF on .NET6の次はWPF on .NET8に乗せ換えるだけだぞ。
>技術的進展もなければ
だからそもそも採用されない。
わざわざ生産性が低いものを選ぶ理由がない。 >>321
生産性は高いよ
時間当たりに生み出す価値が大きいほうが生産性が高いと言う
winformsで5分でできるものをWPFでは確実にそれ以上かかる
しかも学習時間も含めるとWPFの生産性が確実に低い WinFormとWPFは同等の手法が使えるからどっちがどっちって事はないだろ
慣れたら何かBindableObjectとReativeProperty使えばVVMでサクっと作れて見通しも良い >>319
そもそもUWPってGUIはWindows側のAPIを呼ぶだけだからな
WPFやWinUI3みたいに巨大なランタイムをロードする必要がない
AOTみたいな小手先の最適化を云々する以前に、ディスクIOの量が全然違う >>322
いや、生産性はかなり低い。
作るスピードも修正するスピードもWPFの方がずっと上。
winformsの進化版として使う分には学習時間なんてほとんどかからない。 常に勉強し続けるのが善で正義と思うのは間違い
MVVMのパターンも変わり続けて何か正義なのかすらもわからない
これはこうしたほうがいいと絶対的に言える状況なのか
1年しないうちにいやいやこれはとか訂正されたりライブラリから削除されたり生産性が低すぎる MVVMの長らくの議論
ダイアログはどうやって出すかみたいな馬鹿な問題とかもうどうでもいい ひょっとしてWPFはMVVMで作らないといけないと勘違いしている？
MVVMを一切使わなくても問題ないよ。それでもWPF使った方が開発が楽だから。 バインディングって単語が出るとMVVMパターンと同一視しちゃうのかな 個人的にはC++みたく良いとこ取りする感じかな
WinFormsの気軽さで、データバインディングするだけ 単発アプリならVVMでじゅうぶんMは要らん
やりにくいところはコードビハインドで逃げ >>332
Mは普通APIの先のサーバサイドにあるだよ ダイアログに関する議論はMFCの頃から繰りかえされていてMVVM関係ない
最近の話題だと適用ボタンだよね。ダイアログに何か設定するOn/Offという項目があったと仮定して
その設定が反映されるのは(1)On/Off切り替えた瞬間(2)適用ボタンを押したとき(3)OKを押してダイアログを閉じた時
でそれぞれ異なる 使うコントロールも考慮する必要がある。
トグルスイッチはOn/Offを切り替えた瞬間に設定を反映することが求められる。 その話題もMVVM関係ないんだけどな
ただのUIの問題で https://github.com/microsoft/microsoft-ui-xaml/issues/6360
これうちでも発生してるわ
パッケージ名を、初期値のぐちゃぐちゃなやつに戻したらきちんと動いた
パッケージ表示名だけ変えておけば問題ない？ユーザーから見える部分で影響がなければいいんだけど 違うんじゃね？
VとVMの対話の件だろ
結局メッセンジャーパターンで解決されたけど
MVVM界隈でもWPFだけだぞ
とにかくアホらしい MVVMで真っ当に実装する必要があるならダイアログ今はサービス使ってるわ
適当アプリならVMからShowDialogや！ MVVMで御高説をのたまってるやつらも、
ダイアログだけVMがVの参照持ってるの多いと思われ
アホ過ぎ WinUI3のContentDialogは極自然にVMから操作可能ではある
但し厄介なバグがあるんだよな Windowsのシステムで設定したテーマをそのまま使うと問題ないけど
RequestedThemeでアプリ独自のテーマに変更するとContentDialogの表示がおかしくなる
黒バックに黒文字になったり白バックに白文字になったり
しかしContentDialogをページに埋め込みじゃなくて独立させて作るとと何故かうまく動く >>341
いや、違くない。最初にMVVMとは関係ないと断っている。
だから実装ではなくUXの話。
ちなみにメッセンジャーパターンはアンチパターンだから使うやつは馬鹿。 >>348
俺がWPFまだやってた頃、
VとVMの通信の方式でかなり揉めてて
メッセンジャーパターンの確立で
やっとWPF流MVVMのすべての問題が解決！
皆が＼(^o^)／ってなってたんだけど
その後なんか動きがあったのかい？
自分はこの頃WPFにサヨナラして
SPAに全振りする事になったんだけど WinUI3、ちょくちょくデザイナが表示されないってバグ報告あがってて笑った。
まさかデザイナが無いなんて夢にも思わないよな。正式版なのに。 WPFに歴史的価値があるとすれば、それは
MVVMは保守性と開発効率を低下させると実証したこと。 既存のFormアプリにWPFのWindowを表示するため
WPFカスタムコントールライブラリのプロジェクトを追加して
WPFのWindowがダイアログで開けたのですが、なぜかFormアプリの
UIコンポーネントが全て小さくなります。
小さくならない方法はありますでしょうか？ >>350
VでVの要素を操作するサービスクラスを生成してVMにインジェクションするのが一番楽だが
詳細を噛み砕いて説明するのは骨が折れるから誰かやってくれ >>355
WPF メッセンジャー MVVMでググると上位は大体10年前ぐらいの記事が出てきます
でも多分今でもメッセンジャー使ってる人はいるんだと思う
○○の寄せ集めのQiitaですら代わりの技術の紹介がない 他のMVVMではこんな話で盛り上がってないもんな
データの射影ぐらいの扱いなのになんでWPFじゃ状態遷移とかその他もろもろ全部MVVMでやらなければならないんだ
どうせ再利用なんかしないのに >>358
中途半端な初心者が「MVVMでやらないとバカにされる!」
って強迫観念に囚われてるか、意味も分からずこうやって作るものって思考停止してるか、両方か >>359
いやいや
熟練と言うか知り尽くしたほうが危うい メッセンジャーパターンまで付き合って
辞められて良かったわーー
苦労しても固有のロジックすぎて
他で全く役にたたないからな >>359
当時から、
MVVM至上主義って言われてたよな MVVM使わないで、例えばconfigを設定する画面を想定した場合、
//configからcontrolへ
IdTextBox.Text=config.Id;
//controlからconfigへ
config.Id=IdTextBox.Text;
みたいなのをコードビハインドに書いてるの？ HTML/CSSなら思い通りの画面作れるけどXAMLだと作れない。
「技術的に」じゃなくて「自分のスキル的に、っていう意味だけど、
やっぱり参考となるようなsampleの絶対数の少なさがなぁ。 WebView2でよくね？
今更こんなオワコン使わなくても WebView2の人はUIフレームワークとツールキット何使ってる？ あー、WebViewでローカルのhtmlとかも表示できるってこと？
だったらそれでいいのかな >>370
C#のオブジェクトをWebView側に渡すことでJavaScript側からC#のメソッドを呼び出したりC#側の状態を参照したりできる
あとは普通にJavaScript側でReactとか使うだけだ JS側とC#のやり取りをどうやるか定番ってあるのかな。
あまり聞いたことがないがまさかRESTとかじゃないだろうし。 WPFで自前ブラウザー&httpsサーバー作って
SPAをホストする方法ね
中身はReactとか...
自分がSPAに移行するまえに
しのぎでやってた方法
この方式でキオスク端末でまだ何台か動いてるよ
でも今はPWA有るからそっちのが楽だけどね >>372
electron.NETとかみてみれば
もうWPFの要素ないけど... あとc#とjsの連携のedge.jsというのがある なんかいっぱいでてきたｗ
定番とかは定まってないのか。 react
変なの選択すると開発者集めに苦労するよ
保守も 純粋なWebアプリならもちろんReactでいいんだが。
>変なの選択すると開発者集めに苦労するよ
JS on C#ってのが現時点ではそんな気がする。
素直にWPFやFormsでいいじゃん、と。 潮流的にクライアントサイド要員はjs(ts)必須ですね
デザイナーの成果物がhtml,css,jsですから
ダサいのは商品価値もさがりますからね
サーバサイドはjava,c#,js,ruby,python(最近は本当に増えてます)いろいろですね
言語統一したかったらjsですね
ただサーバサイドは要員も別のが多いです jsは型が動的なのがなぁ…tsも実行時の型は保証してないし TSの処理系によって型安全レベルが違ってるからねぇ
ありえんけどブラウザがネイティブでTSに対応したら使ってもいいけど クライアントサイドはc#よりtypescriptのほうが書きやすくて圧勝ですね
あとUI開発にはホットリロード必須と思います
Blazorは最悪でした JavaScript(TypeScript含む)は絶対関わりたくない。
こんなの大規模開発に使っていい代物じゃないよ。
JavaScriptが担っていた部分はDartに置き換わってほしい。
あとReact系もさっさと滅びろ。 >>116のMS製React Nativeがいいんでないか？
もしくは つか、WebView２ならC#とJSのIFは標準で用意されているのに誰も知らないのな
つまり口だけで誰も使っていないということだろ >>354
答えになってないかもしれんが、
FormアプリにWPFを使うなら、formのelementhostにWPFのユーザーコントロールを貼るのがいいと思う >>389
あ、371の人は知っているようだから「誰も知らない」は間違いだな
WebView2のドキュメント見れば書いてあることだ .NET5 WPFのListBoxについて質問があります
VS使わずにやってるんですがBehaviorがないと言われます
名前空間もusingしてますが、そもそも無いようで…
別の機種からの投稿なので具体的な名前空間は忘れましたが、サンプル通りのやつです
やりたいことは一つのListBox内の入れ替えや複数のListBox間のD&D操作です C#でM書いて渡せばWebView2のJSから直接アクセスできるから、MVVMやってるならVVMの部分がそのままJSとHTML/CSSに置き換わるだけだね
つまりビジネスロジックは完全にC#で書けるわけで、これでなおJSで大規模開発辛いと思うなら、
多分そいつがMVVMだと思っているものはVMにロジック書きまくってるエセMVVMの可能性が高い WebView2
ひっそりとそんなブリッジ機能あったのね
10年前にあれば良かったかな...
日曜プログラマー的に
昔みたくフロントreactでロジックc#で作ってみるかな でもWebView2使った
electron相当のもうあんじゃね？
知らんけど System.Windows.Interactivity.dll → Xaml.Behaviors.Wpf >>392
でもJSとC#混在ってだけで一段ハードルが上がるわけじゃん。
ビジネスロジックだけじゃなくてプレゼンテーションロジックも同じC#で書けた方が楽なのは間違いない。 システム開発でweb系が苦手ってだけで
仕事めちゃ少なくなるんですよ
肩身がせまい
情シスのお客さんなら
100%web出来るから
フリーのwebのUIライブラリーに見劣る操作性のものは
恥ずかしくてだせないですね
自分は
そんな背景でjsには精通する必要があって
第二言語のc#は別のでもいい感じなのです
一番多いのはjavaで
最近はバックエンドpythonがマジで増えてる html側もwebview2べったりがイヤだからwebapiモドキ >>398
そのココロは？
単純にJSとC#、Reactと.NETと、異なるものを同時に扱わないとならないだけでもその分労力は増えると思うが。 >>400
Reactみたいにややこしいもの使わなくてもSvelteでも何でも良いんだし。
言ってるほど難易度高くないよ。
カスタマイズしたオーナードローなTreeViewとか作るならHTML+CSSの方がはるかに楽。 >>401
つまり、カスタムコントロール作る前提なら、ってことかな。
うちでやってるデスクトップアプリだと、よほどのことがない限りいちいちカスタムコントロールなんて作らないしなぁ。 アニメーションするチャートとかもWebベースの物の方が良いもの多いよね。見やすいのが多いし、作る側としてもインタラクティブな動きはつけやすい。
最近は業務アプリでもみんな目が肥えてるから。
PowerBIとかもWebViewっぽくないか？ >>403
カスタムコントロールまでいかなくても、チャートの類とか、ビューアーの類とか。
PDFのプレビュー出すのにWebView使うとかもアリよ。 JSとC#の話をしていたはずなのにCSSとXAMLの話になったり、プログラミングの話をしていたはずなのに
ライブラリが豊富という話になったり、なんだろうこのモヤッとする感じ。 c#ジジイたちにWebなんてムリ
今のhtmlやcssは複雑になったしデザインとレスポンシブ込みだとcssフレームワーク使っても使えない無能ばかりだからな >>406
C#とJSを連携する目的はそれしかないからでしょ。
JSで業務ロジック作って連携する訳がないんだから。
C#でXAMLをコントロールする話と、JavaScriptでCSS+HTMLをコントロールする話が、
C#からJSにinteropしてHTML+CSSを動かす話になるじゃん。
その上で使えるライブラリはJSでしょ。
何が疑問？ WPFからバインディングを切り離したグラフィックモジュールが欲しい
バインディングが諸悪の根源 >>410
ならバインディングしなければいいだけじゃないのか
バインディングそのものはWinFormsにもあるんだぜ ID:X0wJkiGG みたいに情報提供してくれる人はありがたいけど
煽り入れてくるのはNGするといいお webもやらないとなぁと思ってVueで入門だわ・・・ >>412
JSだとSvelteで全て済ませたいところなんだけど、d3.jsでチャート書くことも多い。
あと変わり種としては最近はmodel-viewer使ったものも作った。割とウケたけど、これは多分3D触らない人は使わないと思う。 >>410
バインディングを一切使わなくてもアプリは作れるよ Bindingすげぇ！って言ってたじゃんお前ら最初 >>416
ListViewやListBox、TreeViewなどが使用不能だから
しょぼいやつしか作れませんわ
VM使わないならまだしも 仮想化使わなきゃItemsControl系使えるけど
まぁ、データ数増えたらきついな Caliburn.Microならx:Nameだけでバインディングする
PropertyChanged.FodyならINotifyPropertyChangedを自動実装する
バインディングがわからないって初心者、またいちいち書くの面倒で嫌という人なら役に立つかもしれない もう終わったドマイナーライブラリの宣伝はいらないよ VBA触ってからWPF触ったときはデータバインディングに感動したりもしました データーバインディングって Borland C++ Builder の時から有ったよね >>424
そう。当時はシンタックスシュガーでしかなかったものが
MVVM信者によってアーキテクチャの一部に祀り上げられたのが根本的な誤ちの始まりになった。 何が誤ちだよ「過ち」って書くんだよ
MVVM理解できない奴は根本的に学がなくて勉強嫌いだって分かるな >>426
常用漢字ではないけど>>425の文脈だと誤ちでも間違いでもない
そもそも5chで誤字指摘とか… 文書入力した後、見返したり推敲したり編集したりしないのだから入力違いやグダグダ文書なんか当然
いわば一筆書きみたいな文書の書き方になるわけだし 技術板なので技術的にグダグダなのは勘弁して欲しいが意味が取れるなら多少の誤字とかは許容範囲 たぶん、MVVM信者って煽りが気に入らなかったんでしょ
だから誤字を指摘してやり返したと予想 >>425
べつに誤字や漢字使いはどうでもいいんだが
バインディングがシンタックスシュガーって、もとはどうだったのか気になる
もともと機能としてはもってて書き方だけなのか
自動生成なら相当な量のコードに該当する気がするんだが そもそもフロントアーキテクチャ界隈では
viewModelとviewのデータフローで
双方向というのは否定されている >>433
そんなこと言っても、Connected Animationは双方向出来ないと詰む >>426
MVVM信者は本当に枝葉の議論が好きだねえ ところで.NET7が来たわけだが
おまいらどうよ？ 奇数はスルーだろ。
ぎりぎりまで長寿の4.8で粘るという手もあるしな。
確実に3年以上使える。 コンテナの中でおさわりまんこの人です！ってやりたい人は7に飛びつくらしいぞ XAML入門：前編 〜 WPFからWindows11アプリまで 〜 今からwpfアプリ作るなら.net Coreの方がいいのかな？
デメリットは2年ごとにバージョンアップしなきゃいけないくらい？ >>441
.NET Coreは最新の3.1でも今年の年末にはサポート終了するよ
（5以降は名前に「Core」が付かないただの「.NET」） >>442
>>443
失礼しました。.net Framework4.8か.NET6のどちらで作るかという質問でした。 >>444
.Net4.8のサポートが30年あたりだから、25年までは.Net4.8が無難かと。
その頃には.Netも最適化されてるでしょ。
そもそもWindowsが健在なのかも不明だし。 WPFに真剣に取り組んでも将来仕事があるのか心配。 家でWPFに真剣に取り組んで
日中はコンビニでアルバイト
だいたいこういう生活スタイルになるかな >>446
MVVMの第一人者がWPF見限ってWebに移ってるのが全て >>445
ありがとうございます。.NET6はまだまだということでしょうかね。 >>446
「仕事で」というのは随分ニッチ狙いだな。
WPFは個人的に使うツールを作ったりするのに便利。
WPF⇒WinUIに移行する道もあるし。
今は駄目駄目のWinUIも2〜3年後には使えるレベルになってるでしょ。
WebはFlutterに置き換えたい。
JavaScriptはVBAと同じく、プロが使うべき言語じゃない。
TypeScriptも同じ。腐った食材をラッピングしても中身は腐ったまま。 腐ってるのはJavaScript。
誕生の経緯からして大規模開発に使うようなものじゃない。
WPFは頑張ってると思うよ。
Windowsデスクトップ向け開発技術の中ではバランスがいい。
これ選んでおけば困ることがない。
後発が揃いも揃ってヘボすぎる結果でもあるけど。 腐ってると言ってもWPFは納豆なんだよ。好きな人は好きだが嫌いな人は食べない。 >>454
.NET FrameworkのWinFormsはスケーリング対応が腐ってるのがな
.NET6のなら改良されてマシになってるけど >>454
WinFormsを進化させたのがWPF。
だからWinFormsの代わりにWPFを使えばOK。 Flutterってwebもデスクトップもまともに動くんかねぇ・・・ flutterはデスクトップ向けに簡単にネイティブAPIつっつけないんじゃないの？
C#ぐらいデカいデスクトップ向けバッテリーがあっても結構頻繁にネイティブ必要なのに。 flutter webはダメっぽい
CanvasKitのwebasmとか大きすぎてダウンロードが..
そこから..
flutter desktopはok WPFで作成したアプリをWindows Defenderが誤検知したんだがMSふざけてんのか？
お前のとこのツールで作成したアプリだぞ >>465
どの開発ツールで作成したかなんて関係ないだろ、アホか?
見られてるのはどんな挙動をするか。
お前と同じ、キョドってるから職務質問されるんだよ。 ウイルスがやりそうなことや、お行儀の良いプログラムがやらなそうなこと実装すると結構引っかかる Webにおくと問答無用で「人気がない」判定されて疑われる このスレでflutterとかrustとか知ることできて
ありがたい やはりGUIはFlutterで構築するのが流行るかな flutterはネストしたスクロール部分で欠陥があるから注意 まあVSのC++のコンソールアプリのテンプレートのHelloWorldをデバッグビルドするだけで
マカフィーはウィルスとして判定するんやけどな... マカヘー「今どきC++なんか使ってるやつはウィルス作成者に違いない！ギルティ！」 >>472
そもそもUIとしてネストしたスクロールは使いづらいし、
見た目が悪い ネストしたスクロールってandroidで当たり前のツールバーがコンテンツのスクロールに合わせて表示されたり消えたりするやつのこととかを含む..
まじでflutterスクロールまわり欠陥だらけ
jetpack composeはそうならないことを祈る つうか、netflixとかamazonのアプリとかyoutubeとかもネストしたスクロールだろ
縦方向にスクロールさせて個別のトピックで横方向にスクロール
こういうアプリ良くみるけど >>477
カルーセルでしょ
最近のUX言語ではスクロールとはまた別の概念だよ ネストしたスクロールで方向が違うものを特にカルーセルっていうだと思う(想像) ごめん>>479はカルーセルじゃねぇな
やっぱ、>>477はネストしたスクロール方向がちがうスクロールじゃね? >>478
違う概念というが俺は元からスクロールについていってるんだが
横方向と縦方向と方向が違うが>>476はネストしたスクロール
UI的にカルーセルって言葉使いたいなら>>476はネストした
カルーセルじゃね ネストしたスクロールって親にも子にもスクロールバーが出るようなUIだぞ。
カルーセルはスクロールとは言わずにスライドとかページ切り替えと表現する。 それ以前にデザイン的じゃなくて技術的な観点から複数のコンポーネント間でUIイベントをやり取りしてスクロールを調整する動きをネストしたスクロールと表現してそういう前提で話を進めてたんだが
そこはわかりずらかったっぽいので悪かった
だから>>476のツールバーが消えたり隠れたりする動きも含めたり
androidならNestedScrollViewやらNestedScrollingParent
まぁ、そこらへんがflutterはくそ 今からWPFなんてやっても仕事ないけどな
趣味なら好きなようにしていいが かずきのWPF講座読んで、あとは使うならMVVMライブラリのチュートリアルでもやってみれば もはやユーザーが少なすぎてベストプラクティスもクソもない状態だから、自分の好きなように使えばいいよ そうそう。MVVM警察気取りが幅を利かせてた痛々しい時代は過ぎ去ってアーキテクチャ固執主義は間違いだったと実証された。
コードビハインドにガンガン実装しても全然いいよ。 それは生存バイアスってやつだ
そもそも設計の良い悪いを言い出したらMVVM以前にこんな日の目を見なかったレガシー技術を採用すること自体が明らかに悪いわけで、
そういうことを気にしない人が残ってるだけ >>487
身近なところや、「WPF 求人」で検索した結果を見ても仕事はあることはある。
他の人気のある言語と合わせて習得しておくのは悪くはないと思う。 MVVMって誇れるほど難しい技術でもないからｗ
逆にコレがわからないとしたら転職考えたほうが良いかも 超ブラックのIT業界いるなら、しかもPGは底辺なのでさっさと転職したほうがいい。 >>495
わからないと言うより面倒と言う側面の方が強い
後はどうしたらよいか定番みたいなパターンがなかった 今さらDispose()まで必須になったReactivePropety使うならナチュラルに書いた方がシンプルだし分かりやすい 自分的にはReactivePropetyは最初から眼中にない。
ほぼ個人でメンテしているようなものは業務で使うのはありえないし、
わざわざメモリリークの爆弾仕込むようなものだし。 >>456
.NET6のWinFormsデザイナ、まだベータ版だぞ。
スケーリング対応も多少改善されてるけど問題点はまだいくつも残ってるし、
そもそも固定配置前提のUIフレームワークは生産性低すぎて辛いだろう。 >>501
業務アプリだと1画面にビシッとハマらなければならないのでGridでいい
逆にWindowsの「設定」みたいに画面スクロールしてーーとか出したら切られる >>503
Webアプリで目の肥えた客「ウィンドウサイズに応じて最適な項目配置に変わってね。縦長ウィンドウにしたら縦に並べて、横長にしたら横に並べてね。」 >>504
WinFormsでもFlowLayoutPanelてのがあった気が >>505
客「あっ、そうそう、文字サイズは5段階ぐらいで調節可能にしといてね」 テレワークで突然解像度1366x768のノートPCとかいう人権のない環境に叩き落された人もいる
古の業務ソフトには縦800が前提かつ、全ウィンドウでサイズ変更不可とかいうクソみたいな仕様を採用してるものが多いので
最下部のボタンが押せなくて仕事にならないって話をもう数件聞いてる
レスポンシブにする必要はないが画面サイズ固定は流石に時代遅れだと思う >>508
それはそうなんだがWinFormsの場合はPanelを使った流動的なものでもフォントが変更されるとフォント次第ではコントロールの幅とかが変に…
かと言ってWPFはListBoxとかで工夫を加える場合面倒 class ViewModel{
public ObservableCollection<Mail> Mails = ....
}
データグリッドでMailsをbindingして表示します。
データグリッドの各行ににチェックボックスを付けて、例えば一括して削除などの動作をしたい場合、MailクラスにIsCheckedなどのプロパティを追加する以外に良い方法はありますか？
Mailを継承した専用クラスを作ってそちらをbindingする方法も考えましたが、もっと簡単な、あるいは一般的な方法があれば教えて頂きたいです。 UIの状態をあらわすのがViewModelなんだから、Mail用のMailViewModelを作ってそっちにIsCheckedプロパティを追加する
で
class ViewModel {
ObservableCollection<MailViewModel> MailViewModels =
} MVVM的にはViewにバインドさせるのはModelじゃなくてViewModel
Modelをそのままバインドできる要件ならViewModelを用意せず横着してもいいけど こんな単純なことするのにも迷うMVVMゴミすぎる
本末転倒だよ… そういうのはMVVMに限らない。MVCだって学んでなけりゃ迷うわな。 ViewModelも使うけど加工する必要がないデータはModelから直接バインドしてます
最初のころは全てViewModel経由していたけど、その意味がわからなくなって >>515
Modelってことはコードビハインド？
ざっと触ってみた感じ、ViewModelとModelは別物だね
WinFormsとかみたいな場合はイベントとかで直接View、つまりコントロールをいじってた
これをWeb系みたくデザイナーとプログラマの役割分だけするためにイベントやModelで直接コントロールをいじることを禁止する
もちろん、表示・非表示の切り替えみたいなのは別で
ViewModelを介すことで直接コントロールを操作することを防ぐ
例えばListBoxの中身をデータバインディングした場合、ViewModelを操作(配列に対する操作とか)をしたらListBoxに反映される
…って妄想してる デスクトップ開発にデザイナーなんて職業は存在しない。 >>517
反映するにはオブザーバブルでないといけない
それがVM >>518
デザイナーが居る場合はある
XAMLは作ってくれないし、デザイナーの指定したデザインの再現に苦労するのはプログラマだが 採用すると生産性が落ちるアーキテクチャとか存在意義なくね？
プログラマーのオナニーでしかない >>511
これってMailViewModelの中にMailModelを保持すると思うけど、グリッドコントロールで行を消すとMailViewModelは消えるけどMailModelは消えずに残るよね？
そこは頑張ってコード書いて同期を取るしかない？ ストレージから削除するなら
頑張って書いたほうがいい 皆さんありがとうございます。
class MailViewModel : Mail{
public IsChecked {
get => _isChecked;
set => SetProperty(ref _isChecked, value);
}
private _isChecked;
}
上記のようなクラスを作ってBindingするのが良さそうに思いました。 >>523
グリットコントロールから行を消すことがメールの削除の操作を意味するようにしたいならMailModelも消す
単に非表示にしたいだけとか、ゴミ箱に入れておいて復活させるようにさせたいとか、色々考えられる
だからViewModelが欲しくなったのさ >>526
なるほど。ケースによって対処は変わるよね。
ありがとう。 ここまで普及したElectronの牙城を崩すのは無理な気がする。せいぜいGoレベルだろう。
Electronがディスク使用量もメモリ使用量も超重量級なのは不満に思ってたけど。 viewをhtmlとcssで書けないとつまらんよ
デザインがしょぼくなる しょぼい方が評判良くて、デザイナーの自己満足全開デザインが使いづらい・分かりにくいと不評なのが現実 >>535
まあそうやって逃げるしかないよな。
お前の仕事は無意味だって認めることになるんだから。 碌に使いもしないが権限だけは大きいエライオジサンのせいで見た目だけは派手だが使いづらいものになるのはまれによくあること デザインセンス云々は置いといてhtml+cssのほうがデザインの幅が広いのは確か
予算があるならデザイナーにも頼めるしね WPF+MVVM+Rxの実装について勉強中です
それぞれの各機能はなんとなく掴めてきたのですが、実装する場所や通知の受け取り方がまだ分かりません
例えばObservable.Intervalで指定した時間ごとにDBアクセスし、更新があれば通知するという処理はどのクラスに書くべきなのでしょうか
なんとなくですが、Mで実装しVMに通知、Vに表示と考えています >>539
MVVMはあくまで、GUIの設計パターン。
DBアクセスのようなアプリの内部処理は
Mで包んでGUIの処理から隠されるので、
MVVMの処理フローには一切出てこない。
Mの原則は「GUIから見える状態に変化があれば通知する」。
この場合は、DBアクセスし、更新があり、
その結果としてGUIが更新が必要になったら、
Mに通知させるという処理になる。 お気に入りのアプリがWPFで実装されてて公開されてるから古いUIをWin 11のUIに合わせたくてForkしてWinUI3.0に対応させようと思ったらWindows App SDK 1.0だとAcrylicやMicaに対応してないとかズコーだわやっぱアホだわMSやることがすべて片手落ち
結局サードパーティー製のAcrylic実装を使う羽目になったわけだがこっちもろくすっぽメンテされてなくてWin11に対応してなくてダブルでズコー
たまにやる気になってプライベートでいじろうかと思ったらこれだからMSの開発環境ってマジでどうしようもないな
誰かWin11とVS2022で使える無料のAcrylic実装しらんかね？ >WinUI3はまだ完成していません。
一応MSもその認識はあったのね。
あんなお粗末な出来で自信を持って1.0として出したわけじゃないのね。 >>542
WinUI選ぶくらいならこれ。
Flutter for Windows
・fluent_uiパッケージ
・flutter_acrylicパッケージ
Windows向けはまだ出たばかりだけど、
現時点の機能・品質、
フレームワークとしての出来、
将来性、
開発者の期待度
どう考えてみてもWinUIがFlutterに蹴散らされる未来しか思いつかない。
WinUIは
「これが最新らしいし、やってみるか」
↓
「えっ？なにこれ、こんなしょぼいの？こんなこともできないの？」
って感じでちょっと触って実情に愕然として、さーっと離れていく。 fluent_ui実際使うとちょっとアレ
modernwpfもそうだがやっぱ個人メンテじゃなー
Microsoftが手がけろよ >>305
これにUnoPlatformとAvaloniaとXamarin(maui)も追加してくれんと
で、これも全部微妙という
クロスプラットとかUIフレームワークは人的リソースさかないと品質とかできないのにみんなで戦力分散して全部微妙品質 >>544
おーサンキュー
だが流石に.NET FrameworkのレガシーアプリをFlutterでポーティングするほどの時間も熱意もないwww
とういかReactやFlutterが出る10年以上前から思ってたんだがなぜMSはXAMLとASP(Razor)を今でも別々に拡張してるのか理解に苦しむし頭が悪すぎる
まぁどうせ社内の派閥や政治でわけわからんこと繰り返してるんだろうけどその間に開発環境もシェア失ってしまったな
せめてどっちかに統一してUIの定義はCSS拡張にしないともうよっぽどの事情がないとこんなクソなフロントエンドフレームワークなんて誰も使わんぞ
理想を言えばさっさとXAMLとASPを窓から放り投げてTSとCSSで記述する新しいフロントエンドフレームワークを実装すべきだと思うんだがな やるならDart使うか、同じようなJavascriptをリデザインした新言語を作って欲しい >>544
ところでFlutterってVS2022で環境構築できる？
拡張とプロジェクトテンプレートがあれば最高だけどまぁないか
Android StudioはエミュとSDK用にMacに入れてたけどくそ重くてVSCodeでReact Nativeばかり使ってるけどWinで試してみるかな >>548
それなんてReact Native？(´・ω・｀) >>550
VSCodeとFlutter拡張で開発できる。
Windows用ビルドするのにVS2019か2022を入れておく必要はある。
でも今2022の17.1.0のバグでデバッグモードが死んでて17.1.1待ち。 >>553
React NativeもそうだけどFlutterもパッケージのバージョンで開発環境ぶっ壊れて死にそうになる感じかなのか？w
とりあえずVSCodeはReact Nativeに最適化してるから先にAndroid Studio試すわ
そろそろRemote-Containersを試したいんだが最近はコーディングより環境構築がくそムズくてめんどいんだよな >>540
ありがとうございます
まだ追加で質問できるほどの知識もないので、手を動かしながら探ってみます WPFもFlutterも両方入門者レベルだけど、Flutterのが馴染むなあ… じゃあ、先にFlutterでMVVM覚えてからWPFくればいい
そうすれば後覚えるのはxamlだけ とりあえずFlutterのWindows Desktop環境の構築終わってビルドしてみてDartの構文学んでるとこだがこれDartってまんまC#のパクリやんけwww
んでFlutterの構文はJSX(TSX)のパクリだなとりあえず状態管理がReduxみたいにクソじゃなければ文句ないわ
>>544のfluent_uiとfluent_acrylic試してみるわ DartはC#じゃなくてGoogleが再定義した中途半端なJavaでイラっとするんだよな
interfaceの定義が暗黙だったりinternalならプライベートメンバにアクセスできたりわざわざimplementsやextendsが必要で冗長だったりC#の方がよっぽどモダンだよ WinUI3は今でもアプリ内のアクリルは有効だから、ベースに壁紙でも配置すればそれっぽいものにはなるんだがね >>560
DartはJavaScriptの置き換えを狙った言語。
TypeScriptみたいにJavaScriptの上位互換よりも
JavaScriptの古い部分を排除して新しく作り直したDartのアプローチの方が好き。 >>562
は？Dartは静的型付けなんだけが？アンダスタン？
JSの置き換えが目的だが元はCだし動的型付けの進化系とか言っちゃうアホとはさすがに会話にならん・・・こんなレベル低い奴ばっかなのここ？ >>563
レベル低いのはお前。
静的か動的かなんて話は一切してないぞ。
勝手に明後日の方角に突っ走って喚き散らして、そりゃお前と会話になるやつはいないだろうなぁw 理詰めで論破されて悔しいけど反論できないから顔真っ赤でIDコロコロ自演して悪口とか恥ずかし過ぎるだろ 理詰めって静的とか動的の話し誰もしてないのに、一人で突然型付けの話して論破って馬鹿すぎるw
誰もそんな話してねぇんだよww
技術的な話する以前の頭の悪さww WinUI 3.0の完成度は公式の認識ではまだ50%未満なんだな。
これをポジティブにとらえればいいのかネガティブにとらえればいいのか。 世界一のIDEであるVS(codeじゃない)とC#の出来の良さををすべてスポイルしてマイナスにしてしまうフレームワークしか作らないからな
MSは良い加減一貫性や統一性のない大企業病を修正しないと開発環境を失う時代はすぐそこまできてるぞ WinUI3で、普通にペロッとzipなりで相手に渡せるexe作れる？
配置型強制とか開発者モードONならとかは避けたいのだが... >>574
UnPackagedがある
でもファイルサイズでかいし、全体的にβ版品質だぞ >>574
は？githubでbuildしたバイナリごと公開すればいいだけなんだが・・・もしかしてこのスレってレベル低い雑魚専スレだった？www みんなWPF使ってないのにスレはよく伸びるな。MSは釣りの達人だな。 ReactivePropertyって便利ですか？
重かったりしませんか？ WPF使わない人が入れ替わり立ち替わりこのスレにやって来るのが逆に不思議だわ。 >>580
いつメンテが止まるかわからんコントリビューターがほとんどいない日本のガラパゴスフレームワークなんて使う奴は馬鹿だって脳みそに刻み込め
Livetと同じく作者が飽きたらマイグレーションしなきゃならん体験か地獄だろ
まぁそもそもMSの開発環境はまともにメンテされてるサードパーティがほぼないから既にオワコンなんですけどね >>580
便利だと思うよ
軽量版のReactivePropertySlimというのもある
必要に応じて使い分け Windows Helloの実装見てても相変わらずMSが作る認証の実装って抽象化しすぎてて手間がかかってクソ面倒だよな
Xamarin向けで個人が作ってるFingerprint実装の方がよっぽど簡単だしわかりやすい
MSの実装ってすべてこれで高度に抽象化されてはいるが基本機能は提供してやってるからこれを自由に使って開発しろ、もちろん各機能はお前らが開発者が実装するんだ当然だろ？って価値観だからそりゃこんなクソ面倒な環境なんて人気なくなるわな >>581
最大勢力であるWPF勢を取り込めば覇権を手にすることができるからな >>586
後片付けしろw
そんなんじゃ素のINotifyPropertyChangedでもやらかしてそうだ 依存関係プロパティも添付プロパティも面倒っすな
コードスニペットがなかったら発狂してる コード補完が汚れるのと言語やライブラリと関係ないキーワード覚えるの無駄だからスニペット大嫌いだわ
これが嫌だから世界一賢いIntelli Sense搭載のVSをできるだけ使いたいのに他言語のフレームワークがないのMSクソすぎる Q) WinUIを使った実際のプロジェクトを見たことがありますか？
A) 私はC++/WinUI3で簡単なRPAツールを開発したことがありますが、
WinUI3の現在の進捗状況と機能では、商用アプリケーションを開発することができないと言いたいのです。
A) ソロ開発者の話をよく聞いていますが、はっきりとノーと答えることができます。
今のところ私の知る限り、誰もWinUIの道を進もうとは思っていません。
A) 他の人達が言うように、WinUI3は商用アプリケーションにはまだ早いです。
私たちはWinUI3を調査し、WPFの代わりにWinUI3を使用するようにいくつかのアプリを変更できるかどうか検討しましたが、
多くの機能が欠けており、バグの量も多いため、現実的ではありません。
WinUI3は、今のところ趣味のアプリケーションにしか使えません。
私の予想では、Microsoftのリソース次第では、完成まで2年かかるかもしれません。 >>594
リリースの時点で属性ラベルつけるぐらいで通知出来るようにしていたらと 実際にWinUI3触ってない奴や理解できてない奴はは勘違いしてるがWinUI3は各プラットフォームのネイティブUIをWindows App SDKとして完全に切り離して独立させたものだからWin11のAcrylicやMiacなんかを実装するものじゃないぞ
WInUI3(Windows App SDK 1.0)の目的はストアが大失敗した原因の一つであるストアアプリ実装の障害となっていたUWPとWIn32を統合してXAMLで統一することだからな
まぁもうWindowsのカジュアルアプリをAndroidに委ねる方針を決めて既に実装もなかば完了してて英語圏の一部ユーザーには提供も始まってる状況でこんなことにリソース使ってるのはアホだと思うが
今MSがやることはFlutterのC#フレームワークを開発することだと思うんだがなFlutnetを買収してもいいしとにかく買収したXamarinのアプローチはWebがないから失敗だったと認めて精算して次に進むことだ micaやbackground acrylicはWinUI3 1.1の予定でしょ >>598
もう笑えない
windowsアプリなんかやらん MSがオープンソースに舵切って
もう随分日が経つのになにやってんの？ そりゃメインストリームじゃ無くなるって事だから
良いものに投資してそれを担げば良いってビジネスに変わってるのよ WPFはWindowsとともに緩やかに死んでいけばいいものなんだから、
WPFから○○に乗り換える、みたいな思考が出てくること自体が俺にはよくわらかんけどな
○○を適用する領域とWPFがになっている既存の領域って重ならなくない？ ぶっちゃけUWPとWin32なんて放置でいいんだよFlutterでめっちゃ簡単にWinのデスクトップあぷり作れるんだがw
しかもFlutterならすでにAcrylicやMiacが超簡単に実装できるパッケージが存在してて本家のWinUIがすでにオワコンのゴミになってんだよな
個人的にXAMLに統一したのは悪手で最悪のシナリオだと思うがなこれMSの開発環境にトドメ刺した気がする
だってWPFもUWPもXamarin FormsもXAMLを採用してるフロントエンド実装ってカスマイズが半端じゃなく面倒臭くて大変だからな
Xamarin FormsでiOSやAndroidのText Field/Text Editのラインの色を変更するというReactやFlutterなら超簡単な実装がわざわざプラットフォーム毎にカスタムBrush作らないとダメなの頭悪すぎるよMSこんなくそフロントエンドフレームワークなんてそりゃ誰も使わないよwww じゃあなんでFlutterはWinFormsに勝てないんだい？ >>606がネットワークみたいなIDをしてるからでしょうね >だってWPFもUWPもXamarin FormsもXAMLを採用してるフロントエンド実装ってカスマイズが半端じゃなく面倒臭くて大変だからな
デスクトップGUIやってきた人は下手に自分でカスタマイズしようなんて考えないもんだけど
こういうのはやっぱりWebから入った人なんかね いやそれはUIなんて1ミリも意識したことがないセンスゼロの日本のIT土方の発想だからだな
日本の人月仕事のIT土方の作るソフトウェアは業務もカジュアルも楽天のような壊滅的なデザインセンスのゴミばかりだからカスタマイズとか考えたことないんだろうな
海外のアプリはUIデザイン素晴らしいからなしかもプログラマーがデザインしてたりして日本のIT土方とは雲泥の差 DOS時代にオレオレGUIでイキっていたプログラマ連中はWindowsでLook&Feelが統一されたとき
個性が出せないとブーブー文句を言っていたという DatePicker に日付を入力する場合
WinForm テンキー入力が絶望的にムズイ
WPF キー入力が簡単
Chrome キー入力が絶望的 連日こんなところでWPFの悪口を書いて憂さ晴らしとか
可也歪んでいるな WPFで業務システムしか作ったことなくてモバイルアプリなんて作ったことないってバレバレだな
アプリやウェブなんUIのカスタマイズなんて常識だぞ UIコンポーネントのカスタマイズとUIの設計は別の概念であってな... XAMLのUIカスタマイズは相当な知識と技術ないとできないからIT土方には無理
XAMLはもともとMVVMとセットで設計されてるフロントエンドフレームワークだからカスタマイズはモデルを考慮しながらLogicalTreeを操作する必要があって生半可な知識では実装できない
IT土方ではやらないんじゃなくてできないだからそこを勘違いすんなよ 相当な知識と技術が必要なものなんて普及するわけがない 今はLive Visual TreeとLive Property ExplorerとHot Reloadがあるからそれでも相当マシになったけどな
ちょっと前まで実行後のVisualTreeとバッキングフィールドを確認しながらMとVMを設計してXAML、Converter、LogicalTree等々を書いてと手の込んだユーザー定義コントロールの実装は半端じゃなく難しくて大変
プロジェクトごとにGrapeCity並みのユーザー定義コントロール作ってたと言っても底辺な土方は信じないだろうが事実だからな デザインについてはXAMLよりCSSの方が難しく感じる >>613
業務システムは別の難しさがあるんよ
UIのカスタマイズとかしようもんなら、顧客のジジババから
「見たことないようなのはダメ！」「わかりにくい！」と非難轟々 お前がお手本にしたWebやWindowsが分かりにくいからじゃねえの？ >>620
お手本にするのは過去のアプリなのよ
そこから逸脱するUIは受け入れられない
業務アプリとはそういう世界 >>618
CSSのが機能比で1000倍以上はあんだから当たり前 ビハインドコード書かないというのは、以外に疲れるもんやね。
LoadedすらInteractionでイベントバインドとは・・・ 恐ろしい。 >>625
もう結論出てるやん
イベントハンドラをコードビハインドに書きまくるのが正解 >>623
cssって何が出来るの？
TreeViewやDataGiidやCanvas上に自由にコントロールを配置するのは出来る？ >>631
それは基本過ぎてwpfより高機能な例には適さないんじゃないの？
DockPanel、WrapPanelの役割に相当するレイアウト機能はどうやって実現するの？ 俺程度の人間には、GridやStackPanelで十分なのさ。 >>613,618,625,628
これが人月仕事で客先に派遣されてるIT土方奴隷の実態だぞお前ら理解したか？www
このレスだけでこのIT土方がどれだけ底辺か理解できるだろ業務システムなんて客も元請も下請けも馬鹿しかいない
刺身にたんぽぽ乗せる仕事しかしてないからこんなんIT土方が量産されるんだよ日本のこの業界もうオワコンだってわかんねw
いやそれにしてもプログラム板でも屈指のレベル低いスレだわwww >>636
wpfで作っている自作ツールを勉強を兼ねてtauriとやらに移植してみようと思ったんだが
何から取り組めば良いんだろうかと思ってさ
HTML cssの方がクソwpfより全然良いってこのスレでは繰り返されるから、実際どの程度簡単に出来るものなのかと
vscodeがあるってことは、ほぼデスクトップアプリとして遜色ないものが実現出来るんだろうけど
そのためには大量にjs/tsのコードを書かないといけないんだろうか？ >>635
他所では今度はwpfの話が伝わらないんじゃないの？
ここの方がwpfの欠点を知り尽くして、他のソリューションでカバーしてる人が揃ってるんじゃないか？ >>640
wpfのレイアウトなんて誰でもできる
他所で聞け >>641
他所でwpfやってるなんて言ったら馬鹿にされるんで 本当に知りたきゃプライドなんて捨てろ
プライド言い訳にしてるやつは伸びない 違うよ
俺が馬鹿にされるのは良いんだよ
wpfを馬鹿にされるのが悔しいんじゃないか >>641
できなくてWinFormsに固執してるロートルが可愛そうだろ Webから入った人にとってはUIガイドラインとか理解できないんだろうな。
なんでそんな窮屈な制約かけてんの？って。 ガイドライン()、標準化()
日本の底辺IT業界のラインとはピンハネ要因として派遣されてくる底辺IT土方の基準までラインを下げないとプロジェクトが100%頓挫するから最低の線引きするためのラインなのが草
そりゃ日本からまともなUIやデザインのソフトウェアが産まれるわけないわな なんかやけにウェブがどーのとか頓珍漢なこと言ってる馬鹿がいるな
今時のまともなプログラマーはデスクトップもモバイルもウェブもフロントエンドもバックエンドもサービスもなんでも経験してるフルスタックエンジニアばかりなんだが？
逆にC#と.NETでレガシーアプリしか開発した事ない雑魚とかレベル低すぎるから空気読んで議論に混ざってくんなよって話なんだが 日本のウェブデザインは時代遅れ感が半端ないからウェブ系が優れてるんだーっていう主張も通らんよな >>649
スレタイも読めない馬鹿が何言っても説得力ないぞ 体系的な知識もないのに自負心だけは高くて「俺にデザインさせろ」と言うタイプ 自社主導のUIフレームワークを一つに絞れず乱立させてる時点でガイドライン以前の問題ですわ >>649
そんなまともなエンジニアはこんなとこにいないよ笑 かわいそうに。
なんでも屋の末端奴隷としてこき使われてることに気づいてないなんて。 と刺身にたんぽぽ乗せるライン工仕事しかできない底辺IT土方が申しております たまーーに
本屋の陳列にエンジニア魂を見る事がある 小泉とケケナカが定着させた日本のピンハネ中抜き底辺IT土方業界はCOBOLの需要が増えるという意味不明なガラパゴスだからなw
IBMがさっさと見切り付けて逃げ出して富士通が拾ったみずほが大失敗した現実見れば日本のIT土方のレベルの低さがよくわかるwww うるせー土方さんを悪くいう奴は新鮮組として性売してやる！ Flutterちゅばらすぃー
Flutter Windows DesktopはC++をDartでラップしてるだけだからC++でUI拡張するという力技が使えて痒いとこに手が届くわ
え？C++でもXAML使えるって？WinUI自体がゴミなのにC++でXAMLとかどんな罰ゲームだよwww
Flutter初心者の俺がパッケージ3つ入れて400ステップ足らずのコードで元のタイトルバー消して独自タイトルバーでウィンドウ全体にAcrylic適用したDesktopアプリ作れたわ
いやーこれもうWindows Desktopアプリですら.NETとXAML使う必要性なくなったな
しかしMetaも馬鹿だね意固地になってReact NativeでWindows絶対に対応しないマンやってる間にGoogleにしてやられたね Flutterって、GUIはDartで、ロジックはC#で書けたりするの？
だったらWinUIで作成途中のアプリをFlutterに移行したい。 なぜDartなの?
Dartの言語としての特色がFlutterに必要不可欠なの？
C#やKotlin、あるいはgoogleのGoじゃ駄目だったの？ 今のモダンな言語なんてどれも変わらないだろ1日あれば覚えられんだから問題じゃないしどうでもいい
Goじゃ駄目なのかとか言ってる時点でアホすぎるDartすら習得できない老害がGoを理解出来るわけないだろ馬鹿が 保守が楽というか、ホットリロード便利だな
XAMLがありがたいと思う時である HotreloadもLive Visual TreeもReal Time Previewも超便利なんだが遅すぎた
そしてXAMLのカスタマイズ性とMVVMの冗長性が一向に改善されず相変わらず機能毎にStyleとBehaviorとConverterとTriggerとCommandと依存関係プロパティが増えていって対したことないアプリなのにとんでもないファイル数になる
そしてソリューションのロードだけでなく全ての動作がどんどんもっさりしていきビルドも遅くなりストレスが半端ない 動作がもっさりしていくなんてやっぱり依存関係プロパティ、バインディングは使い物にならないですね WinUIになってイベントバインディングができるようになったからビヘイビアを使う機会は激減し、
コンバーターもバインディングで関数が使えるようになってから書かなく良くなった
更にビヘイビア作らないから依存関係プロパティーも殆ど使わずに済む
知らない人は知らないんだな WPF基盤アーキテクチャそのものが時代遅れになってるんだよな >>667
たいしたことないアプリにMVVMなんか使うからそんなことになるんだよ。
ViewとModelだけに分けりゃシンプル。 mvvmは捨てる必要ないぞ
viewとviewModelをヘンテコなbindingで繋がずに、
素直にXAMLのcodeBehindで結べば良い >>674
品質は全部ダメダメ。その中にお勧めは無い。 やっぱそうなの
MAUIはまだ正式リリースされてないが
リソース分散されてどれも中途半端な品質で終わるパターンか
これらで本格的なアプリ作ったことある人皆無やろうからな.. Microsoft Store見たほうがいいよ
もう競争は始まっている もう競争は始まっている(ｷﾘｯ
ちょwおまwwwクソウケるwww
WSAでAndroidアプリが動作して既に米国限定でAmazon AppStoreのテストが始まってんのも知らねー無知な知ったかがもう競争は始まっている(ｷﾘｯは草www
もうWindowsのアプリはすべてAndroidアプリに取って代わられるんだよ馬鹿
だからFlutterなんだよ低脳の馬鹿が MSがそっちについて舵きったから
デクストップアプリもそーーなるよな まだテストなんかしてんのかよ
Win11の売りだろw Windowsデスクトップのみを対象 → WPF + .NET6
マルチプラットフォーム → Flutter
以上 flutterは良いけどdartがパッケージ貧弱すぎてやってられん まぁXamarin使わないといけない特別な事情でもないかぎりまともな脳みそしてればクロスプラットフォームならFlutterかReact Nativeの二択しかないって理解できる
ぶっちゃけシェアって観点ならiOSならSwift+ObjCでAndroidならJava or Kotlinで未だに圧倒的にネイティブ開発の方が多いからな
その過半数もシェア取れてないクロプラでXamarin選択する馬鹿なんて中抜きCOCOAとかそういうのしかないってことも理解できる
カスマイズもメンテもクソ面倒なXAMLなんて強制されなきゃ誰も使わんよ 直接テキスト弄るとか時代遅れ。40年前の開発環境やん。 シンプルってWinFormsでもReactでもFlutterでもシンプルだぞ何言ってんだんだ？w
そもそもXAMLもバリバリコードビハインド使ってるし現代のフロントエンドはコードビハインドに回帰してるんだが時代が10年前から止まってんじゃねーの >>688
WPFのメリットってXAMLが使える事ぐらいだろ
>>691
ノーコード・ローコードツールでも使ってな メリットもクソもWPFイコールXAML+MVVMなんだが？w
MSのJosh SmithがDocsの記事で公言してんだから疑問に予知なんてねーしそもそもそんなことも知らんアホがこのスレでふドヤ顔してんのレベル低すぎて超ウケるwww 別にMVVMが必須ではない
量産し出すと保守の都合でMVVMの方が勝手がいい、それだけ
開発の大半はビジネスロジックやUIの作成に費やされていて、ビューモデルとか割とどうでもいい WPFの三大デメリット
・保守性が悪い
・開発効率が低い
・MVVM信者が仕事しない >>697
WinFormsよりは保守性も開発効率も格段に上だけどな。
MVVMの有無にかかわらず。 XAMLって、HTMLでレイアウト+CSSで機能実現する人には快適だけど、HTML中心、つまり Resource Style使わない人には大変だね。
Webデザイナー向け。
WinFormsでベタボトの人には向かない。 HTML+cssメインの方だと
XAMLでは貧弱過ぎて相手にされないと思いますが >>700
いやいやXAMLのどこがHTML5+CSSなんだよ！w
お前がXAMLどころかウェブもReactもFlutterもなにもわかってない雑魚だってことはそのレスでバレバレだからもうROMってろ、な？w
逆にさっさとXAML捨ててHTML5+CSSならもっと人気でてるわ
XAMLを捨てられず折角買収したXamarinはXamarin FormsでオワコンだしASPもBlazorとWASMで延命はかるも中途半端すぎるわでオワコン
結局MSが出した答えはまたもAppleの猿真似でAndroidアプリをデスクトップで動かしたらええんや！でカジュアルなデスクトップアプリが死亡 webview2上に標準のUIライブラリーを構築しとけば
よかったんですよね
わかります >>698
その割には情報が少ない＝開発効率が悪い >>704
必要な情報なんかとっくに出尽くしている。
情報は目の前にあるのにそれを得られない、
お前の脳の効率が悪いんだろw あああああああああああああああああああああああああああああああ！！！！！！！！！！！（ﾌﾞﾘﾌﾞﾘﾌﾞﾘﾌﾞﾘｭﾘｭﾘｭﾘｭﾘｭﾘｭ！！！！！！ﾌﾞﾂﾁﾁﾌﾞﾌﾞﾌﾞﾁﾁﾁﾁﾌﾞﾘﾘｲﾘﾌﾞﾌﾞﾌﾞﾌﾞｩｩｩｩｯｯｯ！！！！！！！） XAMLはXML寄りだからねー
添付プロパティとか始めると入れ子の階層がすごいことになるし
<ListView.ItemTemplate>とか<i:Interaction.Triggers>あたりは書くのがつらい、まあ慣れたけど XMLよりじゃなくてMSのXML拡張なんだよなんかこのスレってマジでにわかしか居なく無いか？
せめてAttribute Syntaxだけで記述できればマシだったがProperty Element Syntaxはツリーのネストが深くなるし行数も増えるしでいいことないからな
ユーザー定義コントロールのControlTemplateでめちゃ複雑で凝ったStyleとか最後は自分ので書いたのでも触りたくなくなるのに他人のソースとかマジ勘弁て感じ いや属性構文でもXAMLは冗長すぎて属性毎に改行するスタイルになるからどうやっても行数がヤバいことになる
これはもう定義が厳格なXMLの拡張であるXAMLの構造的欠陥なんだわ
せめてCSSを採用してればかなり違ったと思うんだよなStyleやResourceなんて誰が見たってゴミなんだよな ここはbland.SDKをmvvmのライブラリーだと
思いこむレベルの人たちですから... >>710
Flutterでもプロパティごとに改行入れるし、そのほうが見やすい FlutterスレでもMVVMアレルギーおじさん湧いてたけどあれってもしかして・・・ 批判ポイントってネストの深さとか行数とかそういうのしかないのか？ Flutter でも、他で慣れ親しんだのであろう MVVM/ViewModel を単純に持ち込んでまどろっこしいことしてるコード見る度に...
FlutterでのRiverpod盲信はWPFでのMVVM盲信と同レベル、というのは確かにその通り... MAUIはXamarin後継
WPFの後継はWinUI >>717
だからサラッと嘘吐くなよなんで知らないことを間違った知識で語るんだよ虚言癖かよ
WinUIはWin32とUWPを統合してFluent Design採用したWindowsネイティブアプリ用フロントエンドフレームワークだよ馬鹿
WinUI実装の為のSDKの名前がWindows App SDKなのになにがWPF後継だよしったかすんな 別に間違ったことは言ってないから文句があるならプログラマーらしくロジカルに反論すればいい
女のヒステリーのように感情論で叩いても負けを認めてるだけだぞ >>717
MAUIは主にモバイル向けのXamarinの新バージョン。
WPFの後継はWinUI。
もう少し詳しく説明すると、WPFの後継にしようとしてたUWPがどんなに手をれても開発者に見向きもされなかったんで
開発者のニーズに寄り添ってWPF＆UWPの真の後継として作られたのがWinUI。
しかし、いざ正式版が登場してみるとあまりの未完成っぷりに開発者たちから失望のため息が‥… 後方互換性を捨てられず既存のものを弄り回すしかできないMSの開発環境なんてどんなにテコ入れしても産廃だからうんこ
やはりここでも互換性を切り捨てて常に最新の環境に移行してくれるようにエコシステム作りとユーザーを飼い慣らしてるAppleは本当にすごい
IOS15が72%でiOS14が26%という驚異的な移行率でGoogleがMSと同じように最新OSに移行させられなくて苦しんでるのと対照的
しかもM1という驚異的なSoCでiOS/iPadアプリが一番パフォーマンス発揮できるのがmacOSという戦略性はさすが
ハードとソフトの垂直統合をここまで昇華できるAppleだから実現できるからこそだな IBMは全員Macだぞ底辺のお前らには関係ない話だな IBMがMSから捨てられ泣きながらPC市場から撤退したのは何十年前だよ？ Office 2019、2021がインストールされているかどうか取得する方法、誰かご存知ないですか？
2016までならレジストリエディタのGUIDでわかる情報は転がってるんだけど、2019以降が全く見当たらない >>729
if (MessageBox.Show("Office2019または2021がインストールされていますか？","", MessageBoxButtonYesNo) == MessageBoxResult.Yes)
{
// インストールされている（に違いない）
} そんな判定が必要なアプリ開発しとうない！いやじゃいやじゃ！ officeとかってかならずバージョンごとにCOMが登録されるんじゃないの？
しらんけど。 Windows App SDK 1.01
どこが治ったのやら 1.2あたりから手を付けるか判断しても良さそうだな。
UWPみたいに勉強しても業務で全く使うことなく消えていったゴミの前例もあることだし。 Win8のWinRTでガッツリ開発した俺から言わせればあの頃から何も変わってなくて100%産廃になると予言するわ
インシデント使って米国本社まで送ったバグが1ヶ月後に仕様で片付けられた思い出 >>723
何度も後方互換性を捨てた新しいアーキテクチャが、自社の後方互換性を維持したクソなアーキテクチャに負けるのを繰り返してるからな
捨てられないんじゃなくて結果的に捨てなかった方が生き残ってしまうだけな気もするが フルスクリーン、Win7非対応
だけで導入検討結果が出る 1.01になってタイトルバー拡張するとキャプションボタンが消えるというバグは治ったが
依然として書いてあるとおりやるとマトモに動かないわ
SetTitleBarメソッドでキャプションの領域を除けと書いてあるけど、除くとキャプションボタンが動作しない
色々実験してなんとか使い物になりそうだから良かったが そもそも苦肉の策でVS無償化やOSS化したにも関わらず一向にサードパーティ製の便利なフレームワークやライブラリないから開発環境としての魅力がないんだわ
Win32もUWPも先がないからWASMでPWAがデスクトップで動作しますよと押し売りするもノーサンキューされる
最終的に自社のエコシステムではアプリが増える可能性がないからAndroidアプリ動く様にするわと開き直ってしまう
DesktopアプリとしてAndroidアプリ動くならみんなAndroidアプリ作るだろ常識的に考えて
C#の言語仕様が素晴らしいだけに本当に勿体無い MSスタックを選ぶ最大の理由って、アプリより下の層はお仕着せのMS技術だけを盲目的に採用していればよくて、
余計なこと考えずにアプリのコーディングに集中できるという点にあるからね
そのレールから離れると全く融通が利かず、地獄が待っている
スマホアプリみたいにそもそもプラットフォームが他社のものだったりすると前提が破綻してるから、使われるわけないんだわ Linux: コンテナ技術
Windows: フォルダコピー
楽でいいよね 1.01
バグフィックスすらあまりやらん??
それともリストにしてないだけ? 少し待てばいいかなと思ったけど、バグフィックスすら力いれてないなら待つのも無駄やん それでも1.1なら・・・
1.1ならなんとかしてくれる・・・！ MS製品が使い物になるのはVer3からの法則を知らないのか？ 確かにC#もASP.NETもバージョン3でようやくまともに使えるようになった しかしこのスレほど技術的な話がないスレも珍しいな。 岩永か河井より出来る奴なんて5chにいるわけーなからな
まず文句言ってるお前のスキルを詳らかにしてみろよw ガチャゲーておじいちゃんですか？www
河井は能力を認められて自分の会社をサイゲに買収してもらえて今はサイゲ所属ってだけだよ
そもそも河井はソシャゲ用のリアルタイム通信フレームワークを作って提供してた根っからの技術屋だぞ
ソシャゲはゴミだがサイゲが金持ってるのは事実なんだからビジネスとしては賢いわな まあ751-755あたりは技術的なハナシ出来ないやろなあ WPFで業務アプリ作るとなるとウィンドウいっぱい出したいじゃん
ViewModelからWindow.Show()なんてしていいのか 業務アプリでLivetとかReactivePropertyとか使うつもりはないけど
使う現場もあるのか？まあPrismは使うが ダイアログやらメッセージボックス類はService作って出すのが最近のはやりかな
単体テスト気にしないレベルのものなら直呼びでも構わんよ
PrismとかReactivePropertyはバリバリに使ってる現場もある
今だとPrismの方は破壊的変更あったから警戒されてる 出す内容による
今時はダッシュボードといって一枚に収めるのが流行りで
複数ウインドウなんてダサいことしない 閉じるボタンを押すともう２つのウィンドウが立ち上がるような
情報に溢れたプログラムであってくださいね >>764
自分の見たのもビヘイビアでViewに機能持たせてServiceから呼ぶとかそんなんなんだよねえ
どんどんオレオレフレームワークになっちゃうけど
>>765
設定とかならflyoutでいいけど業務アプリは並べたいのよ 業務アプリは多重ウィンドウが必須なんですけどそんなこともs(ry
だからUWPでもXamarinでもReact NativeでもなくWPFなんでs(ry
まぁ出来るやつ三人いたら半年で作れるシステムを20人で1年掛けるゴミを産み落とすのが業務システムだからな
やつらは日銭稼ぐためにあえて非効率かつ非生産的な思考と手法と設計と工程で仕事してるから業務システムのプロジェクトとか今まで上から下まで雑魚しか出会ったことないね 1年ごとにUIどうなってるかな？とググってがっかりしてwpfを使い続ける事をここ10年くらい繰り返してる気がする
WinUI3はウィンドウの位置とサイズを指定する事ができないとか、マルチウィンドウに未対応とか
それはどういう気持で仕様作ってるのかね
リソース足りてないのであれば、完成してから .0リリースすべきだし
本気で無くても問題ないと思ってるなら救いようがないからチーム解体しろ WinUIのgithubでボロクソに言ってやればいい >>765
スマホアプリ程度の低機能なものなら1画面に収めた方がすっきりするし、ディスプレイサイズ的にそうせざるを得ないが、
大画面・複数ディスプレイも当たり前なPCを前提とした高機能なアプリは複数ウィンドウを積極的に活用するべき。
基本はダッシュボードタイプで、各項目をウィンドウ外にドラッグ＆ドロップすると別ウィンドウとして取り出せるようにするとかね。 >>771
MDIを知らん癖に時が20年くらい止まってる時点で相当ヤバいこのガイジwww >>769
WinUIのウインドウサイズと位置は1.0のときにはAPI出来ていたし完璧に動いている
貶す前にもう少し調べようや >>772
UI設計のイロハも知らん雑魚が話に入ってくんなw
最新のブラウザでもMDIを取り入れているものもあるし要は使い所。
UWP製でもきちんと使い勝手を考えているものは複数ウィンドウを活用している。 この底辺ガイジこれで日曜ホビープログラマーじゃなかったらIT土方なんだろうな悲しいね
もともとWindowsでデスクトップアプリ作ってる奴はUI・UXデザインがウェブから10年遅れてると言われてたがこいつはそんなレベルじゃねーゾ
何のためにXAMLにレスポンシブデザインが導入されたのかも理解せず多重窓化すべき！(ｷﾘｯとか底辺すぎてクッソウケる
お前VBでWinFormsでしょーもないの作ってるのがお似合いだからプログラムのイロハを学ぶまでROMってろ、な？ あれだけフローティングウィンドウ大好きだったmacOSでさえ最新のアプリはシングルウィンドウばかりなのに時代に逆行して先鋭的やろ！(ｷﾘｯとかドヤ顔してんの草
お前のこと今日からタイムトラベラーと呼ぶわコテ付けてくれたら暇な時にレスバで遊んでやるぞ嬉しいだろ イキっているところ申し訳ないが、WinUI3は1.01でマルチウインドウ対応したらしい
New features
We have stabilized and enabled the creation of multiple windows on the same thread in WinUI 3 applications. See issue 5918 for more information. で、WinUI3で作られたアプリって何があるの？w 論破されて悔しくて悔しくて顔真っ赤にして泣きながら言い返したくて必死でググってそれらしい記事を咀嚼も理解もせずそのまま引用するアホさが最高にイカしてるわ流石タイムトラベラー
まずWinUIを理解してないところが低脳たる所以だよな、WinUI=Windows App SDKでその目的はWin32/WPF/UWPのフロントエンドをXAMLで統一することなんだがMSのドキュメントに書いてあることがなぜ理解できないのか頭悪いって可哀想
そして今まで出来てたことができてなかったお馬鹿なフレームワークのWinUIちゃんで
『新機能。WinUI 3 アプリケーションで同じスレッドに複数のウィンドウを作成できるように安定化させました。詳しくは、課題5918を参照してください。』
が出来るようになっただけの話を、機能が実装されてるからこれ使うのが大正義(ｷﾘｯとかまた頭悪いドヤリングしてて草
じゃあP/InvokeやMarshallingが実装されてる.NETは常にこの機能を最優先して開発するのが大正義(ｷﾘｯって言ってることと同じなのを理解できない頭の悪さも流石タイムトラベラー >>783
上手くいってもXAML止まりか...
これが一番希望がない >>782
反射的に返信せずにちょっと落ち着いてみようよ
内容はその通りなのに文章のせいで説得力がマイナスだよ 正論でマウント取られたからって感情論から説得力とか言っちゃう奴こそ考えてから発言した方がいいぞ
プログラマーの癖にロジハラとか言っちゃう奴はマジでセンスないから今すぐ他業種に転職しろ あと20年は同じことで議論してそうだな
その前に寿命来そうだが ちょっとマルチウィンドウの実装方法が質問があっただけなのにこの騒ぎですよ
どんだけマウント取りたい奴だらけなんだｗ 進化してるのか退化してるのかもよくわからない
単体の機能では追加はあるが元からある機能を制限したり削ったりしてるのが何とも
今度のAPIではマルチ画面の縦横の方向情報はとれるのかな？ >>787
他人の悪口が言いたいだけの人に付き合っても無駄だよ 間違えていたりググっただけのにわかが突然スレでイキリ始める
↓
ロジカルにマウント取られる
↓
ヒステリーおこして感情的で幼稚な悪口で叩き始める
↓
IDコロコロで自演が始まりスレが大体半日ほど機能不全になる
↓
ループ 論破されIDコロコロとかいってるあたりこいつ
>>568のやつだろ
flutterスレでも最近論破、IDコロコロと同じこといってたぞ
キチガイだから無視したほうがいい まったく俺なんてserviceからメッセージボックス呼んでると見せかけて
実際は中でMessageBox.Show読んでるだけだぞ☆ >>781
WinUI 3 Controls Gallery >>796
serviceの体をなしてるなら十分や
後で必要になったら中身埋めていける >>795
機能はありゃいいってもんじゃない。
もちろん機能自体がないのは論外だが、いかに違和感なく素直に使えるかが大事。 ダイアログ出すだけで大騒ぎのアーキテクチャってなんなの？ ダイアログ出すとブロックされるからしかたなくポイもの出してる環境があるらしいよ それはともかくMeesageBox親窓指定してもど真ん中に出るのヤメーヤ
WinFormツコウタルわ もうMessageBoxよりContentDialogだな
裏に回って操作不能という事故が物理的に起こりえないのは素晴らしい MessageBoxの事故はどんな言語でもたまに起こる事故なのに ContentDialogってちゃんと親ウィンドウからはみ出して表示できるんだっけ？ MessageBoxは不親切だからできるだけ使わないほうがいいよな >>798
できた！
using MessageService = System.Windows.MessageBox;
：
：
MessageService.Show("hello"); Flutter、ネスト地獄と括弧の数合わせるの面倒くせえ。
XMLみたいに開始タグと終了タグに名前がついてれば対応がわかりやすいのに。
それかPythonみたいに括弧を使わずインデントで制御するとか。
一つの言語でUIもロジックもやるんじゃなくてそれぞれに特化した言語でやるのが正解の気がするなあ。 ネスト深いとインデント制御の方がメンテで泣きを見るよ
ネスト深くしてる時点で糞なんだがxamlは比較的マシなのは同意 こんな馬鹿なこと言うやつはNotepadで書いてる老害しかありえねーwww ググることすらできないIT土方の底辺がクレクレしてるだけだから釣られて答え教えてんなよ残念でしたーw XAMLの方が圧倒的にに行数増えるだろ何言ってんだか
ネストだってリソース全部外部に定義してるだけで参照や依存関係追う時逆にクソだるい
そして顧客の無茶な要求に応えるにはゴリゴリにカスタマイズせざるを得ないから大量のコードビハインドによって最終的に作った奴しか読む気にならない属人化の出来上がり >>822
超大手案件の300人規模の開発でラムダ式読めないから禁止と渡された標準化に書いてて俺が率いるチーム全員大爆笑したの思い出した
>行数短くても超絶分かりにくかったら意味ないのよ
こういうこと言う奴いるよねー
こういうこと言う奴はほど信じられないくらい冗長な名前付けてておまいうって爆笑すること多々ある 3流PGが4流PGを笑ってる。
レベルの低いところだな。 論破されて反論できず顔真っ赤で自演とかそうとう効いてて草 単純にラムダ乱用する奴が必ずでてくるからでは？
ラムダが50行100あり、さらにラムダの中にラムダがあってラムダ4重ネスト
しかも1つ1つが結構複雑で長いみたいな。 ラムダ式もメソッドチェーンも読めないし使いこなせないから禁止って底辺すぎるから今すぐ転職してプロジェクトから消えてほしい
レベルのクズだな
>>828
それRedditやStackoverflowで書き込んでみろよ100%馬鹿にされて日本のプログラマーは雑魚だって恥かくから いや callback hell と根っこは同じだから
上手く節度をもって使わないと見づらくなる
ならないならjsとかでasync awaitとかあっても（表面的な）見やすさ全くかわんないよねー
っとことになるわけで。 ルールを笑ってるのか、そのルールが必要な組織を笑ってるのか？
どちらにせよそのルールが必要なレベルの組織でしか仕事をさせてもらえない自分達を笑えないとね データやNECや富士通がこのレベルだからな
日本はゲーム開発以外はマジでただの半官半民の中抜き多重請負の底辺だぞ まあ、一般論だけいうとラムダ使いたがる奴の特徴。
・保守性を全く考えずいつもやっつけコード
・何でもvar使わないと気がすまない
・仕様書書かない
・テストしない
・ラムダが遅いのをハードのせいにする
・コーディングルールを守らない
・空気が読めない
・近眼
・チビ
・ブサイク
・自分を能力者だと思っている
まぁ、ほんと一般的にこう言えるってだけだけどね。 >>833
Googleのリファレンスコードがラムダ式使いまくりなんだけどw
その意味不明な妄想をGoogleのプログラマーに是非ぶつけてみて反応を教えてくれ
まぁ底辺IT土方のお前じゃ一生会えないだろうけど >>833
varの使用はMSが推奨してるんだけどwww
天才あらわるwww まあGoogleには14億株投資してるし、マイクロソフトにも10億投資してるから切磋琢磨して伸びて欲しいな。 その挙動に名前が付けられて見たら理解できるならラムダにはしないでメソッドにしたほうが良い
ラムダはぱっと見ブロックがどこまでかわからないのが多い ラムダ式のコード中身まで見る必要がないならメソッドにしてラムダで呼び出し
ここでラムダ式の中身を見ないと意味が通じないならラムダを直書きにする
でも大体はそういうことはない >>828
ラムダの乱用ってなんなん？(･ω･#) >>839
メソッドの名前がラムダ式そのものになってしまうならラムダ式の方が良いよね 取るに足らないメソッドの名前を考えなくていいのは最大の恩恵なのにな
メソッド名考えるだけで５分１０分かかる時がある デリゲートも匿名クラスも匿名メソッドも知らないし理解できない低脳なんだろ
便利な機能やシンタックスシュガー使わない屁理屈捏ねてるけど結局
それって馬鹿だから難しいこと理解できないから許さんて言ってるのと変わらないじゃん
C#使う意味ないからVB6使っとけよあとアホすぎて相手したくないからコテつけるかROMってろ 理解できないやつなんか居ないだろw
10億円すらない貧乏人とかグズなカス以外w 自分だけが理解できるコードじゃなくて他人にも意味が通るコードにしないと 自分だけが分かるコードでも半年経つとわからなくなることあるよね。 >>833
もしかして、foreach も禁止とか？ >>852
消去法でまともなのがwpfしかないんよ もうMicrosoft.Toolkit.Mvvmが主流なんじゃないの WinFormsより楽だよね
MVVMにこだわりすぎなければ レイアウトが固定ならWinformでもいいんだが
リサイズできるウィンドウやら多言語化やらで柔軟なレイアウトにしなきゃならん時はWPFが楽なんだよな >>855
せめてtemplate packだけvs2022に対応してくれってやつに忙しいから後回しって回答してたしやる気は一応あるんじゃないの windowを小さくされたらコントロールを収納したりしないと使えないでしょ？ Webのレスポンシブとかめっちゃ使い勝手悪いもんな vscodeが複数windowに分離できない以外は遜色ないからweb技術のuiが悪いわけではないと思うが スクロールバーを細くしたり消したり、タブをクリックしようとしたら
いきなりXボタンが現れてタブが閉じてしまったり、糞みたいなUI考える馬鹿が多くて困る。 >>870
リボンってカスタマイズ可能なメニューバーなんだけど、わかってる? FAQ:メニューバーの表示方法
ほんと馬鹿はなんでも隠したがる。見た目しか考えてねぇ。 >>872
リボンUIはメニュー「バー」自体は常に表示されているんだが？
少しは考えてから反応しろよ。馬鹿がバレるぞ。 VSCodeのコマンドパレットはメニューバーより遥かに使いやすいけどな
もうコマンドの数の多いアプリは全部これにしてくれ メニュー+ツールバーがいかに便利か。リボンUIがいかに糞か。
VSとMSOffice使えば分かりますな。だがアホは分からないらしい。
カスタマイズできるメニューバーだ!! バーは常に表示されている!! www メニューが多すぎて探し切れない→検索ダイアログから機能(コマンド)をインクリメンタルサーチすればいい
この発想ってIMEで変換入力している言語と相性が悪い
代わりに利用されるのがピンとかお気に入りという機能
リボンUIではクイックアクセスツールバーと呼んでいる、あんなでかいアイコン要らなかったのだよ・・・ >>874
いや、コマンドの断片でも覚えてないと呼び出すことすらできないから、これのみだと使い物にならない。
>>875
>メニュー+ツールバーがいかに便利か
そう、リボンってまさにメニューとツールバーの融合なんだよね。便利でしょ？
>>876
クイックアクセスツールバーを育てるための元が必要。
こういうコマンドがありますよって中からピックアップしてクイックアクセスツールバーを育てていく。
使用頻度の高そうなものや重要なものは大きく目立たせるのはUI設計の基本。 メニューとツールバーの融合にも失敗してデスクトップとモバイルの融合にも失敗するとか、
MSはほんと無能なUIデザイナーを雇ったな。 デバイス違い、スマホとPCでレイアウトが違う →分かる
リサイズでレイアウトを変える →変えんな!! 使いにくいわ!! >>876
>>877
ああ、確かにコマンドパレットは日本語と相性悪いというのはあるかもな
開発ツールは基本的に英語で使ってるから全く不便に感じたことなかったわ >>879
> リサイズでレイアウトを変える →変えんな!! 使いにくいわ!!
なにが使いにくいのかわからん
ウインドウサイズ小さくした時にスクロールなしで全ての機能にアクセスできるのは普通に嬉しいが メニューとツールバーの融合は成功してるだろ
TabbedCommandBarがある >>878
昔はデスクトップとIE4の融合にも失敗した
やらなくていいことを積極的にやる無能
twitterにもいるけど 当時、MSはデスクトップに天気予報や株価とかニュースを表示したかっただけなんだよね。 デスクトップに好きなサイズ・レイアウトでフォルダウィンドウを埋め込めて便利だったけどな。 ..net7 preview2ブログにNativeAOTが実験状態からメインラインに乗るって書いてあったけど
UIフレームワークはうんこでこのアンバランス あれ？commandってviewmodelに書かないとダメだったっけ？
converterみたいに共通化出来なかったっけ 1.1 Preview1出たけど、誰か試した人いる？ 君が試してレビューしてくれ
俺は何もする気がおきない！ このままオワコンになりそうで触る気が起きないわ
やる気も感じられないし ダークモード対応してるのはいいよ
あと、OSでちゃんと管理してくれるアプリになるのがいい MSってネーミングセンスゼロだね
.Net5、.Net6って名前にしたから検索と相性が悪い >>899
そもそもWindowsからしてセンスゼロ Windowsっつーか、マイクロソフトがダサい
アップルがちょっと洒落たことをすると、すぐ真似をして自滅する 7、8、9、10.って続けてくれるならいんだけど
どうせまた途中で.NET DXみたいに変な名前に変わるんだろ
名前そのものはどうでもいんだけどコロコロするのはやめろ 今は5系と6系だけだからまだいいけど、11、12みたいになってきたらランタイム全部インストールとかダルすぎる。
C++ランタイムはバラバラに入れさせるとかアホなのってことである時点から2015-2022は一括で、みたいなインストールの仕方になったが .NET5は来月でサポート切れるから心配しなくていいよ 偶数のだけ追っていけばいいんじゃないか
どうしても今すぐ使いたい機能がない限り しかし７でNative AOTが出てきたら使わざるをえない .net xとかvisual studio codeとか、なんでこうググりにくい名称にすんのよっていつも思う R「せやな
Go「DotNetXって新しい言葉作ったらええ こうやって不完全のものをどんどんリリースする風潮、そろそろやめにしてほしいねえ
ゲーム程度ならまだしろ、企業向けアプリはどうすりゃいいのってなる バグフィックスならどんどんリリースしてほしい
ただ、WinUI 3のWinUI 2の機能の移植さっさとすすめろよ WinUI 2.7.2
WinUI 2.8まだー?2.7からもう半年過ぎてるんですが?
WinAppSDK 1.0.2 今さら2.0とか3.5の人がいるとは思えないから、4.8で統一じゃないかな
.NET Coreの方はどんどん新しいのが出るわけで、保守には向いてない と、思うだろ？
4.8はvistaやオフライン環境で動かないしvs2019以上必要だから嫌われる
理不尽な世界なんだよ XPなんか使う環境あるわきゃねーだろプギャーしようと思ったら
先週電話でライセンス認証したばっかりだったわ
まあそういうこともあります Vista…？
まあUI系は.NET Frameworkでいいわな
ドメイン層やインフラストラクチャ層はNET5,6で作ったほうが色々恩恵がある。 >>917
2017Expressでも4.8使えるが何か問題ある？ すまん。VS2019は4.8じゃなくて別の依存だった。忘れてくれ
VS201７でもVS2012でも4.8使えた >>917
オフライン環境で動かないってどういう時
インストールかな 急いでるならWinUI 2の方が安定してるからな
もちろん、sandbox環境の要件でokなら
まったり待てるならWinUI 3でいいんじゃね Microsoft.Toolkit.MvvmのRelayCommandをボタンのCommandにBindingしたとき、Enabledを切替えるには、NotifyCanExecuteChanged()を自分で呼ぶのが普通の使い方ですか？
例えば、プロパティAとBがtrueのときにボタンを有効にしたい場合、AとB両方のPropertyChanged時に、それぞれNotifyCanExecuteChanged()を自分で呼ばないといけないのでしょうか？ >>925
.NETCore以降ほんと切れるのはやいよな
こんなの個人で作るツールにしか使えない でも個人で作るツールってクロスにする意味ってあんまりないんだよね。
基本的にWin使いならWinばっかり。
だったらファイル少なくて済む4.8のが使いやすい。
複数のOSを使う人も居るが、エディタとブラウザ以外は
アプリを共通とかコマンドを共通で使うとかやってないんじゃないかな。
ただの無駄だし。
今のところAzure functionくらいかな。 別に瀕死じゃない状況で勝手に瀕死になりうる判断を下し
自ら墓穴を掘るのがMSらしいなあ 普通にVScodeを作った開発環境の
MS版をリリースしてくれれば良かったんよなーー 4.8にするくらいなら6でよくないか？
Windows 10プリインストールって3.5だし 11がリリースされてもう半年経つのに未だにAcrylicやMicaの最新のネイティブフロントエンドに対応しない公式SDKのWindows App SDK(WinUI3)
もうこれだけでMSやる気ないってわかるうえにサードパーティで誰も作らず既にコミュニティが過疎ってて相変わらずオワコンなの草
FlutterはWindows Desktopに対応したばかりなのにサードパーティがAcrylicやMicaを独自実装したパッケージをリリースしててコミュニティが超活発で便利なフレームワークやライブラリ沢山あって盛り上がりがわかる
MSの開発環境の一番ダメなところがこのコントリビューター不在でコミュニティが盛り上がらずいつまで経ってもエコシステムが構築されないところなんだよな
だから便利なパッケージだけでなくノウハウやナレッジもなくて利害関係のある案件でしか誰も使わないから不人気なまま負のループ winuiは最大公約数のライブラリ作ろうってプロジェクトだから・・・ 最大公約数がメタファーとして適切だとは思えないけど高度に抽象化された.NET用意したから後は開発者が便利なフレームワークやライブラリを勝手に作ってコミュニティ盛り上げてね(^^)とMSに放置されてオワコン化した黒歴史をまた再現するの？って話なんだが 便利なフレームワークやライブラリがもう大体揃ってて誰も困ってない可能性があるな たいしたことやってないならそうなんだろうな
客からの要件は大抵有償コンポーネントないと無理って案件ばかりだけどね
これが他の人気の開発環境なら無償で揃ってるんだけどなーってことが多すぎる
特にXamarinは有償でも選択肢が用意されてなくて開発途中で座礁するからおすすめしないCOCOAの惨状見ればまともな開発者ならすぐ気付くだろうけど Xamarinはあのおばさんがでしゃばってるから見ててキツいなと遠巻きに思ってたらそもそも誰も使ってなかったっいう >>932
いい加減な。Windows10初代でも4.6が入ってるだろ
4.8はMay 2019 Update（1903)から入ってる flutterのfluent_ui
メンテナー募集してるな
これが個人の限界 古田はスマホ用に留めておくのが正解だろうな
デスクトップはスマホと違ってOSとの親和性が求められるものだ 古吉
田田
〜 どの家にもアンテナはあるものです 〜 >>932
3.5ってのはまず大嘘だし、4.8と6じゃ寿命が違う。
OSとセットでずっと使える安心感と、リリースされたそばからサポート切れを気にしなきゃいけないせわしなさ。
最新のC#の機能使える快適さとバージョン移行にかかる金、天秤にかけるまでもない。 6も4.8も同じだよ
どっちも長期サポートだしどっちもすぐサポート切られる運命 リリースされたときはこれが最後のWindowsだと発表されてたWindows 10ですらサポートはあと3年（らしい）
4.8のサポート終了はOSの寿命（だったらいいな）だろ。未定だと思うぞ 後継が出ない最終バージョンの4.8と後継が約束されている６は状況がまるで違うだろうに 別に違わなくないのではw
net9でnet6のアセンブリ動くわけじゃないし。
あくまでも同じクラスがあってリダイレクトできたら動くってだけ。
それば別にnet6からnet4.8を参照しても動きますよ、リダイレクト出来る範囲はね。（.net standardに近い範囲に事実上限定されるだろうけど） .NET 7 から NativeAOT だから .NET にしておかないと移行作業大変だよ NativeAOTになってもパフォーマンス良くならないって検証結果しかないのが.NETって感じだな
しかも日本語の記事がまったくなくて既にMSの開発環境なんて誰も興味ないのがわかる
結局VBやF#なんかが足枷になってIL捨てられない仕様だと最適解(笑)しても無意味なんだよな
.NETのバイナリサイズが1/100になって誰が恩恵受けるんだって話 バージョンアップのサイクルの短さはMSに限った話ではないよな
保守的なニッポンのIT企業はヒーヒー言いながら追従しないといけない
IDE出すカネを渋ってる場合ではないのだ よく分からないけど、「サポート終了」になると対象バージョンのSDKやランタイムがDLできなくなるの?
それとも、ホットフィックスを含むアップデートが提供されないってだけ? サポート切れたら
ダウンロードや提供はある（ライセンスの関係で提供終わることもある）
ホットフィックスなどのアップデートはなくなる（致命度によってアップデートくることもある） 他をよく知らないけど、そもそも.NETFrameworkぐらい長く使い続けれるのって珍しいんじゃない？
正直多くを求めすぎだと思うわ 5以降の.NETって4.8以前とはデプロイの考え方が全く違っていて、システムにランタイムをインストールしないのが大前提なんだけど、勘違いしてないか？
アプリに好きなバージョンの.NETをバンドルするから、セキュリティパッチなんかいちちち気にしないで放置しときゃいいんだよ
お前はC++で作られたアプリにスタティックリンクされてるCランタイムやらQtやらの脆弱性なんか気にして使ってるか？それと同じだ スタティックリンクされてるのの脆弱性を気にしないといけない時代だし
システムにインストールされてるのの脆弱性を気にしないといけない時代なんだよ
いまだに脆弱性なんてまったく気にしてないとこも多いけどな WebならわかるけどここWPFスレだろ？
>>960は一度.NET6の全マイナーバージョンのリリースノートを読んで、自分のWPFアプリで現実的に問題になりうるものがどれくらいあるか調べてみたらいい
それをしないでただ最新使ってりゃいいと思ってるなら、最大の脆弱性はたぶん>>960自身だぞ wpfにもWebview2みたいなのはあるだろ
そりゃ現実的に問題になることはまずないが
「脆弱性なんか気にして使ってるか？」なんてやつに言われたくはないｗ そういえば昔はこういう流行り物の記事、俺も書いてたな。
最近「いかがでしたか？」と同じ扱いを受けるのでやらん。 早くリリースするのはいいけど、注目されている機能は次のリリースまで後回しとかするから下手くそだなーとおもう
Win11のエクスプローラーにタブが付くのだって11のリリースに間に合っていればもっと注目されていたんじゃね 間に合ってればね
開発ってそううまくいかないのは携わってれば解るやろ MSほどのリソースがありながらなぜかラピッドリリースができなくてバグくてもテストをかねて開発中の新機能をどんどん追加するReactやFlutterに速度感でまったく勝ててないからな
そもそもWin11ですらリリース半年経ってるのに未だにWinUIがAcrylicやMicaに対応してないという意味不明なロードマップとスケジュールがマジ下手くそというか頭悪い >>965
基幹系のアプリケーションや、OSのバージョンアップに対応する必要のあるアプリならわかるが、OSだぞ？
11出さないと誰かこまったのか？
みんな困惑してるだろ >>967
経営者、企業のスタンスで言えば「11リリース」は10年越しとかの経営計画で盛り込むやろけど
そういう一部の機能までは必要ではないと判断しうるやろ
OSだろうが半年後マイナーバージョンのアップデートで追加する予定の機能を、メジャーバージョンリリースに無理に盛り込むことはしないやろ
そして経営計画で看板商品のリリースを半年遅らせることも普通しない
むしろ11の普及が遅れるであろうことを見越してそのタイミングと計画してたかも
MSなりに積み重ねたナレッジで動いてるだろうよ 10Xを急遽11にしたのはばれてるからなぁ
質素なスタートメニューも「低スペック向け」とか言われてたけど今は発禁だね >>968
そのMSのナレッジとやらでWinUIも普及するといいね とりあえずWindowsアプリにマテリアルデザイン適用するの止めようか。
AndroidアプリをiOS風デザインで作るのと同様、ダサいから。 Win32コントロールに準拠したデザインにしろってことだろ
WindowsはどのソフトでもUIが統一されていて、それによって誰もが初見でアプリを使えるというのがメリットだった
それが最近はなくなりつつある Fluent Designを知らないMaterial Design脳おじさん登場 url開いたら頭に「アプリの設計と Fluent Design System の概要です。」ってあるだろ
そいつは本質的にマテリアルデザインと変わりゃしない >>977
マテリアルデザインって概念じゃなくてグーグルの作ったスタイルの固有名詞だよｗ グーグルはなんたらデザインとかでドヤる前キーボードで全て操作できたWindowsのUIデザインを学ぶべきだった >>978
開発者以外にも認知されているレベルのこと知らないってGUIアプリケーションの開発者としてヤバいよなｗ 本質的には同じものだって言ってるだけじゃん
日本語学んだ方がいいよ 全く異なるデザイン言語を同じものってw
技術者やめたほうがいいぞw 結局WinUIは主流になるの？
今から作り始めるのをWPFとWinUIどっちで作るか迷ってるんだけど。
機能的にはWPFで足りるけどWinUIのほうが明確に優れてるならWinUIにする。 WinUIが主流になることはあり得ないけど、かといってWPFも全然主流ではないんだから好きなの使えばいいんじゃね
WPFはユーザー層は薄いながらも十分に枯れていて、まあ今無難に使える技術ではある
WinUIを選ぶならまともに使い物になるレベルに達するまでにMSが投げ出さないことを祈ることだな WinUIを使いたいところだけど、バグもあるし正直まだ信頼できる製品を作るには足りてない感じ
1.1を待て
1.0時点でちゃんと使えるものを出してほしかったわ MS製品は3.0でやっと使い物になる法則を知らないのか？ 本当あいつらすぐ投げ出すから手を出さないのが一番
やるなら完成してからでいい たぶん人事とリンクしてるんでしょう？MS の出鱈目ぶりは >>984
WinUI3はまだまだバグが多すぎるからApp SDK 1.2ぐらいまで様子見するのがお勧め。 >>990
それが一つの指標よな。
MS自身がWinUI 3を積極的に使うようになったらある程度信用できる。
そんな未来は来ないような気もするが。 Officeは既にクラウド化でサブスク商売する方向だからWeb前提だろ。 OfficeもTeamsもSkypeもReact NativeでVSCodeはElectron MSがUIのデザインをスマホ寄りな感じに変え始めたのって8の時だったはずだけど、
正直よくなったっていう感じはしないし、OS内部ですらいまだに新と旧が混在してるし、
デメリットのほうが上回ってると思うんだが このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 87日 12時間 1分 26秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
