- 1 名前：デフォルトの名無しさん mailto:sage [2017/01/28(土) 16:46:53.58 ID:op86qfG/.net]
- ■Visual Studio 2015 Community & Express (無償の統合開発環境)等はこちら
www.visualstudio.com/downloads/
■コードを貼る場合はこちら
ideone.com/
■前スレ
C#, C♯, C＃相談室 Part91
echo.2ch.net/test/read.cgi/tech/1467211515/
■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
- 984 名前：デフォルトの名無しさん mailto:sage [2017/04/20(木) 19:09:00.01 ID:ofUg/eB0.net]
- >>940
そうね
データベース（モデル）ファーストにしてるのは、
ER図を見るために使ってるだけだからそれでもいいかぁ
クエリ用（Read）とコマンド用（Write）双方ともDBからコードファーストで作って
DB変更時には再度作り直す方法でやってみるかなー
（どこらへんがコードファースト？ って使い方になっちゃうなｗ）
- 985 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 00:34:55.91 ID:IVDQeFzJ.net]
- 毎回迷うんだけど
VS2017ではどのデータベースを使うべき？
そしてEFはどのバージョンを使うことになって参考になるサイトはどこにあるんだ？
それそろ安定してほしいんだけど
- 986 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 01:26:41.50 ID:72Ff37pO.net]
- >>942
MSDN: Introduction to Entity Framework
ttps://msdn.microsoft.com/en-us/library/aa937723(v=vs.113).aspx
上記ページは、なんか日本語表示にはできるけどインデックスやら、
ページのリンクが英語になってたりして、チグハグ
和書では、EFについて書かれた本がほとんどない
書いてあっても一章分でさらっと流す程度だし、
ネット上の情報だと EF を使うための VisualStudio の操作方法とか、
いくつかの落とし穴の回避方法がパラパラ載ってる程度なので、
英語の MSDN をブラウザの翻訳機能で読んだほうがいいと思う
EF Core (EF7として開発されてたらしい) ではクロスプラットフォームの
ための軽量化で一部の機能を削いでるらしい（モデルファーストとかはできなくなる）
EF6 は EF Core が出てからもしばらくはサポートされるので、
今入門するなら EF6 を使うのがいいと思う
（というか、必要でない限り移行はお勧めされていない）
- 987 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 06:35:38.36 ID:h0UgT1Ml.net]
- EFはWeb系のノリで作られてるから安定することはないよ
- 988 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 07:48:39.88 ID:XjCRa8hg.net]
- 業務とデータベースに精通していて
全てを自由に弄れる立場にいて
時間をかけて生成されるデータ構造まで意識した精緻なモデル設計ができて
その案件の寿命までずっと面倒をみれるか同レベルの後継者を育てられる
そんな人がチームにいればモデルファーストは有りじゃないかな
そうでなければ使い捨てアプリぐらいにしか使えないよ
- 989 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 08:13:05.97 ID:dQDWETdW.net]
- >Web系のノリ
どういうこと？
- 990 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 08:17:36.55 ID:lbMf26rv.net]
- >>942
安定って具体的に何のことを言ってんの？とっくに枯れた技術だけど
- 991 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 09:12:06.55 ID:LWRI+6r2.net]
- >>946
ヤマトのりかと
- 992 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 11:08:44.37 ID:U4JkC8YI.net]
- EFとLinqのせいで生のSQL文が書けなくなっている。
- 993 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 11:45:09.91 ID: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 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 11:56:05.07 ID:8CN2PrPc.net]
- 開発されてないのが枯れてるのか。そりゃ確かに枯れてるなｗｗ
- 996 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 12:40:19.25 ID:dpyapAzz.net]
- >>946
あくまでもイメージだが品質とか安定性より開発速度とかリリースを優先するって感じ
>>947
腐ったまま枯れてるってことはいくらでもあるし
- 997 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 17:42:09.62 ID:MpBIOwvX.net]
- そういえば前から疑問なんだけど、フォームのイベント伝搬ってどう組むべきなんだ？
状況としてはよくある波形ビューワーで、表示先頭位置と倍率が変えられて、
カーソルが2つあって、フィットボタンを押すと画面にフィットするもの。
(カーソル0が画面の左端、カーソル1が画面の右端になるように、
自動的に表示先頭位置と倍率が調整され、再描画される)
(A) 表示先頭位置の変更→画面再描画
(B) 倍率の変更→画面再描画
とした場合、
フィットボタンを押す→
表示先頭位置と倍率が自動的に変更される＝普通は上記(A)または(B)に当たる
→自動的に再描画される
となるのだが、ほとんどのケースで2回描画されてしまう。
そこで今は、倍率変更側はフォーカスを確認して
(B') 倍率の変更→（フォーカスがある時のみ）→画面再描画
として1回描画にしているが、
これだとフィットボタンを押したとき、結果的に倍率のみの変更の場合は再描画されない
（同じ値を上書きしてもChangedが発火しない）ので、フィットボタンのイベントの最後に
if (!changed_start_pos) redraw();
を付けている。
ただしこれはリファクタ時に久々に見たら「はて？」と思ってしまった。
この場合って、どう組むべきなんだ？
ちなみにJavaScriptの場合は、プログラムによる変更の場合はイベントが発火しないので、
全てのイベントの最後に redraw(); が必要になるが、全部書けば全く問題ない。
フォームの場合はプログラムによる変更でもイベントが発火するので、この問題が起きる。
ただ、特にレアケースでもないし、一般的なうまいやり方があるとは思うのだけど。
上手く繋げられれば記述が少なくて済むからこの仕様なんだろうし。
- 998 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 17:42:43.14 ID: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 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 18:12:04.32 ID:FFGpioc0.net]
- >>953-954
そもそもコントロールのイベントで再描画ってのはちょっとw
表示先頭位置とか表示倍率とかの値はFormなりUseControlなり
独立したクラスなりのプロパティになってるはずで、それらのプロパティの変更痔に
再描画されるようにしないと
無駄な再描画を避ける方法だけど、一番いいのは余程重いのでなければ
気にしないことだと思うw
どうしてもこだわるなら、直接再描画するんじゃなくて
タイマーのイベントに再描画を紐づけしてタイマーをスタートさせるだけにするか、
Application.Idleイベントをうまく使うかするとか
- 1000 名前：あ mailto:sage [2017/04/21(金) 18:18:11.06 ID:KFYgHFHL.net]
- >>953
リドローが必要だとキューイングするかと。
どうせインプットのリフレッシュレートやら画面のリフレッシュレート越えてリフレッシュしても無駄なんだし、リフレッシュ時には再描画するんだし。
WindowsならWM_PAINTでやるとかが歴史的にいわゆる普通の方法では？
- 1001 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 18:23:10.98 ID:YZVNImgq.net]
- >>950
EntityFrameworkとEntityFramework Coreを同一視してるおバカさん
- 1002 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 18:35:37.53 ID:RSu3z+zM.net]
- フォームのように、SuspendLayout, ResumeLayoutみたいな設計もあるけどね
- 1003 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 18:51:51.53 ID:xzjZrHPt.net]
- イベント毎にRedraw要求を行うのではなく、
イベント毎にRedrawイベントをどこかのキューにぶち込んで、タイマーや別スレッドで監視し、
描画時に複数のRedrawイベントがあれば最新の物を一度で済ませるようにすればいい。
- 1004 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 18:55:13.11 ID: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 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 18:57:50.94 ID:MpBIOwvX.net]
- >>959
サンクス。まあみんな意見は同じか。
他に何か、「プログラムによる変更であってもイベントが発火する」という、
フォームの仕様を上手く使った方法はないかねえ？
- 1007 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 19:08:46.15 ID:xzjZrHPt.net]
- >>961
>>958みたいな感じじゃないか。
WindowsのListViewとかも、大量のデータ挿入を想定してBeginUpdate/EndUpdateと言った手段を用意しているし、一般的な手法かと。
- 1008 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 19:19:20.39 ID:72Ff37pO.net]
- >>957
違いを比較しているURL貼ってるのにレスを読みもしないで小馬鹿にする馬鹿
>>953
瑣末なことで悪いんだけど、どうしても気持ちがざわつくので指摘する
「リファクタする」は日本語としてあまり使われていない
refactor の訳としては「リファクタリングする」が使われている印象
どう間違っているのかはうまく説明できん
refactoring は造語で、それを元に refactor という動詞が造語として作られている
一般的な動詞ではないので注意
- 1009 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 19:50:01.08 ID:MpBIOwvX.net]
- >>962
BeginUpdate/EndUpdateはいいとして、
SuspendLayout, ResumeLayoutは反応しなくないか？
（というか>>958は俺宛ではなくEFの件なのか？と思っていた）
俺の理解ではSuspendLayoutはレイアウト時、つまり、Control.AddRangeを止めるもので、
Graphics.DrawLinesとかを止めるものではないと思っているのだが。
>>963
了解。
- 1010 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 19:56:01.47 ID:FFGpioc0.net]
- >>960
コントロールのイベント使うな、っていうのは無駄な再描画対策じゃなくて設計論ね
そういう設計だと、例えばプログラムで倍率を変更しても再描画されないよね。
まあ余計なお世話だよねw
Application.Idleは例えばこうやって使う
bool DrawOnIdle {get; set;}
void Application_Idle(object sender, EventArgs e}
{
if (DrawOnIdle) redraw();
DrawOnIdle = false;
}
- 1011 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 20:10:34.38 ID:Cei54Lla.net]
- VS2017でどのデータベースとEFを使うべきか質問したものです
レスありがとう
完全に浦島太郎状態でした
こんなことになってるとは思っても見ませんでした
.net.core の方の知識もなくてググってみたらマニュフェストらしき設定ファイルが
xmlからjsonになってるんですね...
- 1012 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 20:16:45.24 ID:TbfEGS8v.net]
- MSに関わると2,3年であっという間に浦島になるからな
- 1013 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 20:28:06.75 ID:MpBIOwvX.net]
- >>965
ちょっと話が噛み合って無い感があるから整理すると、
JavaScript:
プログラムからの変更ではイベントが発火しないから、
全てのイベントハンドラは redraw(); で締めないといけないが、
イベントハンドラ内で他コントロールをどれだけ触ろうと何も考える必要なし。
.NET:
プログラムからの変更でもイベントが発火するから、
関連しているコントロールのイベント先をすべて redraw() にしておけば再描画される。
だから単純な再描画についてはこっちの方が記述はすっきりする。
ただし、今回のように複数コントロールを触るイベントハンドラがあった場合、
その回数だけ再描画される可能性がでてくるからそこを対策しようとすると、途端に汚くなる。
（JavaScriptのコードは redraw(); を書くしかないし、再描画だとはっきり分かるが、
.NET のコードは俺が今やっている妙な対策法だと？？？なコードになる）
再描画されればいいのなら、.NETの方が良いけど、
2度描画禁止とかにしたい場合、.NETの方が記述が余計に必要になる。←これって俺の勘違いか？
というのが今回の疑問。
> そういう設計だと、例えばプログラムで倍率を変更しても再描画されないよね。
違う。プログラムから各
- 1014 名前：コントロールのValueを変更することによって、自動的に再描画させてる。
というか、波形表示画面内容と表示開始位置と倍率は当然同期してないといけなくて、
逆に、表示開始位置と倍率が変わらないのなら再描画の必要がない。
それはコントロールの値を変更する構造によって自動的に達成される。
(.NETは同じValueを上書きしてもイベントが発火しない為)
だからFitボタン連打とかの場合の無駄な再描画はここで止められる。
多分.NETの仕様だとこういう事だと思うんだよ。(これがMVC的に云々というのはまた別の話)
それで、2度描画禁止の場合はどう実装するべきだという想定なのだろう？という疑問なんだ。
普通はキューイングするから問題ない、ってことなのかな？
(なお、明示的に再描画したい場合は redraw() を呼ぶだけだから問題ない) [] - [ここ壊れてます]
- 1015 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 20:42:28.79 ID:MpBIOwvX.net]
- ちなみにMVCの場合はモデルがイベントソースで、
コントロールの値を変更→モデルの値を変更→再描画
という流れになるけど、モデルの値をプログラムから変更する場合、
コントロールの値の表示を手動で合わせてやる必要がでてくる。
これが面倒だから、WPFではバインディングってことで自動化してる。
これはこれで良いとして、
.NET作った時に今回のようなケースが想定されていないはずもなく、
彼等の想定実装があるはずで、
その通り実装すれば綺麗に実装出来るはずなんだが、というのが俺の疑問。
- 1016 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 20:43:34.30 ID:FFGpioc0.net]
- >>968
勘違いではないよね。
その認識であってると思う。
コントロールのプロパティを値の入れ物として利用するのは普通はよくない作法だと思う。
コントロールはあくまでUI（表示と入力）に徹するべきで、
表示先頭位置とか表示倍率とかの値はFormなりUseControlなり
独立したクラスなりのプロパティにするべきだというか、普通はすると思う。
で、再描画はコントロールのプロパティが変更されたタイミングではなく、
表示先頭位置なり表示倍率なりのプロパティが変更されたタイミングで行う。
当然、この場合も一度に複数のプロパティが変更されたときに
不要な再描画を回避する方法は考える必要がある
- 1017 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 21:04:34.72 ID:rPWpf+kQ.net]
- n秒に１回描画フラグを監視する仕組みのが楽だなｗ
コントロールの挙動全部把握してるやつが触らないとぶっ壊れるって
モノ作ってんだろ?
それって設計悪くない?
- 1018 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 21:07:01.51 ID:MpBIOwvX.net]
- >>970
> コントロールのプロパティを値の入れ物として利用するのは普通はよくない作法だと思う。
MVC的にはそうだね。ただ、この部分のUIなんて変更はないからどっちでもいいのも事実。
ところでその場合、バインディングはどう実現する？
(C) numericUpDownのValueChanged→モデルの値を変更
これはいい。ただFormの場合、
(D) モデルの値が変更された→イベント発火でnumericUpDownの表示値を変更
とすると、当然(D)の直後に(C)が発火して、
モデルの値を再度「同じ値」で上書きして、そこでイベントが止まる。
これって全くの無駄でしょ。
.NETの仕様を決めた時、これらが想定されていないはずもなく、
彼等なりの上手い使い方があったと思うんだよね。
(今現在それが良いとされる手法かどうかはともかく)
今のところ、表示とモデルの内容を同期するのに一番簡単な方法は、
「numericUpDownのValueをモデルの値として扱うこと」なんだよ。
そしてこれだと他クラスから見えないので、コピーを持ってる。
これは後付でこうなった、というのもある。
実装は、イベントハンドラに何個でも関連づけさせられるからそこでさせてる。
- 1019 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 21:13:36.92 ID:MpBIOwvX.net]
- >>971
モデルをどこに置くか、という話なんだよ。
Formの仕様だと、numericUpDownのValueプロパティを「モデルの値」として扱えば
すべてすっきり行く仕様になってる。だからそうしてる。
ところが2度描画禁止だとすっきり行かない。だからこれが疑問。
それならJavaScriptみたいに、最初から
「必ず1回redraw()を書かないとダメだけど、1回書けばいいだけです」の方が良かった。
だから、彼等なりの想定実装があったはずで、それを考えてる。
- 1020 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 21:15:27.48 ID:rPWpf+kQ.net]
- 使って問題がある場面のバインディングなんて使わなきゃいーじゃん
マイクロソフトお作法病って損だと思う
- 1021 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 21:15:53.73 ID:Re4upQlq.net]
- >>963
EntityFrameworkはもう十分枯れてるだろバカ
Coreは確かに発展途上だけどね
元のレスを読まないからこんな的はずれなURLを貼っちゃう
- 1022 名前： []
- [ここ壊れてます]
- 1023 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 21:18:21.74 ID:lnct7jOB.net]
- イベントがダブりそうなときはイベントを-して値代入後+しなおしているなあ
>>970の２段落目に賛成だな
見なおしたり他に移植するときにそっちの方が分かりやすいし
- 1024 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 21:33:34.84 ID:MpBIOwvX.net]
- >>974
バインディングといったから分かりにくいが、放置した場合は表示が間違ってるんだよ。
これは完全にアウト。
Fitボタンが押された→
モデルの値が変更された→
再描画された
これで「波形表示」は最新になるけど、
「表示開始位置」と「倍率」の表示されている値が古いままでしょ。
そしてFormのイベントはそれ用になってないんだよ。
>>976
> イベントがダブりそうなときはイベントを-して値代入後+しなおしているなあ
これってかなり面倒でしょ。
今のところタイマで遅らせるのが一番すっきりするからそうしようかと思っている。
(これは他部分で既に実装済みなのを流用出来るというのが大きいが)
redraw()を呼んだら16ms後にredraw_implement()が呼ばれて実際に再描画とか。
ただこんなの.NET作った頃から想定してたのかな？という疑問はある。
- 1025 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 21:34:54.35 ID:h0UgT1Ml.net]
- >>966
来年にはYAMLになってると思うよ
- 1026 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 21:37:01.31 ID:72Ff37pO.net]
- >>975
なんだ、枯れてるとか言ってボコボコ叩かれて悔しかった奴か
「Coreは確かに発展途上だけどね」
Core の前になんかつくだろカス
- 1027 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 21:49:04.78 ID:rPWpf+kQ.net]
- >>977
意味わからん
画面は自分が必要なときにデータを見て勝手に描画するじゃん
フォームはコントロールの操作によってデータを書き換えるじゃん
バインディングなんて使わなきゃ悩む要素皆無だったんでしょ?
- 1028 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 22:08:05.95 ID:Re4upQlq.net]
- >>979
おや、ようやくCoreを認識できたんだね
- 1029 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 22:08:53.85 ID:1MuUAA6h.net]
- >>979
自分が叩かれていることに気づいていないのは見苦しい
- 1030 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 22:09:14.20 ID:k73pGP5K.net]
- >>977
そのへんはレンダリングスレッドがUIスレッドと分かれてるWPFでやろうとしてたと思われ。
- 1031 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 22:29:56.50 ID:MpBIOwvX.net]
- >>983
え？WFPって描画はUIスレッドじゃなくていいのか？
それはすごくいい。
それだとスピンコントロールのボタン連打で描画が追いつかない時にも、
イベントが溜まることなく最新が常に表示されるね。
何もしなくても。
まあ何だかんだで新しい物は改良されてるってことだね。
- 1032 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 22:29:56.87 ID:Cei54Lla.net]
- かずきが日本マイクロソフトに入社してる！
本当に浦島状態
- 1033 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 22:34:32.90 ID:baDy0zQG.net]
- >>985
誰だよ？
- 1034 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 22:37:38.47 ID:k73pGP5K.net]
- >>984
描画はUIスレッドなのは変わらない。
UIスレッドで同じところにポンポン書き込んでも適当に間引かれる。
- 1035 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 22:37:41.43 ID:h0UgT1Ml.net]
- >>984
クソ重いから結果的にはWinFormsの方が遥かにレスポンス早いんだけどね
- 1036 名前：デフォルトの名無しさん mailto:sage [2017/04/21(金) 23:07:08.58 ID:MpBIOwvX.net]
- >>987-988
うーむ、やはりイマイチか。
回答くれた皆さんありがとう。
俺は>>970ではないけど、次スレ俺が立ててもいいけど。(>>1)
- 1037 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 01:19:50.97 ID:Af8PazvW.net]
- >>954
なんか無茶苦茶だな。
クリックイベントの最中に描画処理を実行してるのか？
再描画させたいならInvalidateRectとかでWM_PAINTを発生させてそこでまとめて描画するのが作法だぞ
- 1038 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 03:39:27.34 ID:BJdj4TZ/.net]
- >>990
御説ごもっともだけど、そんな偉そうに言うほどのことでもないよ
- 1039 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 04:54:36.82 ID:y5zvwDCw.net]
- 偉そうかどうかは関係なくない？w
- 1040 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 06:10:42.01 ID:4+2xx2Ut.net]
- >>992
発言の正当性より自己満足度で正当性を確保しているので重要です
- 1041 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 06:23:09.19 ID:9wvnPEyC.net]
- >>990
InvalidateRect発生させてもRect無視して全画面更新しちゃうよ。ふざけんな！
みたいな話だからな。ちょっと方向性が違うｗ
- 1042 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 06:45:50.45 ID:+hjaOcO8.net]
- >>991
2ch初めてか？ w
- 1043 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 08:50:41.11 ID:iVvswOrb.net]
- 次スレ立ててくる
- 1044 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 08:52:51.85 ID:iVvswOrb.net]
- 次
C#, C♯, C＃相談室 Part93
echo.2ch.net/test/read.cgi/tech/1492818720/
- 1045 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 09:05:33.60 ID:/oxuzvQq.net]
- ワッチョイなしで立て直して
- 1046 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 09:09:40.54 ID:AhKt2WIP.net]
- やなこった
- 1047 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 13:34:52.68 ID:3nsKygnV.net]
- 1000
- 1048 名前：過去ログ ★ [[過去ログ]]
- ■ このスレッドは過去ログ倉庫に格納されています
|
 |
