Yes, there is definately a mix between the bAddNew flag and the bAddNewImmediate flag, which seems to throw things a bit. I am not convinced that the current system of flags works correctly - and my 'FIX' does seem to upset this delicate balance. A new 'FIX' is shown below, but first..
------- About the 'bAddNew...' flags-------
Basically, the AddNew status should be reset whenever an updateRecord, cancelUpdate or anything that refreshes the recordset occurs. I note that the current code will set the
bAddNewImmediate flag to
false in most of these strategic places - and I am tempted to believe that the logic of these flags is as follows:
If you perform an AddRecord, it clears the 'field' collection and sets the bAddNew flag. When you try to 'get' a field value, it will now return nothing (due to the
this.fields._newRecord = true;). If you perform a server round-trip, then most of these flags are NOT reset.
At this point the recordset is actually still positioned on an existing row - it is only the bAddNew flag that is set.
If (as is usual) the user fills in the fields and clicks a button - causing a server round trip - then the following happens during page initialisation on the server:
establish the 'bAddNew
Immediate' status given the bAddNew status.
Re-construct the recordset (but still no 'new record' - its still just a flag)
(If ANOTHER server round trip occurs, then the 'bAddNewImmediate' flag becomes false - and your NewRecord status is now lost forever! So if you have a click event on a drop-down list (for example) that causes a server round trip to gather new info - then the Add status be lost)
When an updateRecord is executed now, it detects the 'bAddNewImmediate' flag (NOT the bAddNew) and creates the 'new row' (this._rsADO.AddNew()

before feeding in the values of the text boxes etc..
Therefore, the updateRecord MUST occur AFTER a SINGLE server round trip for the thing to work!!!
Without the 'Fix' the bAddNewImmediate flag seems to get reset easily - but WITH the Fix there isn't anything to turn OFF the New state (as you noticed... - though you could manually set the _bAddNew flag to false after an updateRecord if you wish).
-------------- NEW IMPROVED FIX!!---------------
So UNDO the earlier 'fix' and try this instead...
function _RS__preserveState()
{
if (this.maintainState)
{ // preserve state in hidden field
var bState = false;
var state = new Object;
if (this._bAddNew
|| this._bAddNewImmediate)
{
bState = true;
state._addNew = true;
} ...etc...
This will preserve the 'New' state on round-trips UNTIL an update or cancel resets it.
ALSO
function _RS_addRecord()
{
//bFir...
if (this._allowUpdate && this.isOpen() && !this._bFiringOnBeforeUpdate)
{
this._bAddNewImmediate = false;
@if (@trace_events)
thisPage._traceEvent(this.name,RS_ONROWEXIT);
@end
this._objEventManager.fireEvent(RS_ONROWEXIT);
// set flag to indicate new record for subsequent update
this._bAddNew = true;
this._bAddNewImmediate = true; //ADD THIS LINE
I am also sure that it would be a good idea to set the
fields._newRecord flag following the OPEN in the _restoreState method, or within the _open method. And also, the AddNew flags really should be turned off if you requery or change the recordset, which it currently does not.. Still, see what happens first!
If this works then post a note! (I don't have time to test this at the moment.)
If it does, then then bAddNew flag could be removed all together as it now serves no useful purpose.
Good Luck!