kzeise.com

SharedSizeGroup is a great mechanism to align multiple columns or rows between Grids in WPF, but it can have unexpected performance implications. I recently came across this when I used it inside the ItemTemplate of a ListBox. A few items in there, and everything works as expected, but after putting in a few dozen, it became really sluggish, and the app was permanently burning CPU cycles.

I redid the design without the need for the size group, removed the Grid.IsSharedSizeScope from the list box, and performance was restored. This was with .net framework 4.8.1.

While researching the problem, I also learned:

• ScrollViewer.CanContentScroll can be used to switch the scrolling between ensuring that the top element is aligned (true), and continuous scrolling (false)

• SharedSizeGroup can also be used with multiple columns/rows in the same grid, if you want them equal.

Windows .NET WPF orders their controls in a visual tree, and this tree has the restraint that every element can only have one parent. This can trip you when define a control as a resource, and then reuse it from the item template of a container. You will see the control exactly once in the list. So never do this in your XAML:

Instead either use templates, with DataTemplate or ControlTemplate, or define a VisualBrush for reuse. The better performance for icons and similar uses is with a visual brush, as it is one item that can be reused and is optimized for painting. For example:

The alternative with ControlTemplate initiates more, but is more compact to describe:

I ran into these problems when I naively tried to use the Visual Studio Image Library for some basic icons for my app. All of their icons are defined as a Rectangle, so these techniques are useful if you want to use them inside of lists.

I recently wanted a fast way on the command line to find all available COM ports, and after some searching I constructed the following:

This code searches for all active port devices, which nowadays should only be COM Ports, then sorts them numerically by port number, and finally displays them together with a description and the manufacturer (of the driver). The only tricky part is that the COM port number is not available directly, but must be extracted from the Name property.

My thanks to this overview by Mathew J Bray, which also includes different approaches.

When trying to read data from the USB Serial driver used on the Pico, it would not read anything in my C# program. It turned out that the Pico library also simulates the RTS and DTR signals in its CDC driver, unlike the typical FDTI chips, which simply ignore them. This gives us two options to deal with it in the SerialPort class of .NET:

• Set DtrEnable to true, and keep the Handshake to None
  This ignores the RTS input, which could lead to overflow, but it is a setting that also works with ports that do not use RTS/DTR handshakes.

• Set DtrEnable and RtsEnable to true, and the Handshake to RequestToSend
  This enables hardware handshaking, and behaves unpredictable when no HW handshake is implemented.

As a C# programmer, Icon DLLs are a leftover from Windows XP days, but I recently needed to create one. The process is non obvious, but quite simple.

1. Create a new DLL project for the icons, and remove the default class. To keep things portable, all icons should be in the project folder.

2. Create a stand alone “Native Resource Template” with File | New | File

3. Insert a dummy resource, then use File Save As, with the file type “Win32 Resource File”, to move the template to your project folder, and delete the dummy resource again.

   This is needed because the Save As refuses to save a template without any resources

4. Right click to “Add Resource” and import all your existing icons

5. In the project properties, tab “Application”, choose Resource file for resources, and select your .res file

6. Add a reference to your icon and res files into the project to make them easier to open, with build action “None”.

In WPF/XAML, you will very often create your custom templates for containers, and one of the issues is to properly adjust the template contents with its container.

The most common problem is making the template fill the container completely. This is done with the properties HorizontalContentAlignment and VerticalContentAlignment of the container, setting them to Stretch. You can then use the Margin of your top level template element for positioning.

When we need more precise control, we can do calculations with a converter based on the actual layout parameters of the container. You get that info with a RelativeSource binding in FindAncestor mode.

This requires you to add a simple converter to your project to do the calculation:

and include it in your application resources

I recently was adding binding support to a custom WPF control in .NET, and was checking how you can integrate information from the bindings Binding.UpdateSourceTrigger setting. But you do not need to implement anything. If you just post an update on every change, the binding system itself will prevent the updates from being forwarded if you use a different mode than UpdateSourceTrigger.PropertyChanged. It might be useful to look at BindingOperations.GetBindingBase to retrieve the Binding, and determine when you need to post updates, but that is a performance optimization, not needed to get correct behavior.