OSDev.org

Does anybody, by any chance, know of a way to retrieve the length of a subitem's text in a list view control? I already tried sending an LVM_GETITEMTEXT message explicitly, but I don't believe that actually returns the length of the item but rather the number of characters that were copied to the output buffer, which is useless if I am trying to get a length to guide buffer allocation. Any ideas, or was this just an incredibly stupid decision on Microsoft's part not to include any way of retrieving the length of the text?

Apparently not. You set the item's text, so you're expected to know the maximum length.

I can't see any reference to this in the documentation, but you could try passing zero as the maximum buffer length. Some API functions return FALSE here but tell you the length required; maybe the control will set the cchTextMax member in the LVITEM. I haven't tried this, though, and chances are it won't work.

just looked at the MFC source code...it uses a looping buffer reallocation, trying incrementally to find a good size. why they don't just add a way to get the list view item text length, I don't know, but if even Microsoft, who should know the freakin' API inside and out, uses a kludge like that, I suppose that's the only way to do it.

that you're adding the strings to the list view isn't really a good enough reason not to have it, since the same is true of list boxes, and they have a way to get the item text length. besides, if you're trying to write a wrapper class (as I am), then you don't necessarily know the maximum length string that will go in the list view.

If you're writing a list view wrapper class, then surely you know better than anyone else the typical length of a string in your control? Can't you call _tcslen() on each string you get given?

while that's true, as a matter of style I'd prefer not to have to go for an overkill buffer if a string of length 100 is added among a bunch of strings of length 5. there should still be a way to get the item text length. it's not as if it would have been difficult for Microsoft to add that to the API. the lack of it causes the complexity of my class to be increased for no good reason because I now have to manually keep track of a maximum length instead of just quickly getting the exact length of the string.

If you'd spent more time writing code and less time moaning about Microsoft you'd have this sorted by now.

I'm not "moaning" about Microsoft. I'm simply used to most of the stuff they create making sense, which is why I don't understand this glaring omission. I'm aware that the fact that it should be there doesn't change the fact that it's not, and I never said I thought it was going to be hard to work around, only that it adds complexity (however little) that doesn't need to be there. I see no reason to defend Microsoft in this particular instance, or to refrain from voicing my opinion that the mechanism I need should have been in the API to start with.