DrawItem() not called in owner draw listbox

[Jan M]

In an owner draw listbox derived from CListBox, DrawItem() is not called.

It works with VC6, but fails in a VC7 app using the same code.

The listbox control has "owner draw" and "has strings" set.

What more do I have to do to get the framework to call DrawItem() with VC7?

TIA

Jan

[Joseph M. Newcomer]

I've done this several times in VS7 without any problem; in fact the listboxes in my
PowerPoint Indexer are definitely owner-draw in VS7. I've also migrated some VS6 apps to
VS7 with no problem. You'd need to show something about the message maps and class
declarations to help with this (the actual drawing code in the body is not relevant, but
show the infrastructure, including the class definition, the virtual method declaration,
and if multilevel, all relevant pieces all the way back to the ": public CListBox"
declaration. BEGIN_MESSAGE_MAP and the IMPLEMENT_DYNCREATE or IMPLEMENT_DYNAMIC
declarations should also be shown.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[Fabrice M.]

I had the same problem after inserting a dependency to comctl32.dll version 6.
I passed several days to track the bug. Finally I found that for version 6, LBS_OWNERDRAWFIXED style has to be set in the OnCreate method using the parameter LPCREATESTRUCT lpCreateStruct like this:

lpCreateStruct->style |= LBS_OWNERDRAWFIXED|LBS_NOINTEGRALHEIGHT|LBS_NOTIFY;

For version <6,
The style was modified in the PreSubclassWindow(), using ModifyStyle like this:
ModifyStyle(0,LBS_OWNERDRAWFIXED|LBS_NOINTEGRALHEIGHT|LBS_NOTIFY);

So before this, we need to check comctl32 version with this call:

HRESULT hr = AtlGetCommCtrlVersion(&dwMajor, &dwMinor);

Hope it helps anybody for the future because I have seen no post in forums that explains this MFC issue.

>> Submitted via EggHeadCafe
>> Excel Generate High Quality RoadMaps
>> http://www.eggheadcafe.com/tutorials/aspnet/3310004f-e1ae-45a7-9bea-7b2b970d1230/excel-generate-high-quality-roadmaps.aspx

[Joseph M. Newcomer]

In general, you set these styles in the dialog editor and do not need to worry about
setting them anywhere else. Note that some styles are honored only at creation time, and
changing them after creation (e.g., with ModifyStyle) has no effect. If the behavior is
not specified, then the code is free to ignore post-creation modifications. I have found
that Microsoft tends to argue about "We can't change that because existing code would
break" only when they don't want to change something; they feel free to break other things
without warning or recourse. I would not use either of the techniques below, and I've
never had a problem with setting the styles in the dialog editor. If the argument is that
you want to make sure they are set, then the simplest way is to do an ASSERT that fails if
they are not set properly, and let the programmer fix the characteristics in the dialog
editor. That's the approach I take when I care about the styles.

By the way, always put blank space around binary operators so the text is readable, e.g.,
never write "A|B", always write "A | B". Readability matters.

I would like to add this anomaly to my essay on MSDN Errors and Omissions. Let me know if
you will allow this (I will give you a credit line in the article). If you want a
citation to other than the name you are posting under, and don't want to put that name
here, you can send me private email telling me how you want the credit to read.
joe