WPF(XAML, XBAP, .NET4.5)GUIプログラミング Part17

1 名前：デフォルトの名無しさん mailto:sage [2013/11/11(月) 19:31:37.96 ] ユーザーインターフェースシステム、Windows Presentation Frameworkについて微に入り語るスレ。 Visual Studio 2013 & 2012 & 2010 www.microsoft.com/visualstudio/jpn/downloads Microsoft .NET Framework 4 (Web インストーラー) www.microsoft.com/downloads/details.aspx?familyid=9CFB2D51-5FF4-4491-B0E5-B386F32C0992&displaylang=ja Microsoft .NET Framework 4 (スタンドアロンインストーラー) www.microsoft.com/downloads/details.aspx?familyid=0A391ABD-25C1-4FC0-919F-B21F31AB88B7&displaylang=ja Microsoft .NET Framework 4.5 msdn.microsoft.com/ja-jp/library/vstudio/5a4x27ek.aspx 前スレ WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part16 toro.2ch.net/test/read.cgi/tech/1369912326/ 関連スレ Microsoft Silverlight その9 toro.2ch.net/test/read.cgi/tech/1321150267/ コードを貼る場合は以下のサイトの利用をお勧め。 run codeのチェックは外しておきましょう。 ideone.com/ 232 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 04:09:47.35 ] そもそもUIのプログレスを更新したいのにTask、せめてBackground Wokerを使おうと思わない頭の悪さがVBerだな〜w 考えられないがそこまで辿り着けなかったとしてもアニメーションさせたいなら何故Timerを使わないのか その昔VBのTimerが糞すぎてブビ厨はTimerを使わずにwhile(true)DoEvents();でループさせるコードを量産した そして現在も今時小学生でも書かないような糞コード書く・・・ ブビ厨ってなんで学習しないの？仕事から帰って家でなにやってんの？プログラミングの学習しないの？せめてGoogleさんで逆引きしないの？ 233 名前：デフォルトの名無しさん [2013/12/16(月) 04:39:19.89 ] >>229 んじゃやっぱり上で更新するわけないと言ってたのは老害決定でいいのか。 >>232 その老害認定された人？そのせいでふぁびょってるの？ 234 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 04:42:45.71 ] なぜそこまで辛辣な物言いをしようとするのかがわからない 上を見れば切りがないし下を見ても同じで、自分を絶対的な基準にして 少しばかり自分より後から学んでいる人を萎縮させたがる精神状態は そもそも自分自身のコンプレックスによって 引き起こされているのでは無いだろうか 235 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 05:40:27.96 ] 別に分からなくていいだろよ お前には関係ない はい。この話は仕舞いな。 236 名前：デフォルトの名無しさん [2013/12/16(月) 06:05:55.83 ] なんか頑なにUIスレッド内では表示更新しちゃダメって言い続けてる人がいるなw できるんだからダメもクソもないだろうにwww 237 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 07:41:24.78 ] 今回びっくりしたのは、windows8が割とちゃんとしているということ こんなコードでも動いちゃうんだな（１００００回も更新して） 238 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 08:11:01.39 ] せっかくWPFなんだからアニメーション使おうぜ。 一々ループで小刻みに画面更新しなくても、このアニメやっといて、と指定するだけで後は放置だよ。 以前、TriggerでProgressBar変化させるAction作ったけどその時のコード参考に載せとくわ。 durationで設定した時間をかけて、ToまでProgressBarのValueを変化させるアニメーション。 DoubleAnimation da = new DoubleAnimation(To, duration, FillBehavior.HoldEnd); Storyboard.SetTargetName(da, "実際のプログレスバーの名前をここに指定"); Storyboard.SetTargetProperty(da, new PropertyPath(ProgressBar.ValueProperty)); Storyboard sb = new Storyboard(); sb.Children.Add(da); AssociatedObject.BeginStoryboard(sb); 239 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 08:15:04.04 ] ちなみにこのコードだと、処理の進捗状態とかを示す ProgressBar本来の使い方には向かない。 処理本体が重くても軽くても、非同期で ProgressBarだけ指定した時間で変化しちゃうからね。 このコード使った時は、ProgressBarを全く違う用途に使う場面だった。 240 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 09:11:58.13 ] >>236 そもそもBindingがUIスレッドで表示更新しているんだから、それが出来なかったらWPF自体成立しませんｗ 241 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 09:29:23.49 ] 久しぶりにC#でGUIプログラムを作ろうと思ったら WPFなんてのが出てたんだな。 Windowsフォームは過去の遺物になっちゃったの？ 今C#でGUIアプリを作るならWPFで正解？ 242 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 09:57:58.83 ] >>241 デザイン性求められてないならWinForm、 求められてるなら仕様変更を促してWinForm 243 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 09:59:24.91 ] WinFromsのWin32API由来の制限がうざいと思うならWPF、 特に困ってないならWinFormsだな。 WinFormsでできることをするなら、 生産性やプログラム動作速度はWPFよりWinFormsの方が良い。 WinFormsは過去の遺物だが、WPFも放置気味なので WPFに期待してるとがっかりするぞ。 244 名前：241 mailto:sage [2013/12/16(月) 10:09:33.41 ] よくわからんけど2〜3年様子みれってことかな。 245 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 10:18:21.48 ] WPFは覚えることが多いから、お気楽プログラミングには向いていないが 凝ったことやりたくなったら重宝するよ 246 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 10:24:10.77 ] >>244 その認識で問題ない。 2〜3年後だったら、デスクトップ版WinRTも形になってるだろうしね。 デスクトップ版WinRTの状況次第では、WPFは完全にお払い箱になる。 247 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 11:45:22.95 ] >>244 前スレにも出てたヤツ↓ www.infoq.com/jp/articles/Win8-LOB-Options 使う使わないは自己責任で 248 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 18:57:53.29 ] Bindingとコントロールの合成の2点で採用する価値がある MVVMは頑なにコードビハインドを否定してるのが意味不明 デザイナーなんて居ないことのが多いのだから学習曲線を急な勾配にする価値がない 249 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 19:02:08.70 ] 頭の固い変な人（あるいはバカの一つ覚え） が否定してるだけでMSの大元のMVVMに関するコラムでは何も言ってねえけどな お前も気にしなくていいぞ 250 名前：デフォルトの名無しさん [2013/12/16(月) 19:32:38.96 ] >>248 別にMVVMはデザイナーを分離するためじゃねえだろ Viewん薄くするのは健全だと思うけどね 251 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 19:33:54.78 ] ageて書くようなことか 252 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 19:35:38.16 ] >>240 その批判はBindingが内部的に（長い）ループの中でプロパティを操作しているのでなければ成立しない。 馬鹿じゃないの。 253 名前：デフォルトの名無しさん [2013/12/16(月) 19:35:43.47 ] ビューン 254 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 19:51:06.09 ] Viewを薄くするのはいいが、 それを実現するために、薄くした以上にViewModelが肥大化したら意味がない。 ViewとViewModel、どちらに書けばシンプルで短いコードになるか考え、 適切な方を選べばよい。 何も考えずに「コードビハインド無しで実装できた！」とか喜んでるのは・・・ 目的と手段が入れ代わってると思うね。 255 名前：デフォルトの名無しさん [2013/12/16(月) 19:54:13.19 ] 目的と手段が入れ替わると・・・楽しい！ 256 名前：デフォルトの名無しさん mailto:sage [2013/12/16(月) 20:00:24.00 ] だよな！趣味ってそういうことだよな！ 257 名前：デフォルトの名無しさん [2013/12/16(月) 20:53:10.69 ] >>254 ViewModel使う目的は関心ごとの分離とユニットテスタビリティだろうからそれ行けるならファットになるのもいいとは思うけど。適当に分離すればいいし。 けどコードビハインド避けてViewを薄くするためにファット化するとかだったら意味ないのは同意。好きにコードビハインド書け。 大事なのはテストされたVMの挙動を単純に表示に変えるぐらいの薄さになってればいい。 258 名前：デフォルトの名無しさん [2013/12/20(金) 21:27:32.98 ] .NET4.5のDataGridについてなんですが 検証処理するとき以下のようにValidatesOnDataErrors=Trueにして、チェックはIDataErrorInfoで行うようにしました <DataGridTextColumn Binding="{Binding Data1,ValidatesOnDataErrors=True,NotifyOnValidationError=True}"/> そうするとエラーが解消されてもValidation.Errorsにエラーが1個残ったままになるんですが これ使い方間違ってますか？ 259 名前：デフォルトの名無しさん mailto:sage [2013/12/20(金) 21:56:30.05 ] >>258 エラーを解消した後、IDataErrorInfo.this[columnName] が呼ばれてるかチェックしてみれば？ Binding 経由でプロパティを変更した場合は勝手に呼んでくれるけど、 それ以外から変更した場合は INotifyPropertyChanged も実装して、エラーが解消したプロパティを通知せんとダメよ。 260 名前：デフォルトの名無しさん mailto:sage [2013/12/20(金) 23:00:58.51 ] >>259 ありがとうございます。 エラー解消後に何も入力してなければIDataErrorInfoは呼ばれてません Binding経由以外ではプロパティは弄ってないんです。どうも変な動きしてるんで他のコードは全部削除してみました 試しにValidation.AddErrorHandlerを使ってエラーのAdd/Removeを見てみたところ Addが3回、Removeが2回みたいにRemoveされる回数が少ない、何を言ってるのかわからねーと思うが俺も何をされてるのかわからなかった状態です 後、妙な動きがもう一つ。 DataGridTextColumnのValidationRulesとかConverter例外とかでエラーが発生した場合は他のセルに移動できませんよね これがIDataErrorInfoでエラーを起こした場合は他のセルに移動できてしまう、これは仕様なんだろうか、なんか統一性ない 261 名前：デフォルトの名無しさん mailto:sage [2013/12/21(土) 00:22:07.78 ] >>260 IDataErrorInfo が呼ばれてないのは、エラー要因のインスタンスと、エラー元のインスタンスが別とかじゃない？ Binding 経由で呼ばれるのは入力先のインスタンスだけだから。 INotifyPropertyChanged を実装して、エラー解消時に更新を通知してやれば消えるはず。やってみては？ あと、後半のは意図した仕様だよ。 例外やコンバートに失敗した場合だと、Binding 先のモデルへの set に失敗している→エラー対応はビュー側の責任 IDataErrorInfo の場合は set は成功している→エラー対応はモデル側の責任 262 名前：デフォルトの名無しさん [2013/12/21(土) 11:16:34.22 ] <Grid.ColumnDefinitions> <ColumnDefinition Width="100*" />　←「１つ目」とします <ColumnDefinition Width="100*" />　←「２つ目」とします <ColumnDefinition Width="200*" />　←「３つ目」とします </Grid.ColumnDefinitions> としてGridを配置しており、 親のWindowの ResizeMode プロパティを CanResize にしています。 親WindowのMinWidthは400です。 このときにウィンドウを横に広げると 1:1:2 の比率で広がっていきますが、以下の動作にする方法が ありましたらご教授願えますでしょうか。 ・ウィンドウ（初期値の横幅400px)を横に広げていったとき、 　　１つ目：120px 　　２つ目：120px まで広がった場合は、上記のpxで幅が固定され、 それ以上にウィンドウの横幅を広げた場合は ３つ目のみ広がっていく、ということをやりたいです。 よろしくお願いします。 263 名前：262 mailto:sage [2013/12/21(土) 11:19:21.90 ] うわぁぁ、すみません。 ColumnDefinition に MaxWidth プロパティがありました。。。 264 名前：デフォルトの名無しさん mailto:sage [2013/12/21(土) 16:41:49.30 ] Global Hookしたキーコードを書き換えられないようで、SendInputも調べましたがどうも難し過ぎて手がでません LL APIだと難し過ぎるんで素直にWPFコントロールを継承してイベントをoverrideしてるんですが、今度はbaseに渡すKeyEventArgsがReadOnlyとかなんなんですかこれ、嫌がらせですか・・・ なのでKeyEventArgsインスタンス生成時にKeyを渡せたので安心したら今度はbaseに渡すにはRoutedEventArgsがほにゃららとかマジ糞すぎて泣きそうです KeyDownで押されたキーを渡さずに指定のキーを渡す方法を知っていましたら教えてください 265 名前：デフォルトの名無しさん mailto:sage [2013/12/21(土) 16:54:55.50 ] > SendInputも調べましたがどうも難し過ぎて手がでません とか言ってないで基礎から勉強しなおせ。 SendInputは簡単な方だぞ。 もっともっと難しい方法ならあるが、それ以上簡単な方法なんて無いって。 266 名前：デフォルトの名無しさん mailto:sage [2013/12/21(土) 16:56:06.72 ] あっち書いてこっち書いて全部レス返し無しとかなに考えてんの 267 名前：デフォルトの名無しさん mailto:sage [2013/12/21(土) 16:56:57.54 ] 場当たり的にやってるからしょうがないね 268 名前：デフォルトの名無しさん mailto:sage [2013/12/21(土) 16:57:28.80 ] そりゃあ糞人間だな 269 名前：デフォルトの名無しさん mailto:sage [2013/12/21(土) 18:48:00.66 ] 解決しました 実装書ける人が一人もいませんでしたね さようなら糞PGさんたち^^ 270 名前：デフォルトの名無しさん mailto:sage [2013/12/21(土) 18:52:20.83 ] 今は、これが、精一杯 271 名前：デフォルトの名無しさん mailto:sage [2013/12/21(土) 19:27:52.48 ] 期待する方が間違ってる 272 名前：デフォルトの名無しさん mailto:sage [2013/12/22(日) 18:11:22.89 ] 適切な学習方法がわからん 2年触ってるけど学習効率が極端に悪い 273 名前：デフォルトの名無しさん mailto:sage [2013/12/22(日) 18:13:05.83 ] バインドの種類が多すぎて使い分けがわからん XAMLに色々手を入れすぎて失敗してる気がする 274 名前：デフォルトの名無しさん mailto:sage [2013/12/22(日) 18:14:01.65 ] 普通のバインドとマルチバインドの2種だろ 275 名前：デフォルトの名無しさん mailto:sage [2013/12/22(日) 19:13:45.83 ] XMLってのがそもそも筋が悪いんだよな Jsonと違って定義が厳密すぎるんだよ HTMLもそうだがマークアップなんてゴミだよ しかもStyleやTemplateやResourceがJsやCSSと違ってめちゃめちゃ面倒くさくてどうしようもない どうせならJs＋HTML＋CSSでStoreだけじゃなくデスクトップもウェブも統一したらええねん 276 名前：デフォルトの名無しさん mailto:sage [2013/12/22(日) 19:15:40.23 ] ValidationRulesもマークアップ拡張に書けるようにしてくれれば、後は特に不満もない 277 名前：デフォルトの名無しさん mailto:sage [2013/12/22(日) 19:17:16.97 ] 定義が厳密なのはエディターとの親和性を考慮したんだと思うが Blendが全く普及しなかったからね・・・ 278 名前：デフォルトの名無しさん [2013/12/22(日) 19:38:46.82 ] >>277 使いこなせてないが、MSの人が使ってるの見て使えればかなり生産性高いのは分かった。 279 名前：デフォルトの名無しさん mailto:sage [2013/12/22(日) 19:40:59.41 ] HTML+CSSはHTMLのフロードキュメントをCSSで魔改造しているだけだからレイアウトエンジンとして筋が悪い 280 名前：デフォルトの名無しさん mailto:sage [2013/12/22(日) 19:44:45.42 ] そもそもBlendって単語が久しぶりに出た気がする 一つ前は>>57か・・・ 281 名前：デフォルトの名無しさん mailto:sage [2013/12/23(月) 00:58:17.09 ] 流れぶった切って悪いんだが、ちょっと相談に乗ってくれ DataTemplate使った画面遷移してるんだが、画面遷移を繰り返すと、 繰り返す度にViewが生成される関係でViewに紐づいたTriggerActionが 暴発するんだ どうやら、 １：View1とView2が交互に入れ替わるとき、View1orView2内にItemsControlで View3が表示される ２：View3にはActionTriggerが書かれている って言う条件下で発生するっぽいんだが、解決方法がわからん 誰か分かる奴居たら頼む 最少再現コードというか、再現プロジェクトは↓ www1.axfc.net/u/3122746?key=wpf 282 名前：デフォルトの名無しさん mailto:sage [2013/12/23(月) 06:42:43.74 ] 気持ち悪いノリだな。 283 名前：デフォルトの名無しさん mailto:sage [2013/12/23(月) 10:45:54.77 ] よくこんなノリで書き込むよな。 誰も解決に協力しないだろこんなんじゃ。 （別にそれでもかまわねーぜ！であるなら、そもそも書き込むなよと思うし） 284 名前：デフォルトの名無しさん mailto:sage [2013/12/23(月) 11:25:22.90 ] >>281 InteractionRequestTrigger より ViewModel のほうが生存期間が長いから、 ViewModel の InteractionRequest に古い InteractionRequestTrigger からの参照が残ったままになってる。 （古い参照が削除されないまま、新しい View が作成される度に、イベントへの参照が追加されてる）。 解決には ItemView.Unloaded で DataContext = null しておけば良い。 285 名前：デフォルトの名無しさん mailto:sage [2013/12/23(月) 12:31:48.55 ] >>284 ホントありがとう >>282 >>283 すまんな。このスレの空気読み切れてなかったわ。 286 名前：デフォルトの名無しさん mailto:sage [2013/12/23(月) 12:32:26.31 ] いやそもそも喧嘩腰な方が悪いから 287 名前：デフォルトの名無しさん mailto:sage [2013/12/23(月) 14:21:46.69 ] 喧嘩腰…？ 288 名前：デフォルトの名無しさん mailto:sage [2013/12/23(月) 18:54:14.52 ] このスレで一番喧嘩腰のレスは>>2 289 名前：デフォルトの名無しさん mailto:sage [2013/12/24(火) 17:09:41.78 ] リソースディクショナリって入れ子出来ない？ コントロール1つ配置してControlTemplate と Style の2つの辞書つくって ControlTemplate辞書からStyle辞書のリソース見るようにして コントロールにControlTemplate反映させたんだけど Styleの内容が反映されないんだよね。 ControlTemplate辞書内に<ResourceDictionary x:key="hoge" Source="style.xaml"> なんて記載してみてもだめ。 ControlTemplate と Style を1つの辞書に書くと問題ない。 Blendにコード生成させたのに「解決できません(ｷﾘｯ」てなるwww 290 名前：デフォルトの名無しさん mailto:sage [2013/12/24(火) 17:13:39.50 ] ResourceDictionary の入れ子は不可。ResourceDictionary.MergedDictionaries 使ってマージする。 291 名前：デフォルトの名無しさん mailto:sage [2013/12/24(火) 17:45:09.40 ] 要は結果的に辞書は１つじゃなきゃアカンてことな。外部参照はマージしなきゃ見えない。 292 名前：デフォルトの名無しさん mailto:sage [2013/12/24(火) 18:19:02.18 ] >>290 入れ子不可、理解しました。 でもマージにして複数に分けてみたけど 「解決できません」が復活。 もちょっと触ってみます。 293 名前：デフォルトの名無しさん mailto:sage [2013/12/24(火) 18:44:08.04 ] >>292 <Window.Resources>内で辞書定義してたけど App.xamlの<Application.Resources>内で定義するようにしたら エラー・警告もなくできました。 <Window.Resources>に置いていても Blendの「プロパティ->ローカルリソース」からは 辞書内のリーソスが見えてたので認識してるもんだと思ってました。 勉強代に20時間くらい払ってしまった。 >>290-291 ありがとうございました。 294 名前：デフォルトの名無しさん mailto:sage [2013/12/25(水) 01:36:01.33 ] >>293 プロジェクト直下に"Themes"フォルダ作ってその中に"Generic.xaml"っていう名前のリソースディクショナリを置いて、その中でマージするっていう手もあるぞ。 1アプリ=1プロジェクトならApp.xamlでもいいけど、もしスタイル適用対象のコントロールを別アセンブリ(DLL)に置くなら、 そのApp.xamlでマージできないし、"App.xaml"っていう名前のリソースディクショナリを置いても反応しないので、 そのときはこっちの方法しかない。 注意すべきはフォルダ名、ファイル名が固定だということ。 別の名前にしても反応しないから注意。 もしVSがPro以上なら「カスタムコントロール」プロジェクトを新規作成してみて。 プロジェクト直下に/Themes/Generic.xamlっていうリソースディレクトリがデフォで配置されてるから。 295 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 00:05:01.38 ] ResourceDictionaryって何に使うの？ DataContextだけじゃダメなのか なんかWPFの壁＝Xamlなんだよね ついついC#で全部書いちゃう カスタムコントロールもx:nameにしないとエラーとかイミフだし XamlもっとわかりやすくしてよM$ 296 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 00:19:47.02 ] XAMLはWPFの壁というよりは基本中の基本 297 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 00:31:59.06 ] >>295 ResourceDictionaryを使うとローカライズするとき楽になる Window複数使っててスタイル共通にしようと思ったらResourceDictionary使うしかないし DataContextにスタイルやControlTemplateとか持てないでしょ、いや持てるけどやらないでしょ ・・・普通に使ってるよ 298 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 00:47:24.11 ] コードビハインドからCommand.CanExecuteを見に行ってもいいよね？ 極力シンプルにおいしいとこだけ使うようにしないとチームから批判くらいそう 299 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 00:52:35.63 ] それならVMでコマンド用意する意味ない気がするけどね。 コマンドじゃなくて直接モデルのプロパティを見ればいいわけで。 300 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 03:04:25.42 ] >>295 「DataContextだけでスタイル設定まで済ます」っていうのは、 Webでいうところの「HTMLの各タグにいちいちStyles属性でスタイル設定する」だと思うんだ。 データの内容に依存しないスタイルならWebでいうところのCSS、 つまりリソースディクショナリのStyleTemplateに設定したほうがいいよね。 もちろんリソースディクショナリを使わずに、View内の各コントロールのStyleTemplateを設定してもいいけど。 ・・・どちらにしてもxamlは必要だけどね。 >>298 OKだと思うよ。 そのCommandをバインドしていないButtonの使用可否制御とかに使えるね。 俺ならCanExecuteの元メソッドの返り値をbool型プロパティにしてバインドするけど。 ただCommand.Execute()を生で叩くときは必ずCommand.CanExecute()で検証しないとね。 301 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 07:45:38.18 ] 普通にVMのメソッドを呼べばいい話だな OOPの作法的にはそれを呼び出そうとする側で実行できるかチェックするのもやめて チェックはそのメソッド内でやったほうがいい 302 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 12:42:55.37 ] というか無造作に必ずCommand.CanExecute()で検証とか言うアホの存在が レースコンディションで落ちるアプリを生む元なんだろうな if (cmd.CanExecute()) cmd.Execute();の条件判断と実行の間でコンテキストスイッチが発生して 状況変わることなんていくらでもあるだろうに 303 名前：デフォルトの名無しさん [2013/12/26(木) 12:53:08.38 ] というかその間に別スレッドから状態変更が起きる可能性があり、かつその際に落ちる可能性のあるようなプログラム書いてんじゃねーよ 304 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 13:08:01.03 ] それって別にCanExecuteに限った話じゃないし、 実行可否の判断ができないってことじゃねーか。どんな糞な作りしてんだよｗ 305 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 13:36:44.09 ] だからCanExecuteはそもそもUI上のグレーアウト表示とかの判断にだけ使うもの Execute呼んでいいかどうかの判断に使ってはいけない 306 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 14:17:00.64 ] リソースディクショナリの話があったので 拾い物グラデーション辞書でも作るかと思ってググったら geekswithblogs.net/Silverlight2/archive/2008/10/21/more-xaml-gradients.aspx ここくらいしか見つけられんかった。 ExpressionBlendだとphotoshopのgrdファイル読み込むプラグインあるらしい。 307 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 19:29:03.94 ] コードビハインドで確認しようがXAMLで確認しようがUIスレッド上で動くだけだろ 安全性についての明確な違いなんてあるの？ 308 名前：デフォルトの名無しさん [2013/12/26(木) 21:51:50.83 ] >>307 だからそもそもCanExecuteで安全性チェックしちゃダメだって話なんだが(´・ω・｀) 309 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:03:37.46 ] >>302 「ICommandの設計思想が糞」まで読んだ。 ってか、CanExecuteでの検証OK→Executeの実行の間では、 Execute実行の安全性は確保されるのが前提だろうに。 (おそらく)CommandManagerのほうもそれで動いてるんだろうし。 310 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:15:14.07 ] >>309 マルチスレッドのプログラムやったことあるのか？ 311 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:17:36.66 ] 専用に何らかのフレームワークでも準備しない限りそんなの無理だろ 312 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:19:40.73 ] もともとICommandなんてざっくりしてるのにそんなもん要求スンナ WPFはどのタイミングでCanExecuteチェックしてるかも知らないんだろ 313 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:21:16.76 ] 何の話をしてるのかよく分からんが、とりあえず>>309の話は正しいよ。 最後の行は何言ってるのか分からんが。 というか、Executeは基本、UIスレッドからであればいつ呼ばれても大丈夫（実際に処理を実行するかは 別として）なように実装しないとまずいんじゃないの？ 314 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:24:54.70 ] CanExecuteはGUI様に簡易で用意されてる物 実際の実行可否は日帳に応じてExecute内でチェックするもの 315 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:26:12.27 ] タイプボロボロ CanExecuteはGUI用に簡易で用意されてる物 実際の実行可否は必要に応じてExecute内でチェックするもの 316 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:27:38.08 ] 非同期処理がガンガン書き換えるようなプロパティをバインドすんなが正解だろ コードビハインドでCanExcecute云々と全く関係ない話 317 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:28:12.75 ] >>310 マルチスレッドの各スレッドで同じExecuteを呼ぶのがそもそも間違ってると思う。 そのマルチスレッドそのものをラップしたExecuteを用意して、そのためのCanExecute、Commandを用意すべきでは？ 318 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:29:33.83 ] 俺の移ったのかタイプがボロボロｗ CanExecuteなんてどれを参照してるかわからないのにどれをロックするんだ？ だからマルチスレッドプログラムをやったことないんだろと言った 319 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:30:56.98 ] CanExecuteなんて1秒間も何度も呼ばれてるのにExecute実行まで何をロックするんだ？ 答えてみ？ 320 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:31:03.93 ] STAThread属性なUIスレッドは逐次処理だっての 321 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:35:16.30 ] Icommand自体はWPFのバインドとは何のかかわりもない CanExecuteが何を元に判定しているかなんてWPFは知らない しょうがないから適当なタイミングでWPFがCanExecute呼んで画面に反映してるだけるだけ 何度呼ばれているかカウントして表示してみたらいい 知らん奴は驚く 322 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:37:29.51 ] 的外れな内容でコーディングするよりコマンド使わないほうがいい 323 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:39:23.85 ] こいつUIスレッドが複数あるとでも思ってるのか 324 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:42:00.80 ] いつになったらUIスレッドと無関係だと理解するんだ？ CanExecuteで判断する内容はMに依存していたとして コマンドからはMの更新を知ることができない だからWPFはInotify使えないで地味にCanExecuteを適当に実行してる 325 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 22:43:59.93 ] ワーカースレッドが裏でプロパティ書き換えない限り不都合なんてないだろ 326 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 23:16:42.43 ] ワーカースレッドでCanExecuteが変更されるなら、 CanExecuteChangedもワーカースレッドで呼び出されなければならない。 だが、UIスレッド以外からCanExecuteChangedを呼んで良い、という仕様は文章化されていない。 よって、この動作は不正。 CanExecuteの変更をUIスレッドにマーシャリングしてやる必要がある。 何が言いたいかっていうと、マルチスレッドｋが〜とか言ってる奴が 一番マルチスレッドを理解していないって事だ。 327 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 23:24:55.85 ] 低レベル過ぎて泣ける 相手にして損した ugayaでもかずきでも好きな奴に相手してもらえ 鼻で笑われるだけ 328 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 23:27:20.07 ] > コマンドからはMの更新を知ることができない 知ることはできない、じゃねーよ。 お前が更新を通知する実装をさぼってるだけだろ。 可能なら通知を実装する、 通知がどうしても不可能なら、 CanExecuteは常にtrueにしておき、 Executeでは何も実行しないこともありうる、って仕様にすべき。 329 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 23:28:31.35 ] かずきはともかく、ugayaとかスレッドがわかってるつもりで 全然わかってない奴の代表格じゃねーか。 330 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 23:47:15.40 ] >>328 つか、ControlTemplateでしっかりグレーにするのが面倒になって、ついそういう仕様にしたりする 331 名前：デフォルトの名無しさん mailto:sage [2013/12/26(木) 23:53:26.46 ] 見た目の事？ だったら、無効状態だと透明度を0.4位にするってのが簡単なのでよく使ってる。 332 名前：デフォルトの名無しさん mailto:sage [2013/12/27(金) 00:00:08.19 ] 最近はどうでもよくなってUIのロックしなくなった

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef