Scott,

That code looks fine. The framework only stores nRecNo when the add is successful. From what you're describing, I'm wondering if it's possible that the first record isn't really saved. Then, when you cancel the second addition attempt, the framework tries to access the first, and you get that error.

Remember, too, issuing BROWSE on a row-buffered view will commit its changes, which may explain why you aren't seeing this when debugging. Always check field values in the debugger instead.

I would check to be sure that the first record is really saved, and what the resulting nRecNo value is -- both for the first record, as well as subsequent attempts.

Hope that helps,
---J

>Hello Jason,
>
>Oh, yeah, I checked the code on the controls UMMPPteen times now. That all looks good. It appears that the kcustctl.clistobjedit.cmdadd.click code tests to see if you cancelled or actually added a record. If you add a record, it updates the grids nrecno property. However, if you cancel the add, the framework code tries to move to the record pointer for the added record that you just cancelled! This may be a bug, I'm not sure? I can't seem to locate code in the framework that resets the nrecno? I could change the framework to test to make sure the record number actually exists in the view before attempting to move the pointer, but I don't like changing framework code...no, no, no. Anywhere, here's the code in case you see something obvious that I'm missing:

*snip*