Re: ? Create Not Called in Dialog for Subclassed Control

See below...
On Wed, 17 Dec 2008 17:01:17 -0500, "Alec S." <nospam@xxxxxxxxx> wrote:

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:qrqik45j034jnab64unalnrqcvvb94upc0@xxxxxxxxxx

So you create it at design time with the OwnerData flag.
PreSubclassWindow:
ASSERT(GetStyle() & LVS_OWNERDATA); // requires Owner Data style

But the goal is to avoid having to put the burden on the resource editor or
dialog code, to allow the class to handle its own business. I can have it set
itself to report-mode, toggle gridlines, etc. but not owner-data mode.
****
I consider this an incorrect approach. The goal is that the control will be given
properties in accordance with the specified requirements. The specified requirements are
that it have the OwnerData flag set. So a control which does not will cause an assertion
failure, which will require exactly one rebuild to correct the problem. Not a
particularly serious issue.
****


You can also consider adding, instead,
OnInitDialog:?

Note that there is nothing that disallows having, for a short period of time,
two controls
with the same ID, because, during the time when these two controls exist,
nobody is trying
to access them by control ID.

Interesting idea. Unfortunately while it?s celver, it still puts the
responsibility on the dialog code rather than the control itself.
****
Life is hard. You cannot wave a magic wand and remake the world as you would like it. For
example, you could ideally have PreSublcassWindow PostMessage a notice to the window that
it has the wrong properties, but then that message will not be seen until the message pump
of the caller runs again, by which point it is probably too late.

Why is such a burden for the creator of the control to follow simple instructions?
*****


I suppose it may be best to just have that style set in the resource editor. It
would be nice if the control could do it itself, but if it?s going to be that
much extra hassle, then it is not worth it.
*****
We refer to it as "RTFM". If the programmer wants to use your control, you document the
requirements, and if the programmer fails to follow them, you ASSERT, and then the
programmer makes one fix and the problem goes away for the rest of the history of the
project. Not what I call a bad solution.
*****


Again, I'm stumped. How can I set a style of a control in a dialog at
creation
if it is subclassed? (It is subclassed via the dialog?s DoDataExchange.)
****
You won't ever get a notification such as PreCreateWindow or OnCreate because
the window
has already been created long before the subclassing

Yes, unforutnately. I?m still a little confused though, since the control is
created at some point. It looks like the problem is that my code is not active
yet at the time that the control is created because my (CMyList) code only kicks
in once it is subclassed, which happens after creation; before that, it is still
just a CListCtrl (or maybe even CWnd), corret?
****
It is created before it is bound to a subclass, and the behavior cannot be monitored until
it is bound to the subclass. So you cannot bind the control until it is created, which
means you cannot get the OnCreate notification. It has nothing to do with your code "not
being active", it has to do with the fact that until DoDataExchage (the virtual method
called by OnInitDialog) the controls have no subclassing, so your subclassing is an act of
future work at the point of creation. It is not a CListCtrl, it is not a CWnd, it is a
kernel object represented by an HWND, and only an HWND. Not until DDX_Control is issued
is that HWND bound to a variable, and until it is bound to a variable (and, I should add,
that its WNDPROC is now redirected to point to AfxWndProc) it has no visibility into MFC.
Note that if you do
list.Create(...)
and invoke your *own* Create method, then it will be bound to the variable before the
CreateWindow returns, by a trick where a CBT hook intercepts the window creation event and
binds the HWND to the CMyListCtrl. So after the return from the CBT hook handler, the
window has been subclassed, and the usual mechanisms of MFC become operational. But that
doesn't happen when a dialog is created.

You can learn this by single-stepping DoModal, with a breakpoint at AfxWndProc and, when
you find it setting the hook, setting the breakpoint at the AfxHookProc.
joe
*****
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages