Use a .NET Framework Class to Open a File Dialog Box
Summary: Microsoft PFEs Adam Haynes and Shubert Somer talk about using a .NET Framework class to open a file dialog box.
Microsoft Scripting Guy, Ed Wilson, is here. Today, we have part 5 of 5 guest blogs written by Adam Haynes with help from his friend Shubert Somer. If you have not read parts 1, 2, 3, and 4, you will want to go back and read them before you read today’s blog post.
Take it away, Adam …
<SCRIPT >
[reflection.assembly]::loadwithpartialname(“System.Windows.Forms”) | Out-Null
$openFile = New-Object System.Windows.Forms.OpenFileDialog
$openFile.Filter = “txt files (*.txt)|*.txt|All files (*.*)|*.*”
If($openFile.ShowDialog() -eq “OK”
{get-content $openFile.FileName}
</SCRIPT >
I think Shubert covered line 1, so let’s move on with the rest of the script.
On line 3, we have to use the New-Object cmdlet because, as we discussed in a previous post, we have to instantiate the OpenFileDialog Class. If you need to refresh on constructors, see Shubert’s explanation in the part 2 post.
Line 4 is actually copied from the MSDN site. I stumbled across the Filter property when I was browsing the object and used the example provided on MSDN.
Line 6 took me a couple of tries since I was not familiar with the object (remember, it is an object because we used the New-Object cmdlet). Once I had the OpenFileDialog object, I just started trying the methods that are listed on MSDN (and Get-Member) to see what they did. The Show Dialog() Method looked promising and, in fact, provided all the information I needed to finish the snippet.
ShowDialog() returns a DialogResult Enumeration of either an OK or Cancel. Remember we talked about enumerations in part 3? Now, how do I know that an enumeration is returned? Because MSDN says so. An unexpected side effect of this dialog is that you can’t click OK in the dialog window until you select a file to open, so you get an input validation bonus. Once the file is selected and the user clicks Open, we simply pass the path to the Get-Content cmdlet on line 8 and resume your regularly scheduled Windows PowerShell script. There is no sense in re-inventing the wheel by using .NET Framework to read the file when we already have a cmdlet for that.
One other thing to note about line 6 is that we could swap out [System.Windows.Forms.DialogResult]::OK for OK, and Windows PowerShell would understand what is meant; however, we would miss out on the opportunity to rehash the enumeration topic, and this guarantees that we get what we asked for. You know what happens when you assume?
I hope all of these pieces come together for you, and you start poking around MSDN a little and try out some things that you learned here. The beauty of digging into .NET Framework with Windows PowerShell is that you don’t have to know how to “code” or learn how to use Visual Studio. Let’s call Windows PowerShell a gateway language. There is much more to learn, and as Shubert mentioned in a previous post, there are many ways to do the same thing. So, the way that meets your requirements is the right way.
We encourage you to take the concepts we discussed in this blog series and have a peak at the .NET Framework Class Library. To start, pick a namespace that you are familiar with. I know Active Directory, so that is where I started. If you are more familiar with Exchange or SharePoint, start there. Pick anything you can think of regardless of whether it is immediately useful, and make it work. Start simple, and then dig into all of the methods and properties of your new object.
Talking PowerShell, anyone? I use this in meetings when I get bored.
<SCRIPT >
[reflection.assembly]::loadwithpartialname(“System.Speech”) | Out-Null
$SayIt = New-Object system.Speech.Synthesis.SpeechSynthesizer
$SayIt.Speak(“.Net and PowerShell are cooler than cool”)
</SCRIPT >
Explain this snippet to yourself based on what we have talked about, and then open up the intertubes and look at MSDN to see how you can change the voice, gender, or age. The point is to just do something that doesn’t matter and have fun with it. When you need to use this on the job, you will be ready and confident to show off your new skills and added value for your boss. Tell them that Microsoft Premier sent you.
~Adam
Thank you, Adam and Shubert. This has been a great series. Awesome job.
Join me tomorrow when Microsoft PowerShell MVP and Honorary Scripting Guy Richard Siddaway brings us part 5 of his Windows PowerShell workflow basics series. It will be a real treat.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments