◎正当な理由による書き込みの削除について： 生島英之とみられる方へ:
WPF(.NET, WinUI) GUIプログラミング Part29 YouTube動画>1本 ->画像>11枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1649621434/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
WPF(Windows Presentation Foundation)について語るスレ。
前スレ
WPF(.NET, WinUI) GUIプログラミング Part28
http://2chb.net/r/tech/1642624840/ 関連スレ
Windows 10 UWPアプリ開発Part 3
http://2chb.net/r/tech/1627556967/ コードを貼る場合は以下のサイトの利用をお勧め。
https://ideone.com/ 確か同じくらいに計画が発表され正式リリースも同じくらいだったjjetpack composeの方はmaterial 3の対応でかなり仕上がっきてるのに
winui 3ときたら..
デスクトップアプリ何で作る？
最低要件（最低限これくらいは満たしてね）チェックシート2022
============================================================================
チェック用アプリ仕様:
アプリ上の"はろー"ボタンをマウスでクリックしたらメッセージボックスで"わーるど"を表示する
(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以上が合格ライン（当然点数は高ければ高いほど優秀）
このチェックリストを三人でトリプルチェックしたら間違い無いな
>>6 2022年の基準としてはやや甘めの設定だろ。
この程度クリアできなきゃゴミ。
仮にこの数値の2倍・3倍になったところで気に留める人なんざほぼいない
サンディーおじさんみたいな骨董品PC使ってる人は知らんけど
ただのオナニー
その要件満たしたところでメリット無いしね
メモリやストレージより今どきの見た目のアプリがどれだけ簡単に作れるかだな俺は
技術者としての適性もチェックできるな。
こいつがパフォーマンスの悪い、メモリリークしまくり、バグだらけのポンコツプログラムを作るのが目に浮かぶようだ。
その要件を満たした
パフォーマンスの悪い
メモリリークしまくり
バグだらけのポンコツプログラム
が作れるから
そのチェックには全く意味が無い
今どきZipで固めてユーザーが解凍してショートカットを作るソフトが最新版ですかｗ
特にこだわりがなければClickOnceでいいんじゃない、自動更新してくれるし
clickonceでバージョン管理ツールを
配信してからね
どこに入るかもわからんClickoneとか使い道すごい限定されるような。
>>19 まあデスクトップ系の強みってローカル環境に作用できることだからね
どこにインストールされるかわからないとパスを調べないといけないし面倒
それならWeb系でやるね
MSIX Coreって誰か使ってんの？情報少なすぎ。
ClickOnce、Edgeで動かない報告がちょいちょいあるんだけど
同じ会社なんだから動作確認くらいしてくれ
>>16 単に最低要件だから、ストア経由で配布したいって要件ならストアで配布すれば良い。
「ストアでも配布できる」と「ストアでしか配布できない」は天と地ほど違う。
今はセキュリティが厳しいからストア禁止、管理者権限なし、証明書インストール禁止、書き込めるのはユーザー用に用意されたフォルダーのみ、ネット接続も極度に制限、なんて環境はざらにある。
機能云々以前に使ってくれる環境から外れてたら意味がない。
>>23 ストアとZipのハイブリッドでみんなが知っている最新アプリのタイトル教えてくれ
>>16 シングルバイナリ作って配布してるワイを馬鹿にするなｗ
winui3、必要な機能は一通り揃って趣味アプリなら使えるようになった？
まだやろ
Window絡みのAPIとかそっち優先で
コントロールはWinUI 2.6ぐらい機能で止まってそれがらみのバグフィックスもWinUI 3方に移植されてないやろ
>>29 全然。
未だに素早く動かしたり連打したりするとパフォーマンスが落ちたりハングアップする品質。
今からあと1年待ってもそれほど状況は好転しないかも。
>>31 1.02 1.03を試していないかブログなどの又聞きじゃね？
1.03では表示系バグはかなり残っているけどパフォーマンスは改善している
>>32 1.0.3の話だぞ。
>1.0.3では表示系バグはかなり残っているけど
パフォーマンス以前の問題じゃん。実用アプリに使ったらまずいゴミってことじゃん。
書いてて恥ずかしくないのかね。
WindowsFormが出た頃もこんな感じだったのかね
>>34 表示系と言っても、Dark・Lightの切り替えをアプリ内でやると中途半端な状態になるコントロールがいくつかある
アプリ内で切り替えないか、異常動作が起こらないように工夫すれば十分やっていける
全部無能MSのせい
馬鹿なんだから身の丈に合わせてWinformでも作ってればいいのに
(1)目立ったバグ（特に表示上のバグは致命的）
(2)パフォーマンス上の問題点
(3)致命的な機能不足
がないレベルが1.0正式版として期待される最低限のラインなんだが、全滅。
これらをクリアして初めて採用検討候補に入る資格を持つ。
(3)なんてWPFとUWPで出来ていたことができるってのはあくまでスタート地点で
それに加えて新しい何かがあることを期待されているのに、
過去にすら追いつけてないって酷すぎだろ。
wpfのデータバインディングとかを使い易くしてwpfを開発再開して欲しいのが本音
wpf以降はスマホ意識しすぎてエレメントがスカスカだから好かん
Xamlの場合はこれやろ
Preview2をちょっと弄ってみたが、やっとDark/Lightのバグが解消された模様
TextBoxの実害はないけどムカつくやつはそのまんまだったな
リアクティブな感じを素直にチョチョイと実装できるようにしてほしい
昨日眠る前に見たMSのロードマップにwinformsの項目が記載されてるけどWPFは書かれてなかった
winformsは結構新しいコントロールを入れる予定があるんだなと思ったけどWPFは？
>>55 やっと2022で使えるようになったのか、嬉しい
.NET6なんだけど
Task.RunでBitmapDecoder.Createで画像読み込み → Freeze()してUIスレッド
ってのが動いたんだけど
STAスレッドじゃないと駄目だった記憶があるんだけど気のせい？
オフィスに出社することは｢時代遅れで非生産的｣…リモートワーク希望者は10倍に増加
サイボウズが副業を真っ先に解禁した理由。社員や会社のメリットとは？
｢複業を解禁しなければ人も企業も成長しない｣複業全面OKのサイボウズ社長と実践社員の本音対談
『サイボウズ』は社員満足度の高い「働き方改革」をなぜ作れたのか
サイボウズ式：サイボウズで複業。収入源は3つ──そんな私の「パラレルワークはじめての確定申告」
超ブラック企業だったサイボウズが、全社員と「ザツダン」してわかった“見えない不満”の本質
サイボウズの「100人100通りの人事制度」を実現する働き方改革とは?
Template Studio WPF使ってみた。
これで十分だわ。
WinUIが使い物になるまで何年も待つ必要ない。
グループウェアはGoogle Workspaceもなかなか
Final .NET Foundation Version Latest
This is a procedural release.
Prism is leaving the .NET Foundation. Before making any changes to the Prism repo, we are archiving the current source code which is under the .NET Foundation.
Any code committed after this "Final .NET Foundation Version" release is no longer considered part of the .NET Foundation.
https://github.com/PrismLibrary/Prism/releases/tag/DNF Prismは.NET Foundation.と縁を切った。一体何が有ったんだろうか
もはや事実上個人の趣味プロジェクトになってたから妥当でしょ
コミッタにとっては.NET Foundationにコードを寄贈し続けなきゃいけないだけで何のメリットもない
PrismだけでなくRxなんかの過去C#で大人気で他環境にも影響を与えたものすべて.NETのメンテをやめて他の開発環境でコントリビュートしてるからな
もうMSが.NETを予算縮小のために便宜上OSS化だけしてリソース減らした時点で終わってんだよ
そしてこんな面白い記事を見つけたので.NETにしがみついてるやつらに是非読んでほしい
https://matarillo.hatenadiary.jp/entry/20140418/p1
;『オープンソースは報われない仕事。でもやるんだよ。』
オープンソースとは、おおむね報われない仕事だ。Microsoft .NETコミュニティの場合、時々むなしくなったりもする。ボランティアが全然見つからないことがあるのだ。多くの人々が、デフォルトのものやVisual Studioに同梱されているものを使う。RailsとかNodeの場合は、企業の支援もあるが、プロジェクトはコミュニティが駆動しているという認識がある。現実は中間なのだが、Microsoftのスタック上に構築されたオープンソースプロジェクトでは、ボランティアが「我々は、出荷されたものをただ使うのみだ」なんて言うことがある。
PrismもRxも個人の趣味レベルのアプリでしか使われてなかったからな。妥当。
PrismはMS公式ともいうべきものが出てきたから
もうお役御免
こないだのlog4j,color.js騒動から見るに、OSS界隈も地獄だな
.NET自体が右往左往してるから、対応する人も大変だろう
mvvm.toolkitにはRegionManager相当の機能がないのが少し問題ですね
代用はTemplateStudioがコード生成してくれるからそれを使うのが良いのかな？
俺はよわよわプログラマーなのでTemplateStudio頼みになってる
2022対応してくれたようなので安心した
UWPやWinUI製のアプリってWPFと比べてやたらめったらクラッシュしやすい印象。
イレギュラーな操作じゃなくてもバンバン落ちる。
なんでこんなに脆いん？
誰も使わないからバグが取り切れてないだけでしょ
WPFも初期は冗談みたいなもんだったよ
WinUI3は色々あるけど、UWPは枯れているからバンバン落ちることはないんじゃね？
WinUI3で気になるのは、初期化時にページ内のすべてのインスタンスが確保される前にイベントが走るバグ
タイミングによって落ちたり落ちなかったりするんだよな
某UWP製ソフトはウィンドウサイズ変えただけで落ちたぞ
>>66 個人の趣味レベルのアプリで使われてるほうが驚きや
xamlのデバッグてどうやるの？ブレーク出来ないので変数の状態とかもよくわからない。
Live Previewがあるだろ昔はそんなものなくてLogicalTreeがVisualTreeになるのをイメージしたりしてデバッグしてたんだぞ甘えるな
Bindingは違ったものバインドしてもサイレントでバグが発見しにくいってのはあるからそれじゃね？
x:Bindで幸せになれるけど、全取っかえは無理だったりするな
xamlはbindingで誤字あってもエラーにならないのでデバッグ面倒くさいね。どうにかならんの？
>>85 VS2019でXAML バインド エラーってデバッグウインドウが出来て随分マシになった
x:Bindがバックポートされたら嬉しいけど、まず来ないだろうね
今週待望のbuild 2022だけど
.net maui正式リリース?
winappsdk 1.1正式リリース?
どっちもゴミだけど
.Net6使ってみたくてVS2019からVS2022に変えたらデバッグ実行で固まりまくってまじ困るわ
>>91 WPFだよ
VS2022はコードスニペットもおかしいな
WPFは新しめのVisual Studioの方がより快適。
どんどんIDEのサポートが強力になってる。
実は32bitPCだったとかそういうオチだったりして
原因はよく判らんが、プロジェクト作り直してソースファイルをコピーして再構成したほうが無難ではあるな
wpfて遅いの？
gpuでちょっぱやになってるのかと思ってた
最終的なコンポジションにGPUを使ってるとは言えるんだけど
その前処理の段階でパフォーマンスを台無しにしてるからな
速くなるように作ることができる。
何も考えずに作って速くなるわけじゃない。
(o´･ω･`o)
uwgもオワコンだからwindows app sdkをやればいいの？
Windowsのデスクトップアプリなら好きな実装で開発すればいい
結局WinFormsでも最新のUI実装可能したのがWinUI3xなんだからな
クロプラ開発ってことならMSの開発環境はハイリスクすぎてとてもじゃないが選択肢にならないしおすすめしない
結局マルチプラットフォームじゃなきやwinforms使っとけばいい？
画面のデザインこだわらなければwinformsでいいのでは
だからWinFormsでFluent Designが使えるようにしたのがWinUI3xだってすぐ上のレスで説明してんだろ低脳雑魚グラマーがレスも読めないのか
>>108 どれに言ってるのかしらんが仮に105ちゃんに言ってるのだとしたら、
18秒で104を読んで書き込んでるのではないんじゃなかろうか、とワイちゃんは思うぞ
>>103 windows8からこっちずっとその状態ね
まぁMS社内で予算使い切るための作られた仕事だからな
担当者が変わるたびに新しい開発環境ぶちあげて放置だから誰も使わなくなったってこと
GoogleとかFBとかTwitterは自社で実際に使ってる言語やフレームワークをOSSで公開して人気が出てコミュニティの活動も盛んでちゃんと長期間メンテされてるわけだがwww
まず、Microsoft自体が力入れている
ここが最低ラインなのにWinUIも前は4カ月ごとのメジャーリリース?だったが
最近は6カ月ごとになってMicrosoftの片手間プロジェクトだから
>>102 xaml手書きできるか?
楽勝だぜ!あとバグだらけで不安定でも気にしないぜ!⇒WinUI
ポトペタじゃないと無理ですぅ⇒WPF
わざわざ生産性低い方選ばんでも。
winforms使うぐらいならwpfで楽した方がいい。
Webview2でReactとか使われてる方いらっしゃいますか？
winformsよりXAML手書きの方が楽だと思うなあ
VSが勝手にプロパティ変えたりすることあるからformsもうやりたくないよ
XAML慣れないとか言ってる底辺雑魚グラマーがWPFのスレにいてわざわざ『xaml慣れないし嫌い』とか捨て台詞吐いてるのクソウケるwww
xaml慣れないし嫌いwww
要するにVBでWinFormsしか理解できない底辺雑魚グラマ老害ってことだろ
俺なんて言語やフロントエンドFWの構文なんて1日でマスターするぞwww
こういう底辺雑魚グラマってフルスタックエンジニアは神とか思ってんだろうなwww
理詰めで論破されて悔しくて悔しくて顔真っ赤でIDコロコロ自演とか俺だったら恥ずかしすぎて自殺しちゃうね
って言わないの?ww
>>122 >xaml慣れないし嫌い
これスレのテンプレに入れるわwww
マジ名言クソ雑魚具合がよくあらわれてるwww
そいやxamlのタグとかパラメータとかオプションの一覧とか逆引きとかって、
日本語ドキュメントであるの？
XAMLのオブジェクト要素をタブとか言うやつは100％にわか
なんかにわかしかおらんうえににわかがシャシャってくんなこのスレ
技術的な考証とかディスカッションとか一切ないなマジでレベル低いというか存在意義がないな
すまんこのスレ検索しても
>>127以外「タブ」が出てこないんだが
WinFormしか使えないおっさんだが、xaml覚えるくらいならReact覚えたほうが将来性ありそう
OfficeもReactNativeで作ってるらしいし
wpfを素で使うから使いにくく思う
prismだの色々補助ライブラリを入れればだいぶ使いやすくなる
素のwpfで社内業務アプリを作る
と生産性はwinformsより低くなる、俺的には
>>131 WebやるつもりがあるならReact覚えておいて損はないと思うが、あっちはあっちでデスクトップより
変化が激しいからついていくのはそれなりに大変だと思う。
Formsしか知らなくて今後もデスクトップしかやるつもりがないならReactはやめとくのが吉。
>>134 デスクトップしかやるつもりなくても
寄らば大樹の陰
企業が自分達が使うために作った技術で、使っている人口が多い方が良いと思う
WinFormもどう頑張っても廃れていくし
Windows用デスクトップアプリをざっくり作るときは
WPFでWinFormsのような作り方が楽な気がする
LayoutTransformでレイアウト崩さずまるごと拡大できたりして、老眼の人にもアプリ使ってもらいやすいし
>>135 winformsは廃れないでしょ楽だし簡単だし
>>135 もう決めているならがんばれとしか言いようがないが、いまどきFormsしか使ったことがなくて
これからXAMLとReactどっち覚えるかなんて言ってる人にとってはハードモードだと思う。
>>138 うん頑張るしかないんだよ
MSのUIフレームワークには愛想が尽きた
>>131 WinFormsしか使えない人が何でWPFのスレに出張って来て管撒いてるんだよ
スレチのWinFormsが廃れる廃れない等どうでも良いんだが
こんなもの使わないと主張する方々が集まってなぜかム板の中じゃそこそこ勢いのある不思議なWPFスレです
基本今の5chは技術力なんて無きに等しい住民だけやからねえ
わいも含めて
>>141 可也アスべ臭い人がいついているんだよな
>>139 偉そうな事言いたいだけでReactを頑張る気は無いだろw
実際に移行した人が言わないと説得力無いぞ
頑張るもクソもReactもFlutterも簡単なんだがwww
言語はJS(TS)とDartというくそ簡単なLLでフロントエンドフレームワークはJSX(TSX)とそれをパクったWidget
まともな脳みそしてれば1日あれば習得可能なものが頑張るとか苦行とか素直に頭が悪くてごめんなさいって言え馬鹿がwww
そもそもXAMLすら習得できない馬鹿がこのスレで茶々入れたりしゃしゃってきてんのがクソウケるんだがwww
ReactはいいけどReactNativeは駄目
開発者アンケートにあった「ReactNativeのバージョンアップは地獄の門の向こうで作業しているようなものです」っつーコメントを知らんのか
そんあのReactに限った話じゃねーしそんなの開発者あるあるのmemeの一種なんだよアホwww
そもそもネットの記事をドヤ顔でしらのんかとかクソワロタおまえがReact Nativeさわったことないのバレバレwww
ずっとタブだと思ってて、ここでやっとタグだと気付いたんだろう
誰しも勘違いはある
こんなに反応があるとは思わなかった
なんかごめんなさい
>>137 WPFの方が楽だぞ。
多機能だから全部覚えようとしたらそりゃ大変だが、
便利で学習コストが低いものだけピックアップして習得すりゃいい。
無料の入門書
https://zenn.dev/apterygiformes/books/470ba1042dfbef ReactもVueも入門したけど自由に配置できないわ・・・
>>152 ありがとう読んでみる
作りたいものはテキストボックスとコンボボックスとデータグリッドビューなどのコントロールが全部で20個もない社内業務アプリなんだけど、普段は上流ばかりなのに戯れでトライしたら良くわかんなくて。。。
ネット検索してこのスレに辿り着いて役立つ何かが得られるかもと書き込んだらwpf使いの大天才にコーディングがヘボで頭悪いと言われたら、まあそうなんだろうね、としか言えない(笑)
こういうアプリでもwpfならコーディング少なくて済むの？winformsに対するメリットが分からない、速度もwpfの方が遅いみたいだし
WPFが登場して10年も経つのにいまだにFormsを使ってきた御仁が
なんでいまごろFormsの衰退を心配し始めたんだろうか。
色んなワードをあちこちで見かけるから他の良い選択肢になりうるかどうか気になっただけ、調べたり試さないで初めから除外するのはさすがに気が退ける
>>136 WinFormがそういうの使えるようにしてくれればいいんだけどな
大量のWinForm画面をどこにどうやって移行するか悩ましいわ
>>158 黒人は経験に学ぶ
じゃあ日本人は？
学ばないだろうが！
>>154 コンボボックスとデータグリッドはformsで簡単に出来ることと同じことをwpfでやろうとしたら、確かに難しいかもな
まずは、wpfなら簡単に実現出来る仕様で実装する方が良い
>>136 ほんそれ
WPF使ってXAML使わないのが正解
WPFが登場して10年も経つのにいまだに普及しないからなぁ
Formsが普及しすぎてWPFに乗り換えるメリットが少ないから。
2006年が10年前とかおかしいだろ
もうちょいで登場から20年
AndroidStudioはXAML使ってるけど、PC用はwinFormばっかりだな
>>162 は？XAMLがWPFの一番のメリットだろ。
逆にWinFormsにXAMLが導入されればWinFormsでも使い物になる。
mvvmと書くつもりがxamlと書いちまっただけだろ
xamlもWinUIになると、ビヘイビアもコンバーターも依存関係プロパティーも書かなくていいから大分楽になる
あとイベントハンドラをVMに書けるからFormsヲのまんまの感覚で書ける
来月出すやつが何処まで完成度上がっているかな
xamlの見本アプリがWinUI3 Galleryって名前になってバージョンアップしていた
今度はやっとDark/Lightモードがマトモに表示てきている模様
あと、svgがImageコントロールで普通に使えるようになったのを初めて知ったわ
普及の見込みがないUIフレームワークを使う意義とは？
多少難易度が高くても普及しているものを使った方がいいのでは。
豊富なトラブルシューティグ、技術者も集めやすい。
個人で趣味でやるならいいが、今後企業で使う技術としてはやはり普及しているかどうかが重要。
MSはそのへん理解してるのかしてないのか…
TeamsやOfficeをスレタイの技術で作ればいいのに。
2017頃からC#触り始めてWPFは遅くて使ってる人少ない、winformsは遅くはないけど古い技術、使ってる人は多いってのを見て、業務アプリだし後者を使い続けてきた
WinUI3が出るということでxamlに慣れておこうとWPF+MVVMで作ってみたけどすごくいいと感じてる
Rxなんかも触ったことなかったけどこの機会に一緒に勉強してみたらめちゃ便利だった
MVVMはいいんだけどflutterとか触るとxamlがだるいんだよな..
いつものことだけど、この「普及してない」ってのはどの統計を見て言っているんだろう
まあ元がWPFよりFormの方が多い、って話からだから
Windowsデスクトップアプリで比較するならそれしかないしな。
デスクトップアプリとWebアプリの比較みたいになったらそれはまた別の話だし。
WindowsアプリでReactが使われている統計なんかがあったら見てみたいが。
参考図書やWeb上のサンプルコードもWinFormsばかりだしな、初心者が取っ付きやすいほうが普及する
WinFormsという言葉は「WPFではない」ということを明示する必要のある文脈でしか使われないから、WPFと単純比較するのは公平ではないと思う
Google検索結果
"System.Windows.Forms" 2,180,000件
"System.Windows.Controls" 313,000件
まあWPFでControls名前空間を常に参照するかというと微妙だが、比較的体感に近いんじゃないか
WPFのリリース前を含めるのはフェアじゃないな
2010年以降
"System.Windows.Forms" 192,000
"System.Windows.Controls" 42,500
過去1年
33,500
7,870
>>176 それはメインコード埋め込みな上にプレビューが無いだけじゃね？
Windowsプラットフォーム自体の衰退なのにForms、WPFで戦ってるのアホだろ。
マルチデバイスのプラットフォーム作れなかったMicrosoftが一番アホだけど。
実際の所、C#関連でググってなんかの調べ物してると、WPFよりFormsの情報のほうが
圧倒的に見つかるからなあ。実際のユーザー数がどうなのかは知らんが、その点においては
WPFはプログラミング経験の浅い初心者には勧める気がしない
将来性という点においてもどっちがどっちって感じだしなw
>>189 作ってるぞ？
MSはReact NativeやElectronにコントリビューションしまくってるからな
近いうちにflutterのWindows対応の強化にも手を出すだろうね
MSにとって.NETはAzureでのサーバーサイド開発の主力ではあるけど、フロント技術としてはポートフォリオの極一部でしかない
>>191 これ
そしてMSはReactを製品に使用している
>>185 参考図書(Amazon)
"Windows Forms"
96冊
WPF
827冊
コードサンプル(GitHub)
WinForms
3,873 repositories
WPF
6,599 repositories
求人
WinForms
304件
WPF
1,225件
MSのGUIフレームワーク担当部門が作ったオレオレフレームワークなんて使えねえよって
VSCode部門やOffice部門が言ってるんだろうな
そりゃVSCodeもOfficeもマルチプラットフォームだからな。Windows専用のフレームワークなんか採用するわけがない。
VSCodeなんかWindows11の右クリックメニュー対応すらWindows固有なんで対応を渋ってるくらいだから。
このスマホ全盛期にWin専用のアプリなんて作る意味あるか？自分でしか使わないならいいけど。
支給端末をキッティングするような会社なら案件の選択肢としてはあるな
Webとの２択やろけど
>>197 環境的な制限とかでそれを選ばざるを得ない場合もあるのでは
例えばPCの仮想メモリが4GBとかでオンラインにしただけでPCがフリーズ状態になるとか、ローカル環境にディレクトリを生成したりするようなやつとか
メモリ増設するにしても金が無いからできないとか
>>197 スマホに繋げないハードウェアを制御するアプリなんて、世の中にたくさんあると思うが
そもそもWPFどころかWinアプリに用がない人間が覗くスレではないからなｗ
>>197 スマホの小さな画面で事足りるしょぼいアプリばかりじゃないのよ。
小規模かつPCでしか使わない業務アプリならデスクトップアプリが今でも最善な気がする
残念ながらそういうのは今は出来合いのSaaSを入れるのが主流になりつつあるのです
ゴミみたいなVBAからいつまでも脱却できないExcelからGoogleスプレッドシートに移行しつつある・・・ってコト？
ExcelはSAAS版は普通にJSだからVBAからは脱却できるのではw
どうやって1.0プロジェクトを1.1にアップグレードすりゃいいんだよ
このゴミツールが
WinUI 3 Gallery、キー2連打でクラッシュするバグが直ったと思ったら
今日更新したら起動すらしない致命的バグ。
糞みたいな品質だな。
1.0で作ったプロジェクトをそのまんま１．１にアップグレードしたが
そのままだとDebugでは動いたがReleaseにすると
>>216と同じように落ちたが
プロジェクトを作り直してファイルをインポートで何とかなった
グレープシティ、
WPF用UIコンポーネントセット「InputManPlus for WPF 3.0J」と
「SPREAD for WPF 4.0J」をリリース
Reactで作ってモダンなUI作っても、所詮Webだから安っぽいものが出来上がる。
Microsoft365アプリが全部そんな感じだからさ。
だからネイティブアプリで作ってほしいってのがユーザー側である俺の気持ち。
それに...Win11からARM製SoCに対応するってことだし、将来Windows Phoneが復活しそうな気がするんだよね
Microsoftはその可能性を否定してるけど、俺は信じてる。
Webだとなんで安っぽくなるんだよ？
むしろリッチにできるだろ
WPFで表現できる範囲は多分webでも普通に表現できる
3DアニメーションもXAMLより簡単にできるけどみんな使ってない
HTMLのformを軽く使った、デザインセイ皆無なものみたいなやつを前提としていたりして…
そんなわけないか…
別に変な意味じゃ無いけど
dartだけで作れるようになってくれたらつかったげる
XAMLで面倒だなって思ったのが一覧表示のループ
foreachとかwhileがない代わりにtemplateで記述
これ初心者のハマリどころだよな、難しい言われても仕方ない
Electronキラー、Tauri 1.0 リリース！
いかがだったでしょうblogを紹介するなよｗ
自作自演か？
内部でWebView使うって事で
環境が異なるとUI崩れるって事でもあり
もうクソなんだかな
WPFのメニューってbreak（改列）できないんか
>>238 昔はよく ルーク、ソースを使うのだ！みたいなスターウォーズパロディみたいなことを言われた
「ソースを使え，ルーク(Use the Source, Luke)」
winrt apiでwpfからwindows 10の機能が簡単に使えます♪って改めていうことか？？
最初からできてなきゃいけねえだろ(笑)
>>219 webのwordやexcelは良くできてるだろ
web版officeは「webアプリにしては」よくできてると思うが、普段はやっぱりデスクトップアプリの方を使っちゃうよなあ。
まぁ、excelとかwebアプリのピンキリのピンのだろ?
webアプリを平均すると安っぽいイメージしかない
SIerの作るWebがゴミなだけで、使いやすいWebサービスはいくらでもあるよ
つまり凡百のSIerが使いやすいWebアプリを開発するのはハードルが高いから
おとなしくデスクトップアプリ作っとけってことだな。
概ね同意だけどデスクトップアプリは展開に難があるからなあ…
そういうのは多少UIを我慢してもWeb化するメリットがある案件だな。
スタンドアロンで十分なものにまでWeb化をごり押しするのは困りもんだが。
凡百のSIerにとってスタンドアロンで十分な案件なんてほとんど存在しないからね
こんなふうに「ほとんど存在しない」とか決めつけちゃうところがごり押しだよなぁ。
こんなスレに来てWebを布教するのはこんなのばっかり。
アイデンティティを自分以外の何かに仮託してる奴ってそうなるね
仮託先を否定されると人格否定と受け取ってムキになる
ゲーハーと変わらない
決めつけも何も一般論として実際そうだろ？
俺はデスクトップアプリにするメリットのある案件が存在することは否定していない
それと純粋なスタンドアロン案件が稀であることは矛盾しないよ
確かに今どきはなんだかんだでネットワーク使うからな
スタンドアロンって言葉的には当てはまる案件はなかなかないかもね
デスクトップアプリかWebかなんて要件次第すぎて決着付くはずもない
べつに決着つけるような話でもないがな。
どんな統計を基に話してるのかは知らんが、仮にスタンドアロンアプリの開発が少数ｄとしても
だからといって必要もないのにWebアプリにしようなんてことにはならんしな。
WEBアプリがどうたらとかスレチの話題はお腹いっぱい
為にもならない同じ内容を繰り返してるだけだし
webはuiの作りがよくわからんのだわ
wpfが好き
Webは古典的なサーバーサイドの状態遷移は独特なノウハウが必要でデスクトップな人には馴染みにくかったけど、SPAの時代になって分かりやすくなったよ
ReactなんかのクライアントサイドテンプレートはWPFの複雑怪奇なバインディングよりずっと分かりやすいしな
WPFを知らない人はWPFを複雑怪奇だと感じ、Hooksを知らない人はHooksを複雑怪奇だと思う。
そういうことじゃないのかね。
両方とも全部学ぼうとするとまあ大変だ
WPFもreactも小さい部分だけ使えばさほど難しくない
でもノウハウがないと開発つらい
ググってばかりになる
WPFでUIとか苦行過ぎる
WPFでもUI部分はWebview2でCSS使うわ
Webの人はいまだにWPFが気になってしょうがないみたいだな。
いいかげんWPF離れして好きにやれよ。
WPFも20年前にもっと盛り上がりがあれば良かったのに
今はGUIでマウスなどのイベント処理はビヘイビアつかうのかトリガー使うのかイベントトリガーを使うのかどれが正解なんですか
ぐぐって出てくる情報はどれも交錯していて意味がわかりません
どっちが一方が正解ってことはないんじゃないかな。
対象のイベントまで含めた「振る舞い」として再利用したいならビヘイビアとか。
WPFに正解などないから好きなの使って自由に作ればいい
もはやコミュニティが存在しないからね
>>265 > ぐぐって出てくる情報はどれも交錯していて意味がわかりません
これが一番ガンだと思う
WinFormみたいに一つの方法でしかできないって奴でないと老人には辛いw
ビヘイビアと言えば古のLivetに殆どのコントロール用が用意されていたのを思い出してググったら
ビヘイビアやコンバーターが別パッケージに分離されて他のMVVMライブラリーと併用できるようになっていた
意外と使えるかもしれんな
回答ありがとうございます
リストボックスなどにマウスエンターされたらアイテムを若干大きくしたりしてます
前だったらblendでストーリーボードのきっかけがGUIで作れたんだけど
今はないみたいですね
コードビハインドで実現してますけどMVVMだとどれがおすすめなんでしょうか？
>>270 WinUI3で似たようなことやっているけど、参考にしたMSのサンプルはイベントトリガー使っていたわ
WPFで作られてるソフトって有名なの何がある？
勝手にAutodesk製品はWPFだと思ってるわ
リボンUIだし
Officeはネイティブ
WPFなんか使ってないよ
最近使ってないから変わってるかも知らんけどSource TreeはWPFだったな
グラフィックスデバッガのPIXとかMSがWin専のツールとかで稀に使ってる
リボンUIとかMFCにも実装あるでしょ
もしかしてAutodeskもWPFじゃなくてMFC使ってたとか？
大昔のEvernoteがWPFだったな。
重いからすぐに作り替えたらしい。
>>283 重いのかよ…
今リボンUIのアプリ作ろうとしてるけどWPFに拘らなくてもいい感じなのか？？？
.NET5以降のWPFは.NET Frameworkの時より軽くなったのかな
mvvmなんか気にせず画面周りだけxamlを使えばいい
ドッキングウィンドウ実装するためにAvalonDock使おうと思うんだけどこういうオープンソース系って商用利用してもいいのかな？
そういうライセンス的なものに疎い
フルーエントリボンのライブラリも勝手に商用利用していいのかわからん
こういうライブラリって本気になれば作れるんだろうけどどうやって作るのかすらわからん
>>289 MSPLだから一般的には商用利用可能だが、お前が今の案件でそれを利用していいかは別の問題だ
社内に明確なルールがないなら客との契約次第だから法務に相談しろ
また、受託開発においてはライセンスを受ける主体がお前の会社ではなく元請やユーザー企業になる可能性があり、その場合お前の会社の責任で判断できることではない
>>292 だったら問題ない
どうせ完成させて売れるとこまでいく可能性は極めて低いんだから細かいこと気にしないでよろしい
WPFで作ろうとして実際に重すぎて使わなかった話は昔はたまに聞いた
FBはMVVMも捨てた
MVVMで作ったら状況バグがデバッグできないし困難だから
間違った通知をデバッグして消しても翌日また復活してるって
関係ないけどtwitterのwebのバグがこれ
サイト開くとたまにベルにバッジが一瞬出て消える
ベルを押すとやはり新規の通知がある
mvvmは大型案件には向かない
状態が意図しない場所で常に変わり続けてデバッグが困難
MV*アレルギー発症しちゃってる子がきたのか
お前使いものにならないから要らないってこないだも俺言ったよね？
状態が変わらないということは言われても聞かないということである
有言実行でスバラシイね
MVVMはビューに反映させる必要のあるデータを全てVMの状態として持たなきゃいけないから、
Mの更新があったときにVMの更新前の状態に依存した複雑な更新ロジックを書いてしまいやすいんだよね
その点Reactなんかは、MからVへの単方向バインディングで済むデータについてはVM相当の中間層(コンポーネント)に状態を持たないからプログラマが間違える余地がない
本来MVVMでもVMはMの内容を関数的に反映しているだけになるように作るのが正しいのだが、それをアーキテクチャ的に強制できないんだよ
mvvmは無理に使う必要なくて機会が有れば覚えたらいいよ
>>301 それはVの更新の仕方をカスタマイズするために仕方なくなんじゃないの？
nuGetやVisual Studio Marketplaceでこれは汎用的に使えて便利のおすすめのライブラリってあります？
>>303 そういうケースもあるだろうし、単にプログラマの頭が悪いだけの場合もあるだろうね
いずれにせよそれこそがまさにFBの問題意識であって、Reactでは後者のケースは自然に排除されるし、前者のケースもReactが自動的にツリーの差分を取ることで解決した
前提条件を揃えないと何を比較しているのかよくわからない話になるよね。
>Mの更新があったときにVMの更新前の状態に依存した複雑な更新ロジックを書いてしまいやすいんだよね
複雑なことは複雑で
>その点Reactなんかは、MからVへの単方向バインディングで済むデータについてはVM相当の中間層(コンポーネント)に状態を持たないからプログラマが間違える余地がない
簡単なものは簡単
としか言っていないようにも見える。
つか
pubulic ReactiveProperty<bool> hoge=>model.hoge;
と書けば、Modelのプロパティーは簡単にVMでリレーできるんだよな
要はやり方次第
こういうめんどくさいことがあるからできれば自分でこういうUIのライブラリ作りたいんだがどうやってやるのかわからん
>>310 いやそのソースをどうパクればいいのかわからん
どうやってそのソリューションに持ってくるのかというか…
しゃーないから標準のDockPanel使ってそれっぽいの作ってみた
もちろんフローティングとかタブ、幅調整なんてできないが…
ドラッグでサイズ変更可能なコントロールってあったっけ？
それをDockPanelに仕込めればそいつ大きくしたらDockPanelも追随してでかくなりそうなんだが、もちろん縮小も
>>314 Windowの中にWindowは入れられないってさ
一応それ思って試してみたけど無理だった
>>313 GridSplitterじゃダメなん？
サイズ変更可能な画面spliｔはwinformsの方が楽だな
つか、どんなアプリ作ってるのか知らんが、今時リボンなの??って感じだが
リボンに替わる今時のUIってなんだろう？
うちはずっと旧来のメニューバーのままだけど。
横からだけど、リボンってそんなに悪いの？
リボンUIにするってことは多機能なアプリなんだろうから、使いづらいと感じるのは多機能ゆえに習熟に時間がかかるだけじゃないかと
長所
アイコンが大きく出来る場合が多く非熟練者には操作が類推できる場合が多い
非熟練者には機能がタブ分けされていてわかりやすい
短所
リボンは画面に占めるUIの割合が大きくなり作業領域が減る
各アイコンが大きく一覧性に欠ける
またそのためタブ切り替えなどの操作が増え熟練者にはつらい
例：
従来 アイコンAを押す→アイコンBを押す → アイコンAを押す →…
リボン アイコンAを押す → タブの切り替え → アイコンBを押す →タブの切り替え → アイコンAを押す → …
ウインドウのサイズに合わせてレイアウトや各アイコンなどの表示が文字単体に変わり操作感が変わる
タブなどを超えて短時間にガンガン操作する人にはつらい
操作回数がかなり増えてる
嫌がらせ
ゆったりポチポチする人向け
今どきならNavigationViewにCommandBarかな
リボンの利点はまだあった
タブレットなどのタッチ操作向き
プレビュー機能などが表現しやすい
GridSpliter使ってみたけどだめだったわ
これは最大範囲の中でどの割合でスプリットするのかを決めるスライダーみたいで
最小範囲をデカくするためのスライダーじゃないみたいだ
リボンUIは個人的に今のOfficeやAutodesk製品ソフトが昔のメニューバーより使いやすいから
もちろんショートカットでゴリゴリって人には必要ないかもしれんけど未習熟者にはかなり扱いやすいUIだと思って使ってる
今のパワポ感覚でAdobeのイラレみたいなソフト使えれば面白いなと思って趣味で開発中
navigationviewにcommandbarはほんとに簡易的アプリって感じよな
>>321 Excel 2007でリボンについていけないジジイが騒いでただけ
さすがに最近では滅多に見かけなくなったと思っていたけどクイック操作も知らない
>>322みたいなジジイが生き残ってブツブツ言ってるw
>>322 作業領域減るっていうのは確かに俺もわからないでもないな
Wordはリボン閉じてるわ
Autodesk系はリボンないと無理
>>328 リボン不評がずっと言われて後でクイック操作が入った
最初は作業領域を常に占有してたけど後で閉じれるようになった
不満に思うことは常に開発へ伝えるべきです
相手にジジイとか言う前に結局熟練者の作業性は落ちてることを理解すべきだ
>>331 熟練者の生産性は落ちてないでしょ
あいつらメニューバーでもショトカしか使わないんだし
ショートカットキーはリボンUIになっても変わらんからそこまで生産性落ちてないと思うわ
Autodesk系ってなんだよ
製品数が多すぎてどれのこと言ってんのかわからん
しかも買収した会社の製品の寄せ集めだぞ
>>332 熟練者たちが慣れた後でも今まで1時間で完了していた作業が1時間では全然終わらなくなってた
>>333 AutoCad Revit Fusion360 はリボンUIになってるのを確認
MAYAも広義的にはリボンなんじゃね？
>>334 それほんとに熟練者なのか？
新しい事に適応できない老害だと思うけど...
DockPanelだけど□、✕ボタンのVisibilityをCollapsedにしてTextBlockをrotatetransformで270にしたらいい感じにドッキングパネルを閉じた表現にできた
これを✕ボタンを押したときにDockPanelの内部をCollapsed…のように書き換えれるとかなりそれっぽくなるな
写真貼り忘れ
>>336 UIで生産性が低下する場合もあるんだから普通に知っとけ
>>339 どんな操作してるのか具体的に書いてみなよ
そもそもUIの操作ばかりしてるんかよw
>>335 MayaはもともとIrix（中身はunix）で作られてるからな
リボンよりも前からあのUIで今は少し変わったがリボンって名前ではない
>>331 >リボン不評がずっと言われて後でクイック操作が入った
うわっ嘘つきだー
クイックアクセスツールバーは最初からあったが。
そもそもリボンUIはメニューUIの進化版。
クイックアクセスツールバーが従来のツールバーに相当する。
>最初は作業領域を常に占有してたけど後で閉じれるようになった
これも嘘。最初のバージョンのリボンからできた。
何にも知らねーな。
Officeのバージョンによってメニュー展開がデフォルトか閉じているのがデフォルトか
違うだけ。
リボンがメニューだということが分かっていれば
作業領域を占有するなんて的外れなことは言わない。
メニューを開きっぱなしにしてりゃ場所とるに決まっている。
省スペースにしたいなら一般的なメニューみたいに必要な時だけ展開すればいい。
リボンは開きっぱなしモードもあるってだけ。
>>344 読解力ゼロかい？
メニューのパワーアップ版がリボン
>>342 クイックアクセスは嘘つきじゃなくて勘違いだな
クイックアクセスバーはデフォの内容をオンオフするだけのものでツールバーの代わりだなんて言えるものじゃない
作業領域を占有していたのは本当で誰もタブを非表示にできるなんて知らなかった
後のバージョンで閉じる操作が表に出てきてみんな消すようになった
そして自分でカスタマイズしてコマンドバーが出せるようになり
ツールバーと同じ操作ができるようになった
つまりみんなデフォのリボンが使いにくくてカスタマイズするようになったんだ
それは認めないんだな
馬鹿は老害だーとか言うけど
それで実際に作業効率が下がって生産性が下がってもいいんだなと
馬鹿は大変だ
>誰もタブを非表示にできるなんて知らなかった
はい、これも嘘。「お前が」知らなかっただけ。
なんですぐばれる嘘をつくかな。
少なくとも自分の周りではメニュー（タブ）部分のダブルクリックが一番お手軽に切り替えられることは広く知られていた。
視覚的にもリボン最小化への導線は用意されていたし、これが分からないというならハンバーガーメニューも駄目だろう。
>クイックアクセスバーはデフォの内容をオンオフするだけのもの
全然違う。
あれはユーザーそれぞれに合ったツールバーに育てていくよう設計されたもの。
リボンを使っていて使用頻度の高いボタンがあったらその場で右クリックしてクイックアクセスツールバーに追加していく。
ある程度育ってきたらツールバーをリボンの下に表示する。
こうすることによって必要なものだけで構成された使いやすいツールバーが自然と出来上がっていく。
>>347 切り替わり直後はともかくしばらくしても生産効率下がったままなのは老害だけだろ...
自分の適応力の無さを恥じろよw
>>349 工程が増えてるのに適応もクソもないだろ
頭おかしいのか？
例えばプログラム上ステップ数増えてるのに実行時間同じにしろとか馬鹿なんじゃないの？
どこか別で効率化できるならともかく
>>352 > 工程が増えてるのに適応もクソもないだろ
クイック操作
> 頭おかしいのか？
ブーメラン乙w
WPFでもUWPやWinUIのライブラリって使えたよね？
ColorPickerを使ってみたい
>>351 FluentRibbonが使えなくなったらこれにするわ
>>352 工程は減るんだが?そんなことも分からないのか
そのリボンUIマイクロソフトが配布してるってのはいいけどギャラリー機能とかちゃんとしてんのかな？
WinUI3のSDK試したけどほんとに最新版で作られたものでしか運用できなさそう
ターゲットを新しいものにしないといけないんだがターゲット変えても他のライブラリが対応できていないものもあってかエラーしか出てこなくなる
Fluent.Ribbonが使えなくなったわ
だめだ新規にWinUI3用のプロジェクト作ってもtargetplatformvarsionでおかしくなる
これほんとに正規でリリースしてんのか？
WinUI3はWpfと別のシステムだから、Wpfのコントロールは動きません
GUI部品は全て入れ替えになるし、それ以外もWinRTライブラリが中心になる
空域が共存できるだけで、混ぜられるわけじゃないでしょ
>>369 まじかよ…
colorpicker使えると思ったのに…
WPFでcolorpickerってあったっけかな？
>>368 Wpfで使えるXaml IslandってやつはUWPのコンポーネントをWpf上に貼り付けるやつだが
WinUI3用はまだ出来ていない
>>370 UWP用のColorPickerならXamlIslamd経由で動くはずだが
やったこと無いので保証はできない
頑張って調べてね
XamlIslandsもWPFとWinFormsの相互運用と同じでWinネイティブのウインドウを重ねるだけでしょ？
無茶苦茶非効率な仕組みだからボタンみたいな小さなコントロールの単位で使うようなもんじゃないし、
Windowsネイティブのコンポジションでできる範囲のことしかできないはず
>>362 Q) WinUIを使った実際のプロジェクトを見たことがありますか？
A) 私はC++/WinUI3で簡単なRPAツールを開発したことがありますが、
WinUI3の現在の進捗状況と機能では、商用アプリケーションを開発することができないと言いたいのです。
A) ソロ開発者の話をよく聞いていますが、はっきりとノーと答えることができます。
今のところ私の知る限り、誰もWinUIの道を進もうとは思っていません。
A) 他の人達が言うように、WinUI3は商用アプリケーションにはまだ早いです。
私たちはWinUI3を調査し、WPFの代わりにWinUI3を使用するようにいくつかのアプリを変更できるかどうか検討しましたが、
多くの機能が欠けており、バグの量も多いため、現実的ではありません。
WinUI3は、今のところ趣味のアプリケーションにしか使えません。
私の予想では、Microsoftのリソース次第では、完成まで2年かかるかもしれません。
何時作ったコピペか知らんが、最近のリリースは割りと安定しているんだけどな
世の中には自分用に趣味でツール作る人たちと、数十万人に影響するシステム作ってる人たちがいるからね
後者の人がWinUIみたいな実績のないものを使うことはない
MSは他の部署（Teams,Office）に使わせて実績作ってからリリースしたほうがいいと思うんだなあ
それこそ何万人どころか数億人に影響するシステムに生煮えのUIは使えんじゃろ
SkypeやVScodeみたいなやつがElectronを使うように、メジャーソフトが扱うようになると安定してくるんじゃね
ストアにある、Youtubeとかニコニコ動画用のWinUIアプリ使ってる。
最高に使いやすいからMicrosoftはもっと宣伝してほしい
>>377 WebView2はTeamsでの採用を前提に作られて概ね好評だね
>>379 MSは企業内にメジャーに使われるソフトウェアがあるんだから、結託したら天下取れると思うんだけどね
今のMSだとそれなりの規模のアプリは莫大なレガシーコードを抱えるOfficeや
マルチプラットフォーム前提のサービス用アプリだからWinUIとか採用しづらい面もあるんだろう
Win8以降だと標準アプリはWinRT系使ってるんでドッグフーディングしてるとは言えるんだろうけど
小規模アプリの範疇でもロクな品質になる前に世代毎にコロコロ移行してくのはやっぱアホなのかなと
>>380 使いやすいのはわかるけど凝ったことができない
>>382 以前のWindowsストアインストールするUWPより充実しててワロタ
>>382 ホホエマは以前のUWPアプリだな
UIダサい
>>387 サムネ更新されてないけど、入れてみて
最新のMicaデザインになってるから
まぁ、現在のFluent Designはタッチでも使える閲覧系のアプリがメインだろ
Visual Studioみたく凝った生産系のアプリは従来のUIやリボンでOK
ただ、従来のUIやリボンでもいいがダークモードに対応しろ
>>338とかダークモードにできるの?
でもThemeプロパティ作ればいけるだろ
そのへんはWPFは融通高い
とりあえず進捗色彩ホイール作った
あとは3角部分なんだけどかなり難しい
>>382 しょぼいアプリばっかり。
Filesは2回ぐらい常用しようと頑張ってみたことあるけど、致命的なレスポンスの悪さと不安定さで結局アンインストール。
ファイラーはオリジナルのエクスプローラーと同じレベルのレスポンスじゃないと使う気にならないからWinUIは不向き。
WinUIもUWPもアニメーションのし方のせいもあるけど全体的に動作がモッサリしてる。
あとキーボードのみで使おうとするとものすごく使いづらい。
>>392 なんで自作してんの？
そんなのどこかに落ちてるんじゃないの？
>>394 三角のは落ちてないよ
ここで名前が上がらないし
一応ライブラリあるけど有料
>>382 ちなみに全部WinUI2。
WinUI3なら動き早くなると期待してる。
>>396 VIPでMacクソ信者がWindowsではiOSアプリ作れねぇとかクソみたいなことほざくからWinUI3とザマリン使ってファイラーアプリ作ってみるわ
FilesアプリはUWPでそのサンドボックス環境での制限のために複雑な事してるから不安定なんじゃね
WinAppSdk作り直せばもっとましになるはず
>>398 不安定なのか…
なんか作りやすいおすすめのアプリとかある？
不安定というよりWindows.Storage名前空間のファイルシステムのクラスは、System.IOと比較して体感できるほど遅い
WinUI3ではSystem.IOでファイル操作できるからその部分は解消されていますね
>>401 WinUI3は問題ないってことか
WinUI3使って見る予定だったから大丈夫
なんかよく読んだらWinUI3はデスクトップ向けってなってるみたいだけどスマホアプリにも使えるんかな？
スマホ??スマホなんてないよ
スマホじゃなくてWinUI 3はタブレット向けにはなってる
WinUI 3はWindows専用のライブラリ
で、xamarinというか.net mauiでWindows向けにビルドすると裏でWinUI 3が使われるだっけ??
他のOS向けにビルドしたらそのOSのネイティブビューが使われて、WinUI 3は関係ない
>>405 クロスプラットフォームでfluent UIを使うってならReact Native
WebでいいならReactライブラリとか。
やる手段は他にもある
Windows UI Library 2.8ってのが、リリースされてるけど、これはなんだ？
WinUI3より古いWinUI2のアップデート版かな？
Fluent Designがかっこいいのはみんなわかってるやろ
このfluent DesignがiOSやAndroidで使えないのツラミ
ちょっと遅くなったけど三角カラーピッカーの部分できた
あとはClipで三角に整えてサイズをControlのHeightとWidthに合わせるような処理を書くだけ
>>410 格好よくはない。控え目で地味でありきたりだと思う。
Micaなんて視力1.0未満の人は絶対気付かない。
派手にし過ぎると下品だし、これでいいのかもしれんが。
>>410 > Micaなんて視力1.0未満の人は絶対気付かない。
それは盛り過ぎ
0.1裸眼とかならどうか知らんが
ボタンとかカド丸めたり影つけたりするとそれらしくなるけど最初からやっとけよとは思う
マイクロソフトはわざとダサくしてるんだよ
そうすればデザイナーやコンポーネント屋さんの仕事増えるでしょ知らんけど
WPFが世に出た当初はそれがクールだったんだよ
WPFは作った通りの見た目で表示されるのが大原則なので、流行に合わせてデフォのスタイルを変えたりできない
WPFにもテーマ機能があるんだから
完全とは行かずとも時代に合わせた標準テーマを用意する位出来るはずなのに
放置されてるよな
WPFはVistaと同時にリリースだから、UIがVistaですね
>>420 なるほどたしかにデザインされたコントロール売ってる業者多いわ
すごいな。 みんなそんなにデザインにこだわっているんだ。
あちきは、社内DXで各部署のマイクロサービスアプリ作ってるけど、MaterialDesign+自作スタイルで充分。
それでも、スーパーマーケットのPOS画面並みにはなってます。
こだわるって今時の普通レベルのデザイン求めてるだけでしょ
Windowsなら今時はFluent design
それに仕事と趣味じゃ違うだろ
仕事じゃこだわるより大いに手を抜く
>>419 いや、今は角丸であふれかえってるから
逆に角ばってた方が格好よく見える
>>426 安定性悪すぎるのと、ストレージ容量食いすぎるのと、
デスクトップアプリのUIフレームワークとして完成度が低すぎるのがネック。
.NET Frameworkが出始めの頃の、
「えっ？こんな機能も用意されてないの？Win32 API使うしかないの？」
って状況に似てる。
まぁ WinUI項目追加でExprimentalも無くなった事だし、そろそろ使い始めても良いのでは？ ユーティリティー程度には。
当分、WPFとの共存は続くが、改良されていけばWinUIもクライアント指定になるぜ。
個人的には、MSIXでMS Store稼ぎしたいとはオモ。
PowerBI,docker 記憶にあるのはこれくらい
>>437 ハードウェア紐づけアプリとしてね。
メインはハード売り。
>>434 少しは丸っぽい方がボタンに見える
ノーマルWPFのボタンはボタンに見えない
ストアアプリはUWPの頃はクソダサくて無理だったけどWinUIになってからはかっこいいからこれから移行していこうとは思ってる
見た目うんぬんよりあのsrorageの仕組みをやめて欲しい
クソ
GUIだけを選択したつもりなのにファイルアクセスやセキュリティの仕組みまで強制される
なぜちゃんとGUIと他のAPIを分類しておかないのか謎
winforms,WPF,UWP,WinUI3
全部別の仕組みの組み合わせ
毎回違う
WPF使ってるときにあるAPI使いたくなってもwinformsにしかなかったりしてwinformsをインポート
WPFやwinformsでGPS使いたいとなるとデバイスにより二種類選択肢があって
片方はUWPの仕組みを使わなければならない
MSの馬鹿アーキテクトが適当に考えるからAPIのnamespaceすら適切に分離できない
WSLをダウンロードするのに使ったきりだな
他は何も
win10の電卓って結構頻繁にアップデートしてる印象があるけど
意味があるんだろうか？
MSにはやはり馬鹿しかいないんだろうか？
>>446 最近知ったけど単位変換機能が素晴らしい
バーガーメニュー開いてみ？
プログラミング書くのにもかなり役立ちそう
こんなの
もちろんバイナリからの数も求められる
わかると思うけど
HEXが16進数
DECが10進数
OCTが8進数？（これ何に使うかわからん色とか？）
BINがバイナリ（2進数）
あとm→feet,気圧→パスカルの単位変換とかグラフ書いてくれる機能もある
>>450 こういう重度の馬鹿のために世界中のwin10の電卓アプリがアップデートされ
帯域が使われて電気が使われて環境が悪化する
馬鹿にえさをやるな！
>>452 そんなの使ってる人間なんて百万人に一人レベルだろ
馬鹿なんか？
電卓は電卓
余計なアップデートはするな
>>450 > OCTが8進数？（これ何に使うかわからん色とか？）
unix/Linuxとか大昔のミニコンとか
まあ今時使う機会は滅多にないわな
>>452 この電卓、逆三角関数がなんでInvとかじゃなくて2ndなんだ？
電卓にタブ機能が欲しいよね。
標準電卓とプログラム向け電卓の行ったり来たりが何気にめんどい
フィードバックにコメント送ったら改善されるかもな
俺もN（ニュートン）変換ほしかったから送った
>>456 実機の関数電卓が関数と同じボタンの2ndに逆関数を割り当ててるからでは？
たとえば、2ndとtanでatanとか。
不満ある度にフィードバック送るのは大事だな
言わないとMicrosoftは分かってくれない
>>459 そうなんだけど双曲線関数はhypだったから2ndが逆関数と気付かなかったよ
>>461 2ndは逆関数じゃなく、second functionって意味だよ。
関連性のある関数を割り当ててるだけ。
関数電卓が最も使われるのは、工事現場や工場なので、実機に合わせてるんじゃないだろか。
事務所ではWindowsの電卓を使っても、現場では実機を使うので。
シャープは2ndFなんだね
カシオはInvかShiftだったから違和感があったってことか
こうして馬鹿は細かい意見を送りどんどん電卓ごときがアップデートされ続ける
電飾資源の無駄
そしていつか大きなバグが出る
誰も使わないUIフレームワークの開発よりよっぽど有意義では
Windowsの電卓はGitHubでオープンソースになっていて、WindowsのモダンUIフレームワークを未だに追いかけている奇特な人にとっては必見
これほどクソ綺麗なソース書けるエンジニアを電卓に投入しているのかと驚かされる
>>467 そうなのか！有能なリソースの無駄遣いのお手本ですね
>>460 英語版で送るのも大事だよな
日本Microsoftは怠慢
>>467 最新のWindowsアプリケーションを開発するための見本としてソースコードを公開したそうだから
そりゃ気合入ってるでしょうよ
GitHubにあるって書かれてるのにアドレス教えて、ってレベル低すぎんか。
聞いて返事が返ってくるまで待つより検索すりゃ秒で分かることなのに。
まあこの一連のやり取りが自演臭いけどな。
Windowsの電卓は使うけど
よくアクティブになってないのにキー押しちゃう…
>>473 DirectXとか使ってるらしいけど何に使ってるんだ
>>478 500字未満で長文とか言ってたら恥ずかしいぞ。
で、WinUI3でDDDやりたいんだが、クライライブラリのプロジェクト作るテンプレートはどこにあるんよ？
今は作れないようだが？
今更だけどWinUI3Gallery見てみたけどめっちゃおもろいな
リボンUIもナビゲーションビューで作れそうだしなんか簡単なアプリ作ってみたいわ
モッサリ動作なのがなぁ。
ユーザー操作を邪魔するほどアニメーションが出しゃばっちゃ駄目だろ。
>>483 おしゃれやろ
マテリアルデザインと大違い
どっちも微妙。
動きがあるのは結構だが、瞬時に画面が切り替われば軽快な印象を受けるのに
ウニウニ動いてるせいで「遅せぇ！」ってなる。
マウスでバババババッってあちこち連打すると動きに全然ついてこれてない。
>>16 Visual Studio Code(zip版)か
>>488 アニメーションとかやってるとすごい工数かかるけどな
むしろMFCやめて全部自前で描画した方が早く組めるかも
MFCなんて生産性低いゴミ使ってる奴、さすがにもういないだろw
>>494 たまにメンテやらされる
今となっては古代遺跡だな
マルチプラットフォームは理想ではあるんだけど
win macのデスクトップとandroid iosのモバイル環境を同じパーツで成立させるのなんて不可能なんだよね
フレームワーク側でマルチプラットフォームにちから入れてると、(今は完全にモバイルの方が立場上だから)
リストやボタンのpaddingが（タッチ前提で)スカスカになったり、(スマホは1ウィンドウだから)画面遷移のプロパティは整ってるけどマルチウィンドウがショボかったりするし
そりゃ共通化すればするほど大雑把で使い勝手の悪いものになるのは仕方ない。
Windowsの電卓だってモバイルが普及してなきゃこんな酷いUIになってなかった。
これハンバーガーメニューじゃなくてやるならNavigationViewでしょ。
スマホアプリならこれでも仕方ないけど、デスクトップアプリなら一覧を開きっぱなしにしておけるスペースはあるだろうに。
順番に切り替えて見たいだけでもいちいちメニュー開く操作が必要。馬鹿の極み。
>>497 マルチウィンドウはMicrosoftが対応してくれって思うな
ドッキングウィンドウとか個人で作るの難しいんだから提供してよと思う
>>498 NavigationViewは一応画面幅でタブ表示にするかバーガーメニューにするかを自動調整できる機能あるけどな
WinUI3Galleryで見た
>>496 思い出した！確か
WM_CTLCOLORDLG
WM_CTLCOLORSTATIC
あたりをひっかけて HBRUSH を返す、とかしてたかな？
私は思うのですが、あるテーマごとにまとめて関係するコールバック内とコールバック外とを抽出して、最後に＾重ねていく、みたいなことができませんか？
Visual State Manager
コードからユーザー インターフェイスに視覚的な変更を加える構造化された方法を提供します
動的な外観状態と、その外観状態に遷移する条件や遷移にかかる時間を管理する一連の機能を提供してくれるもので、以下の3つのクラスから成り立っている。
VisualStateGroup（外観状態グループ）
VisualState（外観状態）
VisualTransition（外観遷移）
WinUI 3がメインのUIフレームワークになるには、これ単体じゃダメなんだろうな、うん。
このご時世持ち運べるデバイス=スマホかタブレットがメインだし
.NET MAUIが正式リリースして初めて使われるものになるか？
フィールドを定義したら自動でpublicなプロパティが出来上がるとか気持ち悪いな。
コード上で素直に見れないからメンテナンス性も悪そう。F12でちゃんとジャンプできるのか。
>フィールドを定義したら自動でpublicなプロパティが出来上がるとか気持ち悪いな。
その感覚はよくわからん。
コード生成よりもEFみたいに完全にPOCOで記述できる方向を目指したほうがいいと思うけどねえ
プロパティの変更をVMのpartial methodでフックできるとか、もはや双方向バインディングしている意味があるのか謎
そんなことに力を入れるくらいなら、最近の流行を取り入れて双方向バインディングを使わない仕組みを作ればいいのに
foo でも _foo でも m_foo でも Fooプロパティを生成するのかー
>>510 そのPOCOの値をViewに表示、編集するだけなのにINotifyPropertyChanged書くのダルくね？
CommunityToolkit.Mvvm 8.0 がGAになったと聞いて使ってみたのだが。
なんかこんなシンプルなコードでCS0102の重複エラー出るんだけど…。
みんなちゃんと使えてる？まだバインドもしてないViewModelなのに。
public partial class MainWindowViewModel : ObservableObject
{
[ObservableProperty]
private string? title;
}
実行ファイル群をなるべく少なく小さくしたいから大規模開発以外はMVVMは使わない主義。
ログ出力実装したくてGenericHost入れてみたけども生成されるファイルの多さを見て使うの止めた。
自前で作れば1MB以内に納まるツールにはオーバーすぎる。
>>516 ありがとう～。
これで今作ってるやつのコード量が凄い削減できた～。
>>516 ありがとう～。
これで今作ってるやつのコード量が凄い削減できた～。
>>516 ありがとう～。
これで今作ってるやつのコード量が凄い削減できた～。
mvvm8.0ってVS2017 WDExpressでつかえる？
エラー出てダメだわ
CommunityToolkit使ってみたけど
これWindowのタイトル変えるにはどうするの
ShellViewModelにメッセージ投げる方向でいいの？
.NET MAUIでWinUI 3使えるじゃん
プレビューの記載無くなってるし、本番で使っていいのかな？
C#学ぶか...
.netがubuntuに対応したってだけで喜んでるツイートみたし、MAUIは是非とも成功して欲しい
linuxでも動かしたいから成功してほしい
flutterとかelectronとかどっちかというとやなんだわ…
ubuntuの開発環境は何使うの？
vscodeかな？
開発環境としての使用は想定外でしょ
MSとCanonicalは以前から仲良いから、Azureで使いやすくするためにMSが金出したんだろうね
mauiはまだ完成してないからxamarin名前空間をたくさん使ってるぞ
アップデートしたら前のがコンパイルできなくなる罠があるから慎重にな
Xamarin.Formsのサポート終わるから未完成でも移行するしか無い辛み
Xamarinが評判悪いからMAUIに名前変えただけでしょ
>>536 評判悪くはないだろ
良くもないけど
Windowsアプリなら結局WPFが一番使いやすいしスマホアプリならKotlinやSwiftの方が情報多くて助かる
MAUI Blazorにちょっと期待
これからはMVVMじゃなくてMVUだ！ってやってんのはMAUIだっけ？
>>537 Xamarinするにはまず人脈
なんて名言が生まれるくらい出来が悪い
「まず人脈」が炎上したのはXamarinそのものの問題じゃなくて勉強会でこういうキモいことを言ったやつのせい
人脈のトップとしてちょまどを挙げたところが拡散されてオタサーの姫的な立ち位置に女性たちが大反発
要はちょまどとそれを持ち上げたキモヲタが炎上しただけでXamarinは無関係
人脈要らないし
もっと言えばちょまども無断で旗頭にされただけで責任はない
ちょまどはコミュニティにとっての旗頭になることが仕事なんだから、仮に炎上したら最低限のフォローをするくらいの責任はある
こうやって未だにネタ擦り続ける側もキモオタって感じだな…
XAML自体が2010年ぐらいでもゴミだったのに今時WPFとかこの系統が流行る訳無いんだよなぁ
もうGUIはwebベースのみにすればいいのにｗ
>>545 だからさー
Webだと安っぽくなったりタッチする時の違和感が拭えないからWinUI使いたいんじゃん
MAUIBlazorって言うのは各OS用のネイティブアプリにブラウザを搭載してそこでBlazor技術でC#を動かしてそれをUIとして使うものだよ
ブラウザだからどのOSでも同じ見た目になるしその見た目はCSSで制御できる
CSSフレームワークは既存の物をそのまま使えるしなんならJavaScriptもC#と相互運用できる
MAUIBlazorという名前だけどrazor構文がよくわからんならHTMLとJavaScriptを使うこともできる
要はC#の独自コードを呼び出せる独自ブラウザを作るテンプレートがMAUIBlazor
だから流行り廃りは関係ない
>>542 有料のセミナーでマイクロソフト社の女性社員を神と定義し、主催者側を偉い人たちと称し、金払って受講してる人たちを一般ピープルと述べる。
それに対し批判が集まったところで、件の女性社員が「上司と相談の結果、マイクロソフト社法務部が対応することとなりました」と訴訟をほのめかした。
この、訴訟をほのめかしたことが炎上につながったのでは？
>>552 それが訴訟をほのめかしたことになるかどうかは知らんけど炎上してないのにそんなこと言わないんじゃね
>>554 批判されると反射的に嚙みつく人は、広報に相応しくないのでは？
マイクロソフト社のイメージは相当傷ついたと思います。
>>555 話が変わってきてるけど俺はマイクロソフトのイメージもちょまどのイメージもどうでもいいという立場を明確にした上で言うと
法務部が対応しますじゃなくて法務部に相談しますと言ったんじゃね？
法務部に相談した上で誰がどう対応(場合によっては謝罪など)するかを決めるのはごくごく当たり前の対応だと思うけど何がいかんの？
>>556 世間言噛みつくのは広報の仕事じゃないでしょう。
>>558 訴訟をほのめかしたのは、対決姿勢ですよ。
法務部というのは知らんかもしれんけど法律に詳しい弁護士などからなる部署のことだぞ
広報が今後の対応を決めるのにそこに相談するのは義務と言っていいくらいとうぜんのこと
今後の対応というのは一般人と対決することじゃなく、騒動に対して自分や上司が何をすべきかということだよ
だから法務部の意見によっては謝罪なり撤回なりすることになる
なんで対決と決めつけてるんだろ
>>560 法務部が対応すると広報したことが問題なのでは？
つまり、訴訟をほのめかすことになったから。
>>561 話は戻るが対応じゃなく相談と言ってないか？
>>562 相談ならなおさら悪いじゃないですか。
脅しに使ってるだけと受け取られる。
実際、訴訟をほのめかして脅してるだけで、実際に訴訟を行っていないんだろうけど。
それが透けて見えるから炎上したのでは
カルトを作るには良い人材だけど、グローバル企業の広報には不向きでは？
訴訟をほのめかしたことが炎上につながったわけで。
「Xamarinするには、まず人脈♪」とは、無関係かもしれませんね。
>>567 MS系のコミュニティって昔からそんなもんだよ
例の女性の件は抜きにしても、気持ち悪い内輪ノリを増長しやすい風土がある
LinuxやAWSなんかと比べて、みんな使ってるものが一緒なので人間も均質的なんだよね
>>569 Linuxも相当気持ち悪かったけどな。
おごちゃんの連載なんか、おごちゃんが女子高生にLinuxを教える体裁だったんだぞ。
それが1994年くらいの話だぞ。
LinuxのLの字もないころだぞ。
一番気持ち悪いマックユーザーも見てるところで争わなくていいぞ
インターネット回線の訪問販売員とかも、「ハイ論破」とか普通に言うからね。
そんなんじゃ契約取れないだろうに。
叩きたいという一点だけ一貫してて、主張のおかしいところを突っ込まれる度にのらりくらりと論点を変えるいつものパターン。
いや、叩いてほしいから訴訟をほのめかすわけで、そういうのを世間では炎上商法というんですよ。
ちろちろ燃えてる火に油を注いで一気に炎上させたパワーワードが法務部では？
法務って裁判沙汰だけが仕事じゃないから
法務に相談って言っただけで訴えられるとかアホな妄想するとしたら
訴えられると思ってる方に「心当たり」があるからとしか思えん罠
ちょまどに噛みついてる方が後ろめたい自意識があるということ
>>578 いや、相談するだけなら、黙って相談するわけで。
わざわざ公表したのは、やはり脅しなんですよ。
少なくとも世間はそう考えます。
ちなみに私は、今日このスレ見て検索して全貌を知った、まず人脈♪初心者ですからね。
まあ何にせよ、この一件でマイクロソフト社はだいぶ株を下げましたね。
伸びてるから何かあったのかなと思ったが9割ぐらい見えなかった
MSが次々にフレームワークを作っては投げ捨てる奇行を繰り返してるせいで
「Xamarinみたいな黒歴史は忘れろ。これ使っとけ」
ってのが出てこないのが悪い
>>585 ＞MSが次々にフレームワークを作っては投げ捨てる奇行
ほんとこれ、迷惑な話だ
WinUI3がマルチプラットホームに対応してればワンチャンスあっただろうがMAUIじゃ無理だろ
MAUI vs AvaloniaUI vs UnoPlatform
3つ乱立するような感じで自滅
Microsoftが強力なリーダーシップとらなかったから乱立するはめになってリソース分散で自滅する未来しか見えない
特に新参のUnoPlatformなんてxamarinがパッとしなくてMicrosoftが放置気味だったからUnoつくったろーで開発しただろうに
いきなりMAUIとかちょっとやる気みせてUnoかわいそう
>>541 炎上云々はどうでもよくて、「まず人脈」って言葉だけは耳に入ってきて
Xamarinを少しでも触ってみた人はXamarinそのものの問題だと納得してしまうような出来なのが問題。
スタートアップを買い取ってまとめ上げていくアメリカ文化は、全張りで自前開発しなければならないとする日本人には理解できないだろうな。 Xamarinしかり・・・
AvaloniaもそろそろWebとスマホ対応しそうだね
MAUIでMSのコードに置き換えられてXamarinの諸問題は解決するってMS大好きおじさんが主張してたんだけどなあ
・Xamarin置き換えどころかガチガチ依存
・半年延期したのに未完成リリース
・VS対応もMAUIリリースに間に合わず
明らかに開発リソース足りて無いのに手を広げることばかりに熱心だから当然の結果だけど
WPFは一向に進化しないWindowsのUIに痺れを切らした.NETサイドが暴走した結果生まれたフルスクラッチのフレームワーク
そしてWin8で今度はWinサイドが反撃してストアアプリやUWPが作られ、
そして今またMAUIではフルスクラッチ系に戻ろうとしている
WPFこそが迷走の元凶なんだよ
WPF(またはSilverLight)はHTMLをXAMLで置き換えてWindowsがインターネットを支配しようとして失敗したもの
Windowsにこだわるあまりマルチプラットフォームへの移行が遅れてUWPみたいな誰からも望まれない鬼子が生まれてしまった
Xamarinを手に入れ.NET Coreを開発しこれからどうなるかというところだがちと遅すぎた感がある
今勢いがあって優秀な技術者が集められてるのはBlazorだと感じる
MSの戦略上、BlazorはWebフロントエンドが苦手な.NETerに対してSPA開発の門戸を開くためのもの
優秀な技術者ならそもそも必要ないし、BlazorでWebに習熟した技術者は必然的に去ってゆく
こんなニッチなものは主流になりえないし既に話題にもならなくなった
NumberBoxの×ボタンって何のためにあるんだろう
コントロールの特性上NaNが入り込む隙を与える必要はない気がする
マルチプラットフォームって手を広げすぎると最大公約数が小さくなるだけだと思うんだがな。
Webとスマホとデスクトップを同じコードベースでやりたい需要なんてそんなにあるもんかね。
>>600 GUIに関してはブラウザを使うことでプラットホームの違いを吸収できるから表現力は高くなるよ
そりゃな、ブラウザという単一のプラットフォーム以外を駆逐してしまえば問題解決と。
flutterみたく独自描画じゃないとGUIも最大公約数になりがちだからな
androidにActionBarというかToolBarというかメニュー項目おけるUIあるんだがこれはBottomAppBarとか下にもおいたり要は好きな位置に置けるんだが
xamarinとかmaui軽くググるとそれ用のコントロールないの??
代わりにShellにメニュー項目あって要は位置固定??
最大公約数が小さすぎて融通きかなすぎ..??
スマホとデスクトップを一緒にするとデスクトップが足引っ張られる形になるんじゃないかなあ
>>606 うん、だからマルチプラットフォーム対応のアプリって使い勝手悪いものが大半だろ？
使い勝手がまともなやつを数えた方が早い。
ブラウザでUSBが使えるようになったら、細々生きてきた業務用デスクトップアプリも完全死滅だろうなぁ
>>607 マルチプラットフォーム起因じゃなくてレスポンシブデザイン起因ね。
一画面で全ての情報を表示しなければならない製造ライン設備にレスポンシブデザインを使うバカはいない。
製造ラインはWindows、Android、iPadのタブレットが入り乱れ。
まぁ たまに、スマホでもモニターできるようにしてくれというバカ経営者はいるけれど・・・
USBって、なんでそんな狭い範囲で。
ハードウェア関連ならNativeのライブラリやらSDKやら山のようにあるのに。
ブラウザの拡張機能を作れば何でも使えるよ
業務用アプリがデスクトップなのは開発者のスキルの問題が大きく、技術的に可能かどうかはあまり問題ではない
全体的に業務系はSaaSが侵食してきていて徐々にドカタがゴリゴリ開発する領域が縮小している流れは確かにあるけど、
ハードウェア関連は共通化しにくいし比較的投資規模が大きくて参入障壁が高いから、なかなかSaaSが入りにくいところではある
USBマイクやUSBカメラは既にブラウザで使えるし、
USBメモリは時代遅れだが使いたいシーンはあるだろうし、
USBカードリーダが「標準」で使えたらID/パスワードの入力なしに、社員カードタッチでログインできるし、
業務用の機器だってUSB刺せばブラウザから保守できるって素敵じゃん
「Google Chrome 61」正式版リリース、JavaScriptモジュールとWebUSBのサポートが追加
あんまりChromeに依存するのもなあ
IEが永久にブラウザ代表だと思われていた過去の結末が今だし
とりあえずフィンガープリントを取れそうなものは全部ぶっ込んでいくスタイル
Google WorkspaceとGmailの区別がつけられない人は珍しいな
>>538 これ見てどんな感じか見ようとストアにあったavalonia control galleryインストールしてみたけど最新ではないかもしれんがゴミレベルにひどかった
UnoPlatformもそうだが、弱小フレームワークはインストールして試してもらえると思ってるのか??
インストールする前に、ギャラリーアプリ触ってそこでゴミならインストールすらしないんだが
GooglePlayあるUnoGallery2020年で更新止まってるぞ
そこだけはWinUI Galleryの出来はすばらしい
これなら触って見ようという気にはなる
unoはもうおしまいだろ
Xamarin上で動いてるのにXamarinがMAUIになって存在意義がほとんど無くなった
MAUIに比べて強いところはUWPのXAMLが使えることだけどそもそもUWPが半分死んでるから使えたからどうしたのって感じ
Unoがまともに動くのか知らんが動くなら存在意義はある
UnoだとUIがFluent UIで全プラットホーム統一されるし、
UWPのUIの機能どこまで再現できてるのか知らんが
ここにかかっている
まぁ、Unoも独自描画してなくネイティブビューのラッパーをくししてFluent UIを真似てるだけだろうが、
>>605に書いたけどToolbarすら自由な位置におけない融通きかなすぎフレームワークつかいたくもない
UnoはそこはUWPと同じCommandBarがあるらしいが
何にせよWidgetが豊富なフレームワーク優先だわ
ってことで現状はマルチプラットホームならFlutter
Windows専用ならWinUI
>>611 >ブラウザの拡張機能を作れば何でも使えるよ
ブラウザで動かすこと自体が目的じゃないんだからわざわざそんな苦行しないでNativeのスタンドアロンアプリで済ますだろｗ
>>627 そんなに変な話でもない
拡張機能であればChromeストア等が利用できるから容易に配布でき常に最新に保てる
デスクトップアプリだと出来合いの配布手段としてまともに使えるのはClickOnceくらいで、クロスプラットフォームなら論外でしょ
>>628 各OSにストアがあるからそれぞれに登録する方法がよく使われてるぞ
よく使われてる？
WinのストアもMacのストアも壊滅状態だぞ
配布する必要もないのにストアアプリにする馬鹿いねぇよ
まぁ 国内、ベトナム、タイ、ブラジル、北米工場に設備アプリ配布するには便利だけどな。 ストアは・・・
どの工場もネットセキュリティーがガチガチでバイナリーは送信できないし、ダウンロードサイト作ってやったが、セキュリティーに弾かれることもあり不評。
ストア経由ならどこも無料で且つすんなり通る。
MSストアなんか、利用価値はその程度だろう。
Storeで使われてるのってOfficeViewerだけだろ
ジャップ企業ではMSストアは弾かれてるところも多いだろ
ビジネス向けMSストアは廃止決定したしな
MSやAppleのストアは強制更新できないから業務アプリには使いにくい
MSストア、大きな会社では制限かけられてて使えないこと多いね
バイナリファイルは持ち込めないのにストアはスルーってどんなセキュリティ？
UWPはウイルスを持ち込むのが相当難しいし今のところウイルス騒動は記憶にない
その点ではよく出来たシステムだったのにな
でも、それで制限きつすぎてまともなアプリ作れないんじゃ意味ない
早くWinRT捨てて新しいAPI開発したらいいのに
WinUI3なんて100%失敗するのに何やってんだよと
UWPのサンドボックス環境は必要だろ
あきらかに、たいそうなファイル権限必要ないTwitterなどSNS系アプリがストレージへのフルアクセス権限持ってるなんて嫌すぎるわ
もちろん、ファイラー系とかデスクトップいじったりすると権限制限きついのかもしれんが、そんなアプリばっかじゃないだろうに
Win32でもFluentデザインをきちんと使えるようにするためにWinUI3があるんでしょ？
だからWinRT消えるんじゃなくて？
世の中に必要か不要かの話なんかしてないんだよ。
ストアアプリにするニーズがあるアプリもある一方で、必要ないアプリをわざわざストアアプリにする必馬鹿はいないというだけ。
WinRTでFluentデザイン実装しちゃったからそれをほかでも使えるように
くそめんどくさいことをやってるのがWinUI3
目を覚ませよ
WinRTは捨てろ
XAMLはサポート終了で終わらせろｗ
UIのフォーマットはHTMLだけでいいやろｗ
xaml の発音は ザメル らしいよ
初めて聞いたときはびっくりした
ふらっと始めたC#を20年間も使うと思わなかったよ
Officeで使ってるuiライブラリを使わせろぉぅ
maui使ってみたらpageにx:datatype使えたりでこっちにもくれよ…と思った
x:DataType使わなくてもVMをXAMLで指定すれば補完効くぞ
<Window.DataContext>
<local:MyViewModel />
</Window.DataContext>
デザイン時だけあればいいんじゃないの
ignorableとかなんとか使って
WinUI3かっこいいしいいと思うけどな
WPFと違いなんてなくね？
同じようにつかってるけど
>>664 出来る事が千倍ぐらい違うから
そりゃ複雑にはなるさ
>>666 まぁ確かにそうだけどHTMLに囲まない囲むとか変な仕様あるから全部囲むで統一されてるxamlの方が俺は書きやすい
Template Studio WPF使ってみたけど
navigationService.GoBackで値戻したいときってどうすんの？
>>668 NavigationService.csを弄ると簡単に実装できるよ
バイナリじゃないから簡単
>>665 実行ファイルのサイズが桁違い。
ウザいアニメーションが多いからWinUI性アプリはどれもモッサリしている。
ページ切り替えなんかを高速でクリックしてみればわかるけど、
アニメーションが全然間に合ってなくて処理の取りこぼしが出ている。
アニメーションが全部オフにできればかなりキビキビ動いているように見えるはず。
あとダークモード時のテキストコントローrのフォーカス表現に違和感がある。
フォーカスがあるときはより暗くなるんじゃなくて明るくしてほしい。
フォーカスがあるコントロールはハイライトという原則を守ってなくて
特に高さのあるテキストコントロールだと面積的に下線が目立たなくなってどこがアクティブなのか混乱する。
どうしてもこの方針で行くならテキスト枠全体をアクセントカラーで囲むこと。ダサいけど。
>>670 そりゃしゃーねーだろ
どこのフレームワークも実行ファイルの肥大化は避けられないよ
>>671 んなこたない
WPFとの比較ならWPFは小さいということになるだろ
>>670 フォーカスがあるときは明るくなってますが
>>673 WinUI 3 Gallery
フォーカスなし 0x323232
フォーカスあり 0x1F1F1F
DevToys
フォーカスなし 0x353947
フォーカスあり 0x1F2125
WindowのWidthやHeightにTwoWayでバインドすると
WindowにつけてるEventTrigger MethodName="Loaded"からの
CallMethodActionが呼ばれないんですが回避方法あるんですか？
（WindowのLoadedイベントハンドラは呼ばれる）
https://ideone.com/JfvVEr 2016年の夏に提供されたWindows 10 Anniversary Updateからダークテーマが追加されました。
Windows 10 May 2019 Updateの新機能として、ライトテーマが追加されました。
1.2 preview1出たが、やっとImplicitAnimationのバグが治ったようだ
2.0ぐらいまでいけば実用レベルに安定してくるかな
MS製品は3.0からやっと使い物になるのがセオリー。
そして3が出る頃には既に撤退が決定していたり刷新された次世代プロダクトの足音が聞こえ始めている場合が多い
それが良いものなら良いんだけど
また新しいのに手を出してすぐ飽きてポイしそう
>>221 なんもわかってねえなお前
もしAndroidアプリが全部PWAに切り替わるって言われたらどうよ？
使い心地最悪だぞ
>>685 いまのwebアプリの性能をしらない人かな
ビビるよマジで
>>686 Outlook Liteみたいなんじゃまだダメ
高級感が足りない
スレチな書き込みしてないでelectronスレ行ってこいよ
全然伸びてないじゃん
>>688 今時は業務系システムでも
凝った画面はWebでないと...って話になってる
うちも結構前から部分的にWebViewで出してるよ。
印刷も楽々やで。
そういえば印刷使う業務アプリなんて20年くらい触ってないな。
pdf 出力してダウンロードさせて
あとは勝手に汁
登録ボタン押したら
登録したプリンタから納品書印刷されなきゃ仕事にならないよ
>>693 バグらだけだしパフォーマンス悪いしディスク容量食いまくりだし
実用までは程遠いわ
>>516 VS2022 Ver17.3.4で回避策が不要になりましたね。
逆に回避策付けてるとエラーになる。
>>693 コミュニティツールキットに移行した
まだWinUI3は使ってないわ
ReactivePropertyってあまり使われてない感じ？
個人的には無いとﾀﾋぬレベルなんだけど、たとえばReactivePropertyなしでVMとMってどんな感じで接続してる？
>>701 使ってる。はじめ知らなくてMにイベント仕込わでVMで拾ったりVMのセッターに書いたりしてたがしんどかったわ。
1.2Previewの
Known issue
ListView styles regressed and changed from WinAppSDK 1.1.
って元に戻すと思ってて良いのかな？
戻らないとすると結構問題だわ
時代はWinUI 3
はよ1.2を
アップグレードってNugetのApp Sdkのpackageをアップグレードすればいいの?
よくわからなすぎ
1.2 Preview2
ListViewの不具合はもとに戻って一安心
トリミングって機能が気になるな
ちょうどpreview2が出たのか
次辺りかなpreview外れるの
デスクトップアプリ何で作る？
最低要件（最低限これくらいは満たしてね）チェックシート2022
============================================================================
チェック用アプリ仕様:
アプリ上の"はろー"ボタンをマウスでクリックしたらメッセージボックスで"わーるど"を表示する
(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以上が合格ライン（当然点数は高ければ高いほど優秀）
はろーボタンを押したらわーるどを表示する、と言う要件がチョロすぎて何を使う必要も無いでしょこれ。
はろーを押したらわーるどを表示するだけなのに大きすぎるという結論にしかならん。
>>709 なぜその要件が必要なのか説明がない
まったく考慮する必要のない要件が根拠なく列挙されているだけ
WinFormアプリしか作れない俺のスコアを高くしろ！ていう叫び
>>711 >はろーを押したらわーるどを表示するだけなのに大きすぎる
それ、アウトってことじゃん。
チョロすぎるメモリ要件やストレージ要件をクリアできてないって事じゃん。
>>717 理解できて無くて草
「コンビニ行く」って課題に「チャリンコ以外無いでしょ」「ギリギリで原付」って言われてるんだぞ
「現地に駐車場は無い」
「凄く近い」
「燃費は最高で行ってほしい」
「道は狭いです」
「車の免許は無い」
こんな条件
チャリンコ(WinForms)が最適な解になるための質問じゃねえか、ということ
これが
「この段ボール箱を二つ納品してくる」って課題に
「現地には大型トラック以外は停められる」
「隣の市にある」
「燃費は安い方が良いけども、到着が遅くならないように」
「普通の車が通れる道はある」
「8t以下は何でも乗れる」
であれば、プロボックスで行くか、トラックで行くか、軽トラで行くか。はたまたヤマトみたいにチャリンコに大八車つけたやつ牽いていくかの議論になるでしょ。
>>718 頭悪いねえ。
「徒歩で行ける範囲のコンビニに行く」って課題に飛行機やロケットしか選択肢がないのは使い物にならないって話だよ。
逆に別の国に行くのに飛行機を使っちゃいけないって話でもない。
頭悪いから日本語で書いてくんなきゃよくわかんないや
とりあえず一番わかってるやつがあれを書いたガイジ本人ということでいいのか？
>>720 なるほど。要は取り組んでる仕事の違いなんだね。
俺は今さら大規模システム開発を素のWinFormsでは作りたくないからなぁ。
WebView2貼り付けてガワネイティブにして、ClickOnceで公開ぐらいじゃない？使い道は。
Windows App SDK 1.2のトリミングは今までのダイナミックリンクからスタティックリンクに改めて
実行ファイルサイズを大幅削減が出来る機能だが、これが何処まで効いてくるか楽しみではあるわな
ここからUWPと同じようなAOTに進んで、.netの構造的欠点だったソース丸見え問題も解決するんだろうね
まず.NET 7でコンソールアプリをネイティブアプリとしてビルドできるようにするみたいだな
もっと前からできるけどあんまり意味がないんだよなあ
起動が少し速くなるくらいか
.net frameworkのインストールが不要になるん？
Ngen.exe ってのが有って
>>726はそれのことを言ってるのかな？
WinFormsしか使えないし（WPFで使えない）クライアントにアプリをインストールした後に実行しないといけないから
殆ど使われていないが
ネイティブコンパイルは少し前からあるだろ。
corertとか。
ngenは.net4.xになんらかのパッチが入ったらまたngenをやり直す必要あるからなぁ。
まあでもアイドル時に勝手にやってくれることには一応なっている…
WPF＝MVVMって流れを断ち切ってくれないか？
普及しないのはこれのせいやろ？
イベントハンドラー方式で
誰かが解説すればよい
オレがやっても良いんだけど
時が立ちすぎたからなーー
.net3.5の頃に初めてwpf触ったときに戸惑ったのはマトモにポトペタが出来なかったことだな
WPFのが糞なだけだね
実態はblandのライブラリーがベースだし
>>739 とっくに廃れてるよ。どの界隈でもMVVMは時代遅れ。
>>736 べつに普及するとか関係なくない？使いたきゃ使えばいいだけ。
>>742 リストデータの追加、編集、削除の実装解説が無い
初心者が分かんないのはここだと思う
画面イメージしか見てないがアラームアプリがそれっぽい
>>745 リストボックスじゃダメだろ
データ一件毎に入力コンントロールと削除ボタンが最低無きゃ
あと外部からリストに表示されたコンントロールにアクセスする方法ぐらいは最低無いと
>リストボックスじゃダメだろ
WPF本当に使ったことある?
>>747 何を言ってるのか全くわからん
どういうのをイメージしてんの？
>>749 ヾ(-д-;)ｵｲｵｲ.. 10年以上前になるけど特別仕様のコントロールを作りにアチコチのプロジェクトにお邪魔してたぞ昔は！株価チャート、ガントチャート、スケジューラー...etc
>>750 この手の要件だとtodo listが一般的じゃね？
React、Ember、Vue、Svelte、Angularが揃ってるみたいだから同じようにWPF版を足してみたら？
https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_todo_list_beginning WPF + データバインディング 勉強始めようと思って検索したら
http://work-professor.org/?p=626 を見つけたんだがここの手練れに質問。
データバインディングの方が面倒 & バグが入りやすい と思ったんだが
どうなんだ?
ページの下の「まとめ」では
データバインドはWindowsフォームアプリケーション開発では当たり前に
使われる方法です。
とあるんだがWinFormsの開発でデータバインドが普通なの?!
お教えください!
ここはWPFスレなのでWindowsFormはスレ違い
なおデータバインドなんて旧VBでもある
どうなんだって言われても違うぞと答えりゃいいのか
どんなバグが入りやすいと思ったのかくらい説明しろよw
>>754 だからWPFについて聞いてんじゃん。
大丈夫?
>>753 > とあるんだがWinFormsの開発でデータバインドが普通なの?!
ん？
>>757 それは最後にちょっこ聞いただけでメインは
上部のWPFについてだろ。
並列に聞いてる二つのどっちがメインとか知らんがな
普通は最後に聞いてる方がメインと思われるから覚えとけ
>>758 最初の3文字以外はWindowsFormの話題にしか見えない
前提や状況説明などの導入を先に書いて後から本題に入るのを覚えよう
本題を先に書いて後から蛇足を付け加える時には「蛇足だが」「それと」「ついでに」などの接続詞でそれが蛇足であることを明確にしよう
>>753 その例では説明のためかIPropertyChanged関連をべた書きしてるけど、普通はメソッドを用意してもっとシンプルに書く。
private string _inputTextBox1Text = string.Empty;
public string InputTextBox1Text
{
get => _inputTextBox1Text;
set => SetProperty( ref _inputTextBox1Text, value );
}
INotifyPropertyChangedだった
そもそも
>>755を無視して大丈夫？とか頭おかしい
>>762 ありがとうございます。
INotifyPropertyChanged()使わず、
シンプルに記述できるなら貴方の方が
良いですね。
INotifyPropertyChanged()がどうしても
必要なケースってあるんですか。
>>751 本当にWPF触ったことあるならリストボックスでそれらを実現できることぐらいわかるよね。
>>766 INotifyPropertyChanged.PropertyChangedのことだろうが、
SetProperty()の中でそれを処理するようにするだけで、使わない訳じゃない。
INotifyPropertyChanged()って何も分かってないだろ。
ぼく?
何も知りません。知ってるのはwinforms(C#)とMFC(C++)位。
インターフェースとメソッドの区別がついてないからそれらも知らんだろって言われてるんだぞ
>>753 リンク踏んでみたけどどう見てもwinformsだぞ
Form1とか書いてあるし
頭大丈夫か？
INotifyPropertyChangedの実装はどちらでも変わらないから敢えて無視してレスしたけど、
>>753はWinFormsのデータバインディングの説明。
WPFのデータバインディングを知りたいなら別の例を探した方が良いね。
どっちにしてもデータバインディングでこんなメンドクサイ時点で古いんだよｗ
当時からゴミと思ってた部分だｗ
vue.jsとかやってからだと絶対やりたくないｗ
あれ、ちょっと勘違いしたかも。
ところで、こんなはザムルは自分で書けるの?
WPFやWinUIでのMVVMはCommunityToolkit使えばいいって感じになったみたいだな
統一されてる分昔よりマシだな
ぶっちゃけ、世の中に溢れてるシステムのUIなんてWinformsで十分なんだよな
無理に最新技術を使う必要ない気がするわ
>>783 簡単にUIの入れ替えね。
ピクセル単位の画面デザイントリミングもXAMLホットリロードのメリットだけど、それ以上に入れ替えが簡単。
>>780 いやいや、スゴイね。
微調整はともかく、やっぱりポトペタしか
できんわ。
>>782 UI的にWinFormsで十分でもWPFで作ったらもっと楽できる。
MVVMは使う必要ないよ。
プログラム初心者ほど「WPFはMVVMで作らなきゃいけないんです！」みたいなこと言うけどね。
MVVMで組んで楽な場合とそうでない場合の見極めがまだできませんって白状しているようなもの。
>>782 同じ理由でWPFでも十分なんだよな
もう「最新」でもないし
慣れた方で作ればいい
どっちにも慣れているなら、自由度が高いWPFを選んどくべき
こういう感じのチャート画面（上段）を作りたいときって
ＷＰＦだとどう構築するのがいいんですかね
Ｗｉｎｆｏｒｍｓだと脳死でＯｗｎｅｒＤｒａｗ使ってて、
かなり昔にＷＰＦでＶｉｓｕａｌＴｒｅｅでチャートのタスクを作ってみたら要素が多くなってきたときに
パフォーマンスがでなくてあきらめたことがある感じです。
適当に見つけてきたサンプルなんですが、これも図形を500個くらい出すと
（CPU9900Kで）ガクガクになってしまい
https://github.com/noitaro/wpf-excel-shape-line >>789 一部分しか表示しないなら仮想化してみる
大量のオブジェクトを同時に表示する必要がある場合は諦めてSkiaSharp等で独自に描画
>>790 なるほど。表示時間範囲を変えて多量に表示するケースがあるので独自描画ですかね。
こういう画面だとWPFになってもあんまりWinformsと変わらないんですね。
今もWinformsでSkiaSharpは使ったりしてるので。
>>789 リアルタイムで横スクロールさせる必要あり?
>>793 スクロールのリアルタイムが何を指すのかよく分かってないですが
画面に見えてる期間と、スクロール範囲の期間が指定できる感じです。
今はビットマップにお絵描きしてるんですが、期間が長いとメモリ量や描画速度の問題がでるので
見えてる範囲＋1画面分先まで描画しておいて、スクロールはなめらかに表示できるようにして、
裏で次の1画面先の描画をしてます。
>>789 単なる表示だけで良いなら、GDIなんかでJPGファイル生成して
それをwebviewコントロールで表示。スクロールもスムーズ。
リストビュー(詳細)にプログレスバー入れるのが面倒(難しい)ので
■を並べて疑似プログレスバーにしたり、そういうインチキは必要ですよ!。
WebView使うんならHTML canvasでいいだろ
クッソ速いぞ
試しにWebBrowser コントロール でやってみた。
結構快適でした!
XAMLのgrid大変。XAML作ってくれるサイトないかな。
誰か作ってくれ!。
EXCELの罫線->HTML(TABLE)にしてくれるサイトはあるんだが。
画面とプログラム分業できる! というけど結局はプログラムつくるやつが画面も
やる羽目になるんだよな。
そもそもそんな分業したくなるもんなの？
欲しいのは素材用意する人とかでしょ
分業というか画面デザインとコードが別のファイルになるのが大きいのよ
もちろん一人でもできるけど二人以上が並行作業することによって納期が短くなる場合がある
まぁ 確かにコーダーにはデザインセンスは無いわな。
デザイナーがやっているのを見るとさすがと思う事しばしば。
アイコン作りひとつとっても、ああいう統一感のあるプロの仕事は俺にはできない。
外観や視覚要素のことだけを指して「デザイン」と呼ぶ人が随分と増えてしまったな
暇だったんでXAMLやってみた。gridが基本らしいのでテキトーにサイトから
コピペで張り付けて実験。一応何とかできるようになった。
開発の方に戻るかも知れないのでアンチWPFだったけど再挑戦してみようかなと、
思って。意外とWFPの仕事があるらしいな。
最初はデータバインディングで諦めたがwinforms風の作り方もできるらしいし。
(WPFはデータバインディングが必須だと勘違いしてた)
で、みんなはバリバリ、データバインディングしてんの? 凄いわ～。
逆にWPFのデータバインディングがわからないって知能を疑うレベルなんだが
何がわからないのかがさっぱりわからん
INotifyPropertyChangedを実装したオブジェクトをペタッと貼り付けるだけだろ
コマンドとデータバインディング縛りが面倒でどうしてそんなことしなきゃいけないのかわからんと言うならまだ理解できる
思い込みだけでアンチに走ってるやつたくさんいるよな
>>812 プリズムというのを使わないとやってられん、
と聞いたけどどうなん?
>>815 それは誰かの気のせい
Prismは無駄に複雑だからそれがわからないのはわからんでもない
CommunityToolkit使えばいい
>>816 そうなんだ。
自力で習得したの?
周りに聞くとしたらここ位しかないわ～。
最初はなんかだめんどうだなこれとか思ってたけど
いつのまにやらバインドないとダメな体へ
Prism 懐かしい言葉。
PrismLibralyのぞいてみたら、更新止まっているようだね。
まぁ 他のエクステンションが充実して、もう不要だけれど、リージョンにはちょっと魅力あるな。
ReactivePropertyが流行ったのもPrismが重厚すぎるせいだったんだろうな
今全然使うことないや
そもそもView層にロジック置いてリアクティブスパゲッティとか茹でたらテストめっちゃめんどいし結局INotifyPropertyCanged作らなきゃメモリリークするし
>>821 まぁ 今や、View,Domain,Infrastructure分離の時代。
ViewやViewModelにロジック入れるとは思えないけどｗ
メモリリークは対策したんじゃなかったっけ？ かずきが言っていたような・・・
>>822 > まぁ 今や、View,Domain,Infrastructure分離の時代。
いつの話をしてるんだw
それはMVVMとはまた別の話
というかもう少し原始的な話
>>822 ReactivePropertyはそれを入れるんだよ
まあ少々なら入ってもいいんだが調子に乗ってスパゲッティ茹でるやつ多すぎ問題が発生してな
PrismでもBidableBaseを使う程度だとコレ以上ないシンプルな実装なので
遅くなるなんてあり得ないんだけどね
嘘だと言うならソースを見ればいい
評判悪かったのはDIの実装だが、DryIocを取り込んた後は悪くなかったんだがね
DIって何だっけ？
シングルトンでええやんって奴か
BindableBaseだけならオレオレ実装で十分だから
>>826 いろいろ繋げると玄人になった気分が味わえるからな
ピタゴラスイッチみたいなもんよ
>ViewやViewModelにロジック入れるとは思えないけどｗ
ビジネスロジックじゃなくてプレゼンテーションロジックは普通に入れるだろ。
質問なんだが、コントロールとのデータのやり取りは全てデータバィンディングに
するの?
テキストボックスくらいならまだしもコモンコントロールでいうListViewも
データバィンディング? 大変そうなんだが。
アイテムテンプレートという各アイテムのビジュアル表現をxamlで一度定義すれば後は勝手にアイテムの数だけコントロール作ってくれる
ViewModelはアイテムを表すオブジェクトのListを保持してりゃいいだけ
ListViewの話ね
最初の質問に関してはデータバインディング使いたくなきゃ使わなくてもいいが
その場合、自分でコントロールの中身を手動で更新
これがめんどくなければ使わなくてもいいんじゃないか
素でバインディングじゃ無理な場合はビヘイビアというのでイベントをVMに通知したりする
それでも無理ならサービスクラスをViewからVMにインジェクションするんだが
コレは結構インチキ臭い（MVVMとして）
でもScrollIntoViewなんかを実行するならサービスクラスでやるしか無いんだよな
>>838 普通にコードビハインドでいいしビヘイビアでもできるだろ
>>834 バインディングした方が楽な時だけすればいい。
コントロールに名前つけてプロパティに値設定してやるオーソドックスなやり方の方が
結局メンテもしやすくコードもすっきりする事も多い。
いろいろ助かる。
素人すぎてどういうときにバインディングすればいいかわからんな。
ま、いろいろ試すしかないな。
>>自分でコントロールの中身を手動で更新
今までそうしてたから苦ではないけどな。
>>839 ScrollIntoViewのビヘイビアは作ってみたが、一度表示したアイテムがユーザーのスクロールで範囲外になった時
それを再び表示するとなると、一度nullを入れてからアイテムをセットしないと動かない
美しくないからボツにしてサービスクラスにしました
ユーザーコントロール作るの大変なのどうにかしてほしいわ
添付プロパティとかなんであんな実装大変なんや
>>843 俺もそこは気に入らんけどコードスニペットや拡張メソッド使えばそこまで大変ではないし添付プロパティなんか滅多に実装することないだろ
とにかく面倒くさいという事がよくわかる
いやーー早期にReactに移っといて良かったわーー
データバィンディングについて良いHPあったら紹介を求む!
>>848 そのブログではプリズム使うみたいですね。
止めときます。。
バインドするだけなら、nugetにあるReactiveProperty使ったらどう？
あれが1番簡単そうに見えたけど
データバインディングの勉強目的なら最初は何も使わずにINotifyChangedPropertyぐらい自前実装でいいだろ
10行未満なんだし
バィンディングっていろいろ手法があるみたいでその辺も混乱の元ですね!
INotifyChangedPropertyの実装に関しては、prismもmicrosoft.toolkitもほぼ同じもの
Xaml側は全く同じだからどのHPを見ても何も問題ないんだけどね
prismで勉強して、些末な違いをMSのドキュメントで補完すればいいんじゃないかな
React界隈じゃ
不用なのものを徹底的に排除して突き詰めてるのに、
XAML界隈は
ライブラリー！ライブラリー！ライブラリー！
ドヤ顔ライブラリー房のこの違い...
Reactに対応するのはXAMLじゃなくBlazorなので
>>856 残念ながらUWPとUnoでしか使えないx:Bindはオワコンだ
x:bind最新のWinUI 3で使えないんだっけ?
やってみた。
x:BindはWinUI3もMAUIも使えるよ。
安心しな。
UWP作ってないしx:bind使ったこと無かったわ
その使い心地を見せて貰おうかっ
>>850 今日入れてみた。試してみる。
いろいろフレームワーク大すぎ。
MSが良いもの出さないからか。
こっちでの開発ではプリズム、
異動先ではReactiveProperty使用とか。
難儀やなぁ。
x:bindはUWPでコンパイル時バインドで速いという触れ込みがあったから使ったみたが速度差体感できずコンパイル時の型チェックもうざいので俺はbindindに戻ったけど
コマンドに使用可否だけじゃなくて、表示非表示も持ってほしいよな
VisibleとEnabledを自己バインドすればいいだけじゃね
ｘ：Bindはイベントがバインド出来てFormsのやり方MVVMででコーディングできるんだっけど
そこらへんをアピールするつもりはないようだね
ビヘイビアが難しいわけじゃないけど冗長だから使わずに済むのも大きいね
どういうケースを想定してるのかわからんわ
disabledの時に消せばいいんじゃないのか？
そもそも表示しない
表示するが無効
表示するが有効
この3通りをやりたい時がある
get -> そもそも ？ hidden : 表示する ？ visible : hiddem;
そんなことしたいと思ったことないからわからんけどコマンドとのバインディングでしなきゃいけないなら継承するしかないな
俺ならViewModelのプロパティを使うが
例えば、ログイン機能があるアプリとかでログインしてなきゃ更新ボタンをそもそも表示しない
で、ログインして更新ボタンを押して更新中になったら一時的に無効に切り替えてとか
たまに、表示/非表示と有効/無効を別に扱いたいときがある
単純にコードビハインドでやれば良くね？ 頭悪いの？
それログインボタン以外の管理用機能が必要になった時どうすんの
管理者フラグをVMに用意して管理者用コントロールパネルごと消すべきだろ
個々のコマンドじゃなく
例えが悪いなら謝るが
別にボタンの他に、メニューにバインドされる可能性だってあるし
俺が昔必要に思った時のケースは思い出せねぇわ
そりゃ初心者は理解できんかもな
大きく複雑なプログラムを作る時に威力を発揮するものだから
>>879 らしいね。
みんなもそうな大きく複雑なもの作ってるんだ?
そもそも世の中に転がってるシステムに疎結合なんて不要な気がするわ
設計に時間かけれる人は自己満足でやってもいいかもしれないけど
WPFの主用途はゴリゴリの業務アプリだから、複雑なのはUIではなく業務フローなんだよね
ただ画面数が多いだけだ
>>881 UIとロジックは疎結合にしろ、てもう聞き飽きた。
そんなに大事なんかね。
>>885 VMが出てきたせいで、コードビハインドは悪、画面に関わるコードはすべてVMに書くべきってイメージが出来ちゃったのがなぁ
それ狂信者が勝手に言ってるだけだぞ
マイクロソフトはむしろコードビハインドを推奨してる
>>883 しかも業務アプリって見栄えはあまり
重視せず、使い勝手や速度が優先されるからな。
ボタンが回転したりそんなのどうでもいいわ。
今まで通り非MVVM?のイベントドリブンだとボタンを
押したときの挙動はそのイベントハンドラ(だけ)に記載
されるているのは間違いない訳でソースも追いやすいし、修正、
機能追加もし易い。
自分は知識としてMVVM? 学習してるけど使うことはなさそうだなぁ。
極論かもしれないが、MV*って結局ユニットテストを作成するかどうかだと思っている。
ユニットテストが要らないような規模のプロジェクトなら好きにすればいいのではないかと。
規模といっても色々あるからね
大抵の業務アプリでは全体としてどれほど大規模で複雑なシステムでもただ画面数が多いだけで個々の画面に対する要件はシンプルなので、
UIに関するロジックのユニットテストは手動ポチポチテストと一緒にやっちゃう、でも問題なくスケールする
Excelのあの膨大なコマンド全部手動テストすんの？
MVVMじゃないとテストコード書けないと思ってる○○www
書けるけどさあ
結合テストだけって結局バグ取り切れないから意味ないんだよね
テストコード書くためにMVVM選択するつうのは余りにもセンスがない
知らんのか？
今の開発はテスト最優先だぞ
しつこくXAML推しして他の言語disってたやつがBlazor知ったらすぐそれかい
手動テストするって言っておきながら
テストコード書くと言われても突然前提ひっくり返すなよ
MVVMだと昔自分が書いたコード見てもシンプルで理解しやすいな
>>897 もしかしてロジック全部VMに書いてるの？だとしたらその方が問題だろう
普通はビュー(MVVMならVVM)とモデルの分離は大前提で、少なくともモデルはテスト書くでしょ
その上でビューのロジックの単体テストまで自動でやるかどうかというだけの話なわけだけど、なんか根本的なところを勘違いしてないかな
VMをテストすればVのテストは要らんわけだがこれを分離しないならVでバグる可能性もあって面倒だぞ
MAUIとかスマホでテストすんのか
いやMVVM使おうが画面と繋いで最終的な手動テストはさすがにやるだろう。
モデルの単体テスト、UIの手動テスト、そしてそれに加えてVMの単体テストを仮にやるなら、VMの単体テストで確認すべきは当然VM固有のロジックのみだ。
まあVMのロジックに対する網羅的なテストをUI経由で毎回やらなくていいから継続的な開発の効率化には寄与するだろう。
ただ、まともな組み方をしてれば一般的にはVMのロジックはかなり少ないはずで、そこまで大きな差にはならない。まともな組み方をしてればね。
ロジックっつーか、どのコマンドを発したらどのプロパティがどう変わるかくらい単体テストでできるだろ
これ手作業でやんのかよw
>>886 あくまでイメージなだけで初心者がそれを信じてしまってるのがなぁ
開発工数が削られると最後のテスト工数を削るしかなくなるんだよな
全体で見積もりだしても要件定義でダラダラするから工数足りなくなることなんてザラだし
「ちょっと変だったけど納品までには何とかなるだろ。」
とりあえずシステム起動できるかどうかだけは納品前に確認しておいてくれ
>>912 コーディング段階で異常系を端折る
取り敢えず正常系が動けばOK
ListView等のItemTemplateにボタンなどを置いたとき
コードビハインドにイベントハンドラ置くのが一番楽だからな
頑張ってVMに置いても良いことなど一つもない
ビハインドと共存できないMVVM原理主義者がいるのも事実。
一緒に仕事をした時はびっくりした思い出。
>>917 んなこたない
一つのコマンドを共有してバインドしても手間は変わらん
グラフコントロールとか実装しだすと
データバインデングとか糞過ぎるからな
1つのコマンドを複数のコントロールに割り当てるってほとんどなくないか？
ゲームのUIくらいじゃない？
DataGridでわけわからなくなり、ListViewに。
ソースコピペしまくって一応動作したけど訳わからんわ。
DataGridでわけわからなくなり、ListViewに。
ソースコピペしまくって一応動作したけど訳わからんわ。
複雑なコントロール操作が必要なとき
MVVMとか持ちだすとコードが滅茶苦茶になりがち
良く発生するのが、
バインデングの実行順序
コードビハインドだと
複数のプロパティに意図した順番で値を設定できるが、
さてバインデングではどうなるか？
考えた事すらないんではないか？
昔（なんせ10年以上も前）に調べて
ネット上の資料を見つけた事があるが
もう忘れてしまったね
まずそんなことする必要がない
イニシャライズ以外でプロパティの設定順序によって動作が変わるような設計が悪い
それでも糞設計でどうしても順序が大事ならワンウェイバインディングにしてコマンドから設定すべき
>>928 あるコントロールの
プロパティA
プロパティB
プロパティC
にデータバインデングした
さて値が設定される順序はどう判断すればよい？
>>929 だから、そんな順番でロジックが変わるのがクソって話をしてんだがw
それでどうしても順番が大事ならコマンド使って順番に入れたらいいぞ
二回同じこと言ったけど読めるか？w
プロパティABCが相互作用するのをイメージしてるんだろうけど
それをUI層で解決しようとするのが間違い
MVVMは単純なレベルで破綻するという事だ
本件意外にもモデルがダイアログと対話するだけでも大騒ぎになるのよ
結局MSのホワイトペーパー漁るはめになって苦しい言い訳しなきゃならん事になる
そんな順番に依存していたら、プログラミングなど出来ない
永遠にバグり続ける
UIでの順序って、バリデーション時のチラ表示かな？
ビハインドでのカキコはレスポンスが大事な時と、フォーカス移動やDataGridやGridViewでの範囲選択処理ぐらいしか思いつかないが、他に何かある？
まぁ なんでもかんでもビハインドに書くのあれだし、DialogやMAUIのPopupやカスタムコントロールでもViewModelを作るMVVM教もなんかなぁーとは思う。
勉強としてWINFORMのアプリ(CSV->DataGrid)をWPFに作り替えてるけど
面倒くささ300%増し。
表示するだけなら兎も角、特定のデータがあるカラムの文字色を変えるところで
難儀中。
サイトみたらもっとも難しいコントロールで、難しさから諦める人も多い とある。
諦めていいのか??
>>937 何が難しいんだ
ItemsTemplateとValueConverter作るだけだろ
>>919 ItemTemplate内のイベントはコードビハインド使わずに処理すると可也めんどいだろ
結論はWindows SDK Appに移行すれば解決だな
イベントバインディングでVMにコードビハインドと変わらない理屈でコードが書けるし
単体テストも問題なく出来る
>>941 それだとsenderがobjectじゃん
>>942 ビジュアルステートって数行じゃ終わらないだろ
それとWinUIだとItemTemplateの内部じゃ使えないからイベントハンドラ呼んだほうが早い
>>945 なんでステート使うんだ
コンバーター作ってるんだからそれをBackGroundにバインドして数行で終わるだろ
ここまで読んでわかったけど結局お前らが難しいと言ってるのはMVVMじゃなく単一責任原則と疎結合なんだよ
それはモダンプログラミングの基本だからそれが難しいと言うことは自分にプログラマの素質が無いと自分で言ってるようなもんだぞ
>>946 コードビハインド使わずにイベントを拾うならビジュアルステートだろうに
コンバーターならデータの中身しか使えない
>>948 データによって色を変えるんだからそれで問題ないぞ
まぁ DataGridの部分選択、部分範囲状態をスキャンするめに、ViewModelからViewを参照する人もいるからな。
そこまでして、ViewModelでやる意思は凄い。
当然、SRPなどというクリーンアーキに住んでいない人の方が多い。
>>951 レスを辿れば分かるよ
そっちの話は最初からしていない
DataGrid継承してオレオレDG作ればコードビハインドじゃなくなるからオススメ
どのバージョンでも疎結合を知らないプログラマは厳しいよ
WPFはMS的には既にレガシー扱いで開発終了してるからこの先新機能が入ることはない
かと言ってWinUIやMAUIにはすぐに置き換えられんからなあ
INotifyDataErrorInfoにすら対応してないWinUIの完成度よ
WinUIでMVVMできるしまだそれが推奨だぞ
そのうちMVUになるから絶望しろ
>>956 そこまで気が回る人なら、MVVM真理教でのたうち回っていない。
問題解決能力が全てだという事を肝に銘じていない人に何を言っても聞く耳は持たない。
クリーンアーキはMVVMの基本で、インターフェースで繋ぐ方向が全てだ教えても、10年変わらない奴は、それだけの存在。
DataGridを継承してINotifyChange含むプロパティーを追加するなどという発想がでるわけもない。
>>936 要件が簡単すぎる
設定パネルUIに複数のインジゲータUIをバインド
表示データーはさらに別のスレッドからバインド
監視系だとこんなんザラでしょ
スレ見てると、玄人専用、馬鹿は使うなって感じするわ
こんなじゃ広まるわけないわな
OOPの観点から探ると、アプリの作り方はMVVMに向かうようになっている
すべてが部品で、それでもってアプリが構築されているという姿
MVVMを否定するならカプセル化だのなんだのというところまで否定してプログラム書いたほうがいい
そのほうが一貫性がある
>>968 いやいや、そんな事はない。
検索件数でわかる。
前よりはちょっとは広まったぐらいじゃね
ただし、androidやiosのそっち方面のお陰で
つか、jetpack composeとか最新の環境だとDialogやポップアップメニューも
visible変数どっかで持って自分で切り替えるはめになるし結構徹底してる
winformより広まってないよな
ネットで出てくる情報の量が少なすぎるよ
そういうので更に広まらなくなってる気がするわ
>>964 それ、コントロールの継承と言うかカスタムコントロール作るよりビヘイビア作ったほうが楽じゃね？
そういやプロパティーの順番どうのこうのも、ビヘイビア作ればコードビハインドと同じ処理が簡単にできるだろ
TextBox c# 等で検索すると殆どがwinformsなんだよ。
検索結果の数はともかく検索のしかたにセンスがない
場所はgoogleじゃなくlearn.microsoft.comを使え
検索したいものによって検索する場所を変えるのは基本だ
それからc#じゃなくwinformsやwpfなどのフレームワーク名を使え
一つの言語に同名のコントロールが複数あるのにそれを指定しなくてどうする
自分の欲しい情報がなかなかみつからないのはそういうとこだぞ
検索のしかたが下手でみつからない理由をを情報が少ないからと判断したんだろう
プログラミングでいちばん大事なのって情報量だよね
特に趣味でやってる俺みたいなのにとってはチュートリアルがないときつすぎる
普及させたいならMSはもっとそういうのに金かければいいのに
>>981 チュートリアルあるぞw
検索すればすぐみつかる
WPFの書籍とか需要あるの？
WINUIじゃないの？
俺もbehaviorには触れたくない。 継承で済むものはその方がいい。
ビヘイビアとかWPF特有な物はなるべく使いたくない
普及しない原因は学習コストが高すぎるってのもありそう
>>987 むしろwinforms以外はwpfもuwpもwinuiもmauiも全部behavior使うぞw
作るのだってcommunitytoolkitにテンプレートあるからそれを継承するだけ
ビヘイビアは依存関係プロパティーがゴツいだけで、xamlでアタッチできるイベントハンドラだから難しいものじゃないんだけどな
依存関係プロパティーもxamlでバインド出来るプロパティーってだけだから詳細まで知らなくてもなんとかなる
後はOnAttachedをオーバーライドしてイベント登録してOnDetachingでイベント削除
イベントハンドラの中を記述すれば出来上がりだし、汎用性が高いから使いまわしも出来る
>>988 まじ？それならちょっと勉強しようかな
調べたらこんなこと書かれてたから、迷うわ。
MVVMに準拠するとコードビハインドが使えないので、その代替手段ということになる。
>>992 1番上に出てきたからな
みんな、それを参考にするんや
誰が書いたかとか気にする人なんて一握りじゃない？
>>992 さっぱりわんらんわ～。
winformだろうがWPFだろうが
ぶっちゃけ手法はどうでもいい。
客が納得すればそれが全て。
>>993 みんなが参考にしてるのにいいねが少なくてコメントも無いのがどういうことか考えてみたらどうだ
>>994 それが昔の落ちまくってた頃のwindowsやofficeの作り方だ
>>995 天下のGoogleが1番関連度高いって言ってくれてるから大体の人はそっちを信頼するんじゃない？
lud20250209233656caこのスレへの固定リンク： http://5chb.net/r/tech/1649621434/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「WPF(.NET, WinUI) GUIプログラミング Part29 YouTube動画>1本 ->画像>11枚 」を見た人も見ています：
・WPF(.NET, WinUI) GUIプログラミング Part32
・WPF(.NET, WinUI) GUIプログラミング Part30
・WPF(.NET4.x, .NET Core) GUIプログラミング Part24
・WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part21
・WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part19
・ヒッキーのプログラミングするスレ10(旧 プログラミング雑談 in HIKIKO)
・ヒッキーのプログラミングするスレ 9 (旧 プログラミング雑談 in HIKIKO)
・【嫌儲IT部】6歳の女の子が開発したプログラミング言語『Kuin』が公開される「HSP並に書きやすく、C++並に実用的」がコンセプト
・Windows VS Macプログラミングに適したOS
・プログラミングに適したOSはWindows10かMacOSXか？
・■WindowsCEプログラミング（EVC PB3含む）Ver2.2■
・【IT】グーグル、プログラミング経験不要で「Android」「Kotlin」を学べる無償コース提供 [田杉山脈★]
・【プログラミング】PowerShellってbatとかスクリプト言語とかcygwin＋bashとかと比べて何がいいの？
・WindowsならVisual StudioのC#が1番素晴らしいよな、新参の新しいプログラミング言語とか要らないんだよ
・【嫌儲プログラミング部】Kindleストアでプログラミング・IT技術書が半額セール、人気のPython機械学習の解説書も
・botAIプログラミングコンテストで勝負しようぜ
・AIイラスト…AI作曲…AIプログラミング…重機や建機にAI搭載試験…警備ロボ…
・【IT】小学生プログラミングコンテストで11歳女子ひかりさんの圧倒的プレゼン力が会場を騒然とさせる
・【プログラミング】エンジニアに愛されているエディタ、第1位はNeovim [すらいむ★]
・素人「プログラミング勉強したいー！」バカ「じゃあこう打ち込んで・・・ほら「Hallo Word」ってでたｗ
・【嫌儲IT部】プログラマモメン御用達のプログラミング情報共有サイト『Qiita』にてUIの一新と軽量化が実施される これは良い感じじゃね？
・プログラミングをするゲイ
・プログラミングの勉強法
・雑談 プログラミング
・プログラミングをしたい件
・プログラミングしようぜ
・プログラミングを教えてくれ
・プログラミングおしえて
・プログラミング学びたい人
・七行プログラミング part6
・サウンドプログラミング6
・プログラミング始めたいんやが
・プログラミング詳しい人来て
・プログラミング初心者あるある
・プログラミング始めたいんやが
・プログラミングを教えて下さい
・0からプログラミング始めたい
・プログラミング超初心者の質問
・プログラミングを始めようと思ってる
・プログラミング雑談 - 初級編
・プログラミングつまんな過ぎワロタ
・UNIXプログラミング質問すれ Part8
・プログラミング言語Pythonの欠点
・競技プログラミングは役に立たない
・プログラミング言語C#について語ろう！
・競技プログラミング総合スレ 64
・プログラミングにはMacとか言う嘘
・プログラミングのお題スレ Part7
・Macでプログラミングやってるやつwwww
・なんJプログラミング＆電子工作部 Part.2
・就職以外でプログラミングで稼ぐ方法
・普通科高校高2プログラミング系志望
・Google NaCl プログラミング 2mol
・数学ってプログラミングに似てない？
・プログラミングに向き不向きは有る？
・プログラミング言語ってなにがいいの！？
・ヒッキーの競技プログラミングするスレ
・NHK教育を見て61652倍賢くプログラミング
・理系大学一年が学ぶべきプログラミング言語
・プログラミングって若い頃しかやらないよな
・子供向けプログラミング言語ビスケット
・プログラミング言語のオススメ教えてくれ
・中卒にもプログラミングって出来ますか？
・プログラミングの始め方を教えて〜
・プログラミング簡単すぎワロタｗｗｗ
・プログラミングできる人 来て(ヽﾟд)ｸﾚ Ⅱ
08:49:05 up 65 days, 9:47, 0 users, load average: 8.36, 9.10, 9.55
in 1.832582950592 sec
@1.832582950592@0b7 on 062121
|
