Shell() doesnt look async to me in a special case

[dtv]

We know that Shell() runs an external program asynchronously, but here is a situation i've seen and gives me the feel that it seems that this command waits for something to be end first:

- A command line utility made with Vb6, it takes a bmp file as a parameter, converts it to a jpg file, sends it to an internet server through ftp apis, then finishes and unloads itself.

- A parent program made also with vb6 which includes a visual form with some objects, buttons, lists etc and just to be sure for the strange behavior i am describing here, a timer event which flashes a box on that form every one second. The flash remains stable and continuously, until i am pressing a button which calls the first EXE and sends a specific picture to the internet. The flashing of the box stops for all the time that the second .exe runs. Like the Shell() waits for the program to end first before passes the control to the parent application.

Is that logical? Shouldnt Shell run the program absolutely in async mode and pass the control back to the form (and all the coming events like flashing the box) immediately after the second program is loaded (and before executes the first command which is to convert the bmp to jpg, then send it to internet). Both .exes are too small, about 50kb. When the button Shells to the converter program waits and freezes for more that 5 seconds (its the time needed for conversion to jpg format and upload process), for sure not the neseccary time to just load the program.

How come the two .exes are not fully independent in that case?

Hope i did make it to describle the situation, sorry for any syntax language errors.

[dglienna]

Because that would NOT be async. You'll find that VB6 doesn't do threading, while VB.Net can support anything that you can throw at it.

[dtv]

Shell runs async alright. It doesnt have to do with language stuff, like vb6 or vb.net. Shell runs another process. That process is a new process, and the Windows itself has to deal with it, not the calling app. Its not about multithreading.

Generally Shell runs async ok, but i believe in my case is because the two Exe are vb6 executables, meaning sharing common libraries etc. I am not sure about it, just a guess. For some reason the Windows Task Manager is not passing the control back to the calling application until the executed finishes. Its a unique case and i think the first time i am seeing something like that. Another guess is the kind of commands involved in the executed app, or some DoEvents which is missing (but as an independent app of course does not need any doevents statement just for another app to feel comfortable).

If Shell() behaves like ShellAndWait() custom function, why the need for the first one.

[dglienna]

ShellAndWait returns a value

[rxbagain]

It's because your child process is doing some processor extensive functions. I don't know but I think it's not a good idea to rely on the system to preempt our thread/process.

To demonstrate, here's a sample code that runs itself making the second process. At startup there is a code that waits for 5 seconds without releasing the processor. I put a timer that keeps placing the count in the caption. You will notice that during the time the 5 sec wait is processing, the parent process temporarily stops counting.

Option Explicit

Dim ctr As Long

Dim WithEvents timerX As VB.timer
Dim WithEvents cmdX As VB.CommandButton

Private Sub cmdX_Click()
   Shell App.Path & "\" & App.EXEName & ".exe", vbNormalFocus
End Sub

Private Sub Form_Load()
   Dim d As Date
   d = Now
   Call Me.Controls.Add("VB.CommandButton", "cmdX", Me)
   Set cmdX = Me!cmdX
   cmdX.Caption = "Run a copy"
   cmdX.Visible = True
   Call Me.Controls.Add("VB.Timer", "timerX", Me)
   Set timerX = Me!timerX
   timerX.Interval = 500
   While DateDiff("s", d, Now) < 5
   Wend
End Sub

Private Sub timerX_Timer()
   ctr = ctr + 1
   Me.Caption = ctr
End Sub

[DataMiser]

My guess would be that you would see a different result on a multi core cpu

[dglienna]

Correct. Core 2 Duo: had 4 instances running. Clock never lagged