Hi everybody,

I am developing an app which has to create a modeless dialog using
CreateDialogIndirect() with a DLGTEMPLATE from memory.
As long as I use only predefined system classes (according to MSDN
these are Button, Edit, Static, List box, Scroll bar and Combo box) -
everything runs well.
But I need to use some other dialog elements as well. For example, a
Group box, easily available in the ressource editor of the Visual
Studio, is missing in the list of the predefined classes. How can I dug
it out of the deeps of the Windows ?

Worse than that, I would like to have a control derived from a
CListView, displaying some behaviour I need through few overriden funcs
in the CListView. Is it somehow possible with DLGITEMTEMPLATE ?

Any kindly hints about the topic would be highly appreciated.

Victor

Victor,

A group box is a button class window. Have a look at the topic titled
"Creating a Button" in MSDN.

That's not possible. MFC attaches an instance of your derived class
after the underlying listview32 control (WC_LISTVIEW class name) has
been created by Windows from the dialog template information.

Dave

On 12 Feb 2006 10:25:36 -0800, "Victor" <big.boss@chefmail.de> wrote:

How about using CreateWindow to add at least some of those controls?


-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

Thank you Dave,

concerning the group box, I have coped with the problem quite
successfully.

What about the idea to use GetClassInfo() for the WC_LISTVIEW and then
RegisterClass() with the obtained class information - but with a new
class name? As a matter of fact, I did not change anything in the
CListView except of few overriden message handlers...

How do you assess this approach?

Victor

I have some follow-up considerations :

Dave, you write "...MFC attaches an instance of your derived class
after the underlying listview32 control (WC_LISTVIEW class name) has
been created by Windows from the dialog template information."

Well, I tried to investigate a little into the subject and really found
that a dialog template in memory used during creation a CDialog-based
dialog contains entrees marked 0x81 (i.e. predefined 'Edit' element)
for entities implementing a derived class, exactly like it does for
entities of CEdit. Nevertheless, the created dialog displays behaviour
of a derived control, not that of CEdit.

As far as I can guess, there must be a possibility to attach an
instance of the correct class to the dialog element initially
implemented as 'Edit'.

So the question is only : where does it happen ?

Victor

First off, the dialog template knows nothing about CEdit or
CYourDerivedEdit all it knows is that it's an edit control to be
created.

In the DDX handler. Member variables that have been "attached" to a
variable are attached there.

Dave

Victor wrote:
I haven't used MFC in a long time, but I doubt you need to go
through all that. Just put a list control in your dialog, get the
handle with GetDlgItem() and attach it to the class.


No idea. Look in the MFC source at the CWnd class, find out
which method is the one that attaches the window to the class,
override that method and attach it yourself. Or ask in an
MFC newsgroup, as you'll probably get a better response. I
don't know much about MFC, but I know it's not magical or
anything. It's just ordinary C++.

Matt

Victor wrote:
Your code's DDX_Control call leads to an MFC call to
CWnd::SubclassDlgItem. When you derive from a standard control the
standard control is still created on the dialog template. The
difference is provided by subclassing the control after it is created,
which lets your derived class intercept messages sent to the control.

--
Scott McPhillips [VC++ MVP]

Victor,

Scott pointed you to the bit of MFC code that does the subclassing
(attaching an instance of an MFC class to a control).

You would normally have instances of your derived control classes as
members of your dialog class - so that they exist for the lifetime of
the dialog. The attaching code (normally called from the DDX method)
is called during the WM_INITDIALOG message (OnInitDialog) handler.

Dave

Thank you all guys who answered to my posting.

Now I have some more understanding about the technique to create a
modeless dialog I need, but I am still missing a rather crucial point
in all this stuff...
Well, once again about what I want to implement --

This is a function - say CreateMyDialog() - intended to create a dialog
from a DLGTEMPLATE. Basically, my project has not much in common with
MFC, but I have two controls designed outside of it in an own static
library (LIB) -- CMyEdit and CMyListView, that _are_ MFC-based but
differ in only a couple of event handlers, specially OnPaint. I need to
include several instances of the controls of those derived types in the
constructed dialog.

Well, I realized that the dialog template must contain only standard
predefined classes Edit or List for those control elements. So, the
elements have been evoked to existence quite successfully and have even
the right look.
What I do not still comprehend is : how to attach these elements to my
classes ?

By now, my dialogProc() is a global func, declared and defined in the
same file like the CreateMyDialog(). I attach it to the dialog instance
thru call to the CreateDialogIndirect().

Sorry Dave, I do not recognize how to combine all this with the DDX
handler... and where should it exist? Should I declare an instance of
the CMyEdit anywhere in the file ? Or how to subclass and where ?

Please give me some more points

Best regards
Victor

Victor wrote:
I don't think this is going to work. The MFC controls rely on the MFC
message pump. But it sounds like you are not running the MFC message pump.

But, the problem you are asking about would be solved (in MFC) by
calling SubclassDlgItem after the control object is created. That is
all the DDX handler does.

--
Scott McPhillips [VC++ MVP]

Thank you Scott !
Thank you Dave !

Owing to your hints I have managed my problem !

Best regards
Victor