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 >>513
cssを上手く使ってpcでもスマホでもちゃんと表示出来るのもあるんだけどねえ。
最近はスマホだけに最適化されてるのが増えてきた。
世も末だよ。 >>518
特に大学生はスマホオンリーで、PCなんて不要
という考えが大半なんだよな。
そりゃ見るだけならいいけどよ... >>519
キーボードよりスマホのフリック入力が速いと。
オレなんてミスタッチしまくりさ。 >>515
事前バインドは．ｎｅｔ5と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はコンポーネント化しやすくすることが必須
別のプロジェクトでも流用するとき、１つのファイルを移動させればよい状態が好ましい
いちいち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. ｄｌｌで定義した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クソ過ぎｗｗｗ
セルに表示する値のプロパティ名を文字列で指定できるだけで、
背景色すらbingindで表現できないとか、マジで終わってる(￣▽￣) Formsの仕事が回ってくるようになった会社は潰れる一歩手前 君も○XUGに入って、「偉い人」に
なろう。楽しいぞ「一般ピープル」を煽るのは
タブン 来年早々にもWPFからWinUI3に代替わりするわけだが
x:Bindに感動して、CollectionViewSourceの使えなさに怒りを覚えるんだろうな, >>579
WinUIはWPFに代わるものではなく、WPFなどで使うものなのだが それにしても10年ぶりの.netメジャーバージョンアップだと言うのに、イマイチ盛り上がってないな >>581
2.0まではXaml Islandで使うものだったが、３からはWPFと同格のGUIツールキットになるんだよ
UWPと同じ画面だが、.net frameworkのライブラリもP/Invokeさえ使えるプログラムが実現できる >>582
Windows用デスクトップアプリ自体が下火だもの >>585
https://docs.microsoft.com/ja-jp/windows/apps/winui/
現行じゃなくてWinUI3は２０２１年にリリースされる新バージョンで
ツールキットが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でも生き残ってるからまだそれなりに使われてるんじゃない？
個人的にはいらんけど。 COBOLとかVBAとか、いまだに使われているのは日本だけ、みたいなことを言う人がいるが
どこまで根拠ある話かねぇ。日本で作られたわけでもないのに。 >>612
使われてなかったら.NET Core移植なんてされないよ
まあデザイナーはいつになったらまともに動くようになるのってレベルだけどね ■ このスレッドは過去ログ倉庫に格納されています
