I struggle with $myvar.foo vs. ($myvar).foo vs. ($myvar).foo() vs. $myvar.foo(); vs. $myvar.foo(1), etc., etc.

How do I know which one to use for which case? And then how to put this output into a write-output statement?

There are basically three ways of using parenthesis in PowerShell: grouping, method calls, and sub-expressions. Hopefully the explanations and examples below will help. Feel free to ask questions in the comments if I’ve missed something.

Grouping

The simplest use of parenthesis is similar to the mathematics use of grouping constructs. In fact, in it’s simplest form, it’s exactly the same as what you learned in math, and we use it to group calculations to determine the order of operations:

But in PowerShell, it can also group calls to cmdlets and functions, and can allow you to invoke methods and properties on the output of those cmdlets. This allows you to use operators or call methods on the output of cmdlets without first storing them in variables. You can add and subtract dates:

When doing a registry lookup, you can avoid getting all of the PS* properties, you can call a single property, for instance, to get the path to PowerShell.exe:

You can cast the output of a command to another type. So for instance, if you wanted to pick 10 random letters, you might use the fact that 65..90 are the ASCII values for A..Z, and then cast them to the char type:

Method calls.

All objects have methods. In order to invoke a method, you have to use parenthesis to “call: it. So for instance, strings have a bunch of different methods, which you can see with this command:

For instance to convert a string to all upper case, you call the ToUpper method:

Note that when you type the name of a method without the parenthesis, you don’t invoke it: "hi".ToUpper Instead, PowerShell does reflection on the method and gives you information about how to call it, what the overloads are, etc. You can see much of the same information in the output of Get-Member. When you have a method that takes parameters, you need to pass the parameters inside the parenthesis, separating them with commas if there’s more than one:

Sub-Expressions

PowerShell also has another way to use parenthesis: with a leading $ (dollar sign), they become a sub-expression, which is calculated before the containing expression … so for instance, you will notice that the Write-Host inside the sub expression will output first:

Of course, you can’t put two command pipelines (separated by the semicolon “;”) into a simple parenthesis, but you can in a sub-expression!

The style I use has a nice black background...

A while back Thell Fowler (with a little help, and a lot of testing from me) wrote a very good PowerShell Lexer for Notepad++ 5.2 and later… it’s very thorough, has good code-folding, and full support for PowerShell 2.0 syntax highlighting.

I mention this because Notepad++ 5.6 just released yesterday, and it has built-in support for PowerShell syntax courtesy of Scintilla ... but it’s very, very bad. The scintilla PowerShell lexer is probably the most minimal PowerShell lexer I’ve seen (it’s worse than the old “user style” I had created for Notepad++) and has no support for:

• The ` escape character
• Here-strings (which can contain quotes, etc)
• The difference between strings and literal strings and literal here-strings
• The begin/process/end block keywords and Param()
• PowerShell operators (like -is or -gt or -notcontains)
• [System.Namespace.Class]::Method() syntaxes
• Nested $variables inside strings
• Nested $( code blocks ) inside strings (with strings inside those, and …)
• Any of the new PowerShell 2 syntax like:
  • multi-line comments
  • [Parameter()] and [Alias()] and [Validate …. ]

• [CmdletBinding()]

There’s probably more, but I couldn’t be bothered to spend more than a couple of minutes with it. As you can probably guess … all of those features are supported by the external PowerShell Lexer plugin that Thell wrote, so if you’re a PowerShell and Notepad++ user, I apologize for not drawing your attention to our PowerShell Lexer for Notepad++ before .

Incidentally, I stuck a screenshot in this post so you can see how I use it, but there’s one a more complete example of the PowerShell Syntax Highlighting on that lexer download page.

I’m still thinking about the best way for me to expose this in PowerBoots, because the problem is that attached properties can get attached several ways, and not just on direct children of an element. So I wanted to show you a way that you can do it for now so you can at least use the DockPanel effectively:

A better way …

Here’s what I’m thinking about for the next release of PowerBoots (you can take this and use it now, if you like it, but I’m really looking for, uhm … better ideas). Basically, I have written a function: Set-AttachedProperty, which takes an attached property and a value, and passes through the element on the pipeline. You may want to use this in conjunction with the module I published awhile back for creating type accelerators, because it lets you run a line like this:

Which will let you substitute [DockPanel] for [System.Windows.Controls.DockPanel] … and of course, you can use it for all the types you want to use attached properties from, and it’s a real lifesaver if you need to use a bunch of them. Of course, in this particular example, we really only need to use a single attached property, so it’s enough to define that property ahead of time:

Then you can use the Set-AttachedProperty function through an alias sap, and rewrite that huge block above like this:

Pretty slick, right? And it will even print out the list of values in the error message if you invoke it with an invalid value against an enum property like dock: sap $DockProperty "" … The problem I have with it is that you have to predefine your $DockProperty variable, and you can’t just define it against the root class. So I’m trying to find a way to tweak the dynamic property generation to make it so that the pipe into | sap $DockProperty Bottom can just be a parameter to the original element: -Dock Bottom … if I can’t find that, in the worst case scenario, I’ll just add an -AttachedProperties parameter with a hashtable of $DockProperty,“Bottom” or something … what do you think?

In any case, here’s the sap function, for now, and remember to use it as part of the pipeline: