I would have thought asking a question like that somewhat pointless as it does not contribute to the forum but to answer:
Thanks for your opinion
If you are NOT concerned with building an elegant solution or if you do not deliver to a set quality standard then it does not matter.
If you take a look at hundreds of other apps in the world, open a document, save it, save button greys out, add a space, delete that space (effectively back to start) but save isn't greyed out!
Weird eh?
No.. You see, performing 2 actions to get back to where you started is subtly different to performing one action then undoing it. If you don't believe me, take your ATM card that can withdraw $1000 a day and withdraw $1000 with it, then walk straight into the bank and pay the cash back in. Now try and withdraw again..
If it did not matter for the application I am working on then I would not have posted asking for assistance to deliver those requirements.
You'd be amazed at the number of people we see asking for help with their problem of a broken solution (i.e. what they envisaged to solve the problem, and cannot make it work) versus solving the original problem. First step: establish if there is a problem to solve
It does matter because:
The Quality Standard defined requires the 'Save' button to be active if there are changes on the form that need to be saved.
Change is defined as data that is different to the currently saved data. i.e. where any column in any row has different data to that data that was originally presented when the form opened. This includes additional rows or deleted rows.
Ading a row and then deleting it delivers data that is identical to the previously saved data and consequently the 'Save' button is required to not be enabled because of that change. Likewise, changing a column in an existing row and then changing it back also is a net zero change and no Save button.
I had a similar requirement once, and the amount of time and effort required to add it, relative to the actual worth it added to the application was deemed minimal enough for the feature requirement to be dropped, and I was reassigned more important work
Ergo, I asked if it really mattered..
Up to that point, the only way I had of really detecting if there were any worthwhile changes was to scan every row of the GetChanges() return result, to see if the original vs the Current RowVersions had any difference. This was done at form closing time with a "Changes exist. Save before closing? Yes No Cancel" query.. You may find that making such an inspection on a more frequent basis to determine whether to enable or disable a button has a deleterious effect on performance.
The most irritating aspect I found was that something that initially looked like it would suffice (DataSet.HasChanges) became true for even inane read-only things like navigating through the records on the form..
It's grand that youre sticking to spec etc, but you can implement a system following a Quality Standard to the letter and still end up with a system that has poor usability, does things that the users don't even find helpful, useful or notice at all and is over-budget.