WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part22
レス数が900を超えています。1000を超えると表示できなくなるよ。
Windows Presentation Frameworkについて語るスレ。
前スレ
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part21
http://mevius.2ch.net/test/read.cgi/tech/1494288553/
関連スレ
Windows 10 UWPアプリ開発 Part 2
http://mevius.2ch.net/test/read.cgi/tech/1499658092/
コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/ ユーザー視点からみたWebアプリの使いにくさ最強レベル まぁ、作り次第でWebアプリをネイティブアプリに見た目似せて作れるけどでもやっぱwebアプリはウンコ多すぎ まあフロントをHTMLにするかはともかく今時完全にオフラインなアプリなんてゲームや電卓を除けばほとんどあり得ないから、
最初に学ぶならまずはWebがいいだろうね。
UWPは>>837のような子を満足させるためのベターなオプションに過ぎないから、最初に手を出すものではない。 速度重視にしたらプログラミングめんどくさくても普及する
みんな使うから
プログラミングしやすさアピールしても速度犠牲にしてたら生き残れない
結局他のものもつかわないといけなくなるから
バインディングが速いっていってるのはどーせしょぼい小規模なプログラムだけ WebアプリはHTMLはいいんだけどJavaScriptがクソすぎて困る じゃあC++とC#のwinforms使えるwindowsのデスクトップアプリ開発界隈では俺はWPFとかUWPなんかやらなくても当分安泰ってこと？
web側勉強した方がいいのかな
webになるとクライアント側はブラウザになるから言語も必然的にhtml/cssにJavaScriptとかになるから、c++とかc#のデスクトップアプリ開発で磨いた俺の力が役に立たないよな
だからASP.NETとかやっても微妙かなと思ってるんだが、c++やc#でクライアントサイド作ったらサーバサイドも必然的にc++やC#になんのかな
ソケットとか使うから
javaで作ったサーバアプリと連携とかできんのかな
何勉強したらいいんだホントに 勉強なんて楽しそうなやつやりゃいいじゃん
仕事で必要になったらググりゃいい そもそもデスクトップアプリ自体に将来性がないからね
時代はウェブ、クロスプラットフォーム。MSはもう何年もWPFに力を入れてない
俺も年内にはそっち方面に移る予定 >>833
もう開発されていない
もともとの開発チームはずいぶん昔に解散して今はメンテナンスモード >>844
WPFに限った話じゃなく、UWP以外WinFormsもMFCもメンテナンスモード
デスクトップアプリ全般にやる気が感じられない
WinFormsやWPFの移植作業中の.NET Coreはどこまで本気なんだろ さすがにUWPとWPFを同じ扱いするのは技術者として無知でしょ。 もう10年以上前から「デスクトップはオワコン、これからはWeb」とか言われているけど
いまだにWeb技術でスタンドアロン並みに使いやすいGUIを実現するのって聖杯探しだよな。
WPFもオープンソース化されたことだし、ここはひとつBlazorで動くようにしてくれないかな。 >Web技術でスタンドアロン並みに使いやすいGUIを実現する
Silverlightが死んでなけりゃな…… >>848
BlazorとWPFは全くべつもんやろ… そりゃ別物だろうけど。RazorあってのBlazorだからWPFとは排他だ、と言いたいのかな？ >>848
企業内で使うシステムでデスクトップオンリーの見たことないわ
もう全部ブラウザ経由だよ >>852
全部ってすげえな
Chrome OSでも使ってんの？ ツールとシステムを一緒にするバカは置いといて、うちも社内システムは全部ブラウザだな 勤怠チェック
給料計算
顧客管理
生産管理
最近100社以上のシステム見たけどほぼすべてブラウザ経由
どこの会社のどれをとっても最近はデスクトップアプリなんてどこにもない
今はwebの時代というのはあってる なんで勤怠管理とかでブラウザを経由する必要があるんだ？
全く意味がわからん
極端な話そんなもんエクセルVBAでも作れるし、そっちの方が安いよな
いちいちjava scriptに仕事させてブラウザで結果見るの？
それともサーバ構築までしてサーバ側のjavaとかに仕事させてるの？
わざわざそんなことする必要性がどこにあって、なぜそんなことをしてるんだ？意味がわからんな
流行りだからってことか？
まぁ流行りには乗りたいし俺もwebに移ろうかなぁ・・・
俺のC++、C#がほとんどの開発経験でweb側で高単価で雇ってくれるならすぐにでも移りたいわ 端末に依存せず、更新管理も楽であり、どこからでもアクセス可能
これがその環境において多くのメリットをもたらすなら、検討の価値がある
開発者としては何より経験値を積めることがおいしい >>855
勤怠システムに含まれる打刻ツールはデスクトップアプリやな いろんなシステムのバックエンドで動くバッチやワーカーもWebじゃないね >>859
未経験なわけないじゃん
デスクトップアプリに比べたら業務での経験がめちゃくちゃ経験が短いってだけ
でもwebも簡単だし普通にできる
そもそもWPFまでやる人間がなんでhtmlみたいなバカでもできるマークアップ言語とスタイルシートと簡単なスクリプト言語が理解できないのよ、そんなわけないわ
xamlの方が遥かに難しいマークアップ言語なわけだし、C#の方がJavaScriptより難しいだろ
いくらwebに移るといっても安単価じゃ受けませんよ、私のようなプロがね 100人やそこらの自社のみで使う勤怠管理なんて何でもいいよ
もっと利用者が多かったり複数企業で流用したりとか考えたらブラウザさえあれば済むwebアプリがどんだけ有用なことか
スマホ対応、mac/win対応もwebならコスト減らしやすい
インストール不要、ドキュメントもwebで対応できる、アップデートも利用者を気にしなくて実施しやすい
チャットワークやサイボウズがどんだけの企業で採用されてると思ってんの
開発者ツールでみてもBTSやCIもだいたいwebじゃないか >>863
>開発者ツール
Visual Studio 会社に入ったころは残業時間は表に手書きで自己申告してた
上司がチェックしてハンコ押して部長に回ってた
それをまた手計算してタイムカードと比べてチェックして給料に反映されてた
無駄だけどそれしかなかった
そのうちそれがexcelの表に記入して共有サーバに提出に変わって今はブラウザから申請になった
専用アプリを作ってメンテナンスしたり各PCに必ずエクセル入れたりという状況から抜け出せて良かったのではないかなあ >>865
ブラウザからの申請を記録するものは専用アプリとは違うんかい？
用途を無視してシステムを語るやつは脳内環境だから何言っても無駄か・・・ >>860
> 勤怠システムに含まれる打刻ツール
なにそれ？ 自分の狭い観測範囲だけで能書きたれたがる低脳が多いんだよ さすがにクラサバはWebに置き換わったけど、ツール類はいくらでもあるなぁ。 >>866
デスクトップアプリの話をしてるんじゃないの？ 今度仕事でWPF触らなくちゃいけなくなって初めてマークアップ言語に触れたんだけどとにかく読みにくい
for文だって入れ子減らせ読みにくいってのは当たり前に言われるというのに
どこからどこまでがどう入れ子になってるのが掴むの大変なんだけど慣れると読めるようになるもんなの？
あとそれと上の方でWPFに未来が無いとか書かれててがっかりしました
だよねー……日本語の参考書全然無くて海外のサイトばっか見てるもん…… >慣れると読めるようになるもんなの？
まあインデントさえしっかりしてれば >>872
どんな環境で開発してるのよ
ちょっとまともなエディタならXMLの中身を畳んだりタグの入れ子間違いを指摘することぐらいはできるぞ そうは言ってもXAMLは読みにくい。途中でコメントはさめないのとかほんとしんどい
VS2019使ってて拡張機能でXAML Stylerを入れてるけど、他にいいのあったら教えて下さい xaml stylerって拡張入れたらなんとかなる なんで最近スレ伸びてんのよ・・・
やっとWPFに普及期がきたか。 >>875
> そうは言ってもXAMLは読みにくい。途中でコメントはさめないのとかほんとしんどい
途中がどこなのかにもよるけどコメントは入れられるでしょ XMLをマークアップの標準にしたのはコンピュータ業界の最大の失敗 Blend for Visual Studioってまさにxaml編集用に作られてると思うんだけど…
あと、xamlというかxmlをそもそもよく分かってないんじゃないのっていうレスがちらほらある
あれダメならhtmlとかも理解できないでしょうに namespaceさえ理解すればあとはhtmlと大して変わらんよね。 >>879
例えば、
<Grid
<!--こことか-->
Property1="a" <!--ここに入れたい-->
Property2="b"
..... /> >>883
普通に
<!--
□□の設定
Property1 は〇〇
Property2 は△△
-->
<Grid
Property1="a"
Property2="b"
..... />
ってやれば良いだけだろ >>884
いや、それはそうなんだけど…
まずプロパティが多いと縦に伸びるし、目移りも無駄、
プロパティ名の入力も面倒だし、重要な情報を見落とす恐れもある
それに部分的にプロパティを抜いたり、別の値でテストしたい時とか、
プロパティをその位置でコメントアウト出来れば凄い楽
>>885
その辺は分からないけど、どうにかならんかったのかなといつも思うんだよね >>886
そんなに多くのプロパティを設定するのってどういうとき？
今までの経験だとせいぜい３〜４だと思うんだが・・・ 自分の思う通りに出来ないのは仕様がおかしい
って思っちゃうタイプなんでしょ
プログラマーにはあまり向いてないと思う >>888
例え3つでもコメント行が上に複数行も乗っかるのは嫌だわ
ただでさえxamlは縦に伸びるからね。フォーマットの仕方にもよるけど
プロパティの設定は大体4つ以内に収まるね
多いのだと例えばGridViewの設定かな。イベントの登録だけで4つ使ってたりする
>>889
コードビハインドでViewを構築しろってこと？ちょっとそれは頂けない
>>890
仕様がおかしいなどとは一言もいっとらんが
そもそもプログラマーで言語に不満を持ったことない人なんているんか >>891
なんで全てのプロパティにコメント残す必要があるの？
内容変更するのにコメントで残すってやつも、その項目全部をコピペしてコメント書いておけばいいじゃん。
つか、今時前のコードを残すのはバージョン管理に任せろよ。
条件に合わせて柔軟に対応できないとプロとしてやっていけないよ。 >>892
ちょっと待ってくれ。全てのプロパティにコメントを残したいとは言ってないぞ
例えばいくつかのプロパティについて、メモ書きや注意事項を残したいことってないの？
俺はただそのプロパティの上や横に書けたらいいのにな、と言ってるだけなんだが。
あとは行をその位置でコメントアウト出来れば、テストとか楽だし
一応プロとしてやってますよ
というか不満持ってる人って少ないのかな。長年不満を抱いてたから意外だったわ そもそもWinFormsだってプロパティーにコメント振らない 一応確認なんだけど、viewmodel使ってるのかな？
本来バインディングされるプロパティがあるのだからそっちにコメント入れれば良いと思うけど
viewにヅラヅラ説明を入れる状態が想像できない xmlの属性レベルのコメントができないのを仕様の欠陥扱いしてる人は結構いるよ
今回はマークアップ言語の話だけど、
既存のプログラミング言語に不満持ってるプログラマーが新しい言語を作るんだし
不満を持つことと対応できないこととは関係ないよね
んで、 Holy Hell!! な解法
https://stackoverflow.com/questions/2073140/why-cant-i-comment-attributes-in-xaml > xmlの属性レベルのコメントができないのを仕様の欠陥
ほんとこれ不便 未経験者から質問するけど、XAMLって独自プロパティ追加できないの？
HTMLなら勝手プロパティでコメント書いたりしたけど。 そもそもxaml（xml）を手で編集すんなってことにしたいんじゃない？
jsonなんかも大きくなると手編集向いてないし
とはいえ現状じゃそういうわけにはいかないけど
xaml自体を分割して見通しをよくするとかくらいかね >>893
そういう欲求はある。あると便利だよねえ 思う通りに出来ないなら出来るように作っちゃえばいいじゃない コメント振れないことと言うより
デバッグしているときにプロパティーをコメントアウトしにくいのが辛い
ブロック終わらせてコメントアウトっすりゃいいんだが面倒だ >>902
属性名変えればいいだけじゃん
Property1="a"
↓
xProperty1="a"
とか
応用力なさすぎ >>904
存在しないプロパティ名にリネームすれば無視されるから
コメントアウトの代わりに使える <a>
<a.b>
<c d="d">
</a.b>
</a>
でそれぞれa,b,c,dをコメントアウトするのに最適な方法は？ >>907
今時コメントアウトなんぞ要らん
gitを信じて消せ >>907
お前日本語下手そうだからコメントアウトした結果を書け 正直この先何年もXML引きずるのかと思うと憂鬱だわ >>896
>xmlの属性レベルのコメントができないのを仕様の欠陥扱いしてる人は結構いるよ
XMLに関してはそうだが、XAMLに関してはプロパティ要素構文が使えるんだから
プロパティ要素構文にして、その後ろにコメント付ければいい デスクトップアプリマンってWPFできようがUWPできようが時代遅れなんかな
7年くらいずっとデスクトップアプリばっかやってきたわ
あとはせいぜいゲームとか
WEBは半年もやってない
ASP.NETマンになればブレイクスルーできるのか？
.NETに全てを託すしかねーわもう
WPFが死のうがUWPが死のうが.NETだけは共通の技術だから食ってけるよな？ .NET Coreが迷走してるからわからんよ
今んとこASP.NET開発者の移行はさっぱり進んんでない
苦し紛れのWinForms&WPF対応という奇策もスルーされたら.NET Coreは3が最後のバージョンになるだろうな
そしたら.NETは終わりだ >>914
electronのデスクトップマンになれば延命できるぞ .NET Core 3の苦し紛れ感はSilverlight3の悲劇を彷彿とさせるね >>917
Silverlight3の顛末をググってきたらいいんじゃないかな
今の.NET Coreと状況がそっくりだから
だから失敗すると言いたいわけじゃないが、MS社内のプロジェクトのライフサイクル的に見切りを付ける時期が迫ってきているんだろう 「終わり」ってどういう状態を言っているのかにもよるな。
MFCは既に「終わり」のような気もするが、使えなくなったわけじゃないしな。 >>922
MSはプロダクトを見捨てる前にきっちり完成させるからね
WPFは例外だが WPFはファイルダイアログとかの仕組みをまともに作らなかったよね
みんなが欲しがるものをあえてスルーしてたのはなぜなんだろう？ デスクトップアプリの肩身はどんどん狭くなる
今の元号変更にしたってアプリがweb化されていたらサーバサイドを変更するだけでいい
これからデスクトップだったもののweb化（html化）は加速するだろう >>924
ファイルダイアログはあるだろ
無いのはフォルダーダイアログ Windows API CodePackが事実上のオフィシャルリリースだろうに >>926
Webくんは妄想性人格障害なだけで現代っ子だよ フォルダ選択ダイアログってファイルダイアログに統合されただけだよな。
もともとあれは使いにくかったし。 >>930
人格障害だけでなくガイジも患ってるみたいだね…
ママさん仕事して〜
生ゴミはコンポストに捨てといてね NumericUpDownがないのは作り忘れなの？ ちょいちょいそれ出してくる人いるけど、そんなに重要なコントロールか？
あればあったでいいけど、作れよそんくらい。 wpfに足りないのは洒落たｔｏｏｌｋｉｔだと思うんだがな
JavaFXみたいでいいからcss使えたら大分変わっただろうが レス数が900を超えています。1000を超えると表示できなくなるよ。
