Still write the input interface of that database application, found when the variable is bound to the controls in the dialog. If you can use the MFC dynamic data to use MFC, it is not possible to control the behavior of Edit. For example, I have to let these Edit are all dropped by disabled, and can only enabled the operator to edit the contents of the Edit after the editing state. So, if the CEDIT is binded to the Edit Although the behavior of the edit box is controlled but cannot use the dynamic data of the MFC. This will be very troublesome in the feature that you want to write data exchange. However, it is possible to adopt a way to bind a CString and bind a CEDIT to implement the purpose of using the MFC data exchange and control of the behavior of Edit. Just in this way, each Edit will have two member variables to correspond. There is a lot of edit in the dialog, and the data of member variables is more double. Although this is nothing, I always feel uncomfortable. So hit the dynamic data exchange of the MFC, I don't want to write new DDX and I don't want to write new classes. So try the member variables bound by DDX_Text () to point to the corresponding database field generated by the class wizard in the database class. In this way, directly contact the database class, and the content in the EDIT after the dialog box is directly transmitted to the field variable corresponding to the database, and then execute the updata () to execute the database class directly to the database. . Not like previous, first swap the update content to the bound member variable in dialog box updata (), and assign the value of this member variable to the field variable of the database class. The middle province went very cumbersome. The code code is as follows: ddx_text (pdx, idc_edit6, m_set-> m_yxsj); Notes 1: If there is a date field in the database. After the bind field variable, the member variable type corresponding to this date field is changed from CTIME to cString, otherwise this field cannot be transferred to the EDIT in the dialog data exchange. Note 2: The class wizard does not support such an alternative, so when you do the above modified, open the class wizard. Will ask you to delete these errors. At this point, if you want to use a parsive, you can teamed the binding part to cut off, and then paste it back after taking the class wandering. Note 3: Because the binding member variables are brought to the field variables bonded in the data category, DDX is called when dialog box or view is created and exited. So instantiate the binding data category before and afterwards, otherwise it will cause remarkable memory access. So, it is best to use the New and Delete data categories in the constructor and destructuring functions of the view or dialog. I have written a bunch of mess, I don't know how many people can understand. Have time to modify it
