There's a component of the formatting system that doesn't
really get talked about much, well, at least not in my experience.
I want you to be across it because you might find it useful.
Let's check out formatting views.
Each of the format cmdlets in PowerShell have a parameter named view.
This can be used to define different formatting views other than the
default one if there are any views defined in the formatting files. If
there are no alternate views defined, well,
this parameter isn't going to do much for you.
Let's take a quick look at the format data again with
Get‑FormatData. For the TypeName,
I'll paste the value for System.Diagnostics.Process that's
still on my clipboard from a previous clip,
and I'll drop in the PowerShell version as 5.1. Check out this
property here named FormatViewDefinition,
and you can see there are four entries in total here.
We've got process. Priority, StartTime, and process again.
This means there are different views for the process object type that we could
leverage when formatting the process data in PowerShell.
I'm going to press the up arrow to get that command back, and then put a
closing bracket, followed by pressing the home key to go to the start of
the command, and I'm going to put an opening bracket there. And I'll press
end on my keyboard again to get back to the end of the command, and then
put .FormatViewDefinition.
So we can look a bit deeper at that specific property.
By doing this,
we get a bit more information on those four views that are defined.
We can now see that process, Priority, and StartTime are all table‑based
views and that the second process view is a wide‑based view.
I've still got this information stored in the XML file from the previous clip.
So again, let's run notepad and specify the path to the process.xml file.
And I'll expand that to use the screen real estate here. And
in there, if you look towards the top,
we start by defining a Configuration and ViewDefinitions,
and then a new view is defined.
This one is the default view named process.
If I scroll down a little,
that first view gets closed, and look at this, another view
gets defined, and this one is called Priority.
This view is for the same type of data, and it's also based on a table.
But notice here that it's actually doing some grouping
based on the PriorityClass property.
And lastly, if we scroll down a little bit more,
there's a third view defined here named StartTime.
And this one is doing some grouping based on the date,
and it's also using a ScriptBlock to calculate that property.
Let's jump back into the PowerShell console, and I'll show these
to you. If I run Get‑Process and pipe that down to Format‑Table
and then specify the view parameter, one of those alternate
views was called StartTime, so let's give that a go.
What you see here in the output, if I scroll up,
is a custom view that is grouping the results based
on the start time of the process.
So instead of us having to do the grouping manually,
this PowerShell view will do it for us.
One interesting thing to note here is that there are some duplicate tables,
and that's because this data is getting grouped,
but it hasn't been sorted first. So really,
we should do a Get‑Process, pass that to sort based on the
StartTime, and then send it down to Format‑Table and specify
the alternate view of StartTime.
And now that looks a little bit better.
If you don't want to dig around in the format data to figure out
what views are available for each object type,
there's a handy little trick that I remember from a few years ago,
and I can't remember where I saw it, but if you run a
command and pipe it to format command,
you can do specify the view parameter and then just put in an incorrect name,
so I'll just put a as the view name.
The PowerShell error message here tells us that the view can't be found,
but it then actually goes and tells us what views are
available for this object type.
So that's a quick tip if you want to find the
formatting views for an object type, but you don't want to dig around in the format data.