The native Win32 TreeViewcontrol supports the item state flag TVIS_BOLD for making TreeNodes bold. This is not exposed in the Windows Forms TreeNode API.
I would suggest adding a new Property bool Bold { get; set; } to TreeNode, which when set to true, sets the item state flag on the TreeView item.
C#
namespace System.Windows.Forms
{
public partial class TreeNode
{
public bool Bold { get; set; }
}
}
Describe alternatives you've considered
The canonical way to do this now by setting the NodeFont to something derived from the original is a bit cumbersome and also has the problem of potentially using the wrong font. The built-in default font may be different from the default font set in the OS.
Setting the state flag manually via P/invoking SendMessage(TVM_SETITEMW ...) works but is difficult to implement and also only works if the TreeNode already has a handle, i.e. it has been added to the TreeView already.
Will this feature affect UI controls?
Yes
The new property TreeNode.Bold should be settable via the designer like other TreeNode properties.
A definition for TVIS_BOLD was added in #1742, so we have it in our codebase now.
Bold name does not fit in to the Windows Forms naming convention both at the type level, and at the level of the Windows Forms SDK. Typically a user would think of Bold as being a property of a Font, ~however an individual node does not control Font, instead it is controlled at the TreeView level~ and there is NodeFont property, however it may not work as expected (see below).
In this case I propose we create a property called bool IsBold { get; set; } to control whether a tree node is rendered in bold text or not. This way the property fits well with other IsXxx properties exposed by the TreeNode type.
[UPDATE] applied @weltkante corrections and added a link to more background on the boldness issues
an individual node does not control Font, instead it is controlled at the TreeView level
Not entirely correct, there is TreeNode.NodeFont in case it affects your reasoning, though I consider IsBold being reasonable.
Also note the hint at the bottom of the docs, mentioning that NodeFont is bugged and will get clipped if the text drawn with NodeFont is larger than what the TreeView font would produce. I wonder if introducing the IsBold flag will have the same problem, since a bold font usually leads to bigger text, having a clipping bug present would mean the property would be basically useless.
Also note the hint at the bottom of the docs, mentioning that NodeFont is bugged and will get clipped if the text drawn with NodeFont is larger than what the TreeView font would produce. I wonder if introducing the
IsBoldflag will have the same problem, since a bold font usually leads to bigger text having a clipping bug present would mean the property would be basically useless.
This is exactly one of the reasons why the TVIS_BOLD flag exists in the first place, to avoid the text clipping problem. See https://devblogs.microsoft.com/oldnewthing/20090406-00/?p=18623
Not entirely correct, there is
TreeNode.NodeFont
馃う鈥嶁檪 I'm not sure how I missed it... I guess I was looking for Font.
Thank you
IsBold is nicer than BoldIsBold is independent of the NodeFont we like it.IsBold and NodeFont, e.g. when setting IsBold modifies the NodeFont, then we don't like it because it creates referential integrity issues where setting a boolean in one place suddenly causes the node to use a different font when the font was meant to be shared across multiple nodes. We should investigate that before we approve the API.C#
namespace System.Windows.Forms
{
public partial class TreeNode
{
public bool IsBold { get; set; }
}
}
Most helpful comment
This is exactly one of the reasons why the TVIS_BOLD flag exists in the first place, to avoid the text clipping problem. See https://devblogs.microsoft.com/oldnewthing/20090406-00/?p=18623