C / C++ / MFC

30-Jul-09 6:34

Hi,

When Creating Objects

For Controls e.g. CEdit, CStatic, etc ....

thr 3rd parm in the Create method is a CRect or

Rect specfying the Size of the Control is there

Anyway to use the Values specfied in the

resource file maybe by using NULL as the Value

it would then look at the resource file for the

Size of the Window Object

thankx

Bacon Ultimate Cheeseburger1-Aug-09 17:57

1-Aug-09 17:57

I assume that you are talking about creating controls in a CDialog derived class. If this is the case and the controls are defined in the dialogs resource then you can simply subclass the controls using their respective objects instead of calling their Create() method. Typically the controls are subclassed through the DoDataExchange() method in the CDialog derived class. If you need to create the controls dynamically use the SubclassWindow() method instead.

class CMyDialog : public CDialog
{
protected:
	virtual void DoDataExchange(CDataExchange* pDX);

	CButton m_MyButton;

	// ... more stuff here ...

};

void CMyDialog::DoDataExchange(CDataExchange* pDX)
{
	CDialog::DoDataExchange(pDX);
	// Deal with associating the dialog
	// control with the control object
	DDX_Control(pDX, IDC_MYBUTTON, m_MyButton);
}

1300 calories of pure beef goodness can't be wrong!

ForNow1-Aug-09 19:39

Re: Size Of Control Objects (Part 1)

1-Aug-09 19:39

I am a bit confused

The Sublassing concept I thought refers to messages

that were sent to a Control/window

By specfying a Window/CWnd object as the 3rd

parm of the DDX_CONTROL macro accomplish this ??

Is the message stored somewhere in the

CWnd/Cbutton object???

Using DDX prefix for this is still more

confusing as The DDX MACROS seem to refer to the

data in the Control

I unnderstand the button cotrol cann't have

data .....

Bacon Ultimate Cheeseburger1-Aug-09 23:57

1-Aug-09 23:57

ForNow wrote:
The Sublassing concept I thought refers to messages that were sent to a Control/window by specfying a Window/CWnd object as the 3rd parm of the DDX_CONTROL macro

Yes but it's much more than that. MFC contains it's own message pump and special handling when creating a window. In order for MFC to intercept messages sent to a window it's own internal window procedure must be called. Anytime you call the Create() method of a CWnd or derived object the window is first created and then automatically subclassed. This eliminates two things; the need for you register a window class (e.g. WNDCLASS) and having to supply a [custom] window procedure.

Dialogs however are a bit different. When you create a dialog it automatically creates all of it's child controls when it receives a WM_INITDIALOG message. This completely bypasses the internal window creation handler preventing MFC from processing messages for that window. Even if you make a call to CWnd::Attach() MFC will not receive the messages for those controls (see below). This also applies to windows created by directly calling Windows API functions such as CreateWindowEx() and CreateDialog().

To solve this problem explicit subclassing must be used. This does three things...first it associates the object with the specified window handle by calling Attach(), second it calls the PreSubclassWindow() method of the object and finally it subclasses the window by replacing the original window procedure with the one internal to MFC. It also does some error checking to prevent a window from being subclassed more than once (the debug build will assert if you attempt this). From that point on the object will receive all window message before the original window procedure is called.

This is important if you wish to provide custom functionality in a derived control class. For instance if you wanted to display a context menu when the user right clicks on a list box item you would need to create a class derived from CListBox and add a message handler for WM_RBUTTONDOWN. If the window control is not subclassed the message handler would never be called.

... to be continue ...

1300 calories of pure beef goodness can't be wrong!

Bacon Ultimate Cheeseburger1-Aug-09 23:58

1-Aug-09 23:58

This leads us to another question. Is subclassing absolutely required? The answer is no. If you are not implementing any custom functionality for a window or control calling Attach() can work just as well. This allows you to associate the window handle with a specific object and access that window via the objects methods rather than calling SendMessage(). The object will not receive any of the messages intended for the window but you will still be able to access it in a much more friendly manner. The difference however is that you must call Detach() when the controls parent window is destroyed.

There are a few other details that I haven't touched on here but I'll let you digest this first and if necessary we can move on to them. They mainly deal DDX_Control() and what it does above simply attaching or subclassing a window.

Hope this helps.

Bonus time:

ForNow wrote:
I unnderstand the button cotrol can't have data

Actually that's not true. All windows can have additional data associated with them by using the GetProp() and SetProp() API calls.

In MFC you can create a class derived from say CButton that contains data and then subclass the button control with an object of your new class. Since that window is now associated with your custom object that data is also associated with it.

1300 calories of pure beef goodness can't be wrong!

ForNow2-Aug-09 1:31

2-Aug-09 1:31

If I undertand correctly part of what

DDX_CONTROL does is subclass So after calling

DDX_CONTROL are messages for it still

processed thru the Dialogs Message map

or .......

Bacon Ultimate Cheeseburger2-Aug-09 3:02

2-Aug-09 3:02

ForNow wrote:
f I undertand correctly part of what DDX_CONTROL does is subclass

Yup yup. exactly.

ForNow wrote:
are messages for it still processed thru the Dialogs Message map or ....

Messages intended specifically for the control (any child window really) are dispatched through the controls message map and not through the CDialog's message map. The dialog object DOES however receive notification messages generated by the control. This behavior is defined by Windows itself (child <-> parent relationship) and isn't specific to MFC.

1300 calories of pure beef goodness can't be wrong!

ForNow2-Aug-09 5:02

2-Aug-09 5:02

THANK YOU !!!

If I took a Class in MFC What would the

Previous Dialog Cost me

Wanta a Free Cheese Burger.....

Thnakx Again

Bacon Ultimate Cheeseburger2-Aug-09 14:57

2-Aug-09 14:57

ForNow wrote:
If I took a Class in MFC What would the Previous Dialog Cost me

Much more than a cheeseburger I'm sure lol. Besides CodeProject can be a pretty good classroom so long as you don't make fun of the kid in the corner picking his nose Smile | :)

ForNow wrote:
Wanta a Free Cheese Burger

BEEFCAKE!

1300 calories of pure beef goodness can't be wrong!

ForNow2-Aug-09 5:15

2-Aug-09 5:15

One more thing

Since DoDataExchnge is called for both

Intializing and receving shouldn't I add the

Following code

If CButton.m_hWnd = NULL //

// CButton has not been
// attached

DDX_CONTROL(PDX,IDC_,CBUTTON)

Bacon Ultimate Cheeseburger2-Aug-09 15:04

2-Aug-09 15:04

No. The DDX_??? calls perform a certain level of error checking and validation prior to performing their operations. Calls such as DDX_Control check for a valid window handle. Here's the basic implementation of DDX_Control():

void AFXAPI DDX_Control(CDataExchange* pDX, int nIDC, CWnd& rControl)
{
	if ((rControl.m_hWnd == NULL) && (rControl.GetControlUnknown() == NULL))    // not subclassed yet
	{
		// ... more code here ...
	}
}

On subsequent calls to DDX_Control() no operations will be performed if a window handle is already associated with the control object.

1300 calories of pure beef goodness can't be wrong!

ForNow2-Aug-09 15:17

2-Aug-09 15:17

Thankx got it working

Had a stack overflow but that was the result of

a oversight on my part

thankx Again

Bacon Ultimate Cheeseburger2-Aug-09 15:38

2-Aug-09 15:38

You're quite welcome. Glad I could help.

1300 calories of pure beef goodness can't be wrong!

ForNow1-Aug-09 20:49

1-Aug-09 20:49

Please tell me if the following is Correct

IF you use DDX_CONTROL there is no need for

using Create/Attach which associates A

Windows Object the CWnd/Cotrol object

Bacon Ultimate Cheeseburger1-Aug-09 21:36

1-Aug-09 21:36

ForNow wrote:
IF you use DDX_CONTROL there is no need for using Create/Attach which associates a windows object the CWnd/Control object

Correct. I am actually writing a much longer reply to your previous message which should better help you understand how this all fits together. Hopefully I'll be a little clearer this time Poke tongue | ;-P

Is this your first MFC application or have you been playing around with it for a while?

1300 calories of pure beef goodness can't be wrong!

ForNow1-Aug-09 21:49