アカウント名:
パスワード:
許してください、まだまだ案件でWindows Formが多いんです…(過去アプリのUIそのままで機能追加・改修しろとか)
せめてWPF Canvasにアンカー相当があれば、段階的にというかいったんガラだけ移行して浸透させていくとかもできたかもしれないけど、
（MVVMとかは置いといて）WPFでサクッとツール作れず、デザイン移植しづらくて、アニメーションとか別に求めてないし、結果触れてる人も増えてこないので選択肢として出しにくいんだよな。
OSSとか世界向けだと見栄えも綺麗にしたくもなるけど、即日欲しいツールとか作るためにGridレイアウトとか調整してると時間がもったいなくなっちゃったりも。（変に凝るための）選択肢が少ないというのがむしろWinFormsのメリットになってしまっている気がする。
# それにしてもVS2019が．ＮＥＴ６サポートしないとは思わなかった。
「MVVMとか別にして」ならば、それは慣れの問題なだけです。
新規ならそうなんだけど、既存のものを持っていくときめんどくさいのは画面なので。
WPFのレイアウタは、なにも考えなくても適当に配置して動くのが良いんでは？GridやCanvasなんぞ使わず、作るだけなら StackPanelだけでやればよろしい。
StackPanelはマージン切っていくのが大変。WinFormsもStackPanelだったやつならいいけど。
Canvasがある程度適当に配置して動くが、マージン固定ができない。
一応Gridで分割せずに１セルでやるのが一番近いんだが、それならCanvasにマージン固定する機能つけてくれればいいのにと思う。うーん、Gridで １セルでとりあえず導入してしまうかなぁ。
マージンはスタイルで一括指定してイレギュラーなのは個別指定すればデザイナでチマチマ配置するよりもずっと楽でしょ
新規ならそれでいいけどね。いや、それでもWindowがStackPanelなのはあんまり想像できないんだけど。縦のスタックパネルで行ごとに横のスタックパネル積むとかか？
元コメのように、「過去アプリのUIそのままで」みたいな状況においての話なので、スタイル定義し始めると時間かかる（というか、そんな綺麗にスタイルで一括指定できる様になってないな）
とにかく開発のベースをWPFとかに持っていき、そこからWPFらしい形に直していくって感じで段階移行するのが狙いなので。習熟したメンバーが移行するわけではない。
それにWPFのスタイル…というよりはリソース定義が最初がめんどくさいしなぁ。リソースをもうちょい簡潔に描かせてくれりゃいいんだけど。
StackPanelは一番多用するだろhttps://qiita.com/Kosen-amai/i... [qiita.com]
なので リソースやらスタイルやら考えずに、StackPanelで並べればOKって話だよ。StackPanelの一番シンプルな(何も面倒なことせず部品並べるだけ)って構成にすれば、いわゆる箇条書き状態になる。ゲーム画面とか、凝った物はもちろん無理だが、世の中の入力画面やら結果画面とかは、だいたいStackPanelだけでいい。
既存画面と同じレイアウトでという話ならCanvasで座標固定で配置すればいい。スタイルやリソース定義は楽をするために使うものであって、書かなきゃ出来ないようなものは何一つないぞ。
特にStackPanelが一番っていう説得力はない。一番でもないし、Gridで覆われてる（WindowがStackPanelではない）、StackPanelつかったがために余白作ってる。
StackPanelがうまく使えば便利なものだというのは知っているが、リンク先の最初のウィンドウは今ひとつ。二つ目は部分的なので効果的と言えなくもないけど。StackPanelは横に広がってしまうからね。最初のVisualStudioのプロジェクト作成ダイアログとかと比べればいい。
「過去アプリのUIそのままで」っていう元々の話にも合わない。
これは昔見か
言ってることはわかる。ありがとう。でもその辺はもう通ったの。
> スタイルやリソース定義は楽をするために使うものであってはわかるんだけど、その前でスタイルについて愚痴ってたのは、そのもう一個前で>>マージンはスタイルで一括指定してって言われたから。さらに、StackPanelを推されたけど、StackPanel使ってしまうとスタイルでマージンつけていくのが結構めんどくさい（左上位置もマージン入力したりしないといかんし、自由に動かないからね）様に思うっていうのが発端。
> Canvasで座標固定で配置すればいい。Canvasだと左上は固定できる。Anchor相当があればこれでいいと思った。でもないという話をしていた。「それならCanvasにマージン固定する機能つけてくれればいいのにと思う。うーん、Gridで １セルでとりあえず導入してしまうかなぁ。」
Canvasで右下のマージンを簡単に固定できるならば教えて欲しい。
GridはStackPanelを置くエリアを分けるために使うもの。Gridに通常のコントロール直置きはあまりやらない。
その動画のやつはWPFで作れば楽だったろうに。無駄な労力使ってんなー。
> Canvasで右下のマージンを簡単に固定できるならば教えて欲しい。
えっと……。もしかして、Canvas.Right / Canvas.Bottomをご存じないのでしょうか？
# Canvasなんて滅多に使うものじゃないと思う。StackPanelとかで詰め直した方が、後々楽。
> えっと……。> もしかして、Canvas.Right / Canvas.Bottomをご存じないのでしょうか？
えっと……。もしかしてCanvas.LeftとCanvas.Rightを同時に使えないのをご存知ないか、Gridセルなどでの右下マージン固定とかWinnFormsのAnchorの機能をご存知ないのでしょうか。
> # Canvasなんて滅多に使うものじゃないと思う。StackPanelとかで詰め直した方が、後々楽。
・・・さすがにもう最初から読んでとしか言えん。
あらあら、Anchorの話もでてるのにStackPanelしかでてこないとか、固定サイズのウィンドウしか作ったことないんだろうな。DockPanelすらでてこないとはね…。
動画のやつはWPFじゃないのかよって思うのは確かだが、WPFだと楽ってことはないだろう。開閉のアニメーションとかの表現力が豊かなだけだからな。
でなければどのサンプルはもっとリッチになるだろうよ。
そこまでするコストに見合ったメリットがないんだよなぁ
そうねぇ、ただ別の回答もついているようにコストがね。
一度作ってしまえばいいのだけど、（Gridを真似てMerginの固定で済ますにせよ）デザイナ周りとかどうなるのか見てみないとなんとも言えない。探せばありそうだし、どこで妥協するか次第ではあるけど。
そんなこんなも含めて、CanvasはなんでMergin固定できるようにしてくれなかったのかと。
MVVMだとバインディング先はドコ？を探すのにgrepに行き着く。CでWindow作ってた頃に退化してる💢
整合性とか排他とか参照関係を厳密に管理するなら使わんほうがいいかも？
#見た目だけ全力注がれてデータ整合性とか同期とか排他とか破綻してるやつ再設計ちゅー
いにしえの「ほーむぺーじ作成ツール」と大差ないカオスになるのは目に見えてるな…
.NET 3.5の時代のWPFは、内部でメモリ不足やスタックオーバー起こすとエラーや例外の出力すらなく表示しないので、Pathを手書きしてメモリ使用量を調整する必要があったけどな、、、
Blendなんか誰が使ってんのよ
Creature HouseやMetacreationsのころのExpressionをください。
WPFデザイナとかあるよね？
ちょっと複雑なことしようと思うと破綻しそうになるけど、ユーザーコントロールに分割するのが正しいかもしれない。面倒だから前提知識調べてXAML直接書いてるけど。
そこで補完ライブラリが出るのがJava。出ないのが.netそんな文化。
Javaの場合、補完ライブラリがあって、ようやくWPFとかWinFormの廉価版になるかどうかって程度の利便性しかないからな、、、.NETの場合は、フレームワークそのものには手を入れたくなるほど変なところがないので、ユーザーコントロールとかのライブラリだけですんでしまう。
Run anywhereを標榜してるのと、とりあえずWindowsで動けばいいのとの違いはあるとはいえJavaのUI周りはグダグダだったね
WinForm vs WPF vs UWP(or Uno Platform) vs MAUI
WinUI
.NET 5ですらまだ使ったことないのにもう6かよ・・・
＃主にVS2017、ケースに応じて2012/2015を使ってる
あまり古い開発環境を使うのはそれのランタイムのサポート(セキュリティフィックスを含む)がいつ終了になるかと考えるとすこし怖くありませんか？
中間言語ではなく機械語にコンパイルするので問題ありませんとか？
.NET Core系はLTSでもサポート期間が短すぎるからあっというまに終了する。どんどん乗り換えなきゃいけない自転車操業をやる羽目になるのが確定するから、そっちの方が恐ろしい。
.NETは他のプラットフォームに比べると、実行環境やライブラリ/フレームワークのバージョンやを上げたときに破壊的変更で手を入れないといけなくなったり、実際に問題が起きたりする可能性は比較的穏やかな方。単体テストとE2Eテストを完備して自転車から降りず段差で躓かないよう走り続けられるように整備した方が良い。
これが笑っちゃうことに、VS2015のサポートは一応 2025/10/14。
一方 .NET 6のサポートは LTSで3年なので、 2024年11月。
それならせめてRoslyn積んでるのにはビルドぐらいはできる様にしておいて欲しかったよなぁ。特に今回だけは初のLTSで、.NET Frameworkのバージョン番号より超えて、わざわざWinFormsまで移植して移行を促す下地もそろったんだから商売的な観点で普及第一って意味で今回だけは2017/2019くらいはビルド可能ぐらいにしてくれてたら嬉しかったなぁ。
デバッグ機能とか新たな便利な補助機能は当然新しい環境だけでいいんだけど。
VSCode使えってことなのかな。
（自分は2022使えるしVSCodeでもまぁべつにいいので個人的にはこまらないが、仕事場で使えないのがしんどいのよね。当然サポートされてないから.NET Coreが選択肢に挙げにくくなるし。）
.NET frameworkのほうは4.8がOSコンポーネントだから、Server 2022でサポートされるとなるとかなり長く使えそうなんだよなぁ……。
.NET 5は非LTSだから実戦投入は見送った。.NET Core 3.1から.NET 6に上げる予定。なお、Formsアプリではない。
適した方をつかえばいいとおもうよ。
環境をきちんと縛れば、WPFより軽くていいと思う。(自分で書いて自分で使う、アマチュアの感想です
ようし、パパPowerShell/WinFormでばりばり書いちゃうぞー。と思ったらPerl/Tkで事足りる案件だった。残念。
そこはPowerShell/WPFだろ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
よーしパパ、.NET 6 で Windows Formしちゃうぞー (スコア:0)
許してください、まだまだ案件でWindows Formが多いんです…(過去アプリのUIそのままで機能追加・改修しろとか)
Re: (スコア:0)
せめてWPF Canvasにアンカー相当があれば、段階的にというかいったんガラだけ移行して
浸透させていくとかもできたかもしれないけど、
（MVVMとかは置いといて）WPFでサクッとツール作れず、
デザイン移植しづらくて、アニメーションとか別に求めてないし、結果触れてる人も増えてこないので
選択肢として出しにくいんだよな。
OSSとか世界向けだと見栄えも綺麗にしたくもなるけど、即日欲しいツールとか作るために
Gridレイアウトとか調整してると時間がもったいなくなっちゃったりも。
（変に凝るための）選択肢が少ないというのがむしろWinFormsのメリットになってしまっている気がする。
# それにしてもVS2019が．ＮＥＴ６サポートしないとは思わなかった。
Re: (スコア:0)
「MVVMとか別にして」ならば、それは慣れの問題なだけです。
Re: (スコア:0)
新規ならそうなんだけど、既存のものを持っていくときめんどくさいのは画面なので。
Re: (スコア:0)
WPFのレイアウタは、なにも考えなくても適当に配置して動くのが良いんでは？
GridやCanvasなんぞ使わず、作るだけなら StackPanelだけでやればよろしい。
Re: (スコア:0)
StackPanelはマージン切っていくのが大変。
WinFormsもStackPanelだったやつならいいけど。
Canvasがある程度適当に配置して動くが、マージン固定ができない。
一応Gridで分割せずに１セルでやるのが一番近いんだが、
それならCanvasにマージン固定する機能つけてくれればいいのにと思う。
うーん、Gridで １セルでとりあえず導入してしまうかなぁ。
Re: (スコア:0)
マージンはスタイルで一括指定してイレギュラーなのは個別指定すればデザイナでチマチマ配置するよりもずっと楽でしょ
Re: (スコア:0)
新規ならそれでいいけどね。
いや、それでもWindowがStackPanelなのはあんまり想像できないんだけど。
縦のスタックパネルで行ごとに横のスタックパネル積むとかか？
元コメのように、「過去アプリのUIそのままで」みたいな状況においての話なので、
スタイル定義し始めると時間かかる（というか、そんな綺麗にスタイルで一括指定できる様になってないな）
とにかく開発のベースをWPFとかに持っていき、そこからWPFらしい形に直していくって感じで段階移行するのが狙いなので。
習熟したメンバーが移行するわけではない。
それにWPFのスタイル…というよりはリソース定義が最初がめんどくさいしなぁ。
リソースをもうちょい簡潔に描かせてくれりゃいいんだけど。
Re: (スコア:0)
StackPanelは一番多用するだろ
https://qiita.com/Kosen-amai/i... [qiita.com]
Re: (スコア:0)
なので リソースやらスタイルやら考えずに、StackPanelで並べればOKって話だよ。
StackPanelの一番シンプルな(何も面倒なことせず部品並べるだけ)って構成にすれば、いわゆる箇条書き状態になる。
ゲーム画面とか、凝った物はもちろん無理だが、世の中の入力画面やら結果画面とかは、だいたいStackPanelだけでいい。
既存画面と同じレイアウトでという話ならCanvasで座標固定で配置すればいい。
スタイルやリソース定義は楽をするために使うものであって、書かなきゃ出来ないようなものは何一つないぞ。
Re: (スコア:0)
特にStackPanelが一番っていう説得力はない。
一番でもないし、Gridで覆われてる（WindowがStackPanelではない）、StackPanelつかったがために余白作ってる。
StackPanelがうまく使えば便利なものだというのは知っているが、リンク先の最初のウィンドウは今ひとつ。
二つ目は部分的なので効果的と言えなくもないけど。
StackPanelは横に広がってしまうからね。最初のVisualStudioのプロジェクト作成ダイアログとかと比べればいい。
「過去アプリのUIそのままで」っていう元々の話にも合わない。
これは昔見か
Re: (スコア:0)
言ってることはわかる。ありがとう。
でもその辺はもう通ったの。
> スタイルやリソース定義は楽をするために使うものであって
はわかるんだけど、その前でスタイルについて愚痴ってたのは、そのもう一個前で
>>マージンはスタイルで一括指定して
って言われたから。
さらに、StackPanelを推されたけど、StackPanel使ってしまうとスタイルでマージンつけていくのが結構めんどくさい（左上位置もマージン入力したりしないといかんし、自由に動かないからね）様に思うっていうのが発端。
> Canvasで座標固定で配置すればいい。
Canvasだと左上は固定できる。Anchor相当があればこれでいいと思った。でもないという話をしていた。
「それならCanvasにマージン固定する機能つけてくれればいいのにと思う。うーん、Gridで １セルでとりあえず導入してしまうかなぁ。」
Canvasで右下のマージンを簡単に固定できるならば教えて欲しい。
Re: (スコア:0)
GridはStackPanelを置くエリアを分けるために使うもの。
Gridに通常のコントロール直置きはあまりやらない。
その動画のやつはWPFで作れば楽だったろうに。無駄な労力使ってんなー。
Re: (スコア:0)
> Canvasで右下のマージンを簡単に固定できるならば教えて欲しい。
えっと……。
もしかして、Canvas.Right / Canvas.Bottomをご存じないのでしょうか？
# Canvasなんて滅多に使うものじゃないと思う。StackPanelとかで詰め直した方が、後々楽。
Re: (スコア:0)
> えっと……。
> もしかして、Canvas.Right / Canvas.Bottomをご存じないのでしょうか？
えっと……。
もしかしてCanvas.LeftとCanvas.Rightを同時に使えないのをご存知ないか、
Gridセルなどでの右下マージン固定とかWinnFormsのAnchorの機能をご存知ないのでしょうか。
> # Canvasなんて滅多に使うものじゃないと思う。StackPanelとかで詰め直した方が、後々楽。
・・・さすがにもう最初から読んでとしか言えん。
Re: (スコア:0)
あらあら、Anchorの話もでてるのにStackPanelしかでてこないとか、固定サイズのウィンドウしか作ったことないんだろうな。
DockPanelすらでてこないとはね…。
動画のやつはWPFじゃないのかよって思うのは確かだが、WPFだと楽ってことはないだろう。
開閉のアニメーションとかの表現力が豊かなだけだからな。
でなければどのサンプルはもっとリッチになるだろうよ。
Re: (スコア:0)
Re: (スコア:0)
そこまでするコストに見合ったメリットがないんだよなぁ
Re: (スコア:0)
そうねぇ、ただ別の回答もついているようにコストがね。
一度作ってしまえばいいのだけど、
（Gridを真似てMerginの固定で済ますにせよ）デザイナ周りとかどうなるのか見てみないとなんとも言えない。
探せばありそうだし、どこで妥協するか次第ではあるけど。
そんなこんなも含めて、CanvasはなんでMergin固定できるようにしてくれなかったのかと。
Re: (スコア:0)
MVVMだとバインディング先はドコ？を探すのにgrepに行き着く。
CでWindow作ってた頃に退化してる💢
整合性とか排他とか参照関係を厳密に管理するなら使わんほうがいいかも？
#見た目だけ全力注がれてデータ整合性とか同期とか排他とか破綻してるやつ再設計ちゅー
Re: (スコア:0)
というかフレームワークとして低階層すぎるのか
もうそろそろxamlを人間に書かせようとするのやめて欲しいですね
あんな前提知識必須な構造物は人間が書くものじゃないと思うんですが
Re: (スコア:0)
いにしえの「ほーむぺーじ作成ツール」と大差ないカオスになるのは目に見えてるな…
Re: (スコア:0)
Re: (スコア:0)
.NET 3.5の時代のWPFは、内部でメモリ不足やスタックオーバー起こすとエラーや例外の出力すらなく表示しないので、Pathを手書きしてメモリ使用量を調整する必要があったけどな、、、
Re: (スコア:0)
Blendなんか誰が使ってんのよ
Re: (スコア:0)
Creature HouseやMetacreationsのころのExpressionをください。
Re: (スコア:0)
WPFデザイナとかあるよね？
ちょっと複雑なことしようと思うと破綻しそうになるけど、ユーザーコントロールに分割するのが正しいかもしれない。
面倒だから前提知識調べてXAML直接書いてるけど。
Re: (スコア:0)
そこで補完ライブラリが出るのがJava。
出ないのが.net
そんな文化。
Re: (スコア:0)
Javaの場合、補完ライブラリがあって、ようやくWPFとかWinFormの廉価版になるかどうかって程度の利便性しかないからな、、、
.NETの場合は、フレームワークそのものには手を入れたくなるほど変なところがないので、ユーザーコントロールとかのライブラリだけですんでしまう。
Re: (スコア:0)
Run anywhereを標榜してるのと、とりあえずWindowsで動けばいいのとの違いはあるとはいえ
JavaのUI周りはグダグダだったね
Re: (スコア:0)
WinForm vs WPF vs UWP(or Uno Platform) vs MAUI
Re: (スコア:0)
WinUI
Re: (スコア:0)
.NET 5ですらまだ使ったことないのにもう6かよ・・・
＃主にVS2017、ケースに応じて2012/2015を使ってる
Re: (スコア:0)
あまり古い開発環境を使うのはそれのランタイムのサポート(セキュリティフィックスを含む)がいつ終了になるかと考えるとすこし怖くありませんか？
Re: (スコア:0)
中間言語ではなく機械語にコンパイルするので問題ありませんとか？
Re: (スコア:0)
.NET Core系はLTSでもサポート期間が短すぎるからあっというまに終了する。
どんどん乗り換えなきゃいけない自転車操業をやる羽目になるのが確定するから、そっちの方が恐ろしい。
Re: (スコア:0)
.NETは他のプラットフォームに比べると、実行環境やライブラリ/フレームワークのバージョンやを上げたときに
破壊的変更で手を入れないといけなくなったり、実際に問題が起きたりする可能性は比較的穏やかな方。
単体テストとE2Eテストを完備して自転車から降りず段差で躓かないよう走り続けられるように整備した方が良い。
Re: (スコア:0)
これが笑っちゃうことに、
VS2015のサポートは一応 2025/10/14。
一方 .NET 6のサポートは LTSで3年なので、 2024年11月。
それならせめてRoslyn積んでるのにはビルドぐらいはできる様にしておいて欲しかったよなぁ。
特に今回だけは初のLTSで、.NET Frameworkのバージョン番号より超えて、
わざわざWinFormsまで移植して移行を促す下地もそろったんだから
商売的な観点で普及第一って意味で今回だけは2017/2019くらいはビルド可能ぐらいにしてくれてたら嬉しかったなぁ。
デバッグ機能とか新たな便利な補助機能は当然新しい環境だけでいいんだけど。
VSCode使えってことなのかな。
（自分は2022使えるしVSCodeでもまぁべつにいいので個人的にはこまらないが、
仕事場で使えないのがしんどいのよね。
当然サポートされてないから.NET Coreが選択肢に挙げにくくなるし。）
Re: (スコア:0)
.NET frameworkのほうは4.8がOSコンポーネントだから、Server 2022でサポートされるとなるとかなり長く使えそうなんだよなぁ……。
Re: (スコア:0)
.NET 5は非LTSだから実戦投入は見送った。.NET Core 3.1から.NET 6に上げる予定。なお、Formsアプリではない。
Re: (スコア:0)
適した方をつかえばいいとおもうよ。
Re: (スコア:0)
環境をきちんと縛れば、WPFより軽くていいと思う。(自分で書いて自分で使う、アマチュアの感想です
Re: (スコア:0)
ようし、パパPowerShell/WinFormでばりばり書いちゃうぞー。
と思ったらPerl/Tkで事足りる案件だった。残念。
Re: (スコア:0)
そこはPowerShell/WPFだろ