Hi Mike,

I've been away for a week so just now getting back to this.

Stepped through the code and yes the tablerevert works. What happens though is that before the tablerevert the code pushes the current recno and then pops it after the tablerevert. But since the pop code cannot find the original record (the appended one), the code instead forces an EOF condition. Here is snippets of the code

* from RevertBuffers()

IF AUSED(laWorkAreas) > 0
  LOCAL lnHowMany, lcAlias
  FOR lnHowMany = 1 TO ALEN(laWorkAreas, 1)
    lcAlias = laWorkAreas[m.lnHowMany, 1]
    * TABLEREVERT() only works with buffered cursors: 
    IF      (CURSORGETPROP('Buffering', m.lcAlias) > 1)	;
        AND  ThisForm.IsBufferDirty(m.lcAlias)
      loRecNo = CREATEOBJECT('cusPushPopRecno', m.lcAlias)   && push
      TABLEREVERT(.T., m.lcAlias)
      RELEASE loRecNo   && pop
    ENDIF && this alias is buffered
  ENDFOR
ENDIF && there are open tables/views

* (push code...below results in .inSaveRecNo being -1 as appended record)

WITH This
 .inSaveRecNo = IIF(EOF(.icSaveAlias), 0, RECNO(.icSaveAlias))

* (pop code...a GOTO is tried but it fails)

WITH This
  TRY
    GOTO RECORD (.inSaveRecNo) IN (.icSaveAlias)
  CATCH
    llSuccess = .F.
  ENDTRY

* (and so later in code, if m.llSuccess = .F., it goes to bottom and skips leaving at EOF()

 IF (NOT m.llSuccess) AND (NOT EOF(.icSaveAlias))
    GOTO BOTTOM IN (.icSaveAlias)
    IF NOT EOF(.icSaveAlias)
      SKIP 1 IN (.icSaveAlias)
    ENDIF
  ENDIF

So either I live with it (fairly rare condition). Before I understood what was going on, I was just forcing the form back to page 1 to and since the record on .icMainAlias is pushed/popped, nothing looked too amiss (other than the form jumping to the first page). So either I keep that code or I augment the .CancelAfterSuccess() to do a LOCATE to get back on the original record (because in these forms, there is only ever 1 record in .icMainViewAlias). Or I mess with doing my own push/pop of the original record in .icMainViewAlias which I really do not want to do.

I can't see VMP fixing this as a "bug" as this was the desired behaviour (I guess, the code does not make comments).

Thanks,

Albert

(p.s. to answer your original question, yes, .icMainViewAlias is set correctly).

>Hi Albert
>
>The new record is supposed to be appended to the view. Cancel should be tablereverting the view - back to the previous record. Have you set the icMainViewAlias on the form correctly?
>
>>To those of you who still run VMP, can you confirm this action? It is set up as follows:
>>
>>- uses frmDEgrdNav2Pages
>>- uses a table on the Nav grid
>>- uses a view for the 2nd page for data entry (.icMainViewAlias)
>>
>>Steps to reproduce:
>>
>>1) navigate to a record (not necessary but easier to see)
>>
>>2) Add a new record; enter some stuff. Focus should be on the view page (usually page 2)
>>
>>3) Cancel the add
>>
>>Result: I had not noticed this before - I am left with all disabled, blank fields; reason being is that the view's new record has been deleted because the Add was cancelled and this leaves the record pointer at EOF for the view and thus VMP code must disable everything.
>>
>>Workaround (which I don't like), in .CancelAfterSuccess(), if pcMode = "ADD", force the active page back to Page 1 (the Nav grid) because then if you go back to Page 2 or nav in the grid, the view gets refreshed properly.
>>
>>I would have thought that the view would have popped back to the previous record (and maybe I need to track that down instead).
>>
>>Thanks,
>>Albert