In fact, sometimes your script is intended for users who might not even know how to run a script from the command line! Wouldn’t it be great if you could just have windows display a dialog box to prompt the user for a file to chose as a argument for your script?

Well, you CAN! The following script is a sample of what you can do with the Windows Common Dialog box to enable the user to more easily utilize your scripts– all without knowing about the command line!

There are a few key pieces of the script I want to call out before we dig in and start running the code though. First, the object that preforms the magic here is UserAccounts.CommonDialog, the filter options on the dialog in the drop down to select the file types to display in the browser dialog is the line with .Filter property in it, The initial Directory the dialog uses is specified in the .InitialDirectory Property, and finally the default selection of that drop down is specified in the .FilterIndex Property. Take a look at the code and see how easy it is.

 Option Explicit
Dim ObjFSO, InitFSO

‘ create an instance of the File Browser
Set ObjFSO = CreateObject(“UserAccounts.CommonDialog”)

‘setup the File Browser specifics
ObjFSO.Filter = “VBScripts|*.vbs|Text Files|*.txt|All Files|*.*”
ObjFSO.FilterIndex = 3
ObjFSO.InitialDir = “c:\”

‘ show the file browser and return the selection (or lack of) to InitFSO
InitFSO = ObjFSO.ShowOpen

If InitFSO = False Then
    Wscript.Echo “Script Error: Please select a file!”
    Wscript.Quit
Else
    WScript.Echo “You selected the file: ” & ObjFSO.FileName
End If

Enjoy!

The first time I wrote such a beast I changed the script several times until I had a couple copies doing the same task on different directories. I then tried to create a script that ran against all the directories, but that too became a pain when I wanted to run it as a one off or run it on a different schedule.

 Then I figured out how to add command line arguments to my scripts! What a powerful and time saving piece of information that was to figure out!

 Command line arguments in VBScript are really very simple, once you have the concepts down and know what object to use. Which, of course, is the Wscripts.Arguments object! With this object you can pass any number of arguments and parse them in your script or add them into a variable– or anything you want, the sky’s the limit!

Enough rambling on though, lets get to the code that will save you a ton of time!

args = WScript.Arguments.Count

If args < 1 then
  WScript.Echo “usage: args.vbs argument [argument] [argument] [argument] ”
  WScript.Quit
end If

WScript.Echo “You entered ” & args & ” Arguments, the first was “_
 & chr(34) & WScript.Arguments.Item(0) & Chr(34)

As always, this code works perfectly. However, sometimes the formatting of the blog breaks the code if you copy and paste it into your editor. So, if you’d like to not type or troubleshoot any syntax errors due to the copy and paste problems– I’ve provided the code for download, plus example output files  from my final tests for you. You’ll find the code and other files available for download from my website’s (www.websystemsadministration.com) File Depot under the ITKE Blog Scripts category. Enjoy and happy scripting!

5. Always try to use option explicit in your code, especially if the script is longer than 100 lines.

Trust me on this one, using option explicit may force you to think a little bit about declaring a variable before you use it and it may be a pain having a silly error about a undeclared variable when you test your code, but it’s a heck of a lot better than trying to find two places where you’ve spelled a variable two different ways in your code– and creating a hard to find bug because of the different spellings.

4. Learn when to use on error resume next and when to just let the script die.

Sometimes you just can’t cover all the possible errors in your code (though you should try) and turning off error checking is an absolute must. When you do do this, be sure and turn error checking back on after you have passed over the area of your code that could cause a problem (with– on error goto 0)

3.  Conditional statements are invaluable, just know what tool is right for the job.

Branching your script because a variable has a specific value, is greater than, or less than something else can be invaluable. Often it is the key to clearer to follow code and getting your script up and running quickly. Knowing which conditional statement (If-then-else, for-next, do-loop,  select-case, etc) to use is an invaluable tool to have in your tool belt as a systems administrator.

2. If you do it over and over, then you should script it.

This is my motto! You’ve seen it several times… BE LAZY! There is absolutely no sense in doing something that is repeatable by hand day in and day out. Your time could be better spent spending a few seconds looking at a output from a script to make sure it went well when it ran as a scheduled task. Thus freeing you up to do more (or less) of what you need to accomplish during the day.

1. Everything has been done before, it just may take a little effort on your part to cobble it together.

Almost everything has been done before in a script or other program… it just may not be exactly what you need to get the job done. After searching for a while for a script that does exactly what you want and not finding it— look for several scripts that do pieces of what you need done and put them together into one script that is exactly what you need! Above all else use Google for what it does best, search the web for examples. Additionally, as you find sites that are helpful book mark them for later reference. My blog roll to the right is a good place to start as well, I use these sites myself.

So let’s dive in with Number 10!

10. String Manipulation is your friend.

There’s a reason people are still writing scripts in PERL. It is very useful in manipulating strings– and sometimes you need to manipulate and use strings to get done what you need to get done. Built in String manipulation functions like Replace(), Instr(), Mid(), Ucase(), and Lcase() are invaluable, so commit their syntax to memory or use a script editor with intellisense that will help you with the syntax as you type.

9. Learning to create functions and subroutines will make your life easier.

The key to generating a script quickly is to use the code you’ve already worked hard on creating previously. Most of my scripts that I post here are smaller for a single purpose but, they are still useful if you take the heart of the script and wrap it in a function! You will find, over time, you’ll end up digging through your script repository to copy and paste pieces of code into another script. (I do.) Plus, it will save you time! Be Lazy! Don’t re-invent the wheel every time you sit down in front of the keyboard! 

8. Key scripting objects were created for a reason– so you don’t have to create them yourself.

This is a continuation of the same concept. Don’t re-invent the wheel. There are already objects for specific functions, string manipulation for example– so don’t reinvent the replace() statement unless you have a really good reason to do so. If you need a little different functionality try to at least wrap it in a function.

7. Recursion in your code can be your best friend– or your worst enemy.

Recursion is where a section of code (generally a function) calls itself. This is invaluable! It saves a ton of lines of code because sometimes you do need to use the functionality of a function inside itself. (file and directory manipulations for example) However, be aware that recursion is dangerous because it poses the potential to create an infinite loop (which would be very bad if you were deleting files) and also can be somewhat hard to troubleshoot.

6. You will eventually need to debug that script, so comment your code and use Wscript.Echo to write to the screen what you are doing.

It’s inevitable, at some point a situation is going to arise that you didn’t think of 3 years ago when you wrote the script and your going to have to figure out why that script you wrote (and forgot about) has been dying for 6 months.

Comments are helpful in documenting how and why a script is doing something in a particular manner. I can’t tell you how many times I’ve went to the effort to rewrite a section of code to find out my thought wasn’t going to work because of something I figured out previously and didn’t document or didn’t because the code didn’t make sense.

Another useful tip is to use Wscript.Echo to output the key information the script is using, a variable in a For Next loop for example, or a string being passed into a function and the output of the function. You can always either comment them out when you’re done — or use a variable to hold a “debug state” and wrap the Wscript.Echo in a if statement, like so:

‘This is the debug “flag”, set it to 0 to turn off debugging output
Debug =1

‘… lots of code omitted

If debug = 1 then
     Wscript.Echo “We’re cooking with Gas now!”
End if

That’s enough for now, you’ll at least have something to consider. There’s more in the next Blog posting, so continue on over there!