views:

326

answers:

1

Hello

Can you please tell me your way or give me a reference to best dialog and property sheet validation best practices in MFC application?

I have my own way to do it but I'm interested in any other opinion.

I heard that MFC DDX_xxx and DDV_xxx macros (and UpdateData() function) are not the best solution?

What about property sheet validation?

+3  A: 

I like to use a variation of Model-View-Presenter. A good MFC-style illustration of this practice is "The Humble Dialog Box" by Michael Feathers.

Some principles:

  • Keep the view (dialog or property sheet in your case) as ignorant as possible. It should not contain actual business/validation logic. Rather, it should facilitate display of data to the user and manipulation of the data by the user. It should notify the presenter that things are happening but it should not "direct" the action in any sense.

  • The model is responsible for the shape of the data. In my models, each property is stored in a LimitedXXX struct. For example a LimitedString, has CString m_value, int m_maxLen, int m_minLen, and AllowedChars m_allowedChars. AllowedChars is a flag enum signifying whether integer numeric, decimal/group chars, alpha, punctuation, etc characters are allowed. The model has fields only, it dosen't contain any logic.

  • The presenter is responsible for transporting model values to and from the view and responding to notifications from the view. When the view raises a change notification for an edit control, the presenter responds by validating against the limits exposed by the model. The presenter can then take various actions depending if the value is valid or not. It might display a messagebox and restore the original value, it might push an error message into a notification area of the view, it might make an error icon visible in the view.

  • The components should refer to each other by interface rather than concrete class reference. This allows the model and presenter to be unit tested without UI. And the UI itself is thin and dumb enough that most of the risk is taken care of by testing the other two components.

Aidan Ryan