Tag: XAML Spy

This is the third (and supposed last) article on how to hack the GridView (ListView) of the WPF.

To tell the truth, this post was yes planned, but just for explaining a subtle issue still present in the past release. However, after playing a while with that source, I noticed that another severe issue: a potential memory-leak when the column manager is not disposed together with the (Grid)view.
That caused a dramatic changing of the code, but luckily it comes in a simpler way that the previous one.

The subtle issue.

Let’s have a peek at the known issue, firstly.
It’s about the columns’ header, which allows the resizing of the width by dragging the buttons separator. That’s quite normal, but the issue came out when I tried to resize the latest visible column, whereas the next was hidden. In the following video the issue is very clear:

So, why that happens, and how to solve it?
I had a little effort on inspecting the problem, because the logical tree exposes the GridViewColumn instances, but the visual tree is rather different. Moreover, the embedded WPF visualizer in the Visual Studio (even the Ultimate version) is pretty limited and does not offer enough help in such a situation.
Finally, I decided to try the XAML Spy tool. It looks astonishingly, with a very modern yet attractive look, but that isn’t a trap.

Inspecting the application with XAML Spy.

IMHO, the best feature the XAML Spy tool has is the ability to inspect any running process; of course, it has to be any of the supported technologies, but with WPF, Silverlight, Windows Phone and Windows Store, I think you’ll cover anything but the web.
Once run, the spy asks for the target application to attach to. If the troubled app is already started, it’s pretty straightforward finding it among the “running processes”. In case you don’t see it at first glance, just refresh the Spy’s page.

Press “attach to process” when the target process has been selected.

Immediately, you’ll notice two things:

the XAML Spy app will turn to the inspection page, where many tools are available, and

a special blue tag will be shown in the top of the target window’s viewport.

It’s a drop-down menu (or whatever you want to call it), which offers a series of useful functions.

I must admit that I was shocked by seeing that I can enable a basic ruler: useful for sure for many pixel-perfect artworks, of any every-day app. Anyway, it is just a delightful feature of the XAML Spy, and not what we actually need for the inspection.

In the Visual Studio tree viewer, you have to scan the visual tree “by yourself”, in the sense that there’s no easing on a certain visual element. Sometime, on third-party components, you actually don’t have any idea on what to look for. Finally, when the tree is huge, the searching is more than a challenge.

Instead, the GUI inspection has been made easy with the XAML Spy. Just move the mouse over the desired (or suspected) point, and a dashed border will highlight the related visual element. Of course you can’t do everything, but it’s surely a dramatic quicker way to find the hot spot.

So, the goal is understanding why dragging the rightmost column header separator will reveal the hidden column. The visual inspection (see below) indicates that the sizing button is still available even the column has been hidden.

At this point, the simplest way to get around this behavior would be disabling the whole column (visual) fragment, but…will be a real solution.

One time more, the XAML Spy allows to change the value of a property directly by the aim of the left pane, which is a well-known property-grid. Let’s say that only a subset of the available properties can be modified at runtime with this feature. That’s because the WPF code, which turns to “frozen” many objects (especially whose created by a template-mechanism), thus no more modifiable externally.

So, turning the GridViewColumnHeader as NOT enabled (i.e. IsEnabled = False) is trivial, as well as verifying the result in no time.

The trick can be applied, so the only task to do now is implementing the mechanism in some way.
This is not complex at all, though. A simple converter will do the job: as soon the column width is larger than some pixel, it will disable automatically the whole column itself.

The code rewriting.

As stated, the code presented on the past article has dramatically changed, due a potential memory-leak.
Let’s say that a real memory-leak won’t happen, just because the WPF underlying code checks for the proper GridViewColumn instantiation, and throws an exception. However, the issue is severe enough to take in account, and find a workaround.

The problem faces the inability to reuse the same GridViewColumn more than once, in any GridView context. Once you insert it in a view, either you remove or that can’t be used any more. Since detaching is a bit complex, the only reliable way to consider is to prevent any GridViewColumn reusing.
Better, the old columns’ manager (GridViewColumnsManager) is no more useful and it’s substituted by a very simple ObservableCollection of GridViewColumnWrapper. Then, most of the automation hosted in the old manager has been moved into the GridViewEx.
Honestly, it’s a much more elegant solution, and safer as well. Furthermore, it offers a more abstract column-wrapper source, with just a collection.
So, the GridViewEx code is the following:

Conclusion.

Hopefully this release will be the final one. I test this source better in the near future, and any improvement or bug will be fixed accordingly.
Really can’t miss a final word on the XAML Spy tool, which surprised me a lot for the amazing features it offers. However, as seen, the flexibility of such a tool dramatically cuts the time of debugging and inspecting apps, especially when they’re running.