MFC VC++

[Member_14575556]

Thank you. That clear my doubt :) If you don't mind could you explain this line too:

CHeaderCtrl* pHeader = (CHeaderCtrl*)m_ListControl.GetDlgItem(0);

[CPallini]

m_Name

is an instance of the CStringT class. The

m_Name(_T(""))

initializes it (see Constructors and member initializer lists - cppreference.com[^] with the empty string (of TCHARS, see Generic-Text Mappings in tchar.h | Microsoft Docs[^]) literatal. The same happens with the other strings instance in the member initializer list.

[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:

1. The CWinApp::InitInstance does nothing, so it is safe to discard its call.
2. 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.