Robert,
If you keep using Shell commands to perform functions that Kix can do, you might as well simply write a batch file.
Before you write another line of code, write yourself a list of available Kix functions that you can reference. You don't need to list them all, but scan them all and make note of the ones you think might be useful. I have mine as the front page of my hardcopy Kix manual.
The entire list of KORG UDFs can be viewed here and then there is my complete development UDF library on my web site.
Study the lists and learn what is available to you. Download and include them in your code - you'd be surprised how much faster the WSHPing is, or how flexible WMI queries can be.
As you compile a library of UDFs, consider looking at KGen, which allows you to reference UDFs in your core script. It will then resolve and include all dependencies to create a finished script.
Couple of other points -
- Using "cmd.exe" is bad form - use "%COMSPEC%", which is more portable and will always point to the correct interpreter.
- Don't use double-quotes in Kix, especially in Shell or Run commands. The interpreter usually requires double quotes, so using single quotes within Kix allows you to easily embed double quotes in the command string when needed. (but watch out for message strings with contractions, like "can't"!)
- It's "ping.exe" - get in the habit of qualifying your commands. This eliminates any confusion between batch files, executables, and other scripts.
You might get other advice, as some of this is programming style, but PICK ONE STYLE and stick to it. You have problems because your code is "all over the place". Define your objectives by commenting your code. Plan the execution and logic by commenting your code. THEN, insert the code based on the comments. Your code will be smoother and less problematic.
Glenn
_________________________
Actually I
am a Rocket Scientist!
