"James Whitlow" <jwhitlow.60372693@xxxxxx> wrote in message
news:uBDZfgHCJHA.2476@xxxxxx
> "Tyler Durden" <abuse@xxxxxx> wrote in message
> news:OldexvGCJHA.1632@xxxxxx
>> James, just to make sure, the following is the complete script. Could it
>> be optimized/cleaned in any other way?
>>
>> Dim LaunchDir, FSO, WSHShell
>> Set WSHShell = WScript.CreateObject("WScript.Shell")
>> LaunchDir = WSHShell.CurrentDirectory
>>
>> WSHShell.Run """" & LaunchDir & "\vncviewer.exe"" -notoolbar -autoscaling
>> myhost.dyndns.org" >
> I personally think it looks good. Others in the group might have some
> helpful comments, though.
>
> The only things that I would do differently would be to add 'Option
> Explicit' as the first line to force variable declaration and use some
> form of Hungarian Notation to indicate what type your variables are
> (string, integer, object, etc.). I think most people prefer 3 letter
> abbreviations (ex: strLaunchDir, objWSHShell), I personally prefer 1
> letter abbreviations (ex: sLaunchDir, oWSHShell). Personally, I mistrust the current directory and prefer to explicitly use
the directory where the script is located, i.e.:
replace( WScript.ScriptFullName, WScript.ScriptName, "vncviewer.exe")
This will give the full path to a file called "vncviewer.exe" located in the
same directory as the script itself - even if the current directory has been
changed for some reason, or is pointing elsewhere in case your script is
being executed by another script and not by double-clicking in explorer.
Some will point out that the above replace reference will fail in the event
that the path includes a folder that is a superset of the name of the
script. A more bullet-proof method would use the GetParent method of the
file system object. As an aside, it is almost always better to use the
filename parsing capabilities of FSO instead of string concatenation and
sub-stringing methods to calculate file paths.
/Al