>>>>I'm creating a set of classes to handle data:
>>>>
>>>>

>>>>class CompanyInfo : DataRecordBase
>>>>{
>>>>    private string _CompanyName = "";
>>>>    public string CompanyName
>>>>    {
>>>>        get { return _CompanyName; }
>>>>        set { _CompanyName = value; }
>>>>    }
>>>>
>>>>    public override bool SaveChanges()
>>>>    {
>>>>      if(Validate())
>>>>      {
>>>>         // Code here to save
>>>>      }
>>>>    }
>>>>    public override void Load()
>>>>    {
>>>>    }
>>>>
>>>>    private bool Validate()
>>>>    {
>>>>        bool bRetVal = true;
>>>>
>>>>        if (_CompanyName == "")
>>>>        {
>>>>        }
>>>>
>>>>        return bRetVal;
>>>>    }
>>>>}
>>>>

>>>>
>>>>They are all based off the abstract class DataRecordBase. The question is this - If the Validate method returns false, because a property is not complete, what should happen? I don't want to raise an exception?
>>>>
>>>>Since this is a non-visual class I don't want to pop up a message in this class. I'm thinking that Validate should set a class variable to an appropriate message, and maybe set a public IsValid flag to false.
>>>>
>>>>Then, in the form or class that uses it, if SaveChanges returns False then I know that the message property would be populated with something like "The Customer Name cannot be empty".
>>>
>>>I'm never in favour of public variables. You could use an out parameter to pass back the error message (or even an array of error messages) so something like:

>>>        public bool SaveChanges(out string msg)
>>>        {
>>>            if (!Validate())
>>>            {
>>>                msg = "This went wrong";
>>>                return false;
>>>            }
>>>            else return true; 
>>>        }

Called with

string str;
>>>            if (!CompanyInfoInstance.SaveChanges(out str))
>>>            {
>>>                MessageBox.Show(str);
>>>            }

BTW, if this is WinForms have you thought of using the ErrorProvider class in the UI?
>>>Regards,
>>>Viv
>>
>>I guess I could, but this class just represents a data record. It's not visual. That's why I thought a property defined in the base would work.
>
>But surely the error has to be surfaced in a visual way eventually - and the UI layer is the obvious (possibly only sensible) place for that?

Yes, but this class and those like it are not UI components. They are a data record represented in a class. So when an issues/exception occurs, how do you inform the UI?