WPF(.NET4.x, .NET Core) GUIプログラミング Part25
レス数が1000を超えています。これ以上書き込みはできません。
Windows Presentation Frameworkについて語るスレ。
前スレ
WPF(.NET4.x, .NET Core) GUIプログラミング Part24
https://mevius.5ch.net/test/read.cgi/tech/1575862574/
関連スレ
Windows 10 UWPアプリ開発 Part 2
http://mevius.2ch.net/test/read.cgi/tech/1499658092/
コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured 前スレでVSCodeの話題が出てたけど
VSCodeでXAMLが快適に書けるようになるのはまだまだ先なのかなあ
プレビューは難しいとしてもインテリセンスくらいは利くようになってほしい
あと、VSCodeで出来ることは基本VSでもできるものと理解してたんだけど違ってる？
ReactもVueもVSCodeはもちろんVS2019でも普通に開発できるしMicrosoftDocsにVS2019でのチュートリアルも用意されてるような
それともVSだと開発に必要な機能が全然足りてないってこと？ >>2
>>ReactもVueもVSCodeはもちろんVS2019でも普通に開発できるし
数年まえから出来ません！！(*>ω<*)(ﾉ∀`)ｱﾁｬｰ そうなのかあ
https://docs.microsoft.com/ja-jp/visualstudio/javascript/tutorial-nodejs-with-react-and-jsx?view=vs-2019
あたりを見る限りReactの開発も問題なくできるのかと思ってたんだけど
この程度じゃ全然だめってことかあ
SPA開発やったことないんで分からないんだけど、
>>3の考えてる「できる」の水準に達するためにはあと何ができるようになってなきゃだめなの？ >>6
vsじゃオープンソース系のプロジェクト
デバックするのむりだよ。
苦労しても無駄におわる。 前スレ最後の方
>OfficeでもWPF使えよ
わろす 他の言語でGUIプログラミングしたことある人からしたらWPFはどう？快適？
このスレだとWinFormsかUWPとの比較で終始するだろうから良さが分からん XAMLにてテキストベースでのデザインがイケるとこが快適。 やっぱ今から開発するならWindowsUIを選択しとくべきかな？ WinUIの問題はSupports non-MSIX deploymentが未定で恐らく１０月ってところかな
それまでは証明書とるかStoreに置かないとインストーラー作れない .Net5の話が出てきてついにうちの会社もWPFベースのアプリを作ることになりそうなんだけど
何でこんなにデザインするのが面倒くさいんだ
ボタンにイメージを貼り付けるだけでも一苦労だ
慣れたらみんな目をつぶってリソースファイルを関連付けられるようになるの? <Image Source="{Binding Source}"/>
なんかこういうバインドするための記述がいまいちどういう種類があるのかわからん・・・ 何かSpotifyでだらだら聴いてたらラムシュタインがやたら格好良くて濡れた .net5でもwinforms使えるんじゃなかった？あと濡れ濡れかよ >>21
なにもかわらん。
（出来る事が増えただけ）
相対パスを指定
<Image Source="/xxxx.png"/> >>21
見たらプロパティパネルから
出来んじゃないの。(*>ω<*) Bindingさぁ、Visual Studio上のGUIで指定できるようにならんかね？
この数値をここに表示したいんだけど、ってな風に >>27
移行を機にDPIスケーリング(高解像度)に対応したいとか? >>28
ある程度は指定出来るようになってる。でも
・バインディンク構文間違ってなくてもエラー ・ウィザードでは出来ない指定が多々
は勘弁しちくれ(*>ω<*)な！ ストアアプリならUWP、スタンドアロンならWPF。
ストアアプリ作る人が少ないだけ。 ストアを開いたのってWSLを入れたときの1回だけだな
ストアが開設されて8年のはずだけど1回 UWPは仕事で過去2回手掛けただけ。
UIがダサすぎて
新規なら全力で採用せんわ。 そりゃ何使ってもきちんとデザインしなきゃ見た目は悪いわな… winui 3 preview 4 released >>31
UWPは融通が効かん
WPFならアプリ野良配布も簡単だしexe->exe呼び出しもできるし >>31
UWPはセキュリティ重視で出来ることの制限が厳し過ぎた UWPはWindow10以上でないと動かんし
どんな馬鹿が作ったんだよ >>25
みんなexeフォルダに画像ファイルばら撒いてんの？ >>40
作ったのは、馬鹿じゃなくてお花畑だと思う。 >>44
winformsならボタン右クリックメニューからリソースの画像を選択出来る androidとか慣れると、windowsの非sandboxアプリインストールするのすごい気が引けるわ
フル権限必要なアプリなら仕方ないけど、ちょっとしたアプリならUWPで android とUWPの違いを論ずる前に
アプリの起動速度をAndroid並みにしてから言え！
ですな UWPは実行ファイル小さいから直ぐ立ち上がるんだけどな XAML、セコセコ書きたくないわ。というか書けん。
全然、「VISUAL」じゃないじゃん。 昔ダイアログしかポトペタできないのにVisualと謳ってたツールがあってな VS6.0(MFC)初めて使ってコントロール貼り付けで楽々で感動したのに。
逆戻りしてるって感じ。 WPFでポトペタがお好みなら自動的にインストールされてるBlend for Visual Studio2019使えば 別にWPFとVisualStudioでもポトペタできるだろ vsが重くてWPFのポトペタはきつい。
ノートじゃむり？ XAMLにいろいろ詰め込みすぎ
レイアウト限定にすればすっきり 仕方なく勉強してるんだが、動作がおかしいとき、XAML側に問題があるのか、
ソース側に問題があるのか良くわからくね?
慣れればパッっとわかるもん? >>64
だいたいバインド失敗してるからログを見る >>65
V側からVMを参照させるのが主旨だろう。
レイアウトのみにしたら外からVを参照しなきゃならなくなるがそれこそ主旨に反している。 >>63
アニメはcssのほうが優秀だわな
VisualStateManagerは細かい制御できるけど
あまりに複雑だ
UWPだと使えないときもある バインドって初心者用?のサイトみるとスライダの変化で自動的に数値が変わるんで
イベントドリブンの記述が不要とかテキストボックスに文字いれるとこっちの
テキストも変わる、とかあるけどそんなもん?
他にもっと有効な使い方ってあるん? >>67
>>63,65はWinForms脳だから今更そんなことを言っても理解されないぞ 来年位に登場するMVUが出てから苦労する方が良いぞ。
https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/?utm_source=vs_developer_news&;utm_medium=referral
XAMLも残るし（恐らくおいしい所はXAMLがそのまま使えると思もわれ、
テンプレートとかはそのまま使いたいなーー
ビヘイビアーとかトリガーとか糞クソは使かわねーーよなーー）
Reactやflutterと比べても恥ずかしくない位の実装が可能になるぞ。 これで、OS問わずマルチプラットフォームで使い物になれば
クライアント開発環境としてはマジで最強かもよ。 mauiの最大の問題はmauiが基本がプラットホームコントロールのラッパーであるということ
つまり、各プラットフォームの最大公約数のしょぼ機能しか共通化できない
もちろんカスタムビューで独自描画のコントロール作れるだろうが誰がつくるんだ? Xamarinは独自UIをサポートするらしいですが、
Xamarinなんであんな期待しない方がよいですかね。
自分も独自UI派なんですが、クライアントアプリだと他には
Unityやflutter位しか思いつかないけどですね。（WebView使う以外、他にある？） XamarinのUI関連の大言壮語は聞き飽きてるからなぁ
あまり期待しない方が良いかと WinUI 3の プロジェクト作った時点で、ソリューションエクスプローラーの依存関係が解決出来ないとエラーになるんですが、何が足りないのでしょうか？
https://i.imgur.com/LThIdEb.png >>73
このMVUってどうやってテストするんだろ。
テストフレームワークから中のButtonなんかにアクセスできるのかな。 テストコードでコード読めなくしちゃいかんよ。
ＤＩ野郎も同じ。 Xamarinは姫プの取り巻き達がガチ勢を怒らせなければもうちょい流行ってたのかなぁ >>84
それでXamarinスレに変なやつが居着いちゃったのかw >>84
企業の紐付きユーザ会の公式セミナー
の開催中にお誕生会のケーキカット
まですれば、そういう人達の集まりと
思われても仕方ないと思うの。知らんけど CocoaでもXamarinに責任押し付けられてるな 我々クソザコwinformマンは今後人権ない感じですか？ >>88
アトミックなファイル更新すら考慮してないうんこ実装だったのは事実だし まあ、Xamarinの問題というよりは、そこをコミットした奴に基本的な知識が欠けていたって話ではあるが >>90
MFCのようになるがしばらくは生きていけるだろう >>90
WinFormsマンは元VB6マンな印象
ｲｷﾛ！ >>95
WinFormすらできないVB6マンが協力会社にいるわ VB6マンってクラス作ってオブジェクト指向で作ってる？
社外のVB6やVBAでまともなソースコード見たこと無いんだけど。 WinFormsマンだけど、今のところWinUI3楽しんでるよ。
昔WPFちょっといじってたから、思ったほど違和感なかった。
たぶん暗黒面を見たらイヤになるんだろうけど。 マルチディスプレイ環境で、「全てのディスプレイにまたがってwpfウィンドウを最大化する」って可能です？
ユーザーが手動でウィンドウ引っ張って伸ばすしかない？ マルチモニタと言っても解像度が同じとは限らないし自分でやらないと無理なんじゃないかとおじさんは思うのです。 SystemParameters.VirtualScreenLeft とか Width とか取得してそのサイズにすればいいんじゃね？ wpfを基礎から勉強したいんだけど
おすすめの参考書ってある？
ちなみにwin formマンです .Net 5が出たと思ったらもう.Net 6のプレビュー版が出てるのか .NET 5 は俺がまだ青い頃に
既に出てた気がするが... あとは追加パッケージなしにWinUI3が使えるようにしてほしい。
はよ。 >>107
完全に内製開発前提になってて、ジャパニーズドカタはもう完全に置いてけぼりだな ドカタerは名前ばかりのLTSなんてあてにしないで.NET Framework使うから 実践にベータ版を投入してるのは
基地外でしょうか？ 実践の内容による
金もらってる相手にはさすがに適用しない（そもそも品証とかが関与してくるし）けど、部署内のシステムとかでごめんなさいで済むなら適用することもある >>105
はっきり言って「無い」。それがWPFが普及しなかった最大の理由だと思ってる。 >>116
言える。
あとMVVMが理想としてもMVVMで作ったほうが良い大規模な
アプリなんてそうそう作らんわ。
大規模としてもいらんし。 あの公式サイトの壊れた日本語見るだけで
嫌になる。
Google翻訳の爪の垢でも煎じて飲めや WinFormでも工夫すれば高解像度で使えるし。
今更、XAMLなんてチマチマ書きたくないわ。(というかできない) >>118
慣れれば自分用ツールみたいなのもMVVMの方が作りやすいよ
WinForm久々に組むとイベントハンドラ書くのがしんどい
コマンド周りだけ面倒だけどね WPFは本来パッケージソフトの開発に使うためのものなんだよ
UIに金かけても客が増えれば回収できる
時代はSaaSに移ってしまったからWPFは用済み WPF、かなりうまくやれば良い見栄えのものになるだろうな。
これは市販品には求められるんだろうがな。
SaaSなんて初耳。 いまだにWPFの価値がUIの見栄えだけみたいに言ってる人がいて違和感 イベントハンドラでSQL垂れ流すようなクソ設計してない限りは大差ねえよ
結局WPFだって最終的には手で触ってテストするんだし >結局WPFだって最終的には手で触ってテストするんだし
自動テストやってないと確かに有難みがわからないのかも。 >>131
してるよ
そんな低レベルな話じゃなくて、最終的なUIとの連結は手で触ってテストするしかないし、そこの分離が適切にできてさえいれば大差ないって言ってるの やるかやらないか0-1の話じゃなくて程度の問題な。
Formの頃はアプリケーションロジック含めてUI経由でやらなきゃならない場面も多かったけど
MVVMになってからは基本的にバインディングが正しいかどうか(状態があるものについては
各状態毎に)確認する程度で手動テストの項目数を大分減らせた。
>そこの分離が適切にできてさえいれば大差ないって言ってるの
まぁ、Formでもイベントハンドラとそのロジックをきっちり分離していれば同じようにできるだろうが
それやるならWPFの方が楽だよなぁという印象。 >>126
マジレスで、WPFのメリットって、例えば全画面表示にしてもボタンなどがズレないように出来るっていう見栄えの部分と、イベントが発生した時に即座に再計算だの再表示だのしてくれる部分かと思ってた。他にも「これ忘れてるぜ」みたいなのある？体感的なメリットを100%のうち、何%見栄え、とか書いてくれると嬉しい。
あと、テストがやりやすいってのはWPFの話じゃなくてMVVMの話と考えていいんだよね？なんかそれらをごっちゃにするから話が必要以上に複雑になってきてる印象。それほど自動テストが重要というんだから、WPFやるならMVVMやらないと意味ないよってほどMVVMは欠かせないのかな？ このDarknetの出力が正しいかWPFで検証して
はくれまいか？
単体テスト機能で簡単に検証出きるんでしょ。 >>134
WPFだからMVVMを使うというより、UIの要件が複雑だからWPFやMVVMを使う、が正しい
WPFになって従来よりリッチなUIを作れるようになったが、リッチなUIになれば当然その分制御が複雑になる
そのため、追加の抽象化レイヤを設けて複雑さを低減しようとする試みから生まれたのがMVVM >>76
ザマは人脈無いと使いこなせないって聞いたよ昔に WpfとMvvmが全てじゃないけど、フォームを開きまくるアプリからページ切り替え型のアプリに移行するのもメリットの一つだな
wpfと言うよりprism+unityのお陰だけどね >>118
MVVMが理想？
笑
でもこの"笑"が
昔は通用しなかったんだよな。 今や1 way bindingが主流で、MVVMは時代遅れだからねえ >>140
そりゃシンプルさを真っ向から全否定してる
WPF+MVVM だったら
2 wayぐらい出来なきゃダメでしょ。
もっと糞になるよ。
話し変わるけど、
低レベルPGが大量に投入される案件には
WPFのMVVMは向かんね。
最も美しい状態のコードでも糞クソなのに
輪をかけてクソコードの連発になる。
コード読んでて発狂しそうになるわ。 webでVueとかやってたらこんなクソみたいなものやってられない
そもそもデスクトップアプリなんて簡単に作れればいいのに、変な作法を要求するのが頭おかしい >>134
>>テストがやりやすいってのはWPFの話じゃなくてMVVMの話と考えていいんだよね？
MVVMの話しの事だけど、
ここに住み着いてるテスト坊が言ってるだけの事なので
気にせんでもよい。
>>136
誤り。
Blendを機能させる為に
肥大化した仕様になってしまっただけ。
MVP（MVVM）モデルはあんな大量のコード書かなくても実現出来る。 >>142
このところ立て続けに2案件連続で
MSのMVVMからのリプレース。
to vue.js
to asp.net + knockout.js
コード酷すぎて泣けてくる。 knockout.jsいいぞーー
これもMS系列のMVVMライブライリだ。 wpf 嫌われてるけど重い計算ガンガンするやつは何がおすすめ？
結局winformに戻るしかないの？ >>98
まともにVB6使ってたら
そういう作り方は言語仕様により出来ないし >>149
UI使って計算するわけじゃ無いんだから重い軽いは関係ないっしょ
UIの要件で何使うか決めなはれ >>149
MVVMはWPF(XAML)の上に
XAMLを使って足されたライブライリですよ。
WPF(XAML) + MVVM
winForms開発者には引き続きイベントハンドラーでの実装がサポートされます。
WPF(XAML) + コードビハインド
てかUIコントロール作ってるレベルの人は
最初からMVVMとか使ってません。
てか使ってもパフォーマンス悪すぎて使えません。
ちなみに来年にWPF(XAML) + MVUが登場します。
これでやっとReactとかに追いつきます。 そしてMVUも流行らずに数年後にまたMVなんちゃらが登場するのであった >>136
> WPFだからMVVMを使うというより、UIの要件が複雑だからWPFやMVVMを使う、が正しい
> WPFになって従来よりリッチなUIを作れるようになったが、リッチなUIになれば当然その分制御が複雑になる
喧嘩腰じゃなくて冷静に書くけど、
それが正しいなら、UIの要件がシンプルでリッチなUIも不要な場合はWPFおよびWVVM要らないよね？
まず、このYes/Noクエスチョンには答えてほしいな >>138
ずっと前、WPFでページ切り替え型のサンプルコード実行してみた
まぁまぁ便利だったけど、二つのフォームの内容を同時に見たい時は
やっぱりページを行ったり来たりしないとだね >>154
シンプルでも
リッチでも
MVVM原理主義で無い限りいらんとです。 >>140-141
えーっ、1 Way Bindingのみが主流なの？
じゃ、例えば、
A: 123
B: 456
みたいな入力ボックスがあって、
B=A*2
A=B*0.5
みたいな相互関係になっている場合はどうすんの？ MVVMを実現するDataContextやBinding、INotifyPropertyChangedなどは
最初からWPFを構成する要素なんだが。
ところで、
>ちなみに来年にWPF(XAML) + MVUが登場します。
MAUIのMVUがXAML使うとか情報あったっけ？
それともMAUIとは別にWPFにMVUが導入されるとか？まさか。 >>154
そこは適材適所で良いんじゃないかと。
たしかにポトペタでチャチャっと作る分にはFormaの生産性は高いと思うし。 >>143
テストがやりやすいってのがMVVMの話なら「WPFの」メリットじゃないよね、
他の言語でもMVVMで書けるんだし。
> Blendを機能させる為に
> 肥大化した仕様になってしまっただけ。
Blendはインストールしただけで触ったことないけど、
それが本当のような気がする
無駄に仕様が大きい
例えば、Animatable Model3Dとか要るか？使うか？って話だよね
俺は要らない >>155
メインに対してサブのページを同時に表示くらいならさほど苦労もなく実現可能だよ >>156
確かに要らないかも。
いろいろWPFでMVVMのサンプルコードを落としては走らせてみたけど、
コードが膨大な割には実行させると「え、これだけ？」みたいなのが多い。
>>159
そう言ってくれるなら納得。
データベースで言うと、チャチャっと作るにはSQLite、大規模なのを作るにはSQLServerみたいなね。
それで言うと、俺はやっぱりほぼほぼWinFormで作るべきだな、UIの要件からして。 >>162
そのサブページって、追加メニューから
（「新規のウィンドウ」じゃなくて）「新規のページ」で追加？
表示Visible/非表示Invisibleみたいな設定があるの？ モデルという概念が大抵のアプリでいらないんだよ
DBからの自動生成ならまだ許せるけどちょっとしたアプリにormみたいな概念はいらない
C#ならDataSetとかで十分やろ >>164
メインのフレームとサブのフレームを最初に定義して、それぞれに別のページを読み込むイメージ
エクセルなんかのマルチウィンドウとは別物だけど、案件によっては十分使い物になります >>157
ふつうに、AまたはBの変化をモデルに伝える経路と、モデルの変化をビューに反映する経路がある。
1-wayとか2-wayとか言うけど基本的にどちらもsingle source of truthの考え方に基づいていて
本質的な違いはない。なんとなくループが大きいのが1-way、コンポーネントごととか小さいのが
2-wayと呼ばれているような感じ。 そもそもデザインとプログラミングの切り分けが目的だったんだろ
なのにMVVMだのなんたらだの、といってプログラマのオナニー会場に成り下がってる >>165
MVVMではVMではあまり処理をせず処理の本体をModelに置きます
VMは複数のModelのメソッドを調整するのが主な役割ですね >>169
それrivetの作者の受け売りだろ
彼の主張信奉してるの日本人だけだし、外人でそんなこといってる人いるから?
一度ちゃんと自分考えた方がいい VがVMに依存してその逆ではないという点でクリーンアーキティクチャとよく似た考え方なんだよね。 >>165
>>ちょっとしたアプリにormみたいな概念はいらない
>>C#ならDataSetとかで十分やろ
話しあうね。 >>167
サンクス
片方が変わったらもう片方も変わる、みたいなのは1-Wayでも出来るのかな？
2-Wayではやったことがあって、1-Wayでは試したこともない >>168
そ！
これはMVVMが出たときからそうだった。
MVVM原理主義と
圧倒的少数の穏健派（俺もこっち側）の戦い。
Blendも初期から使ってきて
初見では震えるぐらい感動したけど、
あまりに肥大化するコードと
見通しの悪さに疲弊した。 あ、読み返してみたら>>140は「1 way binding」って書いてるんだな。
「1-way data flow」が主流ってんならわかるがbindingはないわ。 RivetもPrismも正しく動作したことがない
もう一つReactiveなんとかいうのも動作したことがない
「これが使えるとすごく便利！」みたいな書き込みがあるのに使えないからもどかしい
だから面倒でも自分でMVVMを構成しないといけない
これでWPFが嫌いになった >>170
標準的なページ遷移型のプログラム組むと、VとVMはページが変わるたびに再作成する
そしてModelはDIで永続化されるという仕組みだからVMにロジックを置きにくいんだわ
画面一つのアプリならVMにModelの機能まで作り込むのも一つのやり方では有るな
もっと小さいものならXamlのコードビハインドに全部作り込んでも良い >>175
穏健派自称するなら、MVVMいらないとかそういう否定から入るのはやめてくれや。 つか、お前ら経験足りないだけだと思うよ
MVVM本当に楽だよ
テストしやすいとかもあるし、コードの再利用とかもあるけど、そんなことより、新しい設計思想おぼえずに他のフレームワークでも使えるってこと
WPF/UWPでMVVM覚えて、今はandroidアプリとかモバイルアプリしか作ってないが
android/kotlinでもデータバインディング+MVVM
flutterはデータバインディングはないがflutterでもMVVM
全部アプリをMVVMで作ってる
もちろん、MVVMでなく一つの設計パターンがあればいいが >>174
モデルの状態が更新されることにより、それに依存している他のビューも結果的に更新される
MVVMみたいに、プロパティ単位でこれとこれが依存しててみたいなクソみたいな低レベルな制御はしないの Code behind の逆は Cfront かもしれんね。 MVVMでは基本、ViewModelとModelはその特性上、c#だろうがkotlinだろうが似たように設計できて、
ViewとViewModelの繋ぎ型だけが違う
WPF/UWPならxamlで繋ぐ
androidならデータバインディングあるからそれで繋ぐ
flutterはデータバインディングないけど、ちょっとコード書いて繋ぐ
いちいち、他のモバイルアプリ作るときにどう全体設計しようか悩まなくていい。とりあえず、慣れたMVVMでいけるから楽 >>176
MからVへのマッピングは宣言的、VからMへは手続き的
そういう意味では1 way bindingも間違いではない >>179
おいおい否定からはいっとらんぞ。
もともとMVVMがMessengerパターンで一応の完成？を見たあたりまでガチガチで組んでたし、
そもそもBlandをかなり活用してた。
ただコードビハインド使ったら負けみたいな意味不明なゲームには疑問を抱いてたりはしたりして、
その後Rx（Reactive）が出た位から、バインドいらんじゃんみたいになって
だんだんと否定派（穏健派）に転じた歴史だったかもね。 >>181
ああ、そういう仕組みなら大歓迎
そうそう、プロパティ単位でこれとこれが依存しててみたいなクソみたいな低レベルな制御だよね
そんなマイクロマネジメント要る？って感じだよね 結局使いこなせない人が悪口言ってるだけに見えるんなあ
同意できるのはa390-aJe7氏くらいだわ MVVMは、VMがMのラッパーでありながらVの抽象でもあるという点で単一責任の原則に反してるんだよ
VMのプロパティがVの状態に極めて強くバインドされているために、どうしても状態がMから乖離しやすい
>>186のようなプロパティ同士の依存関係って大抵のケースではMの共通の属性に対してVへのマッピングが複数存在するだけの単純な話なのだけど、
それぞれがV-VM間で2-way-bindingされていることにより問題がとても複雑になる それはそういう風に組んじゃってるからだろうな
初学者はどっちつかずの実装にしちゃってグチャグチャになる
その辺りガッツリ布教してないMSが悪い 書籍がないのが悪い
MSがまずまともな日本語書籍を出せ もう今更だよｗ
10年以上経っていて全く普及していないのだし
windowsアプリをネイティブで作る時代は終わりつつある
簡単なツール作るぐらいならWinFormsで十分だし
この用途ぐらいしか今は無いかなｗ >>192
この話しにwinFormsは全く関係ない あとMVVMが問題あるんじゃなくて
WPF流MVVMが...なだけ。
そりゃそうさ。
Blendを作る為に肥大化しちゃったんだもの。
angularとかknockout.jsは
そんなに酷い事にはなってないんだもの。 なんでそんなにBlendと絡めたがるんだｗ
Blendのせいで肥大化したってソースあんの？
アニメーション作るときくらいしか使わんが Blend Blend言ってる人の念頭にあるのはBehaviorじゃないかねぇ。
MVVMそのものとは直接関係ないし必要な人だけ使えればいい代物だが。 簡単なツール作るだけならWinFormsで十分っていうのはまぁそうだろうな
直感的だし覚えることも少ない
WPFに慣れればWinFormsを使う気にはならないが >>197
無論、それも含まれるのだが、
ViewとViewModelの結合を無理やりXAMLだけでやらせるという精神性だよ。
そこになんの意味があるのだ？ bindingはいずれにしろどこかに記述する必要があるだろうが「無理やりXAMLだけでやらせる」って
具体的にどういうことを指しているのかがわからんな。
しかも「精神性」ときた。 奴隷仕事する安いWeb屋以外には全く不要と理解した >>149
それだったらネイティブC系でないと。
全然違うぞ。 ツール位ならWinFormで十分ってあるけどWinForm以外でみんなはどんだけスゴイ複雑なアプリ作ってんだ?
WinFromじゃダメなアプリって一体。。 速度優先で描画って話になるとwinformじゃ
制約多過ぎなので、WIN32Apiで書くでしょ >>205
.NET以外のCなら良い。MFCとか。 ここでツールって言ってるのは自分しか使わないようなツールのことだろ？ >209
職場で30万ステップはあるだろう、電子診療録があるけどな。
1000人位が使ってる。 winformもwpfも絵文字を色つきで表示できないのがな…
業務アプリでも要望あるんよね 絵文字って〒とか？
リッチテキストボックスなら出来るんでは？ >>218
表示はされるけど、色がモノクロになってない? 試してないけどこれ？TextBlock.IsColorFontEnabled そういやMicrosoft.Toolkit.MvvmってのがPreview4まで来ていて
WindowsCommunityToolkit7.0の機能の一部として恐らく来月にリリースされそうだが
これ今後使われるのかな？
UWPだけじゃなくてWPFでもそのまま使えるものらしい wpfでGPU支援ありってのが売りになってるけど
windows.formsはGPU支援無いの? FormsがベースにしているGDI+はGPU対応ができないといって捨てられた。 テキストボックス コンボボックスなどのコントロールでGDIもGDCもないわ。 WinFormsマンはMVVMなんて完全無視してコードビハインドべったりでWPFやればいいんだよ >>226
誰かがWPFで
①MVVMパターン
②MVVMを使わないパターン
の実装サンプル作れば良いかもね。 ネット上にいくらでも転がってる
同じ課題を両方で、とかいう面倒な意味なら
対価と引き換えに作ってくれる人ならいくらでもいるんじゃね
俺とか >>226
柔軟なレイアウトの恩恵は受けられるんだから、これがformとwpfのいいとこ取りな方法だと思う 昔ながらのアプリならViewとModelの内容をリアルタイムに一致させとく要求なんてないんだから
ViewとViewModelだけ使うのもアリ >>235
それはMを勘違いしてるのでは
Mは直接的にドメインモデルやデータモデルではなく、UI固有の状態をモデル化したものであってもいい
VMとの違いは、VMはVと蜜にバインディングされることを前提にインスタンスやプロパティがVと一対一で対応する点だ >>232
prism使わずにmvvmは考えられないのだが、あなたは全部自前で実装しているのかな？
prism以外なら何を使っているのか教えてほしい
INotifyPropertyChangedやICommandの実装やViewModelLocaterは最低限必要でしょ ほらでた、prism 持ち出すクソ信者！
クソの上にクソを積み重ねたクソの塔 prism。
>> INotifyPropertyChangedやICommandの実装
それぐらい自前で書けや。
>> ViewModelLocaterは最低限必要
そんなもんいらん。
まあもう、大昔にデスクトップアプリは捨てて
クロスプラットフォームに完全移行したんで、
どうでもよいけど。 よく判らないのでword star か
GOFで説明してくれ >>237
INotifyPropertyChangedは簡単な自作クラスで、後はReactivePropertyだな >>240
INotifyPropertyChangedは2、30行位の共通コード書いて、
ViewModel内の個々の定義は１行で行けた記憶あり。
>>ReactiveProperty
だね。UIこそReactiveだ。
MVVMなんぞ使わずとも、
コードビハインドでＲｘフル活用すればかなりイケた実装が出来る気がする。 最近のデザインパターンってあんま聞かなくなったけど、
デザインパターンって勉強してんの？
これこそ基本と思うんだけど。 >>236
めんどくせー
WinFormsを前提とした話なんだから
そんな厳密な話でもないやん 自分の主戦場でも、状態管理ライブラリの流行があって、
量産されたクソコードが有難たがられる風潮になっちゃんてるんだけど、
それってデザインパターン的な実装能力の欠如から来るんじゃないかと思っとる次第。 Microsoft MVP for WSLであり、KENTAの師匠でもあるぞ。
業界に疎いのか？ >>243
もっと詳しく！
まず、オワコンの理由は？
あと、デザインパターンがオワコンなら、それに代わる代替手段はあるの？ >>249
ラベルされたものを信仰するような？？では無いので。 >>251
そいつLinux板も荒らしまわってるやつだから、相手しちゃダメ >>253
デザインパターンの意味も分からんSEが増えとるっつう事だね。
ところで Blazor desktop つうのが出たんだが、ますます混沌としてきた...
https://www.publickey1.jp/blog/21/net_6xamarinuiblazorapple_m1.html 派手に自作自演失敗してるな
>>253
それも自作自演 KENTAのサロンで基本を勉強したら？
なぜデザパタがダメなのか理解できるようになる。 >>253
今気づいた！あの頭悪い？？ね。(>_<)！ >>256
ここ数年でプログラミング初心者を食い物にする商売めっちゃ増えたよな KENTAは、あわしろ氏の一番弟子で実力は折り紙付き。 KENTA のサロンは、Ruby on Rails だろ
Rails は設定より規約。
クラス名・ファイル名の書き方が決まっていて、デザインパターンも自動的に決まる
Railsの規約に従うことを「レールに乗る」と言う
Railsは10年以上、デザインパターンの議論をしてるから、
どう書くべきか、すべて決まっている KENTAはRubyだけじゃない。
何でもできる雑食系エンジニア。
業界の人脈も広い。
サロンに入れば、あわしろ氏と個人的に会食できるかも？ >>204
返信なし。
大したもの作ってないのね。 >>265
それは素晴らしい。CenterNetを超える検出器を
作って公開してくれまいか ボタンの外観を画像で差し替えようと思ってるんだけどResourcesフォルダって作成場所指定できないのね
xamlファイルから見て親ディレクトリにResourcesが作成されるから別の方法を考えないと WinFormsのSplitterみたいに、マウスで位置変更可能な可能なWinUI3版スプリッターを教えてください。
SplitViewがそれっぽいけど、マウスで変更出来ません。 >>270
Windows Community Toolkit 8.0.0 Preview 4 で正常に動きました！ありがとうございます！ WinUI3なにこれ、ビルドすると実行にこんなにファイルがわらわら必要なの？
流行るとは思えないなぁ。 WinUI3ってどんな感じで始めるの？
NuGetから何か落とすの？ WinFormsは結局使い続けられてるけど
WPFって（UWPではない）次のGUI開発ライブラリが出た途端に
誰も使わなくなるんかな？
おまいらどうよ？ UWPはサンドボックス環境での実行とかあるから必要として、新規ではWPFの代わりがWinUIになるんじゃね
C++向けにもMFCの代わりにWinUI
ってもWinUIはまだタッチ寄りのUIだけど つか、そもそも多少の違いはあるが同じxamlだし、一方で学んだことの9割ぐらいはもう一方でも通用するだろ??
だから、どれにしようとか悩む必要ないだろ
要件にあうもの選べばいいだけ >>277
XAMLとMVVMの区別ついてる？
こんど主流はMVUになるよ。きっと。 俺は>>180だけど
区別ついてるからWPF/UWP/WinUIはどれも基本xaml+mvvmで
作るから一方で学んだこと他方でも使えるから悩む必要はないって言ってるに
>>278の君は何を言ってるの? >>279
.NET6の新型xamarinと新型Blazorで採用されるMAUIというSwingみたいなGUIツールキットが登場するって話だと思うが
xamarinが何時になったら安定するんだろうかって問題が
WinUI3は秋には完成しそうだけど、MAUIはその頃最初のバージョンが出る予定だがどうなることやら XAML＝MVVMと思もいこんだ人が
多いこと多いこと... >>280
mauiは品質の問題もあるけど、flutterの独自描画と違い基本OSごとのネイティブコントロールのラッパーという、要は最大公約数みたいな機能しか標準で用意されてないしょぼいUIになりそうってので期待してないかな >>275
ありが㌧
そうだった、まだPreviewか
しかも秋に完成かもって？
じゃ、今のプロジェクトはWPFのままで行くか… WinUI使いたければそのうちxaml islandsでWinUIのコントロールをWPFで使えるようになる つか、WinUI2なら今でもWPFからxaml islandsで使えるんだっけか? アクリルがfluent designで一番かっこいいところなのにねw
ストアアプリの5chの専ブラのsankaとか、アクリルでキラキラしまくっておしゃれだわ >>274
WPFもWinformもサポートされる限り使われて続けるよ
サポートされなくなったら使われなくなる
例えばVB6はサポートされなくなったから、もう誰も使ってないだろ MVUというよりこのままだと
flutterに完全に負けるね。 >>293
flutterまあまあよくできてるよ
dartにする必要性は全然ないけどね >>291
企業目線じゃなくユーザー目線の返答すべきだろ
サポートされなくなったら「使ってない」という話じゃなくて「使えない」だろ
UWPは絶賛サポートされてるがほぼ誰も使ってない WinUI 3-Project Reunion 0.5 Preview
https://microsoft.github.io/microsoft-ui-xaml/
結局今月はプレビューなのね
あと、アプリ内アクリルはサポートされた模様 >We expect to ship Project Reunion 0.5 in late March, which will include the first stable, supported version of WinUI 3.
つうことで、今月（late March）に最初のバージョン出る予定は変わらんようだ WinUI 3 Preview 5 で、起動時のWindowの位置/サイズ設定は可能になりました？
Preview4の時は出来なくて、API使って強引にやったけど。 えなにいまはMVUてのがあるの
MVPとか次から次へとでるるなぁ・・・ エバはふさわしくないって各社アドボって言い出してるよな
福音伝道師から何に変わったのだろう？ 今どうか知らないけど
マイクロソフトの社員で名刺にテクニカルエヴァンジェリスト(エバンジェリストだったかも)って書いてあるのに時々出会った 今頃になってMicrosoftの名前のついてMVVMクラスが登場したけどどうすりゃいいんだろうね
https://docs.microsoft.com/ja-jp/windows/communitytoolkit/mvvm/introduction
単純なINotifyPropertyChangedやICommandの実装だけじゃなくてDIやViewModelLocaterやEventAggrigatorのような機能もある
Prismのサブセットみたいなものだが、なぜコレを出してきたのかそこらへんがよくわからない MSジャパンにエンジニアはほぼいない
営業会社だから まぁ外資ITの日本法人の人をエンジニアだと思って見てる人はほとんどいないでしょ Activityが起動してないとServiceが動作しないとか
設定ファイルの書き出し中にプロセスが死ぬと設定ファイルが消える
「アレ」ですか >>310
アプリ、インフラそれぞれ十数名程度かな >>309
そんなものよりカラーピッカーとかformにしかないやつを使えるようにしてくれや chart早く追加してほしいわ
そんなに需要ないのか？ >>309
俺も力いっぱい言わせてくれ
なんで今更出すんだよ！
遅いわ！ >>316
カラーピッカーはwinuiにとっくにあるだろ MAUIはmvvm でもいいよみたいなこと書いてあったしプレビュー来たからそこで使えってこと？ こいつの売りはNET Standard 2.0で動いているから、ありとあらゆる.netで同じバイナリが使えることのようだ
複雑化したprismよりメンテナンス性いいかもしれんね .net standardっていう名称はもう廃止なんですかね？
.netという単語だと検索かけるときに色々混同して出てきてちょっと困る いや、.NET Standardはこれからもずっと.NET Standard。もう新しいバージョンは出ないってこと。 net4は古いバージョンから新しいバージョンをアセンブリとしてロードできたから
バージョンは結構適当でよかったけど
NET5以降は1年単位で出る新バージョンが古い方からは読めなくなるから困ったことになるんじゃないかなー 新バージョンが出たら古いのはすぐにサポート切れるから問題ないよ .NET5でWinformバリバリ作れるかと思ったらデータソースまだ無いのか
じゃあバインディング使って楽してDBアプリ作ろうと思ったらやっぱWPFじゃなきゃダメなのか
WPFってあんま楽じゃないのに… WinFormではダメってどんだけ物凄いアプリ作ってんだろ。
規模にして1000万ステップ位? 誰もWinFormsをダメとは言ってないし、物凄くないアプリならFormsの方が良いというわけでもない 今担当してるのは10万ステップ位だな。
作り出したころはここまで大きくなるとは思ってなかったけど。
一人だから構造に関しちゃやりたい放題できるけど、
xamlとVMを初期からきっちり分けといて良かったと心底思う。
winformでやってたらどうなってただろうと思うことはある neeviewの作者??
インハウスの社内向けのちょっとしたツールなら10万行なんてそうそういかねぇしパッケージソフトレベルやろ
で消去法でいくとc#で頑張って作者がメンテナンスしてるソフトはhohoemaかneeviewぐらいしか知らないから
残ったのはneeview あわしろ氏は、内製ツールのソースが2000万行超えたと言ってたな。 某SaaSの社内向けツールは9割コピペなんじゃないかってくらいまあ酷いもんだったね
C#を使っている組織としては国内トップクラスの一角には入ると思うが、それでも社内のコードなんてそんなもんだ 一般の目に触れることはないだろう内製ツール。
コピペでソースを増大させないようには気を配ってる。後の自分に降りかかってくるから・・
センサやスマフォと通信しデータはDBに貯めるWebサーバっぽいことをやってる。
グラフライブラリとかツールライブラリ買う予算なんてないからほぼ100%内製。
ベジェ曲線APIなんて初めて使ったよ。LiveChartとかも試したかったな
最近WPFがレガシー化しつつあるのと、大量のデータを描画させると
やっぱり遅いってのが気になってる。
始めた当初よりWebブラウザでいろいろできるようになってるし
Webアプリに移行しようかと本気で悩んでる。 .net Coreは速いって聞くけど、Core版WPFはパフォーマンス変わらないの？ WPFが遅いのはWPFのアーキテクチャのせいだから変わらん いや、変わる処理と変わらない処理があるってのが正しいやろ WPFってビルド時にバイナリ変換とかされないの？
実行時にＸＭＬそのまま処理してるの？ この流れで訊いとこうか
ASP.NETってC#やVBAで（Pythonで言うところのDjangoみたいに）Web制作できるって代物なの？
>>340みたいのが行く方向ってそっち？
そんでWPFは使えるの？
ついでに、AzureってAWSやGCPみたいなもんでしょ？
あれはC#、特にWPFが使えるとなんか得することあるの？ ASP.NET (Core)は.NETでウェブアプリケーションを作るためのフレームワークという意味でDjangoみたいなモノはあってるけどVBAは.NETではないので関係ない
WPFとASP.NETはJavaFXとSpring bootの関係と同じで全く関係ないWPFのBFFに使うとかそういう話ならともかく
Azureは.NETをほんのちょっと使いやすいというだけ同様にWPFは関係ない >>340
デフォルトの蓄積型で描画する場合にFormsより相対的に遅いというのはわかるが、WebがWPFより速いとは限らんが。
というかかえって遅いんじゃね？ 描画のパフォーマンスは圧倒的にWebが上だね
MSとGoogleとAppleが寄ってたかって馬鹿みたいに金かけて最適化してる 意外とjavascriptは速い。Chromeのみを対象にするなら良い勝負かも？ 律速するのはJSよりもDOMだろう。
WPFで表示が遅いと感じるくらいの数のエレメントを表示した場合の速度がどうなのか。 >>352
常識的に考えて、要素の数はWebの方が比較にならないくらい多い
平均的なWebサイトをWPFで作ったらガックガクだろうな >>347
おお、ありが㌧
あら、じゃあ、WPF知ってるからってASP.NETやAzureの勉強の足しにはなりそうにないね
じゃ、今まで通り、DjangoとAWSで行くわ DataGridで実際に入力したらクソなのが実感できるな
WinFormに戻ろうかな 業務用途だと標準のコントロールじゃなくグレープシティとかの商用コントロールを使うんじゃないのか。 DataGridでセル選択状態の時のIMEを制御するにはどうすればいいですか？
編集時のEditBoxは制御出来ましたが編集前から切り替わっていないと役に立ちません >>361-362
てめーら、何もしてねーだろが、この寄生虫が WinUI3がやっとリリースされたようだが、WindowクラスにDataContextが無いという謎仕様なんだな
すぐ内側ｊにGrid置けばなんとかなるけど、ViewModelLocatorが面倒なことになりそう reunionしたのはいいけど、この先またWinUIとMAUIで分断するのか？ WindowsでのMAUI実装がwinuiだと思ってたが違うのか？ >>371
昨日からVer.0.5だけどリリースバージョン。
VSにPreview5入れていたけど、何もせずに勝手にリリース版になっていた
日本語のwebは未だだが、英語の方はドキュメントも対応している
https://docs.microsoft.com/en-us/windows/apps/winui/winui3/
previewで作ったソースはcsprj弄らないといけないらしい まだデザイナないじゃん
フォーム確認するのにビルドして実行とかやっとれん WPFのXAMLでのStringFormatの書き方がよく分からないんだけど、
C#コード上のString.Format("{0, 2}", value)やString.Format("{0, 00}", value)みたいな右詰めや0埋めってどうやって書けばいいの？ stringじゃなく数値をバインドして、表示上はゼロパディングとかしたいってことだよね？
多分コンバーターは用意されてないから、自作のコンバーターを作って変換して表示させるとか？ >>379
ごめん、そういうこと
public int valueをバインドしてString.Format("{0, 00}", value);をXAMLで書きたいけど無理っぽいか Binding="{Binding Path=hoge, StringFormat=#\,0}"
でできないんだっけ？ >>378
同じように書けるみたいよ
3桁の０埋め
<TextBlock Text="{Binding Value, StringFormat=商品A {0:D3} 円}"/>
https://qiita.com/koara-local/items/815eb5146b3ddc48a8c3 >>357
WinFormで請求書の作成で使ってる。
まぁ普通に動いてて満足。
WPFだとどうなんだ。 winui3はc#のちょっとした社内ツールや個人アプリでは流行る目は皆無やな。
インストーラー用意するくらいのアプリなら可能性皆無ではないかもなっていう感じ。
まあでも感覚的にWPF以上に全く使われない感がある。 >>384
そうなのか
なに、（また）仰々しいの？
C#のユーザーのターゲット層が掴めてないんだろうな
とにかく、あのXAMLの深い階層だけは辞めてほしいわ UWP作ってないからしらないけど
WPFに比べてUWPに有用なUIはどんなのがあるのん？ >>386
なんで今更UWPとかでやるん？
MSもなかった事にしたいぐらい散々たる状況なのに... WINUI3もUWPが敬遠された部分引き継いでるからなぁ。
ばっとコンパイルして、パット起動が出来ない。
開発者モードのみでの起動か、署名かというところからスタート。
まずこの時点で自己ツール目的で利用されることは殆どないだろうなぁ。
自己ツールで使わない書き方は裾野が広がらない。UWPと同じ運命が待ってるとしか思えないなぁ。 >>388
WINUIの話してたからUWPとくっついたらどんなもんなのかなと >>391
Microsoftご謹製のUWPコントロールのデモ
アンインストすると綺麗サッパリ消えるから試してみると良いよ >>393-394
おぬし、それのWPF版を持っておらんかな？ WinUIって、Windowの位置とサイズはどうやって指定すればいいの？
探したけどよくわからない。 WPFスレにそこそこレスがあるってことは、まだまだワンチャンあるってことだよね。
WPFの話題あんまりないけど。 >>397
いや、WPFよりもっと使いやすいの出せや！と集まってるだけだが Web用フレームワークにも .NET MVC, Razor, WebForms,
Blazor(Server/Wasm), MAUI の少なくとも5つがある。
さらに、.NET Core MVC などという亜種もある。
Webではないフレームワークには、
WinForms, WPF, UWP, WinUI, WinRT
がある。結局、初期に出来たWinFormsが一番使われているらしいが。 WPFくらいまでならまだしも、それ以降のものをやってみたら
思わぬ問題が見つかるかもしれないし、やらない人が多いのかもな。
何かを改良した場合、何らかのトレードオフが生じて別の問題が
入り込むことが多いし、誰も使ってないからMS以外による評価も出てない。
問題が生じた時、古いフレームワークならかろうじてなんとかなるような
対策がなされていることが多いが、新しいフレームワークならそういう
バッドノウハウもないかもしれないし、怖い。 WPFでも実際に試して見るとWinFormsより使い勝手が悪いことがある。
Formデザイナーが使えないとか。
だからWPFが全面的にWinFormsよりすぐれていることにはならないし
置き換えることもできない。
それと同様の事が新しいフレームワークでもあるかもしれないが
試す時間がもったいないので誰も試さない。 そもそも問題としてWinFormsで問題を感じてない人が多い。
仮に感じていたとしてもWPFでそれは解決したりする。
それでも満足できずに新しいフレームワークに進もうとする人がどれだけいるか。
否、全くいない。
改良点もはっきりしないし、むしろ悪くなった点もあるとうわさがあったりもする。 UWPとかセキュリティきつくて社内ツールには使えなかったな。 >>404
WPFなのにWinFormのデザイナー使おうとしてんの？？ MSなら画面はHTML,CSSでコードがC#で書けるものを用意すれば良いだけなのにと思うわ
C#のコードはトランスパイル出来るようにすればjavascriptになるとかだとウェブアプリにも出来るし
exe変換などもサポートすればWindowsアプリにも出来るみたいな
Blazorはベースがダメ過ぎるｗ >>407
さっき調べたら、WPFにもXMLデザイナみたいなのがあるんだね。
でも昔やってみたら使い方が分からなくて使えなかったような気がする。
忘れたけど。 WPFで使うMVVMという概念が、もしかしたら Webプログラム的で、
WinFormsやMFCとは全く違うから、伝統的なGUIプログラミングに
慣れた人が困惑するのだろうか。
よう知らんけど。 >>409
WPFでWinFormに劣る個所とか
ほぼほぼ無い。 WPFでもWinforns的に組むのは全然OK。
xamlよくわからなかったら、xaml排除して
普通にイベントパンドラベースで組んでいいわけで。
そもそもC#の.netwindowsターゲットで、デスクトップアプリでデザインをUIデザイナーが、
機能をプログラマが組んで分けてることなんてかなりレアケースでしょ。
分けても見通しが良くなるケースの方が少ないってことよ。
パブリックなアプリならUnityみたいなものの方がデザインも2Dと3D混ぜやすいし、デザイナーもやりやすいだろう。 WinFormだと画面デザインはUIデザイナーでないと弄れなかったのが、
コードエディターでも直接編集可能になったのがWPF最大の進歩だよ。
まあ、猛者はxxx.Designer.csファイル直接編集してたけどね。 デザイナーのプロパティシートの出来は悪いよな
分類変だし
border引くだけでもタグ手書きしないといけない
リストなんかはダブルクリックイベント拾うだけでも大騒ぎだよ >>417
boderは最初面食らうね。
css流に使い方変えるだけで手書きは不要だ。
>>ダブルクリックイベント拾うだけでも大騒ぎだよ
それあなただけでは？ ネットに転がっているサンプルソースもWinformが多いし、やはり情報量の多さだとWPFは分が悪いな しかもWinFormsで困らないと思う。
WinFormsで困ったというのを聞いたことがないし。
はっきりとしたWinFormsの問題点をWPFを解決しているようではない。 >>421
高DPI対応が面倒くさいとかバインディングが貧相位は聞いて事あるだろう
UI変更の差分を追うのも苦手だな 業務アプリみたいなのは貧相なバインディングで十分なんだろ
ウィンドウ表示時、データ表示して変更して、画面閉じる時に更新してで、イベントハンドラにごそっと書くから、TwoWayなくても十分で.. >>422
解像度というのは大画面に対応するためにあるものと思っているので、
解像度が高いのに物理的なディスプレイの大きさは普通、などという
環境を使ってるのはそもそも本人が悪い。なぜならコンピュータにおいて
グラフィックは最も遅い原因の一つでドットが増えれば遅くなることが
られているから。
ゲーム目的でもビジネス目的でもそんな環境は良くない。
また、バインディングやMVVMを考えた人は地頭が馬鹿なのかな、と思う。 >>425
バインディングやMVVMの利点を理解せずなぜか考案者を頭悪い認定してるおまえが一番馬鹿だよ
単体テストしたこともデザインパターン学んだこともなさそう >>426
お前は自分で気づいてないが実は賢くない。 >>425
逆に聞きたいんだけど、MVVMやバインディングの何がダメなの？
普段どうやって画面に値を反映させてるの？
答えられずになんとなくでMVVM否定してるなら頭悪いよ？ >>428
MVVMが馬鹿なのは、ことを複雑にしてるだけでまともな意味がないからだよ。 >>429
普段どうやってイベントを実行したり、画面に値を反映させたりしてるの？ ****が馬鹿なのは、ことを複雑にしてるだけでまともな意味がないからだよ。
何を入れてもそれっぽくなる >>432
UIとロジックをよりシンプルに分離するための仕組みのひとつがMVVM
だから逆にどうやってるのかなと思って聞いてみた
それを無関係と言うのなら利点も意味も分からず自分が理解できないものを複雑無意味と言ってただけなんだなと
考案者を馬鹿呼ばわりする前に自分の頭の悪さを顧みたら？ ListBoxItemにいろいろ入れたいからWinFormsには戻れない
自分で描画したくない >>408
いいねぇ、その方法をもっと推せよ
HTML, CSSなら他にも潰しが効くしな
XAMLみたいな箸にも棒にも引っ掛からん奴を勉強しても何の得にもならん 10年前ならともかく今時MVVM考えた奴は馬鹿とかねえ
WinFormで満足してるならわざわざこっちに来なくていいから >>425
だからあれは、Blendデザイナーを機能させるの為の最低限の実装なのだよ。 >>433
あなたが他のUIフレームワークを、
知らないだけに見える。
一回Vue.jsでもやってみ？(*´ω｀*)
まあWPFでももうすぐWVU使えるようになるから、
そん時どう思うかが楽しみだ。 ⅣIWIⅥ
IⅥVVⅣI
MWM
ΜVVΜ
IVIVVIVI
本物はどれでしょう？ >>438
>>440
MVUの間違い！(*>ω<*)！ >>438
＞あなたが他のUIフレームワークを、
＞知らないだけに見える。
なんでそう思うの？自分がvue.jsの話をしたいだけのために意味不明な言いがかりつけるのやめたら？
仕組みの一つがMVVMって言ってますよね？
そもそもアーキテクチャの話をしているのであってフレームワークの話をしてるわけじゃないよね？
wpfのmvvmの実装が中途半端なのは同意するしMVUも楽しみにしてるよ >>442
はよ！
スレ見てみ♪
言いがかりは貴殿の方だと思いますよーー( ；´Д｀)
あと文書から推測すると理解が...欠けて...かも 各方面からdisられるWPFだけど、WinForm派は実感がこもってるように見えるけど
HTMLとかMVUとか推す意見はなんか表層的なんだよな。 既存のものの悪いところを改善して新しいものが出てくるから、たいていの場合新しい方が優れてると思ってる >>443
3行目以外何が言いたいのか分からないんだが、キマっちゃってる人なの？ >>447
Unityって一時仕事でやってたけど
すげーー技術満載だよな >>449
どんな技術？
あと、単なる興味だけど、どんな仕事？
ゲーム？それとも物理エンジンかなんか作ってたの？ もう一つ
UnityってWPF使うの？
Unityはインストールしたし、セミナーにも参加したが、本格的にやる時間と気力が無い
今さらゲーム業界になんて行けないしな
子供の頃はゲームプログラマーになりたくてプログラミング始めたんだがな
OpenGLでダンジョン歩き回るみたいなの作って終わり >>450
マイクロソフトのARだよ。
ホロレンズね。ゲームじゃなくて業務アプリ。
一年位やってた。 >>451
ARで使う機能もあれば、それ以外の機能は
WPFとasp.net + js + knockout.js(MVVM)だよ。 >>452-453
ああ、イメージ湧くわ
ARは3Dが得意なUnityの独壇場だね
WPFも使うなら、俺もUnityを使う方向性を考えようかな
線形代数もまぁまぁ覚えてるし、
行列はx, y, z, α（透明度だったよね）の4x4まででいいんだよね、きっと >>455
確かに混同してた（笑）
4つ目はベクトルだった
原点から動かすときに使うんだった まあ、4次行列や極点回避はかなりカスタムなカメラ作る際には必要。
でも高度なゲームじゃない限り、ただのアプリで登場するシーンはまずないかな。
ただの普通のアプリ用のUIだと、空間に配置していたとしても、
3次のベクトルの加算、サイド判定のための内積と外積ぐらいしか使わないかと。 >>454
>行列はx, y, z, α（透明度だったよね）の4x4まででいいんだよね、きっと
ベクトルとしては、[x, y, z, w]と書かれて、通常は常に w = 1.0 のまま使うこと
になる。
行列としては、ある1列(またはある1行)に平行移動成分が入っており、
その他の 3 x 3 行列の部分が「回転行列」。
ただし、回転行列と言っても、回転行列 x Scaling行列 x 変形行列
を入れることも可能。
これらの行列やベクトルは「済次」「同次」表現などともいわれる。
意味は、最後に平行移動用の足し算を行わずに、全て掛け算で書けるという意味。
X, Y を何かの量(ベクトル)、A を演算子とするとき、
Y = A X + C : 非済次表現
Y = A X : 済次表現 >>460
αを透明度とするのは、alpha blending 関連の色の話。
ARGB, BGRA, RGBA, ARGB 表現などといわれ、4 x 4 行列の話とは別。 行列なんかは回転や移動等々くらいまでは、文理に関わらず全員やっとるハズだから
空間エミッターを処理するのは問題ないハズ。 >>461
誤: ARGB, BGRA, RGBA, ARGB 表現などといわれ、4 x 4 行列の話とは別。
正: ARGB, RGBA, ABGR, BGRA 表現などといわれ、4 x 4 行列の話とは別。 DataGridのColumnHeaderのBottom位置に1dサイズの横線みたいなの無い？
DataGridColumnHeadersPresenter配下の何かっぽいけど、そのあらゆるUIElementに対してBorderThicknessやらPaddingやらMarginやらを0にしても消えない・・・ >>465
3Dグラフィックに置いての4次元ベクトルの外積は、第四成分を無視した
最初の3成分を3次元ベクトルとみなして、外積を計算するだけ。
100次元でも外積は定義されているが、質問者には関係ないと思われるので
ここでは書かない。 >>466
つまり、3Dグラフィックに置いての4次元ベクトルは、[x,y,z,w]と
書かれて、非常に特殊なケースを除いては必ず w = 1 なので、
[x, y, z, 1]
になっている。だから、
[x1, y1, z1, 1]と[x2, y2, z2, 1]の外積は、
[y1*z2, z1*x2, x1*y2, 1]
で良い。 >>468
本当の意味の4次元ベクトルの外積は、リーマン幾何学や一般相対性理論
で出てくるが、そんな質問なのかね？ >>469
関係ないと思うが、そんなに知りたいなら一応書いておけば「外積代数」を
学べば出てくる。直和記号を使って定義する。テンソル代数とも関係がある。
電磁気学(やベクトル解析)のガウスの定理やストークスの定理などを
統一して理解するのに役立つ。
一般相対性理論でも便利なので出てくるが、4次元以上の外積は、
物理的な空間ベクトルとは直接の対応関係はない。 >>470
いろいろな書き方があるが、テンソル代数は、直和記号、
外積代数は、ウェッジ積、
を使う流儀があるが。 すまん、直和ではなく、直積。
○の中に掛け算の記号を書くやつ。 >>471
それ、テンプレコピペだから相手にするな >>467
すまん、間違ってた。正誤表 :
誤: [y1*z2, z1*x2, x1*y2, 1]
正: [y1*z2 - z1*y2, z1*x2 - x1*z2, x1*y2 - y1*x2, 1]
覚え方は、
v3 = v1 x v2
の場合、
x3 = y1 * z2 - z1*y2
なのだけど、本質的には、
x? = y? * z? - 逆
の形式になっていて、? の部分は、ベクトルの順序通りに 3,1,2 を入れる。
逆の部分は、y と z の順序を逆にする。
y3, z3 については、上の規則を「サイクリック」に1つ変更する。
レビチビタ偽テンソル ε_{ijk} を使うと
x_{3i}=Σ_{jk} ε_{ijk} x_{1j}x{2k}
の関係がある。
忙しいのでまだ書き間違いがあるかもしれない。 デュフフフフ拙者が説明して差し上げましょう的なね
知識を披露したいだけなんだろうけど実害ないしやらせてあげよう >>396
遅いかも知れんが、どうもそこら辺は今の所用意されていないからWindowsAPI使って取得するようだ
https://docs.microsoft.com/ja-jp/windows/apps/winui/winui3/desktop-build-basic-winui3-app
ここにWindowHandleのとり方があるので、それを使ってuser32のGetWindowPlacementで取得
PInvoke.User32ってのをnugetすれば簡単だ TextBoxのIsReadOnly＝True
の状態でフォーカスを当てたあと
IsReadOnly＝Falseにして入力可能にしたとき、なぜかIMEが無効になって日本語入力できないバグがある
最近出た不具合ですか？ Windows10 2004 以降のIMEはバグだらけで使い物にならないから
設定から「以前のバージョンのIMEを使う」としておかないとあかん WPFは使われてないんだからWPFのほうが救いがあるだろ 新しいIMEも糞すぎて使ってもらえないから枯れるまで相当時間がかかるだろうね。
いきなりキー設定変わって、Updateすると設定を初期化されるのは
最近のMSは低スキルPGばかりだから仕方ないかと設定しようとしたら設定すらできないんだもの。
毎回リプレースすると機能が劣化するのはWPFから相変わらずだな。 MSにマウンティングは草
そんなブラック企業辞めて高給ホワイトなMSに就職したらどうか バカでも使えるようにしたらwpfで使えなくなった
つまりwpfは馬鹿じゃないの？ winform→WPF、IE→Edge、IME→新IME、アップデートすると機能劣化していく。
MSのPGは楽でいいな。 >>491
それはAI softのOEM版から何一つ進化していない
と同義語やね OS周辺は金にならんねん…
SaaSやサーバー売っとったほうがええねん… >>491
というか、日本製のIME(FEP)が優れていた。
Vzエディタとかも。 未だにWZエディタを使っている俺は勝ち組中の勝ち組 数十KGのFEPでできる処理なんだから
これからは不安定なOSを使うより
アプリに組み込んだほうがいいんじゃなかろうか 最近のMS好きだけどな。
ドキュメント関係は超絶劣化してるけど。 ドキュメントの手抜きこそが一番最悪。終わりの始まり。 手とり足とりサポートしてやってもロクなもの作れないSI系の連中に媚びるより、
Azureで基盤だけ押さえつつ自分でサービス作ってエンドユーザーに直接売ったほうが儲かることにMSが気付いてしまったからな ドキュメント関係も超絶劣化してるのは日本語のクソ品質な機械翻訳なやつだけでしょ
あれは確かに見るに耐えないけどさ
英語版ページを（原文／ブラウザ翻訳を対比しながら）見なきゃいけないのはまあ面倒だけど、慣れかなという気もする 原文も十分に説明不足だけどな
.NETとかはまだマシだが ドキュメントビューアがそもそも糞すぎて。MSDNライブラリの頃は便利だったのに。
新しいのに置き換えるたびに機能劣化するのはほんと止めてほしい。 原文もひでーよ
.NET Core になって更に酷くなった >>504
MSDN Library 2001 の オフラインの Html Help は便利だったが、
VS 2005 の Help の Document Explorer からはオフラインヘルプも
使いにくくなった。 >>504
.NETFramework は内容はともかくそこそこ見易いしpdfでも落とせるから他のドキュメントもこれにして欲しい
https://i.imgur.com/m1E3CEy.jpg ドキュメントは必要な情報はあまり記載されずにどーでもいいことが長々と書かれてる サンプルも意味分からんの多いしな
唯一まともだと思えたのはアップデートを繰り返した非同期処理のサンプル
あれはかなり分かりやすい ドキュメント劣化なんかしてないでしょ。
日本の文章が適当になってるのは日本人のソフトでの貢献やフィードバックが年々下がってるから仕方ないのでは。 ほんと最近のMSのPGは酷い。サンプルのソースのレベルが低い。
まるでOracleのサンプルレベルのが増えてきた。 ORACLEのドキュメントとか読ませる気あんのかっていうレベル 一番クソなのはMSDNの質問コーナーだろ
何か質問すると、第一声が「専用のアプリでログ記録して送って下さい」だからな
いやいや、そのままの状態で答えられるだろ
それで応答が無いと「解決しましたか？」・・・するかヴォケ
マイクロソフトにはクソしかいねぇ ✕マイクロソフトは無能
○日本マイクロソフトは無能 MSのドキュメントはしらんけどオラクルのは普通に読みやすいと思うが・・・ 一見読みやすいけどところどころで原文と逆の意味になってたな enum定数なんかうっせえよ毛唐、英語が世界の共通語とかナチュラルに思ってんじゃねえよって言いたくなる MSのドキュメントはしらんけどオラクルのは普通に読みやすいと思うが 昔のJDKのドキュメントは良かったな
今のは知らんけど >>522
Java有償化(OpenJDKは有るけど)、Oracleライセンス料金アップと来てる
MySQL商用ライセンスのみになったらユーザー皆発狂するだろうね このスレにJava使ってる馬鹿なんていないと思うぞ >>524
MySQLが商用ライセンスのみになっても、MariaDBがあるのでは？ そこはSQL Serverと言うところでしょ！！！ MSのスレで最近オカルトJava信者が暴れてるよな。 >>527
マイ苦労ソフトの犬が！
最初から課金する腹のDBは使わねぇ！
>>528
本格的にJavaがオラ狂うに課金され始めて行き場を失ってるんだろ
ここは俺達ががっちりとガードしないとな
>>521-524
二度とこの敷居を跨ぐんじゃねぇ！( ﾟдﾟ)､ﾍﾟｯ このスレで説明するまでもない。
なぜなら無償のC#があるから 同じ事しても単価安いからな
オフコンのコボラーと一緒で
同じコボラーでも汎用機なら需要があるが
JavaもAndroidなら需要あるのも同じだね 散々訴えられたからgoogleはとっくにkotlinを推奨してる。 >>529
> 最初から課金する腹のDBは使わねぇ！
小規模ならExpress Editionでいけるぞ 今はLocalDBもある
これって開発限定なんだっけ? >>536
Express用にいまさらLinux鯖用意するのもなぁ 全然関係ないが、これから俺が進むべき道が見えたぜ、ありがとう～！！ >>421
WinFormsの保守でめちゃくちゃ困ってる。
OS×DPI×解像度の50パターン弱の組み合わせでレイアウトが崩れないか確認するんだけど
崩れるんだよ（怒）
その回避のためすっげー泥臭い処理入れてる。
今時ウィンドウサイズ固定で使い勝手も悪いし。
WPFで作っておけば何も特別な対応いらなかったのに。
あとWinFormsが糞なのはUI変更のdiffが取りづらいこと。
使ってるカスタムコントロールのせいなのか知らんが、プロパティ1つ変更するだけでDesignerファイルが
ぐっちゃぐちゃに書き換えられた。
結果、差分見るのは諦めてチェックインのコメントを信じることにした。 winformだって特別な対応いらないだろう。
◯◯なDPI、解像度はサポートできませんでいい。単におまえのコミュ力不足。
デサイナが変更するファイルを覗く時点でかなり変な奴なのは分かる。
客がどうしてもと言うならWPFに移行しましょうと見積もり出せばいい。
まぁそうやって新しく作り直せばwinformの劣化品ができるんだけどなw 高DPI環境における Windows Forms アプリ終了のお知らせ
ttps://hilapon.hatenadiary.org/entry/20160621/1466501984
>◯◯なDPI、解像度はサポートできませんでいい
IEでしか動きません、みたいなのはゴミソフト。
普及している環境はサポートして当たり前。
>デサイナが変更するファイルを覗く時点でかなり変な奴なのは分かる。
チーム開発したことない人？
他人がコミットしたコードを確認しないの？
>まぁそうやって新しく作り直せばwinformの劣化品ができるんだけどなw
winformより劣化品はないのでそれはないでしょうね。 >>544
コミュ力って何想定してんの？
社畜だったら顧客から開発部門まで何段階の伝言ゲームがあるか知ってるだろ？ >>543
Designer.csみたいなものを実用化したのは素直にすごいと思うが、
すごいことはすごいんだけど結局csのコードにする意味って無かったよな。 >>543
少しずつWPFに移行すればいいんじゃね？
俺もwinformアプリの保守やってるが、修正や仕様変更の機会にコントロール単位やダイアログ単位でWPFに書き換えてるよ ヒエラルキーの下の方なんだろ
あんまり突っ込んでやるな ああそうか、受託生産か
すまんな、商品開発なんでちょっと感覚違ったわ >>550
社内でしか使わないシステムならともかく、不特定多数に販売するソフトで誰と話すんだ？ 本当に不特定多数ならWebだわな
どうせ不特定多数(数社)なんだろうけど、それくらいならプロパーのエンジニアだったらエンドユーザーと話す機会は普通にあるだろうね >>557
企業向けじゃなくてコンシューマー向け。
それに保守って書いてある通り既にユーザーは今のサポート環境で長年使ってるわけ。
論点がずれてるぞ。
労力を使わずに潜在顧客が増やせるならその方がいいに決まっている。
サポート範囲は可能な限り増やすべき。
ただポンコツUIフレームワーク(winform)なんか使ってるせいでそれが多大な負担になってしまっている。 ポンコツはMS開発者も認めるWPFじゃないだろうか。 複雑なこととは違うかもしれんが、複雑な画面はFormsよりはるかに開発が楽だなぁ。 ぽんこつじゃ無いUIフレームワークってなんだろう
特にゼロ年代から使えた奴で、今も保守可能なものって GridのChkBoxみたいに見た目はいいけどツカエネーのが多い MaterialDesignUIを見てたらモチベは上がるな webアプリに馬鹿にされないレベルに
やっと到達しただけ。 MS開発者が使いたがらない時点で終わってる。いや一般の開発者にもほとんど普及しなかったが。
このスレの一部の住人だけマンセーしてて笑える。Javaの盛り返しはWPFのおかげかもしれない。 >>567
バグがまだ多いのはしゃーないけど、遅いのが気に食わんな
AOTのUWPに比べて体感で倍ぐらい遅い WINUI3ってちゃんと2、3個のファイルに収まる？
form出すだけでコンパイルすると20個ファイルありますとかじゃ絶対嫌なんだが... .NET Core系は基本的にDLL祭りだから安心しろ
それが嫌ならもう.NET辞めたほうがいい 外形的に見えない関連ファイルの多さは問題視する場所じゃねーな
単にケチつけたいだけだろ
５００MBのHDDって時代じゃあるまいに MSは失敗続きでもはや何も期待してないのであら捜しする気もない。
なんでこーなった。始まりはWPFからじゃないのか。 >MS開発者が使いたがらない時点で終わってる。いや一般の開発者にもほとんど普及しなかったが。
MSは大所帯だからWPF、UWP、Formsどれでも使いたがらない奴は存在するだろうが、
そうじゃなくて何か数字が出ている話か？ >>577
MSのキラーアプリと呼べるのは、VS、Explore、IE(Edge)、Officeかな。
これ以上の説明がいるならキミにWPF宣教師の称号を与えよう。 >>581
そういうことじゃない。
ただシングルバイナリにしても馬鹿みたいに巨大なファイルになるから
Core系はサーバーサイド以外では使いづらい。
ちょっとしたツールを作って配るなら当分Frameworkの方を選択した方がいい。 1～2MBで済んでたものが数百MBになるのは馬鹿らしい。配布方法に制限が出る。 訳分からんな。
昔は320KBのフロッピー一枚で結構楽しいゲームが出来たのに。 ファイルサイズならUWPが最強なんだがね
ライブラリから使っている部分だけ取り出して再パッケージだからな
.net nativeが将来WinUI3の後継で実現されたらいいのにな >>587
個人的には、庶民目線に立てなくなったら起業は衰退すると思うし、存在意義
も薄れると思うけどね。 それこそフロッピーが現役の会社も探せばまだあるだろうし、
メールもチャットも大抵5MBとか10MBとか制限かかってるところは多いだろうし、
クラウドストレージもファイルサイズが大きいと同期にやたら時間がかかって使いにくいこともあるし。 >>583
そんなにいかない。130-140MB程度。 容量が100倍になるには30年くらい掛かるし、読み込みやバックアップの時間も
かかるので、出来ることが今までと大差ないのに容量だけが100倍になったこと
を騒ぐのは時代遅れだとか貧乏人だとか言うのはおかしいと思う。 >>592
昔から日本には次のようなことわざがある：
「一円に笑うものは一円に泣く」
「塵も積もれば山となる」 >>595
俺は、フロッピーは昔の話を出しただけ。
でも、フリーWifiなどは遅い場合が有ると聞くし、ネットアプリなんかは
1MBでも起動が遅いと感じることはあるはず。 すまんマジでフロッピーでの配布とか出てくるところの話だとは思わなかったわｗ
そりゃ最新の開発環境は使えんよねうんうん スーパーフェチを有効活用するには単一よりバラバラのほうがいいのだろうか？
別フォルダでも同一ファイル扱いしてくれる？ >>597
数テラバイトのSSDを積んだ環境でもコンパイル結果が 100MB にもなると
バックアップに苦労する。時間的にも容量的にも。 .net5はHDDでは使えないと
はっきり言ってくれればいいのにね 今WPFを.netCoreで作るメリットってC#9.0が使えるくらい？ SCDで塩漬けにできること、それに尽きる
MSがWPFを.NET Coreに移植した目的はまさにそれで、既存WPFアプリケーションをSCDにしてしまえば今後Windowsに.NETがバンドルされなくなっても気にせず放置できる
今更新規にWPFを使うなんてまず無いしね Web系を除くとLOBアプリは消去法でWPFぐらいしか残らんだろ。 >>600
VSは、SSDで使わないと遅くて使い物にならないね。
ただし、SSD環境ですらかなり遅いが。 >今更新規にWPFを使うなんてまず無いしね
これはWindowsのデスクトップアプリの開発にWPF以外を使うという意味なんだろうか。
それともWindowsデスクトップ自体やらないということなんだろうか。 むしろ、現実のデスクトップアプリの新規開発は、MFCかWinFormsだな。 それはない。
MFC使ってた奴なんてもう寿命で死んでるだろ。
WinFormsも今更使う理由がない。技術力低くて自身がないのかもしれんがとりあえずWPFで作っとけ。
それなら後から優秀な人がきれいに作り直すのもやりやすいから。
ElementHostでやりくりするのは辛すぎる。 うちの周りでWinForms使う新規プロジェクトなんて見ないなぁ。 すげー伸びてる。
そろそろWPFも普及期に入ったな!!! WPFがくそだから使ってる人少ないとかどうこういう前に、Windowsアプリの需要がほとんどないってだけだろ
ios/android並みに新規開発の需要がwindowsアプリにあったならwpfにしろuwpにしろ使われたと思う UWPを出したタイミングあたりでUWPではなくMAUIとかのクロスプラットフォームのAPIが出てたらまだ結果違ったと思う
WPFがなかなか普及せずに時間経過して次のGUIツールキットに期待だけは高まってた
なのにUWPは囲い込みを意識したストア経由の配信方針と
パッケージに署名必須で勝手アプリ禁止、
Windowsのブランド付きのクロスプラットフォームがないことを予見させるネーミング
今はもうMAUI発表してもまだなんかやってる程度しか注目集められなくなってる
MSはWindowsのブランドマーケティングに足引っ張られすぎ ﾌﾟﾌﾟﾌﾟ、WPFスレが人気で嫉妬してますね^^ >>613
UWPはWindowsPhoneとデスクトップの共通化を夢見たからできたんだぞ
あの頃はWindowsデスクトップのマーケティングなんか考えてなかった 今はunoってのがあるけどな
UWPアプリを自動でxamarinとBlazorに変換してスマホとブラウザ対応 >>613
UWPは普通に開発者モードにすれば勝手アプリ配布できるんじゃ?
androidも設定で変えればいけるし、勝手アプリ配布の手軽さは同等じゃないかな >>617
UWPとAndroidの比較なら確かにそのとおりだ、すまん
ただUWPで証明書を趣味の個人開発者が購入するのはつらいし、
他者がオレオレ証明書をインストールするのも問題すぎる
どうすればいいかは分からんです
GUIまわりでMicrosoftが開発した技術一覧をざっとまとめてみた
これにプラットフォーム(Windows, WindowsPhone, XBoxなど)、アーキテクチャ(x86, arm)、
サポートしてるプログラミング言語、技術の名前変更やバージョン別に依存関係があったりする
まとめてくうちに笑えてきた
高レベルGUIツールキット
MFC, WTL, WindowsForms, WPF/XAML, Silverlight, WinJS, Xamarin,
UWP, WinUI, Blazor, ReactNative for Windows, Project Reunion, Project MAUI, Uno(MSサポートが入るっぽい？)
低レベル(レンダラー含む)
WinG(Win3.X用), Win32 API(GDI/GDI+), DirextX(Direct2D, Direct3D, DirectDraw, DirectWrite含む),
XNA, OpenGL, OpenGL ES(ANGLE)
デザイン
Luna, Aero, Metro(Modern UIに変更), FluentDesign WinUIはProject Reunionの一部じゃねぇの？ OpenGLとか入ってるし気持ちよく箇条書きの水増ししたいんだから細かいこと突っ込んじゃダメ >>618
アカウント取得してストアで公開すれば証明書は無料なのを知ってるよね？
最初に個人１９ドル、法人９９ドル払わないといけないけど、費用はこれが全てだ WinRTもある。
OpenGLやOpenGL ESは、MSが考えたものではない。 他に .NETは、Standard, Framework, Core, 5/6 などがあり複雑。
互換性があるようで無い。MS独自の仕様にC++/CLI などもある。
DirectXは、DirectDrawが古くなり、Direct2DやDirectWriteが追加されたが、
DirectDrawの方が便利なことが有ったりする。他にとても大事な仕様として
DirectShowがある。これは動画カメラを入力する時に使う。しかし、
それも著作権保護のために変化して今は別のものが推奨になった。
他に音関連でDirectSound, MIDIやMusic的なものが有る。
ジョイスティック関連でDirectInputも。
ドライバ関連は次から次へと新しい仕様が作られ、古いものは非推奨とされた。
恐らくこれはReactOSやWINEなどを完成させないためだと思われる
(後から追加されたものは、関数の量が多すぎてほぼ真似できない。)。
MFCも昔はWin32のWrapperが主体だったが、後にMFC独自実装が増えた。
なお、Blazorは、ServerとWasmの二系統が有るので1つとは言いがたい。 https://www.nda.co.jp/memo/codesigning/index.html
無料ってのはちょっと違ったかも知れんが、破格なのは間違いない
ここのリストじゃ１年間で最低９９ドルだからな
Storeは年数制限もないしアプリの数の制限もない >>626
あーあー、620とか何を指して水増しと言ってたのか分からんかったが、
仕様がMicrosoft以外なのに他の技術と同列に列挙してたことを指してたのか
OpenGLの仕様は別組織なんだからメンテしてる実装のことだと勝手に理解してくれると無意識に考えてた
確かに開発した技術という一覧で並べたらおかしいな
「OpenGL(opengl32.dllの実装)」と書いとけばよかった 他に ASP.NET や Azureもある。
ややこしいこととして、ASP.NET MVC と MVC が付かないものが有ったと思う。
AzureとASP.NETの関係性も複雑に感じる。
また、Blazorは、、ASP.NETやMSクラウド(Azure)を使わせる
ために作られたものだという説がある。 こう書いとけば良かった、じゃなく完全に場違いのものを列挙してるって理解しなさいｗ 「ASP.NET Core」なるものもある。
色々なフレーム枠たちの全体把握がとても難しい。 ASP.NET MVC
ASP.NET WebForms
ASP.NET Core
Razor
Blazor Server/Wasm ---> 2種類ある。
はどれも異なる。
AzureとASP.NETの関連性も難しい。 WTLのほかにATLもあり、
OLE, OLE Automation,
COM, COM+, DCOM, AcitveX
UMDF
などもあったが、難しすぎて全体を理解できている人は少ない。 >>630
おかしかったと言葉の綾を認めてるのにしつこいな
そんなにネチネチくるなら言わせてもらうが、
>>615
> あの頃はWindowsデスクトップのマーケティングなんか考えてなかった
とか、Microsoftが最重要要素のマーケティング考えてないと想像するのも十分おかしい >>637
> 確かに開発した技術という一覧で並べたらおかしいな
> 「OpenGL(opengl32.dllの実装)」と書いとけばよかった
認めてないだろ
しつこいとか書いて自分は悪くないような印象操作するなクズ >>632
すまん
一覧のタイトルを訂正させてくれ
?GUIまわりでMicrosoftが開発した技術一覧
○GUIまわりでMicrosoftが開発または実装した技術一覧 >>639
他所の仕様を動かすためのMS実装なんて含めたら
ただでさえ意図の不明なリストの趣旨がさらに胡乱なものになるぞｗ
修正するならタイトルを変えるんじゃなくて指摘されたものを消すだけでいいんだよｗ >>641
了解
OpenGL と OpenGL ESは取り消す Prismはオワコンだな。
Regionのデザイン時表示に制限があることがわかって
こんな欠陥ライブラリ使い物にならんなぁと思ってたところに
MS印の軽量なの見つけたんでこれにするわ。 MVVM Toolkit
こういうの標準ライブラリに入れないからイマイチ浸透しないんだよな。 >>646
prismはprismで便利なんだけど、MVVMコーディングの肩代わりさせたいだけなら重すぎるな >>618 いろいろなものを作って混乱させ、あとはどうやって収集させるのだろうか？無理だろうが C++の場合、MFCとWin32はよく使われているが(特にMFCが)、ATL, WTLなどは余り使われてないと聞いている。
同様に C#においては WinFormsとWPF以外はほぼ使われてないらしい。
UWP, WinUI, WinRT などもほとんど使われてないが。
理由は初期のものとの差が分かりにくいから。
MAUIは、マルチプラットフォームなのでちょっと違ってくるかも知れないが、やっぱり使われないかもな。 WinUIはまだスタートラインに着いたところでしょ、普及する気がしないけど
MAUIはXamarinの後継だから主流にはならないっすね ATLとWTLを新規開発に使うなんてことある？
昔のコードであって、機能は全部MFCに入ってると思ってたけど。
無料環境でやるんだったら仕方ないけど、もう更新されてないでしょ？
あとC#のフレームワークの話してるけど、プラットフォームが違うでしょ
WinUIは上の通りだが。
言語云々よりもアプリの数見れば選択に上がらないのは想像つくかと。
>>651はWindowsでソフト作ったことあるの？ ATLとWTLとMFCが何か知らないのは構わないが
調べもしないで妄想を垂れ流すのは止めてくれ。 MSは現場の技術力が低下している
VS2019で新規プロジェクト制作でプロジェクト種類一覧を出すだけでクルクルして待たされる
江戸時代かよ… >>652
XamarinはWinForms風やXAML風が使えたようだけど、MAUIはMVC風に
するらしいから本当は後継とは言えず、受け継ぐのはマルチプラットフォーム性
だけかも知れない。
つまり、MAUIはXamarinとはプログラミング作法的には全く違ってくるかも知れない。
しかも、MVC風はWeb系の人には馴染みがあるがデスクトップアプリ系の人には
抵抗がある書き方。 勘違いしてたわ。Xamarin自体がXAMLを使っているがMVVMだったそうだな。
MAUIでは、アプリケーションモデルとして MVVM, RxUI, MVU, Blazor の
4種類も用意されるそうだが、となると、MAUIでggっても自分が使ってる
アプリケーションモデルと異なる説明が出てきたり、不具合を直すための
バッドノウハウ系の情報も出てこないだろうな。
あと、MVVMやBlazorはWinFormsの代わりにはならないだろうな。 また勘違いしてたわ。WPFはXAMLを使っているがMVVMが推奨され
てるんだってな。
そうか、だから普及しないんだな。
MVVMは伝統的なデスクトップアプリの作法とは違うからな。
HTMLとJSを組み合わせるWeb系プログラムに似た作法だから。 MVC/MVVM 系の代表格は、Ruby On Rails, Vue.js, Angular で、Web系に多い作法。
WPFもそれを推奨とすると聞いた。
ASP.NET には、WebFormsとMVC の二系統ありに系統有り、前者は
デスクトップアプリプログラマ向け、後者がWebプログラマ向けだと聞いた。
前者は名前からも分かるようにWinFomsに似た作法らしい。
・WinFormsは、C++のWin32やMFCと似た伝統的なデスクトップGUIアプリの作法に似る。
ASP.NET WebFormsがこちら。
・WPFは、WebプログラムのHTMLとJSを組み合わせた作法に似るのでWebプログラマ向け。
ASP.NET MVCがこちら。
ということらしい。 >>656
技術力が高かったことはない
元々低かったのがさらに低くなった >>656
俺ははっきり言ってローエンドのCPUを使っているが、
もしも、コア数の多い最新版の Core i7 や i9 などを最新の M/Bと
共に使ったら、速いのかね？
それが分からんし、どれくらいのCPUにすれば速くなるのかも分からんし、
貧乏だし、ローエンドCPUを使ってる。 そんな事言ったら、androidの新UIフレームワークjetpack composeの重さに発狂するわ
まだベータだが 新規プロジェクトのテンプレ一覧なんて表示にそんなに時間のかかる者なのか？
かかるとしてキャッシュするぐらいの知能がないのか？ WPFは遅くないとか言ってる馬鹿が開発してるのだろう。 「Microsoft Build of OpenJDK」が一般公開 WPFは、RIA(Rich Internet Application)と関連深かったらしく、
Silverlight は、WPF/E と呼ばれていたらしい。
この意味で WPFが、MVVMを推奨したり、Web系の HTML+JSでプログラミング
する作法に似るのは当然かも知れない。
また、XAMLは、画面をデザインするデザイナーとプログラミングをする
プログラマーが共同作業を行うときに有利だとされていたらしい。 リッチなWPFだけど、内部でWebの様なレンダリングをしてるのだろうか XAMLを解するデザイナーなんて存在しない。
XAMLはプログラマーが手打ちで作るもの。 XAMLでなんでもやろうとするよりレイアウトだけやって他はコメントいっぱい書かかせておくのが一番
でもコメントも書きずらいからやっぱり糞 ずっといるというか、糖質は適切に治療しないとずっと寛解しないからな 16.10.0のプロパティ簡単設定機能はXAML直書きの苦行から少しは解放されるん？ むしろXAML直書きを支援する機能を充実させてほしい UWPとWIｎUI3のx:Bindはインテリセンスが効く
別件だがVSのオプションで
>テキストエディタ＞C#＞IntelliSenseで「インポートされていない名前空間の項目を表示する」を設定すると
using していないクラスもインテリセンスの候補で出てくるようになっています コードビハインドでUI記述したらWPF使う意味がない。
XAMLは画面プレビュー見なくてもそれだけで画面の構造・イメージが把握できるのがメリット。 >>692
XAML直書きってそういう意味の事か。
勘違いした。 xamlってstyleやtrigger使うとかなり階層が深くなりがちなんですけどよい解消法はありますか？
あとは深いところでちょっとだけ違うものを短く書けないかなと
似たような山が3つとか並ぶと不快です そういうのはできない
XAMLの致命的とも言える大弱点 それはXAMLの問題ではない。
お前の問題。
普通にコードビハインドで書けばいい。 だよねぇ。
ペアレントを数段階遡ってサーチしDatacontext設定やってんじゃねぇ、、、 と言いたい。
ビハインド一発。 Styleはコードビハインド無理だろ
ResouceDictionaryで分離するくらいしか手がない Resourceに切り出せば階層の深さも限定的だと思うけどね。
特定のコントロールにベタ書きしているんであればそのコントロール自体をUserControlに切り出すとか。 お前らもgridの設計書はexcelで作ってるの？ そういう後日全く役に立たない成果物という代物は整理できないものなんだろうか
この仕事が生まれてからの永遠の課題だが 人足仕事で案件取ってくる営業からしたら一粒で二度おいしいだろ >>700
そんな資料が必要な時点で作りが悪い可能性。
普通は上手に部品化してGridとStackPanelを使っていけば
見りゃわかるレベルで構造が綺麗になるもんだけどな。 >>698
コントロール自作するレベルは
最初からmvvmとかつかってない。
まず遅すぎて使えない。
XAMLの美味しいとこTemplateやStyle使っても
コードビハインドから十分かける。 >>705
誰にいってんのかな？
ちなみに複合コントロール(データグリッドとかガントチャート)とかの内部実装はそんなもんです。
それに、WPFのコントロールの開発者のほとんどは、
WinFormsのコントロールの開発者でもありますよ。 >誰にいってんのかな？
一人しかいないでしょう。
ちなみにプロジェクトの規則でWinForms禁止や、
発注側が（質の低い技術者を振るい落すために）WinForms禁止を指定してくることもあるよ。 見た目こだわらないならWinFormsでいいんじゃないの？ 見た目のカスタマイズに限った話だけど、
コードビハインドだと標準の挙動で上書きされて思い通りに動かないことがある
じゃあXAMLスタイルを部分的に入れ替えて作ろう、てやってると
段々>>694の状態になっていく
コードビハインドだけで解決できる世界じゃ無いんだよ >>708
見た目こだわらなくても開発生産性や品質上げたいならWPF使うでしょ。 なるほど
世間では生産性や品質はMSが考えるほど重視されなかったのか
参考になる >>714
技術者です。MSのサポートを何度も利用してますがいつもインシデントを消費できません!!!
wwwww >MSが考えるほど重視されない
むしろ「MSに期待してない」
本気で考えたらMSの製品なんて採用しない 横からだけど
生産性を高めるには標準コンポーネントをさらっと使えたほうが楽だからwinformの勝ちだと思うけど 仕様によるわな
レイアウトは崩れてもいい、という仕様ならwinformの方が工数は少ない 普通に作るとWPFでも崩れるよ
デスクトップでまともに表示されてもタブレットに移すとボタンが画面を占拠したりする 画面の解像度が同じでもdpiなどが違う場合を考慮しないと簡単に操作不能になる >>719
そういう話ではなく、どちらが生産性が高いかという話だよ
当たり前だけど、そんなの仕様による
ウィンドウが小さくなったときにどう表示するかも、その仕様のひとつでしょ
スクロールバーをつけるのか、全体を縮小表示にするのか、コントロール自体を少なくするのか
または、小さいウィンドウはサポート対象外とするか 勘違いしてるようだけどwindowは小さくなってない
実際の画面が小さくてdpiは高くなってるけど文字とかが大きくなってるからボタンが占拠してるんだろう
やっぱりwinformsのほうが生産性が高い そんなの当たり前、WPF使ってもレイアウト崩れるようにつくれるし
アダプティブにレイアウトが崩れないようにつくりやすいのはWPFで、こっちの方が生産性が高い WinFormsはMFCと似ているが、WPFは作法が違いすぎる感じがする。
WPFはHtml+JSベースのアプリに似ている。 ただ、WinFormsもイベントハンドラの書き方がVBと似ている。
基本的にグローバル関数の様な関数でイベントを受けるところとか。
MFCは、イベントを受けるクラス毎に好きに選べる。 >>725
誤: MFCは、イベントを受けるクラス毎に好きに選べる。
正: MFCは、イベントを受けるクラスを好きに選べる。 >>717
いや、使い捨てのプログラムですらWPFのが楽だわ。
>>719
WPFの普通の作り方は
コントロールに幅や高さ、位置を指定しないでレイアウトコンテナーに流し込む
というものだけど、ちゃんとやってる？
普通の作り方していれば画面崩れなんてまず起きないよ。 MVVM必須にするならWinFormの方が初心者には優しいし、MVVM使わないならどっちでも大して難易度変わらないだろ。 WinFormでもMVVMで作ることは可能。自分はやらないけど。 >>727
いやいやそういうのだけでうまく行くなんて思うなよｗ
縦にボタンをスタックしてdpi高いデバイスに移ったら
ボタンがデカくなって下の方のボタンがはみ出るｗ >>730
まさかとは思うが、ウィンドウサイズ固定なんて初心者丸出しの作りしてないよな？ もう馬鹿は黙ってた方がいいんじゃないか？
恥の上塗りだけど？ 同じ解像度でも
PCだと全画面表示で縦にボタンが10個表示できたとしてタブレットだと縦に6個ぐらいしか表示されないと言うことがありうる
例えウィンドウサイズが変更できたとして何ができるんだ？ ウイドウサイズ固定ガー レイアウトガー DPIガー
WPFスレってずっとしょうもない話ばかりしてるよな。フレームワークが糞すぎて
PGとデザイナーの分離とか言う理想以前のレベルにまで落ちてしまった。
まあ、日本語でLinux使うとボタンが画面の外に出て押せないとかしょっちゅうだけどなw >>733
スケーリング倍率の違いを考慮せずにPCの画面いっぱいにデザインして
FlowLayoutにするとかViewBoxやScrollViewerを使うとか何も対策しなきゃそうなるだろうな
OSのスケーリング倍率設定を無視して表示したければマニフェストを編集すれば簡単に出来るよ >>733
最終兵器のViewBoxというものが有るよ ViewBoxつかうのは下の下だろｗ
本当に使ったことがあるのか？ >>733
>PCだと全画面表示で縦にボタンが10個表示できたとして
えーと、ウィンドウサイズを小さくしたらボタンが隠れて使えなくなるような酷い作りって事？
VGAぐらいまで縮めても使えるように作るでしょ普通。 >>730
StackLayoutをScrollViewerでラップするだろうに
大丈夫か君?? ＞ WPFの普通の作り方は
＞ コントロールに幅や高さ、位置を指定しないでレイアウトコンテナーに流し込む
＞ というものだけど、ちゃんとやってる？
＞ 普通の作り方していれば画面崩れなんてまず起きないよ。
からの～
↓
＞ えーと、ウィンドウサイズを小さくしたらボタンが隠れて使えなくなるような酷い作りって事？
＞ VGAぐらいまで縮めても使えるように作るでしょ普通。 お前らの言う普通てなんだよとｗ
そんなもん考慮しないで作っても使えるようになれば楽なんだ 普通に今時アプリ作るなら、
StackLayoutをScrollViewerでラップするけど
特に設定画面とかほとんどそうするが 鼻くそほじりながら普通に作るアプリの要素をいちいちScrollViewerでラップしてるのか？
関心だねｗ >>744
本当の意味での本来のレイアウトと違う結果になるから
それとかなり強めの副作用が出る そもそも極端にスケーリング倍率が異なるモニターに映して
どのような動作になるのがお好みなのかさっぱり分からんぞ 今度は鼻くそほじりながら作るとかアプリの種類もピンキリだがアプリの種類を極端なほうに持ってこうとしてて草 例えば地図の経路を編集できるアプリがあってデスクトップでは片側に縦に操作ボタンが並んでたとする
タブレットではタッチで操作できるからタブレットにそのまま移してみた
ボタンが画面の半分を占めてしまったりしたらどう思う？
しかも下の方のボタンを表示するにはサイズ変更やスクロールしないといけない
同じ割合で表示されていたらと思うが他の人は違うのかな？
だったら知らんけど ん?話ずれてねぇか??
特定のレイアウトが使いづらいとかただのUIの話してるの??
アダプティブなレイアウトをWPFとWinFormsで作るならどっちが生産性が高いかの話だろ?? 趣味でしか使ってないけどWPFは欠陥品でいいと思う
無駄にややこしいし WPFとかWinFormsとかもはや関係なくてDPIスケーリングとUIデザインの話になってるな
>>749
>>735に書いたけど、スケーリングしないようにすれば? >>750
えっ
いつから話をそらし始めたのかな？
つかさ初めからそんな話はしてない
>>740みたいなのか君も？ >>740
うん。
その通りに作ってればウィンドウサイズを広げても縮めてもちゃんと使えるようになってるはずだよ。
>>741
Gridで領域を区切ってその中にそれぞれScrollViewerとStackPanelをはめ込む。
これが基本。 病気なのか
そこに書いてある通りで上のようになるんだがｗ ターゲットモニタを顧客と仕様で決められない無能SEの話でしかない。
WEBアプリ開発とかでIT音痴の顧客に、すべてのOS、ブラウザ、バージョンで動くようにしろと言われて
無理ですと答えられないアホSEだったのだろう。その手のデスマーチは何度も見てきた。 >>752
だよな
完全に話の中身というか論点変わってるよな Aさん Gridの領域を区切って～ と作ればちゃんと使える
Bさん アダプティブなレイアウトが作りやすいだけでちゃんと使えるように作る必要がある
Cさん すべてのOS～で作れるようにはならん 仕様が決められていない！
で？と言いたくなる 俺はそもそもがこれだけ言ってただけなのに仕様とか言い出すんだから困るな
同じところを勝手にお前らが堂々巡りしてる
AさんBさんCさんの意見は似てるようで似ていない
719 名前：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr8d-6ypv)[sage] 投稿日：2021/06/01(火) 00:30:07.02 ID:LVmbfPywr [1/3]
普通に作るとWPFでも崩れるよ
デスクトップでまともに表示されてもタブレットに移すとボタンが画面を占拠したりする
720 名前：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr8d-6ypv)[sage] 投稿日：2021/06/01(火) 00:37:47.40 ID:LVmbfPywr [2/3]
画面の解像度が同じでもdpiなどが違う場合を考慮しないと簡単に操作不能になる ウィンドウサイズを縮小するとレイアウトが崩れるしょぽい作りのアプリが
DPIスケーリングで相対的にウィンドウサイズが縮小された場合にも
同じようにレイアウトが崩れるってだけの話だな >>749
それが気になるならViewBOｘでパネルごと自動で縮小すりゃいいじゃないか
つうか、もしかしてViewBoxを他のものと勘違いしていないか？ 無限のフィールドにどんとおいちゃうViewBox
非常に使いどころが難しい
今のやつ程度なら様子見ながら使ってもいいけど普通は使わない
あらかじめそうなるとかそうしないとどうにもならない場合でしか使わない
副作用が大きすぎるから他と絡めて使う場合普通は避けて通るのが吉だろう >無限のフィールドにどんとおいちゃうViewBox
どうみてもScrollViewerに対する表現だよな
WPFに関しては初心者同然でViewBoxが何かを知らない人が喚いているだけ ViewBoxは画像として伸縮させてるだけだから、
スケール合わないとすぐ滲むよ どんどん盛り上がてくれ
WPFのノウハウをどんどん吸収するからさ レイアウトが崩れるというどうでもいい話しかしてない >>767
他の事に注力したいのはやまやまだがクリアしとかなきゃならない課題だ。
winformだと本当に地獄だから。 >>767
案件によってはどうでも良くない
レイアウトが崩れて「実行」ボタンが押せないとかw >>756
程度による。
本来制限する必要のないことを技術選定ミスや設計ミス、技術力不足のせいで制限かけて客に押し付けるのは無能。 >>769
折衝能力不足。
仕様されるターゲットを限定できない馬鹿SEのアホプロジェクトだけだろ。 レイアウトガー、レイアウトガー、レイアウトガー
最初からWEBアプリ作ってろよ >>775
スマホでPC版ページのまま表示させたら辛いこと多いやろ >>772
技術力が低いと客を騙してどうにかするしかないわなｗ >>777
> 本来制限する必要のないことを技術選定ミスや設計ミス、技術力不足のせいで制限かけて客に押し付けるのは無能。
ドアホ無能SE。要件にターゲット明記せずにどうやってテストするんだ？
いつも未テスト納品でもしてんのか？ テスト仕様書ぐらい書けよ、ウスノロ。
仕事したことねー幼稚園児はマ板に行って勉強してきな。糞野郎。板違いだ。 >>775
後発って言ってもHTML5の10年前に登場した太古のアーキテクチャだぞ。 >>778
読解力ないな。どう読んだらターゲット明記しないなんて読み取れるんだ？
SE失格だぞ。 wpf面倒に感じてもwinformsには戻れないわ レイアウトだけにすれば全然面倒じゃない
とても快適 WPFならModelを本体にして、低解像度と高解像度を別々の画面を用意する荒業も大した手間もなく出来る
横の部品を縦長ならGridのRowとColumnを変更して下に表示もできる
WinFormsでは不可能な柔軟性を持っているのは事実だ どのみち対してwpfはさして流行らんまま次のものへと移行してくわけだから、
存在感としては、winform以上に割り食いそうだけどな。 その「次のもの」が10年近く迷走を続けている状態だなぁ。本当、Win8以降のストアアプリ路線が黒歴史。
WinUIが決定版となってくれればいいが。 そもそも、WPFは、WinFormsより人気無いよね。 https://blog.jetbrains.com/wp-content/uploads/2020/06/dotnet-2020-survey-frameworks.png
2020年:
Which technologies or frame works do you use ?
ASP.NET Core : 55%
Entity Frame Work : 43%
ASP.NET MVC : 42%
Win Forms : 31%
WPF : 26%
Azure : 22%
ASP.NET WebForms : 19%
Unity 3D : 18%
Xamarin : 13%
Windows Communication Foundation(WCF) : 12%
UWP : 6%
Share Point : 2% >>785
もともと、Windowsアプリ開発の決定打は MFC だったし、今でもそう。
Webプログラマが色々言ってるだけ。 >>788
デスクトップ向けのWPFやFormsとWeb向けのASP.NETとIaaS・PaaSのAzureとジャンルごちゃまぜで意味なさすぎるアンケートだな 将来的なサポートはFrameworkだと思うけどなぁ 今は.netじゃないネイティブアプリは何で作ってんの？ >>792
.NET Frameworkは.NET4.8で開発終了したけど何言ってるの VB6みたいな断絶されたシステムと違って互換性がある後継が存在するからな >>796
新技術の取り込みないからレガシー化待ったなしだぞ
c#8も全機能使えないし >>764
素人だらけだろこのスレは
ScrollViewerだけじゃないだろ
サイズ計算やレイアウト絡むものを入れてはいけない わかるぞ
他人を馬鹿扱いしないと主張を保てないみじめな人生
そして経験不足からくる傲慢さ >>799
あんたが>>749に書いた仕様など
>同じ割合で表示されていたらと思うが他の人は違うのかな？
と言うならViewBoxで解決じゃねーか
あんたがViewBoxを知らなかったのはバレバレなんだよ いや、実際息が長いのは.net frameworkの可能性が高い。
実際にはあれで作れないものって業務むけでは殆どないし。
.net5以降は古いメジャーバージョンから、新しいメジャーバージョン一切読めないから
結構困惑が始まると思うぞ。 >>795,796,798
新規開発で4.8を選択するのはプロジェクトの性質によっては妥当。
Core系を選択してしまうとたったの3年でサポート切れ、
OSのサポート期間だけ気にしておけばいい4.8の方が長期的に見てずっとコストを低く抑えられる。
開発側からすれば新しい方が便利な機能使えて楽だが、使う側からすればそんなの知ったこっちゃないからな。
レガシー化って言ってもVB6ランタイムですらまだWin10で生き続けてるからな。 >>749
マウス・キーボード操作前提のUI設計、タッチ操作前提のUI設計をするべき。
サイズが違うとかそういうレベルの話じゃなく、使い方が異なるものを
同じUIで済まそうとするのは手抜き。 なかなか説得力あるなｗ
でも技術者としては「これからも.NET Frameworkで新規開発するよ！」なんて言う組織にはいたくないなｗ まあ>>805みたいなのは短期的には至極正しいんだが、長期的には優秀なエンジニアが離れていって結果的に品質は低下していくんだよ まあそもそも今時Winのデスクトップアプリ作ってる時点でアレなんで、>>808のような理屈を持ち出すのはナンセンスな気もするな .NET CoreはWin10に勝手にインストールされるようにならんのかね
GUI付きのツール作って配布するときいちいちランタイムインストールしてくれって周知するのがめんどい
だったら.NET Frameworkで我慢して作っちゃうって人多いと思う >>810
どれだけWindows Updateの遅さで苦しんでいると思ってるのか。
もともと独占禁止法違反に拍車をかける。 >>810
ポータブルなデプロイできるでしょ
容量増えるのがイヤならしょうがないけど >>810
それがネックでまだ個人利用でしか使えないよな。
>>812
3MBぐらいまでコンパクトにならないと実用性無い。
何十個もファイル分割して送りたくない。 .net frameworkなら1ファイルなものが、20ファイルとかになったら、やはりプラスには受け止めないけどなぁ。
少なくともオレは。
ショボショボコンソールツールすらファイル20個とかだと、
同じディレクトリにショボツール5つまとめて置いておきたいんだがーとかもためらわれるよね。 しょぼしょぼコンソールツールなら.netで書く必要ないし
そうでないならインストーラつけるで良いのでは メリットよりデメリットの方が大きいなら無理して .NET 5 使う必要なくね
どうしても .NET 5 じゃないといけないならランタイムインストール方法をきっちり説明するなり
半自動インストールツール提供するなり
Dockerイメージでデプロイするのもありらしいね >>814
> 企業や組織が導入しているメールサーバーでは、1 通あたりのメール容量上限を 10 MB 程度に設定しているケースが多いです。
> ただし、古いシステムを使い続けているところでは、1～3 MB と容量がかなり少ないこともあります。
> メールのマナーとして「添付ファイルは 2 MB まで」と言われていますが、一般的には 3 MB 以内なら送っても問題ないと考えていいでしょう。
ファイル共有サービスやチャットも管理者が容量制限かけてることが多いから1回の送信は数MBと考えておいたほうがいい。 >>820
メールで配布？
いまどきWebなり共有ファイルサーバーもないとかありえんだろ アメリカ企業が作るものは何でも金持ちであることが前提になっている。
アメ車も燃費が悪いし、デカくて狭い日本では運転しにくいし。
Visual Studioやいちいちネットに繋ごうとするし、Windows Updateも然り。 iPhoneやアメリカ製タブレットはすぐ電池がなくなって数年で買い換えないといけない。
SONYタイマーは5年だったが、これらは二年以下。 >>821
メールは例の1つ目。
ファイルサーバーでも同じ。
ちゃんと読め。 >>824
今時ファイルサーバーでMB単位の制限とかアホかよw 社内アプリなら管理者がCoreだろうが何だろうが整えれば良い
管理部門通さずコソコソやりたいって話ならVBA万能説と大差ない MFCの学習コストの事を思ったらWPFは楽なもんだけどな 普及してないのって単に難しいってだけだよね
俺もWPFわけわからないし MVVM系のフレームワークはWebじゃ普通に使われてるんだから、MVVMが難しいは理由にならんよね
WPFがイケてなくて不必要に難しくなってるか、WPFやってる人の頭が悪いかのどっちかだろう vbとかwinformsオジサンなんだろ。
web系もやったことがないか、やったとしてもweb formsとか。
MVCすら分からないんじゃね？ XAMLを擁護してる奴だけは本当に意味が分からない
ブラッド・コックスとトム・ラブがObjective-Cを作ったのは失読症だったからって冗談があるが、だったらXAMLを作った奴は滅裂思考かなんかだろ
病院に行け それXAMLじゃなくてBlendの為のマークアップ拡張な
これがやたらめったら糞なだけ。
だから標準libraryからはずれてんの 最近のVSだと、ホットリロードで実行しながら細かいプロパティー弄れる様になって
開発も容易になったんだが、そういうの知らないんだろうな
ある意味フォームより直感的な修正が可能 覚えること多すぎだから挫折するんだよ
実質セットやんwpf+xaml+mvvm
androidとか他でmvvmとか覚えたら、ここに戻ってきたらいい >>834
完全に同意
単にちょっとした<List>の要素をループで表示したいだけなのに
なんであんなクソ深い階層を作らんといかんのか
そんなのWPF側で吸収しろよ
>>836
ホットリロードも使ってるし、元々使わなくても書けたが
あの階層を見る度に「WPFを作った奴はアホだな」と毎回思ってる mvvmでちゃんと作ってないてけとープログラマーだけどwpf好きだ WPFのとっつき悪さはXAMLとバインディングのおまじないの合わせ技やろうなあ >>838
そんなんHTMLと変わらん。階層が深くなって扱いづらいなら分割すりゃいいだけのこと。 ｃ＃のメソッドでも更にメソッド呼んで結構階層深くなるけどソレを簡単に把握できないと商売上がったりだよな
xamlは言っても一つの画面で収まる程度の深さだからさほど苦にもならん >>841
これだと思う、つーか俺が正にそれだわｗ
バインディングの呪文がいちいち分からなくなって調べて書いてた
UWPのx:Bindだとだいぶマシだったな XMLの柔軟性で表記に微妙な揺れがあるのが初心者殺し >>825
仕事できなそうだな。
言われた以上のことはおろか、言われたことすら満足にできなそう。
もっと想像力を働かせろ。 >>847
容量の話で反論できなくなったら人物攻撃かよ
老害はこれだからw >>848
そういうところだぞ。
ファイルサーバーでも制限かけずに全社員が好き勝手に使ったらあっというまにパンクする。
ちょっと考えればこんなこと中学生でも気付く。思考が浅い。
わずかなやりとりだけでパフォーマンスもメモリ効率も悪い、バグも多い駄目駄目コードを書くだろうことが容易に想像できる。 一人１Gなら１０００人居ても１T
時代が違うんだよな
何年前の世界の住人なんだろうかｗ >>849
バカはファイル単位の制限とドライブ単位の制限の区別もついてないのか…
いまどきExcelでもでかい表だと10MBオーバーとか普通にあるのにw まぁWPFはスマホもないような石器時代に作られたフレームワークだからな。
これでモダンなGUIアプリ作れとか木の枝で火を起こせと言ってるようなもの。 実際ほとんど非公開型のデスクトップアプリでしか使われてなく、公開されてるものの中での使用割合でもwinformに全く届いてないとおもわれる。 本当は古いかどうかは問題ではない。
WinFormsはC#の中で最も古いのに最も使われているし、
MFCは、それよりさらに古いのに WinFormsよりも使われているのだから。 >>850
うちはユーザーに解放されている領域は全員で5GB以内に制限かけられてるけど。
もっと制限きつくしてるところもあるだろうし、ファイルサーバー自体用意していないところだってあるだろう。
時代のせいにするのは「逃げ」だよ。 >>851
バカはお前さんだよ
ファイル単位の制限も、ドライブ単位の制限のも
考慮する必要がある
それに間違ったExcelの使い方自慢されてもな >>859
そう、全体での制限はもちろんある
うちの会社だと1G ~300G まで1G単位で設定されてる
ファイル単位の制限を付けるのは標準だとできないことが多いしあまり意味がないからやってる企業はそんなに無いだろうね
いまどきファイルサーバーを用意してないような企業はないとは言わんけど…
まあレアケースじゃね？
>>860
> それに間違ったExcelの使い方自慢されてもな
最大行数が65535行のExcel使ってる老害乙w そこで、楽天SIMで威張られてもなぁ
とか言って更なる地獄を作り出す未来が見えます。
せめてOpenXMLの話をしているのかと
思ったら😅 アンマーネージドのfree/delete地獄はイヤじゃ >>862
そういうことを言ってるんじゃない
データベースとかBIツールとかもっと適したものは他にあるだろってこと >>867
> データベースとかBIツールとかもっと適したものは他にあるだろってこと
そんなのケースバイケースだろ >>862
どっちかってーとファイルサーバー使ってる方が旧態依然とした企業じゃないか？
今はメタ情報を色々付与できるファイル共有サービスの方が主流。 >>869
で、そのファイル共有サービスとやらは数MBの制限があるのかい？
知ってる単語並べても恥ずかしいだけだぞw >>871
状況もわからんのに選定誤ってるとかアホかよw wpf datagrid で任意の列の値の一覧を取得したいんだけど,
for文とか使って地道に1行ずつループさせるしか方法ないん？(´・ω・｀) >>874
全然わかんない……(´；ω；｀)ﾌﾞﾜｯ 「地道に」というが、速度的に問題ないならそれで十分。 >>877
それはWPFのdatagridが速度面に問題あるからかも知れないから、どうしようもない
かも知れない。それがC#よりC++を好む人がいる理由でもあるのだから。 速度の問題が有るなら表示件数を制限するところから検討だな
１万件を表示しても誰もそのデータを目で追うはずがない >>881
そっか今度やることがあったら参考にしようと思っただけなんだ datagridずっと叩かれてるけどMSは直す気ないの？ 俺は酷使したこと無いが、UWPのDataGridがデータ多くても早いって話だからWinUI3使えばOKじゃね？ >>872
その通り、漸く理解したか
各々共有方法や制限は様々、だからサイズは小さいに越したことはない
一部の環境で問題ないからOKなんてのはアホの考え >>888
ファイルサーバーの容量制限の話とExcelの容量の話を混ぜて話を誤魔化そうと必死すぎ
そろそろ情報のアップデートしなよw >>884
WPFはもうメンテナンスモードなので新機能が入ることはない >Microsoftは今後UWPに投資しない
>UWPからProject Reunionへの移行に関して
>すべてのUWPアプリケーション開発者は今すぐ検討を開始するべき
>UWPとWinUI 3 in Desktopの両方で開発する、という方法を推奨
>アプリケーションに必要な機能がProject Reunionに揃ったならば、
>UWPバージョンは廃止して、WinUI 3 in Desktopバージョンのみを公開すればよい WinUIってまとめただけのものだぞ。
UWP、WPFの代わりではなくWinUI in UWPという類。 そうなんだけど、でも、普通に今WinUI 3プロジェクト作ると
WinUI in xxxというより
ただのWinUIって感じじゃね?? WinUI3はWin32APIが使えるUWPって方が近いかな？
WinRT APIのクラスはUWPと同等な制限が残っているし WinUIを使ったことある者に訊くが
WPFよりシンプル？複雑？ もうちょっと教えたくなるような態度で言ってくれないと… WPFの教訓を活かして、普及するまで手を出さない!!! あっと言う間にflutterの天下だもんなーー。
ちなにみオープンソースに舵きったMSも
React forWin同様こちらにも投資してますよ。 winuiもreactも、winformおじさんを収用できないとブレイクしない
wpfにもuwpにもそれができなかった
技術どうのこうのよりもwinformおじさんに理解できないと
業務アプリの主流になれない
ちなみに元をたどるとVBおじさん ブレイクしないといけない理由がないのでそのまま廃れるといい >>908
C#は、名前と表面を変えたVBに過ぎない。
名前にCを入れたことでC系だと錯覚させるが実はBASIC。 >>912
VBしか使えない爺なんだろ
スルーしとけ 5chは爺の巣窟ですよ。
子供は他所で遊んだ方が良いですよ。 >>908
WPFおっさんももう粗大ゴミです。コード書かない、テストしないくせにうんちくばかりで。 >>912
winformはDelphiの踏襲と言えますが言語はjava#ですよ、おじーちゃん。 いつもどうでもいいことで争ってるけどほんとお前ら頭悪いな 結局、若者はボクだけでみんな使えないじーさんばかり。ボクのようなスマホ世代、デジタルネイティブと
スマホのない時代に作られた骨董品WPFスレの住人では話が全然噛み合わなくて当然ですね^^ 適材適所でいいのにな。
C++ならMFC、C#でWindowsデスクトップならWPF、クロスプラットフォームが必要ならElectronとかAvaloniaとか。
そのうえでWinUIやMAUIが使い物になって自分の用途に合致するならそれ使えばいい。
WinFormとかそれしか使えない奴が執拗にWPFを叩いているだけ。 そうそう要するに適材適所だよ。WPFに適した場所がどこにもなかっただけ。 あれ？お前みたいな若者がWindowsデスクトップアプリ開発するの？ プログラマとデザイナーを分けてる開発現場などどこにもなかったのだ。 Blendでやりたかった事が、
Chrome DevToolsでほぼほぼ出来とるつうのが
悲しいよな。 実際小規模なところはみんなわけてないよね
フォーム作って出来合のボタンラベルテキストボックスを貼り付けて、そのまま納品するのは
formsでもwpfでも変わらない ていうかデザイナーとの分業という話がWPFと関係あるのかと。 >>911
だって名前変えただけでただのXamarinじゃん。 >>930
Xamarinがそんなに悪いものだったのか。 >>928
何を書いてたのか知らんが専任のデザイナーがいないこととWPF使うことには何の関係もない。 >>933
何を訳の分からんこと言ってんのか。
馬鹿ばっか。 「Xamarinするには、まず人脈♪」って5年も前の話
古いネタをいつまで引っ張るつもりだろ Xamarinが少なくともスマホ環境においてゴミだったのは否定し難い
iOSでファイルの安全な更新(別名で保存してからリネームする奴)を行っていなかったため、バックグラウンドに移行した時にファイル書き出しが中断されると設定が消滅するとか
AndroidでメインActivityのonCreateでXamarin主要機能の初期化をしてるからバックグラウンドサービスでXamarin機能に触るとクラッシュするとか
本当にこれを使ってアプリを作成している人達が居たのか疑わしいレベル Ruby は名前を変えた Perl である(キリっ 自分だけかもしれないけど
WPFは直感的にわからないことが多い
普通の利用局面でもパターン化されていない
listbox（）でアイテム右クリックしてコンテキストメニュー出してアイテム削除とかするでしょ？
これをXAML+MVVMで書きたい場合を自分はさらっと書けない
ググってもあまりよくわからない
結局自分で書いて試してうまくいけばそれを使う
次書くときはまた忘れてて同じことをする
どれかライブラリを使えば簡単に書けるのかもしれないけどそれもわからない
よくあるパターンを普通に書けないしノウハウもたまらない
それは頭が悪いからだとか言う前にもっと単純な仕組みをつくるべきじゃないかなと どうしてそんなに流行って欲しそうなのか分からないｗｗ
いいじゃん流行らないなら流行らないで廃れてしまえば
それでいて何か損することがあるのだろうか？ listboxにItemContextMenuと言うのでもあればなあ >>941
contextmenuをxamlで書こうとすると無茶苦茶ややこしくなるが、VMにC#のコードでメニューを作ればさほど難しくもない
状態で細かい制御をする時はむしろこっちしかありえない
あと右クリックをVMに伝えるにはWPFだとビヘイビアでOKで、コードはそこら中に転がっている
WinUI3だと、イベントをそのままVMにバインド出来ますね >>940
winformおじさんは新しいもの流行ったら困るもんな wpfおじさん。wpfは15年も普及活動したけど流行することもなくオワコンらしいよ。 他所で流行っているかどうかは関係ないな。
どっちにしろWindowsでデスクトップアプリ開発するならWpfはほぼ必然なわけだし。 >>942
wpfはコマンドパターンをアプリコードに書かせようとしたのが敗因の一つだね
uwp以降のイベントを直接バインドできる形式で良かった
ICommand実装してもEventArgs欲しかったらアクロバットやるはめになるし >>939
直感的じゃないってのはまさにそのとおりだと思う
わざと難しくしてるのかと思いたくなるくらいひどい
Win2dとかローカル画像すら簡単に表示できなかったわ WinformおじさんとかWPFおじさんとか言って馬鹿にしてるけど
結局はMSおじさんが一番無能なんだよね >>870
容量的にはもっといけるが気兼ねなく使えるのは数MBぐらいまでだな。
それ以上になると同期が遅すぎて使い物にならない。 >>951
なんでも環境やハードのせいにするそのしょぼい頭をなんとかしろよw GTKこそ何年間の技術だよｗ
今は + 付いてないから気をつけろよ >>952
たかが数MBのファイルの同期が遅すぎるとかそれ以外の原因あるのかよw >>901
この機能↓がどこまで充実してるかが気になるな
Compile-Time ViewModel Generation
This experimental feature will use C# Source Generators introduced in .NET 5
to generate boilerplate code for your ViewModels at compile time.
Command declarations, property change notifications, IDataErrorInfo implementation,
and service support will be automatically added to a partial class linked to your ViewModel.
このManual Partの部分を変えてもそれ相応についてきてくれるんかね？
例えば、CountだけじゃなくてSumも表示したいわぁって足しても出してくれんの？ >>902
見た目はほぼWPFそのまんまだな
> Window クラスに DataContext プロパティがありません。
> Window 内に置かれるコントロール類は DataContext プロパティを持っているので
> そこで設定すれば従来通り {Binding Xxxxx} のようにバインドできます。
ComboBoxやListBoxなんかがそれぞれDataContextを持ってるってこと？
今まではWindowのDataContext一つだったけど、
これからはそれら複数を同時に表示できるようになったってこと？
あと、ReactivePropertyが使えるからって使ってしまうと
どこまでが純粋な違いか分かりづらいな
うちの会社じゃ何故かReactiveProperty使えない Windows10は最後のWindowsって言ったじゃん！
騙された！
また騙された！！ ┌､ r┐ r┐ヾ> (_ ／ ミ
!. | ヾ> ｜| lﾆ ｺ 〈／｀ヽ _ ﾐ
|. ! ノ| | ﾚ! _| |. ,ｲ,.- ､ | ￣_￣丁 '' ｰ┬‐- -ﾐ
ヽ二／ .ヽ/（___ﾒ> /,|.l l ! （ ） ! (´ ) ! r‐
ry'〉 ,､ /ｲ,! `ｰ' _L =- --┴-ﾆ二ﾄ､_'ｰ'
lﾆ', r三) （（ |'J｣-''_二 =-- ‐一 ｰ‐t‐-ﾄ､ 二__
|_| ）） ﾚ'／´ｨ ､______＿＿＿ ヾﾐ| l
_r┐ __ （（ V ,、 F≡三r一ｔｧｰ, | l:.:. .::
└ｌ. ﾚ',.-､ヽ ）） |ノ＾>、 '＾ミ二´ | l:.:.:.::
ﾉ r' __,! | （（ V/ｲｿ .::ヽ､二_
└'!_| (_ｔ_メ.> ）） | / ,' _ .:.:.:.::i|,)ﾉ
r-､ （（ |.〈、 ､ _〉 ｀丶、 ;:ｨil| ノ
,､二.._ ）） | 笊ｙfﾐﾐミミヾ､ '!ｌ|il|li!fj'
ｰｧ ／. （（ ヽ |i''r ''_二二ﾆﾐ;ヽ､ ,|ｌ||il|l|,｢ﾟ|
ん､二ﾌ ）） |,l| V´ :::::::::;;／ ﾄi|l|i|i|ｌ|!Ll
,.-─-.、 （（ |i! ゞ=-‐''" ,i||i|ｌ|ｌ|l|!|i{
/ /l .i^ヽヽ ` |il! ｰｫii|｢、 ,,.,.ｨi||l|i|l|l|i|l|ｼ'
. | .ﾚ' / l.｜ ヽ二ﾆ,ヽ ,/i|l||livil|||l|i|l|l|lil|l|i|l|i|i|i|l|l|l|{'
. ヽ／ ﾉノ ＜ノ {l|!|l|i|l|i|l|i|||i|i|l|i|i|i|i|l|l|!|l|l!r'
r┐,.─-､ / 7 ヾ!||i|i||i|i|l||l||i|i|l|l|l|l||l|l!ｲ
|｜し'＾) ,! ┌‐' 'ｰ┐ﾄ､ ｀`,ﾍi|l|i|l|i|l|l|i|r''`''"´ i ,
|_| l´r' 7 /_7 / ｣__〉 （＿~｀^~"ﾞ'ヾ ﾉ ／ ,
[_] [_] 〈_/ヽ_/ .ト─' ﾉ ／ ／i サポート終了は良いんだけど
次のOSの情報さっさと出せよ デスクトップアプリにMVVMって必要なのかね？
なんか「とにかく何でもオブジェクト指向！」みたいな臭いを感じちゃう 純粋なデスクトップアプリ自体がすでに終わっていて、VSCodeみたいにWebブラウザを全面に貼り付けるだけというのが主流になっている
従来のデスクトップアプリはパイが小さくなりすぎてもはや主流とかベストプラクティスとかスタンダードとか呼べるようなものは存在しなくなっているから、
もう自分のやりたいように好きにしたらいいと思う >純粋なデスクトップアプリ自体がすでに終わっていて、VSCodeみたいにWebブラウザを全面に貼り付けるだけというのが主流になっている
その両者を自由に選択できるとして、あえて後者を選ぶのはクロスプラットフォームにしたいとか
既にWebベースのリソースがあるとかの場合だけじゃないかねぇ。
現状じゃまだ特に開発が楽になるわけでもないし。 >>965
webしかできない人が作る場合
って書こうとしたら、そもそも両者を自由に選べる場合という前提に反することに気づいた 実際のところ、「Webしかできない人」にElectronはハードルが高いと思う。 Webさえできれば、Electronは本当にただのガワとして使いつつ実際は普通のWebアプリという構成も取れるわけだしな 「Webしかできない人」にそんな応用力あるかなぁ。
Reactとか使いこなしているのにWebしかできない人ってあまり見たことない。 そもそもWebしかできないの意味が分からない
HTMLコーダーみたいなののこと？
そいつらはプログラマーに入ると思ってなかったよ ローカルアプリのためにアプリケーションサーバー用意するの面倒じゃん >>963
元々はデスクトップアプリのための設計手法で後からWebにも広まっていったんだし。
しかし画面が1つしかないような小さなアプリなら不要。 なんでデフォルトでVirtualizingされてないんだろうな
めんどくさいわ まあWebアプリの構成そのままでElectronアプリにしようとしたら中でexpress立ち上げるようなことになるし。
アプリ内のV-M間のインターフェースがRESTって、MVVM以上に面倒くさい。 は？SPAだからインターフェースがRESTなんだろうが。graphqlでもいいが。 Auto Mount Daemon が実社会侵略中 >>983
それが5chクオリティ
気持ち悪いと思うなら
もっと健全な所を探して移ったらいい >>985
5ch平均年齢高いからっていうのもあるが老人の僻みみたいなのが多くて見るに堪えないな MVVMというか具体的にはWPF+Prismなどだろうが
言うほど難しいものじゃないんだから、ここまで敵視することないのにな
サンプルもそこそこ有るんだから少しは勉強しろ、と ちなみに、WinFormsでMVVMってやろうと思ったら出来るの？
出来ないとしたら、何が足りないの？ MVVMって手段の一つだからな
Formsだろうが何だろうがViewとModelを分離できるならそれで良い >>990
実際できるか？
XAMLの部分はどうすんの？
本当に質問の意図を理解して書いてる？ そのXAMLがウルトラクソなんだよなあ
XAMLを除けば悪くないフレームワークだと思うよホント >>991
xaml必須じゃないぞ
フレームワーク丸ごと自分で作る気になればできるだろう >>992 >>994
あら、XAMLなしでも出来るんだな
ありがとありがと
確かに面倒そうだが、ちょっとやってみようかな
WPFはそのうち廃る、賭けてもいい
だが、MVVMかその派生は残り続ける
WPFが死に絶えるまでWinFormsで凌ぐのもいいかもしれない
>>993
これでXAMLとオサラバだ（笑） 「XAMLなしでもできるんだな」とか言ってる知識と理解力の低さで
なぜ「WPFは廃れる賭けてもいい」とか言い切れるんだ？ MVVMとオブジェクト指向って関係あるのエロい人？ .Net MAUIがMVU対応で宣言的に書けるから、XAMLとはおさらばできるかもな ModelとViewの分離ならMFCの頃から実装されてるじゃん このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 134日 21時間 2分 28秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
