アカウント名:
パスワード:
サーバサイドアプリの開発ならまだしも、GUIアプリの開発ならC#が他を圧倒する
でも、.NETってUIライブラリが沢山あって、要員集めが大変そうだよね
WinForms (自由度は皆無)WPF (WinForms使いにディスられている。ボイラープレートを書かないといけない)UWP (夢の跡)Xamarin.Forms (スマホUIベースでマルチプラットフォーム)MAUI ( 次期UI(Xamarinの後継) )
たくさんか?Web系なんか何から手を付けたらいいかわからないぐらい酷い状態だし、Androidもバージョンによって書き方が変わりすぎてて参考書泣かせだし。
Windowsデスクトップに限定すればWPF選んでおけば間違いない。WinFormsは苦行。WPFがWinForms使いにディスられているって負け犬の遠吠えっしょ。ボイラープレートも必須じゃない。
UWPもXamarinも手を出さなくてよかった。
.NET Coreも初期の混沌としていた時代から関わってた人、お疲れ様です。って感じ。こなれてきた3.xから使ってみようかなと思う。
> ボイラープレートも必須じゃない。必須ではないけど、WPFの魅力は半減するでしょう。
WPFは(DependecyPropertyの定義や、INotifyPropertyChanged等)ボイラープレートを受け入れないとほとんどコードビハインドで書くことになりWinFormsと変わらないんじゃ・・・
# テンプレートを使えば作成の手間は減らせるが・・・
個人的にバインディングは必要最小限にとどめて、積極的にコードビハインドに書くスタイルが一番バランスが良いと思う。Rxは使用禁止、MVVMで書くかどうかも案件ごとにメリットデメリットをよく検討してからにする。
WinFormsと比較した時のWPFの最大のメリットはXamlでしょう。コントロールの部品化や拡張が用意だし、定義から画面構成の把握が容易だし、WinFormsと違ってまともにdiffがとれる。
> Windowsデスクトップに限定すればWPF選んでおけば間違いない。
これホント?
たいていはWPFで済むような気もするけど、ユーティリティでなくそれなりの規模があるようなやつはどうでしょう?
例えばVisual StudioのようなMDIをWPFだけではつくれない気がする。ちゃんと裏側調べたわけではないけどVisual StudioはFormの上にWPF乗っけているような気がするんですけど。違うかな
なあにwebアプリも含めてBlazorが天下統一してくれるから大丈夫。
ほんとうか?
BlazorをWEB専用以外で使うのは無理。UIフレームワークのAPIが、httpプロトコルとブラウザのhtmlレンダリングという概念に依存しまくり。なんでUI書くのにHTTP意識せなあかんのだ。
なにこれ。GWTじゃん。
WinForms ... 悪い意味で枯れているWPF ... 良い意味で枯れているUWP ... 種のまま腐った
> MAUI ( 次期UI(Xamarinの後継) )
どっちかというと、WPFの後継。WPFにXamarinのフレーバー足した感じだが、Xamarinみたいなレイアウタと実態が混在したり継承関係ぐだぐだになったりしてない。
Xamarinはクソすぎたので、あれで書くのはWinForms並みの苦行。
>>WinForms (自由度は皆無)
最初の1行で聞きかじった知識と思い込み(おそらく願望)の読むに値しない妄想だと分かった
読みたくないなら、わざわざ意味のないコメントをしなくても良いよ?
それとも、深く理解している貴方であれば、例えばListBox上の、各項目の表示内容をWPFのように簡単にカスタマイズする方法を把握されているのですか?(例えば題名を1行目、詳細の先頭数文字を2行目に表示し、各項目を上に下に移動させたり削除するためのボタンを右側につける)
その結果何が起こったかと言えば、Win32APIや独自の描画APIを使ったカスタムコントロールの登場な訳で、WinFormsが提供する機能としては自由度が低かったし、抜け道という意味では自由度が高かった。(まぁ、WPFでもHWND使えるけど)
もしかして、標準で提供されている機能の外で、ネイティブのAPIを叩けば実現できるから自由度は高いという主張ですか?
> (まぁ、WPFでもHWND使えるけど)そんな事をする必要もなく、TemplateやStyleを変更することで、標準内で完結してカスタマイズ可能なんですけどね?
オーナードローで余裕(爆
自前でListのItemの描画処理を実装すると?随分と無駄な苦労がお好きなようですね?
そして、Item内のボタンに関する記述が見当たりませんが、どう処理するつもりなのでしょうか?まさか、ボタンの処理を疑似的に実装とか言わないですよね?
ネタにマジレスされても困るんですが……
WinFormsしか使えないロートルさんは本気でそう思ってそうだからねw念のため指摘してあげないと
> (例えば題名を1行目、詳細の先頭数文字を2行目に表示し、各項目を上に下に移動させたり削除するためのボタンを右側につける)
そんなことがやりたいのか?おえっ
それなりによく見るUIだと思うが
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
GUIアプリの開発ならC# (スコア:0)
サーバサイドアプリの開発ならまだしも、
GUIアプリの開発ならC#が他を圧倒する
Re:GUIアプリの開発ならC# (スコア:0)
でも、.NETってUIライブラリが沢山あって、
要員集めが大変そうだよね
WinForms (自由度は皆無)
WPF (WinForms使いにディスられている。ボイラープレートを書かないといけない)
UWP (夢の跡)
Xamarin.Forms (スマホUIベースでマルチプラットフォーム)
MAUI ( 次期UI(Xamarinの後継) )
Re: (スコア:0)
たくさんか?
Web系なんか何から手を付けたらいいかわからないぐらい酷い状態だし、Androidもバージョンによって書き方が変わりすぎてて参考書泣かせだし。
Windowsデスクトップに限定すればWPF選んでおけば間違いない。
WinFormsは苦行。
WPFがWinForms使いにディスられているって負け犬の遠吠えっしょ。
ボイラープレートも必須じゃない。
UWPもXamarinも手を出さなくてよかった。
.NET Coreも初期の混沌としていた時代から関わってた人、お疲れ様です。って感じ。
こなれてきた3.xから使ってみようかなと思う。
Re: (スコア:0)
> ボイラープレートも必須じゃない。
必須ではないけど、WPFの魅力は半減するでしょう。
WPFは(DependecyPropertyの定義や、INotifyPropertyChanged等)
ボイラープレートを受け入れないとほとんどコードビハインドで書くことになり
WinFormsと変わらないんじゃ・・・
# テンプレートを使えば作成の手間は減らせるが・・・
Re: (スコア:0)
個人的にバインディングは必要最小限にとどめて、積極的にコードビハインドに書くスタイルが一番バランスが良いと思う。
Rxは使用禁止、MVVMで書くかどうかも案件ごとにメリットデメリットをよく検討してからにする。
WinFormsと比較した時のWPFの最大のメリットはXamlでしょう。
コントロールの部品化や拡張が用意だし、定義から画面構成の把握が容易だし、WinFormsと違ってまともにdiffがとれる。
Re: (スコア:0)
> Windowsデスクトップに限定すればWPF選んでおけば間違いない。
これホント?
たいていはWPFで済むような気もするけど、ユーティリティでなく
それなりの規模があるようなやつはどうでしょう?
例えばVisual StudioのようなMDIをWPFだけではつくれない気がする。
ちゃんと裏側調べたわけではないけどVisual StudioはFormの上にWPF
乗っけているような気がするんですけど。違うかな
Re: (スコア:0)
なあにwebアプリも含めてBlazorが天下統一してくれるから大丈夫。
ほんとうか?
Re: (スコア:0)
BlazorをWEB専用以外で使うのは無理。
UIフレームワークのAPIが、httpプロトコルとブラウザのhtmlレンダリングという概念に依存しまくり。
なんでUI書くのにHTTP意識せなあかんのだ。
Re: (スコア:0)
なにこれ。GWTじゃん。
Re: (スコア:0)
WinForms ... 悪い意味で枯れている
WPF ... 良い意味で枯れている
UWP ... 種のまま腐った
Re: (スコア:0)
> MAUI ( 次期UI(Xamarinの後継) )
どっちかというと、WPFの後継。
WPFにXamarinのフレーバー足した感じだが、Xamarinみたいなレイアウタと実態が混在したり継承関係ぐだぐだになったりしてない。
Xamarinはクソすぎたので、あれで書くのはWinForms並みの苦行。
Re: (スコア:0)
>>WinForms (自由度は皆無)
最初の1行で聞きかじった知識と思い込み(おそらく願望)の読むに値しない妄想だと分かった
Re: (スコア:0)
読みたくないなら、わざわざ意味のないコメントをしなくても良いよ?
それとも、深く理解している貴方であれば、
例えばListBox上の、各項目の表示内容をWPFのように簡単にカスタマイズする方法を把握されているのですか?
(例えば題名を1行目、詳細の先頭数文字を2行目に表示し、各項目を上に下に移動させたり削除するためのボタンを右側につける)
Re: (スコア:0)
その結果何が起こったかと言えば、
Win32APIや独自の描画APIを使ったカスタムコントロールの登場な訳で、
WinFormsが提供する機能としては自由度が低かったし、
抜け道という意味では自由度が高かった。
(まぁ、WPFでもHWND使えるけど)
Re: (スコア:0)
もしかして、標準で提供されている機能の外で、
ネイティブのAPIを叩けば実現できるから
自由度は高いという主張ですか?
> (まぁ、WPFでもHWND使えるけど)
そんな事をする必要もなく、TemplateやStyleを変更することで、
標準内で完結してカスタマイズ可能なんですけどね?
Re: (スコア:0)
オーナードローで余裕(爆
Re: (スコア:0)
自前でListのItemの描画処理を実装すると?
随分と無駄な苦労がお好きなようですね?
そして、Item内のボタンに関する記述が見当たりませんが、
どう処理するつもりなのでしょうか?
まさか、ボタンの処理を疑似的に実装とか言わないですよね?
Re: (スコア:0)
ネタにマジレスされても困るんですが……
Re: (スコア:0)
WinFormsしか使えないロートルさんは本気でそう思ってそうだからねw
念のため指摘してあげないと
Re: (スコア:0)
> (例えば題名を1行目、詳細の先頭数文字を2行目に表示し、各項目を上に下に移動させたり削除するためのボタンを右側につける)
そんなことがやりたいのか?
おえっ
Re: (スコア:0)
それなりによく見るUIだと思うが