A co-worker of mine posed the question of how to get the same type of pop-up that you get when you are using a simple wscript.echo in VBS. Since I am always telling him that PowerShell is typically easier than VBS to do something I was a bit annoyed, because he found one case where VB is easier.
Searching online you find that most people try to create a new object that is a VBS session and then pass the wscript.echo command over there. I don’t like that solution because it’s a bit kludgy. Instead I figured that there was a .NET object that you could use to do this, and indeed there is.
Here is a link to the MSDN Article for System.Windows.Forms.MessageBox:
System.Windows.Forms.Messagebox
Alright, so we know that there is a .NET class, so we can just make a new object, right? Well, normally yes. But there is a bit of an annoying statement on that site, “You cannot create a new instance of the MessageBox class.” So that means that I have to call the methods with a static call. Here’s the basic gist
[System.Windows.Forms.MessageBox]::Show("Hello, World.")
So that is the addition of the assembly to our current shell session and then calling it via a static method. As you can see it gives a really ugly window. We can add to that, though by overloading the show method with more stuff. Specifically, let’s fill out the title, the type of buttons we’ll use and the icon it will show.
Alright, so how did I know what text to type to make those buttons and icon appear? What others are available to me? Well you can refer to Microsoft’s site to find out:
Message Box Buttons
Message Box Icons
So, you can see that this can be fairly powerful, but not quite as “easy” as in VBS. Now, if you care about the input that the user gives, it’s really easy to get. All you need to do is grab the output.
#Imaginary click of the "Retry button"
$Testing
>> Retry
So you can see that we can work with the output now in other ways, but what if we want something really detailed, like we could get in VBS with the Inputbox command. Well, that’s a giant pain. I played with this for a while, but since there is no equivalent .NET object, it’s not very easy. Basically, you have to create a blank form then add all your objects to it. Set what all the buttons do and then set what happens when the form closes. I found a good tutorial written by Microsoft, so I won’t re-invent the egg:
Creating a Custom Input Box
From the VBScript to PowerShell guide:
$a = new-object -comobject wscript.shell
$b = $a.popup(“This is a test”,0,”Test Message Box”,1)
Worked for me, thanks!
Good feedback: however during script development, many developers use simple echo statments to verify vairables are carrying throughout subroutines etc..
wscript.echo ”variable”, which does not require any global variables or set parameters, is a very easy way to assist in the development of a script. PS must of have a native echo without having to use windows.forms or going back to wscript.shell? Which it does:
write-host ”variable”
It would of been nice if Powershell Contruct natively ran (write-host) in either windows.form or wscript.shell interface style, outside the ISE or any other IDE tool, opposed to DOS based interface when running outside of an IDE. But O”well small change to get used to.
=)
I can agree and disagree. I do think that it would be nice to very easily replicate any features that were provided in older solutions, in this case being VBS. That is because if you are trying to convert older scripts to the newer Powershell scripting engine, then you probably aren”t in the mood to re-think any conquered problems. On the other hand, this is a shell first and foremost, and when you get into the habit of calling items that run outside of the shell you infact lose a large portion of the power and functionality associated with it. I”ve been working with Powershell since it was in beta, and last week was the first time I had ever considered trying to make a pop-up window. It really isn”t needed but in perhaps a few very specific situations.
As far as ways to got output from a script natively, well I think it blows VBS out of the water. You can output to the console, or a printer, or a gridview, to a CSV, or XML. You can write to files, or the event log. You create you own errors or warnings, and you can even create your own progress bas. All of that with only one line of code each. As far as output I don”t think VBS is even in the running against Powershell.
I wouldn’t consider VBS as a candidate for running against PS at all, that is a moot point. When working within different Scripting environments you require the flexibility of not only relearning concurred problems, but also having to relearn the way to solve a problem. Scripting is just a very fundamental way of learning this lesson. Power Shell is easier to learn, easier to follow, and for lack of better words: simpler in all forms. This achieves two things; Many more people will have a skill set of scripting, with even fundamental knowledge, thus making scripting a less hard to find skill in a Microsoft environment. One encouraging note to any heavy VBS writer: once over the basic hurdles, you will find Power Shell far more easier to use, more powerful, and less time having to think your way through a script. In all ways it has been dummied down while reaping far more benefits with its power.