See below...
Post by WoodyI'm using someone's customized CListCtrl code. The code is in a static
library, which I link w/my apps. I have two "uniqueness" problems, for
which I'd like advice.
1) The control sends a message to the parent dialog under certain
circumstances. How can I be sure the message code is unique? If it is
compiled into the library, an app which defines its own message codes
may conflict.
****
You have said nothing about the message. WIthout knowing what you are talking about, it
is hard to answer the question.
If the code is of the form
GetParent()->SendMessage(UWM_WHATEVER, ...);
where UWM_WHATEVER is the message code, then the only way to do this is to use Registered
Window Messages, where the header file defines a string like
#define UWM_WHATEVER_MSG _T("UWM_WHATEVER-") _T("<guid here>")
In the PreSubclassWindow handler for the subclass, do
UWM_WHATEVER = ::RegisterWindowMessage(UWM_WHATEVER_MSG);
where UWM_WHATEVER is a static UINT. Your app does a similar RegisterWindowMessage. What
I usually do is put this in the header file:
namespace {
UINT UWM_WHATEVER = ::RegisterWIndowMessage(_T("UWM_WHATEVER-") _T("<guid here>"));
};
The use of a static variable in an anonymous namespace is the accepted way of handling
this. Note that you can include this header file in as many compilation units as you want
without any multiply-defined symbol errors.
Then, for dispatching, you use the ON_REGISTERED_MESSAGE macro in the message map.
See my essay on message management on my MVP Tips site.
The use of constants, such as
#define UWM_WHATEVER (WM_APP+32)
is considered to be in exceptionally poor taste in defining custom controls, since any two
programmers can choose the same WM_APP offsets (and using WM_USER is considered to be
tasteless-squared). In fact, this is the compelling reason for NEVER using a
compile-time-static control ID for messages from a child to a parent (unless you are
sending a WM_COMMAND or WM_NOTIFY message).
****
Post by Woody2) The control creates edit controls dynamically. How can I assign a
unique resource ID to each control, that will not conflict with the
IDs of the other controls in the parent dialog, or doesn't this matter.
****
If the purpose of the edit control is to achieve something like a spreadsheet editing
capability, then the parent of the edit control is the custom CListCtrl, not the parent of
the CListCtrl, so there is no possibility of conflict if you handle all the edit messages
in the CListCtrl itself. You can pick some useful random number for the ID and the only
conflict you need to worry about is with other edit controls you create as children of the
CListCtrl. And note that if you have six CListCtrl instances in your dialog, each one of
them can create child edit controls with exactly the same ID, and there will be no
possibility of conflict.
joe
****
Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm