FoxPro/Visual FoxPro - FORMULARIOS GENERADOS

Hola, amigos!
Cuando mi proyecto usa FORMULARIOS GENERADOS y luego lo abro en otra máquina para seguir programándolo, me pide encontrar las bibliotecas de clases las cuales no instalé manualmente. Creo que al seguir el programa, tendré problemas cuando realice el SETUP (Instalador). Existe alguna manera para solventar este problema y evitar que el programa de SETUP (instalador) no me falle con los formularios generados? Gracias.

Tal vez quieras explicar algunas cosas:
1) A qué llamas "Formularios generados"
2) Cuando abres el proyecto "en otra máquina" cómo lo haces: Mudas todo el proyecto, usas dropbox (o similar), es una LAN, escritorio remoto (o similar)?
3) Las clases a que te refieres son tuyas, son de terceros ?
Si puedes poner un ejemplo, mejor.

Gracias, amigo Fidel Jose! Te has convertido en mi paño de lágrimas. El problema es el siguiente:
En vista de que no tengo tanto conocimiento en FoxPro, he tenido que generar unos tres formularios con el generador automático de Visual FoxPro. No me gusta este generador, pero hay algunas cosas que no he podido resolver, tal vez puedas ayudarme y así creo los formularios en conflicto por mi propio medio:

Es un formulario con TABLAS RELACIONADAS. La principal lleva una GRID y campos para mostrar los registros seleccionados en la GRID1 -> Cada vez que paso de un código a otro, Me muestra la información de los registros de la TABLA SECUNDARIA. Eso me funciona a media. El problema es que cuando incorporo registro en la TABLA SECUNDARIA se disloca, cosa que no sucede cuando yo uso el GENERADOR AUTOMATICA DE FORMULARIOS DE VISUAL FOXPRO.

Además de estos, necesito que cada vez que incorporo un registro a una tabla secundaria correspondiente al CODIGO DEL SOCIO SELECCIONADO, me muestre el número del registro se le ha hecho al a cada SOCIO.

Te agradecería cualquier ayuda.

Eusebio
No sé exactamente cómo es tu necesidad pero no parece algo demasiado complicado.
1) No uses el generador de formularios ni otros Wizard por el estilo. No aprenderás nada con ello.
2) Si tienes dos tablas con una relación de uno a varios te paso un ejemplo al voleo.

Para estudiar este ejempo crea un formulario en blanco, al que solamente le agregas un método llamado "getcuotas" con el código que te digo más abajo y colocas en el Init del Form, el código de Init que transcribo.

En la práctica, puedes agregar dos controles grid en forma manual y el código de "GetCuotas" colocarlo en el método AfterRowColChange del grid principal. En ese caso, no utilizas BINDEVENT().

La estrategia para el grid secundario, no pasa por usar las relaciones en forma directa, sino por lo siguiente:
1) Crear un cursor vacío que tenga la estructura del cursor o tabla que se quiere mostrar en el grid2
2) Buscar los datos en la tabla secundaria, y colocarlos en un cursor de paso
3) Limpiar el cursor vacío (porque estará vacío la primera vez solamente) y agregar por Append From los datos del cursor de paso.
4) Refresh para el grid secundario.

Con este modelo, te aseguras que tu grid secundario mantenga la configuración original (que la construyes sobre el cursor vacío).


No te embrolles mucho con el BindEvent. Recuerda que puedes obviarlo si agregas los grid en forma manual al formulario y escribes el código de GetCuotas en el AfterRowColChange del grdSocios.

Busca en la ayuda todos los comandos y funciones que no conozcas y trata de fundamentar su uso.

Hola, amigo FIDEL JOSE!
Gracias por esa pronta respuesta que me enviaste. Estuve analizando el código y si funciona, pero no pude colocar el código en los botones para poder incorporar un REGISTRO A LA VEZ, y por supuesto GUARDARLO con la descripción que me enviaste. Incorporé los grids manualmente y funciona, pero es la misma forma del código enviado. Tal vez te he estado molestando mucho pero, en verdad lo necesito. Todo en el formulario trabaja bien menos la tabla secundaria.

Puntos que necesito:

El nombre de la tabla primaria es: SOCIOS, y el de la secundaria: dbPagos_soc.

1) Al pulsar el botón AGREGAR me active los TEXTBOXs y desactive los botones (ahí no ha problemas).
2) Una vez llenados los TEXTBOXs se realiza la inserción de los TEXTBOXs a la tabla.
3) Se debe llevar un número de cada registro para así poder entregar un recibo (comprobante).
4) En caso de que se decida CANCELAR ese registro, pulsar el botón CANCELAR para anularlo.
5) Puedo eliminar el registro de seleccionado de la tabla "dbPagos_soc" (tabla secundaria).

Si notas que es necesario hacer algún cambio en este formulario, te pediría me lo hagas saber.

Ahí te envío una toma del formulario en cuestión. Te agradezco cualquier ayuda, a parte de las otras que me ha mandado. Gracias de nuevo por todo.

Eusebio
Lo que tienes que hacer es mejorar tu diseño de flujo, más allá de cómo armes el formulario. Normalmente hablamos de ABM (altas, bajas, modificaciones) que es lo que determina de alguna forma el movimiento de datos. Sobre eso se arma la interfaz, que es nada más la forma de mostrar y permitir acciones al usuario.
En mi manera de ver, estás mezclando dos (o más) problemas que deben tratarse en forma independiente:
1) Definir el modo de generar los abonos (devengamiento de cuotas de socios)
2) Definir el modo de registrar la cobranza de los abonos (pago de las cuotas (abonos) de socios)
3) Definir si los abonos se pueden modificar o eliminar y con qué condiciones
4) Definir la forma de mostrar la situación de un socio
5) Definir la forma de mostrar la situación de abonos emitidos / abonos cobrados (o abonos impagos)
6) Definir los historiales, estadísticas y otros informes que resulten necesarios

Si quieres hacer todo junto, vas a estar en problemas. El planteo que haces inicialmente, se corresponde solamente con el punto 4).
La generación de los abonos es un proceso que se corre, generalmente, una vez al mes. Pero puede tratarse de un caso donde haya que emitir abonos de otra forma. De todos modos, obliga a un procedimiento especial.
La cobranza de los abonos, debe tratarse como lo que es: un proceso circunstancial. Puede ocurrir o no. Cuando ocurre, te conviene tener un formulario aparte, donde tratas el tema del pago: fecha, cobrador, caja, asignación contable, cancelación del abono, etc. Con esto modificas las tablas necesarias y regeneras la consulta para tu formulario principal, de modo que te quede actualizado. Fijate que si: el grid de la izquierda (socios) tiene su código de busqueda lanzado desde AfterRowColChange y además es AllowCellSelection=.T. (default), solo necesitas enviar el foco (thisform.grdSocios.SetFocus) cuando grabas cualquier modificación. Si el formulario de cobranza es modal, lo puedes colocar exactamente después de la convocatoria a ese form. Si el form de cobranza es modeless, puedes pasar como parámetro la referencia de objeto del formulario y en el botón de grabar del form secundario, usas esa referencia (previamente convertida en propiedad del form en el init del secundario) para hacer dirigir el foco al control grid o lanzar directamente el nuevo SELECT si lo tienes en un método del formulario.

1) A los grids que muestras, por favor, configúralos como DeleteMark=.F. Esa columnita negra a la izquierda es horrible y además no debes permitir que cualquer juguetón te quiera borrar los registros.

2) Salvo en alguna circunstancia especial, utilizo los controles grids con Set("Readonly",.T.,"Column") para no permitir ninguna modificación directa en la cuadrícula. Para Agregar, Modificiar, es mejor crear un formulario que haga la tarea con todas las validaciones necesarias y la obvia posibilidad de cancelar el procedimiento. Para Borrar, es mejor tener siempre una consulta, después que el proceso de borrado se haya autorizado (condición de clave, nivel de usuario, fecha, bloqueos de procesos, etc.)

3) Separa los procesos. Separa los procesos. Separa los procesos. Dividir para reinar!
Fijate que hay rutinas que pueden ser empleadas por dos, tres, todos los formularios y procedimientos. Para ello puedes utilizar un prg o una clase custom, como más te guste, pero la idea es escribir estas rutinas correctamente solo una vez y que todos los elementos recurran a ella.

Te recomiendo la atenta lectura de estos artículos de Fernando D. Bozzo (uno de los mejores programadores de Visual Fox que conozco)

http://fdbozzo.blogspot.com.es/2014/01/crear-un-proyecto-foxpro-por-donde.html
[url]fdbozzo.blogspot.com.es/2014/09/vfp-guia-de-buenas-practicas-de.html[/url]
http://fdbozzo.blogspot.com.es/2014/01/desmitificando-el-control-de-errores.html
http://fdbozzo.blogspot.com.ar/2014/10/vfp-la-interfaz-las-reglas-de-negocio-y.html

También te dejo la dirección del blog de comunidadvfp, que es donde Luis María Guayán está subiendo los artículos más importantes que se publicaron en PortalFox (ya fuera de funcionamiento).
http://comunidadvfp.blogspot.com/

También te adjunto un excelente artículo de Daniel Díaz sobre Programacion Orientada a Objetos.

• Visual_FoxPro_y_Programacion_Orientada_a_Objetos.zip(35,4 KB)

Hola, Fidel Jose!
Gracias de nuevo por este tremendo aporte. Pude resolver el problema dividiendo el formulario y creando un formulario de consulta. Con estos enlaces que me enviaste, me he detenido un tanto y estoy analizando una gran cantidad de códigos que en realidad lo necesitaba. Gracias por todos.