Top 上へ 目次
Ver.4系のβ版（？）Ver.4.60Ver.4.70(中編)
まぢすみません、まさかの3部構成になっちゃいました。
前回からの話の続きで「1個のタブが固まっても他のタブに影響を及ぼさないようになれば、かなり幸せだなプロジェクト」の一環です。
今回は「開く」なり「ジャンプ」なりのアクションの際に、対象がアクセス不能であった場合に発生する遅延の「隠蔽」です。
前回のように「解消」ではありません。
あくまで錯覚を起こさせるためのバックグラウンド処理です。
すごく雑な表現をしちゃうと「テキスト文字列のフルパス表記」から「ITEMIDLIST」に変換する際に、スンゲェ遅いものがたくさんあります。
前回手を入れた「切断されたネットワーク先」は飛びぬけてダメな子でしたが、やたらと応答の遅い仮想フォルダー（リムーバブルメディア、マイネットワーク、検索結果など）が今回の対象になります。
ちなみにXP時代には、そこそこの速度で応答が返ってきており、XPでは必要が無かったわけで、これもXPサポート終了計画の一環です。
なんか同じ内容を繰り返し書いてますが、問題の本質はVista/7/8/8.1がクソOSなんだと思います。
多分、メジャーOS番号が7になったら、似たようなドツボが待ってるんだろうな・・・という予感がヒシヒシとしますがね・・・。
なんとなーく、ファイラーの存在が許されない世界がチラホラ見えてますし。
で、愚痴っててもしょうがないので方法を考えます。
ざくっりと乱暴に手順を表現をすると、リストの走査スレッドに「このパス開いてね」って渡す時に、ITEMIDLISTではなくフルパス文字列を渡しちゃいます。
で、走査スレッドの中でITEMIDLISTに変換しちゃえば、他のタブに影響されず動作する・・・というカラクリです。
まぁ、一覧の作成処理が成功するか失敗するか分からんけど、とりあえずスレッド作って放り込んじゃえという発想ですね。
さて影響範囲なんですが、ユーザーが手入力って、入力間違えをすることが大前提になるわけですよ。
つまり、現在のパスが不明という状態が頻繁に起こるわけですね。
そして内部的には「フルパス文字列」って、一覧生成どころかファイル操作でも使用していません。
ほとんど、このITEMIDLISTというブラックボックスを用いるように作られています。
つまり、スレッドに丸投げされてるので、自分の親フォルダが何なのか？取得できるかどうかすら判定不能な場合もあるのですから、異常判定の処理を片っ端から見直す必要があるわけですよ・・・被害甚大です。あうあう。
・・・しかしまぁ、最初からXPの対応は諦め半分でしたが、結構できちゃうもんですね。ちょっとびっくりしました。
まぁ誰も動作保証してくれないものを、私が動作保証しなければならないというのは辛いですけどね。
というわけでキリが良いので、ここで一旦切り上げるつもりでした。
しかし「開く」「移動」の次は、当然「閉じる」「中断」の改善をしないと粗が目立って仕方ありません。
というわけで、今しばらく気長にお付き合いください。