Another common situation for us is that the entry of one field will cause one or more other fields to change their value. Is having the business object sink its own FieldPropertyChanged event the best way to handle that?
Thanks for your help.
Fran Parker
MaxQ Technologies, Inc.
This kindof becomes a "sticky wicket" when you start trying to do this. The only way to prevent forward (or backward) navigation in a text box is in the validating event. You can prevent records from being saved, navigated, etc. But the only option .NET even provides in this arena is the validating event. If this type of entry can be avoided, then this is my recommendation. This is what we used to do in our medical system and this is where we got the most complaints. Our users despised it because they would either get stuck or they would keep clicking save and get another error no knowing where the end was. Sorry no great revelations here for you.
You can go either way here. Generally, standards indicate that if you are changing values on a form, you set the form controls. But if you are changing data, you change the BO field properties. But it really doesn't matter. If you change the field properties of the BO, you may need to call the Refresh of the BO to reflect the changes made to the data:
MyBO.Refresh("MyFieldName")