I found this here -> http://technet.microsoft.com/en-us/library/ff730941.aspx
I’m using Windows7 64bit
Admin Windows PowerShell ISE Host 3.0
I can’t get $x to store a value I’ve tried
F:\jtbdocs\sCRIPTS\testout\input.txt
1
billy
the $x at the bottom doesn’t output
also is there a line by line debugger for Power Shell like VbsEdit did for VB
There is a debugger; read the help for the *-PSBreakpoint commands. You can also use Write-Debug.
I believe your problem is in how your’e capturing $x. The way you’re doing so isn’t standard WinForms programming. Typically, you would create an “OK” button, as you’ve done. You would set that OK button object ($OKButton) to the AcceptButton property of $objForm. That way, when the user presses Enter, the OK button’s Click event gets called automatically. That’s different from what you’re doing, which is trying to manually intercept the Enter button. Similarly, the form has a CancelButton that you’d set to your $CancelButton object to handle Escape.
You then create an event handler for the OK button’s Click event. In it, you set $x equal to $objTextBox.text (BTW, PowerShell scripters don’t tend to use the “obj” Hungarian notation anymore; that was kind of a VBS thing).
What you’re doing now will not work if the user clicks the OK button, rather than pressing Enter.
Further, your current script is mixing event-driven code (which is what WinForms uses) with procedural code. When your script executes, it ALL executes (except event handlers). So your “$x” on the last line is executing well before $x has been populated. Additionally, $x will never be valid outside of your script, due to the way PowerShell scope (help about_scope). If you wanted to output the content of $x, you would do so immediately before closing the form, in an event handler. Also, as-is, $x is being set INSIDE an event handler. $x will not have validity outside that event handler. So again, you would need to OUTPUT it inside the event handler. Folks typically do that by writing functions, which are PowerShell’s formal way of passing data between scopes.
Event-driven programming is massively different than procedural programming, and it will require a pretty strong understanding of how Windows Forms works - which is a complex topic. A lot of folks will use a tool like PowerShell Studio to simplify the process a bit, but it’s still a very different programming environment than just writing a straight-line script.
Although your’e using PowerShell as a language, what you’re tackling is very much software development, and not scripting. It’s just as complex a topic as doing this same thing in VB.NET or C#. The fact that you’re using PowerShell as a language doesn’t actually remove any of the complexity - and in a way, because you’re not able to use a strong tool like Visual Studio, PowerShell can make this task MORE complex, not less.
Wow ‘THE’ Don Jones? I requested and got your books for Christmas “Learn Windows PowerShell 3 in a Month of Lunches” and “Learn PowerShell Toolmaking in a Month of Lunches”. Thank you for the quick response…
So is there a best practice to create a Gui input box to set a string variable or is it just too complex?
Maybe TechNet should remove this code from tip of the week?
Well, PowerShell isn’t really “GUI,” right? It’s kind of all about the command-line. But it depends a lot on the situation. There’s no harm in using Read-Host. Using the Visual Basic InputBox is straightforward, too. Probably a lot easier than building your own.
Just keep in mind that minute you commit to a GUI means of collecting input, that script CAN ONLY EVER BE USED BY HUMANS. No scheduling. No combining with other scripts. So it’s a bit limiting.
Those TechNet WinForms samples all seem to have the same problem. Here’s another thread from a month or so ago on the same topic (though it was using the List Box example rather than Input Box.) You can see an example of the code changes Don mentioned:
https://powershell.org/forums/topic/selecting-items-from-a-list-box/
Thank you Dave, That was a huge help :-)…May I suggest a scripting war with the TechNet guys >;-)
On a side note, I’ve recently been told that these sample scripts worked fine in PowerShell 2.0, which was probably current when they were posted.
Thanks man…wait so PowerShell scripts aren’t backwards compatible? Hmmm and PowerShell 4 is out…scary