- 1 名前：デフォルトの名無しさん mailto:sage [2009/04/01(水) 10:15:52 ]
- (#ﾟーﾟ)つ ＜ C#、.NETの話題はこちらでどうぞ。
前スレ
C#, C♯, C#相談室 Part51
pc12.2ch.net/test/read.cgi/tech/1233757615/
Visual C# 2008 Express Edition 日本語版
www.microsoft.com/japan/msdn/vstudio/express/vcsharp/
その他テンプレ>>2-5くらい
- 66 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 15:38:44 ]
- なんで機能を継承してるのに隠蔽する必要があるの？
っていう話に落ち着くぜ
- 67 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 16:08:04 ]
- そういう場合って継承するんじゃなくインスタンスをプライベートに持って
アクセサを作るのが普通なんじゃない？
#言語仕様とは別のデザパタのdelegationって奴になるのか？
継承してるのに使えないとかはOOの性質上無理だと思うけど。
- 68 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 16:11:45 ]
- >>66
>>67
ですよね
今作られている既存のカスタムコントロールがそう作られていて大きく変えないようにするにはどうかなと考えていたんですが・・
おとなしく新しく作り直してそっちに変更するように要望をかけるとします。
- 69 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 17:12:19 ]
- TextAlignは見えるけど，機能上使えない，っていう特殊化ならアリ
- 70 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 17:34:53 ]
- 継承はis aの関係が基本で、決してカスタマイズ／再利用じゃないからね。
継承元で出来る事が継承先で出来なくなるのは有り得ない。
- 71 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 17:35:33 ]
- 既存のコントロールを内包してるけど、
別物として扱いたいってことか。
セットされた値を何かしらの方法で計算して表示するコントロールでほとんどラベルなんだけど、
表示されてるテキストは直接書き換えはさせたくないみたいな。
- 72 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 17:39:20 ]
- ググったら似たような質問あったよ
件名：[C#]コントロールのプロパティ固定(継承)
www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=42032&forum=7
セッターを空のメソッドでオーバーライドして殺してるみたい。
質問の内容自体に対する評価はここと似たようなもんだな。
- 73 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 17:43:11 ]
- youtubeとかニコニコの動画のダウンロードってどうやるの？
- 74 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 17:54:04 ]
- 一度言ってみたかった・・・
「ググれカス」
- 75 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 18:16:56 ]
- >>55
洋書でいいなら、中国語でいい本がある
- 76 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 18:18:01 ]
- グぐってきました・・・で、動画のurlの特定ってどうやるんですか？
- 77 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 18:23:40 ]
- >>76
。 。
。 ｡ 。 。 ﾟ
。 ｡ﾟ。゜。 ﾟ｡ 。
/ ／/ ／ ／
( Д ) Д)Д))
- 78 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 18:29:53 ]
- C#に特定した話じゃないなあそれ
- 79 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 18:35:29 ]
- ・・・もういいです・・・使えない人たちですね
- 80 名前：73 mailto:sage [2009/04/06(月) 18:39:47 ]
- >79
これ誰だよｗ
C#じゃないみたいなんで、他所のスレ探します
- 81 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 18:43:39 ]
- 取り敢えず公式見てこいよ。
「正当な」方法でどうやって情報取得するかきっちり書いてあるんだから。
- 82 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 18:44:58 ]
- 公式はどこにあるのですか？
教えて下さい
- 83 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 18:48:53 ]
- そりゃニコニコやyoutubeのトップから辿れよ
- 84 名前：73 mailto:sage [2009/04/06(月) 18:53:18 ]
- >>81
ありがとう調べてみます
>>82
だから誰だよｗｗ
- 85 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 18:58:28 ]
- >>75
中国無理っす
- 86 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 19:00:20 ]
- >>80,84
いい加減にしてください・・・誰なんですか・・・
- 87 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 19:07:16 ]
- これが無職いたのよいところ
- 88 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 19:16:56 ]
- ここまで全部俺の(ry
- 89 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 19:22:05 ]
- もう私のために争うのはやめて！
- 90 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 19:29:15 ]
- WebBrowser Controlでの質問です
ttp://domworld.cool.ne.jp/mst/index.cgi?mode=mstinit
↑のページを完全に読み込みたいんですが、javascript?のところで途中で止まってしまいます
MessageBox.Show( webBrowser.Document.GetElementsByTagName( "html" )[0].OuterHtml );
でHTMLを表示してもソースと違っていてどうにもなりません
対処法があれば教えてください
あとソースとwebBrowserのhtmlが違う理由をわかる方いたら併せてお願いします
- 91 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 20:07:24 ]
- 違っていてってどう違ってるのかぐらい教えてくれよ。
User-Agentあたり見て出力内容わけてたりしてな。
- 92 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 20:13:43 ]
- >>90
ううむ。折れんところで試してみたが、一応完全に？読めたけど。
- 93 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 20:15:57 ]
- >>90
> ソースとwebBrowserのhtmlが違う理由
ブラウザがパースしたDOMをテキスト表現にしているからだとおも
- 94 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 20:54:33 ]
- >>91-93さん
レスありがとうございます
WebBrowser.Document.All.GetElementsByName("id")[0].SetAttribute( "Value", "name" );
のように入力してログインまで持って行きたいんですが
>>92
正確ではありませんでした
すみません
DOM解析済みのHTMLでFrameを取りに行ってるみたいなんで無理みたいですorz
WebBrowserコントロールからフレームを利用したのページのHTMLソース取得方法
ttp://social.msdn.microsoft.com/Forums/ja-JP/vsgeneralja/thread/41e23caf-05d6-4dff-b5a1-9b1ecb12b4ed/
- 95 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 22:15:40 ]
- >>94
がんばればできる。
- 96 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 14:17:00 ]
- 現在大体100μs単位で動くタイマーを作成しているのですが、別スレッドからControl.BeginInvokeでコントロールを
操作する際に、そこでApplication.DoEvensを実行すると、コントロールが壊れる?みたいなのですが、なぜでしょうか?
具体的にいうと、別スレッドでビジーループを回して待機していたタイマーからイベントが飛び、Control.BeginInvokeで
メインスレッドにて登録されたデリゲートを実行するようになっており、デリゲート内にApplication.DoEventsがあると、
別ウインドウで操作していたHScrollBarが壊れ、Dock.FillしていたはずのコントロールがHScrollBar部分をドラッグ
することによりリサイズできてしまう、という具合です。
サンプルプロジェクト:
ttp://www1.axfc.net/uploader/He/so/214358
pass: invoke
サンプルプロジェクトのProcessingWindowのStartボタンをクリックした後、ControlWindowのスクロールバー右を
連打するとスクロールバーが壊れます。
一応メインスレッド上でタイマーのビジーループを回すか、Application.DoEventsを取り除くことにより回避できますが、
前者だと何もしてなくてもCPUを食ってしまうし、後者だと重い処理を行っているときにUIの更新ができなくなってしまう
のでできれば別スレッドからBeginInvokeしたときにApplication.DoEventsを実行したいのですが…
- 97 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 16:04:51 ]
- とりあえず俺の環境では起きないんだが
- 98 名前：96 mailto:sage [2009/04/08(水) 17:32:32 ]
- >>97
こちらでは、スクロールバーの右の矢印部分を連打(結構なスピードで)すると簡単に発生するのですが…
スクロールバーの描画が破綻した後、右矢印部分になぜか点々(サイズ変更可能なウインドウに表示されてたり
するアレ)が表示されます。
こうなると、スクロールバーは完全に機能しなくなり、スクロールバーのあった部分は再描画が無効になります。
- 99 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 18:07:52 ]
- >>98
俺も結構な速度でやってみたんだけどな
それこそクリックしたら画面の女の子脱ぎますよと言われたくらいの速度でｗ
ほぼ同じ環境の後輩に同じことやらしてみたけど症状が出てない
一応環境
VISTA BUSINESS SP1(エアロ有効)
VS2008 Professional上でデバッグ実行
- 100 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 18:23:43 ]
- >>97のPCで問題を再現するには超人的なスピードでの連打が必要なんだよ、きっと。
>>98
こういうケースでは、スリープを追加するなどして
"連打" ではなく、一回のクリックで問題を再現させることを目指すと、原因がわかったりするよ。
例えば、DoEvents()の後にThread.Sleep(100);と書き、スクロールバーを右クリックしてみるといい。
運良くこっちと似た環境ならば、100％の確率でスタックオーバーフローするので
スタックトレースを見れば原因がわかるはず。
- 101 名前： [―{}@{}@{}-] デフォルトの名無しさん mailto:sage [2009/04/08(水) 18:25:08 ]
- >>98
ディスプレイドライバのせいだったりして
ハードウェアアクセラレータ無効にすると治るとかない？
- 102 名前：96 mailto:sage [2009/04/08(水) 18:44:52 ]
- >>99
こちらでは速めのダブルクリック程度の速度でも発生するのですが…
こちらの環境は
Geforce 9600GT 512MB
XP 32bit
VS2008 Pro
です。
>>100
スタックオーバーフローするのは、BeginInvoke内でdoEventがtrueになる前に何度もBegineInvokeが
実行されてしまうのが原因でした。これについては、Invokeの前にdoEventをtrueにすることにより解決できましたが、
スクロールバーが壊れるのとは別問題のようです。
>>101
ハードウェアアクセラレータは切ってみましたが、特に関係があるわけではないようです。
ドライバも最新のものにしてみましたが、改善しませんでした。
- 103 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 20:38:21 ]
- ほんとだうちの環境でも壊れたぞ。
- 104 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 21:12:13 ]
- >>102
うーん。自分の環境だと再現しないので勘になっちゃうけど。
DoEvents でもたぶん BeginInvoke なキューを処理する気がするから
このコードだと一度間に合わなくなればそれより優先度の低いメッセージは
まったく処理されなくなる希ガス
あとそもそも精度 100μs なんて無理って話は突っ込んでおいたほうが
いいのかな
- 105 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 21:35:32 ]
- >>96
環境によって差が出てるということは、
Control.BeginInvokeの発行間隔が処理時間より短いせいだと思う。
前の処理が終わらないうちに次のBeginInvokeが実行されないようにするか、
同期型のControl.Invokeにする。
あとはDoEventではなくpictureBox1.Updateを使うべきだろう。
- 106 名前：96 mailto:sage [2009/04/08(水) 22:10:18 ]
- >>104,105
それだと、タイマーのインターバルをゆっくりにすれば発生しないはずですが、それでも発生しますし、
インターバルが短くても、Application.DoEventsを取り除くと発生しなくなります。
また、フラグを立てて(バグってたけど)同時に何度もBeginInvokeされないようにはしているので、
>>102の通り、別問題な気がします。
>>104
>>100μsなんて無理
確かに精度はよくないのですが、実際に使うときには最短で200μs程度のインターバルで使用するので、
その間隔で使用する分には何とか使用できる程度の精度は出るようです。
>>105
このサンプルでは、画面の更新しかしていないためそれでもいいのですが、実際はボタン操作や
テキスト操作なども反映させるため、Application.DoEventsを使いたいのです。
- 107 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 22:29:01 ]
- DoEventsでやらずに、ピクチャーボックスのInvalidateメソッドを実行し、
描画はImageプロパティは使用せずに、Paintイベントで描画するようにすれば?
GraphicsオブジェクトはPaintイベントの引数eにe.Graphicsがあるからこれを使用して描画する
- 108 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 22:31:40 ]
- テキスト操作も更新するときはそいつのInvaridateを実行。
DoEvenｔsはプロセスすべてのイベントを処理するから重いんだよ。
- 109 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 23:03:36 ]
- μsはmsの間違いだと思う。
- 110 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 23:34:43 ]
- 排他とかInvalidateでの再描画とかいくつか考慮は必要なのだが、
この方法でいけるはず。
基本はControl.InvokeもApplication.DoEventsも使わないことだな。
if (!abort)
{
//c.BeginInvoke(busyMethod);
Tick(this, EventArgs.Empty);
}
//pictureBox1.Image = image;
using (Graphics g = pictureBox1.CreateGraphics())
{
g.DrawImage(image, 0, 0);
}
Draw(count);
count++;
//Application.DoEvents();
- 111 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 00:08:41 ]
- >>96
なんか分かってるのか分かってないのかよく分からんコードだな、というのが率直な感想。
なぜそうしているのか理由や必然性がわからない部分が多すぎる。
ちょっとVB上がりのコピペプログラマの臭いがする。
つーか、せいぜい70hzでしか更新されない画面をusオーダーで更新して（そもそも不可能だけど）
なんか意味あるのかなw
- 112 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 01:04:43 ]
- >>110
テキストの更新をするだけならInvaridateで十分なのですが、ボタン操作やメニュー、ショートカットキー等々の
UIの操作を行った際に発生するイベントを処理するためにDoEventsを差し込んでいます。
そういう意味で、ボタン操作やテキストの更新と書きました。
>>111
VBの方はほとんど触ったこと無いですw
実際に使用する際には画面更新中に発生したTickの回数分だけ処理をとばすようにはするのですが、
その前にタイマーがちゃんと動作するかどうかを確認している際に発生したのがこの現象です。
サンプルの方はDock.Fillなはずのコントロールがリサイズできてしまうということを確認してもらうために
余計にコントロールを追加していたり、タイマーが回っているのを視覚的に確認するために画面更新していたり
しますが、実際にはウインドウにHScrollBarを貼り付けても発生しますし、TickのDrawを中身空っぽのforを
10万回回した後にDoEventsするだけでも発生します。
- 113 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 01:13:01 ]
- どんなに Interval の数値大きくしてもCPU使用率が上に張り付くんだけど
本当にこれで処理大丈夫なの？
- 114 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 01:29:36 ]
- >>112
あほな自家製タイマーがメッセージループを占有しなければ、
＞UIの操作を行った際に発生するイベント
はdoeventsなんか呼ばなくてもちゃんと処理されるのだけどね。
メッセージループ経由でのUIの更新は動画のような短時間での更新向きではない。
なんかWin3.1のころのメッセージループのアイドルにバックグランド処理をやらせる
のを念頭に置いたりしてないか。
- 115 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 02:46:55 ]
- マイクロ秒とかそもそもリアルタイムOSじゃないWindowsには過酷すぎる要求ではないか
- 116 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 09:13:24 ]
- >>112
ちょｗｗｗ
スレッド分けてる意味のないコードになってるってことじゃないのか…・
- 117 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 09:16:13 ]
- >>112
valid
Invalid
Invalidate
な
2回以上同じところを間違えると馬鹿みたいだぞ
- 118 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 09:50:34 ]
- 根本的にわかってないようだな
- 119 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 11:49:46 ]
- vb触った事無いらしいが
作りこみがVBにしかみえない
- 120 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 12:17:54 ]
- VBっぽい作り込みとC#っぽい作り込みって具体的に
どの辺が違うんですか？素で気になります。
初心者の書き方っぽいだけでVBが悪いわけじゃないのか
VBを使うと必然的にそうなるのかよく分からない。
もしかして.netのVBを指している訳じゃない？
- 121 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 13:26:42 ]
- VB6っぽいというべきだろうな。
.NETでDoEventsを使っているなら９割がた間違った使用法と考えるべき。
何のためのスレッドかぜんぜん理解していないようだし、
Control.BeginInvokeが何をしているかも理解してないな。
- 122 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 17:33:25 ]
- 誰かFormとマルチスレッドとConrol.BeginInvokeについて説明してやれよ
- 123 名前：96 mailto:sage [2009/04/09(木) 20:24:27 ]
- >>121
・Application.DoEventsは、処理中に発生したイベントをすべて処理する
・スレッドは重い処理などをバックグラウンドで処理させたり、処理を並列して行うことにより高速化を図る
・Control.Invokeは別スレッドからのUIの操作をUIを持つスレッドに行わせ、BeginInvokeは処理の完了を
待たずに制御を戻し、処理の状況を確認するためのIAsyncResultを返す
と理解しているのですが、違うのでしょうか?
もし違うのであれば、参考となるページでもいいので教えていただきたいのですが…
- 124 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 20:26:59 ]
- そこまでわかってれば、DoEventsを使う必要には迫られないはずだが
- 125 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 23:46:32 ]
- >>123
VB6はバックグラウンド処理用にスレッドを自由に起動できなかった。
全部の処理はUIスレッドで実行するしかなかった。
だからビジーループ的な処理があると、それを実行している間はUIが
必然的に応答できなくなる。（だってその処理は、プロセス中の唯一のスレッドである
UIスレッドで実行しているのだから。）
その問題をやり過ごす（根本的解決ではない）ためにDoEventsは使われた。
ビジーループの中でDoEventsを実行してやると、その時点でキューにたまっていた
ウィンドウメッセージが全て処理される。つまりユーザー目線では、UIが操作に反応する。
自由にスレッドを起動できるドトネトではわざわざUIスレッドでビジーループを
書く必要がないから、わざわざApplication.DoEventsを使用する理由は普通ないはず。
- 126 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 00:05:44 ]
- >>123
バックグラウンドのスレは高速化じゃなく、ユーザへのレスをよくするのが目的では？
- 127 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 00:59:33 ]
- マルチコア（CPU）なら、マルチスレッドは高速化に寄与するよ。
- 128 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 01:48:03 ]
- もちろん、複数スレッドで同時に仕事をやらせればの話だけどね。
- 129 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 01:54:50 ]
- そもそも、高速化 = レスポンスとスループットの向上 と考えれば間違ってないでしょ
- 130 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 01:58:00 ]
- レスポンスとスループットはトレードオフになることが多いよ。
- 131 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 02:26:08 ]
- やりかたによるけど反応返ってこなくなるもんな。
- 132 名前：96 mailto:sage [2009/04/10(金) 02:37:10 ]
- >>125
では、今回のように別スレッドからBeginInvokeなどが連続して呼ばれて結果的にビジーループ
のようになってしまうような処理の場合、どのようにしてイベントを処理すればいいのでしょうか?
タイマーの精度をあきらめる(そもそも無茶らしいですが)として、
while (!abort)
{
while (doEvent && !abort)
{
Thread.Sleep(1);
}
...
Thread.Sleep(1);
}
としてもTickの内容が重たいとビジーループになってしまうのですが…
ここまでするくらいならSystem.Windows.Forms.Timerかなんかを使ってTickで処理時間分Intervalから引いていった方が
いいような気もしますがw
- 133 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 02:41:48 ]
- UIに限って言えば
UIが属していないスレッドがいくらビジーループになっても構わないのでは？
あと草が邪魔
- 134 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 09:00:49 ]
- よくわからんけど、多重呼び出しにならないよう待たせるか、
呼び出す度に重い処理のスレッド作るとか
- 135 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 09:23:03 ]
- どうせDOEVENTやってんだから普通にInvokeでやってみれば？
そんな重そうな処理でもなさそうだし
Invokeの中身を高速化するために、画像を先に作っといてInvokeで呼び出されている関数内で転送するだけにするとか
以上ド素人の意見でした。
- 136 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 10:29:34 ]
- そもそも96はどんなソフトを作ろうとしてんだ？
- 137 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 10:48:24 ]
- CodeDomProvider.CompileAssemblyFromSource()
でソースを動的にコンパイルした場合、そのソースの中から
アプリ本体のクラスを使うことはできるのでしょうか？
- 138 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 10:55:39 ]
- >>137
普通に出来るでしょ
参照アセンブリに追加すれば
コンパイルする前に参照するアセンブリをロードしなきゃいけないんだったかな
適当にそのアセンブリのクラスを使えばロードされる
- 139 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 10:59:48 ]
- >>137
CompilerParametersに参照をしたら出来るんじゃなかったっけ？
よく憶えてないけど
- 140 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 11:13:08 ]
- >>132
わざわざdoevents使うなんて
実質シングルスレッドで動かしてますよと公言するよーなもん
- 141 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 19:58:48 ]
- >>132
言ってることがよく分からないんだけど、
例えば仮に1msの処理時間が必要な処理があるとして、
この処理を同一のスレッドで1ms未満のインターバルで繰り返すことは
太陽を西から昇らせる以上に不可能だ、というのはOK？
失礼だがなんかこのあたりの当たり前のことを理解してない気もするんだが。
- 142 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 20:30:55 ]
- >>141
まずその処理が1msで終了するのか勘定してみるといい。
スレッド起動から勘定するんだぞ。
- 143 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 20:57:31 ]
- >>142?
- 144 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 21:09:47 ]
- >>142??
- 145 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 21:13:00 ]
- >>142???
- 146 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 22:32:31 ]
- ＵＩスレッド以外からＵＩを操作すると壊れるってのも理解してないような気がする
- 147 名前：137 mailto:sage [2009/04/11(土) 01:44:04 ]
- >>138 >>139
CompilerParameters.ReferencedAssemblies.Add("EXEファイル名");
でできました。ありがとうございます。
- 148 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 04:43:38 ]
- ComboBoxコントロールなんですけど
ドロップダウンの表示幅を表示するテキストに合わせて伸縮させることは難しいでしょうか
- 149 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 08:12:32 ]
- オーナドローでググれば一撃
- 150 名前：96 mailto:sage [2009/04/11(土) 12:52:55 ]
- >>133
>>132で言ってるのは、別スレッドからTick終了後に間隔を開けずにまたTickが呼ばれるため、結果的に
UIを持つスレッドがビジーになってしまう、ということです。
>>141
そこについては理解しています。
上の方にも書きましたが、BeginInvokeが何度も呼ばれないようにフラグを立てています。
ですが、
Tick Tick
├───┤ ├───┤
├─────┤├─────┤├─────┤...
インターバル ↑ インターバル ↑ インターバル
↑:Tick呼び出し
となればTickとTickの間にほかのイベントを処理することが可能なのですが、今回の場合
Tick Tick
├─────────┤├─────────┤
├─────┤├─────┤├──┤├─────┤├──┤...
インターバル ↑ インターバル 待機 ↑ インターバル 待機
となってしまい、結果的にUIスレッドがビジーになってしまうため、ということを言いたかったのです。
わかりにくくてすいません。
>>146
BeginInvokeやInvokeでUIを持つスレッドに処理を任せても壊れてしまうのでしょうか?
別スレッドからUIを直接操作すると壊れる、ということは実験したことがあるのですが…
- 151 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 12:55:05 ]
- >>150
結果的にUIスレッドがビジーになってしまうため、 → ×
結果的にUIスレッドがビジーになってしまう → ○
です。
- 152 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 13:44:31 ]
- あんたはどんなアプリを作ろうとしてんだ
- 153 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 15:00:31 ]
- >>96=150=151
まず、設計が滅茶苦茶。原因は知識不足にあるのは明白なので、
勉強しろ(ここで問答しても埒が明かない)としか言えない
とりあえず、コードの不備だけ指摘すると、
UIスレッドでdoEvent=trueにしてるから、BeginInvokeが複数回呼ばれる可能性がある
タイミングによって、上記が全て完了する前にdoEvent=falseになっていることがある
その場合、更にBeginInvokeが複数回呼ばれる
で、暫くすると...＼(^o^)／
- 154 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 15:34:36 ]
- >>149
遅くなりましたけど、ありがとうございました。
オーナードローでいろいろ調べてやってみます。
- 155 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 15:44:18 ]
- doEventフラグがlockまたはvolatileで宣言されてない。
それにdoEventはBeginInvokeする前に設定しなきゃいかんだろ。
もっと言えばInvoke使えばフラグはいらない。
- 156 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 15:52:22 ]
- もひとつ、BeginInvokeでBitmapに描画、PictureBoxに設定、DoEventsの呼び出しを
やってるわけだが、Bitmapの描画はスレッド側、
つまりBeginInvoke呼び出し前に処理していいだろう。
何のためのスレッドだよ。BeginInvokeの中身は軽くしなきゃ。
- 157 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:00:08 ]
- >>153
> UIスレッドでdoEvent=trueにしてるから、BeginInvokeが複数回呼ばれる可能性がある
その点については、本人は治したと言ってるが、本当に治っているかどうか怪しいな
- 158 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:15:55 ]
- アニメーションを表示するのにpictureboxを使うものなのか？
直接スクリーンに描くにせよ、イメージにいったん描いて画面に転送するにせよ、
普通はPanelか何かにGraphices#drawImageを使うぞ。
そうすればControl.Invoke自体いらなくなる。
- 159 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:20:26 ]
- 普通はOnPaint、Invalidate、Updateを使うだろうな
ただし、バックグラウンドで生成した画像を表示する必要があるなら
PictureBoxを使ってもやってることは変わらないかも
- 160 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:25:47 ]
- >>159
動画のようなアニメーションにOnPaint、Invalidate、Updateはつかわんだろう。
はなはだ効率が悪いのに。
- 161 名前：96 mailto:sage [2009/04/11(土) 16:41:50 ]
- >>152
C#の勉強もかねて自分用の動画編集ソフトを作成しています。
>>153,155
その点については、>>100で指摘を受けてTick呼び出し前にdoEventをtrueにするように修正しましたが、
現在Invokeに置き換えて様子を見ています。
>>156
最終的な目標としては、もう一つスレッドを立ててそこでイメージを生成するようにしたいと考えています。
しかし、まだタイムラインのUIに手をつけたばかりなので、とりあえずTick内でイメージを生成するようにしていました。
>>157
上記の通り、Tickの前にdoEventをtrueにするようにし、BeginInvokeが重複して呼ばれることがないことを
確認しましたが、volatileをつけていなかったため、偶然だったのかもしれません。
>>158,159
PictureBoxよりもPanelに描画する方がいいのでしょうか?
OnPaintやControl.CreateGraphicsで直接描画するのとPictureBox.Imageにイメージをセットするのは
ほとんど変わらないものだと思っていたのですが…
- 162 名前：96 mailto:sage [2009/04/11(土) 16:48:26 ]
- これだとさっきと言いたいことが変わってる orz
>>156の部分の追記
ただ、ファイルアクセスがネックになってイメージの生成が遅れた場合に>>150の図のようになってしまうので、
これについてもどうにかしたいのですが…
- 163 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:50:27 ]
- アプリ見て大体想像していたが、動画編集アプリかよｗ
だったら、100マイクロ単位のタイマーなんてぜんぜん必要ねーじゃねーかよ。
なぁ、どっからマイクロ秒なんてものが必要と思ったんだ?
- 164 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:55:16 ]
- DirectShow使えばいいじゃん・・・
- 165 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 23:11:58 ]
- もうそこまでやるならDirectX使うべきだな
- 166 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 23:15:52 ]
- WinFormsでリアルタイムで動画イメージ生成して描画とかさすがにありえんわ
|
 |
