MFC VC++

Member_14575556

Thank you. :)

BOOL CMyDlg::OnInitDialog()
{
CDialogEx::OnInitDialog();
..........
..........
return TRUE;
}

What is the reason of calling the base class member function

CDialogEx::OnInitDialog()

inside the child class member function?

BOOL CMyDlg::OnInitDialog()

Victor Nijegorodov

All the dialog controls are created and subclassed within the base class CDialogEx::OnInitDialog()

Victor Nijegorodov

Where did you get this code? The better way to obtain the pointer to a header control is using [CListCtrl::GetHeaderCtrl](https://docs.microsoft.com/en-us/cpp/mfc/reference/clistctrl-class?view=vs-2019#getheaderctrl) method.

Victor Nijegorodov

Note that if these m_Name, m_Status, m_Comments are CString (CStringA, CStringW, CStringT) objects then you do not need to additionally initialize them to empty because they are already created (via default ctor) as empty strings.

CPallini

Code reuse. See, for instance: 11.6a — Calling inherited functions and overriding behavior | Learn C++[^].

Stefan_Lang

True, but I expect that in this case the compiler will optimze away the double initialization. All that remains is a little bit of extra code that, while not needed, serves to clarify that these members are indeed properly initialized - no matter what types these members really are. Moreover, if the types happen to change in the future, it's safer not to rely on them being initialized by default. It's similar to soem C++ keywords, like override: at the time you add it to your code, it doesn't serve any purpose but documentation. But if the virtual base method gets changed in the future, it's safer to use the override keyword because then the compiler will complain if you don't also adapt your override method(s).

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Member_14575556

Thanks for the reply. I got this code snippet from an MFC tutorial website.

void CMyDlg::ResetListControl() {
m_ListControl.DeleteAllItems();
int iNbrOfColumns;
CHeaderCtrl* pHeader = (CHeaderCtrl*)m_ListControl.GetDlgItem(0);/* <---- this line */
if (pHeader) {
iNbrOfColumns = pHeader->GetItemCount();
}
for (int i = iNbrOfColumns; i >= 0; i--) {
m_ListControl.DeleteColumn(i);
}
}

I know this code will reset all the Item and column in the list view control. I want to get a deeper understanding in that specific line of code.

Member_14575556

First of all Thank you for the help. :) Is this concept similar for CWinApp::InitInstance . Even when I commented this line my application still works. why?

BOOL CWindowApp::InitInstance()
{
CWinApp::InitInstance();/* <--- this line */

CMyDlg dlg;
m_pMainWnd = &dlg;
INT_PTR nResponse = dlg.DoModal();
.......
.......
.......
}

I would like to ask one more question regarding m_pMainWnd. Sorry if this is a silly question. Why do we assign the address of the dialog to m_pMainWnd? I know m_pMainWnd is a CWnd* m_pMainWnd.

Victor Nijegorodov

Well, perhaps it is still working, but is there any guaranty it will also work in every new Windows version? What will happen if header control will get some other control ID?

CPallini

Quote:

Is this concept similar for CWinApp::InitInstance . Even when I commented this line my application still works. why?

There are two alternative explanations:

The CWinApp::InitInstance does nothing, so it is safe to discard its call.
InitInstance does perform some initialization that now is missing in your application. Your application may run fine, at the moment, (for instance because it doesn't need such initializations) but this is definitely not a safe scenario.

Bottom line: if they (Microsoft) do invoke CWinApp::InitInstance in their code samples (and in generated code) then I would do the same.

Quote:

hy do we assign the address of the dialog to m_pMainWnd? I know m_pMainWnd is a CWnd* m_pMainWnd.

Possibly because the dialog it is the application main window.