The Windows Scripting Host Remember batch files? They were simple, easy to program, and very productive since many tasks could be automated. Windows still allows batch files, but batch files don't allow any control over the Windows shell and Windows environment. By introducing the Windows Scripting Host, Microsoft has introduced a script and COM based engine that can access the Windows Shell, the computer's environment and network settings using simple VBScript or JScript code. In addition you can even access any COM component, including your own. This column will introduce you to the basics of how the scripting host works and how you can incorporate its features into your Visual FoxPro Applications. What you need to get started The Windows Scripting Host ships with Windows 2000 and Windows 98, and is also available as part of the NT Option Pack when installed on Windows NT 4.0. Older Windows NT and 95 can download the Windows Scripting Host files from the Microsoft Website at: http://msdn.microsoft.com/scripting/. In addition to the core scripting engine, a series of whitepapers, code samples, and technical articles can be downloaded as well. What is the Windows Scripting Host (WSH)? The Windows Scripting Host is a language independent scripting engine. Scripting languages such as VBScript and JScript can be used to drive many processes. The same language that is used in client-side scripts in Internet Explorer (IE) or server-side scripts in Internet Information Server (IIS) can now be hosted by the Windows Operating System itself. Prior to the release of the WSH, the only scripting language that existed for Windows was MS-DOS batch files. Although powerful, batch files lacked the control over the Windows Operating System that is truly required. The WSH provides this capability. Scripting Files Unlike scripting in Active Server Pages, where the language can be specified with tags, the same is not true for script files used by the Windows Scripting Host. Instead, the WSH relies on the file extension to determine which language to use. If the script file ends in VBS, VBScript is used. If the script file ends in JS, JScript is used. The following files are simple hello world examples the point out the differences between VBScript and JScript: VBSscript:
'hello world.vbs
Dim WSHShell
Set WSHShell = WScript.CreateObject("WScript.Shell")
WSHShell.Popup "Hello World"
JScript:
// hello world.js
var WSHShell = WScript.CreateObject("WScript.Shell");
WSHShell.Popup("Hello World")
The following is a more complex example that uses scripting to open and control Microsoft Excel: 'This VBScript File opens Excel and creates a workbook
Dim objXL,oWorkbook
Set objXL = WScript.CreateObject("Excel.Application")
objXL.Visible = TRUE
Set oWorkbook = objXL.WorkBooks.Add
With objXL
.Cells(1,1) = oWorkbook.Sheets.Count
End With
Running these script files is a very simple task. In Explorer, you can click the right mouse key over the file, and select Open. Alternatively, you can double-click the item in Explorer as well. Yet another alternative is to use the Run Method of the Windows Scripting Shell Object. This technique will be illustrated when the Shell Object is discussed in more detail. Furthermore, you can execute these script files directly from your applications using the ShellExecute() API simply by specifying the filename. A quick word about debugging and handling errors No programming environment is complete with a full-featured debugging environment and the Windows Scripting Host is no exception. As far as error handling is concerned, VBScript does not have a global error handler. Instead, errors need to be handled on an in-line basis. The following code demonstrates how to deal with errors on an in-line basis: On Error Resume Next
dim objxl
Set objXL = WScript.CreateObject("Excel.Application")
objxl.foo ' reference a non-existent Excel Method
If Err.Number > 0 Then
Call ErrorProc
End If
Sub ErrorProc
msgbox err.description
End Sub
If no error trapping exists, you will be prompted with a dialog asking if you wish to debug the application. Figure 1 illustrates how the code will appear in the script debugger. 
Figure 1 - The Microsoft Script Debugger uses the same IDE as Visual InterDev and Visual J++ 6.0 | & | | 
By: John V. Petersen John Petersen has been developing software for over 20 years. It all started when, as a staff accountant, he was asked to get involved in a system upgrade to replace an old IBM Series 1 computer (about the size of a large refrigerator!). Those first programs were written in Clipper, Summer 87. Since that time, John’s tools included dBase, FoxBase, Visual FoxPro and Visual Basic. An early adopter of .NET, he then decided to go to law school. After practicing law for a few years, John realized that technology was a lot more interesting than the law. Today, John focuses on ASP.NET development and is having more fun than ever solving business problems for clients. John is a Practice Director for Custom Application Development at Neudesic, a Microsoft Gold Partner and the Trusted Technology Partner in Business Innovation. A 9-time recipient of Microsoft’s Most Valuable Professional Award, John is a current ASP.NET/IIS MVP. John is also an ASP Insider and is the INETA Mentor for PA and WV. John is the author of several books and is a frequent contributor to CODE Magazine and DevPro magazine. John holds a BS in Business Administration from Mansfield University, an MBA in Information Systems from St. Joseph’s University and a JD from the Rutgers School of Law – Camden.
email: johnvpetersen@gmail.com
blog: codebetter.com/johnvpetersen
twitter: @johnvpetersen
john.v.petersen@comcast.net |