以下の内容はhttps://var.blog.jp/archives/61721571.htmlより取得しました。
COMMENT
コメント一覧 (40)
1. ななしさん
2016/09/21 19:14
UPW ではなく、UWP ですよ
2. [管理人]
2016/09/22 12:09
ほんとうですね
修正しました
おしえていただきありがとうございます
3. 7of9
2017/04/21 15:56
色々参考になります。
ありがとうございます。
4. ななしさん
2017/05/13 12:08
WPFで複雑な事をするとVisualStudio自体が落ちる事が多々ありますが、WPFってFormよりバグが多そうです。
5. 4のななしさん
2017/05/13 13:36
VisualStudio自体が落ちる原因がプラグインによるものでした。
WPFはまだまだ素人ですが、Form世代よりリッチな表現ができるのがいいですね。
6. ななしさん
2017/05/30 20:28
バグの面だけ言えばWPFの方が多いです。初心者で使い方がわかっていないのでバグに見えただけでは?
7. [管理人]
2017/05/30 22:44
そうでしょうか
どちらも適度に使ったのですが WinForms ではコントロール系にバグがありすぎて
単純なアプリを作るだけでも苦労しましたが WPF では全くないわけではありませんが
困ることはほとんどありませんでした
バグの判断基準は私見ではなく stackoverflow や ms のコミュニティで昔からあるバグです
と書かれていたものなのでバグには違いないと思います
8. ほが
2017/06/08 08:42
大抵の場合自分のスキルのなさを人のせいにするんだよな
9. [管理人]
2017/06/08 21:49
スキルあるなし問わずバグが多く放置なものを使いたくはないですね
どんなバグだらけのものであろうとやりたいことを実現出来るスキルがあるのだとすれば すごいとは思いますがそこにがんばるより もっと使いやすいものを選ぶという選択をしたいです
WinForms 使いたい人が使うことを否定する気はありませんので
あなたが WinForms のほうが優れてると思うのなら使えばいいと思います
10. C#er
2017/08/19 22:58
文字比較仕様が変だ!バグだ!
→包摂基準(総務省)知らないだけ
少数丸めが四捨五入じゃねえ!バグだ!
→IEEE知らないだけ&指定方法知らないだけ
みたいな痛い人がほぼ大半だから、バグと騒いでてもまるで信用してませんけどね。
まあ、新規はWPFというのは同意です。
ただし、
・グリッド(コッチは暫定)
・WIN32API
この二つが必要にならないように出来るなら、ですかね。
グリッドは大量データ使わなければ構わないけど、使いたがるとこは基本大量データ貼りたがるw
11. はち
2017/09/06 15:13
確かにWinFormsは古いと思う
でもWinFormsよりWPFに関する情報がまだ少ないから敷居が高く感じます
12. [管理人]
2017/09/20 21:51
> 文字比較仕様が変だ!バグだ!
> →包摂基準(総務省)知らないだけ
> 少数丸めが四捨五入じゃねえ!バグだ!
> →IEEE知らないだけ&指定方法知らないだけ
このあたりはよくあるやつですね
Chrome の JavaScript みたいに float 部分で誤差があれば表示したときに 0.30...4 のように表示してくれればいいのですが 言語によってはダンプやデバッグツールでみても全く同じ表示になっていて == は false になるのでこの不親切さでハマった覚えがあります
ですが ソフトウェアのバグ自体はそんなに珍しいものではないと思います
一日中プログラム書いてるような生活をしてれば 探そうとしなくても週に 1 つ程度は何かのバグが見つかると思います(私の経験的に)
まあ 9 割以上が誰かがすでに見つけていて issue があるのですけどね
記事内でバグを挙げておけばよかったのですが WinForms の場合は週に 1 つというレベルを遥かに超えていて (使い始めなので慣れてれば誰でも知ってるレベルのも含まれるからかも) 最初はひとつひとつメモっていたのですが 途中でもう知らないっとメモを投げ捨てるほどでした
なのでバグの例は書いてないです
というかそういうことがあったので勢いだけで書いた愚痴記事です
それなのにこのブログの中で閲覧数が上位になっていて驚いてます
> ・グリッド(コッチは暫定)
これは私も思いました
パフォーマンス面で数千数万のデータを表示するとなると WPF はちょっと遅すぎるので ここだけは WinForms のほうが優れてると思います
> ・WIN32API
ウィンドウのスタイルを変えるとかはないですが FileDialog みたいのならけっこう WPF 中で使ってますね
13. [管理人]
2017/09/20 21:54
> 確かにWinFormsは古いと思う
> でもWinFormsよりWPFに関する情報がまだ少ないから敷居が高く感じます
それもありますよね
使ってる人が少ないので情報も少なめ
これからまだまだ良くなって人が増えるのかと思いきや、 Microsoft はもう Win10 用の UWP の方に力を入れているみたい
セキュアにするため UWP のストアからしかアプリを入れられない Windows エディションを作るみたいな話題も耳にしました
なので 今後 WPF が大幅進化して WPF ユーザも増える なんていうのは想像できないです
情報が増える期待もあんまりできないですね
14. ななしさん
2017/11/06 22:59
未だにWPFからのC#入門書が少ないのが現状なのでしょうか
WPF(XMAL)入門サイトや入門書を見ると必ず、一番初めにBindingの話が出てきます(当たり前ですが)
Bindingしなくてもコードからtextblockの内容変えれるのに...
私のようなWinForm道場出身者からすると「レベル高けー」と言うしかないですね
どのサイトよりもわかりやすくてでおもしろいです!
15. ななしさん
2017/11/12 17:38
Windows Formって元々VBから来てるんじゃない?
ちょっとボタン配置した簡単なアプリくらいしか作りづらい。
旧VCとかでも同じような画面はあったけど、
基本的に全部コードで書いたから、
レイアウトがXAMLになったWPFは使いやすくて作りやすかった。
理にかなってるしね。
Androidとか似たような考え方だし、
Windows FormってVBからの移行のために昔のやり方を引きずってるだけだと思う。
16. [管理人]
2017/11/15 00:24
そういえば WinForms のアプリでメインのクラスを VB の名前空間のクラスを継承して作っているのをみたことがあります
C# なのにどうして VB の継承してるんだろうと疑問に思ったのですが WinForms 自体が VB からと考えればなっとくです
単純に GUI でボタンをぺたぺた並べて貼り付けて簡単なアプリ作るのにはいいのですが全画面やウィンドウサイズ変更などに合わせてレスポンシブにレイアウト調整となるとすごく大変ですからね
アンカーじゃ限界ありますし デフォルトコントロールだと配置やマージン関係にバグが多くて単純なことですら……
web のHTML もそうですし最近は XML 系の構造定義+スタイル定義 がほとんどの GUI の作り方になっててありがたい限りです
17. [管理人]
2017/11/15 00:41
14. ななしさん
Binding は入力値見るときに View のコントロール触らなくて良かったり Grid 関係ではオブジェクトのリストを関連付けるだけで良かったりといいところも多いですが 慣れるまでが大変ですからね
Binding 目当てで使う人ならともかく WinForms の GUI の作り方が嫌で XAML 使いたいってくらいの人には最初の難関だと思います
Binding は必須というわけでもないので XAML 使いたいだけなら View を XAML に置き換えるだけで直接コントロールのプロパティ書き換えも十分アリですよね
今でも 1 画面のみで機能もちょっとしたものだと ViewModel とか作らないで直接コントロールの値参照する作りだったりします
18. ななしさん
2018/04/26 12:06
一通り読んであげたけど、なんだか頭悪そうな文章だなぁと思いました。
あなたじゃWinFormsだろうがWPFだろうが、何使おうがたいしたモノは作れそうにないですね。
たいしてモノを知らないくせにこういう記事を書くのは、WinForms使ってる人に失礼ですよ
19. [管理人]
2018/04/26 18:53
無理して読んでくれなくてもかまいませんよ
わざわざこんなコメント残す人はもっとたいしたことないでしょう
以降コメント頂いても読んであげられないと思いますので、コメントはけっこうです
20. ななしん
2018/05/14 19:46
少なくとも、vsは、wpfになってから
遅いし、バグ多いし使いづらくなった。
これが真実だよ。
21. [管理人]
2018/05/15 22:15
遅くなったのは同意ですが バグについては私は WinForms のほうが多く感じます
さすがに .NETFramework ほどの規模ですべての機能のすべてのバグを把握できてる人はいないと思いますし バグの多さは使う人がどの機能をどう使うかで感じ方が変わると思います
私はどちらもシンプルなものだけであまり高度な使い方はしてません
その限りでは WPF ではほぼバグと感じるものはなく WinForms ではけっこう頻繁にであいました
22. ななし太郎さん
2018/05/25 17:16
バグが多いと言いますが、実体験として
作っててバグで困ったという経験はあまりありません。
他の方が、技術的に未熟なだけじゃ…と疑いたくなるのもわかります。
ホントにバグとしてあったとしても、クリティカルなものであれば
ある程度歴史のあるC#なりVB.netなりは、修正されていると思います。
もしそれでも、バグが多いというのであれば具体的な事例をいくつか挙げるべきかなと思います。
それを他の人が見て「確かにバグだね」というのか、「それはバグじゃねぇーよ」というかはわかりませんが。
ただ、バグが多いを連呼しても説得力がないですね。
23. [管理人]
2018/05/25 23:44
> 具体的な事例をいくつか挙げるべきかなと思います。
それはおっしゃるとおりだと思うのですけど 別コメで書いたように使ってて溜まったストレス発散的な記事であって具体的な問題点の紹介を目的としてるわけでもなければ バグであるかを判定してもらいたいというわけでもありません
あくまで個人ブログであって公的なものでもないので 具体的なものを出さずに書くなと言われても応えられません
信じる信じないは個人に任せてそう感じてる人もいるんだーくらいに流してくれればと思います
> クリティカルなもの
クリティカルかどうかで言えば違うと思います
あくまでコントロール周りのレイアウトやデザイナです
デザイナは有料(今は無料?)のより高度なツールがあったと思いますしコントロールは最悪 1 から自作すれば代替可能です
本格的に使う人は有料や無料のライブラリのコントロールを使ってるらしく そういったものではコントロールのバグは修正されているので デフォルトコントロールだけでどうこうしようとしなければあまり影響はないかと思います
バグと判断した理由はすでに書いたかもしれませんがドキュメントにある仕様通りであればそうは動かないはずのものであり MS のフォーラムや Stackoverflow 等でバグであると書かれてあり それに反論がなく それなりの評価をもらっているものです
単純にどういうものがあるのか興味があるなら その辺りで調べてみてください
もうけっこう前のものなので私自身 具体的に何があったかをはっきり覚えてないので……
24. 無名
2018/11/03 10:08
多分使い方がわからないからバグ呼ばわりしてるだけだと思う その手の質問よく受けるけどだいたいAnchor使ってないからそれ使えばすぐ解決することが多い
25. キリギリス
2018/11/07 19:46
個人的には、生産性(開発効率)の高さと求められるスキルレベルの低さ、可読性には、WinFormsに軍配が上がると思ってます。UIで凝った作りをしたい場合やマルチデバイスの場合のみ、WPFやUWPが選択肢になるのかなと思ってます。因みに小生はバグで困った事はありません。
26. ななしさん
2018/12/18 15:19
ユーザーに依ってはリッチな表現も不要だし細かなコンポーネントのバグも影響が無い。
そうなると、簡単に使えるWinFormsの方に軍配が上がる。
というか、WPFは色々出来そうだけど簡単なレイアウトを簡単に作れない。
産業用のリッチである必要のないアプリではこの辺が問題。というか面倒。
何か色々出来そうなんだけどなぁ…と思いつつWinFormsでさっさと仕上げる毎日。
27. ななしさん
2018/12/20 17:16
偶然とはいえ、こんな昔の記事を見つけてしまうなんて
さらに突っ込まざるを得ない自分が憎たらしい
今となっては、.netFramework自体が産廃となりつつある
WinFormsもWPFも死亡待ち中
MSとしては、Win7/8.1のサポート終了待ちをしてて、Win10のみになったら
UWP/Xamarin/Unityのみで行くだろうね
.netFrameworkも.netCoreに食われて消える予定だし
何が問題かってWinFormsで作られている業務ソフトが多すぎること
かつてのVB6マイグレーションと同じ事がWinFormsでも起こる予定になってること
今日もイベント駆動プログラムしかしらない元VB6プログラマーに
MVVMの基礎を説かないといけないのが憂鬱
28. ななしさん
2019/01/10 16:40
.NETCodeではWinFormsもWPFもサポート決定。
まだまだWinForms使えるね。
というか他が使えなさすぎ。
タスクトレイ常駐アプリをWPFで作ろうとすると面倒すぎてやる気にならん。
29. ななしさん
2019/01/15 22:27
個人ブログの古い投稿に書くのもなんだけど・・・
> 敷居が高い
辞書で調べましょう
今もお仕事でWindowsForms使ってますけど、業務ロジックとUIロジックが混在してバグだらけになっててすごい面倒
正直WPFだったら解決してるのにってのが多くて
TreeView+DataGridViewなコントロールのデータは自力で1行ずつAddしてるし、選択行から情報を取得するのにTagに色々なデータをぶち込んでてそれ以降はTagのデータを使う形で元のリストデータは使わない、そのせいでデータがばらばらに散ってて訳が分からない構造になってる
こういうところをWPFでデータバインドしてればかなり解決するんだけどねぇと正直辛い
30. ななしさん
2019/03/27 13:49
んーなんだろ。バグが多いバグが多いって連呼してるけど、具体的に何のこと言ってるんだろ。
仕事でform使っててそんなにバグで困ったことないけどなー。本当に使ったことあるのだろうか。
ただ、管理人もストレス発散記事だと言ってるので、そんなに信用度の高い情報ではないのでしょう。
31. ななしさん
2019/04/27 07:52
デスクトップアプリは現状WPF一択。
.NET Core 3&WPFで将来も明るい。
UWPはモバイルが死んだ今、存在意義がない。
制限を緩和したりデスクトップに寄せてきているけど、まだまだWPFには及ばない。
WinFormsの人もWPFに移行した方がよい。
「バインディングを使わねばならないのである」
「MVVMで開発せねばならないのである」
なんて馬鹿の発言に怯えてしり込みしているのかもしれないけれど、
バインディングも使わず、コードビハインドに全部コード書いてもいい。
それでもWPFに移行するメリットはある。
コードを一行も書かずに画面サイズ変更に柔軟に対応できるレイアウト作成はWinFormsにはできない。
まずは脱WinForms!
32. みそち
2019/06/25 22:42
winformのバグのほとんどは、win32apiのバグ。
windowsのバージョンが上がるたびにバグが増えたり、減ったりしてる。
データバインドしないからバグるわけじゃないし、UIとロジックが分離してないからバグるわけでもない。
33. うんこ
2019/08/13 23:09
データバインドって、言うほど便利じゃなくないですか?個人開発ならいいけど、チーム開発だと可読性悪い気がしますが。。。
34. ななしさん
2019/08/31 19:19
19の怒った管理人さんも可愛いです。
35. ななしさん
2019/12/29 08:19
Windows Forms使うのがギリギリ許せるケースは、個人で画面1つだけの小さな使い捨てアプリを作るときぐらい。
それ以外の全てのケースはWPFを第一候補で検討したほうが良い。
高DPI, レスポンシブレイアウトが当たり前の今の時代、Windows Formsで作るのは苦行すぎる。
複数人で開発するとき、画面をほんの少し修正しただけでDesignerファイルがあっちこっちぐっちゃぐちゃに書き換えられるWindows Formsは修正差分がまともにとれない。
Windows FormsからただWPFに変えるだけでも、本来しなくていい無駄な作業が減る。
データバインドも必要性を感じたら使えばいい。WPFだから使わなきゃいけないわけじゃない。
総じてWindows Formsは開発生産性が低い、修正時の工数も多くなる、結果、品質が悪い。
36. ななしさん
2020/04/19 15:46
WPFはWindows専用だから
Monoでも使えるWinFormsやAvaloniaUIの方が良いような…
37. 通りすがり
2021/06/13 22:32
こんな古い記事にコメントするのも悪いし管理人さんもだいぶ叩かれてるけど、たまたまこの記事が引っかかってしまい誤った認識を植え付けられてしまう哀れなエンジニアが減る事を願ってコメントします。
winfirmsは枯れたフレームワークなのでバグらしいバグはありません。
.Netのアップデートでバグが出た場合はMicrosoftがちゃんとサポートしてくれます。
管理人さんがバグだと思った事象やStackOverflowなどでバグだと騒いでいる事象は99%仕様動作です。
自分がやりたい事をフレームワークがサポートしてない、思ってた動作をしないからといってバグと言ってはいけません。
まずはよくMSDNを読みましょう。
WPFとFormのどっちが良いかは作るアプリによりけりなので是非は難しいですが、オープンソースで公開されてるパッケージはForm向けのものの方が多いのでnuget探せばだいたいのものが揃うのがFormの優位性ですね。
38.
[管理人]
2021/06/14 00:35
>>37
自分で必要な検証もせず 個人ブログの書き込みを鵜呑みにしていたら どの言語・ライブラリもどこかでディスられているわけで何も使えなくなりますし 気にするほどでもないと思いますよ
仕様と言うなら別に構いませんが 現実としてこう動くと期待されるものがそう動かないわけです
開発者からしては仕様であってもユーザからすればバグです
仕様だろうがバグだろうが 「WinForms は使えない」 のであって この認識は今も変わりません
.NET Core や .NET を経て大きく改善してくれることを期待したのですけどね
ASP.NET は多少大きめな変更があったみたいなこと聞きましたし
昔のことなのであまり詳しくは覚えてませんが 問題が起きたのはレイアウト系で WPF やウェブのようなレスポンシブだったり 柔軟性のある見た目にして作っていたときです
昔ながらのいかにもな Windows アプリの外観(コントロール単純に並べたくらい)であれば大きな問題はなかったと思います
WinForms がそういうものを作ることを想定していないから 使うものが間違ってると言われればそうかも知れません
困ったことがないという人が多いのも メジャーな使い方から外れてるからだとは思ってます
なのでどちらが良いかはアプリによるというのは私も同意です
TextBox を 2 つおいて片方の入力を変換した結果をもう片方に入れる くらいのシンプルなものなら私でも WinForms にするでしょうし
当時は外部パッケージを使わず 標準ライブラリのみという制約があった上での評価なので Nuget を使うなら WinForms でも使える部分が増えてくると思います
以前別件で 外部パッケージありのものを使ったときは 標準コントロールでの問題は発生しないものが多かった記憶がありますし
39. ななしさん
2021/10/05 16:46
Winformsのデザイナの
> よくわからないエラーで表示できない
には狂おしく同意.
それが「仕様」なのかもしれないけど,
フォームクラスの定義より前の行に何か定義を書いたら死亡するぜ!とかそんなのわかんねぇよ…っていう.
40. 野獣
2022/04/30 14:10
microsoftがUWPの開発やめる通達出してますね。
Windows App SDK(未完成)に切り替えて、WinForms、WPF全部使えるようにするってんで、WPFがむしろ重要性増す感じですね。
何がしたかったのかよくわからないですけど、簡単にFluent UI(mica material)が使えるなら嬉しい話。
.NET MAUIのリリースも控えてますし、なんだったらFlutterもWin32が使えるようになるから、選択肢がもっと増えますね!
ってことでもっとみんなXAML使ってリソース増やして♡