We would like a new SetDirtyOnAdd property that works just like the SetDirtyOnEdit property for business objects.  If a user clicks to add a record and never actually enters any data, when they close the screen we don't want to show the save changes confirmation message.  Is this possible?

Well, a record has to be added so that the business object knows to INSERT it into the database.  If you add the new record and then save the changes, you would then have to know to set the record back to Added rather than Modified.  So, I'm not sure.  That's what the ICancelAddNew interface is for on the BusinessBindingSource, but that's really only used by grids.

Is there something else I can look at on the BO to determine if the current row is truly dirty? I don't want to ask the user to save changes on exiting a form if they have not changed anything. The IsDirtyOnEdit property works great for editing, but I need to do the same type of thing for adding.

Why can't you just look at the row state?  This will tell you what is going on with the current row.

The row state is 'Add' regardless of whether or not the user enters anything. It becomes add as soon as I execute an .Add() on the BO.

So what is your criteria to determine if a record is "truly dirty?"  Are you trying to determine if they typed in anything at all?  In that case you will have to enumerate the fields to see if anything has been modified....or turn of the AutoSaveChagnesMessage and handle this yourself.

Yes, I want to know if they user actually typed in anything. Just like on an edit when 'SetDirtyOnEdit' is false, dirty does not become true until the user changes something. I was trying to avoid the brute force method of looping over all the fields.

This is obviously much more difficult since you are truly adding a new record to the data table within the BO.  Without looping ADO.NET has no way of telling nor does the BO since we rely on the ADO.NET row to tell us the state.

Editing is entirely different because a row already exists, so it is just a matter of not setting the row state to anything and just letting nature take it's course.  When adding a new row, you have to have something to put values into ... so you HAVE to create a new row.

The only two options I see for you is to either write a method to loop....or drop on a second BO which all of the fields are bound to.  Then use a second BO as your "permanent" BO which has the data from the editing BO copied into it using the CopyDataFrom method on the BO in the BeforeSave or AfterSave and where you feel you need to make the transition.  This will require more work but would allow you to have the "clean" row.  In any case, you are going to have to create this logic yourself as the BOs and ADO.NET do not have a method to do this natively.

This is where Foxpro's getfldstate() -function would come VERY handy, as it shows the add -status as well as the buffer status.  Would be nice if the framework would provide this at some point or another.  It really is a nit, but customers can be real nit-picky about this kind of stuff -- they want as speedy of a UI experience as possible with as few alerts as (safely) possible.  This is one of those.

Pertti

As mentioned above, if you have this need you can implement it yourself.  The GetFldState is replaced in ADO.NET by looking at the version of the field, which you can do just like you did in FoxPro.  All fields in ADO.NET have a buffer, this is how concurrency works.