FoxPro/Visual FoxPro - Problema con registro eliminado de un cursor

Buenas a todos, de nuevo vengo con un problema que me trae de cabeza.

Estoy en un grid editable el cual se rellena con datos de un cursor, al dar a insertar registro se crea un registro nuevo y se pueden introducir datos como referencia, unidades, precio, etc... mientras vaya metiendo registros no hay problemas, al pulsar la tecla escape tengo puesto que se ponga el grid como no editable, se elimine la última linea y suba al registro anterior.
Tengo cargado los set para que no visualicen los borrados.

Parece que funciona salvo que si pulso al final cursor abajo me aparece el registro eliminado no me lo oculta y si pulso retroceso de pagina una vez q estoy en el inicio me lo oculta del todo.
He probado a realizar el grid en un formulario con lo imprescindible y me funciona, pero con todo lo que tengo cargado no y ya no se por donde meterle mano.

El código es el siguiente dentro del evento Keypress:


CASE thisform.donde = "linea"
**** Vaciar los campos
SELECT detalle
GOTO BOTTOM
DELETE
KEYBOARD '{UPARROW}'
thisform.pageEntSal.page1.grdEntySal.AllowCellSelection = .F.


Gracias de antemano por la ayuda.

El problema es que el Grid, con respecto a su actualización, no se comporta exactamente del mismo modo si AllowCellSelection = .T. y su opuesto.
Yo observo tres cosas, al margen del detalle comentado:
1) Conviene analizar qué registros no son aceptables para borrarlos y no borrar el que resulta de GO BOTTOM. Si utilizas un índice sobre el cursor, GO BOTTOM puede rematar en cualquiera que no esté vacío.
2) Este KEYBOARD {} resulta un artilugio innecesario.
Para el mismo caso, si SET DELETED ON
SELECT detalle
GOTO BOTTOM
DELETE
GO TOP && También podría utilizarse SKIP - 1, pero tenés que comprobar que quede algún registro.
GO BOTTOM
This....Grid.REfresh


3) Tal vez usas AllowCellSelection = .F. porque quieres obtener algún efecto especial.
Fuera de este cambio de aspecto en el cursor, lo que correspondería hacer es poner todas las columnas en READONLY = .T.
This....Grid.Setall("Readonly",.T.,"Column")
Esto último tiene la ventaja de que no cambia el comportamiento de AfterRowColChange y te permite continuar utilizando las celdas como tales, por ejemplo para copiar datos, hacer sumas parciales de determinadas columnas y otros chiches que se le pueden agregar a un control grid.

Por último, el Refresh del grid es, en algunos casos, sobreabundante. Pero resulta necesario tanto cuando se agregan registros como cuando se quitan registros del cursor.

Buenas tardes desde aquí y gracias por contestar tan rápido Fidel, creo que ya me has ayudado en otras ocasiones y te lo agradezco al igual que a todos los compañeros.

He estado probando muchas veces refrescando el grid por muchos sitios y nada...... no funcionaba hasta que se me ha ocurrido poner el refresco en el movimiento de filas Afterrowcolchange, y parece que de momento va.......

Sigo probando y comentando

Gracias.

Antonio
Para simplificar, necesitamos entender que un control grid es un BROWSE bastante sofisticado.

La norma general es trabajar con el cursor asociado (grid.recordsource) con los comandos habituales para trabajar con tablas o cursores.
El Grid.Refresh, debe ocurrir cuando se cambia algo en el cursor asociado y se necesita que ese cambio se refleje en el Control Grid. La función del REfresh ese actualizar los ControlSource del objeto que se ataca. Y eso es lo que lia cada columna del grid a su origen de datos (el cursor asociado).

No vale la pena colocar un This.Refresh en el AfterRowColChange salvo que estés metiendo cambios en el cursor en ese evento, lo que no es, en principio aconsejable.

Para trabajar directamente sobre un control Grid, debes tener en cuenta que el cursor se actualiza cuando se produce el lostfocus del objeto que estás actualizando. Si colocas algún código en el objeto (text1, check1, etc) dentro del objeto las referencias deben ser This.value y no el valor del campo del cursor, que es el valor anterior.
Y también debes tener en cuenta que cualquier movimiento (flechas, mouse) puede disparar el Valid y el LostFocus, dejando un campo a medio llenar, o con valores absurdos.
Si se mueve el cursor del grid hacia otra columna o hacia otra fila, se dispara AfterRowColChange.

Para atacar directamente la interfaz del grid, tienes dos recursos:
1) Hacer una clase Textbox o la que se necesite para reemplazar el currentcontrol por defecto (text1, check1, etc) (recomendado)
2) Si tenés VFP8 o VFP9, podés utilizar BINDEVENT(). En ese caso, el objeto del grid atacado (text1, check1, etc) se identifican por referencia de objeto a traves de Aevents().
Podés utilizar ambas soluciones porque no son incompatibles, siempre que cada una tenga una responsabilidad precisa.

Por otra parte, para mí es necesario preguntarme cada vez, si realmente es necesario que el usuario trabaje sobre el grid o si es mejor crear un formulario con toda la entrada de datos y agregarlo al cursor cuando ya esté todo validado.
Para esto se pueden utilizar, al menos, dos caminos:
1) Crear un cursor paralelo de actualizción
SELECT * FROM (THISFORM.GRID.RECORDSOURCE) WHERE .F. INTO CURSOR curActualiza READWRITE
SELECT curActualiza
Append Blank
2) Crear un objeto que contenga todos los campos del cursor y pasarlo como referencia de objeto al formulario de actualización
LOCAL LoObj as OBJECT
loObj = NEWOBJECT("Empty")
SELECT (thisform.grid.REcordSource)
SCATTER MEMO BLANK NAME loObj
Ahí tienes creado un objeto cuyas propiedades son los nombres de los campos y la cláusula BLANK hace que tengan su correspondiente valor vacío.

En cualquiera de ambos casos puedes utilizar, en el formulario de actualización, ControlSource o asignar por Value. Depende un poco del caso, del gusto y de la comodidad de cada uno. En la mayoría de los casos prefiero liar por ControlSource, pero en algunos casos se necesita que no sea así.