WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part22

Windows Presentation Frameworkについて語るスレ。

前スレ
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part21
http://mevius.2ch.ne...cgi/tech/1494288553/

関連スレ
Windows 10 UWPアプリ開発 Part 2
http://mevius.2ch.ne...cgi/tech/1499658092/

コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/

<Grid>
<Canvas>
<Path Data="M 29.602622 23.073567 0.97801322 35.798371 V 31.333527 L 23.550279 21.535676 0.97801322 11.737825 V 7.272981
L 29.602622 19.997785 Z M 71.175277 23.073567 42.550668 35.798371 V 31.333527 L 65.122933 21.535676 42.550668 11.737825
V 7.272981 l 28.624609 12.724804 z
M 104.36395 37.708332 H 84.37137 V 33.93802 h 7.689453 V 9.1829419 H 84.37137 V 5.8095044 q 1.562695 0 3.348632 -0.2480469
Q 89.50594 5.288606 90.423713 4.7925122 91.564729 4.1723951 92.209651 3.229817 92.879377 2.2624342 92.978596 0.65012949
h 3.844726 V 33.93802 h 7.540628 z " Fill="DimGray" />
<Path Data="m 125.10066 38.502082 q -7.9375 0 -8.33437 -5.357812 -0.19844 -3.373438 7.9375 -12.104688 1.5875 -1.5875
15.27968 -15.279687 H 116.56785 V 1.9895826 h 27.38437 l 0.99219 -0.99218749 3.175 2.18281249 q 1.38906 0.5953125 -0.79375
1.190625 -12.10469 11.7078124 -19.24844 19.4468744 -6.15156 6.548438 -6.15156 8.532813 0 2.38125 3.96875 2.38125 h 21.03437
q 2.18282 0 3.175 -1.389063 0.99219 -1.389062 1.38907 -4.960937 l 4.16718 0.79375 q -0.59531 3.571875 -1.38906 5.754687 -1.38906
3.571875 -5.95312 3.571875 z" Fill="DimGray" />
<Canvas.Effect>
<DropShadowEffect BlurRadius="4" ShadowDepth="2" Color="Gainsboro" />
</Canvas.Effect>
</Canvas>
</Grid>

Virtualized TreeViewでスクロールを繰り返すと
stackoverflowexceptionが出る件、まだ直らないのか

MVVM的に真っ当にタイマー処理をするにはどういう設計にすればいいですか？
Modelでタイマーオブジェクトを管理するのはおかしいですか？

>>4
タイマの目的によると思う
定期的なビューの更新をしたいだけなら、モデルにはなるべく静的なロジックだけを持たせるようにしておいて、
ビュー側からタイマー起点で最新情報をモデルに要求する形にするほうが綺麗(いわゆるプル型)
例えば倉庫の作業管理システムで30分毎に休憩のためのアラーム鳴らすとか、
ビジネスロジック的なタイマー処理ならモデル側で時間測ってビューへプッシュしてやるべきだろうね

補足しとくと、VMはビューに含まれると考えてくれ。
ビューにタイマを持つと決めたなら、VかVMのどちらに置くかははっきり言ってどうでもいい。
MVVMはあくまでビュー層に閉じたデザインパターンであって、
モデルとの役割分担さえ守れてればあとは大した問題ではない。なんならVMなんか無くても大枠には影響しない。

>>5
定期的にサイトをダウンロードして解析してメール送信等を行うプログラムの場合はどうしますか？

>>7
モデルというか内部処理側だな
少なくともビューに直接埋め込むのは無い
あと、そういう単画面のツール的なアプリにVMは要らん
MVVMはDBの単純な読み書きをしたりするだけの紋切り型の画面を大量生産するのに使うんだよ

>>7
Mでいいんじゃないかな。
タイマーは単体テストするならインターフェース挟んで実装差し替えれるようにしておくと幸せかも。

WPFでMVVMパターン勉強中(Prism6 + ReactiveProperty)
ボタンとWebBrowserを配置して，ボタンを押したときにWebBrowserのRefreshメソッドを
実行したいのだが，どのように実装すればよいか教えてほしい。
メソッド自体はBehaviorで実行できるが，メソッドへのトリガのかけ方がわからない。
Messenger? ActionTorigger?あたりを使う？

あと，できればWPFの勉強方法も教えてもらえるとありがたい。

なんも処理はさまないならEventTriggerでClickイベント拾ってCallMethodActionでWebBrowserのReflesh呼んでもいいんじゃないかな

普通にイベントハンドラでやればいいでしょ
間にVMを噛ませる意味が全くない

MVVMを勉強したいだけならWPFより他の方法を取ったほうがいい
BehaviorにしろEventTriggerにしろMVVMやるだけなら要らん
Commandも要らん
焦点がぼやけるだけ

MVVMを勉強したいならテーマ選定も不適切だね
モデルが明確に定義できないものにMVVMは向いてない
自分のToDo管理システムでも作っとけ

複数選択できるチェックボックスつきのリストビュー
というのがWPF初心者には不向きな題材に思えるけども
年賀状住所録とか交通費清算フォームとかがいいんじゃない、Master-Detailな画面で

今後複雑化したら（既に複雑だから）UIとロジックを分離したいんだろ

>>16
迷ったときは原則に立ち返ることが大事。
なんでビューとロジックを分けるかというと、オブジェクト指向でいう「関心の分離」に従って
それぞれビューはビューだけ、ロジックはロジックだけに集中して開発できるようにするのが目的だ。
でMVVMはさらにこのビューを「ビューの状態とその制御」と「デザイン」とに分離するわけ。
で質問者のケースでは、大まかに関心を分離すると、ブラウザの制御、スケジューリング、ビュー、となるだろうな。
こう分離したときビューっておそらくかなり単純なものになるはずだよ。
その上であえてVMを分離する必要があるだろうか？ということ。

先に言っておくけど、バインド使いたいだけならコードビハインドにプロパティ定義すれば済む話だからね。VMを使う理由にはならない。

WebBrowserに依存関係プロパティは存在せず、かと言ってsealed宣言されてるクラス
セキュリティ上の制約という説明になってるが早い話がいじれない
他の選択肢があるんじゃないか、例えばCefSharpなら今風でナウい子向けじゃないの

前スレのポトペタできるを信じて勉強がてらユーティリティ作ろうと思ったんだけど、
フォルダダイアログって WindowsAPICodePack を入れるしかないのか？

チープな奴でよければWindows.Formsを参照に追加しても使える
何となく負けたような感じがするが気にしてはいけない
全てはMSが悪い

WPFはポトペタできるって主張したの誰だよｗ
WinForms 使ってやってみる、ありがとう

あ、WinForms のフォルダブラウザダイアログを使って WPF を使ってみるってことね

勉強なら自作するのもありじゃん？

BitmapImage を MemoryStream から読み込んで作ってるんですが、
特定の jpeg ファイルを非同期で読ませると、デコードが非常に遅くなります（他のファイルの 10 倍くらい）
同期的に読ませると普通に速いです
メモリには余裕があり、また Visual Studio のプロファイラを見る限り、GCが頻発してるわけでもありません
また jpeg を bmp に変換してやると問題は解消されて、他のファイルと同じくらいの速度でデコードが完了します
(1) なぜ特定のファイルだけ遅くなるのか
(2) なぜ非同期だと遅くなるのか
このあたり、何か知ってる方はいるでしょうか？

新規アプリ作ってその１つのファイルだけ読んでも遅いんだよね？？
まぁ、そうだしても思い当たるふしねぇな。

どこから持ってきたJPGなんだい？
ステガノグラフィや埋め込みバイナリとか付いてるんじゃない？
JPGファイルの内部をチェックしてみてはどうかな？

>>17
それらを現実のもので例えたら何？

JPEGと言ってもプログレッシブJPEGとかグレースケールJPEGとかある

いろいろアドバイスありがとうございます
眠すぎるのでわかったことだけ

問題のjpegファイルですが、セグメントを一個ずつ消してみて
デコード速度を測定したところ、APP2セグメントが問題だと分かりました
APP2セグメントを消すと他のファイルと同じくらいの展開速度になります。
BitmapImage がカラープロファイルを見ていい感じに表示しようと頑張ってるんだと思います

それにしても非同期のときだけ10倍も遅くなる理由が分かりませんが……

BitmapCreateOptionsにIgnoreColorProfileあるから、それ指定すると速くなるのかな？

>>31
どんぴしゃです
100倍くらい速くなりました
コードはこんな感じです
https://ideone.com/6iePK6

Pixel Shader Effects Libraryのプロジェクトが古すぎるから2017でもビルドできるように作り直した
8年前というとWindows 7が出たころだよな
現在でも機能が先進的すぎて使いこなせる気がしない

俺も触ってみるか

最近、海外でwpf、wpf言うから流行ってんのかと思ったらwtfだったわ

wpfで助かったｗ
製品型番で微妙に設計が違う画面設計が数十種類もあって、WinFormsではコマタだったが、wpfで事なきを得た。
WinFormでは、ロジックからGUIコンポーネントにアクセスするのに対し、wpfはコンポーネントからコントローラーにバインドする。
画面バリエーションに対し、ロジックを共通に使えるのは助かる。

winforms触ったことねぇけど、フォーム？の継承はできなかったんけか？

>>37
普通にできるよ

そっか。なら
>製品型番で微妙に設計が違う画面設計が数十種類
もWinFormsでも問題なさそうだけどな。

微妙に違うカスタムコントロールを継承先から差し替えするのか？
ChildrenからName探して、カスタムコントロール差し替え&イベント設定するのも手は手だな。

WPFに慣れると発想からしてすべてが面倒になるんだな

項目増やしたり減らしたりするのが、xamlだと簡単だってのも在るね

一部分でも誉めると親の仇を取りにくる奴がいるのは難点だな

>>41 が WPF、WinForms どっち側を勧めているのか分からない

WPF推奨： WPFに慣れると（Formsを扱う場合）発想からして（コントロールの扱いやUI差し替えなどWPFに比べて）すべてが面倒になる（面倒くさく感じる）んだな
Foms推奨： WPFに慣れると（設計についてごちゃごちゃ考えるようになり）発想からしてすべてが面倒（面倒な扱いの人）になるんだな

ちょっとしたアニメーションをつけるだけでWindowsフォームだと大騒ぎになる
WPFならトリガー入れてStoryboardでアニメーションがあっさり入る
もちろんWinformsでも頑張ればできるわけだが手数かかってしまい手早くインスタントな作りにならない

アニメーションするUIは散々ウザいってよく言われてるのにカッコイイとか思ってる奴もいるのね。
flashのUIがウザい理由もそれ。

やっとXAML分かってきたわ
最初の一歩の敷居高すぎやろ
魔除けかよ

>>46
WindowsのOS自体がアニメーションだらけの時代に、化石みたいなこと言う人いるんだな

>>46
アプリの動作とは全く無関係なアニメーションがウザいだけ。

VS2008のアニメーションは最低最悪のUXだったよな
オフにできるとはいえ、WPFになる直前の史上最高完成度のVSがあれで台無し

WidowsのアニメーションをONにしてる開発者ってかなりの初心者。
アニメーションしてるおかっこいい、最先端、革新とか言ってるのか。

マジ笑える。>>48

アニメーションはカッコいいだろ
電卓がまともに計算できなくなるとしても優先すべきだ

>>51
おじいちゃんこんにちは

やあこんにちは小僧

アップルのアニメーションなら良いのかなw

Widowsだから、恐らく未亡人アニメのことかと

>>48　←こいつ、Windowsの効果音もONにしてそうwww

iPhoneでOK

ウインドウズはもちろん若い子が夢中のアイホンにアンドロイドもアニメーションだらけ
あれがカッコイイんでしょ

アニメーションをオンにして遅くなるようなボロいマシン使うなよ。

どんなに速いマシンでもアニメーションをオンにしたら遅くなることも理解できないアホがいるとは。
ここム板なんだけど。まさかコード書けない奴までいるとは想定外。

お前はプログレスバーアニメーションのようなものまで否定するのか?

進捗しているように見せかけるプログレスバー(ブラウザに多い)は死ね

ｗｐｆ使えない人は、こういう言い訳するんだな
出来ないのに出来る人を蔑むプライドっって笑えるね

>>63
失礼なことを言うな

進捗率の「%」部分が
「%」と「I」が交互に表示されて
動いてるように見えるだろう

でも、死んでるんだけどね

実年齢は分からないけど面白いお爺様がいるのね (´・ω・`)

視線誘導とかの目的にはアニメーションいいと思うけどね。

>>60はたぶん体感の話
>>61は日本語の理解力が足りないアホ

>>68 ←こいつすげー馬鹿。アニメーションの実装したことないことがバレバレ。

アニメーションがかっこいいとか遅いとかそういう事言い合ってるのに、突然実装の話しだす。無理するなよw

横レスだがWindowsのアメニーションを体感で遅くなるとか言ってる人はWindows使ったことないと思う。
Windowsのアニメーション装飾が何の機能か知らない人の発言。おらそく馬鹿マカー。

当たり前だがPCの速度でアニメーションが早くなったり遅くなったりするような実装になってない。
だから速いPCにしろというのはさすが意味不明、筋が通らない。体感なんてなおさら関係がない。
MS開発者はアニメーションはふつうOffにすることすら知らないんだからやはりマカーだね。
Appleは古い機種をアップデートすると故意に遅くなるようにしてたらしくて訴えられたが。

> 視線誘導とかの目的

これが嫌われてる細大の理由だね。flash=詐欺広告、下品なエロ広告

夜中までご苦労さん w

>>69
今更アニメ作れるみたいなこと言い張ってもバレバレですわ、爺様

すまんのう、ガンダム世代の爺なのぢや

>>73
もしかして本当に呆けてるの？

Windowsのアニメーションをオンにしてる開発者を一度もみたことない。
顧客からもアニメーションのオフにする方法は聞かれるが仕様でアニメーションにしてくれなんて要望されたこともない。さすがに無職でしょう。

パフォーマンスオプションの視覚効果のことなら今どきのPCならデフォルトでONだろうが、
開発者でもわざわざOFFにしてる奴なんて見たことない。

他人のPCの設定を念入りにチェックする奴なんて見た事ないわ

>>80
他人のPCの視覚効果ON/OFFって設定見ないと分からんのか？

作れないやつが、ほぼ言いがかりで作れるやつにマウンティングするとか笑えるねｗ
webがアニメしまくりなのに、もしかするとjavascript切るんだろうか？

よく知らないけど、iPhoneの電卓がバカなアニメーションのせいでまともに使えなかったことは知ってます

操作性を損なわない程度のものならあっていいんじゃないかい。

画面に変化のあったところを気づかせるためや、マウスオーバー時になにかできることしめしたりや、ナビゲーション時に前のページと関連のある項目をわかりやすくするためとか。

すごくアプリに慣れた人にとってはいらないかもだけど、そうでない人にとって気づきやすくさせるために使えると思う。

エロ広告みたいなうざいやつだけではないから、適切に使えばいいだけの話。そして、WPFには組み込みのアニメーション機能があって、そういうのが無いプラットフォームよりも楽に作れるってだけじゃん。

なんで言い争ってるの？

組み込みのアニメーションが憎くてしょうがない
WPFにメリットがあってはならない

僕は林檎るdisることができればスレの流れは気にしません

そんなに楽なのか
俺はトランジションが難しすぎてドハマりしてるけどな
アーティファクトを発掘したはいいが使い方がわからない感じ

操作の遅延動座でしかないアニメーション装飾で喜ぶなんて小学生低学年までとマカーだけだろ。

人間はそういうふうに思うんだからいいじゃない

WPFの次はアニメーションが親の仇かw

正月ということもあって勢いでスライドショーするソフト作ってみたが
アニメーションが重いというのはないね、軽快で快適
どちらかというとダウンロードの仕組みが入ると遅い
上手いこと先読みしたりキャッシュしとかないと無理あるね

本気で言ってるなら頭の病気。

XPと秀丸をこよなく愛してそうなおっさん

WPFむずいわー
今日はTreeViewをやった
けどTreeViewってWinFormsでもむずいんだよな
むしろFormsのほうがむずいまである
はあ〜しんど

>>94
正直なところTreeViewをMVVMであれこれやるところが一番めんどくさい
やらなくていい

ComboBoxも結構面倒だと思うよ、TreeViewより頻出だと思うし
文字に色つけたりアイコン画像入れたり

このスレまだあったのか。しかも伸びてる。相変わらず普及しない、ゴミという話題ばかり。

今年は飛躍の年になる
たぶん

あるならこれよりマシなGUIフレームワークを教えて欲しいわけだが

WPFはシステムであってフレームワークは自分で構築するか、既存のフレームワークを導入する必要がある
以前からWPFがむずかしいと言われる理由の一つがこの導入コスト学習コストの高さ

Visual Studio InstallerもElectronで作られる時代

VisualStudio本体もWPFで作られてるというよりWPFを描画と入力に使った独自フレームワークだからね
次のVSは本体にもElectronが入ってくるだろうけど

>>102
なぜそう思った？

VisualStudioのIDEってサードパーティー製のコントロールを使ってるって以前聞いたけど
本当なのか？

グレープシティは入ってたはず

MVVMの本質ってModel View ViewModelに分けることであって、
データバインド機能がなくてViewとViewModelを手動で結びつけててもMVVMです？

手動でやるとMVVM以外に結びつけるクラス(コード)が必要ですけど。

本質はまあそう（責務の分離）かも知れんが……

>>106
MVVMはバインディングを効果的に利用するためのパターンなので、本来はバインディングを使わないならMVVMとは呼ばない
手動でやるのはMVVMの基になったMVPとかPassive Viewっていうパターンがある

>手動でやるのはMVVMの基になったMVPとかPassive Viewっていうパターンがある
WPF発祥の地ということ詳しい人がたくさんいるのはここだと思って
でここで質問したんですが、実際はWPFは関係なくてJavaScriptのWebアプリなんですよね。
で、実際、クラスを設計しようとして、モデルクラスつくって、次にビューモデルクラス作ってと
やってビューのフレームワークは実際React使うですんが、Reactはデータの流れは１方向で
ビューで発生したアクションは手動でビューモデルのメソッドを呼ぶように作ろうとしています。

で、責務的にはMVVMっぽくわけてるんですが、これMVVMって呼んでいいのかなとふと疑問に思ったもので・・

MVPとかPassive Viewとか前にチラッと言葉だけは覚えたんですが、調べてみます。

どうでもいいけど、
WPF発祥の地
は
MVVM発祥の地でした

reactならfluxでしょ
少なくともビューとC/P/VMを双方向に同期させないのはデータフロー的にもMVVMとは根本的に異なるよ

fluxというかreduxはややこして、今mobx使おうと思ってます。
>ビューとC/P/VMを双方向に同期させない
だからこれを手動で双方向に同期させようとしてるんです。

>MVVMはバインディングを効果的に利用するためのパターンなので、本来はバインディングを使わないならMVVMとは呼ばない
つか、仮にそうだとすると、バインデイングの機能を単に誰が用意するかの話問題になっちゃういますよね？？

自分で手動で用意するか、標準で用意されてるか誰か他の人がバインディングライブラリを作ってそれを利用するかの・・

それでMMVMと呼ぶか呼ばないかが決まっちゃう。
うーん。

共通の仕組みを使うのと毎回手書きするのは違うだろ

https://qiita.com/ta...597c48ece57b4623cdee
ちょっとPassive Viewについて見てみました。おっしゃる通り本質的にはMVVPとデータフローは
同じでビューと(ビューモデルまたはプレゼンター)間がデータバインディングされてるか
されてないかの違いっぽいですね。

そうなると自分のはMVPかな？
クラス名の末尾をViewModelではなくPresenterにしとけばいいかなw

>おっしゃる通り本質的にはMVPとMVVMはデータフロー
に修正します。
誤字がひどくてすみません。

正直、実装するときにはどうでもいい話だな。

今日はComboBoxをちょっとだけ勉強したで
ワイWinFormsではデータセットからポトペタしてたんやけど同じようにできるっぽいんかこれ？助かるわ。
せやけど表示のカスタマイズ方法が馴染みなさすぎてｵｯｻﾝついていかれへんで

オーナードローよりは遥かに春かに簡単

データソースからポトペタしたデータグリッドのコンボボックスそのままやと使いもんにならんやんけ
これだけで1週間かかったわ
あったまっがパーン

かっそ過疎やな
せやけどXAMLおぼえたらあんまり話すネタないよなこれ

もう使ってる人いなくて新しい話題がないからね

登場しからずっと話題は、普及はまだ？ 馬鹿には使えない!!　のループだったな。

UWPスレよりは人いるから…

しかしWindows用のデスクトップアプリを作るとなったとき、現実的な選択肢はこれしかなくないか？
UWPは10用だし、マルチプラットフォームのあれこれはまだ発展途上で、
結局シングルソースじゃなかったり容量が馬鹿でかくなったりするし

>>126
Electronで十分だわ

>>127
容量がおかしいのそれだよ
Electron製で50MB以下のパッケージ見たことない
インスコしたら200MB超えましたなんてのもザラ
ついでにメモリも大食い

>>128
で？

で、>>126に戻る

>>130
ただ、Win10その他の制限が問題ない場合はUWPが良いよ
特に起動が１０倍単位で早いってのがね
コンパイルは１００倍単位で遅いけどね

>その他の制限が問題ない場合はUWPが良いよ

そりゃ、マイナス条件がないならプラスしか残らんのは当たり前だわなw
同様に、WPFの制限が問題ないならWPFが良いし、WinFormsの制限が問題ないならWinFormsが良い。

>>132
Fornsのアドバンテージは人足を集めやすいことで、wpfは特別な制約はなくて強いて言えばGridViewなどが遅いことぐらい
UWPは逆汗が難しいことやパフォーマンス。それとｔｏｏｌｋｉｔが標準で用意されていること

それぞれ使い分け出来たら良いけど、人足集めるのが大変だわなwpfとuwpは

メトロUIは業務系ユーザーに不評だから提案する気になれない。

wpfのネイティブコンパイルが出来れば全て解決なんだがなぁ
進んでるのかな

せっかくXAML覚えたのに来月からJavaScriptの仕事になってもうたわ
けどワイMS製品で育ったしいつかまた会うやろ。じゃあの・・・

コロコロと違う言語やプラットフォームに技術者をぶち込む企業はさっさと転職したほうがいい。

若いうちならご褒美だろう。

20代ならなー

俺は45過ぎてからC++とGPGPU始めて、50近くになってTypeScriptとSPAやってるとこだわ。

このスレ加齢臭がする

４０・５０過ぎてもC++とか理解できますか？

>>142
地頭とプログラミング適性次第

c++の文法ルール自体はそんなに難しくない
自動でメモリ解放してくれるようにもなったし
c++は生まれ変わった

でもライブラリなどがレガシーの塊なので非常に地獄

>>142
CとC++の壁？　かなり高いよ。
年齢は関係無い。

C#はすっと頭に入ったけど、C++はなかなか入らないですね
特にMFCというのが昔から苦手で今日まで来てしまった

別にMFCはC++の構成要素じゃないよ

好きなフレームワーク使えばいい

だいたいwpfでC++もないやろ
なんでそんな話になってんだ全く

次々からフレームワークが出て習得するのが面倒だよな。PGはそんなに暇じゃないっての。
フレームワークを使い捨てにするMSはアホ。wtfだってまだ使ってんだよ。
というか.netの売りは言語自由だったはずなのにwpfではC++を排除してるのかよ。ほんと嘘つきだな、MSは。

.NETのウリは言語自由って初めて聞いたが
いくつかの言語から選べるってのはよく聞くけど

WPFおもろいわ。

仕様拡張も含め、.net core対応ｷﾎﾞﾝﾇ

全く。マウンティングするための道具として最高におもしろいわ。

WPFはエヴァンジェリストとブロガーのオモチャ。

Windows10,VS2017でWPFでWindowChromeちゃんを使って、
Windowのスタイルをカスタマイズしようとしてるんだけど、
タイトルバー高さをSystemParameters.WindowCaptionHeightで取得すると
23が返ってくるんよ。で、これ実際にPhotoshopとかで測定すると、31ぐらいなんだけど、
これって、もしかして72dpiと96dpiの違いで、96/72=1.333...をこの23に掛けてるんかな？
例えば、電卓の右上の[X]ボタンはH:30,W:48なんだけど、
SystemParameters.WindowCaptionButtonWidth=36
SystemParameters.WindowCaptionButtonHeight=22
36 x 1.333...= 47.999999
22 x 1.333...= 29.333333

こういう資料って、公式のどっかに説明あるんでしょうか？

>>151
わたしもきぼんぬ

>>154
試してないけどこれはどう？
http://blogs.microso...ow-client-area-size/

>>156
どうもThemeの方にヒントがあるようね。
Firefoxのソースでも、Themeからひろってきてるみたい。

デザイナ画面で、現在作業しているプロジェクトファイルのパスが取得したいのですが、方法ありますでしょうか？
AssemblyやGetCurrentDirectoryを使ってもXDesProcのパスが返ってきて取得できません

TreeView を操作していると、StackOverflowException 例外で WPF アプリケーションが強制終了します
https://blogs.msdn.m...eption-wpf-47-crash/

まだ枯れてないのか。

ComputeFirstItemInViewportIndexAndOffsetがFloorをつかっている件か

datagridにおいて、以下のようなキーボード操作はXAMLだけで記述できますでしょうか？

・セルのtab移動を止める
・enterキーで次の行に移動するのを止める（矢印キーのみで移動）

DataGridは未完成糞品質のまま開発打ち切られて放置されたままのゴミだから使っちゃダメ
WinFormsのをホストして使うかサードのを買うかListViewでスクラッチするかWPFを捨てよう

>>163
行数少なければ十分使えるから、数百行表示させないようにプログラムすればいいだけですね

2ヶ月ちょいjs/javaやったけど
Eclipseはポトペタできへんから面倒くさすぎる
いやワイが知らんだけかもしらんけど
しかしIDE落ちまくるし同期とらんと時々嘘くさい表示しよるし何なんやこれ
隣の席のやつ(javaﾏﾝ)はWPFやらされててワカランワカランいうてるし
ちゃんと履歴書読んどんのかここの会社逆やろｗ

そう思うんなら便所に落書きするより上司に相談しろ
喜んで入れ替えてくれるだろ
その程度の交渉や調整もできないカスなら何やらせたってダメだし、会社もお前に何も期待しないよ

eclipse使ってる企業なんてまだあったんだ

替わりたくないんやが
ちな会社は赤字垂れ流して潰れそうやでw

嘘みたいな話だけどeclipse大好きっこているんだぞ

一個も共感できないeclipse自慢話してくるよ

eclipseはモダンemacs的な開発者のオープンプラットフォームとして、
今でいうVSCodeに近いポジションを占めてたから、そういう面ではわりと根強いファンはいた
今ではJavaはIntelliJに取られemacs的な用途はVSCodeに取られ完全にオワコン

>>169
あるある

GridSplitter を挟んだUIを作成中です

<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="1*"/>
<ColumnDefinition Width="Auto"/>
<ColumnDefinition Width="3*"/>
</Grid.ColumnDefinitions>
...

上記のように Columnの幅を1:3などの割合のまま、
Properties.Settings のメンバに Bind するにはどのようにしたらよいですか？

下記のように書いてみましたが、いくつか問題にぶち当たりました
<ColumnDefinition Width="{Binding Source={x:Static p:Settings.Default}, Path=ColumnSplitterSize, Mode=TwoWay}"/>

・Column の幅を変更して、Settings.Default.Save() しても Settings に反映されない（Settings の他の値の変更は確認済み）
・Settings の要素の型に GridLength を指定した場合、3* などを指定できない（数値かアスタリスクのみ）
・1:3 などの割合を指定したまま、サイズを保存、復元する方法があるのか不明

グリッド幅の保存は基本だと思うので簡易な方法があると思うのですが……

GridLength 構造体

>>173
はい、GridLength 構造体です
Settings の要素の型を GridLength にしても反映されないので質問しました

何か基本的なことを見落としてるような気がします

GridLength GridUnitType.Starでぐぐる

>>169
マルチプラットフォーム的なのが少なかったんで
選択肢がそこに居ちゃっていたってことじゃないんかな？

>>172
１：３なのに、なんでAUTOが入ってるの？

>>177
GridSplitter

試行錯誤しつつ、あれから冷却期間を入れて試したところ 2番目の問題は設定できるようになりました

>>175
> GridLength GridUnitType.Starでぐぐる
「・Settings の要素の型に GridLength を指定した場合、3* などを指定できない」
ことへのコンストラクタを使ってコードを書くべきというアドバイスかと思います

本当に申し訳無いのですが当方の思い込みが含まれていました
実際に試した値は「1*」で、書き込むと「*」になるため、誤認していました

正しく書き直すと、
プロジェクトの「プロパティ」→「設定」→要素の「型」で
PresentationFramework の System.Windows.GridLength を指定した
ケースでの「値」列の内容について、XAMLで指定できる文字列「1*」を指定できず、
書き込むと「*」になるということです
Settings.Designer.cs での DefaultSettingValueAttribute の引数の文字列です

試しに「3*」を入れたところ、3:3(=1:1)に指定できましたので Settings で初期化はうまくできていましたので、
2番目の問題は解決しました
（「1*」は値として同じ意味の文字列「*」に自動で変換されるみたいです）
XAMLは下記のとおり、
<ColumnDefinition Width="{Binding Source={x:Static p:Settings.Default}, Path=ColumnSplitterLength}"/>
<ColumnDefinition Width="Auto"/>
<ColumnDefinition Width="3*"/>

ただ、Settings で指定は可能なのですが、Grid.Width プロパティは実際のサイズに連動しておらず、
Mode=TwoWay を追加しても、肝心の1番目、2番目が解決できませんでした
実際のサイズに連動するよう少しずつ調査する予定です
（ActualWidth:double を読み取って、GridLengthのコンストラクタを使って Settingsに保存する？）

>>178
はい、GridSplitter を挟んでGridの列を 1:3 にするXAMLの書き方になってます

あああ、typo です
「ただ、Settings で指定は可能なのですが、Grid.Width プロパティは実際のサイズに連動しておらず〜」
ColumnDefinition.Width プロパティの間違いです

175は忘れてください　
Value+GridUnitType　<--> 文字列 相互変換できてました
フォルダー　<UserName>\AppData\Local\<アプリケーション名>
の下のほうの user.configに書き込まれているはず

splitterの幅をバリアブルにしている理由はなんなの？

ま、いいか理由はあるんでしょうから。

質問させてください。
以下の画像のようにウィンドウの表示がSizeToContentの値によっておかしくなる場合があるのですが、
対策方法など分かる方がいらっしゃれば教えていただけないでしょうか。
https://dotup.org/up...dotup.org1526890.png

VSのバージョンは15.6.7、ターゲットフレームワークは4.7.1、
実行環境は Windows 10 で「拡大縮小とレイアウト」の設定は100%です。
XAMLは以下の通りです。どうぞよろしくお願いいたします。

<Window
　　x:Class="SizeToContentIssue.MainWindow"
　　xmlns="http://schemas.micro...l/presentation"
　　xmlns:x="http://schemas.micro...infx/2006/xaml"
　　xmlns:d="http://schemas.micro...ion/blend/2008"
　　xmlns:mc="http://schemas.openx...atibility/2006"
　　mc:Ignorable="d"
　　Width="213" Height="55"
　　SizeToContent="Width"><!--←Width を Manual に書き換えると正常に表示される-->
　　<Grid>
　　　　<TextBlock>
　　　　　　<Run Text="{Binding Width, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type Window}}}"/>
　　　　　　x
　　　　　　<Run Text="{Binding Height, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type Window}}}"/>
　　　　　　縦棒が入ったり入らなかったり→
　　　　</TextBlock>
　　</Grid>
</Window>

>>184
SizeToContent paints an unwanted border
https://stackoverflo...s-an-unwanted-border

<Window UseLayoutRounding="True" />
でとりあえずその線は消えた

>>185
レスありがとうございます！私の方でも線が消えることを確認しました。
Webで検索しても答えを見つけられなかったので質問させていただいたのですが、
恥ずかしいことに紹介していただいたページは見落としてしまっていたようです。

何はともあれ、お答えいただきどうもありがとうございました。

>>184-186で自分の検索の不十分さを反省して以前から抱えていた別の問題も改めて検索してみたのですが、
やはり私の力ではどうしようもありませんでした。
立て続けに申し訳ないのですが、こちらについてもお力を貸していただけないでしょうか。

以下のような Binding のマークアップ拡張を作成したところ、
Mode が TwoWay のときは期待通りに動作するものの、
Mode が OneWay だと正しくバインディングできずに困っています。

class MyBindingExtension : MarkupExtension
{
　　public PropertyPath Path { get; set; }
　　public BindingMode Mode { get; set; }
　　public override object ProvideValue(IServiceProvider serviceProvider)
　　{
　　　　var service= (IProvideValueTarget)serviceProvider.GetService(typeof(IProvideValueTarget));
　　　　var target = (DependencyObject)service.TargetObject;
　　　　var dp = (DependencyProperty)service.TargetProperty;
　　　　BindingOperations.SetBinding(target, dp, new Binding { Path = Path, Mode = Mode });
　　　　return target.GetValue(dp);
　　}
}

（続く）

（続き）

原因はほとんど分かっていて、

・Mode が OneWay のとき、ターゲット側が書き換えられるとバインディングがクリアされてしまう
・ProvideValue が呼び出されたあと、その戻り値でターゲット側が書き換えられる

ということだと思うのですが、この問題を解決する良い方法が見つかりません。
苦肉の策として、SetBinding の行を次のように書き換えればとりあえず動作することが確認できています。

　　　　// BindingOperations.SetBinding(target, dp, new Binding { Path = Path, Mode = Mode });
　　　　Application.Current.Dispatcher.BeginInvoke((Action)(()
　　　　　　=> BindingOperations.SetBinding(target, dp, new Binding { Path = Path, Mode = Mode })));

ただ、バインディングのタイミングがずれてしまうと、
例えば SetBinding してから ClearBinding したつもりが順番が逆転してしまうなど
思わぬバグの原因となりかねないためできれば避けたいと考えています。どうぞよろしくお願いいたします。

良かったなお前ら
https://blogs.msdn.m...esktop-applications/

YATTA!

やるやん

日本語でOK

Windowsでしか動かない.NET Coreアプリw
一体何の意味があるのか

せっかく.NET Coreが盛り上がってきてたところだったのに、水を差すことになりそうで心配だな
Linuxサーバーで運用してる人達からしたら、結局梯子外してWinに誘導するいつものMSがまた正体を現したかと疑念を持たれるよこれ

>>193
Windowsにインストールされた.NET Frameworkに縛られなくなる

>>194
そもそもWindowsでしか動かなかったもののランタイムが変わるだけだし、corefx自体に追加されるわけじゃない
むしろ.NET Coreの普及を後押しする

実質何も発表なかったこと一緒ってこと?
.NETは完全にWinプラトフォーム環境限定ということでオワコン

サーバーサイドはクロスだけど微妙にしか人気ねぇし、Xamarin捨てる勇気なかったのか

>>197
どこをどう読んだらそうなるんだよｗｗｗ

.NET Core 3ハWindowsデスクトップアプリをサポートする
https://www.infoq.co.../net-core3-announced

開発者が、既存の.NET Framework for Windowsではなく.NET Coreを使いたい理由はなにか？
それにはいくつかの理由がある。まず、.NET Frameworkとは違い、.NET Coreアプリは完全に独立しており、異なるバージョンの.NET Coreを使用することが可能だ。
.NET Core 3の新しいオプションでは、.NET Coreランタイムと組み合わせて実行できる単一の実行ファイルを生成することが可能だ。

この発表に反応した開発者は、WPFとWinFormsをGitHub上でオープンソース化する可能性について尋ねた。
興味深いことにこの要求は、Lander氏に否定されてはない - Microsoftは将来的にオープンにする可能性がある。
コミュニティの主な望みは、これらをmacOSやLinuxに移植するよりも、Windows用のGUIツールキットの拡張とモダン化である。

.NET Coreが全然注目されないからいろいろやりだしたんだな

いままでの.NET Coreって誰から見たら魅力があるのかわからない微妙な物だから
積極的に使いたいと言う人は少なかった

日本は全体的に低レベルなエンジニアが多い
なのでUIとその他のロジックがガッツリ結合して分離できない
なのでそう簡単には.Net Coreに移植できなかった
そうする必要のないあらゆるものまでがdnfやwindowsインフラに依存してしまっていたんだ
そりゃ移植して使えないものに魅力は感じないだろう

海外では設計が綺麗なので細かいコンポーネント事に移植の可能性を検討することができた
移植可能なものはすぐに移植する動きが広まってあっという間にCore対応が進んだ
彼らは高パフォーマンス、セルフコンテインドデプロイ、マルチプラットフォーム対応といった様々な収穫を殆どタダで得ることができた
.NET Coreはとても魅力的でエキサイティングなアップデートだった

.NET Coreは既存の環境から乗り換えたいと思わせるだけの魅力がない
windowsで,.net frameworkから乗り換える人は少ない
linuxで他の言語から乗り換える人も少ない

利点をはっきり打ち出せてない
ただ作りました使ってくださいじゃ使わない

コンパイルして起動時間が一桁早くなるってのは十分な魅力だと思うが

>>203
>>202でも書いたけど日本ではスパゲティシステムだらけで移植のコストが高すぎたから受け入れられなかった

海外では日頃から品質を高める努力をしていたので移植が容易にできた
そして様々なメリットを享受することができた

利点を示せなかったのではなく
利点を示したけど日本だけが利点を受け入れる下地ができてなかっただけ

つまり日本はハブられたんだよ
いじめられっ子がリア充の生き方なんつまらないと負け惜しみを言うようなもの
キツネとすっぱい葡萄の心理というやつだ

>>204
起動は確実にクソ遅くなるよ
今までは共有ライブラリとしてシステムにインストされいて自然にメモリにキャッシュされてた大量のDLL達を、
ローカルにバンドルしていちいちディスクからロードするんだから

>>206
.net nativeはスタティックリンクだから、ライブラリの中で使っている部分だけ切り取って本体に取り込んでリンクするんだわ
通常はファイルサイズが激減します

>>207
勘違いしてるようだけど、.NET CoreのSCDと.NET Nativeは別物だよ
SCDは.NET Coreランタイムと依存DLLを全部バンドルするだけ

>>208

一番要望の多いnative取り入れないとは思えないが、情報あるの？

体感的にわからない程度に起動が遅くなるかもしれない

デメリットってそれだけ？

>>209
https://blogs.msdn.m...esktop-applications/
あくまで.NET自体を簡単にバンドルできるのが売りだ
.NET NativeはあくまでWinRT版の.NETの機能で、今出てる.NET Coreとは関係ない
ちなみに、.NET CoreではNuGetパッケージを結構細かく分割するのが普通だから、
WinFormsやWPFがそれぞれ丸ごと一つのNuGetパッケージになるようなことはたぶんない
必要なNuGetパッケージをある程度小分けで取捨選択できるようにはなるから、
今のSystem.Windows.Forms.dllよりは結果的にロードするサイズが小さくなる可能性はあるよ

>>211
将来はともかく、最初はこの程度なんかね

よく分かんないけど
動作環境の.NETバージョンに影響されずに済むって話じゃないの

>>210
全部バンドルしちまえってのは今時の流行りで基本的には良いものだけど、あえて挙げるならこんなとこかな
・配布サイズがクソ大きくなる
・DLLのディスクキャッシュが共有されないのでメモリを食うかも
・.NETに重大な脆弱性や不具合が見つかってもユーザーの裁量で.NETを更新できない
・NuGet必須なのでインターネット環境がないとビルドすらできない
・NuGet必須なのでキャッシュなしの状態だとビルドがクソ遅い

・.NET Coreは(NuGetのせいでもあるが)デバッグが遅い
も追加で

>>201
どうやら違う世界に生きてるようだ

>>214
こいつC#使ったことないやろ…

>>214
RuntimeStoreも知らないようだし、NuGetがインターネット必須ってのも大嘘
ユーザーの裁量でRuntimeを更新できないってのも嘘

>>217
最近はずっと.NET Core&C#&Azureやってるよ
一般的な常識に基づく推論と俺の個人的経験で書いただけだから、間違いがあるなら具体的に指摘してるれると助かる

corefxやcoreclrも知らないからユーザーの裁量でランタイムを更新できないって発想になるんか？

>>216
そちらは新規開発案件の1割以上がc#を使ってる世界ですか？
不思議な世界ですね

こちらの世界は全ソフトウエア開発者で.Net Coreを知ってる人が
1%以上いるかどうか怪しいです

>>219
配布サイズが大きいのは、RuntimeStoreのない時代かもしくはランタイム自体をアプリに同梱する場合ね

>>221
ああ奴隷の世界ねごめんよ

>>223
いい加減に空想の世界から出て来いよ

.Net Coreなんてほとんど誰も知らない
C#使ってる中でも知られてない
みんな跨いでいく

デスクトップでCore使うメリットはSCDで、当然それは大前提だと思ってたんだけど
システムにCore入れるならそれこそ何の意味もなくね？

サーバサイドでも使われてない
デスクトップでも使われてない
業務でも使われてない

趣味で使うのがちょうどいい
C#大大大大好きだけど.Net CoreやAsp.net CoreやUWPは早く消えてほしい

>>224
Stackoverflowのreportでも見て現実を直視しろよｗｗｗ

>>225
どうも思い込みが激しいようだ
どっちかって言うとSCDこそ特殊な場合で、SideBySideでランタイムをインストールする方が良い

>>225
Microsoftのブログくらい読めよ
https://blogs.msdn.m...esktop-applications/

>>228
だからそれFull .NETのサイドバイサイドと比べて何のメリットがあるの？

>>230
>>229

>>230
たとえば.NET4.5.2と4.6.1はSideBySideでインストールできないっしょ？

>>232
結局システムに.NETを入れさせなきゃいけないのは同じだよね
.NET Coreなんか頻繁にアップデートされてるから事実上はほとんど特定のアプリと一対一になるだろうし、
アプリ側で.NETのバージョンを上げたくなったらまたそのアプリのためだけにまた特定バージョンのCoreをインストールさせるのか?
そのとき前のバージョンを安全に削除できるかどうか誰がわかる？
開発環境でのテストくらいにしか使えないよこんなの

まだ実用化されていない技術のブログ記事上げてドヤってる
それは既存の.Net Coreの利点じゃないだろ？

コアのアーキテクトの戦略がフラフラしてる
魅力のないロードマップがそれを物語ってる

>>233
前のバージョンを削除ｗｗｗ

>>230
こいつSideBySideなんて知らんのやろ

>>236-237
.NET CoreのSideBySideを利用したデスクトップアプリの正しいデプロイサイクルを具体的に説明してくれ

ちなみに.NET Coreって月一くらいのペースでバージョン上がってるんだが、それ全部SideBySideするってことだぞ？
アプリとは別にシステムの.NETのバージョン管理の余計な手間が増える以外になんかSCDと比較してメリットある？

>>239
全部とかただのキチガイか

>>214
NuGetって言葉覚えたてかな？嘘ばっかｗｗｗ

>>240
結局アプリごとに必要とするバージョンが違うケースが多いはずだからSCDでいいだろと言ってるんだけど、これだけ言っても伝わらない？

>>242
RuntimeStore

>>242
>アプリごとに必要とするバージョンが違うケースが多い
なんで？

>>244
そりゃ.NET CoreかつFDDのアプリ自体が(WinFormsやWPFがサポートされてもなお)稀だろうし、
フレームワークの方も月一で更新されてるとなれば共有できるケースは現実にはほとんど無いでしょ

もちろんデスクトップアプリに限った話な
サーバーだと一括で複数のアプリをデプロイしたりすることは普通にあるからもちろん意味はあるよ

WPFってグラボの違いでどれくらい速度変わってくるものなの？
ハイスペックグラボ使う意味ある？

>>245
妄想おつ

大変そうだな。予防線はりまくりマウント取ろうと形だけは前傾で

デスクトップ対応はありがたい
業務系でウェブアプリはめんどくさいだけなんだよね

>>211
https://github.com/dotnet/corert

corertとかあるけどこれちゃうの？

ちょくちょく試すけど相変わらずx86がうまく生成されなかったりIssue多すぎて
比較的アクティブとはいえ使い物になるのかよくわからん状況だけど

VCランタイムすら不要の単体PEファイルになってdnSpyとかじゃなんも見れなくなるし
こういうのがプロジェクト単位でざっくりと組み込み検討できそうだから
デスクトップ向けの.NET Coreも結構期待してたりするんだけどね

WinformsとWPFのポーティングは朗報だけどどうせ改良する気はないんだろうし
クロスプラットーム化は無理でもせめてReference Source下じゃなくOSSにまでして提供してほしいもんだぬ

なんでDateTimePickerすら入ってねえんだこのゴミは
こんなんだから普及しねえんだよ

オープンソース化もあり得るって話だぜ
なんであれが無いんだーじゃなくてなければ作ってプルリクが当たり前になるのかな
数年後には有料サードパーティライブラリのような高級コンポートが標準化されるかもね

標準でnumericupdownすらないWPFに何を言っても無駄

欲しいものは自分で書いてプルリクを出せばいい
同じことをみんなやりだすからすぐにリッチコントロールが整備される

そういえば標準じゃフォルダー選択ダイアログもないな

WPFって正しく作法に従った汎用コンポーネント作るの結構難しいから、外野がプルリク投げてもなかなかマージされないと思うぞ
MS謹製のToolkitですら悲惨な品質でWPF本体にさっぱり採用されないまま潰れちゃったし

Material Design In XAML ToolkKit　使えばいいじゃん

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

204GM

FormsとWPFはUIテスト自動化への対応具合どうなの？
UIテスト自動化が快適にならないと躊躇してしまうよね
いちおうappiumのドライバは見つけたけど業務で使いこんでるぜって類の記事が全然出てこない

>>260
https://github.com/M...crosoft/WinAppDriver

1.0.0が出たのは去年の10月だからね

prismってmessengerパターンするならEventAggregator使うようになったの？
InteractionRequestは過去のも？

今のprismってMSの手を離れて単なるコミュニティプロジェクトの一つだからなあ
開発者の好みが反映された寄せ集めのツールキット集に過ぎず、もはやリファレンスでもなんでもないよ

>>263がInteractionRequestが好みなら自分でプロジェクトにコントリビュートすればいい
EventAggregatorよりも充実させればInteractionRequestがPrismの主流に見えるようになるだろう
今のPrismってそういうもんで、トレンドを追っても何の意味もない

Datagrid内comboboxのdatatemplateのバインディングがどうやってもできないw

>>266
サンプル見ると、スタティックなオブジェクトリンクしている

Prism6.3でInteractionRequestのRaiseAsync使おうとしたらないんだけど
問題あってなくなったの？

>>268
どこの馬の骨とも知れないメンテナの気まぐれ
君が復活させてもいいんだぞ

共同ツール 1
https://seleck.cc/685

https://trello.com/
ボードのメニュー → Power-Upsから拡張可能 Slack DropBoxなど
Trello Chrome拡張機能　elegant
http://www.kikakulabo.com/service-eft/
trelloのオープンソースあり

共同ツール 2
https://www.google.c.../ja_jp/sheets/about/

共同ツール 3
https://slack.com/intl/ja-jp
https://www.dropbox.com/ja/
https://bitbucket.org/
https://ja.atlassian.../software/sourcetree
https://www.sketchapp.com/
http://photoshopvip.net/103903
https://goodpatch.co...blog/sketch-plugins/

Trello Chrome拡張機能プラグイン集
https://chrome.googl..._category=extensions

Slackプラグイン集
https://slack.com/apps

Sketchプラグイン集
https://sketchapp.co.../extensions/plugins/
https://supernova.studio/

>>252
>>254
いつかはWPFって思ってたのに移行できねーよそれじゃ

まあ、趣味ではWebサイトの方で忙しいから最近はC#あんまできないんだが

UWPにもnumericuodownないんだよな。死ねよと思う。

タッチデバイスのためとはいえ、ほんと実用軽視には反吐が出るな。UI統一は大失敗。

>266
俺はこんな感じでやってるけど
comboBoxItemListはDataGridItemのプロパティにしてる

<DataGrid
ItemsSource="{Binding Path=dataGridRowList}">
<DataGrid.Columns>
<DataGridTemplateColumn>
<DataGridTemplateColumn.CellTemplate>
<DataTemplate>

<ComboBox
ItemsSource="{Binding Path=comboBoxItemList}"
SelectedValue="{Binding Path=column1}"/>

</DataTemplate>
</DataGridTemplateColumn.CellTemplate>
</DataGridTemplateColumn>
</DataGrid.Columns>
</DataGrid>

質問失礼します

以下の2つのTextBoxはどちらも期待通りに動作しますが
2つ目はx:Staticを使っているため文字数が多くなっています

<TextBox
　　HorizontalContentAlignment="Right"
　　Background="Red"/>
<TextBox
　　HorizontalContentAlignment="{x:Static HorizontalAlignment.Right}"
　　Background="{x:Static Brushes.Red}"/>

新しく定義した型で1つ目のような短い記述を行いたいのですが、
HorizontalAlignmentのような列挙型では特に工夫することなく実現できるものの
Brushesのようなケースではどのようにすればいいか分かりませんでした

BrushesはRedのような静的プロパティをたくさんもつだけのクラスなので
Background="Red"という記述が受け入れられたり
この記述を行うときに入力補完が働いたりする仕組みが全く想像できないのですが、
そのような仕組みを新しく定義した型で使うことは可能でしょうか

もしご存知の方がいらっしゃれば教えていただけると嬉しいです
よろしくお願いします

AQ8

AQ8

>> 275
wpfのソース

良きゲームだった
https://goo.gl/VuXjSo

>>278
お返事どうもありがとうございます
以下のコードを読んでみたのですが、それらしい箇所を見つけることはできませんでした
お手数をかけて申し訳ありませんが、読むべきソースを具体的に教えていただけないでしょうか
どうぞよろしくお願いします

（NGワードのためURL省略）

280のURLです。NGワード回避のため一部省略しています

XXX = https://referencesource.microsoft.com/（中略）/System/Windows/Media

XXX/Brush.cs
XXX/Brushes.cs
XXX/KnownColors.cs

何度も申し訳ありません
（中略）の部分は #PresentationCore/Core/CSharp です

コンバーターが明示的に指定されてないけどデフォルトでそういう動作すると決まってるだけでしょ
そういう仕様
自分の作ったクラスは明示してコンバート

ようやっと過去の物をprismに移行した
livetさらば

ゴミが作ったもんなんて普通は使わない

MSが作ったモノが使われなくなって早10年か。

だが果たした役割も大きいで…見方によっちゃリーディングカンパニーではあった

そう思ってるのはWPF関係者だけで
今の世の中に対してなんの爪痕も残せてない
影響はどこにも及んでない

FBがWPFをぼろくそに言ったことも忘れてる
そのFBはreact作ってる

AndroidのGUIフレームワークなんか明らかにWPFを参考にしてるし、
今やWebのSPA開発の標準となったMVVMの発祥地でもある
まあプロダクトとしての設計や実装がアレだったが根本の思想はわりと広く受け入れられた

うわぁこれは日本スゴいと同じメンタルですね
ダッサ

MicrosoftのC#が発祥でパクられまくってる便利機能って多いよね
MVVM、MVC、Task、async/await、Linq、Rx、var、EF、、、
Nullセーフティなど最近は遅れる事があるけどSpanやrefタイプみたいな試みはまだまだ先を行ってるね

webのMVVMとWPFのMVVMは全然別物なんだけど

>>291
よく見たらMVCまでC#起源とか言い出してるし
韓国人みたいなメンタルになったら終わりだぞ？

いい年こいて自己評価が低い奴ほど所持品や帰属集団を持ち上げるのよ
そうしないとアイデンティティが保てないからね

マカーのことですかね？

マカーは間違いない

ボタンにマウスが乗っかるときのアニメーションを切りたいんですが
どんなコードになるんでしょう
XAMLじゃなくてコードで書きたいです

>>297
テンプレートを丸ごと入れ替える
コードじゃなくてXAMLで書いてください

なぜ知ってる範囲だけで済まそうとして苦行をしようとするのか

ありがとうございました
出来ました！

FormsよりWPFの方が、VisualStudioがよく落ちるな
WPFって脆弱なイメージがあるけど大丈夫か

ヒミツだ

やりたかったのはJSPなのかも知れないが、
現時点ではそびえ立つ糞

その印象は正しいよ
WPFはDirect3Dを使うからハードウェアとの相性で落ちたりしやすい

脆弱フレームワークだから寂れていくのは当然だな

見るからに煩雑で洗練されてないもんな。馬鹿文系が設計したイメージ。

docker for winのGUIはWPF

見づらいフラット文化をなんとかしてくれ。

老害は分化から去れよ

>>309
フラットって昔からあるデザインだということも知らんとかアホすぎ。

時代錯誤なんだよ、おまえとフラットは。おまえの脳もフラットなんだろうwww

>>310
顔真っ赤だよw

フラット脳乙w

額縁ド3Dはダサいとなっちゃったからなぁ…

ならクビにする必要ねぇな。なんでMSはフラット推進した奴をクビにしたんだよ。
Windows8以降の移行、普及の失敗はそれ以外にないからだろwww

タダでも移行しない人が半数もいるとかどんだけダサいんだって話だ。中身はほとんど同じカーネルなのに。

しかもカッサコイイだの最新だの言ってる奴はどいつも単発ID。過疎スレである以上同一人物なのは明らか。
つまり、全く人気がない、流行ってないのに、さも人気があるようにレスしてるマカーと同じ行動w

この恥ずかしい自演は自ら人気がないことを自覚してるからに他ならないwww

フラットは個人的に好きじゃないが、ただでも移行しない理由がそんなとこあるとは思えん
むしろ個人的には完全強制せずによく半数も移行したなって思うくらい

Windows8のUIはフラットがどうとか以前の問題だと思うが。

MicrosoftのModern以降のUIはシグニファイアを全く考慮してないので
素人がガワだけ真似たのが丸わかりなんだよ
フラットとかそういう問題以前

流石に3Dルックは古い

マテリアルデザインはショボすぎだわ。もうちょっとエフェクト多用してGPU使ってほしいわ

まぁ、fluent designもアクリルエフェクト抜かせばマテリアルデザインと似たようなもんか

Aquaが出たとき俺はあまりのダサさに絶句したけど、称賛する人多かったね。

>>318 ←こういう馬鹿ってスマホしか使ったことないんだと思う

今wpfで組むならデザイン何使うのがオサレなの？

>>318
おじいちゃんはまだWindows1.0を使ってるの？

>>323
Luna

>>323
Material Design In XAML Toolkit が結構良い感じだ。
ほとんど手を加えなくてもそこそこの見た目になるのでお手軽だし、サンプルのデモプログラムも良く出来てる。

画面遷移するのに、標準のNavigationWindowとPrismのNavigationのどちらを使うか迷っています。
それぞれメリット・デメリットは何がありますか？

>>325
LunaってXPみたいなやつ？

>>326
Material Design In XAML Toolkitってまだイケるんや

WPFってほんと情報ないよな。誰も使ってないんじゃないの？

Stackoverflow（非JP）がバイブルすぎてな

あそこ見りゃ大抵は解決するので他の情報サイトの出番が無い感じ。

入門みたいのの話じゃない？
定番の本とかもないしstackoverflowはある程度わかる人には便利だけど
みんなMSDNオンリーでマスターしてんのか

Pro WPF 4.5 in C# のサンプル

>>329
GitHubに参考になりそうなのめっちゃあるやん

俺はMSの外人サン記事？のwpf サンプルから盗んだなぁ最初は
あと基礎部分はMSDNだな。依存関係プロパティとかそこらへんの基礎分かってないと辛い

なるほど。これは惨いな。
しかしこんなゴミのスレがPart22まで伸びるなんてMSの力は恐るべしだな。
やはり使ってる人が多いのだろう。

>>335
なにが？

WPFの宣教師がたくさんいたらいいのにね

ぶっちゃけWPFは先行きどうなの？
あと、Windowsのデスクトップアプリ作るのにWPFでやる利点あるの？

MSはWPFの終息宣言を出す一歩手前らしいよ（出すかどうかはわからないけど）
もうメンテナンスレベルだから最新の技術を使いたいならUWPに行くしかない

>>339
ソース

>>339
.NET Core3.0でわざわざアレするのに？

UWPこそ将来性どうなのよ

UWPてWindows10だけだろ？

>>343
基本的にはね
unoみたいな例もあるけど

UI変更だけでここまでWindows10が拒否られるとは。
やはり、UIは変更するなと言ってたゲイツは天才だったんだな。

>>345
Windows10が嫌われてるのはUIだけが原因じゃないだろ

つまりFormアプリケーションが鉄板だったてことか（ry

残念ながらそう

Visual BasicのFormアプリが一番良いよなｗ
俺のような馬鹿でもいっぱしのモノが作れたのに、なぜWPFみたいに小難しいものを作ってしまったのか・・・

WPFでもビハインドにイベントベタ書きならFormsと同じ感覚で楽チンやで

同じことするのに新しいことを覚えなきゃならないならまず覚えないよな。

>>329
かずきさんのブログ(かずきのBlog)のWPF4.5入門

Formが良かったとかじゃなくて、先に出たものはその仕様に合わせて作るんで
次に考えるときそれが標準で考えちゃうってことだろうな。

必要ない動きでもFormがこうだったから、とか。
最初のツールが右下に決まったものがでるようになっていたら
後のツールも右下に出ないと困るとか。右上でも問題なくても
今までそうだったから。

なんってところでしょう。

ずっと言われてるけど
JSとかflashの受けが良かったんで.NETに乗せたって事でしょ？

strict感と冗長感が敗因
.NETに乗せると命名が省略できないからなぁ

web技術の流行なんて使い捨てばかり。だって作ってる奴らは何も考えてないもの。

WPFでGUI作成がより合理的になったと思ったんだけどな
まさかFormにあるのにWPFにないコントロールがあるなんて・・・
タッチ前提とかふざけるな、まるでFormのサブセットじゃないか

NumericUpDownすらない...
みんな自作してるの？
それともフリーや有償のUIコンポーネント使ってんの？

商法のひとつなのかもしれない

そういやBlendで小銭稼ごうとした罪があったな…

mf

>>358
NumericUpDownはWPFの機能紹介のためにあえて削られている
NumericUpDownくらい簡単に自作できるのがWPFなんですよみたいなノリで
いたるところいろんな人たちにより作り方が公開されてる

ボケてるんですか、おじいちゃん。ただの実装忘れですよ。

WPFは、実際の現場でコーディングなぞしないエヴァンジェリスト達がブログやセミナーでドヤ顔するための道具

は？

ひたすら画面を量産する業務アプリのコーダーにXAMLを弄くって遊ぶ余裕は無い。

Forms のいいとこは、コントロールのカスタマイズ性の低さでもあると思う
ここまでしかできないんですよ、ってのはメリットでもある

追加やカスタマイズが容易だから最低限のコンポーネントしか用意しなかったってのは
最初の方針として悪くないと思うけど、一段落ついたところで MFC FeaturePack みたいなものを
用意してくれたらよかったのにねぇ。VSにいろいろ作り込んだコンポーネント公開するとか。

WPFは楽そうで全然楽じゃない
普通にボタンそのままだと楽だけど選択表示の青色を変えようとするととんでもなくめんどくさい
あとは意味不明の動作がたまにある
listboxのセレクションが単独になってるのに複数青色の選択状態になってたりする

あと日本人に青天井仕様は合わないんだよ。天井決められなくて右往左往する

自由度が高いとおれジョブス的な馬鹿がトンデモなUIにするからな。

>>368
それいいね

>>369
テンプレートを修正すればいいだけだから、慣れたら簡単なんだけどな
ヴィジュアルステートマネージャーとか取っつきにくいのは確かだが

なんという時代遅れの開発。viで開発してた暗黒時代かよ。RADはどこ行った？

WPFとか関係なく時代の流れで消えてったな>RAD

ポトペタじゃレイアウトできん

.NET core3でWPFが動く方になったりUWPコントロールをホストできるようになるらしいが、未来はUWP。

wpfのテンプレートに文句言う人は、formsでgdi+触ったことない人なんだろうね
あれに比べたらwpfは天国だよ

このコードを碌に書いたことがない素人が設計したとか思えないWPFが天国だとは。
キミはOSS出身者か？　キミがどういう開発経験を経てWPFを使ってるのか聞きたいものだ。

下をみたらどんなクソでも天国じゃんw
そんなの使いたくねー

上を見ようにも、.NETでデスクトップアプリ作る場合は、他に選択肢無いし
FormsとWPFならWPFの方取るな
作るものにもよるけど

よく映画であるように、WPFでマンションなどの建物を
3dのワイヤフレームで表現したい。

この場合、建物のモデリングというか座標計算は
別のツールを使うのが定石でしょうか？
path情報をxaml形式で吐き出してくれたり
するのでしょうか

SharpDX

久しぶりにwinアプリ作ろうするとあれwinのUIってダサかった?と思うぐらいださいな。
WPFは標準でもっとかっこいいスタイルだかテーマを用意してほしかったな。
visual studio2017のダークテーマのUIのアプリを簡単に作れるようにしてほしい。

material desingn tool kitやらmahapp metroとか微妙すぎる

>>383
ありがとうございます、調べてみます

WPFでコーディングしてるだけでも落ちるようになった。
Formsの時はこんなに落ちなかったのに、やっぱりGPUにアクセスしてるから
ドライバーが悪いんかな

vs2010と2008R2の組み合わせは惨かったなぁ

まぁ環境書いた方が良いかと

10年経っても枯れないWPF。人柱が少ないせいだな。

タイミング悪かったんだろう。WPFの後すぐにiphoneが出てみんながｽﾏﾎアプリ開発に舵を切り出しちゃったから普及しなかったとか?
4,5年ぐらいipohneの発表遅かったらもっとWPFできる人もっといたんじゃね

勝利だな。ずっと最新技術

Silverlightの機能が充実して来て、さあいよいよこれからってタイミングで
林檎が「RIAプラグインは悪！」って強硬に主張したせい

>>387
.vsフォルダー内のファイルを消してみたら(.suoファイル以外)

Windows8-10に移行してくれないのはiPhoneのせい!!!
アクロバット杉だろw

Silverlightが終了した理由としては間違ってない
あの潮流で主要ブラウザからNPAPIのサポート切られて、どうにもならなくなったからね

WPFがって話になると、またちょっと事情は違ってくるけど
全く影響が無いって事もないな

Flash排除の政治
これに尽きる

だがあれは死んでくれて良かった

統一されるなら生きてた方が良かったな。まぁ、特定の会社にコントロールされるのはあれだけど。そしたら、c#で楽に開発できるし。
更にスマホもマイクロソフトが覇権とってりゃな、c#一本でいけらのにな

WPFの競合相手は他でもないWinformsだろう
しかも敗北したようなもんじゃね？

XAMLに機能を詰め込もうとし過ぎて開発者オナニーに半身突っ込んでるような設計だし
根本的なパフォーマンスの問題もまるで手に入れないまま一新する機会を失った

慣れればレイアウトやコントロールのカスタム自体はWinformsと比べて強力ではあるんだけどさ

そこまでパフォーマンス要求されるアプリを.netで作ったことねぇけど、UWPの.net nativeとx:bindとか結構すごいのかね?

UWPアプリ何個か作ったが、x:bindとbindingで体感差とかタスクマネージャー見ても精度悪いから差を感じねぇし、パフォーマンスプロファイルしてもわからねぇw

画面のレイアウトはXAMLで非常に楽になった。もうFormsに戻りたくない。

一度覚えたらXAML書きやすいよね
俺はイベントはFormsみたいにコードビハインドにベタ書きしてUIだけXAMLの恩恵受けてるわ
MVVMとか意識高いことしなくてもこれで十分使いやすい

ブロガーだかエヴァンジェリストだかいう連中が意識高い布教し過ぎただけだろｗ

formで画面のレイアウトに苦労するというUIとはいかなるものか。
それはもしかして、ひょこひょこと動的にレイアウトが変わるあの一番嫌われてるUIのことではないのか。

>>399
XAMLは実体はただのオブジェクト生成用のDSLでしかないから詰め込んでないよ

部品貼り付けてプロパティ弄ってイベントコード書く単純作業しかできない業務アプリのコーダーにWPFは無理。
VB全盛の頃から今に至るまで大量に生産されたそいつらに再教育は無理。

ジョブスもいつもユーザーのせいにしてたしな。

別にandroidだってdata bindingライブラリができて、最近はarch　componentで永続するviewmodelが用意されてmvvmでつくれるようになったのに