WPF(.NET4.x, .NET Core) GUIプログラミング Part24
レス数が1000を超えています。これ以上書き込みはできません。
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 通知領域常駐アプリ整備士
「80パーセント？冗談じゃありません。現状でアプリの性能は100パーセント出せます」
シャア
「ウィンドウは付いていない」
通知領域常駐アプリ整備士
「あんなの飾りです。偉い人にはそれがわからんのですよ」 WPFもWindows 7 SP1 .NET Core 3.1(LTS)の最終環境に到達したな >>8
MSは、UWP から、Win32アプリの方に戻ってきていると書いている人がいた。 >>13
MSの取り巻きって内輪ノリが酷くてキモいんだよなあ
MS系スタックはなまじ一貫性があるから変な空気が醸成されやすい 結局、今 windowsのexeアプリを作る時、UIは何で作ればいいの？
wpfは機能追加全然ないし。プレースホルダー付きのテキストボックスすら無いし(追加されたらすまん) https://github.com/Microsoft/Xaml-Controls-Gallery
これとか落としてみたけど、相変わらずスマホで使って欲しいのかmenu itemやボタンとかのテキストにことごとくマージンついてるし
マウスで操作したいからマージン0でいいし、表示のアニメーションも全部いらん OSSが主流の時代になって各陣営はどれだけ優秀な貢献者を集められるかのがキモなんだが
windowsのGUI は全然人が集まらないので全然何も進まない
WPFはコントロールを提供するのがめんどくさいのでこれからも流行らない その他すべての陣営
react.js vue.js python PHP ruby RonR べつにWindowsデスクトップが特に好きなわけじゃないけどJavascriptは無茶苦茶嫌いなのでGUI全部がHTML5で動くような世界にはならないでほしい
MSはほどほどに頑張れ vue.jsとかのjavascript系フレームワークはwpfのMVVMの影響をかなり受けてるよ。 >>17
楽したいならWebでやりなはれ
工数いくらでもかけられるならWPFでもUWPでも、できないことはほぼない >>23
Javascriptそのものが嫌いなんだよ
MVVMであろうがなかろうがJavascript死んでも触りたくない 今だとUWPもWin32もWindows UI Libraryにまとめてく方針なのかねえ
まああれもﾁｶﾞｳｿｳｼﾞｬﾅｲ感凄いけど コントロールをWinUIにまとめてくれることはいいことじゃね？OSSにしてOSのアップデートと切り離して、更新とか頻繁にしてくれてるし。
少なくとも前よりマシじゃないかな。
>>17
Windows だけなら、.NET じゃないの？
web 系なら、HTML, CSS, JavaScript で、
VSCode は、Electron 製
Redmine は、Ruby on Rails >>29
いかにプロダクトの思想が正しかろうが、思いつきでUIフレームワークを量産して次々に見捨てていくことこそが最低最悪の害悪 Blazor流行ったらいいけどセキュリティ的にActiveXの二の舞になりそう >>32
昔、ネスケとMSが法廷で争ったとき、MSの懸念の1つはブラウザがOSの支配的地位を奪ってしまうことだったらしい。
ブラウザが有れば、どのOSでも同じ結果が得られてしまうため、どのOSを使っても差がなくなってしまう。
それはちょうど、WindowsOSをインストールしてしまえば、アプリ環境としては、PC-9801とPC/AT機の差がなくなってしまうので、オープン化で安くなったPC/AT
機が売れてしまったことと似ている。つまり：
・Win/Mac/Linux/iOS/Android と ブラウザの関係
・PC・AT/PC-9801 と Windows の関係
に対応関係がある。
何が言いたいかというと、Blazorが普及してしまえば、Windowsが必要なくなってしまうため、MSの安定収益が1つ無くなってしまう。
そうなれば、Googleは検索エンジンが安定収益になっているのと対照的だから、Googleに負けてしまうことになる。 >>33
一つ考え忘れていることがあった。それは：
Blazorアプリを動かすにはWindowsは必要ないが、Blazorアプリを開発するにはWindows(またはMac?)が必要だということ。
これがあるのでBlazorの発展はMSには問題にならないかもしれない。 >>34
ただ、Blazorアプリの開発がWindowsでしかできなくても一般人には全く関係ないが、プログラマの数と一般人の数は、1:50 位なので、Blazorアプリの普及はWindows離れを起こす可能性はある。 >>35
1:50 ではなく、1:300 くらいかもしれない。 >>34
WindowsとMacでほぼカバーできてるだろ
別にLinuxでも開発できるし BlazorをWebに乗りそこねたドットネッター達の救世主みたいに持ち上げてる人多いけど、
BlazorってReact系のプログラミングモデルでHTMLもCSSもバリバリ書くんやで
これ使える人なら普通にReactやVue使えるだろうし、単にそこに選択肢が一つ増えただけのことでしかないよ >>39
javaScript書かなきゃいけない量は格段に減るっしょ。それが何より。 >>40
君にとってはJSを書かないことが重要なんだろうね、それを否定する気はない
・HTMLやCSSはバリバリ書ける
・しかも出来合いのJS製のコンポーネントに頼らなくても余裕なハイスキルフロントエンダー
・しかしJSやTSは絶対書きたくない
・だがC#は得意
こんな君みたいな奴がどれだけいるだろうねw あとBlazorでJS書く量が減るのって、クライアントコードをC#に置き換えたからというよりは仮想DOM技術の恩恵が大きいと思うよ
Blazorが多くのドットネッターにとって革新的に感じるのは、
彼らが仮想DOM系フレームワークに始めて触れたのがBlazorだったからじゃないかな
SPAだから全部JSで書かなければならないとでも思ってるなら別だが >>41
javaScript絶対書きたくないとか誰も言ってないやろ Blazor に親でも殺されたんだろ
すでに拗れてるみたいだしスルーしといた方がいいよ 今のBlazorのプレゼンテーション層はRazorのままだから仕方がないが、Blazorに期待してる人は
WPFまで移植してくれることを夢見てるんだろう。
ClickOnceが使えなくなる前になんとかしてほしい、と俺も思う。 JavaScriptは絶対悪だからな
それを根絶できるという理由でBlazorに限らずWebAsm由来言語は期待されてる >>47
現状だと根絶はできないけどマシにはなるよねって感じ jsに触れた途端いろんなものが腐りだす
それを正そうとしたtsですらすでに腐れがとまらない WPFもjsも死にプロパティ多くない？
あ、これもあのクラスと同じプロパティあるじゃん
よし、じゃこうやってセットして・・・アレ？効かないよ？
？？？：ブブー、このクラスはそれじゃできませーん
↑作った奴、腹、切れ WPFのオリジナルの開発チームはとっくに全員クビにされてそう
WPFのCore移植でも作業してたのほとんど外注だったから、実際には外に丸投げしてたのかもしれないけど >>52
なんでだよ
htmlもそうだけど
存在するにも関わらず死にプロパティ多すぎだろ
せめて効かないやつ削除しろや 言語にそういう機能があればいいんじゃね？
って思うけどね この前まで6のドキュメント置いてあっただけだから
見出し書くていどのやる気は出たってことかなｗ メルヘンだね〜
WPF, Prismの情報が少ないのに本家までこれじゃぁハードル高いわ 複数のVisualBrushで重ね塗りする方法を教えてください VisualBrushの足し算みたいなことはできないということですかorz google playにあるUno platform製の電卓アプリUIが重すぎ。xamarinと同じで絶対流行らん そういう流行らんもんがいっぱい出てきて淘汰されて良いもんが出てくる
良いもんだけを出すことは不可能
だから糞が出てくること自体を否定する意味はない
業務でその糞を使えと言われないことを祈るのみ ためそうかとしてたがUno重いのか……
まぁいらってみるか みんないつかは、Brazorに行ってしまうん？ WPF捨てて WPFよりBlazorのほうが未来あるしそうなったほうがいい WPFとBlazorは排他的なものじゃないと思うが。Razorのことか？ Blazorは結局Webのスキルセットが必須だからWPFの比較対象にはならんだろう
この期に及んでクライアントアプリに固執してるような奴がBlazorのためにCSSの勉強とかすると思うか？
百歩譲って勉強するとしても、だったら普通にWebへ行くだろ >>73
Blazor for Native次第だね Blazorっていうかデスクトップアプリは捨ててWebアプリに移行するよ。 10年くらい前からそんなこと言われていてずっと環境が揃うのを待っているんだが、あと何年かかるのかね。 WPFは15年経っても流行らなかったがまだこれから来るとか抜かしてる奴がいるし
言い続けている限りは負けじゃないのさ(彼らの中では) Browser+RazorなのにBlazorっておかしくね？ Brazorと呼ぶべきなんじゃ？ >>78
Lの方がかっこいいやろーとか言ってなかったっけ？ >>73
C#案件が広がりを見せるという結果が期待されてるんでしょう C#で全部やりたいとかのニッチ向けに感じる
Webに移行するならコミュニティ、情報などの面からもクライアント側は素直にJS/TSでやった方がいいし
デスクトップGUIに価値を見出すならブラウザ上ってだけで欠点になる >>82
作れる。世界最大(?)のCADメーカー AutoCadがWasmを使ってWebアプリとして移植したとされている。
Wasmの例：
https://yutakaaoki.github.io/ >>83
毎度思うがもうちょいマシな見た目のサンプル紹介したれ photshopもあるし3Dもブラウザでできる
逆にブラウザでできない分野ってある？ >>86
実は、ローカルPCのファイルシステムに上手くアクセスすることがデフォルトでは出来ない。
ローカルPCにファイルを保存することは出来るのだが、ブラウザ(Chrome)の特殊な
データ領域に保存されてしまい、c:\ のディレクトリ内容を取得したりすることはブラウザを特殊なオプションで起動しない限りできないようになっている。
>>83 でdemo1などを起動してファイルメニューのOpenやSave As は少しトリッキーな特殊な方法でやっているが、自由自在にファイルを読み書きできるわけではない。 >>87
すまん、途中で書き込んでしまった
それは流石にautodeskに聞いてくれ >>90
「バックエンドが必要である」ことは正しい情報？？ >>91
すまんがそれもautodeskに聞いてくれ
とりあえず単体では動かないみたいなので何ら名のバックエンドはあるはず
ライセンス認証だけかも知れんが >>92
もしかしたら、それとは意味がずれるかもしれないけど、少なくとも、データ保存のためには、クラウドというか、リモートのサーバーにデータを渡す必要があるかもしれない。それはWebアプリはローカルPCのファイルシステムには容易にデータを保存できないから。 >>88
DTMのようなリアルタイムかつ低レイテンシーが重要な分野は厳しいんじゃないかな ローカルPC に、Node.js, Ruby などのサーバーを立てれば、保存できる
VSCode は、Electron 製 = Node.js + Chrome。
Redmine は、Ruby on Rails 製 >>95
ElectronはNode.jsのモジュールとしてChromiumエンジンを組み込んでおり、決してHTTPサーバーを立てている訳ではない
あとRedmineみたいなゴミとVSCodeを一緒にするな cgiが使えるLocalServerを起動していれば、cgiの仕組みを使ってローカルファイルシステムに自由にアクセスできるようにはなる。
また、この仕組みを使えば、WebアプリからローカルOSのあらゆる機能が使えるようになる。 RubyやPython, node.jsなどはどれも cgi server として起動することも出来て、
さらに、cgiを書くスクリプト言語としても使える。
そしてほぼあらゆるプラットフォームで動作する。
だからそれらを利用すれば、理論上は1つのcgiスクリプトであらゆるプラットフォームでOS固有のファイルシステムにアクセスすることが出来る。
>>99
まあ、悪用すればそうなんだけども。 linuxなどではルートフォルダを自由に指定してある階層から出られなく出来るけど
winはそれがないからちゃんとフォルダ指定内容をチェックしてないと単なるセキュリティーホールになる cgi serverとWebアプリを組み合わせたツールキットを作れば、それだけでnativeアプリと同様の機能を持ったマルチプラットフォームツールキットになるかも。 >>101
native アプリではそもそもどんなフォルダにもアクセスできますので、それを持ってセキュリティーホールとは言えないと思います。 >>92
悪いが、個人でAutodesk規模の開発
をする気は無い。っうか無理だ
ライブラリーも含めてそういうものを
開発出来るベースが無いという事で納得した。 ブラウザで動作するCADソフト開発する上でのベースが無い
という納得？
ブラウザアプリもデスクトップアプリも変わらんと思うけど >>94
MIDIやSynthesizerのWemAppli、Wasmに関する話らしい：
https://twitter.com/DasSurma/status/1217129248038670337
遅延に関しては、Webゲームを試してみる限り気が付かない程度だった。
https://twitter.com/5chan_nel (5ch newer account) >>106
他にも色々あるけど、例えばこんなものがある。
スライダーを動かすと音が変わる。
これで遅延のほどは分からないが、遅くて使い物にならないようなものではないことは分かる：
https://csound.com/wasm/Sliders.html アクション性の高いfpsゲームなんかもブラウザでゴリゴリ動く時代にそんな遅延なんて気にならんと思うけど…
マイクロ秒単位まで求められるならしんどいが 告白しますと、以下の簡易テニスゲームはモバイル機器では音ずれが起きるのですが、それは、HTMLのaudio要素を使っているからで、HTML5のWebAudio技術を使えば直ると思っています。
実際、ちゃんとしたWebゲームでは音ずれは起きていません。
https://yutakaaoki.github.io/demo_tennis/ >>109
なお、そのサイトとはWebGLを使っており、WebGL 1.0はOpenGL 4.1から正式対応したので、OpenGL 4.1以上に対応したGPUでないとがたがたすることがあります。
Intel CPU内臓の Intel HD Graphics というGPUは、初期バージョンのものは OpenGL 4.0
までの対応なので、WebGLを使う場合に Chrome79 ではハードウェアアクセラレータが使えません。 >>108
> マイクロ秒単位まで求められるならしんどいが
まあそこまで求められたらデスクトップアプリでも厳しいと言うか汎用OS上だと無理じゃね？ >>111
うん、そう思う
なんでブラウザアプリでできないことってローカルファイルへのアクセス以外はあんまなさそうな感じする
まぁ細かな面倒くささとかはもちろんあるけど不可能ってわけではないしね 画像上でラバーバンド描画しようとすると
最低でも10fpsぐらいで画像送信する事に
なるけど、Webで出来る？ >>112
Chrome限定になるけど、Native File Systemなるものでローカルファイルシステムが自由に使えるようになる。
ただし、デフォルトでは無効化されているので、
chrome://flags/#native-file-system-api
でEnableにする必要がある。
また、これは、HTML5 の File API とは別。
そっちの API では、ブラウザの特殊な記録領域にファイルが格納されてしまう：
https://qiita.com/pentamania/items/ada07c45d4e5cc139c03 >>113
ローカルPCでJavaScriptやWasmを使ってグラフィックを描けば、ネット回線を使った画像の転送は要らない。 >>99
ローカルにcgiサーバーを起動してローカルFSを使えるようにする場合、そのままだとあらゆるHTMLアプリがローカルFSを使えてしまうようになってしまうためセキュリティーホールになる。
それを防ぐには、ポリシーファイルというものを作ってその中に親となれるHTMLアプリのローカルディレクトリ名を列挙しておいて、それ以外の場所からのHTTPリクエストは禁止するようにすれば良いと思う。
CGIのHTTPリクエストのヘッダの中にOrigin: URLアドレスという項目があるので、それを利用して判定することが出来る。 blazorだかよう知らんがHTML/CSS嫌いの俺には
究極の選択になりそうだ。
C#+BlazorでHTMLさわるか
クソ言語のDart+Flutter
究極の選択
Flutterで一本アプリ作ってるが.. まぁ、去年はFlutter三昧だったけど、Dartのクソにもなれたし。Flutterの豊富なWidgetは最高。 >>116
撤回。
HTTPリクエストのOriginもRefererも偽装が可能なのでその方法だとやはりセキュリティーホールになると思う。
対策は、公開鍵、秘密鍵の様な方法を使えば可能だと思われる。 >>119
クライアントの偽造を心配するならLocalServer側で変な所を読み書きしようとしてないかをちゃんとチェックして必要に応じてエラーを返すように作るべし >>100
UWPだとそういう抜け道をつぶすためにローカルホストへのソケット通信が出来なくなってる AF_UNIXまで潰されている事に気がついた
時には殺意が湧いた。
どんなメリットがあるんだろう？ >>102
そしてアプリの数だけlocalサーバーを起動しておくんですね ローカルのTCPサーバーなんてIPCなどで普通に使う
お前が思っているほどダサい発想ではない Socket を使えば、簡単に local server が作れることがわかった。
cgi や html を扱う HTTP (プロトコル)も、基礎はTCP/IPで、
それが socket を使って行われる。
socketは元はUnixのもので、WindowsでもWinSockが、ほぼ互換性があるとされる。
Javaでもsocketは使えるのでAndroidでも使えると思われる。 >>124
理論上は、local serverは一つ起動しておけばよい。
native file systemへのアクセスは、そこから呼び出されたcgiが担う構造となる。 >>126
元はBSDの AF_UNIXで同一マシン内の通信用
それをネットワーク対応にした。
その名残がinetd cgi側が作り出した10桁くらいの乱数を、cgiを使いたいWebアプリ側に入力する
事で認証にする方法を思いついた。
JavaScriptでもnativeのクリップボードの内容をペーストできるので、ボタンを
押しただけでこの動作を自動化することも出来る。
ただし、それをするとフィッシングされてしまうことがあるので、cgi側がメッセージボックス
を出してユーザーに確認することが必要だと思われる。
または、cgiとWebアプリを組にして配布し、両方に公開鍵と秘密鍵を埋め込んでおき、
乱数に対して正しく応答できるかで相手確認をする方法も思いついた。 socketのaccept()関数には、通信相手のIPアドレスが分かる機能がある。
ブラウザにはhtmlをlocalにコピーする機能がある。
localに保存したhtmlである場合のみ、native file systemへのアクセスを許可する
ようにlocal serverを作ることも出来るかもしれない。
悪意サイトをlocalに保存する人は少ないだろうから。 >>131
で、長々と書いてるそれWPFと何の関係があるの？ Blazor Server、Webasm、PWA、Hybird、Nativeと開発の選択肢が充実してきた
FormsもWPFももうおしまいだ
俺が言ってた通りBlazorだけでおｋになる日も近い まともな書籍とプロジェクトテンプレート
が出来たら考える UWPで非sandbox環境がくるらしいけどいらね BlazerはSilverlightと同じ道を辿らないの？
(´・ω・`) >>138
業界標準とされているWebAssembly吐くから大丈夫だとは思うけど諸行無常の世界だからな
セキュリティインシデントでブラウザがサポート終了する未来しか見えない Windows7のサポートも終わったし、WPFは爆発的に普及する予感。 しかしwinformを15年以上使い続けてる奴が一番の勝ち組だな。Windows界のコボラーだね。 winformでも高dpi対応ではあるけど注意事項が多すぎてオワコンだよねえ 嫌ぁWPFってWindowsAPIから遠いでしょぅ
例えば、WORD/EXCELの保存ダイアログの
上部のディレクトリ指定ツールバーに
SendMessage送ってディレクトリ変更出来る？ ポトペタでGUIをでっち上げるスピードはForms最強だよね。 >>147
それWinFormの方が楽とかあるっけ？ >>150
formのコントロールならSendMessage
で大概okでしょ >>153
> 例えば、WORD/EXCELの保存ダイアログの
> 上部のディレクトリ指定ツールバー
の話だよ？ >>154
winapiはwinformとは関係ないだろ WPFよりもWinFormのテキストが圧倒的に多いから取っ付きやすい MSDNにWPF関連のドキュメントたくさんあるやん まぁ良く言って汚物溜め。
探しても探しても、ろくな情報が出てこない msdnは嘘は書いてないのだろうけどかなり分かり辛い 間違いを指摘しても修正されなくなったし、スナップショットも出なくなったし、
ドキュメント保守部門が丸ごと消えたんじやねーの。
担当の開発チームが自分勝手に編集してるだけのように見える。
OSSの悪いところをマネ もうMSにとってITドカタは客じゃないんだよ
いい加減気付け そういう意味ではAzureとOffice使ってくれるのが今のMSの「顧客」だろうな ライブタイル使ってないもん
スタートメニューに張り付けられるのは便利だけどアイコンあれば充分だしな… >>171
OSSを推奨した人が多かったので、OSSが台頭。
それまでプロプライエタリソフトは、買った人の利便性を考え、
必ずしも営利にとらわれず親切心からマニュアル類を整備してきたが、競争上
OSSに勝たなくてはならなくなったので、親切心だけでは
どうしようもなくなって、利益を生まないなら放置されるようになった。 >>176
もう一つは、OSSの台頭によって、MS以外のプロプライエタリの開発環境が死滅または弱体化してしまったため、MSの競争相手がプロプライエタリの開発環境ではなくOSSの開発環境となったため、マニュアル整備もOSSと同レベルにまで水準を落とされた。 今のCEOのナデラやろ
その前のバルマーまではOSSを敵対視してた 昔と時代が違う
Ruby による今世紀最大の起業家、Vagrant の作者・Mitchell Hashimoto(HashiCorp)だろ
その後、Docker, Kubernetes。
RedHat が、CoreOS を買収、MS が、GitHub を買収
今は、OSS からしか、富を産まない オープンソースからコードパクればcoplandやEdgeのような失敗はしないし、
開発費を抑えれるから利益が出るという話ですね。
IT業界全員ジョブスですね。搾取されるはPGだけ。 OSSを使えば、みずほ合併も20年も
かからなかったという事ですね。 wpf はComboBoxのカスタマイズが異常に面倒
TextBox部分の背景色を変えたいだけなのに、どれだけコードを書かせるのかと
最終的にはComboBoxの上にBoarder挟んでTextBoxを重ねたわ スタイルの一部分をちょこっと変えたいだけなのに
スタイル全書き換えだからなあ
バージョンアップでスタイルに手が入ったら追随しないとまずいし… >>188
もう死に体だけどな
ほそぼそと延命措置されてるだけだから、早々にPrismに乗り換えた方がいい livetはいまokazukiさんとかがメンテしてるみたい >>192
okazukiさんだけじゃね？
PRとか来たらそれの対応するような程度だけだから、もう死に体よ prismよりlivetが得意なことってどういうところ？ >>196
mahappをヌゲットで当てれば一応それっぽくはなる >>194
昔見た感じだと、ビヘイビアが充実していたから、そこだけ使うのもありじゃね？ >>194
日本製だけあって日本語での使い方がすごく豊富
prismのregionとかみたいに「そこまで高尚なのはいらないな」みたいな使い方には最高 prismもOSSになってから標準機能だと思って使ってたものがごっそり消されたりするから怖いけどね… 今のprismは有志数人がやってるコミュニティプロジェクト
機能の取捨選択などはMSの推奨とかではなく、あくまでメンテナの個人的な好みに過ぎない
もはやまともな旗振り役はどこにもいない PackageReferenceでPrism.UnityをぬげっとしたプロジェクトをVisualStudioインストーラーでインストーラーを作成
そのインストーラーでWIndows10にインストールするとエラーでViewが立ち上がらない
Packages.configでぬげっとすると問題ないんだけどPackageReferenceが地雷なの？ >>204
そういうの有りそうw
インストーラの依存関係から漏れてるかな? ScrollViewerの最小サイズを指定する方法を教えてください ねーねー
教えて欲しいんだけど
C#で記述すると
sender is Button b
のような is を、C++/Cliで表現すると、どのように記述するの？
※is なければ dynamic_cast で判定したりするん？ >>207
b::typeid かなあ
ぼーっと生きてるんで分からん >>209
ありがとうございます。
マクロかテンプレート組んでみますわ Linuxで使えんのかこれ？
メンテナンスの依頼が来たんだが、おうちにWindowsないからお勉強できないんだが .NET coreだとだめなの？
やりたいことが出来るかは知らんけど >>214
WPFは.NET coreでも動くけど、Windows専用
Linux+.NET coreじゃ動かない >>215
そうなんだ、ごめん
よくわかってなくて失礼した どこに保守頼んでも断られて無知な犬厨が受けてしまったか。ご愁傷さま。 今更WPFアプリのメンテとか絶対やりたくないな
今時Winクライアントアプリって時点で苦痛なのに、もはや覚えても何の役にも立たないオワコンフレームワークとか地獄すぎる
全力で逃げた方がいいぞ あとはWebかスマホかな。個人的にはそっちの方が制約が大きくて苦痛だが。 >>220
代替できてないじゃん
Windowsがなくならない限り、そのクライアントアプリの仕事もなくならないと思うが 部署内ツール程度の小規模開発ならWinFormで事足りる オフィスのPCで4k普及なんてあと10年先じゃないかな。2k普及だって怪しい。 実行ボタンと中断ボタンがあるよくある仕組みだと現状何で作るのがベスト？ WPFスレなのでWPFとTPL
で、CancellationToken使う 計算プロパティをOneWayバインディングしたのに反応しないぞ
バグか？ int A
get a
set a = value; RaisePropCh("A")
int B
get A * 2
こんな感じなんやけどAに入力してもBが変わらんのや >>234
端折られてて良く分からないけど
Bの変更を通知してないのかな RaisePropCh("A", "B")にすればええのんか
でもBがAに依存しとるという情報をAに書かなあかんてなんか気持ち悪いねん >>237
Aの更新通知(INotifyPropertyChanged.PropertyChangedイベント)を監視して
Aが更新されたらBの更新を通知すれば良い
AとBが同じクラスなら気にしないで良いと思うけど >>238
RaisePropertyChangeじゃろ
あんな書き方しないけど、それでも分かるでしょ WPFがもし大成功して今でも新機能開発が続いていたら、Reactみたいにプログラミングモデル上は脳死で全更新するだけでよくて
フレームワークがうまいこと差分取って効率的に更新してくれるようになってたのかもね >>237
そんなあなたにReactiveProperty…(´・ω・｀) RactivePropertyはObservableCollectionとsynchronizedできないやん 解決策を発見したで
プロパティ名をnullでRaiseすれば計算プロパティもええ感じにバインドされるみたいやわ 今windwosアプリ作るのならどういう環境がいいわけ？
めんどくさいからみんなelectronに移行してるんだが edgeが標準プラットフォームになったんだから
そろそろhtaのver.2をリリースしてください Blazorって.NETランタイムをWebAssembly上で実装？
MS何考えてるんだ BlazorはMSのR&Dの社員がお戯れに作ったもので、戦略もクソもない
アイデアとしては面白かったが既に下火だし、最終的に似たような技術が天下を取ることもあるかもしれないけどそれは多分Blazorではないよ Blazorは色々計画しとるみたいよ
とりあえず.NET 5になってからだな デスクトップアプリはMSがやる気なくて、これと言ったのが無いよなぁ
消去法でWPF使ってるけど >>253
SignalRとかも元々お戯れだったけどな まあもうネイティブアプリの時代じゃないんだろうけどね
ゴリゴリにWin32 API書いてたのが懐かしい >>250
electronはJavascriptだから駄目 silverlightにはならないで欲しいなblazor Blazor黒魔術感やばいけど
なぜC#なのか
TypeScriptならワンチャン覇権あったのに JavaScriptに触れる機会が減るだけでも嬉しい >>261
禿同
Javascriptを駆逐してほしいわ TypeScriptならそこまで毛嫌いするほどかな
それにJavaScriptのクソさって言語もさることながら主にDOM操作が問題なわけだけど、
Reactみたいな最近のフレームワーク使うならDOM操作は完全に抽象化されていてテンプレートで宣言的に書けるようになってるよ
BlazorでDOM触らなくていいのはReactと似たアーキテクチャになってるからで、
言語がC#だろうがDOM操作をもし生でやるなら下痢便みたいなコードになるのは違いない >>264
Blazorで下痢便みたいなコードってたとえばどんなの？ >>260
MSILがブラウザ上で動くってのがBlazorのポイントだろ。TypeScriptはもとからトランスパイルできるじゃん。
WASMがポイントだというなら動的なJSやTSは今のところ無理だね。 C#で下痢便書くような奴なら
JavaScriptではどんなに美しいコードが書けることだろう マイクロソフト、新UIフレームワーク「.NET Multi-platform App UI」（.NET MAUI）発表。単一コードでマルチプラットフォーム対応。Microsoft Build 2020
https://www.publickey1.jp/blog/20/uinet_multi-platform_app_uinet_mauimicrosoft_build_2020.html > In addition, we are enabling developers to write fluent C# UI and implement the increasingly popular Model-View-Update (MVU) pattern. MVU promotes a one-way flow of data and state management, as well as a code-first development experience
ついにMVVMも時代遅れのゴミになったな
モデルとしてはReactに近い？
そしてもう名前すら出てこないWPF Blazorで統一ならまだ勝ち目はあったかもね
まあまともに今のWinUI系のXAMLを使い込んでるのなんてMS自身くらいだろうし、
広く使ってもらうというよりMSが自分で使う目的が主なんじゃないかな >>273
ローカルのリソースやデバイスへのアクセス制限がウザい >>272
MVUってMVVMの進化系っぽいけど
コーティング量が減って良さげ one-way bindingだからMVVMとは根本的に別物でしょ
Webで流行りのいわゆる仮想DOMってやつで、更新の度にテンプレート当ててUIツリーを全部書き直してdiff取りゃ実際に画面に反映させるべき差分は分かるんだから、
なんちゃらPropertyChangedとかいちいちプロパティ毎にクソ煩雑な低レベルな制御しなくてもいいだろ
って思想だ 今にして思うとPropertyChangedってサイコーに頭悪いアイデアだったな いやいや、今までのMVVMと大差ないから...
アプリ分割方法は今まで通りモデルとビューとビューモデルに分割して問題なし
単にフレームワーク提供の双方向バインディングがなくなったから、ユーザーイベント発生時にコードビハインドでビューモデルのメソッドを呼ぶようになるだけ...
基本は単にそれだけ。後はxamlという専用の言語使わずにレイアウトを宣言的に記述できるようになるだけ。これは、厳密にはMVなんたらとかアーキテクチャと関係ないだろう >>279
VとVMの間の分離が皆無な時点で全然違うと思うが あと、勘違いしてるようだがイベント発生時にはコンポーネント(たぶん279のいうVM)自身のステートを更新するんじゃなくてMを更新するんだぞ
その結果としてビューの更新が走ってbody関数が呼ばれて画面に反映されるというのが本来の流れだ
サンプルコードではそのへん省略してコンポーネントに直接ステートを持たせてるようだが、原則としてはコンポーネントは可能な限りステートレスにするんだよ
もちろんコンポーネントはVMみたいにMのプロパティを猿のようにラップする必要もなくて、究極的には単純にMを入力したらDOMを返す純粋関数になるのが理想 >>283
いや、何を更新するかそこは自由に選べるから...
イベント発生時にビューモデルのメソッド呼べば、ビュー,ビューモデル間のデータフローが双方向になり今までの通りにMVVMになるし、他のなんたら?モデル呼べば例えばfluxになったり
flutterもそうだが別に限定されてない MVUってことはElmみたいな感じになるのかしらん。
F#との親和性も上がるといいな。 中途半端な絵空事を追いかけるよりExcelをさっさと.Net化して欲しいわ
いつまでCOMやねん モバイル版は既にかなりの部分がC#なんじゃない？
Win版を置き換えることはないだろうけど、既にWin版のOfficeの一部にも.NETは使われているし、
今後は本体に.NET Coreが組み込まれてC#で書かれたコードが増えていくことも十分考えられる
プラグイン機構のことを言っているのなら、そもそも現在MSが推進しているWinRT系のRPCの仕組みはCOMベースなので、仮に今後新しい仕組みに置き換えられるとしても.NETベースになる望みはない UI部分はすでに全部React Native Windowsだろ WPFでなくてすまないんだが、
UWPでデバッグしようとしたら、デバッガが無い風のメッセ出て
上手く動かないんだが。
VS2017のcommunityっす >>293
Ultra Windows Powet 完全に趣味でプログラムやってて
WPFに手を出してみようと思い↓のサイトのドキュメントで学習してたんだけど
http://kisuke0303.sakura.ne.jp/blog/?p=340
↓の106ページ目のコード動かしてみても図の通りにコンソールにファイルパスが表示されず「コールバック処理を行います」とだけ表示される。
http://kisuke0303.sakura.ne.jp/blog/wordpress/wp-content/uploads/2016/08/4843696230c1698ad8ff7d086b998344.pdf
でもサンプルのコード見る限りだとこれが正常な動作な気がするんだけど（ファイルパスを表示させる部分の記述が見当たらないので）
俺が何か見落としてるのだろうか。 wpfのチュートリアルはかずき大先生のページ以外は駄目だよ〜 >>296
ぱっと見だと図のような表示コードないね
多分途中で書き換えたのにコード側に反映忘れてる
まあ本でも誤植なんてしょっちゅうだし自分で合うように書き換えよう WinUI 3も結局UWPみたいなタブ向けUIなんだな
Fluentだなんだか知らないけどデスクトップ向けもうたうならちゃんとレガシー()コントロールも用意して欲しい レガシー必要なのってもう業務系アプリくらいだからなあ >>300
まあ業務系アプリはいつまでたっても一定の需要はあるからな(´・ω・｀) >>300
業務系アプリがなくなるってあり得なくね？ 業務系はWeb化してきてるし
webformだからレガシーだけどな >>304
デスクトップアプリはなくならないよ
需要は減るけどね 今時はそうでもないわ
クラウドがあるからWebの方がお手軽 当初から散々ゴミと言われたとおりWPFは普及せず、
クラウド化しても企業の効率なんて当然上がらず、社員は不便を強いられ、
データを吹っ飛ばれさてから黙れされた連呼する自称SEたち。
ここの住人は馬鹿ばかりだなw .net FrameWorkのOWINで
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Login/Index"),
CookieName = ".AspNet.SharedCookie",
Provider = new CookieAuthenticationProvider
{
OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<IdentityUserManager, IdentityUser>(
validateInterval: TimeSpan.FromMinutes(0),
regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
},
TicketDataFormat = new AspNetTicketDataFormat(
new DataProtectorShim(
DataProtectionProvider.Create(new DirectoryInfo("C:\\TEMP"),
(builder) => { builder.SetApplicationName("SharedCookieApp"); })
.CreateProtector(
"Microsoft.AspNetCore.Authentication.Cookies." +
"CookieAuthenticationMiddleware",
"Identity.Application",
"v2"))),
CookieManager = new ChunkingCookieManager()
});
System.Web.Helpers.AntiForgeryConfig.UniqueClaimTypeIdentifier = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name";;
で認証して別の.net Core2.1アプリに遷移するんだが、
.net Coreアプリ内でこの認証クッキーをidentityに復号してsigninしてUser.identityを使いたいんだが方法はあるのか？
認証.net Core自体の認証を完了させたい感じです。
伝われ〜 string authCookkiValue = string.Empty;
HttpContext.Request.Cookies.TryGetValue(".AspNet.SharedCookie", out authCookkiValue);
var ticket = authCookkiValue;
var protectionProvider = DataProtectionProvider.Create(
new DirectoryInfo(@"C:\TEMP\"),
(builder) => { builder.SetApplicationName("SharedCookieApp"); });
var dataProtector = protectionProvider.CreateProtector(
"Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationMiddleware",
"Identity.Application",
"v2"
);
var ticketFormat = new TicketDataFormat(dataProtector);
var test = ticketFormat.Unprotect(ticket);
で解決しました。
スレ汚し失礼しました。 他人のコードを読みたくないのはボクだけじゃないはず。 vs2019でwpf、.NET Core 3.1で作成したアプリのインストーラを作成したいのですが参考になるサイトありますか？
WinFormsと同じようにやってみたのですがプロジェクト出力でプライマリ出力を選ぶと.dllと.runtimeconfig.jsonしかなくexeが存在しません
元のプロジェクトがおかしいのでしょうか？ >>319
やって見たけどプライマリ出力を参照させるとそうなるねえ。
依存関係がうまく抜けてないっぽい。
今のところはプライマリ出力をやめて発行させてpublishフォルダを参照するしか無いかも。
stack overflow辺りには何か情報があるかも? .net coreアプリはmsiじゃなくてmsixパッケージを使うようだな。 >>321
ありがとうございます
msixを調べてみます msixにするとアプリによっては動かなくなるから気をつけて
行儀のいいアプリなら問題ないと思うけど
dotnet publishの出力先をコピーしてexeのショートカット作るだけのインストーラーが何かで作れるなら、そっちのほうが問題はおきにくい >>323
そういう問題が起きる可能性があるのですね。
プロジェクト出力でプライマリ出力ではなく項目の公開を選択でもいいのかな？
それらしいのが作れたけど… BlazorはCSSを各コンポーネント毎に好きなの割り当てできるようなバージョンアップは予定してるのかな
ちょっと使い難い 先月のBuild 2020開催期間中、Microsoftは、デバイスネイティブなアプリケーションを開発するためのマルチプラットフォームフレームワークである.NET MAUIのロードマップを発表した。新フレームワークはXamarin.Formsの進化形に相当し、Android、iOS、macOS、Windows用のネイティブ機能を提供する。
https://www.infoq.com/jp/news/2020/07/maui-multi-platform-ui-dotnet/ http://var.blog.jp/archives/69202816.html
未だに大部分のプログラムは Win32(というかMFC)で、
WPFを使ってる中で一番有名な VisualStudio は劇遅。 >>332
リンク先ではVisualStudioはWPFにしてはすごく軽くて十分に快適って書かれてる(C++とのハイブリッドも疑ってる)のに
何故激遅に書きかわるw >>334
「WPFの割には軽い」
と言っているだけで、現実には激遅だからだ。 VSは.net版に変わったら非常に遅くなったよ
それだけは譲れないｗ
サードパーティー製のコンポーネント使ってると聞いた
＞ WPFにしてはすごく軽くて
WPFでは激遅になると思ってたらそこまで遅くない！と言う意味であると体感している
今でもc++版に戻ったら非常に速いと思う 2015が一番重かったけど、2017→2019とどんどん軽くなってきたよね 今のVS十分軽いしさっさと古いクソPC投げ捨てて新しいの買ってこい さっきDocker Desktop入れたらUIがWPF製だったわ >>334
たしかにVSのタブやページ切替とかの反応は普通のWPFアプリと全然違うんだよな
なんらかのファクターXがあると考えるのが合理的
一般的WPFアプリには慢性的なもたつきが発生する 教科書通りにMVVMなんてしてたらあきまへんって事かな？ .NET CoreのWPFと.NET FrameworkのWPFでレスポンスに違いはある? >>342
自分で作ってるWPFアプリと差を感じないけどなあ >>342
VSはWPFの低いレイヤだけを使って独自のフレームワークを構築している
WPF標準の低品質なコントロールはダイアログにしか使っていない 普通のWPFって、あのクソ重いVSより遅いって、どんだけ遅いの。 WPF登場が2006年、VSのUIに採用されたのがVS2010から。
自分で作ったGUIライブラリなのに自社ツールに組み込むのに4年もかかるとか
どんだけ設計がゴミだったかがよく分かる。 >>346
むしろその独自のフレームワークを公開してくれよ 一方、MFCは、MS-Officeで実装後、MFCで提供される。
机上の空論 → 実装 → 使い物にならない
実装しながらブラッシュアップ → 使い物になる
よく話はやはり実際そうなのだ。 昔ロータスかどこかが表計算ソフトでどうやってもofficeの速度が出ないので調べたら非公開API使ってた！
マイクロソフトは不公平だ！と言ってたらしい 都市伝説か勘違いしてるか
Lotus123の対抗はexcelじゃなくてマルチプランだ >>352
馬鹿なの？
普通に考えて1-2-3のWindows版の話だろ >>354
馬鹿なの？
undocumented windows読んだ事無いのか >>355
はあ？
> Lotus123の対抗はexcelじゃなくてマルチプランだ
の話なんだがw 自分が買ったPCにLotus123 windows版を入れてたけどなあ win95と同時に32bit版Excelだしやがったから
サードパーティじゃ間に合わん
3.1のころはいい勝負してたと思うよ >>358
> 3.1のころはいい勝負してたと思うよ
そうだったっけ？
1993年にFMV買った時はWord/Excelと一太郎/三四郎のどっちかしか無かったような記憶があるが… Excelで1900年がうるう年バグってるってのは有名だけどこれってLotus123との互換用なんだよな
もっというとLotus123側もうるう年判定を簡略させるための仕様だったと undocumented APIを検出するtool
でwindows3.xの頃のMS-APPは
インチキしてないって話しだったな。
インチキしてLotusクラッシュさせたのは
DOS1.25の時代だね 今は、そういう嘘より、FUD合戦が流行っている。
「セキュリティーで危ないから、WindowsをUpdateしろ、LinuxよりWindowsの方が安全。」
「セキュリティーで危ないから、セキュリティーソフトを買え」
「セキュリティーで危ないから、ソースがないソフトは駄目。オープンソースを使え」 BindingされたCheckBox.IsCheckedはFallbackValueもTargetNullValueも利きませんが
どうやって初期値Trueを入れたらいいのでしょうか？ Windows 10/.NET Core 3.1
TextBoxにintのプロパティをバインドすると数字以外にエラーを出してくれるようにできるが、
TextBoxのTextを手動ですべて削除したときに最後に有効だった数字がプロパティ側だけに残るのは不具合なのかな。
数字が入ってないのに、その数字で計算されてしまう。
intは空になれないからこうなっているのだと思いint?でも試してみたが同じ結果だった。
intのプロパティにバインドするのは罠？
TextBoxに123と入力されている場合:
12を消して、最後の3を消すと見た目上のTextBoxが空になるが、バインドしたプロパティには3が入っているものとされて扱われてしまう。
そして、3が入っているものとされているため、プログラム上で空になっている場合を処理できない。 3 から先に消して
2 消して
1 を最後に消しても一緒 int諦めてstringにして検証部分書きました。
intのプロパティにバインドしたらそれだけで介護してくれると思わせて、実は手抜き介護だった。 数値型バインドするときはコンバータで細工するとか必要だったかな 学術の巨大掲示板群 - アルファ・ラボ ttp://x0000.net
数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など
VM + ASM を書いた (C#, DX) * x86 ではない!
simulationライブラリで純粋な関数式プログラミングをする
UIライブラリ (C#, 2D) を作ったよ
連続と離散を統一した！
4Dエンジン
matrixのライブラリ
ある強力なFor関数
SQLライブラリ
VM + ASM のダウンロード
ttp://up.x0000.net/files/TSimulang.zip WPFの経験があるならXamarinなんて簡単だろう Xamarinって結局OSの差分吸収しきれてないんじゃなかったか？ WPFがスタートでこけた理由って当時の要求スペックの高さもあるけど、MVVMパターンというものを主張しすぎたよね
適用できる一つのパターンであるのに、それがすべてであるかのように広められてしまったのでWPFは敷居が高いと錯覚させてしまった
WinFormsのコードビハインドの部分がXAMLとして前面に出てきただけというところからスタートするべきなんだよ
あとMVVMパターンを説明しすぎている
パターンって理解してなくてもその通りに実装すれば、そうなってくれるんだから初期段階で深い説明はいらない
どこに何を書いていけばいいかを説明するほうが重要、パターンを意識させる必要がない ネットに転がってるWPFのサンプルってイベントべた書きのばかり。 いやReactやVueやAngularだってMVVMの亜流なんだから別にそれ自体がWPFを難しくしているわけではない
むしろWPF開発の複雑さを低減するためにMVVMパターンが使われるようになったわけだしな
問題はMVVMでデータバインディングを駆使しなければやってられないほどにWPFが複雑すぎる点と、
そもそもWPFにとってMVVMが後付けであるためにReact等の後発とは違って実装に余計な自由度がある点にある WinFormのがわだけWPFに置き換えするだけで良いのでは、第１ステップは むしろ煩雑でよかった。winformが10年以上延命できた。 10年間進化してきたならともかく本当にただの延命なので共倒れ XAMLはDesigner.csなんかよりよっぽど良いと思うけどな。
XMLに馴染みがないのかフォームデザイナーしか使わない人なのか。 C#に瞬殺されたと思われたJavaの圧倒的な巻き返しでC#も息してるかどうか疑わしくなってきた。
MSはいろいろ戦略が誤っていたのだろう。デスクトップOSのシェアすら今後保てるかどうか分からない。 Javaの巻き返しは無理だよ
言語に葉快適な変更をいくつも入れないとC#には追いつけない WinFormsのポトペタに慣れ切った人がWPFで同じようにやろうとして思うように配置できなくて諦めるってのはあるかもな
だからといって、新規作成したときのデフォルトがGridでなくCanvasだったらアレだけどｗ VSで無理やりMVVMパターンにはめるのが糞なだけでXAMLとバインドは十分使える WPFは客先Java案件で開発補助ツール作るときに重宝しとる >>400
WinFormとまったく同じ手法で開発できるようにしても良かったな
学習意欲のある人には最初からMVVMコースを選べるようにして
後出しアイデアだけどね 業務系アプリや有名なアプリはその時流行ってたフレームワークや作り方を使って秘伝のタレ化してる
新しく作り直すこともせず完全なレガシーとなって開発者を苦しめてる
新規のアプリは結局Electron一択みたいな感じになった
この失われた20年をなんとかしろ >>400
そうそう、Excel方眼紙の人にWordは無理だよねえ(爆笑) x 新しく作り直すこともせず完全なレガシーとなって開発者を苦しめてる
o 新しく作り直すと新たな地獄が始まり若い開発者が逃げ出す
WPFしかりEdgeしかり。winformやIEをずっと保守しとけば良かったんや。 WinFormは保守してるでしょ
.NET Core でも使えるぞ WPFでAndroidアプリ作れるようにしてほしかった
xamarin.formsはなんというかちがう FormsのCore移行は保守というよりクロージング対応でしょ
.NET Frameworkのままだとフレームワークのバージョンが上がるときに一緒にFormsをメンテし続けなきゃいけない
一方、Coreはスタンドアロンなアプリに関してはSCDが大前提なんで、フレームワークのバージョンは固定して安全に塩漬けにできる
つまり、.NET6以降でFormsがまともに動かなくなったとしても、MSも俺達も無視して放置できる >>404
結局ElectronもVSCodeという念仏だけを唱え続けて何年になるのかという感じで盛り上がってない
ただ一つ確かなことは、これからのGUIプログラミングはマークアップ言語を避けて通れないということだけ >>414
.NET Framework は 4.8 で打ち止めと宣言されてる >>415
VSCodeの中のUIフレームワークみたいなのを
切り出して欲しいんだよね
今更HTMLで動的なツリービューとか流石にゼロから作る気にはならん >>411
ほぼそっくりな Uno Platform でできる。 まだvb6が切り捨てられないのに。
winformも同じだろうなあ。 COBOL、VB6、Winform。
時代に取り残された底辺プログラマにも生き残る道を与えてくれる。 WPFは先に行き過ぎてただけだな
普通に今通用する技術が身につく >>425
いったんUWPやってからWPFに戻るとちょっと時代遅れかなーって思うわ
UWPはデザインアレだけど先進性はある 10年以上前に初見でこんなものは普及しないと言ったボクの先見性も褒めてよ >>428
まったく先見性がない
10年前にWPF触ってた人たちは上のステージへ上がっている ゴミはとても匂いますからまともな嗅覚があれば触らずに済むのですがいやはや XMLに馴染みがない人にとってはXAMLがネックになるのかなぁ。 C#は省略記法をコツコツ取り入れているのに
xamlはなんで省略記法を取り入れないんだ
Ammy UIより省略された記法がほしい 専用のパーサーが必要で一般的なツールが使えない独自記法はいまさらやめてほしい。 >>433
xamlをvisual studio以外のツールで編集してるのか?
vsのideは優秀だが >>431
そこを学習する力がないのであればGUIアプリのプログラマーをやめてノーコードへ行ったほうが未来がある
これからはマークアップ言語は必須だ フォームデザイナでポトペタするのが最先端と言いたいんだろうか？ RADツールが最先端？ 30年前からあったってボク歴史の時間で習ったよ。
15年ほどの前の昔に登場したWPFがキラーアプリ一つも生み出せないばかりか禄に普及しなかったのに、
先を行き過ぎた先進性だの最先端だの未だに言ってるおじいちゃん。
この骨董品WPFの最先端とは何か教えてください。 WinFormsにしがみついてる人たちは何も知らないようだ
成長することもない 近所のおじいちゃんがワンボタンマウスは革新的だと言ってます。
どこが革新的なのか聞くと多ボタンマウスを使ってる人たちは何も知らないようだ、
それでは成長することもないと言って教えてくれません。ボケてると思います。 さて、マークアップ言語が時代遅れだと言っている人は時代遅れじゃないものを教えてくれるのかな。 ポトペタでかっけえの作れるのが欲しかった未来なのに その未来が欲しいならプログラマーやめてノーコードを盛り上げる活動をしたほうがいい
これからはノーコードで作れるものと作れないもので二極化していく
そしてその未来では「ポトペタ」はノーコードを意味する言葉にかわっている >>448
小学校でやるプログラミグ教育の内容がそれそのもの。
20年前のITバブルでその手のアホツールが腐るほど出たがどれも生き残っていない。
老人たちは何度同じ夢を見るのだろうか。先見性がないだけでなくボケてますね。 でも今ノーコードに取り組んでくれるのはグーグルやマイクロソフトだろ
常識が覆る可能性は否定しきれない ノーコードで日本の顧客が満足するプログラムが組めるといいなぁ・・ >>451
ノーコードで作ったものはプログラムというのか？は置いておいて
顧客自身が使って小物を作る程度の需要は満たすかもしれない。
複雑にデータが散在するようなシステムや、データへの意味が独自で手が込んだ物は無理かな。
シンプルかつサービス同士を糊でつなぐ程度のモノならあるいは。
UIやデザインに五月蠅い顧客の需要も満たせるのか微妙と思うが皆さんどう思う？ MSがノーコードノープログラムだと!!
WPFオワコンじゃん。 WPFerはパラダイムシフトを乗り切る力があるから問題ない
より新しいものに乗り換え、習得できる力がある
WinFormserが心配だ
彼らにはその力がない
ノーコードの進化は「作業の量や質がノーコードとは言えなくなるところまで」に限ることを考えて開発されているはずだ
その範囲を超えるとノーコードをノーコードとして使っていた利用者が離れていくフェーズが始まってしまうからだ そんなに余力あるならプログラマなんか辞めて医者や弁護士になったほうがいいよ。
法で利権が守られてるからね。一種やソフ開なんていうゴミ資格とは違う。経産省大臣のハンコに価値はない。 >>455
いきなり医者、弁護士、情報処理試験という無関係なこと話はじめるとか
知能や精神にエラーが発生してる証拠なので病院でデバッグしてもらった方がいいぞ >>452
顧客自身が作る小物はVBAマクロと同じ運命を辿る
それは開発者が自分達の為に作るツールも同じ たいして機能つかわないし
なんだかんだlivetに戻った・・・ >>460
livetに先はないよ
今も片手間でメンテを続けてくれてるだけだし、開発した本人から完全に移譲されてるわけでもないし
多機能すぎるけどPrismでやったほうが自分のスキルにもなっていいと思う 求人みると意外とWPF多いんだよな。
デザインとロジックに別けて開発できる! ってアンタどんだけの規模の開発だよ。 >>126
sockaddr_in構造体なんて同じだよな。 >>462
意外か？
ウチの周りじゃWindowsの新規案件はほとんどWPFでたまにC++でMFCは混ざる感じだが。
いまだにFormsでやっているところって本当にそんなに多いのかなぁ。 >>465
winformのがお手軽だからなあ
高dpiも騙しながら何とかなる 内輪でお手軽にやるためにわざわざ求人することも少ないんじゃないかと思うが。 WinFormsは論外としてWin7対応ならWPF一択だからな >>471
WIN7でもwinform使えるし
今更WPF勉強する位ならVC++6.0 MFC使ったほうがマシ。
W10でもVS6.0使えるんだよな。 そこまで勉強したくないやつがなんでプログラミングやってんのか不思議 Z80のハンドアセンブルの頃からテキトーにやってきたよ。 >>473
苦労して覚えたからもう二度と同じ苦労をしたくないってPGが世の中には腐るほど居る >>476
確かに。どうやってみんな勉強したんだ。 それ10年前の話じゃないの
今は情報が出揃っていてやる気だけあれば普通に習得できる ヤフーオークションで WPFの本検索したが三件だったぞww 顧客にとって関心事はライフサイクルコストだから
それが一番安上がりになるの方が正義 PCの性能が進化した今でもWinFormのアプリはやたら軽い
wpfが重いのはprismのせいなんだろうか 本とかいらねーだろ
わからないことを検索することもできんのかよ ID:H4U+QONT0 リアルで仕事でこんなこというPGいたら笑うけどw WPF勉強しときたいけどおすすめのサイトか本ある？ >>482
MVVMがレイトバインディングオンリーなのもね… 今は機械翻訳ばかりでMSの日本語ドキュメントがゴミのようだ。
かといってMSの公式解説書も酷い訳のものがある。英語で読むしかないね。 https://www.wpf-tutorial.com/
ここが英語だけど高1くらいの英語力の俺でもそんな苦労せずに読めたからおすすめ >>489
最近の技術系の翻訳本ってほぼ機械翻訳かけて手直ししてるだけっぽいからなあ
>>490
見てみる 酷い翻訳も慣れると逆算して読めるようになるから不思議だ
いや、読みやすいのが一番だけどね >>483
体系的に短時間で学ぶには今でも本が便利だよ >>490
日本語が Localized versions の上位には上がってないので
more languages ...
で出たが
Localization
https://www.wpf-tutorial.com/Localization/
日本語対応遅れとるな >>487
okazukiさんのブログが一番いい
prismとかReactiveproperty関連はとりあえず読み飛ばす前提で prismとか意味なく使うから
コードがめちゃくちゃになる。 >>494
ExcelがVBAというレガシーチャンピオンを抱えてるからそのうちスプレッドシートにシェア奪われるんだろうな コントロールは今まで通り、貼り付けで配置できるん? >>497
たぶんWinApiのFormatMessageのことだな(適当) >>501
デザイナはあるけれど、WinFormsのポトペタをイメージしているのならコレジャナイってなる >>501
ぽとぺたWindowにコード全部かいてもいいぞ！
好きにしろ あらら、またスマホベースで残念だわ
デスクトップベースのWPFが生き残り続けてしまうことに・・・ 最近のwebページもスマホベースのが多くて、pcで開くと横にドーンと広いんだよね(´・ω・｀) スマホ用のアプリをパソコンで開くと無駄なスペースとか多すぎでくそなのは事実だが、とりあえずタブレットというか2in1用のタッチベースのアプリが増えないことには
一般向けのアプリのほとんどが参照系でタッチベースで十分なわけだし
で、マウスベースの生産系アプリ作る場合はどうするんでしょう...マイクロソフトさん...
winuiもコンパクトモードがあるがすげえ中途半端だし... MSがWindows 1からデスクトップだけを考えてアプリ開発をしてきた最終的回答がWPF
おそらくこの分野でライバル出てくるとしたらWindows 11が出るような変化の時だろうな >>507
そもそもwww(html)なんてUNIXが発祥なのに
変だろ。
納得できんわ。 >>504
コード書くなら「Visual」Studioじゃないよな。
WIN32APIで書くのと変わらん。 >>512
UWP推進のために敢えて放置されてたのか、痒い所に手が届かない部分が所々合ってもどかしい
せめて事前バインディングはマージしてくれ >UWP推進のために敢えて放置されてたのか
これだよなぁ。ペゾルト本もWPFスキップさせられたし。 画面デザインとコードで分業できる、というけど実際そうしてるんか?
結局全部自分でやってね? >>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移植なんてされないよ
まあデザイナーはいつになったらまともに動くようになるのってレベルだけどね WPFからは他のXAMLなりHTMLの似たようなフレームワークへ移行できる技術力があるのでWindowsである必要さえない
WinFormsの囚人たちは全力でWindowsを守れ 開発補助ツールや趣味で作ったりするときはwinformsかな
とりあえず動けばいいっていう用途なら選択肢に入れてる
そこまで極端に邪険にする技術ではないと思うけどwinformsに親を殺された人が多いのかな 俺は柔軟なUIが作りやすいWPFのが好きだな
例えばウィンドウのサイズが可変なFormで、サイズに合わせてコントロールを見やすいように配置するようなアプリ
Winformでもできなくはないけど、Gridに縛られるとか制限も多いし、
修正するにもデザイナのソースを直接触るのは危険だし バインドバインドとうるさく売り込む割に実装が洗練されてなくてコードがあんま綺麗にも楽にもならんのが印象悪かった
intellisenseもバインド関連はかなり冷淡だし
バインドはおまけ扱いでGUI周りのアドバンテージから攻めてればもっと受け入れられたのでは WinFormsがメインストリームだと勘違いしたままになってる人いるよね
WPFが楽なのでWinFormsが選択肢に入ることはない WPFはメインストリームになったことすらないけどな >>619
WPFに親を殺された人の方が多そうな気がする まあwinformの時代が長かったから、狂信者も多いよそりゃ
優劣ではなくて母数の問題 手軽さはwinformもwpfも同じだと思うがなぁ
どちらもポトペタで作れるし wpfはポトペタの後に数手間がデザインコードに必要でしょう WPFは.netの発展を妨げたと思うよｗ
WPFは.net farameworkを殺した >>630
WinFormsって別の選択肢があってWPFが強要されたわけでもないのにそんなに影響あるわけない
それならむしろUWPだろ WPFのころは最初スター開発者というかカリスマ開発者が結構いたけど
徐々にWPFに愛想をつかしてみんな出て行った
UWPのころは全然いなかったイメージ WPFが失敗したというより、Win32とかWinFormsとか関係なくWebやスマホの台頭で、パソコンの地位が大幅低下してWinアプリ開発者自体がいなくなっただけだろ WPFがこれからって時にRAIのSilverlightくるか？と思ったらスマホやhtml5に潰されて、開発者はそのままwebやスマホに流れてそして誰もいなくなった
タイミングが悪かった Silverlightの存在自体忘れてたわ
Flashですら終わったし何が流行るかようわからんな >>629
ポトペタ後の手間はwinformもwpfも同じでしょ wpfがあるおかげでpowershellで見栄えのよいgui使えるのが助かる WPFは結構書いたけど
Silverlightは本当に一回も書かないうちに消えたなあ 俺は最初個人的にWPF触って遊んでて、Silverlight3でMSの本気を感じて移行
そしてMS公式によるHTML5使え発言でXAMLは完全に見限ってWebへ移った
当時の選択は正しかったと自信を持って言える .net coreになってLinuxにも対応！でも結局ランタイム入れないと動かない
monoと比べて何の優位性があるの？ WPFって参考図書がほとんど無いし取っ掛かり難い感じ >.net coreになってLinuxにも対応！でも結局ランタイム入れないと動かない
Linux版は同梱できないの？ できるけどLinuxなら普通はDockerでOSごと同梱するからSCDかFDDかはあまり関係ないな
Dockerfileの書き方がちょっと違うだけ WPFに移行したかったが、WinFormsの資産が多すぎてむりだった。 メインはWinformでも、一部分だけwpfにできるよ >>648
まじで
…一部ってどういう意味？
プロジェクトの中で混ぜれるってこと？ >>649
うん、混ぜれるよ
elementhostでググるといい >>651
めっちゃ判ります
合わないっていうより
いつもどっち使うかで迷う 最近のフレームワークはスマホでも使えますよアピールしてドロップダウンの要素が激太りになるのがイヤ
マウスでクリックするからフォント＋パディング1pxでいいのに 大きさの事いってるのならドロップダウンのみならずほぼ全部だろ
マウス入力するときはでかすぎて迷惑だが JetBrains、デスクトップUIフレームワーク「Jetpack Compose for Desktop」を発表 | OSDN Magazine
https://mag.osdn.jp/20/11/11/123200 >>656
これ面白そうだな
Androidと同じようにアクティビティやフラグメントを使ってアプリ作れてデスクトップで動くってことだろうか？ いくらコードで簡単にUIが作れますよ言っても、GUIエディタは用意しておいて欲しい ・オープンソース
・マルチプラットフォーム（Win/Linux/Mac） >>659
Windows, Linux, macOSで動きます
asp.net Web Formは消えました
Linux, macOSでデスクトップアプリは動きません > Linux, macOSでデスクトップアプリは動きません
いやこれが重要だろ・・・ >>663
.NET MAUIにご期待ください
ただし、リリースは.NET 6目標です >>663
Android, iOSのアプリが作れれば問題ないでしょ uno platformはどうなんだろうね？
uwpで作ればxamarinとBlazorに変換してくれるマルチプラットホーム GitのCredential ManagerはJava製からAvaloniaになったよね… >>664
.NETって５で打ち止めじゃなかったんか？ >>668
機能追加が無くなるのは.NET Frameworkで4.8が最終
.NET5からは.NET Coreベースになって続くよ ５がすでにCoreなのか
ということは4.8から5にしようとしたら修正が必要になる可能性が高いのな .NET 5 は .NetFramework 4.8 -> 5 と .NET Core 3.1 -> 5 のダブルミーニングなんだね >>673
そんなことはどーでもいいし、それって使える奴ですかね？ >>674
使えるもなにも、今後もC#で開発するなら相手にするしかないやつです まあ業務では今後10年は4.8が主流だろうから、10年後にまだC#を使う必要があるなら考えりゃいいんじゃないか >>676
10年どころかvb6のようにゾンビ化して死ねなくなる 未だにvbや3.5使ってるところ山ほどあるからな。 いつ壊れるか分からん古い車は捨てて新しい車に乗り換えじゃ。
運転サポート機能も良くなるだろう。 運転手はそれで良いよ
その新しい車はだれがどうやって作るんだい？ wpf勉強はじめた
これWindows環境無視するにはランタイム含めるのが第一？ wpfで、
Task.Run(()=>{
var button = new Button();
});
って書いたらExceptionがでるのはなぜですか？
UIスレッド以外からだと、コントロールの生成もできない理由が分かりません。
FormアプリだとExceptionは出ません。
別スレッドからUIを操作する場合に、Dispatcher.Invokeが必要な事は知っています。 >>686
そもそもWPFのButtonとWinFormsのButtonは別クラスですんで……じゃだめですか >>686
できそうだけどInvalidOperationになるねえ。
xamlを使わずにc#のコードだけで書いたらどうなるんだろ。 ボタンの生成自体をUIスレッドで実行しないといけないというのは不便ね
バックグラウンドで次の画面を用意するとかできないじゃん
JavaFXではボタンやパネルなどのNode生成自体はどんなスレッドでもできる
Nodeをウィンドウに追加する操作やウィンドウに追加した後のNode操作はUIスレッド限定
おかげでバックグラウンドでのUI準備がはかどる
WPFは違うのか、残念 >>689
メイン以外の複数のUIスレッドを持てばいい
Threadを作成して、そのスレッドでDispatcherを起動すればそのスレッドでButtonなどを作成できるようになるらしい
たた、そこまでしてUIを作成するのが重い処理なの？ xamlで出来ることをコードで実装するメリットは無いなあ >>689
React.jsのアーキテクチャとか知ってりゃわかるけど、論理的なツリーの構築なんて実際にそれを画面に反映させるコストに比べたら無視できる
IOが必要なデータとか激しく時間がかかるものだけ先読みしておけば十分 ちなみに、Win32コントロールをラップするWinFormsのコントロール、
>>686でコントロールの生成で例外発生しないとの事だけど、最終的に画面に表示できたの？
ググるとどのみちエラーでる記述が >>691
それってuiスレッドが空かなきゃ描画出来ないのでは? 新しいスレッドをSTAにして複数のUIスレッドを構築/動作させることはできるけど
どのみちコントロール作成時に呼び出しスレッドのDispatcherに結び付けられちゃうので
WPFは別スレッドでコントロール作成してメインのUIスレッドに渡すみたいなのはできなかったと思う
（XAMLのデシリアライズも然り） >>695
というか、たぶんWindow単位とかになりそうだな...
つまり、あるWindowを表示してて、別のWindowを別のUIスレッドで作成みたいな感じで... うん、>>696みたいな感じ
WPFではそれが限界だと思う >>697
そう言うコードにするメリットは無いですよねえ('・ω・')
分かってないやつほどスレッドを使いたがる法則 >>699
メリットがあるかどうかはそれは>>689に聞けよ
俺も意味なさそうだから>>691でそこまでしてUI作成するのが重い処理なのって一言書いただろ
でも、勝手にこっちでメリット判断して実際できるか答えないのもあれだから一部できるやり方書いただけだろ まぁ、お前みたいな低レベルは、複数UIスレッドもてて、コントロールがUIスレッドに結びつくという知識なかったから
>できそうだけどInvalidOperationになるねえ。
xamlを使わずにc#のコードだけで書いたらどうなるんだろ。
こんな馬鹿みたいな感想でるんだうが >>702
自スレッドで作ったUIにはアクセス出来るのでは? >>702
>>686のコードってwinformだと実行出来るんですよねえ。
何でwpfで実行出来ないのか謎に思っただけです。
オレって低次元? 非同期よく分かってないんだけど
スレッドプール上で例外投げてもそれだけでは他スレッドには例外って飛ばないんじゃないの？ >>708
お騒がせしてすいません
>>709
飛ばないけどデバッガ上だと出力Windowに出ます >>700
UI構築ってそんなに低コストかな？
JavaFXのFXML（XAMLみたいなもの）からUI構築するのって結構コスト高いんよ
マークアップ言語からインスタンス生成していくのもそうだし
FXMLに記述したイベントハンドラーの実際の割当がリフレクション使っておこなわれるとかあるので
複雑なUIだとFXMLからUI構築するのに0.3秒かかることもある
XAMLだとそういうことはないのかな？
ともかく準備がバックグラウンド**でも**できるのは単純にメリットじゃない？
もちろんUIスレッドでやりたい人はそうしてもいいんだし >>711
ここWPFのスレで基本デスクトップ向けのアプリだから、そこそこパワフルなマシンで動かすだろうとはしょったが、
xaml自体はくそ重いと思うw
baytrailのatomタブレットの頃のUWPアプリ作ってた頃に、画面表示にx:bind使おうが結構なCPU使用率いって格闘してたし
Uno Platformのアプリもandroidで動かしてみると、ページ切り替えとか
もっさりしまくり。xamlが重すぎなのかどこがボトルネックになってるが調べたわけじゃないが あんま詳しくないけどリフレクション結構使うことになるから重くなるんじゃなかったっけ？ WinUI３のPreview3とWebView2の正式版が出たようだがイマイチ盛り上がってねーな そうね
GPU使うのもそうだし
UIスレッドとは別にレンダリングスレッドがあるのも良い
本質的にWPFはWinFormsより性能を出しやすいアーキテクチャになってる GPUないとクソ重くゴミ同然。仮想環境では使いものにならない。 >>714
ここにはそういうチャレンジャーあんまりいないので…
C#9ゴリゴリ使うのは楽しそう >>656
だんだんiOSが無視される様になってきたな。 >>724
やったことないけど、ググると仮想環境でもGPU使えるらしいよ >>724
グラボGPU無くてもCPUにGPU内蔵でしょ GPU使うちゅーても合成に使うだけでその前に贅肉たっぷりの処理が走るので意味ないわよ WPFの3D表示部だけ遅いからグラボいいのかって乗せたけど動きは変わらなかった WinUI in Desktop使いたいけどボタン押したときの感触が気に入らなくて辛い
純粋なデスクトップから生まれた発想じゃないもんね https://forest.watch.impress.co.jp/docs/news/1290743.html
米Microsoftは11月20日（現地時間）、.NET向け「WebView2」の一般公開を発表した。「.NET 5.0」や「.NET Core」、「.NET Framework」（Windows Forms/WPF）をベースとしたアプリケーションに新しい「Microsoft Edge」を組み込むことが可能。現在サポートされているすべてのWindowsで利用できる。 >>733
Win32 C/C++向けの「WebView2」は10月にリリースされており、これでWin32と.NETの両方をカバーできるようになった。 >>737
あるよ。
一番肝心なAndroid, iOSに対応していないし、サイズも大きいし、起動も遅いし
どうにもならない。 WPFはWindows Desktop専用だからいいんだよ
Electronは話題性もないし立ち位置も中途半端 .NETのアプデすらNGな案件でサーバー上でちょっと動かすツールだと、WinFormかWPFの二択になるんだよな >>743
.NET使わなきゃいいだけでは？
.NET CoreでSCDする手もあるし そうだね
実行ファイルのサイズがクソデカくて笑ってしまった Electron使ってる有名どころって何がある?
Teamsがそうなのは知ってるけど、使い勝手がいまいちな部分が多くてあまり印象良くない Prism 8使ってるけどViewModelのコンストラクタでIDialogParametersとる方法ないの？ SkypeとかUI変わって滅茶苦茶評判悪かったやつじゃん 既存アプリがWPFに移行した場合、使いにくくなったという悪評しか聞いたことがない。
当然の結果だけど。 それはUI framework関係なくUXの話では？
UI frameworkの評価って大体、作りたいものが作りやすいか？凝ったことをしたいときにやりやすいか？っていう開発者都合だと思うけど
別にwpfが良いと思わない部分はあるがその評価基準は違う気がする Electronは言語もJSかTypescriptになるし、Wasmも簡単には使えないようだし
中後半端。
特にやはりスマホやタブレットで動くアプリが作れない事が痛い。 いや、ウェブビュー2ベースのエレクチオンまだかなーと たしかにモザイクされたサムネは赤黒黄が多くてグロっぽい Defenderにワイのwpfアプリ勝手に消されたわまじﾀﾋね >>755
WPFでも既存のフォームアプリと同じようにUI作れると思うんだけど違うの？ wpfはxamlをきちんと勉強しないと、直感だけでは使いこなせない人が多数だと思う。
入力を伴うデータグリッドだけは、未だに扱いにくいと感じてる。 WPFはトップダウンな設計が必要で、ドカタのWinForms開発のように個別に画面を作り始めると破綻しやすいんだよ WinFormっぽく使うことは可能だけど、DataGridをクリックした時の動作は不評だな >>772
色々弄ってない素のDataGridの動作で文句言われないの? GrapeCityのSPREADとか使いやすいのかな。まあ、試してみればいいのだが。 DataGridは弄るのも面倒だからなあ
Excel.Net作って欲しいわ gridを方眼紙のように張り巡らせてどんな座標にも置けるような画面設計があって驚いたんだけどこんなんアリなの？ アリだよ
ウィンドウサイズ可変のアプリでも部分的にはサイズ固定の領域って存在するし
レイアウト機構を持っていても絶対値座標指定機能を持つUIツールキットは多い ビジュアル・デザイナーとロジック開発者との協業ができる。
とあったけど、どんだけ凝った画面にするんだろ。
普通はコード書く人が画面(コントロール配置)やるだろ。 powershellからだすWindows Formで野比家のボタン2回押して、磯野家1回押して、野原家3回押してOKしたら「男14人、女9人、犬3匹、猫3匹」って返してくれるプログラムください 野比家の女：玉子さん
磯野家の女：フネさん、ワカメ (フグタ家のサザエ除外）
野原家の女：みさえ、ひまわり
どうしても延べ10人になるけど、9人って返さないとダメ？ >>781
コードを書く人に任せるといまいちなデザインになりがち
凝る凝らないに関係なくね よくみたらWPFのスレでPowerShellもWinFormsも関係ないから
答え書かない方がいいか 各家の人数を加算なんかせずにボタンをある一定の手順で押下したときにだけ特定の文字列を返すプログラムで良いのでは？ ボタン押す回数が少なかったときや多かったときの動作は仕様上未定義だから
常にOK押したら固定文字列「男14人、女9人、犬3匹、猫3匹」を返せばいいんじゃないかな >>781
デザインはデザイナにしてもらって、それ見ながらコーディングすればいいよ
中途半端な分離はかえって生産性落とす >>787
2-1-3は決まってるから、それ以外ならハズレ演出して、2-1-3の時だけメッセージだした方がまだ仕様（）に近くない？ デザインをデザイナと分担できるというけど、経験上ビジネスロジックと比べたらデザインの工数なんて半分以下だから分担の恩恵が薄いんだよな 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とコードを分けられることがメリットじゃなくて
そこが疎結合になるからいいんでないの 疎結合になること自体はメリットではない
疎結合になることで何がメリットになるか書かないと
結局、分担作業やデバッグが楽という話に落ち着くと思うが 疎結合のメリットがわからない人はここにいるのかい？ 疎結合になること自体はメリットではないことがわからない人がここにいるのかい？ 個人とか小規模開発ならあんまメリット大きくないよな どんだけでかいシステム作るんだろうな。
VC6.0やVB6.0でいいだろと言いたい。あれは良くできてた。 疎結合って
キチンとインターフェース決める設計手法と
ほぼ逆の事をやってるね。
VS等の参照ジャンプが利かなくなって
かつリファクタリング機能の対象外となるし、
コンパイル自分に結合保証も担保できなくなるから、
大規模化リファクタリング後の
潜在バグの原因になっとるんだが。 >>890
疎結合だとデバックが楽というの
どんなケースを想定されてるのでしょうか？ 疎結合だとデバッグが楽・・・
ビューとモデルが明確に分離されてることで
「画面に表示される値がおかしい！」というときにまずはモデルをチェックすればいい
だいたいこれで誤りが見つかる
ビューはモデルを素直に反映するようになっていればビジネスロジックの影響をほとんど受けない
つまり、デバッグ（点検）対象から外せるケースが多くなる >>898
Viewとmodelの分離は
疎結合は関係ないんじゃ...
「ビューはモデルを素直に反映するように」
これも... ViewとModelの分離で結合が疎にならないの？
>>899の思ってる「疎結合」の定義を聞かせてほしい
「ビューはモデルを素直に反映するようになっていれば」という前提の整理について
>「ビューはモデルを素直に反映するように」
ここだけ抜き出して「これも..」と指摘してるのはいったい何が言いたいの？
なんか逆張りで根拠もなくケチつけてるだけに見えるんだけど >>900
「密結合してViewとmodelを分離」
「密結合してViewとmodelを素直に反映」
しても結果は同じでは？ ？？？
ごめん>>903の国語力か俺の国語力かどっちかに問題があって
あなたの主張したいことがわからない
で、あなたの思ってる「疎結合」の定義について説明をお願いしたいんだけど >>901
昔というか、
WinFormsと同じようにWPFでも書けるよ。
実際サンプルコードはコードビハインドで
イベントハンドラーで書いてあるもの多い。 >>905
mvvmのサンプルじゃ無きゃ
イベントにベタ書きのサンプルだらけ >>904
良い説明をググッてみたけど
見つからないので簡単に書くと、
コンパイル時に参照が切れた状態になる実装を
疎結合。WPF流MVVMでバインディングで繋ぐと疎結合になる。
対してC#で普通に書くと密結合。 ちなみにMVVMで
XAML(View)とmodel間の接続を、
例の難解なバインディング構文を使わずに
コードで書く(密結合)事もできる。 >>905
それで売りの高解像度にも対応してるなら
それでいいやね。
>>906
MVVMもそのうち消えるだろう。 >>910
初心者には難解じゃない？
コード補完も効きにくいし。
最初の多きな(大きすぎる)ハードルでしょ。
設定間違えると動きも変わるし。 ビューとモデルの分離って、ロジックに影響なく簡単に見た目を変えられることにあると思うのだが >>909
>>MVVMもそのうち消えるだろう。
MVPの派生だし消えるほど酷くはないけど。
自分はReactとかでViewModelとかいう概念は
便利に使わせてもらってる。
View(React,ts)+ViewModel(ts)+Model(C#) >>911
コード量は増えるけどバインド有ってのXAMLでしょう。 >>913
よくわからんがなかなかの上級者ですな。
元MASM使いなんだが今の方が覚えること多いわ。 >>907
あーなるほどね
俺とは疎結合・密結合の定義が全然違うわ
あなたは静的型付け・動的型付けみたいなものとして考えてるのね
疎結合は実行時解決だから統合開発環境で流れを追うのが難しくなると
まあそれも分からなくはないがな
俺の言ってる疎結合・密結合というのはそういった技術的に明確なものではなく概念的なものなんだ
インターフェースが明確に決められていて必要十分な最小限のやり取りがされるように設計されてれば疎結合
そういった取り決めがなくあちらこちらで繋がってるのが密結合 treeの子要素にアクセスするのめんどくて嫌になる
もっと簡単にして >>911
UWPともう直ぐ出るWinUI3では、バインドでインテリセンス効くし型チェックもやってくれる >>916
説明書いててそうかと思った！
「静的型付け・動的型付け」この型付けは開発完了時に
100%分かってないとダメだろうから型固定なんだよね。
「静的型リンク・動的型リンク」が正しい（昔はそう言ってた）と思ってるけど認識間違い？
>>916
>>インターフェースが明確に決められていて
ＡさんとＢさんが同一箇所の実装作業をしていて、
お互いが作成したクラスを呼びだす時、
その取り決めをインターフェースクラスとして作成して
これを別モジュールに切り出してお互い齟齬が出ないようにして開発する方式を
オブジェクト指向的な開発の基本と思ってるだけど、
この別モジュールのインターフェースクラスの役割を
疎結合に置き換えたプロジェクトが多いね。
テストしてても実行しないとバグわかんないし、
仕様書が必要になるから生産性下がんない？仕様書もらうより、
インターフェースクラスを寄越せと言いたくなるけど認識が低い？ >>920
WPFのバインディングはちょっと難しい構文を書くと、
合ってるのに警告出たりしてウザかったりするけど完璧なものになった？ >>918
コンピュータが未だ真空管だった時代ですね >>922
逆に厳密な方チェックになっているからintとdoubleの違いでもエラーとなるから
コンバーターかますかViewModelをイジる必要がある
あとコンバーターは型チェック無いからハマる時があるのが問題だったり >>914
大昔からやってる（WinFXとか言ってた時代からやってる！！）と気づく人いたと思うけど、
WPFの開発者が目指したのは、開発時にBlandエディタが使える実装なんだよ。
Blandは別製品で今はVSに統合されたけど、使えてる人はいるのかな？
Blandを使わない時点で、WPF流MVVMの実装パターンはやりすぎだし過大だ。
そのくせ、コードビハインドは捨てきれてないし、
中途半端で今時流では欠点を指摘される事が多くなってる。 DreamWeaver が対応しないと
デザイナーは手を出さないでしょうな mvvmは疎結合というか、vmからvやUIフレームワークへの依存がないというのが一番の肝だろう。
だからUI抜きの結合テストが容易にできる。 WinUIはUWPの系譜だから事前バインディング x:Bind なんでしょ
イベントも対応しててちょっとしたボタンクリック程度ならコマンドパターン適用しなくていいし楽だったわ
あとMVVMじゃなくてMVUとかいうを使えとか WinUI3は４ヶ月毎のマイルストーンって言っていたから
予定だと来月に出るが、何もアナウンス無いから延びるんだろうな 個人的にはwinform よりmvvmwpfの方が設計を考えるのが楽だとは思う
コード量がアホみたいに増えてるとは思うけど WPFでUI書いて処理はイベントにベタ書きが一番楽だわ
WinFormsよりUI要素のレイアウトしやすいし gridはレイアウト決めるときにすごく便利ですね
これだけでもメリットは大きい >>932
先々週に次の予定発表されたやん..
3月にサポートされるバージョンの0.5
で5月のbuildイベントで0.8
で、急遽、2月中にpreview 4 >>935
それくらいならWinFormsのTableLayoutPanelと変わらなくない？ >>937
Blendつかえばmvvmの意味するものがわかるよ。
使うの多少ハードルあるけど、
なんでWPF流mvvmがこーなってるのか解る。 >>936
https://youtu.be/MulUg7iD2-s
ソレのソースらしきもの見つけたが
ここではreunion0.5にincludes WinUI 3.って書いてあるのにな
それがpreview4ですか・・・ >>940
preview 4はその最新のロードマップが発表された後に、プレビューリリースの間隔が長すぎという批判が出て急遽リリースされることになった
https://twitter.com/marbtweeting/status/1354134751766953984
2月 preview 4
3月 reuinoin 0.5
5月 reuinion 0.8
じゃないかな?
https://twitter.com/5chan_nel (5ch newer account) WPFの本のKindle版を買ってまだあんまり読んでないのに
もう別のUI出るのかよ・・・
ちきしょー、紙版買っときゃよかったぜ
それなら中古で売れるのによ・・・
WPFにはクソな思い出しかない WinUI以前にとっくの昔からWPFはレガシーなのに何を今更 WinFormsとかWPFのいい所は、配布先のPCでだいたいランタイムの新規インストール不要で動くとこなんだけど、
WinUIだと当面ランタイムも同梱しないといかんよね？ こんな中途半端なものでレガシーとかWPF終わってるな windowのvisibilityにデータバインドして
イベントハンドラでhiddenになったらthis.close()してやろうとしているのですが
クソコードですか？ WPFのリリースは2006年、もう15才だ
一般的なソフトウェアのサイクルとしては決して短くはない
結局日の目を見ることはなかったが、ここまでよく頑張ったよ
もう楽にさせてやろう WPFに関連する検索キーワード
wpf 普及しない
wpf 将来性
wpf 流行らない
WPF C#
wpf 将来性 2020
wpf サポート終了 他のキーワード
wpf 普及しない
wpf 将来性
WPF C#
wpf 将来性 2020
wpf 流行らない
WPF(Windows Form)
wpf サポート終了
WPF 入門
他の人はこちらも検索
What is WPF used for?
Is WPF Dead 2019?
What is a WPF project?
What is replacing WPF?
Why is WPF dead?
Why is WPF so slow? デスクトップで悩むならWebに逃げるわな
デスクトップでしかできない要件があるなら別だが Web SerialとかWeb Usbあるから殆どのことは出来るのかな 動かないことはないと思うがjQueryとか古い技術使ってそうね
今のreactやvue.jsなんかも数年立ったら古いって言われてると思う
Webは技術がコロコロ変わりすぎてやる気になれない 組み込みはずっと相変わらずc/c++だからそれはそれでモチベ維持難しいぞ なんだ。勉強しようと思ったら終わりかよ。
業務アプリって明快でサクサク動くのが第一条件だからなぁ。 そう。
ボタンに影つけるとかアニメーション、回転なんて実際、どうでもいいんだよね。 軽さならUWPだな
ライブラリの使わない部分切り捨てるしAOTだしライブラリ自体がCOMオブジェクトだし リユニオンでUWPもレガシー化するから、生き残るのはWinUIと、昔から裾野が広いWinForms >>964
C++時代にCOMとかActiveXとかに手を出して、COMアレルギーになったわ 生き残るかどうかといったら大体生き残るだろ。
はっきり死亡宣告されたのはC++/CLIとかGDI+くらい。事実上死亡はC++/CXとか。 >>963
同感
社外に出すなら知らんけど、うちは社内の業務アプリ開発やってるから見栄えよりもパフォーマンス重視なんだよね
みんなWinFormsでやってて、社内でWPFやってるの俺しかいねぇ
リアルタイムでグラフが動いたりすると「おおーっ」と言われるが、作った俺本人は別に要らんかったなと思ってる COMもうサポートされないやん
このままだとExcelもいずれ死んじゃう >>970
暗にWPF使うアプリケーションは見栄え重視と言いたいようだけどそんなん少数派だよなぁ。
というか本当にそれ目的でWPFやってんの？ >>963
ま、両方できるならそれに越したことは
ないがな。 MSはReactivePropertyとかPrismみたいなの取り込む気はあるのかな
MSでWPFの冗長さが問題になってなさそうなのが不思議 MSの縦割り組織の悪い面だとおもう
オフィスはReactNative
VSCodeはなんだっけな、これもjs系言語で作ってたとおもう
Windowsの衰退はWPFの衰退 >>985
いや、単一の技術に全集中する方がヤバい
まあ余力がある企業だからできる技だけど多方面に分散するのは生き残る知恵だよ >>986
そういうことではなくて
自分の会社が作った技術を他の事業部がほとんど使わないんだよ
色々技術つけるのはいいよ？でもその技術作った会社がほぼ使ってないってどーいうことなの？
ってなる
なんかその辺の企業にありがちなオレオレフレームワークと一緒じゃん visual studioなんか自社が人柱となってベータ版を積極的に使って改善していたと言うのは過去の話か ドッグフード食うって話より、例えばOfficeでもWPF使えよって話なのでは >>987
自分の事業部で使ってるんでしょ？
事業部制ってそう言うもんだよ
別会社みたいなもんだし、下手すると現場では競合したりもする
日本でも昔はそういう企業も多かったけど無駄だからやめようとトップダウンにして現場の士気は下がって業績もついでに下がってるw WPFというとかぎられてしまうけど、
XAMLという括りで見ると
社内開発ツールとしてのシェアないの？
windows8以降のOS周りは
全部XAMLじゃないの？ >>990
事業部制はほんとつらい
乱立するオレオレフレームワークに振り回されている…
MSと他企業の違う点は、MSは作った開発フレームワークを公開してるとこだな
>>991
それは確かに。 MSはVisual Studioの方向性も考えたほうがいいな
以前はVSとWeb開発の親和性を高めるためにASP.NETを生み出したりしてた
こんなやり方は今後は通用しない
今後はMSが歩み寄ってVS使えばReactやvue.jsの開発が楽になります！みたいな方向になっていって欲しい
さすがに巨人MSでもWeb技術を自社で囲い込むのは無理だ >>992
MSは作る立場の会社なので使うだけの会社とはちょっと違う
使うだけの会社なら標準化すべきだよ >>993
VScodeが担う役割じゃないの？
それらじゃ充分デファクトになっとるし。 MSはVSCodeに注力しすぎだろ
このままじゃ有料のVisual Studioが死んでしまう
MSは製品販売で収益上げるのをやめるのかな
無料のVSCodeでいいソフト作ってくださいねー Azuleで動かしてくださいねー という戦略だろうか VSは随分前から
フェードアウトしてるようにみえてるけど。 VSCodeは開発者のWindows離れ問題への対策の一環でしょ
Web開発でWindowsは使い物にならなかったのが、VSCodeやWSLによってここ数年で急速に改善された
Windowsへの繋ぎ留めが目的とはいえWeb技術に疎いドザ達だけに任せてたらエコシステムとして成長しないから、VSCodeはマルチプラットフォームにする必要があった 有料のVS無くなってもいいから日本語ドキュメント整備に力入れて欲しいわ 確かに
あのdocsの日本語?読んでいると
頭が痛くなるな このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 424日 7時間 12分 34秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
