Cetin and Josh,

Thanks for all the proposed solutions; the problem wasn't related to them (I think), but I'm confused now about why the way I fixed it worked. Basically I was able to determine that a variable used in a scan to force a return to the proper record was not incrementing. The variable was set to RecNo('ViewName') and when it was set to just RecNo() it worked fine. I'm not sure why explicitly stating the view would be different than not stating it, but it was. And, this problem ONLY occurs when calling the processing from a textbox on the associated grid (no relations, no filters other than intitially creating the view from SQL server). Calling from a checkbox or dropdown worked fine. Also, the checkbox and dropdowns seem to move the pointer on the grid, but not when from a textbox. Again, the problem was resolved when not explicitly stating the view in the RecNo() function. I'm happy that it works now, but confused.

Any ideas?

...and thanks for the comment on the company name, Josh - now let's hope I'm not sued by NBC... :-)

Regards, Renoir

>>This is an odd one... When entering values into a textbox in a grid our processing seems to get into an endless loop. This only happens in two specific columns (only one entry object per column) and only when the number of displayed records is past the bottom of the grid. If ESC is hit and then Ignore, the processing continues like normal. If there are no records past the bottom of the grid, the processing is normal. We're getting close to releasing for production and this has us stumped (and stopped). Thanks in advance for any suggestions or comments.
>>
>>Regards, Renoir
>Hi Renoir,
>Count of displayed records affect the performance of grid for dynamic* properties are reevaluated for visible portion. But it's nearly unmeasurable delay. What you say is never normal for a grid.
>-Do you have a set filter ?
>-Any calculation done in between (ie: valid of a field resum the column and show column total)
>-Lockscreen on/off in between ?
>-Worst case - is activerow used as a controlsource (ie: to show the line no of child rec) (This one is the best candidate for causing long delays to my experience).
>
>If filter is used, better use relation or a filtered index (or views though harder at first). Set filter is sloooow no matter how ideally you have your indexes. An alternative is to use a temporary cursor and update original table as appropriate.
>
>If calculation is done, use a better algorithm and just use changed data for recalculation and only for fields that affect calculation (ie: if sumcolumn do not do sum in afterrowcolchange -if field check is not done-, but lostfocus of txtbox in column, do not sum whole column per child record change just add delta value to sum, do whole column sum for only parent rec change).
>
>If lockscreen is used try to find best place for it.
>
>Never use activerow as a controlsource (or part of).
>Cetin