17/04/21 20:16:45.24 TbfEGS8v.net
MSに関わると2,3年であっという間に浦島になるからな
1013:デフォルトの名無しさん
17/04/21 20:28:06.75 MpBIOwvX.net
>>965
ちょっと話が噛み合って無い感があるから整理すると、
JavaScript:
プログラムからの変更ではイベントが発火しないから、
全てのイベントハンドラは redraw(); で締めないといけないが、
イベントハンドラ内で他コントロールをどれだけ触ろうと何も考える必要なし。
.NET:
プログラムからの変更でもイベントが発火するから、
関連しているコントロールのイベント先をすべて redraw() にしておけば再描画される。
だから単純な再描画についてはこっちの方が記述はすっきりする。
ただし、今回のように複数コントロールを触るイベントハンドラがあった場合、
その回数だけ再描画される可能性がでてくるからそこを対策しようとすると、途端に汚くなる。
（JavaScriptのコードは redraw(); を書くしかないし、再描画だとはっきり分かるが、
.NET のコードは俺が今やっている妙な対策法だと？？？なコードになる）
再描画されればいいのなら、.NETの方が良いけど、
2度描画禁止とかにしたい場合、.NETの方が記述が余計に必要になる。←これって俺の勘違いか？
というのが今回の疑問。
> そういう設計だと、例えばプログラムで倍率を変更しても再描画されないよね。
違う。プログラムから各
1014:コントロールのValueを変更することによって、自動的に再描画させてる。 というか、波形表示画面内容と表示開始位置と倍率は当然同期してないといけなくて、 逆に、表示開始位置と倍率が変わらないのなら再描画の必要がない。 それはコントロールの値を変更する構造によって自動的に達成される。 (.NETは同じValueを上書きしてもイベントが発火しない為) だからFitボタン連打とかの場合の無駄な再描画はここで止められる。 多分.NETの仕様だとこういう事だと思うんだよ。(これがMVC的に云々というのはまた別の話) それで、2度描画禁止の場合はどう実装するべきだという想定なのだろう？という疑問なんだ。 普通はキューイングするから問題ない、ってことなのかな？ (なお、明示的に再描画したい場合は redraw() を呼ぶだけだから問題ない)
1015:デフォルトの名無しさん
17/04/21 20:42:28.79 MpBIOwvX.net
ちなみにMVCの場合はモデルがイベントソースで、
コントロールの値を変更→モデルの値を変更→再描画
という流れになるけど、モデルの値をプログラムから変更する場合、
コントロールの値の表示を手動で合わせてやる必要がでてくる。
これが面倒だから、WPFではバインディングってことで自動化してる。
これはこれで良いとして、
.NET作った時に今回のようなケースが想定されていないはずもなく、
彼等の想定実装があるはずで、
その通り実装すれば綺麗に実装出来るはずなんだが、というのが俺の疑問。
1016:デフォルトの名無しさん
17/04/21 20:43:34.30 FFGpioc0.net
>>968
勘違いではないよね。
その認識であってると思う。
コントロールのプロパティを値の入れ物として利用するのは普通はよくない作法だと思う。
コントロールはあくまでUI（表示と入力）に徹するべきで、
表示先頭位置とか表示倍率とかの値はFormなりUseControlなり
独立したクラスなりのプロパティにするべきだというか、普通はすると思う。
で、再描画はコントロールのプロパティが変更されたタイミングではなく、
表示先頭位置なり表示倍率なりのプロパティが変更されたタイミングで行う。
当然、この場合も一度に複数のプロパティが変更されたときに
不要な再描画を回避する方法は考える必要がある
1017:デフォルトの名無しさん
17/04/21 21:04:34.72 rPWpf+kQ.net
n秒に１回描画フラグを監視する仕組みのが楽だなｗ
コントロールの挙動全部把握してるやつが触らないとぶっ壊れるって
モノ作ってんだろ?
それって設計悪くない?
1018:デフォルトの名無しさん
17/04/21 21:07:01.51 MpBIOwvX.net
>>970
> コントロールのプロパティを値の入れ物として利用するのは普通はよくない作法だと思う。
MVC的にはそうだね。ただ、この部分のUIなんて変更はないからどっちでもいいのも事実。
ところでその場合、バインディングはどう実現する？
(C) numericUpDownのValueChanged→モデルの値を変更
これはいい。ただFormの場合、
(D) モデルの値が変更された→イベント発火でnumericUpDownの表示値を変更
とすると、当然(D)の直後に(C)が発火して、
モデルの値を再度「同じ値」で上書きして、そこでイベントが止まる。
これって全くの無駄でしょ。
.NETの仕様を決めた時、これらが想定されていないはずもなく、
彼等なりの上手い使い方があったと思うんだよね。
(今現在それが良いとされる手法かどうかはともかく)
今のところ、表示とモデルの内容を同期するのに一番簡単な方法は、
「numericUpDownのValueをモデルの値として扱うこと」なんだよ。
そしてこれだと他クラスから見えないので、コピーを持ってる。
これは後付でこうなった、というのもある。
実装は、イベントハンドラに何個でも関連づけさせられるからそこでさせてる。
1019:デフォルトの名無しさん
17/04/21 21:13:36.92 MpBIOwvX.net
>>971
モデルをどこに置くか、という話なんだよ。
Formの仕様だと、numericUpDownのValueプロパティを「モデルの値」として扱えば
すべてすっきり行く仕様になってる。だからそうしてる。
ところが2度描画禁止だとすっきり行かない。だからこれが疑問。
それならJavaScriptみたいに、最初から
「必ず1回redraw()を書かないとダメだけど、1回書けばいいだけです」の方が良かった。
だから、彼等なりの想定実装があったはずで、それを考えてる。
1020:デフォルトの名無しさん
17/04/21 21:15:27.48 rPWpf+kQ.net
使って問題がある場面のバインディングなんて使わなきゃいーじゃん
マイクロソフトお作法病って損だと思う
1021:デフォルトの名無しさん
17/04/21 21:15:53.73 Re4upQlq.net
>>963
EntityFrameworkはもう十分枯れてるだろバカ
Coreは確かに発展途上だけどね
元のレスを読まないからこんな的はずれなURLを貼っちゃう
1022:
1023:デフォルトの名無しさん
17/04/21 21:18:21.74 lnct7jOB.net
イベントがダブりそうなときはイベントを-して値代入後+しなおしているなあ
>>970の２段落目に賛成だな
見なおしたり他に移植するときにそっちの方が分かりやすいし
1024:デフォルトの名無しさん
17/04/21 21:33:34.84 MpBIOwvX.net
>>974
バインディングといったから分かりにくいが、放置した場合は表示が間違ってるんだよ。
これは完全にアウト。
Fitボタンが押された→
モデルの値が変更された→
再描画された
これで「波形表示」は最新になるけど、
「表示開始位置」と「倍率」の表示されている値が古いままでしょ。
そしてFormのイベントはそれ用になってないんだよ。
>>976
> イベントがダブりそうなときはイベントを-して値代入後+しなおしているなあ
これってかなり面倒でしょ。
今のところタイマで遅らせるのが一番すっきりするからそうしようかと思っている。
(これは他部分で既に実装済みなのを流用出来るというのが大きいが)
redraw()を呼んだら16ms後にredraw_implement()が呼ばれて実際に再描画とか。
ただこんなの.NET作った頃から想定してたのかな？という疑問はある。
1025:デフォルトの名無しさん
17/04/21 21:34:54.35 h0UgT1Ml.net
>>966
来年にはYAMLになってると思うよ
1026:デフォルトの名無しさん
17/04/21 21:37:01.31 72Ff37pO.net
>>975
なんだ、枯れてるとか言ってボコボコ叩かれて悔しかった奴か
「Coreは確かに発展途上だけどね」
Core の前になんかつくだろカス
1027:デフォルトの名無しさん
17/04/21 21:49:04.78 rPWpf+kQ.net
>>977
意味わからん
画面は自分が必要なときにデータを見て勝手に描画するじゃん
フォームはコントロールの操作によってデータを書き換えるじゃん
バインディングなんて使わなきゃ悩む要素皆無だったんでしょ?
1028:デフォルトの名無しさん
17/04/21 22:08:05.95 Re4upQlq.net
>>979
おや、ようやくCoreを認識できたんだね
1029:デフォルトの名無しさん
17/04/21 22:08:53.85 1MuUAA6h.net
>>979
自分が叩かれていることに気づいていないのは見苦しい
1030:デフォルトの名無しさん
17/04/21 22:09:14.20 k73pGP5K.net
>>977
そのへんはレンダリングスレッドがUIスレッドと分かれてるWPFでやろうとしてたと思われ。
1031:デフォルトの名無しさん
17/04/21 22:29:56.50 MpBIOwvX.net
>>983
え？WFPって描画はUIスレッドじゃなくていいのか？
それはすごくいい。
それだとスピンコントロールのボタン連打で描画が追いつかない時にも、
イベントが溜まることなく最新が常に表示されるね。
何もしなくても。
まあ何だかんだで新しい物は改良されてるってことだね。
1032:デフォルトの名無しさん
17/04/21 22:29:56.87 Cei54Lla.net
かずきが日本マイクロソフトに入社してる！
本当に浦島状態
1033:デフォルトの名無しさん
17/04/21 22:34:32.90 baDy0zQG.net
>>985
誰だよ？
1034:デフォルトの名無しさん
17/04/21 22:37:38.47 k73pGP5K.net
>>984
描画はUIスレッドなのは変わらない。
UIスレッドで同じところにポンポン書き込んでも適当に間引かれる。
1035:デフォルトの名無しさん
17/04/21 22:37:41.43 h0UgT1Ml.net
>>984
クソ重いから結果的にはWinFormsの方が遥かにレスポンス早いんだけどね
1036:デフォルトの名無しさん
17/04/21 23:07:08.58 MpBIOwvX.net
>>987-988
うーむ、やはりイマイチか。
回答くれた皆さんありがとう。
俺は>>970ではないけど、次スレ俺が立ててもいいけど。(>>1)
1037:デフォルトの名無しさん
17/04/22 01:19:50.97 Af8PazvW.net
>>954
なんか無茶苦茶だな。
クリックイベントの最中に描画処理を実行してるのか？
再描画させたいならInvalidateRectとかでWM_PAINTを発生させてそこでまとめて描画するのが作法だぞ
1038:デフォルトの名無しさん
17/04/22 03:39:27.34 BJdj4TZ/.net
>>990
御説ごもっともだけど、そんな偉そうに言うほどのことでもないよ
1039:デフォルトの名無しさん
17/04/22 04:54:36.82 y5zvwDCw.net
偉そうかどうかは関係なくない？w
1040:デフォルトの名無しさん
17/04/22 06:10:42.01 4+2xx2Ut.net
>>992
発言の正当性より自己満足度で正当性を確保しているので重要です
1041:デフォルトの名無しさん
17/04/22 06:23:09.19 9wvnPEyC.net
>>990
InvalidateRect発生させてもRect無視して全画面更新しちゃうよ。ふざけんな！
みたいな話だからな。ちょっと方向性が違うｗ
1042:デフォルトの名無しさん
17/04/22 06:45:50.45 +hjaOcO8.net
>>991
2ch初めてか？ w
1043:デフォルトの名無しさん
17/04/22 08:50:41.11 iVvswOrb.net
次スレ立ててくる
1044:デフォルトの名無しさん
17/04/22 08:52:51.85 iVvswOrb.net
次
C#, C♯, C＃相談室 Part93
ｽﾚﾘﾝｸ(tech板)
1045:デフォルトの名無しさん
17/04/22 09:05:33.60 /oxuzvQq.net
ワッチョイなしで立て直して
1046:デフォルトの名無しさん
17/04/22 09:09:40.54 AhKt2WIP.net
やなこった
1047:デフォルトの名無しさん
17/04/22 13:34:52.68 3nsKygnV.net
1000
1048:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています