<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ファイルの内部をチェックしてみてはどうかな？
JPEGと言ってもプログレッシブJPEGとかグレースケールJPEGとかある
いろいろアドバイスありがとうございます
眠すぎるのでわかったことだけ
問題のjpegファイルですが、セグメントを一個ずつ消してみて
デコード速度を測定したところ、APP2セグメントが問題だと分かりました
APP2セグメントを消すと他のファイルと同じくらいの展開速度になります。
BitmapImage がカラープロファイルを見ていい感じに表示しようと頑張ってるんだと思います
それにしても非同期のときだけ10倍も遅くなる理由が分かりませんが……
BitmapCreateOptionsにIgnoreColorProfileあるから、それ指定すると速くなるのかな？
Pixel Shader Effects Libraryのプロジェクトが古すぎるから2017でもビルドできるように作り直した
8年前というとWindows 7が出たころだよな
現在でも機能が先進的すぎて使いこなせる気がしない
最近、海外でwpf、wpf言うから流行ってんのかと思ったらwtfだったわ
wpfで助かったｗ
製品型番で微妙に設計が違う画面設計が数十種類もあって、WinFormsではコマタだったが、wpfで事なきを得た。
WinFormでは、ロジックからGUIコンポーネントにアクセスするのに対し、wpfはコンポーネントからコントローラーにバインドする。
画面バリエーションに対し、ロジックを共通に使えるのは助かる。
winforms触ったことねぇけど、フォーム？の継承はできなかったんけか？
そっか。なら
>製品型番で微妙に設計が違う画面設計が数十種類
も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 アニメーションはカッコいいだろ
電卓がまともに計算できなくなるとしても優先すべきだ
>>48 ←こいつ、Windowsの効果音もONにしてそうwww ウインドウズはもちろん若い子が夢中のアイホンにアンドロイドもアニメーションだらけ
あれがカッコイイんでしょ
アニメーションをオンにして遅くなるようなボロいマシン使うなよ。
どんなに速いマシンでもアニメーションをオンにしたら遅くなることも理解できないアホがいるとは。
ここム板なんだけど。まさかコード書けない奴までいるとは想定外。
お前はプログレスバーアニメーションのようなものまで否定するのか?
進捗しているように見せかけるプログレスバー(ブラウザに多い)は死ね
ｗｐｆ使えない人は、こういう言い訳するんだな
出来ないのに出来る人を蔑むプライドっって笑えるね
>>63
失礼なことを言うな
進捗率の「%」部分が
「%」と「I」が交互に表示されて
動いてるように見えるだろう
でも、死んでるんだけどね 実年齢は分からないけど面白いお爺様がいるのね (´・ω・`)
視線誘導とかの目的にはアニメーションいいと思うけどね。
>>68 ←こいつすげー馬鹿。アニメーションの実装したことないことがバレバレ。 アニメーションがかっこいいとか遅いとかそういう事言い合ってるのに、突然実装の話しだす。無理するなよw
横レスだがWindowsのアメニーションを体感で遅くなるとか言ってる人はWindows使ったことないと思う。
Windowsのアニメーション装飾が何の機能か知らない人の発言。おらそく馬鹿マカー。
当たり前だがPCの速度でアニメーションが早くなったり遅くなったりするような実装になってない。
だから速いPCにしろというのはさすが意味不明、筋が通らない。体感なんてなおさら関係がない。
MS開発者はアニメーションはふつうOffにすることすら知らないんだからやはりマカーだね。
Appleは古い機種をアップデートすると故意に遅くなるようにしてたらしくて訴えられたが。
> 視線誘導とかの目的
これが嫌われてる細大の理由だね。flash=詐欺広告、下品なエロ広告
>>69
今更アニメ作れるみたいなこと言い張ってもバレバレですわ、爺様 Windowsのアニメーションをオンにしてる開発者を一度もみたことない。
顧客からもアニメーションのオフにする方法は聞かれるが仕様でアニメーションにしてくれなんて要望されたこともない。さすがに無職でしょう。
パフォーマンスオプションの視覚効果のことなら今どきのPCならデフォルトでONだろうが、
開発者でもわざわざOFFにしてる奴なんて見たことない。
他人のPCの設定を念入りにチェックする奴なんて見た事ないわ
>>80
他人のPCの視覚効果ON/OFFって設定見ないと分からんのか？ 作れないやつが、ほぼ言いがかりで作れるやつにマウンティングするとか笑えるねｗ
webがアニメしまくりなのに、もしかするとjavascript切るんだろうか？
よく知らないけど、iPhoneの電卓がバカなアニメーションのせいでまともに使えなかったことは知ってます
操作性を損なわない程度のものならあっていいんじゃないかい。
画面に変化のあったところを気づかせるためや、マウスオーバー時になにかできることしめしたりや、ナビゲーション時に前のページと関連のある項目をわかりやすくするためとか。
すごくアプリに慣れた人にとってはいらないかもだけど、そうでない人にとって気づきやすくさせるために使えると思う。
エロ広告みたいなうざいやつだけではないから、適切に使えばいいだけの話。そして、WPFには組み込みのアニメーション機能があって、そういうのが無いプラットフォームよりも楽に作れるってだけじゃん。
なんで言い争ってるの？
組み込みのアニメーションが憎くてしょうがない
WPFにメリットがあってはならない
僕は林檎るdisることができればスレの流れは気にしません
そんなに楽なのか
俺はトランジションが難しすぎてドハマりしてるけどな
アーティファクトを発掘したはいいが使い方がわからない感じ
操作の遅延動座でしかないアニメーション装飾で喜ぶなんて小学生低学年までとマカーだけだろ。
正月ということもあって勢いでスライドショーするソフト作ってみたが
アニメーションが重いというのはないね、軽快で快適
どちらかというとダウンロードの仕組みが入ると遅い
上手いこと先読みしたりキャッシュしとかないと無理あるね
WPFむずいわー
今日はTreeViewをやった
けどTreeViewってWinFormsでもむずいんだよな
むしろFormsのほうがむずいまである
はあ～しんど
>>94
正直なところTreeViewをMVVMであれこれやるところが一番めんどくさい
やらなくていい ComboBoxも結構面倒だと思うよ、TreeViewより頻出だと思うし
文字に色つけたりアイコン画像入れたり
このスレまだあったのか。しかも伸びてる。相変わらず普及しない、ゴミという話題ばかり。
あるならこれよりマシなGUIフレームワークを教えて欲しいわけだが
WPFはシステムであってフレームワークは自分で構築するか、既存のフレームワークを導入する必要がある
以前からWPFがむずかしいと言われる理由の一つがこの導入コスト学習コストの高さ
Visual Studio InstallerもElectronで作られる時代
VisualStudio本体もWPFで作られてるというよりWPFを描画と入力に使った独自フレームワークだからね
次のVSは本体にもElectronが入ってくるだろうけど
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と呼ぶか呼ばないかが決まっちゃう。
うーん。
>おっしゃる通り本質的にはMVPとMVVMはデータフロー
に修正します。
誤字がひどくてすみません。
今日はComboBoxをちょっとだけ勉強したで
ワイWinFormsではデータセットからポトペタしてたんやけど同じようにできるっぽいんかこれ？助かるわ。
せやけど表示のカスタマイズ方法が馴染みなさすぎてｵｯｻﾝついていかれへんで
データソースからポトペタしたデータグリッドのコンボボックスそのままやと使いもんにならんやんけ
これだけで1週間かかったわ
あったまっがパーン
かっそ過疎やな
せやけどXAMLおぼえたらあんまり話すネタないよなこれ
登場しからずっと話題は、普及はまだ？ 馬鹿には使えない!! のループだったな。
しかしWindows用のデスクトップアプリを作るとなったとき、現実的な選択肢はこれしかなくないか？
UWPは10用だし、マルチプラットフォームのあれこれはまだ発展途上で、
結局シングルソースじゃなかったり容量が馬鹿でかくなったりするし
>>127
容量がおかしいのそれだよ
Electron製で50MB以下のパッケージ見たことない
インスコしたら200MB超えましたなんてのもザラ
ついでにメモリも大食い >>130
ただ、Win10その他の制限が問題ない場合はUWPが良いよ
特に起動が１０倍単位で早いってのがね
コンパイルは１００倍単位で遅いけどね >その他の制限が問題ない場合はUWPが良いよ
そりゃ、マイナス条件がないならプラスしか残らんのは当たり前だわなw
同様に、WPFの制限が問題ないならWPFが良いし、WinFormsの制限が問題ないならWinFormsが良い。
>>132
Fornsのアドバンテージは人足を集めやすいことで、wpfは特別な制約はなくて強いて言えばGridViewなどが遅いことぐらい
UWPは逆汗が難しいことやパフォーマンス。それとｔｏｏｌｋｉｔが標準で用意されていること
それぞれ使い分け出来たら良いけど、人足集めるのが大変だわなwpfとuwpは メトロUIは業務系ユーザーに不評だから提案する気になれない。
wpfのネイティブコンパイルが出来れば全て解決なんだがなぁ
進んでるのかな
せっかくXAML覚えたのに来月からJavaScriptの仕事になってもうたわ
けどワイMS製品で育ったしいつかまた会うやろ。じゃあの・・・
コロコロと違う言語やプラットフォームに技術者をぶち込む企業はさっさと転職したほうがいい。
俺は45過ぎてからC++とGPGPU始めて、50近くになってTypeScriptとSPAやってるとこだわ。
c++の文法ルール自体はそんなに難しくない
自動でメモリ解放してくれるようにもなったし
c++は生まれ変わった
でもライブラリなどがレガシーの塊なので非常に地獄
>>142
CとC++の壁？ かなり高いよ。
年齢は関係無い。 C#はすっと頭に入ったけど、C++はなかなか入らないですね
特にMFCというのが昔から苦手で今日まで来てしまった
別にMFCはC++の構成要素じゃないよ
好きなフレームワーク使えばいい
だいたいwpfでC++もないやろ
なんでそんな話になってんだ全く
次々からフレームワークが出て習得するのが面倒だよな。PGはそんなに暇じゃないっての。
フレームワークを使い捨てにするMSはアホ。wtfだってまだ使ってんだよ。
というか.netの売りは言語自由だったはずなのにwpfではC++を排除してるのかよ。ほんと嘘つきだな、MSは。
.NETのウリは言語自由って初めて聞いたが
いくつかの言語から選べるってのはよく聞くけど
WPFおもろいわ。
仕様拡張も含め、.net core対応ｷﾎﾞﾝﾇ
全く。マウンティングするための道具として最高におもしろいわ。
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
こういう資料って、公式のどっかに説明あるんでしょうか？
