WPF(.NET4.x, .NET Core) GUIプログラミング Part24
■ このスレッドは過去ログ倉庫に格納されています
Windows Presentation Frameworkについて語るスレ。 前スレ WPF(.NET4.x, .NET Core) GUIプログラミング Part23 https://mevius.5ch.net/test/read.cgi/tech/1557960752/ 関連スレ 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 >>504 コード書くなら「Visual」Studioじゃないよな。 WIN32APIで書くのと変わらん。 >>512 UWP推進のために敢えて放置されてたのか、痒い所に手が届かない部分が所々合ってもどかしい せめて事前バインディングはマージしてくれ >UWP推進のために敢えて放置されてたのか これだよなぁ。ペゾルト本もWPFスキップさせられたし。 画面デザインとコードで分業できる、というけど実際そうしてるんか? 結局全部自分でやってね? >>513 cssを上手く使ってpcでもスマホでもちゃんと表示出来るのもあるんだけどねえ。 最近はスマホだけに最適化されてるのが増えてきた。 世も末だよ。 >>518 特に大学生はスマホオンリーで、PCなんて不要 という考えが大半なんだよな。 そりゃ見るだけならいいけどよ... >>519 キーボードよりスマホのフリック入力が速いと。 オレなんてミスタッチしまくりさ。 >>515 事前バインドは.net5とWinUI3でデスクトップに降りてくるようだからな ついでにイベントのバインドも出来るからビヘイビアの大半が要らなくなるのも良い 大幅変更のビッグウェーブくるね。目指すはwinformの開発効率。 今日からWPF始めたんだが x:Name で適当に名前つければ簡単にコントロール 利用できる事を知ったんだがだけどそれでいいのん? データバインドなんちゃら って必要なの。 >>523 実行前にエラーが分かるのは大きいだろ >>524 バインディングは必須ではないからそれでも良いよ >>526 なるほど。 この場合は自動実装プロパティなど不要でスッキリですな。 一応、習得しとこうかなとは思ってる。 >>524 それでもできるしバインドしてやることもできる バインドの方がハードル高め 個人的には両方できてしまうことがわかりにくくしてる要因だと思う なるほど。 質問ばかりで申し訳ないんだが、 コントロール一つごとに ・自動実装プロパティ ・ビューモデルのクラス生成 ・データコンテキストの設定 が必要であってます? 必要ではない 複雑なことやらないならWindowクラスのViewModelに各コントロールのバインディングソースプロパティを持たせればいい なお自動実装である必要はないよ というかプロパティ変更をINotifyPropertyChangedで通知したいなら自動実装ではダメ Mode=OneWayToSource以外ならgetterが必要 Mode=OneWayToSourceかTwoWayならsetterが必要 VM→Vで変更通知するにはINotifyPropertyChanged.PropertyChangedイベントを発生させる で、getterはbacking fieldを返し、setterはbacking fieldに代入しイベント発生、というのが定石 定石過ぎてReactivePropertyとかPrismのBindingBase.SetPropertyを使うと楽できる だめだ。バインドの有効利用方法がわからん。。 面倒くさい 煩雑 しか思えん。 最初はバインド面倒にかんじて コントロールに名前つけてアクセスしたらいいじゃんって思うだよな >>535 それをやめさせるには、 コントロールに直接触るのはスレッド安全じゃないってことを解らせないとダメなんだよな... MVVMバインドは確かに技術的に古く、将来はMVUに移ったほうが 記述量が減ったり、堅牢になると思う ボタンを押したときのためにCommandを用意して呼び出すなど無駄な作業でしかない クリックイベントでいい VMとVを疎結合にするのはIDEの支援が限定されて生産性が落ちる 参照先にジャンプしたときにインターフェースで実装がわかりませんでは 時間がいくらあっても足りない VMとVを別のフォルダーで管理するのも扱いづらい 最近のUIはコンポーネント化しやすくすることが必須 別のプロジェクトでも流用するとき、1つのファイルを移動させればよい状態が好ましい いちいちVMとVのファイルを移動など面倒だ とは言えMVUは.NET6まで待たなければならない それまで自分はPropertyChanged.Fodyで変更通知してる。 記述量が少なく、属性主体なので影響も少ない。 ModelはJsonシリアライザーに優しくないと使い物にならない >>226 未だにSXGAなんてザラ。 WUXGAすらない。 >>538 そうとは思わない。 特に「VMとVを疎結合に...」以降の自論は なにか勝手な思い込みではないかと思う。 MVVMでコマンドもコンバータもバリデーションルールもファイルコピーして使いまわしてるが prismとかはその辺ぶっ潰してるからやりにくくなってるだけじゃない? やっぱマニュアルのMVVMが最強やな >>529 リストビューみたいな列挙にだけdatatemplateとバインディング使って、ただのボタンとかは全部コードビハインド+非MVVMでもいいんじゃないかと思ってる 個人とかうちわ向けのツールなら >>542 意味解らずprismとか使うとコード量がふくれて 馬鹿みたいに面倒になるね。 意味解ってないから MVVMの実装はこうしなければいけないと 思い込んでる。 >>543 理解出来てるならバインディングは一切使わなくても大丈夫だね。 最速を求めるなら使うとむしろ遅くなる。 有名どころのコントロールのソース見ても 内部はあんまりMVVMしていない。 遅くない!!っ言い張ってた子の気持ちも考えてね!! >>545 まあ実際自分でやる分にはちゃんと書くようにしてるけど、winformsからwpfになって個人、内輪で便利になったのってそこくらいしかないというか データテンプレートで綺麗でリッチな表示できるよねーっていう winformsでもデータコンテキストはあったけど自分の周りのはforでまわしてリストにaddするような人達ばかりだったし MVVMだけならReactivePropertyが一番楽ちんだな PrismはUnityでDIしたりViewModelLocaterの機能や EventAggregatorなどで手放せない あと、EF使う所はBindingBaseでMVVMするな BindingはListBoxの要素では必須だから、そこから勉強始めたら覚えやすいかも >>546 たとえば1000万行のデータグリッドが必要なら、内製するし バインディングとか使わない。 仮想化とか必須の領域だし、 細かい制御が出来ないし、 結果的に確実に遅くなる。 バインディングで出来ることは 全部コードだけで出来る。 オープンソースのコントロール読めない人なら 当然、バインディングをお勧めする。 ところでコントロールを作成するレベルの入門書は 洋書でも存在してないのではないか? 自分はMSのコントロールのソースと インフラロジスティクのソースを解析して覚えた。 で、取り纏めて書籍化を考えたが 確実に売れないのでヤメたがかなり昔のはなし。 >>549 売れないことないんじゃない? VC++でカスタムドローとかオーナードロー の資料がなくて苦労したわ。 comも。 >>549 >コントロールを作成するレベルの入門書は >洋書でも存在してないのではないか? ずっと探していたんですけれど、やっぱりないんですね… >取り纏めて書籍化を考えたが >確実に売れないのでヤメたがかなり昔のはなし。 kindle 化して、とりあえず様子をみる、というのはいかがですか? 私なら(印税50% の kindle 出版に対して)10000円で買うつもりです デザイナで動くって何? ちゃんと表示されるってこと? >>553 VSのデザイナーは一定の条件下でのみ動作する。 コントロール作成レベルの作業中だと 機能しない事が多い。 そういうのはやってれば普通に解るし 察する。 わざわざコントロールで作るってことは 頬杖ついてマウスでペタペタ貼るだけで再利用できるようにするってことだよ。 コード上でnewして再利用できるだけでいいクラスライブラリとは違う。 かんたん Visual C++[改訂2版]、堀義博、2017 VC++の使い方と、画面の作り方、 DDX(Dialog Data Exchange) の仕組み、 MFCの、AFX_MSGMAP, DECLARE_MESSAGE_MAP()など MFC には、色々なコントロールの基本クラスがある。 それを使えばよい ただし、VS のGUI デザイナーが、それに対応しているかどうかは知らないけど。 それに対応するには、VS でのプラグインの作り方を学ぶ必要がある MFC使うくらいなら素のWin32APIを叩くはw >>558 いつものRubyキチガイが自分の知ってることを垂れ流しに来たんだろう >>556 それができないならコントロールがちゃんと作れてないんでしょ そしてちゃんとしたコントロールを作る事自体はそんなに難しくないと思うんだけど >叩くはw たまに見かけるけど見るたびにイラっとするこれ EventAggregatorって非推奨になったのかと思ってたけど InteractionRequestだった… 一切使ってないからさっぱりわからない コードビハインドを徹底的に避けようとするのって病的だなと思うようになった コードビハインドにあるべきコードはコードビハインドにあっていい >>566 ScrollIntoViewを呼び出すのに便利だから作ったけど、ビヘイビアで実装し直した 動くけどしっくり来ないんだよな 同じアイテムを連続で動かしたい時、一度Null入れないとダメな所が コントロールのサブクラスを極力避けるというのがwpfの方針でしょ https://devblogs.microsoft.com/dotnet/repo-experience-survey-results/ WPF was the main outlier for satisfaction. Drilling into the comments, the main concern was that PRs and issues were not being addressed by the maintainers and there was a lack of clarity on if and when they would be. Internally the WPF team was not sufficiently staffed and did not have the test infrastructure in place to be able to respond to the community contributions. dllで定義したstyleを参照する方法を教えてください こんなんだったはず 〜MyStyleLib.dll〜 〜MyButton.xaml〜 <Style x:Key="KeyMyButton" TargetType="{x:Type Button}" BasedOn="{StaticResource {x:Type Button}}" > <Setter Property="Background" Value="Blue" /> </Style> 〜使う側〜 <ResourceDictionary Source="pack://application:,,,/MyStyleLib;component/MyButton.xaml" /> <Button Style="{StaticResource KeyMyButton}"> BUTTON </Button> 入社して数年間ほぼWPFだけ使ってきて、今月初めてFormsをまともに触ったが、 DataGridViewのbindingクソ過ぎwww セルに表示する値のプロパティ名を文字列で指定できるだけで、 背景色すらbingindで表現できないとか、マジで終わってる( ̄▽ ̄) Formsの仕事が回ってくるようになった会社は潰れる一歩手前 君も○XUGに入って、「偉い人」に なろう。楽しいぞ「一般ピープル」を煽るのは タブン 来年早々にもWPFからWinUI3に代替わりするわけだが x:Bindに感動して、CollectionViewSourceの使えなさに怒りを覚えるんだろうな, >>579 WinUIはWPFに代わるものではなく、WPFなどで使うものなのだが それにしても10年ぶりの.netメジャーバージョンアップだと言うのに、イマイチ盛り上がってないな >>581 2.0まではXaml Islandで使うものだったが、3からはWPFと同格のGUIツールキットになるんだよ UWPと同じ画面だが、.net frameworkのライブラリもP/Invokeさえ使えるプログラムが実現できる >>582 Windows用デスクトップアプリ自体が下火だもの >>585 https://docs.microsoft.com/ja-jp/windows/apps/winui/ 現行じゃなくてWinUI3は2021年にリリースされる新バージョンで ツールキットがUWPから切り離されてWin32から直接呼び出せる代物になります つか、プレビュー出ているが、UWPの画面出しながらWin32のシステムコールできることは確認した >>589 はWin32環境からシームレスにUWPのAPIも同時に使えるだけだから失敗する要素はない プレゼンテーション層にUWPのガワが使えるWinUI3にしても、WPFから大きく変わるわけでもないから WPF使いなら何も問題なく使いこなせるし、新機能のx:Bindや新しいコントロールは魅力的だ やっと軌道修正したけど、その前はずっとUWPに拘ってたからな 出来るのに敢えてやらなかった期間が実の惜しい reunion やwinuiは普通に使われるようになるだろ mauiが問題 既存アプリのリプレースついでにwinformsからwpfに置き換えるメリットっていうとやっぱ苦しいよね いい加減抜け出したいけどそれに金積めるかっていうと チームのスキル具合にもよるけど、リプレースならwinformでもWPFでも工数は変わらんと思うがなぁ WPFに置き換えるメリットは柔軟なレイアウトがやりやすくなるくらいだから、 多言語化したいとか見た目をモダンにしたいとかの要求がないと苦しいね >>597 wpfの良いところは高dpi対応だよ winformでも出来なくは無いけど面倒すぎる >>598 dpi対応が必須なアプリも珍しいんじゃね? ほとんどはUIが多少ボケても使えればいいものばかりでしょ 後はテストとかかなぁ。 UIAutomationを使わなくてもVM経由の自動テストでだいたい用が足りるのがありがたい。 >>599 ピントくっきりはプログラマーとしてのこだわりさ。 言わなきゃwinformのボケには気づかれんし。 昔より拡大のアルゴリズムが良くなったのかボケも気にならん。 いつまでもWinFormsに閉じ込められてる人たち可哀想 >>599 ボケてるとユーザーからクレームくるからなあ >>604 それなら金取れるからwpfに置き換える理由にはなる ワイが客ならボケてるだけで作り直す金取られたら詐欺だって騒ぎ出すけどな 作り直すにしてもWPFじゃなくhtmlベースでだな webアプリはこのスレではないことになっている webは覚えなきゃいけないものが多いけど html, css, javascriptとフレームワーク, httpプロトコル, 他にも色々と WinFormsって海外でほとんど使われてないんだよな もう廃止でいいと思うわ 日本では勘違いしてあれに触り始めてしまう初心者も多そうだし .NET5でも生き残ってるからまだそれなりに使われてるんじゃない? 個人的にはいらんけど。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる