Re: ? Extending and (Forcibly?) Overriding a Class
On Tue, 2 Dec 2008 18:41:42 -0500, "Alec S." <nospam@127.0.0.1> wrote:
Got it. I?ve put an ON_MESSAGE handler for LVM_INSERTCOLUMN. Here?s what I?m
doing now: I?ve created a struct like this:
typedef struct tagCLVCOLUMN {
LVCOLUMN column;
int iDataType;
int iWidthType;
} CLVCOLUMN, *LPCLVCOLUMN;
Then I create a new InsertColumn function and override the existing ones.
In the existing ones, I put the LVCOLUMN in the CLVCOLUMN and call the new
InsertColumn. The new InsertColumn calls CListCtrl::InsertColumn, passing it
CLVCOLUMN.column, and adding the other variables to a linked list or something
like that. At least that?s what I?m thinking at the moment.
I've already explained why that's a bad idea. To summarize, the existing
InsertColumn functions are not virtual, so you cannot override them, and in
your LVM_INSERTCOLUMN handler, there's no way to distinguish your CLVCOLUMN
struct from a plain old LVCOLUMN, which LVM_INSERTCOLUMN can still receive
through SendMessage(LVM_INSERTCOLUMN) and by extension
CListCtrl::InsertColumn. I still think the best approach is to handle
LVM_INSERTCOLUMN and set the extra information to some useful default,
providing another function to change the extra settings. If you're really
set on having the option of doing it all with one function, you could do
this in your derived class:
using CListCtrl::InsertColumn;
result_type InsertColumn(params, extra_params)
{
InsertColumn(params);
UpdateColumn(extra_params);
}
This overloads your InsertColumn with the CListCtrl versions, which would
otherwise be hidden but remain available under public inheritance, which is
a bad thing as already mentioned. The using-declaration brings them into
your derived class to overload with your function, so you're no longer
hiding them, which demonstrates you've thought about the issue and
presumably have addressed it. Your LVM_INSERTCOLUMN handler would set the
useful defaults so that it doesn't matter who calls it (that's what I mean
by "addressing it"), but your special InsertColumn would then call
UpdateColumn on behalf of its caller.
I?m wondering what CListCtrl::InsertColumn does. I imagine that it is a wrapper
for a message to the CHeaderCtrl right? The list control doesn?t keep track of
the actual columns, the header control does correct? In that case, things would
be easier since I can shift the burden to my custom header control.
Search the MFC source code to answer those questions.
Pressing Ctrl-+ in a list control auto-resizes all the columns. You?ve never
done that? :o
Nope. I guess it might be useful in some situations, but making all the
columns the smallest they can be WRT the data they currently hold is rarely
what I want or need to do. OTOH, I do find it useful to double-click on a
divider to resize a single column. I find it useful in Excel to do this for
multiple column selections, but only because Excel respects the header
data, while the listview control ignores the header control contents, which
tends to result in lots of ellipses.
--
Doug Harrison
Visual C++ MVP