17/04/16 13:21:57.61 UDjczAnn.net
>>903
>・GC って概要として不要になったメモリを解放する機能って理解はあってる？
はい
>・メモリ確保時に初期化が実行されるとの理解はあってる？
正確ではない
ヒープからオブジェクトを確保したら初期化されていることが決まっているだけで、
初期化�
948:ﾌタイミングは決まってない 既に初期化済みの領域から割り当ててるはず >・一般的な挙動として、メモリ確保と GC は別物との理解に誤りはある？ > ※実装が GC 時に初期化しているかどうかではなく、GC と言う言葉の定義に初期化が含まれるかと言うこと 誤りはない ただし片方だけではメモリのシステムとして機能しない >自分は上記が正しいと思ってるから、 >>895 の内容に違和感を感じなかったんだ。 .NET の実装によるので 「GCで大量にゼロクリアが必要にはならない」 は誤り .NET Core の実装ではページングの機構を使って大量にゼロクリアしてる(と思う) オレオレCLR実装でGC時ではなく、オブジェクト確保時にゼロクリアする実装というのはあり得る
949:デフォルトの名無しさん
17/04/16 14:12:52.31 0ImhO/qF.net
>>903
> GC と言う言葉の定義に初期化が含まれるかと言うこと
含まれていないけど、実質同じ。
GCってプログラマの負担を減らす為の物なのに、
いちいちゼロ初期化必要だとコンセプトとしておかしいでしょ。
まともなGCならゼロクリアされている。CLRもそう。
仕様としては、
△ > ・メモリ確保時に初期化が実行されるとの理解はあってる？
○ ・メモリ確保時には初期化済み
であって、どのタイミングで初期化するかはGCの実装による。
同じ事はOSでも行われていて、以下ページのZeroed参照。
URLﾘﾝｸ(nyaruru.hatenablog.com)
950:デフォルトの名無しさん
17/04/16 15:02:23.81 79m5iU1q.net
なんかすごい重箱モードの議論だねw
いや批判はしてないですよ別に
951:デフォルトの名無しさん
17/04/16 18:44:26.20 dr2cdwts.net
粘着質な人が居ると困りますねw
952:デフォルトの名無しさん
17/04/16 18:59:23.11 I10lJTDS.net
>>892,906
そうかTHX.
isの方がなんとなく速そうだと思ってたが案外そうでもないんだな
953:903
17/04/16 20:38:49.89 EJt90aDw.net
>>904,905,907,908
教えてくれて、ありがとう。
自分も MSDN の文章を読んだりしてみました。
斜め読みだから読み落としてる可能性も高くそうしたらごめんなさい。
[一般的定義]
・GC は概要として不要になったメモリを解放する機能のこと
・一般的な挙動として、メモリ確保と GC は別物
[CLRの仕様]
・メモリの確保も解放も GC の機能の内
・確保されたメモリは初期化されている
[CLRの実装]
・GC 時にメモリを初期化してるっぽい
ふつう、挙動を考える際には仕様を元にすると思うから
「GC時(正確にはメモリの解放時)にはメモリの 0 クリアは期待しない／できない」と理解してよさそうな気がする。
>>895 の「GCで大量にゼロクリアが必要にはならない」が「GC時に 0 クリアしている訳ではない」との意味であれば
仕様としては正しいことから一般論としても正しい。
ただ、実際にはやってくれているけど、それは仕様に基づいているわけではないからいつ改変されるか分からないアテには出来ないもの、と理解しました。
自分もよくやるんですけどね。仕様にはないけど自分が考える安全のための後始末とか。
954:デフォルトの名無しさん
17/04/16 20:52:22.64 3ec5aaGF.net
勝手に０クリアしてもいいけどGCはそれがわからないから
またGCが０クリアするよ
つまり二度手間
高速化なんてのたまてってるけど馬鹿ばっか
955:デフォルトの名無しさん
17/04/16 20:53:23.50 3ec5aaGF.net
無能の馬鹿の議論は飽きたわ
どこか別でやってくれよ
個人のブログとか
956:デフォルトの名無しさん
17/04/16 20:55:58.52 dr2cdwts.net
正直議論に見えない、自演に見えてきた。
957:デフォルトの名無しさん
17/04/16 21:04:46.71 wSkKKBMW.net
>>912
もともとのガベコレの意味はざっくり言えば「確保/解放によって断片化したメモリのデフラグ」
だったはず
知らんけど
958:デフォルトの名無しさん
17/04/16 21:22:51.36 0ImhO/qF.net
>>912
GCは「アイドル時にやれ」というのは分かるよな？
実際はとりあえずこれを目指しているはず。
メモリ確保時にゼロ初期化するのはユーザ時間に直接影響する。
（メモリ確保のレイテンシが著しく増大する）
GC時に初期化するのはGC時間が長くなる。
CLRの場合は確かGC時にはユーザスレッドを凍結していたはずだから、
これもユーザに見えることになる。
だから、普通に考えて、
一旦GCした後、(ユーザスレッドと並行可能な)別スレッドでゼロ初期化だよ。
959:デフォルトの名無しさん
17/04/16 23:10:52.0
960:0 ID:rt4ZW9V3.net
961:デフォルトの名無しさん
17/04/17 21:40:45.89 3B2OvgTj.net
でも初期化するクセは付けた方がいいぞ
プログラマとして
そういう意味でゼロクリアされている事がわかっていても
明示的にやっておくのも間違いじゃない
962:デフォルトの名無しさん
17/04/17 21:53:33.58 DRWzf9HM.net
いいぞ
誰に向かって威張ってるのかね
そんな威張っていうような話か？w
963:デフォルトの名無しさん
17/04/17 21:59:35.59 FPOa41qy.net
一週間も馬鹿な話続けてる奴にそんな嫌み通じるかよ
お前も馬鹿か
964:デフォルトの名無しさん
17/04/17 22:28:28.26 0+0M+jw7.net
じゃぁ配列は、こう初期化すんの？
byte[] buff = (byte[])Enumerable.Empty<byte>();
965:デフォルトの名無しさん
17/04/17 22:37:56.61 sNToWnIL.net
自分のブログでヤレ
966:デフォルトの名無しさん
17/04/17 22:40:07.22 sNToWnIL.net
わかってないようだから書くけど
こいつがまず重度の馬鹿
>>919
967:デフォルトの名無しさん
17/04/17 23:18:50.28 pEHnUlca.net
924 はキチガイの類
968:デフォルトの名無しさん
17/04/17 23:22:01.64 pEHnUlca.net
これがキチガイの末路w
これこそが本物だ
URLﾘﾝｸ(www.int2.info)
969:デフォルトの名無しさん
17/04/17 23:38:40.81 YebzKHR/.net
ここまで基地外だけ
970:デフォルトの名無しさん
17/04/18 00:27:01.11 0Yq9p2Hl.net
>>926
Microsoft相手に訴訟すると
こういう目に会うのか
971:デフォルトの名無しさん
17/04/18 00:36:27.92 gic2i7xr.net
んな訳ねぇだろ、てかお前本人だなw
そんな予感はしてたんだ、文体似てるし60代臭していたし
Delphi板荒らしていたヤツとよく似てたし、お前Delphiやってたし
もうじき親の財産次るんだろ？もう終わりだろ、はよ死ね
972:デフォルトの名無しさん
17/04/18 01:34:33.30 4m6dsFPX.net
client sideのvalidationがめんどくさすぎるのだけどVMからvalidator.jsを生成するサービスないのか？
973:デフォルトの名無しさん
17/04/18 06:15:21.44 dwhcaFAX.net
それは頭悪いだろ
サーバーサイドでやってるバリデーションと同じことがしたいならAPI作ってajaxが筋
974:デフォルトの名無しさん
17/04/18 06:39:33.82 RUjuZHo6.net
そのAPIとそれを使ったクライアントコードの生成サービスないかってことでしょ
975:デフォルトの名無しさん
17/04/18 07:40:17.90 4m6dsFPX.net
>>931
不要な通信を避けるためにclient side validationするわけでしょ
そのために通信をしてたら意味ないじゃん
976:デフォルトの名無しさん
17/04/18 07:51:25.03 Su4pCCia.net
あるわけねえだろ夢見んな
977:デフォルトの名無しさん
17/04/18 18:30:31.09 dwhcaFAX.net
>>933
client side validationの目的は一般的には通信を避けることではなくフィードバックの即時化によるUXの改善でしょ
よほどレイテンシの大きい糞NWを想定してるとか、サーバーに頻繁にリクエストが来るのがキャパシティ的に許容できないとかでない限りは
ajaxによるバリデーションは十分有効
978:デフォルトの名無しさん
17/04/18 18:34:28.24 b4tf0yLR.net
クライアントにidとパスハッシュのリスト送信しておけばおｋ
979:デフォルトの名無しさん
17/04/18 19:24:13.68 T0vdTXyx.net
>>935
なるほど
でもその説明じゃうちのロートル達が納得しないよ
もっと素人が喜びそうな説明はできないの？
980:デフォルトの名無しさん
17/04/18 19:34:36.94 qpdySibv.net
死ね
981:デフォルトの名無しさん
17/04/20 14:46:51.02 ofUg/eB0.net
EntityFramework で System.Data.SQLite 使ってるんだけど、
SaveChanges() が遅すぎるので、
CQRS( URLﾘﾝｸ(msdn.microsoft.com)
982:mt788619 )をやってみようと思った クエリ用にデータベースファースト、コマンド用にコードファーストで DbContext を作ってみたんだけど、モデルファーストの DbContext を new すると コマンド用の POCO と競合して曖昧と言われる まだ試してないけど解決方法がなんか汚い ttp://entityframework.codeplex.com/workitem/483 クエリ用、コマンド用ともにコードファーストにするのが普通なんだろうか？ SQLite はマイグレーションサポートしてないようなのでコードファーストはメジャーじゃない？
983:デフォルトの名無しさん
17/04/20 18:34:56.61 9NLTwIyk.net
>>939
DBからコードファーストじゃだめなん？
984:デフォルトの名無しさん
17/04/20 19:09:00.01 ofUg/eB0.net
>>940
そうね
データベース（モデル）ファーストにしてるのは、
ER図を見るために使ってるだけだからそれでもいいかぁ
クエリ用（Read）とコマンド用（Write）双方ともDBからコードファーストで作って
DB変更時には再度作り直す方法でやってみるかなー
（どこらへんがコードファースト？ って使い方になっちゃうなｗ）
985:デフォルトの名無しさん
17/04/21 00:34:55.91 IVDQeFzJ.net
毎回迷うんだけど
VS2017ではどのデータベースを使うべき？
そしてEFはどのバージョンを使うことになって参考になるサイトはどこにあるんだ？
それそろ安定してほしいんだけど
986:デフォルトの名無しさん
17/04/21 01:26:41.50 72Ff37pO.net
>>942
MSDN: Introduction to Entity Framework
URLﾘﾝｸ(msdn.microsoft.com)(v=vs.113).aspx
上記ページは、なんか日本語表示にはできるけどインデックスやら、
ページのリンクが英語になってたりして、チグハグ
和書では、EFについて書かれた本がほとんどない
書いてあっても一章分でさらっと流す程度だし、
ネット上の情報だと EF を使うための VisualStudio の操作方法とか、
いくつかの落とし穴の回避方法がパラパラ載ってる程度なので、
英語の MSDN をブラウザの翻訳機能で読んだほうがいいと思う
EF Core (EF7として開発されてたらしい) ではクロスプラットフォームの
ための軽量化で一部の機能を削いでるらしい（モデルファーストとかはできなくなる）
EF6 は EF Core が出てからもしばらくはサポートされるので、
今入門するなら EF6 を使うのがいいと思う
（というか、必要でない限り移行はお勧めされていない）
987:デフォルトの名無しさん
17/04/21 06:35:38.36 h0UgT1Ml.net
EFはWeb系のノリで作られてるから安定することはないよ
988:デフォルトの名無しさん
17/04/21 07:48:39.88 XjCRa8hg.net
業務とデータベースに精通していて
全てを自由に弄れる立場にいて
時間をかけて生成されるデータ構造まで意識した精緻なモデル設計ができて
その案件の寿命までずっと面倒をみれるか同レベルの後継者を育てられる
そんな人がチームにいればモデルファーストは有りじゃないかな
そうでなければ使い捨てアプリぐらいにしか使えないよ
989:デフォルトの名無しさん
17/04/21 08:13:05.97 dQDWETdW.net
>Web系のノリ
どういうこと？
990:デフォルトの名無しさん
17/04/21 08:17:36.55 lbMf26rv.net
>>942
安定って具体的に何のことを言ってんの？とっくに枯れた技術だけど
991:デフォルトの名無しさん
17/04/21 09:12:06.55 LWRI+6r2.net
>>946
ヤマトのりかと
992:デフォルトの名無しさん
17/04/21 11:08:44.37 U4JkC8YI.net
EFとLinqのせいで生のSQL文が書けなくなっている。
993:デフォルトの名無しさん
17/04/21 11:45:09.91 72Ff37pO.net
まだサポートが十分でないDBとかあるし、ガンガン開発されてるのに枯れた
994:とか言っちゃうんだ Web系の人なんだろうなー ttps://docs.microsoft.com/en-us/ef/efcore-and-ef6/features EF1 2008/8 バージョン4.0までは ObjectContext を使ったプログラミング、データベースファースト EF4.0 2010/4 セカンドリリース、POCOサポート、モデルファーストサポート EF4.1 2011/4 DbContext が導入される、コードファーストサポート、NuGet配布 EF4.3.1 2012/2 マイグレーションのサポート EF5.0 2012/8 .NET4.5 が対象、enum EF6.0 2013/10 オープンソース化、async対応、細かな改善多数 EF6.1 2014/3 DBからコードファーストするウィザード EF6.1.3 2015/3 EF6系の最新(EF6.2 が出る？) EF Core 1.0(EF7) 2016/6 コードベースが新たになる、ObjectContext 非推奨 EF Core 1.1 EF Core 2.0 2017/Q3予定 準備中 GitHub のフォルダ構成見て初めて気づいたんだけど、 EF ってASP.NET の1モジュール扱いなんだな 964 の言ってるWeb系のノリ、納得
995:デフォルトの名無しさん
17/04/21 11:56:05.07 8CN2PrPc.net
開発されてないのが枯れてるのか。そりゃ確かに枯れてるなｗｗ
996:デフォルトの名無しさん
17/04/21 12:40:19.25 dpyapAzz.net
>>946
あくまでもイメージだが品質とか安定性より開発速度とかリリースを優先するって感じ
>>947
腐ったまま枯れてるってことはいくらでもあるし
997:デフォルトの名無しさん
17/04/21 17:42:09.62 MpBIOwvX.net
そういえば前から疑問なんだけど、フォームのイベント伝搬ってどう組むべきなんだ？
状況としてはよくある波形ビューワーで、表示先頭位置と倍率が変えられて、
カーソルが2つあって、フィットボタンを押すと画面にフィットするもの。
(カーソル0が画面の左端、カーソル1が画面の右端になるように、
自動的に表示先頭位置と倍率が調整され、再描画される)
(A) 表示先頭位置の変更→画面再描画
(B) 倍率の変更→画面再描画
とした場合、
フィットボタンを押す→
表示先頭位置と倍率が自動的に変更される＝普通は上記(A)または(B)に当たる
→自動的に再描画される
となるのだが、ほとんどのケースで2回描画されてしまう。
そこで今は、倍率変更側はフォーカスを確認して
(B') 倍率の変更→（フォーカスがある時のみ）→画面再描画
として1回描画にしているが、
これだとフィットボタンを押したとき、結果的に倍率のみの変更の場合は再描画されない
（同じ値を上書きしてもChangedが発火しない）ので、フィットボタンのイベントの最後に
if (!changed_start_pos) redraw();
を付けている。
ただしこれはリファクタ時に久々に見たら「はて？」と思ってしまった。
この場合って、どう組むべきなんだ？
ちなみにJavaScriptの場合は、プログラムによる変更の場合はイベントが発火しないので、
全てのイベントの最後に redraw(); が必要になるが、全部書けば全く問題ない。
フォームの場合はプログラムによる変更でもイベントが発火するので、この問題が起きる。
ただ、特にレアケースでもないし、一般的なうまいやり方があるとは思うのだけど。
上手く繋げられれば記述が少なくて済むからこの仕様なんだろうし。
998:デフォルトの名無しさん
17/04/21 17:42:43.14 MpBIOwvX.net
なお、今のコードのイメージは以下。(CLIだけど）
void numericUpDown_fitButton_Clicked(Object^ sender, EventArgs^ e) { // フィットボタンクリック
// 倍率と表示先頭位置の再計算
numericUpDown_magnitude->Value = XXXX;
numericUpDown_startPos->Value = YYYY;
if (!changed_start_pos) redraw();
}
void numericUpDown_magnitude_ValueChanged(Object^ sender, EventArgs^ e){ // 倍率変更
// スクロールバー等の増減量等、他機能の整備もここでやっている
if (((NumericUpDown^)sender)->Focused) redraw();
}
void numericUpDown_startPos_ValueChanged(Object^ sender, EventArgs^ e){ // 表示先頭位置変更
redraw();
}
void redraw(); // 再描画
ぱっと思いつくのは全部 Focused を確認して redraw() だが、
それだとこの仕様（＝フォームのイベントはプログラムによっても発火する）にした意味無いよね？
(その場合は明らかにJavaScriptの仕様の方がマシって事になってしまう)
多分何らかの上手いやり方があると思うのだが。
色々奇妙なのは後付でごちゃごちゃやっているから勘弁で。
今までは問題なく動作していたから放置していたが、ついでなのでリファクタしようとしている。
999:デフォルトの名無しさん
17/04/21 18:12:04.32 FFGpioc0.net
>>953-954
そもそもコントロールのイベントで再描画ってのはちょっとw
表示先頭位置とか表示倍率とかの値はFormなりUseControlなり
独立したクラスなりのプロパティになってるはずで、それらのプロパティの変更痔に
再描画されるようにしないと
無駄な再描画を避ける方法だけど、一番いいのは余程重いのでなければ
気にしないことだと思うw
どうしてもこだわるなら、直接再描画するんじゃなくて
タイマーのイベントに再描画を紐づけしてタイマーをスタートさせるだけにするか、
Application.Idleイベントをうまく使うかするとか
1000:あ
17/04/21 18:18:11.06 KFYgHFHL.net
>>953
リドローが必要だとキューイングするかと。
どうせインプットのリフレッシュレートやら画面のリフレッシュレート越えてリフレッシュしても無駄なんだし、リフレッシュ時には再描画するんだし。
WindowsならWM_PAINTでやるとかが歴史的にいわゆる普通の方法では？
1001:デフォルトの名無しさん
17/04/21 18:23:10.98 YZVNImgq.net
>>950
EntityFrameworkとEntityFramework Coreを同一視してるおバカさん
1002:デフォルトの名無しさん
17/04/21 18:35:37.53 RSu3z+zM.net
フォームのように、SuspendLayout, ResumeLayoutみたいな設計もあるけどね
1003:デフォルトの名無しさん
17/04/21 18:51:51.53 xzjZrHPt.net
イベント毎にRedraw要求を行うのではなく、
イベント毎にRedrawイベントをどこかのキューにぶち込んで、タイマーや別スレッドで監視し、
描画時に複数のRedrawイベントがあれば最新の物を一度で済ませるようにすればいい。
1004:デフォルトの名無しさん
17/04/21 18:55:13.11 MpBIOwvX.net
>>955
別クラスのプロパティに分離しても本質的には同じだよね？
複数のプロパティが、
・どれかは変更される
・全てが変更されるとは限らない
・必ず変更される物があるわけではない
状況においては、内部的にOR取ることが必要で、一番単純なのはキューで上書きしてしまう方法。
つまりそちらのようにタイマーに要求を出して、
timer->start()は何度打っても同じだからそこでOR取ってしまうとか。
しかしこれだと余分にこの構造が必要なんだよね。
（ただし他の部分ではこの方法も使っている）
UIから変更された場合、60fpsとかにするくらいなら直接イベントで描画してもほぼ同じでしょ。
波形はwaveファイルで数百メガとかの場合もあり、このときは明らかにもたつくので2度描画はNG。
あるいは、独立クラスにフラグを持ってそこで上書き、
独立クラスのeventをサブスクライブしろ、ということ？
それは理想的な構造なのだろうけど、話が膨らみすぎて面倒だ。
Application.Idleは初耳だが素晴らしい。(JavaScriptではアイドルが取れない)
これってUIスレッドが、ってことで良いのか？
（ただしこれは今回は使えそうにはないが)
>>956
WM_PAINT見たがよく分からん。
システム側が再描画タイミング(おそらく60fps)を通知してくれるので、
それをサブスクライブして、そこで溜まっている
1005:再描画を掃くのか？ それはゲームみたいに常に再描画する用で、 今回みたいにUIで変更された時のみの場合は常にイベントが呼ばれる分ウザくなる気が。 あるいは、自分で何かを再描画した時だけ、 システム側で60fps同期でWM_PAINTを打ってくるのなら、今回には使えない。
1006:デフォルトの名無しさん
17/04/21 18:57:50.94 MpBIOwvX.net
>>959
サンクス。まあみんな意見は同じか。
他に何か、「プログラムによる変更であってもイベントが発火する」という、
フォームの仕様を上手く使った方法はないかねえ？
1007:デフォルトの名無しさん
17/04/21 19:08:46.15 xzjZrHPt.net
>>961
>>958みたいな感じじゃないか。
WindowsのListViewとかも、大量のデータ挿入を想定してBeginUpdate/EndUpdateと言った手段を用意しているし、一般的な手法かと。
1008:デフォルトの名無しさん
17/04/21 19:19:20.39 72Ff37pO.net
>>957
違いを比較しているURL貼ってるのにレスを読みもしないで小馬鹿にする馬鹿
>>953
瑣末なことで悪いんだけど、どうしても気持ちがざわつくので指摘する
「リファクタする」は日本語としてあまり使われていない
refactor の訳としては「リファクタリングする」が使われている印象
どう間違っているのかはうまく説明できん
refactoring は造語で、それを元に refactor という動詞が造語として作られている
一般的な動詞ではないので注意
1009:デフォルトの名無しさん
17/04/21 19:50:01.08 MpBIOwvX.net
>>962
BeginUpdate/EndUpdateはいいとして、
SuspendLayout, ResumeLayoutは反応しなくないか？
（というか>>958は俺宛ではなくEFの件なのか？と思っていた）
俺の理解ではSuspendLayoutはレイアウト時、つまり、Control.AddRangeを止めるもので、
Graphics.DrawLinesとかを止めるものではないと思っているのだが。
>>963
了解。
1010:デフォルトの名無しさん
17/04/21 19:56:01.47 FFGpioc0.net
>>960
コントロールのイベント使うな、っていうのは無駄な再描画対策じゃなくて設計論ね
そういう設計だと、例えばプログラムで倍率を変更しても再描画されないよね。
まあ余計なお世話だよねw
Application.Idleは例えばこうやって使う
bool DrawOnIdle {get; set;}
void Application_Idle(object sender, EventArgs e}
{
if (DrawOnIdle) redraw();
DrawOnIdle = false;
}
1011:デフォルトの名無しさん
17/04/21 20:10:34.38 Cei54Lla.net
VS2017でどのデータベースとEFを使うべきか質問したものです
レスありがとう
完全に浦島太郎状態でした
こんなことになってるとは思っても見ませんでした
.net.core の方の知識もなくてググってみたらマニュフェストらしき設定ファイルが
xmlからjsonになってるんですね...
1012:デフォルトの名無しさん
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:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています