wshell.run on a datafile sometimes fails - what could be causing it ?

[R.Wieser]

Hello all,

I've made a small script which uses "wscript.run" to open a few folders, a
console window and open a datafile (implicitily running its executable).
Each of those steps is seperated by a sleep of half a second. The script is
manually started (by doubleclicking it).

The thing is that /sometimes/ the datafile step fails, and all I hear is a
single beep. I would like to know what causes it to fail, and what I can
do against it.

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
Hello all,
I've made a small script which uses "wscript.run" to open a few folders, a
console window and open a datafile (implicitily running its executable).
Each of those steps is seperated by a sleep of half a second. The script is
manually started (by doubleclicking it).
The thing is that /sometimes/ the datafile step fails, and all I hear is a
single beep. I would like to know what causes it to fail, and what I can
do against it.

Is the datafile's type associated to a program file with full path, or just
the file name?

[R.Wieser]

JJ,

Post by JJ
Is the datafile's type associated to a program file with full path,
or just the file name?

The program file is referred to by a full, absolute path (its not on the
standard searchpath)

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
The program file is referred to by a full, absolute path (its not on the
standard searchpath)

If the data file dynamically created/updated, the program file might have
problem opening it if it's done too soon where the data file is still being
opened.

Or the program file might have an inconsistency during its initialization.

Either way, it's still not clear whether the error occured within
WShell.Run(), or in the program file itself.

So, you might want to log the process using Microsoft Process Monitor to
findout exactly when and how it fails. As many times as needed.

[R.Wieser]

JJ,

Post by JJ
Either way, it's still not clear whether the error occured within
WShell.Run(), or in the program file itself.

There is a saying going along the lines of "the mother of all f*ckups is to
assume something".

You're right, the problem isn't VBS, but the program itself. Yesterday,
just before turning in, I realized that the actual program is launched by a
helper program (of my own hand). Which uses a WaitForInputIdle timeout of 5
seconds. It looks like that the actual program (sometimes) takes more than
that.

I've increased the timeout and changed the single beep to something a bit
more "thats not the system thats complaining" sound.

Thanks for the help. :-)

Regards,
Rudy Wieser