\nCommenter Frans Bouma asks,\n<\/P>\n
\n\nWhy is the text of a treenode chopped off\nwhen you switch the font from normal to bold<\/A>?\n\nIt apparently is for backwards compatibility<\/A>\nbut I fail to see why this is necessary for backward compatibility…\n<\/BLOCKQUOTE>\n\nActually, bold treeview items work just fine.\nWatch:\n<\/P>\n
\nStart with our \n\nscratch program<\/A>\nand make these changes:\n<\/P>\n
\nBOOL\nOnCreate(HWND hwnd, LPCREATESTRUCT lpcs)\n{\n g_hwndChild = CreateWindow(\n WC_TREEVIEW, NULL, WS_CHILD | WS_VISIBLE | WS_TABSTOP |\n TVS_HASBUTTONS | TVS_HASLINES | TVS_LINESATROOT,\n 0, 0, 0, 0, hwnd, (HMENU)1, g_hinst, 0);<\/p>\nTVINSERTSTRUCT tvis;\n tvis.hParent = TVI_ROOT;\n tvis.hInsertAfter = TVI_LAST;\n tvis.item.mask = TVIF_TEXT | TVIF_STATE;\n tvis.item.stateMask = TVIS_BOLD;\n tvis.item.state = 0;\n tvis.item.pszText = TEXT(“First”);<\/p>\n
tvis.hParent = TreeView_InsertItem(g_hwndChild, &tvis);<\/p>\n
tvis.item.pszText = TEXT(“Second”);\n tvis.item.state = TVIS_BOLD;\n TreeView_InsertItem(g_hwndChild, &tvis);<\/p>\n
tvis.item.pszText = TEXT(“Third”);\n tvis.item.state = 0;\n TreeView_InsertItem(g_hwndChild, &tvis);<\/FONT><\/p>\n
return TRUE;\n}\n<\/PRE>\n
\nI elided error checking for expository purposes.\n<\/P>\n
\nThis code creates a tree view and populates it as follows:\n<\/P>\n
\n
- First\n
\n
- Second<\/B>\n
- Third\n<\/UL>\n<\/UL>\n
\nWhen you run this program, you can see that the text for all\nthe items appears as expected; nothing is truncated.\n<\/P>\n
\nAs for the backward compability remark,\nit’s quite simple:\nEvery change, no matter how seemingly insignificant,\nhas compatibility consequences<\/I>.\nThe common controls are heavily used in third party programs,\nmany of which make strange assumptions about how the controls work,\nrelying on quirks of implementations in strange ways.\nFor example,\nthose who have read\n\nthe first bonus chapter of my book<\/A>\nwill know that even something as seemingly harmless as\nfixing a flicker bug in the status bar resulted in\na broken status bar in a program from a major software publisher.\nEvery change is taken with great trepidation, and the bias is\nto preserve bug-for-bug compatibility.\n<\/P>\n
\nIn this case, the issue was with the way the width of the treeview\nitem is calculated.\nYou can easily imagine programs which worked around the existing behavior\nby artificially padding the item with spaces to compensate for\nthe miscalculation.\nIf the treeview suddenly fixed the bug,\nthese treeview items would now be undesirably large,\npossibly creating a horizontal scroll bar where there previously\nhad been none, resulting in \nbugs like “After upgrading, the last item in my treeview is\nbeing covered by a scroll bar.”\nWe saw something like this before when we looked at\n\nthe effects of the
DS_SHELLFONT<\/CODE> dialog style<\/A>:\nFixing the bug described in that article would result in property\nsheet pages coming out undesirably large (because their sizes were\nartificially inflated to compensate for the erroneous calculation).\n<\/P>\n\nThat doesn’t mean the bug can’t get fixed, however.\nJust as the
DS_SHELLFONT<\/CODE> flag is a signal to say\nthat your property sheet page wants to use the new calculations,\nyou can tell the tree view\n“Please give me the version of the treeview that fixes the\nfont bug” by sending it theCCM_SETVERSION<\/CODE> message\nand specifying that you want version 5.\nSimilarly, you can opt into version 6 of the common controls\nby providing a manifest.\n<\/P>\n\nUpdate<\/B>:\nI slipped a subtlety into this article which\n\nit appears people didn’t pick up on<\/A>,\nso I’ll make it explicit.\n<\/P>\n
\nThe original question was about “switching the font from normal to bold”,\nbut there are multiple ways of doing this.\nMy sample code used the recommended (declarative) method of setting the\n
TVIS_BOLD<\/CODE> flag.\nBut if you click through the link, you’ll see that\nthe original commenter was using the procedural method of\nhandling theNM_CUSTOMDRAW<\/CODE> notification,\nselecting a new font\n(a boldface variation of the normal font),\nand returningCRF_NEWFONT<\/CODE>.\nThis is a technique I had illustrated previously with\n\nlist views<\/A>\nand\n\ntool tips<\/A>.\n<\/P>\n\nThe compatibility behavior is for fonts customized via\n
NM_CUSTOMDRAW<\/CODE>.\nThe declarative method was added specifically to address the bug\nin item size calculations when people change the font procedurally:\nOlder versions of the treeview control asked for the custom font\nonly when painting; it didn’t ask for the custom font when measuring.\nAdding the font query to version 6 was actually quite risky,\nsince the only way to ask the application for the procedurally-applied\nfont is to actually go through the motions of drawing it<\/I>,\ngenerating a\n\ndummyNM_CUSTOMDRAW<\/CODE> notification\nwith an empty paint rectangle<\/A>.\nIf an application painted outside the rectangle, you would have seen\nseen random painting on the screen.\n<\/P><\/p>\n","protected":false},"excerpt":{"rendered":"Commenter Frans Bouma asks, Why is the text of a treenode chopped off when you switch the font from normal to bold? It apparently is for backwards compatibility but I fail to see why this is necessary for backward compatibility… Actually, bold treeview items work just fine. Watch: Start with our scratch program and make […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-18623","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Commenter Frans Bouma asks, Why is the text of a treenode chopped off when you switch the font from normal to bold? It apparently is for backwards compatibility but I fail to see why this is necessary for backward compatibility… Actually, bold treeview items work just fine. Watch: Start with our scratch program and make […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/18623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=18623"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/18623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=18623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=18623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=18623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}