C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[10]: filesystemwatcherの昔のバグなおってたのかな

(過去ログ 14 を表示中)

[トピック内 12 記事 (1 - 12 表示)]　 << 0 >>

■4749 / inTopicNo.1)

　filesystemwatcherの昔のバグなおってたのかな

▼■

□投稿者/ 倉田　有大 (26回)-(2007/06/24(Sun) 15:54:26)

分類:[雑談]　

なんか、VS2002の時はRenamedイベントのとき、フルパスが全部小文字になってきたという
不具合か仕様があったんだけど、
いつのまにか2005になってから、直っている気がする～

引用返信 編集キー/

■4751 / inTopicNo.2)

　Re[1]: filesystemwatcherの昔のバグなおってたのかな

▲▼■

□投稿者/ 渋木宏明(ひどり) (242回)-(2007/06/24(Sun) 18:56:16)

もともと同時に多数の変更が発生した時は取りこぼすので、イベント引数で渡されてくるファイル名にそれほどの価値が無いように思います。

引用返信 編集キー/

■4753 / inTopicNo.3)

　Re[2]: filesystemwatcherの昔のバグなおってたのかな

▲▼■

□投稿者/ 倉田　有大 (27回)-(2007/06/24(Sun) 20:07:58)

■No4751 (渋木宏明(ひどり) さん) に返信
> もともと同時に多数の変更が発生した時は取りこぼすので、イベント引数で渡されてくるファイル名にそれほどの価値が無いように思います。

うーん、エクスプローラーライクのようなやつを作っているのですが、一定時間たてば、監視しているフォルダ全部更新したほうがいいのでしょうかね？

引用返信 編集キー/

■4754 / inTopicNo.4)

　Re[3]: filesystemwatcherの昔のバグなおってたのかな

▲▼■

□投稿者/ 渋木宏明(ひどり) (243回)-(2007/06/24(Sun) 20:48:38)

ちゃんと確認したわけではないですが、「変更があった」こと自体はこぼさないようなんで、「どんな変更が起きたのか」だけを自力で調べればいいんじゃないでしょうか。

引用返信 編集キー/

■4772 / inTopicNo.5)

　Re[4]: filesystemwatcherの昔のバグなおってたのかな

▲▼■

□投稿者/ とっちゃん (150回)-(2007/06/25(Mon) 16:09:28)

■No4754 (渋木宏明(ひどり) さん) に返信

そんなものもつくっていたりしますが...ｗ
変更通知を受けたら(同一フォルダ内に限定しないと悲惨ですのでご注意をｗ)、フラグを立てて適当にリフレッシュが基本ですね。

うまく作らないと、更新しまくり地獄に陥るのでかなり難しいですが...

要するに通知のタイミングで更新だとまったく意味を成さないという事ですｗ

引用返信 編集キー/

■4778 / inTopicNo.6)

　Re[5]: filesystemwatcherの昔のバグなおってたのかな

▲▼■

□投稿者/ 渋木宏明(ひどり) (244回)-(2007/06/25(Mon) 17:27:17)

> うまく作らないと、更新しまくり地獄に陥るのでかなり難しいですが...
>
> 要するに通知のタイミングで更新だとまったく意味を成さないという事ですｗ

要件さえ許せば、適当に遅延させるのがコツですよね。

変更通知が来たらフラグ立ててタイマ起動→実際の処理はタイマハンドラで、とかよくやってます＞自分

ほぼ一定のペースで高負荷のシステムには使えませんが、そんなケースでは、どうせ抜本的にやり方変えないとうまくいきっこないし ;-p

引用返信 編集キー/

■4784 / inTopicNo.7)

　Re[6]: filesystemwatcherの昔のバグなおってたのかな

▲▼■

□投稿者/ とっちゃん (151回)-(2007/06/25(Mon) 17:59:58)

■No4778 (渋木宏明(ひどり) さん) に返信

うまく作らないと、更新しまくり地獄に陥るのでかなり難しいですが...
>>
>>要するに通知のタイミングで更新だとまったく意味を成さないという事ですｗ
>
> 要件さえ許せば、適当に遅延させるのがコツですよね。
>
ですです。

> 変更通知が来たらフラグ立ててタイマ起動→実際の処理はタイマハンドラで、とかよくやってます＞自分
>
おいらは、変更通知監視スレッドつくって、そこで通知を受けたあと、再度Waitする際に、時限タイマーしかけて処理してます。
感じとしては
無限待機で通知待ち
待機時間設定して通知待ち
タイムアウトしたら更新司令

無限待ち...

という奴ですね。
もちろん、単純待機じゃなくて終了イベントとともに待つわけですが＜そうしないとスレッド終われねーからｗ

> ほぼ一定のペースで高負荷のシステムには使えませんが、そんなケースでは、どうせ抜本的にやり方変えないとうまくいきっこないし ;-p
>
です。
そういう場合は、監視を割り込ませるより自ら通知させるなどを検討した方がいいでしょうね。
元々、変更通知自身がエクスプローラのためにあるようなものだしｗｗｗ
＃それくらい細かいことができないってことですがｗｗ

引用返信 編集キー/

■4852 / inTopicNo.8)

　Re[7]: filesystemwatcherの昔のバグなおってたのかな

▲▼■

□投稿者/ 倉田　有大 (28回)-(2007/06/27(Wed) 17:53:44)

>そんなものもつくっていたりしますが...ｗ

おお、やはり作られている方おられるんですね。
というか、標準のエクスプローラーコントローラーってほしい気がするんですが、ないのかな？
まあ、自分のはSusiePlugin対応とか、ごちゃごちゃしているんですが。

> おいらは、変更通知監視スレッドつくって、そこで通知を受けたあと、再度Waitする際に、時限タイマーしかけて処理してます。
> 感じとしては
> 無限待機で通知待ち
> 待機時間設定して通知待ち
> タイムアウトしたら更新司令
>
> 無限待ち...
>
> という奴ですね。
> もちろん、単純待機じゃなくて終了イベントとともに待つわけですが＜そうしないとスレッド終われねーからｗ

なあるほど、一定時間たてば更新ですか。
2，3秒ぐらいがめやすかな？

引用返信 編集キー/

■4866 / inTopicNo.9)

　Re[8]: filesystemwatcherの昔のバグなおってたのかな

▲▼■

□投稿者/ とっちゃん (152回)-(2007/06/27(Wed) 21:11:49)

■No4852 (倉田　有大さん) に返信

> おお、やはり作られている方おられるんですね。
そういう仕事なんで...ｗ

> というか、標準のエクスプローラーコントローラーってほしい気がするんですが、ないのかな？
TreeView とか、ListView ってもともとエクスプローラのためのコントロールですよｗ
実際、それをサポートするための段取りが山ほどあります。
全部Native用で Managed なコードから使われることは全く想定していませんけどｗ

>
> なあるほど、一定時間たてば更新ですか。
> 2，3秒ぐらいがめやすかな？
>
そんなに待つ必要はないです。２秒も待ったらバグってるんじゃね？と思われます。
遅延を前提とするのなら、どんなに長くても一秒未満。通常なら0.3秒以下が基準です。
＃待機時間ではなく挙動が現れるまでの時間ですのでお間違いなく

これを超える時間変化がないと、あれ？と思われます。

実際はリストアップルーチンがどうなっているか？に大きく依存しますので
正直に言ってどれだけ待てばいいかはわかりません。完全に実装依存です。

ですので、全体を俯瞰して総合的に判断する形になります。

一応具体例もあげておきましょう。

おいらは異なる実装で２種類この、変更通知を持ってるんですが
片方は待ち時間なしです。それに対してもう一つは２００ミリ秒待っています。

変更通知の要求も違いますが、それ以外もまったく違っていますので
こんなにも時間差があるということです(待つ内容とどういう状況で利用しているかが
ぜんぜん違っているので同じ実装にはできない)。

引用返信 編集キー/

■4891 / inTopicNo.10)

　Re[9]: filesystemwatcherの昔のバグなおってたのかな

▲▼■

□投稿者/ 渋木宏明(ひどり) (251回)-(2007/06/28(Thu) 07:55:38)

> ＃待機時間ではなく挙動が現れるまでの時間ですのでお間違いなく

単に「変更通知を受けてからｘ秒後に処理を実行する」のではＮＧということです＞質問者の人

「最後の変更通知を受けてから、一定時間が経過したら実処理を開始する」ようにします。

別な言い方をすると、「変更通知を受けて実処理を開始するまでの間に次の変更通知を受けたら、再度実処理の開始を遅延させる」ということです。

> おいらは異なる実装で２種類この、変更通知を持ってるんですが
> 片方は待ち時間なしです。それに対してもう一つは２００ミリ秒待っています。

めんどくちゃいから、Timer クラスのデフォルト 100ms でやることが多いですｗ＞じぶん

引用返信 編集キー/

■4897 / inTopicNo.11)

　Re[9]: filesystemwatcherの昔のバグなおってたのかな

▲▼■

□投稿者/ シャノン (185回)-(2007/06/28(Thu) 10:23:43)

■No4866 (とっちゃんさん) に返信
>>というか、標準のエクスプローラーコントローラーってほしい気がするんですが、ないのかな？
> TreeView とか、ListView ってもともとエクスプローラのためのコントロールですよｗ
> 実際、それをサポートするための段取りが山ほどあります。

アイテムの形をしたリージョンを作る機能なんてのもありましたっけねｗ

引用返信 編集キー/

■4902 / inTopicNo.12)

　Re[10]: filesystemwatcherの昔のバグなおってたのかな

▲▼■

□投稿者/ とっちゃん (157回)-(2007/06/28(Thu) 12:11:25)

■No4891 (渋木宏明(ひどり) さん) に返信
> 単に「変更通知を受けてからｘ秒後に処理を実行する」のではＮＧということです＞質問者の人
>
> 「最後の変更通知を受けてから、一定時間が経過したら実処理を開始する」ようにします。
>
> 別な言い方をすると、「変更通知を受けて実処理を開始するまでの間に次の変更通知を受けたら、再度実処理の開始を遅延させる」ということです。
>
です。一定時間内に再度変更通知があればさらに遅延。という形ですね。
なので、待ち時間はそれほど長くとる必要はありません。

>>おいらは異なる実装で２種類この、変更通知を持ってるんですが
>>片方は待ち時間なしです。それに対してもう一つは２００ミリ秒待っています。
>
> めんどくちゃいから、Timer クラスのデフォルト 100ms でやることが多いですｗ＞じぶん
>
おいらのは、待機そのものが別スレッドなので、Waitのタイムアウト指定ですｗ
もっとも、Native のコードなのでManagedとはちょっと違うんですがねｗｗ＜段取りは変わらないけど...

■No4897 (シャノンさん) に返信
>>TreeView とか、ListView ってもともとエクスプローラのためのコントロールですよｗ
>>実際、それをサポートするための段取りが山ほどあります。
>
> アイテムの形をしたリージョンを作る機能なんてのもありましたっけねｗ

色々ありますよ～ｗ
ただ、エクスプローラのもろもろはOSのバージョンにべったり依存する上
9x系だとIEのバージョンにも依存するので、これはここで使えるのか？
というのが常に付きまといますけど...ｗ

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -