[RESOLVED] ListView Bolded Items Font Size/Style cannot be changed

I'm playing with per-monitor awareness and trying to get VB's Common Controls ocx v6 compatible. Request below is for a non-subclassing approach.

With the listivew, about the only thing I haven't figured out how to manipulate is the Bold property on the control's Font and/or .ListSubItems Font objects. When .Bold is set to True, then any changes to the font size due to DPI changes are ignored.

It seems that the ocx creates a Bold font object exactly once, first time an item's .Bold property is set to true and does not recreate it when a new font (size, name, etc) is assigned. You can test this easily enough with any v6 listview
- Add a couple list items
- Ensure one has its .Bold property set to true
- At runtime, change the listview's Font size to 1.5x
- Each unbolded item will resize. If you change the font name, the bolded item does not change either.

Anyone know of a workaround to get the bolded items using the same font as non-bolded items?
- I've tried unbolding every item before changing the font and rebolding afterwards -- no change
- I've tried using SendMessage WM_SETFONT -- no change
- I've tried toggling the View property -- no change
- I've tried removing every bold item, changing font, & reinserting items while making bold -- no change
- I've even tried to completely clear the listview (headers & listitems) -- no change
Note: Simply toggling the .Bold property results in expected font when not-bolded and reverting to cached font when bolded. Those items not previously bolded change to cached font when bolded.

Granted that the v6 of the ocx is outdated, but this is the only option, so far, that I have not been able to get per-monitor DPI aware.

So MSCOMCTL.OCX, not COMCTL32.OCX then.

I don't have an answer yet but it helps to know which control we are talking about. Thanks.

Quote:

---

Originally Posted by dilettante

So MSCOMCTL.OCX, not COMCTL32.OCX then.

I don't have an answer yet but it helps to know which control we are talking about. Thanks.

---

Correct - mscomctl
FYI: comctl32 doesn't have a listitem.Bold property nor listsubitems. But clarifying leaves no doubt

P.S. Maybe applies to treeview's Node.Bold property too -- but I haven't played with treeviews & per-monitor DPIs yet ... next on my list.

Say LaVolpe, I make a great deal of use of the ListView in the MsComCtl.ocx.

Would you mind posting a small sample project that's manifested how you're doing it, so I know we're on the same wavelength?

I haven't messed with the per-monitor DPI aware stuff that much, but I know it's coming as my users' eyes get older and monitors get higher resolution.

EDIT1: Also, if you don't mind, please include the manifest file so I can easily stare at it.

@Elroy - manifest has nothing to do with this specific problem, nor does DPI awareness; other than font size changes during DPI scaling.

This is a 'bug' I believe, just wondering if others have a known workaround...

1. Add listview control (v6)
2. Paste this code into form load

Code:

---

    Dim n As Long
    ListView1.View = lvwReport
    For n = 1 To 3
        ListView1.ColumnHeaders.Add , , "Header" & n, 1440
    Next
    For n = 1 To 10
        ListView1.ListItems.Add , , "Item " & n
    Next
    ListView1.ListItems(3).Bold = True

---

3. Add this in form's double click event

Code:

---

ListView1.Font.Size = ListView1.Font.Size * 1.5

---

4. Run the project, double click on the form to show the 'bug'

That's really weird.

It has the same behavior on SubItems. Also, I played with it quite a bit and found some more information.

Apparently, there's one extra slot for a Font object in the control. But, it's unused until you set Bold somewhere on an Item or SubItem. It does NOT seem to be a slot per Item or SubItem.

I took the bolding out of the code, and just did it in the immediate window. I also put some text into SubItem #1 of all rows. Here are some results:

Scenario #1 (nothing bolded to start):

• Run program.
• Bold item #3. (All ok at this point)
• Make font bigger. (Error, bolded item doesn't get bigger.)

Scenario #2 (nothing bolded to start):

• Run program.
• Make font bigger.
• Bold item #3. (All ok, bolded item is larger font)
• Make font even bigger. (Error, bolded item doesn't get bigger.)
• Try making font much smaller. (Still an error, bolded item never changes size, and stays too big)

Scenario #3 (nothing bolded to start):

• Run program.
• Bold item #3.
• Make font bigger (same error as scenario #1).
• Bold item #4 (interestingly, font goes bold, but gets smaller, same as item #3).
• Make font even bigger. (bolded stuff stays same size).
• Make item #3, subitem #1 bold. (It's small like the bolded item #3. All bolding is same size and wrong.)

I tried other scenarios too, always with the same type of results.

So, apparently the control's font gets copied (i.e. a new instantiation of the font object), and then, all you can do is toggle the bolding on/off on that second object.

To fix it, we need to find a way to "get at" that second instantiation of the font object, making it resize along with the primary font object.

EDIT1: Here's an image of where I made it big, bolded, and then made it small again, including a SubItem. Actually, I bolded the SubItem after I made it small again:

Attachment 172147

EDIT2: Just to clarify ... it seems that a second font object is getting instantiated at the moment anything is bolded.

Wow, you can do...

Code:

---


ListView1.Font.Bold = True


---

... and everything is fixed. However, if you then subsequently do...

Code:

---


ListView1.Font.Bold = False


---

... everything is broken again.

Apparently, if the main font is bolded, the secondary font is ignored.

I've played around with some values stored relative to the listview object's memory location. At 17th Long offset from that memory spot, the value is the same as the 16th offset to start with. When .Bold is first called, the 17th offset changes its value. I tracked 50 offsets and offset 17 is the only one that changed after .Bold is first called.

I think offsets 16 & 17 are related to the two fonts. But I do not know what those values are. They are not hFont values per GetObject API. I don't think they are IFont or StdFont interface pointers/address, but am not sure. However, I do feel those values are related to the two fonts you mention.

I'm about to mark this as resolved and flag that option is non-compatible with per-monitor DPI awareness.

I looked through all the ListView messages, and didn't find anything about making specific items bold. I was thinking/hoping there was some API way of getting at that secondary font.

That must be some kluge that was done for VB6, is all I can figure.

We could consider just re-copying that 17th DWord (putting it back to the 16th), but that would almost certainly orphan an instantiated font object.

Interestingly, you can execute a...

Code:

---


Set ListView1.Font = Nothing


---

I wonder what the 16th DWord looks like immediately after doing that. Apparently auto-instantiate is on because you can subsequently set the font again, and it continues working (but still with the bug).

Quote:

---

Originally Posted by Elroy

We could consider just re-copying that 17th DWord (putting it back to the 16th), but that would almost certainly orphan an instantiated font object.

---

I thought of that too, but am not keen on that idea. If it's a pointer to allocated memory on the stack or virtual memory, I can test that. And if so, it can be deallocated. But if that memory location contains other stuff like pointers, then whatever those pointers are will be leaked or objects orphaned until the process terminates. Typically, the offsets after the object pointer are instance-related values for that object -- don't like messing with those unless I know exactly what they are.

I also used Spy++ to see if I can get a clue. But all I really see are a bunch of WM_USER messages (probably undocumented). Was hoping one of the parameters looked like a font handle, but doesn't appear so. When I see the WM_GETFONT messages for the listitems during repainting, all I see is the same font handle being returned, not two font handles. I'm thinking the control is simply testing something like:

Code:

---

If ListItem.Bold = True And PrimaryFont Is Not Bold Then
    If BoldFont Not Created Then Create BoldFont
    Select BoldFont Into hDC
Else
    Select PrimaryFont Into hDC
End If
Render ListItem

---

And changing the primary font never triggers destroying the created bolded font

Quote:

---

Set ListView1.Font = Nothing ...
I wonder what the 16th DWord looks like immediately after doing that. Apparently auto-instantiate is on because you can subsequently set the font again, and it continues working (but still with the bug).

---

Yep, I tried that too. Though I wasn't looking at which values change when the primary font is changed after bolding takes place the first time.

Yep, once that bold font gets instantiated, we seem to have no way of uninstantiating it (or messing with its properties, other than .Bold) without uninstantiating the whole control.

That's probably why there's no italic. If they had bold and italic, they'd need three more fonts: bold but not italic, bold and italic, not bold but italic. And on and on for other font properties. And I guess they didn't want a font-per-item-per-subitem.

And I thought once I had a simplified/generic routine to swap out scaled image lists, everything was smooth sailing afterwards. Got stumped on a simple property instead. I wouldn't be surprised if treeview's Node.Bold suffers same problems -- tomorrow it gets a look.

For all. Marked this as resolved. If anyone has a proven workaround (no subclassing), please chime in. The v6 common controls ocx does have just a couple of things that are not compatible with per-monitor DPI awareness. This is just one more thing & unfortunately, I think the .Bold property is a pretty common option used in v6 listviews.

Edited & FYI: The .Bold property of treeview nodes does not suffer from this 'bug'

LaVolpe,

How are you snooping the object? I'm doing the following, and I don't see anything changing at all, no matter what I do:

Code:

---


Private Declare Function GetMem4 Lib "msvbvm60" (ByRef Source As Any, ByRef Dest As Any) As Long ' Always ignore the returned value, it's useless.

Private Sub Form_DblClick()
    Dim i As Long
    Dim j As Long

    For i = 0 To 20
        GetMem4 ByVal ObjPtr(ListView1) + i * 4, j
        Debug.Print j
    Next

End Sub



---

Quote:

---

Originally Posted by Elroy

How are you snooping the object? I'm doing the following, and I don't see anything changing at all, no matter what I do:

---

ObjPtr(ListView1.Object)

Ahhh, thank you.

Hmmm, I'm doing this, and still not seeing any changes, no matter what I do to bolding items, subitems, or changing overall font size.

Code:

---


Private Sub Form_DblClick()
    Dim i As Long
    Dim j As Long

    For i = 12 To 20
        GetMem4 ByVal ObjPtr(ListView1.object) + i * 4, j
        Debug.Print j
    Next

End Sub



---

I give up. I tried subclassing it and watching the messages, and exploring several of those options, but I still couldn't figure anything out. Without some deep disassembly digging, I don't think this one has a fix.

It appears the MSComctlLib.ListView custom draws its items/subitems in order to make the text bold or change the forecolor or draw a checkbox. The bolded font's handle can probably be retrieved via GetCurrentObject, but then, what now? Is there an API that can change a GDI font object's properties given its handle? Apart from (at least partially) overriding the ListView's custom drawing, the only other thing that can probably be done is delete that font handle; not sure how the ListView would react to that. Would it recreate the secondary font based on the current primary font or crash (or perhaps do nothing)? This potential solution, of course, necessitates subclassing.

The .Bold for ListItems is done via CDDS_ITEMPREPAINT and CDRF_NEWFONT.

Thanx Krool. At least I now know which subclass message to trap to determine the font handle. If I can find where the font handle is stored, then it can be changed. Will likely play with that a bit later today. If successful, I'll post the hack. For my purposes, I do not want to subclass the listview -- that would be the owner's responsibility.

Follow-up. I can see the static bold font handle. However, I haven't been able to locate where it is stored by the ListView. It's like looking for a needle in a haystack. Pretty much giving up on a non-subclassing approach. The .Bold property of ListItems and ListSubItems will be tagged as non-compliant for per-monitor DPI awareness without subclassing to correct the issue.