Sincronización rejillas en un formulario (con variables en el formulario)


([N4] spereira) #1

Buenas tardes, estoy probando en un formulario sin origen a cargar dos rejillas y que la segunda sincronice al seleccionar un registro en la primera rejilla.

 

El problema viene en el segundo proceso porque intento pasarle unas variables locales que declare en el formulario. Las variables estan rellenas (las veo en el formulario), pero al recalcular el control en el proceso de la segunda rejilla no soy capaz de pasarselas, lo intente creando un manejador de objeto y con get variable local, ¿se puede hacer como quiero yo? ¿lo hare con variables globales?.

 

Gracias.


([N1] Rafael) #2

Se pueden sincronizar rejillas, por supuesto, pero debes de hacerlo a través de una búsqueda. Esta busqueda contendrá componentes de búsqueda con las variables que desees. Luego sólo has de recalcular el control una vez asignada a la búsqueda los valores.

El panel de búsqueda el amigo Jorge Velasco peude aportate alguna luz:

http://www.theseedsc.com/blog/panel-de-busqueda/

 

Salu2

 

 


([N4] spereira) #3

Estube probando el ejemplo que me dices y no puedo hacerlo asi, ya que el formulario que uso es sin origen.

Los pasos que sigo:

* Formulario sin origen y le creo una variable local. 

* Tres rejillas.

* Un evento en el cual al seleccionar un registro de la primera rejilla rellena en la variable local del formulario (esto lo hace bien).

* El mismo evento recalcula las otras dos rejillas, estas se cargan con dos procesos, y en cada uno de los dos procesos intento leer la variable local del formulario, pero no puedo. ¿Se puede hacer esto? o uso variables globales.

El problema no es hacerlo (con variables globales funcionaria perfectamente), el asunto es si se puede hacer como digo yo porque quedaria mas limpio.

Un saludo.

 


([N1] Velasco) #4

Buenas.

Y si el evento que ejecuta dos procesos para recalcular
las rejillas ejecutase dos eventos? Así podrías acceder a las variables
locales del formulario y pasárselas a las búsquedas que refrescan las
otras dos rejillas.

O de otra manera, que no se si te funcionaria ;), si a
esos procesos que llamas desde el evento en vez de ejecutar proceso los
dispararas mediante manejadores de objetos les podrías pasar variables locales.

A ver si así te vale. Sino mándame un correo con el problema exacto y lo vemos.

Un
saludo.

 

 


Jorge Velasco Fernández

jvelasco@theseedsc.com

www.theseedsc.com


([N4] spereira) #5

Al final lo he comentado con soporte y me han aconsejado usar variables globales como tenia pensado hacerlo, y funciona de vicio (el tema de conexiones a eventos, eventos, etc. me esta gustando bastante).

 

Un saludo a todos.


([N1] aztecmexico) #6

Buen día a todos, Spereira, tengo un caso bastante similar, un formulario sin origen con dos rejillas, pero ando un poco perdido respecto a la manera en que "cacho" el valor del registro seleccionado en la primer rejilla, y al leer tu post encuentro lo siguiente:


Un evento en el cual al seleccionar un registro de la primera rejilla rellena en la variable local del formulario (esto lo hace bien).

Si fueran tan amable de indicarme de qué manera lo haces -o lo hacen los demás miembros del foro- ya que no logro cachar esa parte.

Un saludo.

Martin Ibarra.


([N4] eic) #7

Hola.

Hablando de memoria (o sea, puede que me equivoque en algún paso):

- Usas una conexión de evento en el formulario sin origen, para el control vista de datos - rejilla 1, con la señal Item: simple click, y haces que ejecute un evento del formulario
- En ese evento, mediante Interfaz: procesar control (Seleccionados), tendrás los elementos seleccionados en el control vista de datos (normalmente, será uno). Después, vas con Leer ficha por posición 1, y ya estás en el elemento seleccionado en la rejilla.

Saludos,

Fran Varona


([N1] aztecmexico) #8

Muchas gracias Fran, exactamente como mencionas.

Pero ahora tengo un pequeño problema que intentaré resumir.

Si en la conexión de evento selecciono Item: simple click, la segunda rejilla se sincroniza perfecto pero solo al utilizar el mouse, si utilizo las flechas no sincroniza -se entiende perfecto este comportamiento-.

Si en la conexión de evento cambio el Item: simple click por Item:cambio de seleccionado funciona perfecto si utilizo las flechas, pero aqui vieno lo raro, si realizo el cambio de registro seleccionado con el mouse, se dispara el evento -tengo un mensaje que me avisa- pero no ejecuta el comando de Interfaz;procesar(rejilla1,seleccionadas) y en consecuencia no hace la sincronización, sin embargo, si vuelvo a seleccionar otro registro con el mouse, hasta ese momento ejecuta la sincronización, pero no con el registro recien seleccionado, sino con el anterior.

Para evitar esto generé dos conexiones de eventos, una con señal simple click y otra con cambio de seleccionado, sin embargo si utilizo el simple click, este es ignorado y el que se ejecuta es el de cambio de seleccionado, con el consiguiente comportamiento erróneo al utilizar el mouse, esto es, sincronizando con el valor penúltimo que se seleccionó, no con el último.

Es raro no?

Seguiré probando pero si tienen alguna experiencia al respecto les agradeceré comentarios sobre la solución que hayan aplicado.

Un saludo.

Martin Ibarra.


([N1] aztecmexico) #9

¡¡¡¡¡¡¡SOLUCIONADO!!!!!!!

La solución que dá el comportamiento esperado para ambas ocasiones, con flechas y con mouse, es con los dos eventos, uno con señal simple click y otro con la señal cambio de seleccionado.

Al parecer lo que me generaba el comportamiento indeseado eran los mensajes que utilizaba a manera de seguir el flujo del proceso, simplemente al comentarlos y ejecutar de nuevo TODO FUNCIONÓ.

Gracias de cualquier manera a todos, en especial a ti FRAN.

Un Saludo.

Martin Ibarra.

P.D. Esto, simplemente -a mi parecer- evidencia la URGENTE necesidad de un debugger o depurador, que nos permita seguir los flujos sin tener que estar metiendo mensajitos que -primera vez que me sucede- interfieren con el comportamiento de la aplicación, haciendo creer que existen errores donde no los hay, he dicho.


([N1] juan_figueroa.telefonica) #10

Lo suyo, creo, es como lo soñó JPereira, que funcionara con variables locales a los objetos, porque son más limpias al estar aisladas. Para eso creí yo que se habían implementado en la V7.


([N1] Emanuel) #11

El tema de éste tipo de estructuras llenas de eventos y variables globales (caprichos arrastrados del 6.x) no me gusta nada y menos al no tener depurador de código. En fin prefiero las formas más estructuras, orientadas a objetos o aunque sea automatizadas. Las variables globales para colmo están en un proyecto de datos. Otro tema que veo que no me agrada del todo es hacer tablas de parámetros de búsquedas, muy "vueltero" el tema. Me parece que el V7 debería mejorar los formularios asociados a búsquedas o facilitar la creación de formularios con una grilla y un panel de filtros. Dejar de abusar tanto de los eventos y variables globales.
Lo mismo se debería mejorar quizás en los procedimientos al navegar por la información para no tener que llevar los datos del origen de la navegación mediante variables locales por ejemplo.

Es solo mi parecer.

Saludos.


([N1] juan_figueroa.telefonica) #12

EManuelToro,
¿Qué quieres decir con:

Otro tema que veo que no me agrada del todo es hacer tablas de parámetros de búsquedas, muy "vueltero" el tema ?

No entiendo lo de "vueltero"
(Lo siento, estoy un poco pez en la V7)


([N1] Emanuel) #13

Si la verdad un poco por arriba hice el comentario. Me refiero que en el V7 hay mayor libertad de las que había con el 6.X ya que uno dispone de eventos y conexión de eventos. Es decir el sistema que usa las librerías QT para el manejo de eventos. Lo que no me agrada mucho es que los mensajes entre objetos de Velneo, lo que muchos en definitiva llaman la sincronización de objetos se realicen mediante eventos y variables globales. Me parece que se deberían de poder enviar mensajes con sus parámetros, etc.
Por otra lado una misma cosa se realiza o de forma automática con las herramientas que proporciona la V7 o de forma "manual" mediante en su mayoría el uso de eventos y variables globales.
Voy a dar un ejemplo a ver si me explico mejor, no es fácil de explicar.
En mí programa quiero hacer una búsqueda parametrizada de una tabla donde registro los movimientos de stock y presentar esos datos en una rejilla. Entonces recurro a las búsquedas y a un formulario de búsqueda asociado. Es una muy buena forma automatizada de seleccionar los filtros a utilizar a partir de los campos de la tabla o recurrir a las variables locales al formulario que se "sincronizan" con las locales al objeto búsqueda. La cuestión es que es "limitada" ésta opción porque solo puedo filtrar por los campos de la tabla o por el valor que tome alguna variable y también es limitada a nivel presentación ya que no se podría mostrar en forma de panel. Por lo tanto se deja de usar ésta forma cómoda y automática de hacer las cosas y se recurre a soluciones o alternativas más "sucias" al problema como ser la creación de una tabla que solo contendrá campos que se usaran para hacer filtros y al uso de eventos y variables globales para poder ir actualizando la información según la selección que realice el usuario.
Con ésto no digo que sea buena o mala una forma determinada de hacer los filtros, solo digo que quizás se podría mejorar la forma "clásica" de generar pantallas de búsqueda con filtros.
Por ejemplo yo utilizo una forma con panel de búsqueda basándome en un formulario de búsqueda asociado a la tabla por la cual quiero buscar datos y una rejilla presentada mediante un objeto vista de datos, sin usar para nada variables globales. Y por ahora me parece bastante buena pero sigo con el problema de que solo puedo filtrar por campos que pertenezcan a la tabla.

Es solo mi opinión según lo que conozco por ahora del nuevo Velneo.

Saludos.


([N1] juan_figueroa.telefonica) #14

ES decir, "vueltero": que hay que dar más vueltas que una peonza en vez de ir directamente al grano. Comprendo y tampoco a mi me gusta mucho. Gracias por la explicación


([N2] bannu) #15

Se debería poder enviar mensajes a cada objeto desde cualquier proceso, evento, u otro objeto. Ejemplo, imaginemos que se pueda definir un subobjeto filtro dentro de la rejilla, con los campos que estimemos oportunos, se le enviaría un mensaje a la rejilla con los valores deseados y que la rejilla solita se encargara de mostrar los datos filtrados, es una idea.


([N1] juan_figueroa.telefonica) #16

Mi idea era que las variables locales de los objetos podrían capturar esos mensajes o parámetros enviados por procesos etc..
Por lo visto no es así.
Una pena


([N1] Emanuel) #17

El tema del pasaje de información en Velneo V7 lo tengo en práctica/estudio y voy descubriendo cosas interesantes en los ejemplos oficiales y otros ejemplos "no oficiales". Veo sinceramente muchas cosas que facilitan la programación y otras no tanto y peor si no se usan bien, es decir...me falta un curso de buenas prácticas con Velneo. Quizás en Mayo lo podré recibir.
Eventos, conexión de eventos, compartir información mediante variables globales, cestas, variables locales gracias a los manejadores de objetos, uso de subformularios o vistas de datos alimentadas de diferentes formas. Un mundo de posibilidades. No?
Quizás cuando tenga un poco más claras ciertas estructuras y formas de hacer las cosas pueda dar mejores opiniones sobre éstos y otros temas.
La comunidad me ayuda mucho y también los tutores, gracias a los cuales estoy llevando adelante mi primer "programita" serio en V7.

Saludos.