Click here to Skip to main content
15,906,624 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hello! Need some help - I have MS VC++ 6 project; so I'm just trying to add EDIT control to the one of my modal window (IDC_EDIT1), variable m_Edit1 (CEdit) and even after that this is impossible to open such window. Application crashed with "Access violation" error - NTDLL.DLL (0xC0000005). If i remove this variable via Class Wizard - all is OK again. And I found this problem in every window - even in the main form. What does it mean? Thank you for support.

What I have tried:

header file:
// Dialog Data
	CEdit	m_Edit1;
	CComboBox	m_ComboSerial;
	CComboBox	m_ComboDeviceType;
	CSortListCtrl	m_ctrlListHistory;

cpp file:
DDX_Control(pDX, IDC_EDIT1, m_Edit1);
DDX_Control(pDX, IDC_COMBO_SERIAL_NUMBER, m_ComboSerial);
DDX_Control(pDX, IDC_COMBO_DEVICE_TYPE, m_ComboDeviceType);
DDX_Control(pDX, IDC_LIST_HISTORY, m_ctrlListHistory);
Updated 9-Feb-24 2:28am

You need to call m_Edit.create( style, rect, parent, ID) before you can use the CEdit object.
Share this answer
shupike 9-Feb-24 9:48am    
You know - I just added all necessary strings manually and it works! I mean - without Class Wizard using. Looks like some problem in Visual Studio - how do you think?
Rick York 9-Feb-24 11:11am    
The question was far from clear but if the controls for the dialog(s) are in the resource file then one does not need to create them. The DDX_CONTROL statement will map the object to the resource so calling create is unnecessary.
There are three steps to making a control in a dialog work with an MFC program. You did two of them and omitting the third will result in the behavior you observed. The third step is to add an edit control to your IDD_NOTEBOOKS_DIALOG with the identifier IDC_EDIT1 in the resource file. This is usually done with the resource editor but it can be done manually if you prefer.

FWIW, I have worked with MFC a long, long time and eventually I got in the habit of never putting dialog class declarations in header files because it is just unnecessary. With the proper interface, nothing else needs to know the details of a dialog's implementation except the dialog itself. The key to this is the interface. A typical interface I would write would like something like this :
bool OpenNotebookDlg( CWnd * pparent, NotebookData & data );
The implementation of that function would be with the dialog's code and would initialize the controls with the data and then, if OK is clicked it extracts the data from the dialog and returns true. Usually I would have an Edit method in the NotebookData class and its implementation would call the function shown. I have found this to be a very clean and easy to use practice. The one caveat to it is the dialog code has to know about the data it is displaying but I consider that to be a fair and appropriate trade-off.
Share this answer
shupike 14-Feb-24 3:13am    
You know that the strangest thing is that if I add a variable for the Edit control through the ClassWizard, an error "Access violation" error - NTDLL.DLL (0xC0000005) occurs, but if I write it manually in the *.h and *.cpp files, it works, but after that the values of the variables stop being displayed when the cursor is hovered over them. And this is no longer being corrected. I don’t understand why the ClassWizard doesn’t accept new variables.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900