お世話になっております。　また調べても分からない事象が発生したので、
教えて頂きたく、質問させて頂きます。
初心者レベルの質問かもしれませんが、ご了承下さい。

ＯＳ：Windows2000
開発：ＶＢ６．０

Shell関数を使用して、別のEXE（EXE名を「Ｂ」とします。）に起動を掛ける処理があります。
「Ｂ」の処理は条件により、処理をする時と、Sleepで２０秒程待機する場合があります。

「Ｂ」が、処理をする際は、Shellからの戻りが、１秒〜２秒で返ってくるのですが、
「Ｂ」が、Sleepをする際、Shellからの戻りが、１０秒程度掛かります。

なお、実際のShellで実行する部分は、下記のようになっています。
Call Shell(ディレクトリフルパス & ＥＸＥ名)

「Ｂ」の処理内容は、単純でして。
トリガーファイルが存在すれば、処理を行う。
トリガーファイルが存在しなければ、Sleep２０秒し、再度トリガーファイルの存在をチェックしま
す。

Shell関数以外の起動方法がある事は、知っているのですが
「原因追求しなさい」との命令に逆らえません。
知っている方がいらっしゃいましたら、是非教えて下さい。

> 「原因追求しなさい」との命令に逆らえません。
原因は Shell関数 のつくりそのものです。
Shell関数のヘルプにもありますが、
<引用>
メモ
   既定の設定では、Shell 関数はプログラムを非同期的に実行します。
   したがって、Shell 関数を使用して実行を開始したプログラムが終了しなくても、
   Shell 関数の次のステートメントは実行されます。
</引用>
と、非同期実行するとあります。Sleepしないときうまくいっていたのはたまたまなのでは？と思います。


> Shell関数以外の起動方法がある事は、知っているのですが
一番簡単な解決方法は、WScript.ShellオブジェクトのRunメソッドを使うとか。

サンプル)
Sub test1()
    Shell "calc"
    MsgBox "オワ"
End Sub

Sub test2()
    CreateObject("WScript.Shell").Run "calc", 1, True
    MsgBox "オワ"
End Sub

回答ありがとうございます。

なるほど、Shell関数の仕様ですか。。。
「Ｂ」のSleep時間に比例して、Shell関数の応答時間が長くなるのが
若干気になりますが・・・「仕様です」と言いきっちゃいます♪

ちなみに、下記は実験結果。（体内時計でカウントしたので誤差ありありですが）
「Ｂ」のSleep時間　　Shellの応答時間
　２秒　　　　　　　　２秒ちょい
　４秒　　　　　　　　４秒ちょい
　５秒　　　　　　　　５秒ちょい
１０秒　　　　　　　１０秒ちょい
１０秒以上　　　　　１０秒ちょい　・・・・ここからは、いくらSleepさせても１０秒程度
　
> 一番簡単な解決方法は、WScript.ShellオブジェクトのRunメソッドを使うとか。
おぉぉ！なる程、これは簡単ですね♪
ありがとうございます。また武器が一つ出来ました。

> 「Ｂ」のSleep時間に比例して、Shell関数の応答時間が長くなるのが
> 若干気になりますが・・・「仕様です」と言いきっちゃいます♪

Sleep API の使用は、避けた方が良いかと。
hhttp://www.bcap.co.jp/hanafusa/vbbbs/wforum.cgi?no=6548&reno=6547&oya=6547&mode=msgview&page=0

魔界の仮面弁士さんもおっしゃっていますが、アプリＢのSleepが悪さをしているとしか
考えれません。
(ＢがVBでできているとは思わなかったわけで。。。6547で話題になっていましたね。)

ためしに、VB6とVC6でSleepをするEXEを作って、Shell関数で確認したところ
VB側だけ遅延することが確認できました。

# 》 ウィンドウを作成するスレッドでは、Sleep 関数ではなく、MsgWaitForMultipleObjects または
# 》 MsgWaitForMultipleObjectsEx 関数を使ってください。
# より
# VCはコンソールアプリケーションです。
# VBはコンソールアプリケーションっぽく作っても、ウィンドウは生成されてしまうんですね。

追記
実際にMsgWaitForMultipleObjectsを使ってみると、Sleepのような現象は起こりませんでした。

# 脱線

> # VBはコンソールアプリケーションっぽく作っても、ウィンドウは生成されてしまうんですね。

対話モード不許可(App.UnattendedApp = True)モードでコンパイルし、かつ、
リンカパラメータを /SUBSYSTEM:CONSOLE に変更すれば、ThunderRT6Main は生成されないかな。

ちなみに、/SUBSYSTEM:CONSOLE の場合は、FileSystemObject の GetStandardStream()
メソッドで、標準入出力を手軽に扱えたりする…。今回の件とは関係ないけど。

なるほど。　ありがとうございます。
VBでSleepってあまり信用出来ないっぽいですね。
色々調査している時にも、同じような事をおっしゃってるサイトが多数ありました。（＾＾；）

色々教えて下さいました方々ありがとうございました。

ＰＳ：今度は、意味不明な障害が発生してしまいました。
　　　つきましては、新しくスレッドをあげるので、分かる方、どうか教えて下さい。