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 デザインをデザイナと分担できるというけど、経験上ビジネスロジックと比べたらデザインの工数なんて半分以下だから分担の恩恵が薄いんだよな scrollviewerがmanipulation系のイベントがハンドラ内でe.Handled=trueによってイベントのバブルアップを止められているらしい(URL貼れないけどどっかの個人ブログ参照)から
カスタムコントロールでe.Handle=trueしないものを作りたいんだけどうまくいかない なんでtreeviewのbeforeexpand無くなってるの？
MSってよく意味の分からないことするよね 長年WindowsFormsやってきて、ようやくWPFに移行しようとしているワイのモチベーションがあがるお言葉をお願いします >>798
何かを始めるのに遅すぎると言う事は無い >>798
WPFは既にメンテナンスモードでWinFormsと同列
現在のシェアから考えてWinFormsより長く生き残ることはまずないから、もし自身のエンジニアとしての延命が目的なら今更やるのは全くお勧めできない
Webやれ デスクトップじゃWin32アプリが最後まで生き残りそう。
winformアプリも大量に有るのでゾンビの様に死滅しない。 >>798
web系技術でデスクトップアプリ作る
時代になってますよ。 mongodbのコンパスとか多分chromiumだろうけど美しいもんなー web系って流行り廃りが激しいので後のメンテが大変かも。 ３月に正式リリース。７月にフルスペックの予定のWinUI3がWPFの代替となる予定だが
特に大きな変化はないから安定すれば移行が進むんじゃねーかな？ >>808
イマイチわかってないんだけどUWPと共通化できて嬉しい？ 結局Web系ってなにやればいいの？
ASP.NET MVCとか？ 結局Web系ってなにやればいいの？
ASP.NET MVCとか？ Web APIならね。UIが必要ならそこはRazor Pagesにしときな。 >>802
Win32レベルでいいならC++/CLI以外みんな生き残るだろ。 >>803
「作れる」のレベルはだんだん上がってきているけどデスクトップフレームワークの域にはまだ遠いよなぁ。
BlazorでWPF動かせるようになったらいいんだが。 >>817
Blazorはjs書けない層の
救済ライブラリーですよ。 >>818
Cはアセンブラ書けない層の救済言語、みたいな？ >>819
ちょっと違うかな。
js<-->c#のラッパーライブラリーになります。
なので遅くて機能も少ないです。 そういう話じゃなくてね、>>818はC#よりJSの方がハードルが高いと言いたいのかってこと。 >>821
それは人によりますね。
>>819
アセンブラ書ける層にもｃ学ぶメリットがありますが、
（ｃはアセンブラ書けない人の救済目的でない。）
jsでwebアプリ開発者出来る層が、
Blazor学ぶメリットは無いって事です。 >jsでwebアプリ開発者出来る層が、
>Blazor学ぶメリットは無いって事です。
つまりWebアプリの方がハードルが高いって言ってるんだろ？ webアプリメインでやってりゃ
デスクトップアプリ開発なんて未知の領域だし
逆もまた然りでしょ。
つってるうちに、
web開発者がそのスキルの延長で
デスクトップアプリ作り始めてるって時代に
なっちゃってますけどね。
因みにスマホアプリも業務系は
かなりの部分的がwebView使った
webアプリですわ。 結局デスクトップアプリやりたかったら何勉強したらいいんだよー UWPはいいね
この前ストアアプリ配信したんだけど結構ダウンロード数伸びてる大したことないアプリなのに
まだマイクロソフトストアが未成熟だからね
すでに飽和してるApp StoreやGoogle Play Storeじゃこうはいかない
マイクロソフトストア狙い目よ Web(React)もデスクトップ(WPF)もやってるが、だからといって今のReactで
デスクトップアプリ作る気にはなれんな。
>web開発者がそのスキルの延長で
>デスクトップアプリ作り始めてるって時代に
自分が持ってるスキルで他分野に入り込みやすくなったから
喜んで使っているんだろうが、これから新しくデスクトップアプリを
始めようって人に勧めるのはちょっと違うかな。 趣味の開発なら良いが業務用アプリでUWPを使おうとは思わんな でもさ趣味と業務で技術を使い分けるのも非効率じゃない？ 趣味はある程度妥協できるけど、業務はそれができない >>833
業務用には枯れたものを使いたいねえ
最先端も追っかけなきゃ技術者としては終わるけど マイクロソフト環境にどっぷり漬かっている会社ならビジネス向けストアを使う手もあるだろうが
IT部門が全社に配布する手間を減らせる以外のメリットが思いつかんな。
まさか常にサイドローディングしてもらうわけにもいかんだろうし。 新規だとWPFですかねえ
winformよりはUWPへの乗換ハードルは低いし
webじゃ無理なアプリもあるし デスクトップ ExcelVBA
Web スプレッドシートGAS 今から投資するなら
.NET MAUI
かな。xaml + mvvm が糞すぎた。 全く詳しくないんだけどWINUIは糞なところは改善されるの？ 良く判らんが、ザマリン下位のskia
をGDIでラップ出来るようになったの？ UIがどうなろうとIPropertyChangedは全部書かないといけませんか？ >>843
必要でしょう
ReactivePropertyとかBindableBaseを使えばコーティング量が減る うーん
プロパティにref使えないけど
SetPropertyどうやって使ってんの？ xaml登場時からやってる
ベテランの自分でさえ
xaml流mvvmは
コード量が激増して面倒臭すぎる。
ReactのJSXみたいに
xaml中にコードが直接かけるように出来んものか？ <x:Code>で囲めばゴリゴリC#書けるよ
面倒だから素直にコードビハインドに書いた方が早いけど
どうせg.csにコピーされるだけだし
まあ何につけmvvmが失敗の原因だったよね 失敗というか、WPFに挫折した人の原因ではあるのかもしれない。 VisualStateManagerはBlend前提の設計かもしれんが、ちょっと解りにくいわな MVVMってテストしやすいのはいいけど、設計難易度上がるし面倒なところあるから初めて関わる人や新人いるチームだと大変すぎてな。一人や少数精鋭チームでやれればいいけど。 ビューとモデルの完全分離を目指した結果
肥大化するコードと失われる可読性って本末転倒じゃん >>849
xamlてコード分離が目的なのに中にコード書いたら意味無いような気がするが >>855
コードを分離する
メリットとデメリットは？ >>856
メリット、ユニットテストがやりやすい
デメリット、めんどくせー >>857
ユニットテストは
やりやすいレベルにはならんよ。 model view を結合するのはいいけど、、
model もうひとつつくって、プログラムされたタイミングで
同期させたい
isDirtyな
double bufferともいう INotifyPropertyChanged実装しないModelクラスを、ViewModelでラップするのがしんどい。 mv結合100%だから不自由なんで、
設計でいうmodelとは別に
実装用のmodel作るべき
設計modelは切り離して
change by user
change by initialize
change by signal
も判別しなきゃだな >>863
mvvmを捨てる事から初めてみましょう！ >>854
俺の言いたいことをすべてお前が大便してくれた >>861
FormsアプリをUIAutomation使って自動テストする地獄を味わったことのない人には
有難みがわからないのだろうな そもそも>>858はユニットテストがなにか知らんような気がする
マニュアルに従ってテキトーにポチポチクリックして落ちなきゃテスト終わりーとか言ってそうw >>870
今時ICサーバー必須と言われてますわ。 ICサーバーってなんだ？
まさかと思うけどCIサーバーのことじゃないよな？w >>870
俺は>>858じゃないけど、
マジ、おせーて
assertとか使う奴？
それともGUI上で出来るようなのがあんの？ >>855
ビジネスロジックコードの分離が目的なのだから、デザインコードは一緒になっている方が良いかも Javaでオブジェクト指向が流行った時期の間違いみたいに
大規模開発専用のクソ仕様を銀の弾丸として全部に使おうとして失敗してる感じに思える アニメをデフォルトで使う分にはxamlってそれほど複雑でもないんだけどね
formsと同じことやるなら UI作る人と分業できるって言うけどどんだけ凝った画面にすんだろ。
結局はコード書く人が画面まわりもやってね?
最近違うの? 専業のUIデザイナー雇ってるとこなんて余程の大手だけだろうな xaml書く専業デザイナーって聞いたことないけどいるの？ UIとコード別けられるのが最大のメリットという位だしな。
居ないとおかしいがな。 誰が言った言葉かは知らんが、少なくともUIデザインを別担当者にできるのが
最大のメリットだということじゃないと思うぞ。 俺個人としてはxamlでレイアウトしやすいところとmvvmでテストしやすいところかな。 デザイナーがHTML/CSSで作ってプログラマーが同じ見た目になるようにXAML書く デザインとプログラミングの分業においては遥かに先を行っているはずのWebでは、
最近は逆にJavaScriptにインラインでHTMLを書いているのでした >>885
初めからデザイナにXAMLで書いてもらったら? >>887
XAML書いてくれるデザイナーなんているの？ 作業としてUIとコードを分けられることがメリットじゃなくて
そこが疎結合になるからいいんでないの 疎結合になること自体はメリットではない
疎結合になることで何がメリットになるか書かないと
結局、分担作業やデバッグが楽という話に落ち着くと思うが ■ このスレッドは過去ログ倉庫に格納されています
