Peter,

This is just a WAG but, after the TABLEREVERT(.F.) put GO RECNO(0). HTH

>>Hi Peter,
>>
>>Not sure what the problem is here. However, have you considered using a combobox in column1 instead of a textbox? This way the user can only pick valid invoice numbers.
>>
>>>IF NOT SEEK(THIS.VALUE,"Invoice","Invoice_no")
>>> TABLEREVERT(.F.,"Payments")
>>>ENDIF
>>>
>>>This code is attached to the valid method of grdInvoice.Column1.Text1
>>>
>>>There are one or more rows above the active row.
>>>
>>>All rows in the grid show up empty, Payments table hits EOF, and no amount of GO TOP IN Payments followed by refreshing the grid or the entire form for that matter will show the data.
>>>
>>>Debugging does not get me anywhere, ´cause during debugging this does not happen.
>>>
>>>Am at my wits end, and any and all suggestions are appreciated.
>>>
>>>Regards
>>>
>>>Peter
>
>Done it, awfully slow at refreshing screen, dumped it.
>
>Let me restate the problem, hopefully more clearly.
>
>The object is to let the user enter payments, in full or partly, corresponding to an invoice number.
>
>Rather than being stuck, if (s)he enters a nonexisting number, I issue a TABLEREVERT(.F.), thus deleting the entire row.
>
>Works fine, except the whole grid goes blank. Nothing there.
>
>The data are there, except for the reverted record of course, but they dont show unless I deactivate/ activate or close and reopen the form.
>
>That´s the problem. In the meantime I´ve figured something out that works.
>
>A KEYBOARD "{UpArrow}" right after the TABLEREVERT seems to do the trick.
>
>Why it works is gods own private mystery, and I´d still like to hear of other solutions, ´cause I´m not really comfortable as long as I don´t know the reason why.
>
>I suspect it has something to do with the pesky thing losing track of the undelying data. Had a similar problem once, described below.
>
>My _basicgrid class for instance has
>
>LPARAMETERS nColIndex
>FOR i=1 TO THIS.COLUMNCOUNT
> THIS.COLUMNS(i).CONTROLSOURCE=THIS.COLUMNS(i).CONTROLSOURCE
>ENDFOR
>
>in the AfterRowColChange method. This is because otherwise it can not calculate
>correctly if you move from row to row.
>
>Microsoft has confirmed this to be a problem (at least to me) and I believe they have posted the above workaround in their knowledgebase.
>
>Only took about two weeks of pigheadedness to figure out.
>
>Regards
>
>Peter