AFX_DATA_MAP - why is the DDX routine outside of the map

i simply added a combo box using visual studio C++.  why is it putting it ouside the AFX data map?  this is really disturbing.

void CDlgOrder::DoDataExchange(CDataExchange* pDX)

      // Primary Id
      DDX_Text(pDX, IDC_EDIT_ID, m_id);

      // Contract description fields
      DDX_Text(pDX, IDC_EDIT_CONID, m_conId);
      DDX_Text(pDX, IDC_EDIT_SYMBOL, m_symbol);

        <<custom code here>>

      //why was this added outside the data map?
      DDX_Control(pDX, IDC_COMBO2, m_strategy);
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

When Class Wizard add controls, it uses this AFX_DATA_MAP section.
That's all. It's okay, that your DDX_Control is out of that section.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
supportorangesAuthor Commented:
Thank you.  I can't remember too much about Class Wizard.  Are you saying the previous programmer explicitly used class wizard when creating the CDialog box derived class via the Dialog editor and that's why his got into the AFX_DATA_MAP and my combo box didn't?
the //{{AFX_DATA_MAP(CDlgOrder) is only a comment same as  //}}AFX_DATA_MAP. however, these comments allow visual studio to colour the code differently such that you easier can recognize wizard generated code parts. but, the compiler does not evaluate the comments, what means that statements within the comments were handled not differently to statements outside.

i assume you added the combobox later and that's why it was it was added at end of the function such that custom code would be performed first and new code later.

for your information: the DoDataExchange can do 3 things. first, it initially can assign a control to the dialog and subclass it. subclassing controls means that the mfc can dispatch messages and notifications to the right class which also could be a derived class. second is that it could transfer data from a member variable you associated to a control to the dialog (screen). and third it could get data from screen and move it to member variable.


Learn SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

supportorangesAuthor Commented:
So if I would have added the variable via ClassWizard, it would have made it into the map?
i don't know exactly. i checked some DoDataEchange functions in my current project and it looks more that added members generally were moved at end. probably to not change any order if the developer has added custom code to the function. but you could move the statement within the "map" if you like better.

supportorangesAuthor Commented:
Thank you everyone for clarifying this and reminding me about class wizard!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Editors IDEs

From novice to tech pro — start learning today.