Google Groups unterstützt keine neuen Usenet-Beiträge oder ‑Abos mehr. Bisherige Inhalte sind weiterhin sichtbar.

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

7 Aufrufe
Direkt zur ersten ungelesenen Nachricht

R.Wieser

ungelesen,
08.07.2021, 06:26:1408.07.21
an
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

ungelesen,
09.07.2021, 07:30:5309.07.21
an
Is the datafile's type associated to a program file with full path, or just
the file name?

R.Wieser

ungelesen,
09.07.2021, 09:34:3209.07.21
an
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

ungelesen,
10.07.2021, 01:42:2910.07.21
an
On Fri, 9 Jul 2021 15:34:15 +0200, R.Wieser wrote:
>
> 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

ungelesen,
10.07.2021, 05:08:1410.07.21
an
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


0 neue Nachrichten