One of the fun things about being the Microsoft Scripting Guy is the ability to read all of the e-mail that gets sent to the Scripter@Microsoft.Com e-mail address. Each week, I attempt to answer the several hundred e-mails that I get, at times with varying success. One common form of e-mail I get goes something like this: I need a WMI script to swap the mouse buttons on 100 computers at work … or words to that effect. The easy answer to that particular question is, it cannot be done. You can detect if you have a right handed mouse, or a left handed mouse, but the handedness property is read-only on the Win32_PointingDevice WMI class.

The long answer to the question of the mouse, is that while you cannot use WMI to solve the problem, you can write a script that uses P-Invoke and some of the new features of Windows PowerShell 2.0. The SwapMouseFunction.ps1 script illustrates this technique.

# ------------------------------------------------------------------------
# NAME: SwapMouseFunction.ps1
# AUTHOR: ed wilson, Microsoft
# DATE: 2/13/2009
#
# KEYWORDS: Add-Type, user32.dll, mouse, pinvoke
#
# COMMENTS: This script uses Add-Type to create a
# function from user32.dll that allows you to swap the
# mouse button.
#
#
# ------------------------------------------------------------------------
#Requires -Version 2.0
Function Add-User32Mouse
{
$signature = @"
[DllImport("user32.dll")]
public static extern bool SwapMouseButton(bool fSwap);
"@

Add-Type -memberDefinition $signature -name "Win32SwapMouseButton" -namespace  Win32Functions -passThru
} #End Add-User32Mouse

# *** EntryPoint to script ***
#$SwapMouse = Add-User32Mouse
#[void]$SwapMouse::SwapMouseButton($False)
[void](Add-User32Mouse)::SwapMouseButton($False)

You see, the thing is, the person who sent the e-mail asking for a WMI script to change the mouse buttons assumed that because they used WMI to detect the primary and secondary mouse buttons, that they should also use WMI to change the mouse buttons. Such an assumption when working with scripting leads to tunnel vision, and convoluted scripts at best, and to misleading and inconsistent results at worst. Rather than assume what technology you will use to solve the problem in a script, it is best to clearly define the problem, and then choose the best approach from the available technology to solve your problem.

Contrary to building buildings, in programming the form dictates which function you will use and not vice versa. Now we have both the long answer, and the short answer to the problem of the mouse.

One of the things that I often discuss with people who write VBScript code is the process of translating VBScript code to Windows PowerShell code. In fact, several years ago, I was approached about writing a utility that would automate the process. I thought about it long and hard, and in the end decided to forgo developing such a tool.

In my Windows PowerShell Step by Step book, that was published by Microsoft Press, I have an appendix that is called the VBScript to Windows PowerShell conversion guide (there is a similar document on the TechNet Script Center). The conversion guide is useful from a getting started perspective, but should not be taken as best practice, or even as authoritative.

I even wrote a series of Hey Scripting Guy! articles that talk about converting VBScript to Windows PowerShell (one such example is here).  But in all actuality, I have translated less than 1% of the more than 10,000 VBScripts I have written in my lifetime.

There are several reasons for not translating VBScript to Windows PowerShell:

1. Waste of time. If the VBScript works, leave it alone.
2. Better way of doing things. Many VBScripts wrestled with things such as opening files, retrieving property values of objects and writing output to the console. These types of tasks are nearly automatic in Windows PowerShell.
3. There are too many new things to script using Windows PowerShell. Many things that were impossible to do using VBScript are now possible using Windows PowerShell. There is a seemingly endless list of new things to script. I simply do not have time to go back and translate VBScript code.

Reasons to translate VBScript  to Windows PowerShell:

1. You are just learning how to script, and would like to have an example to follow along with.
2. You have a rather complicated COM based script, such as Word or Excel automation, that will not be significantly different when written in Windows PowerShell.
3. You are in the process of phasing out VBScript from your network, and you need to quickly migrate your existing scripts.

Probably the biggest reason not to translate from VBScript to Windows PowerShell is because you will want to take advantage of the new features that Windows PowerShell offers. Often the difference between a 50 line VBScript and a Windows PowerShell script can be as many as 49 lines of code. You can save yourself an awful lot of work once you learn how to allow Windows PowerShell to do the work for you.

Yesterday was labor day in the United States, and many people had the day off (including yours truly). I spent the day in my wood working shop practicing making hand cut dovetails. Because Americans do have the amount of time off from work as people in Europe do, we tend to prepare for our days off so as to maximize our time. Before my time in the wood shop, I had read a book on how to make hand cut dovetails and felt I had already mastered the technique. I even took 12 pages of notes on the technique.

I would love to be able to report that the dovetails came out looking like … well dovetails. Instead I succeeded in turning several nice looking boards into nothing more than firewood. Fortunately, I have a class scheduled in a few weeks where I will finally be able to master this hallmark of woodworking craftsmanship. But I was hoping to get a jump start on the process.

When a technique is particularly complicated, and has a huge number of dependencies, the ability of a book to effectively teach the skill is hampered. A skill such as making hand cut dovetails is made up of a number of component skills or sub skills. Each of the sub skills must be mastered before attempting the larger skill.

The only way to develop a new skill is to practice it. But practicing doing something wrong does not help one to learn the new skill. There must be checkpoints, or guidelines that help one to know if the skill is being practiced correctly. With each of the component skills there should be a practice session, or step by step exercises. Some multimedia content might also be helpful.

I am not saying that it is impossible to learn how to create hand cut dovetails from a book, but that the process of creating such a book is extremely difficult, and requires much more than a few fuzzy black and white pictures to successfully impart the skills.