Separadores de formulario dinamico


([N1] cristianvg2003) #1

Hola,

Una pregunta simple, si a los subcontroles que componen un separador de formularios se les indica una condicion visible que depende del estado de un campo boleano, al cambiar el valor de ese campo boleano no deberia de verse el efecto en la visibilidad o no visibilidad de las pestañas ?

 

Hay que hacer algo mas que la indicacion en los subcontroles de la condicion de visibilidad ?, he explorado las instrucciones del interfaz y ninguna se me acomoda, si bien las instrucciones "Activar subcontrol" y "Esta activo el subcontrol" podrian servirme no esta la intrucción "Desactivar subcontrol", en otras palabras la funcionalidad me queda a medias.

No se si algo se me escapa,

Saludos,

 


([N4] eic) #2

Hola.

Fíjate en la incidencia 1520 de vBugman. Las condiciones de visibilidad de las pestañas de un separador sólo funcionan cuando se abre el formulario, pero no se modifican si, ya estando abierto, las condiciones cambian.

Saludos,

Fran Varona

 


([N4] eic) #3

Hola.

Posible solución alternativa: pones dos separadores, cada uno con las pestañas correspondientes a cada una de los dos valores del campo booleano, y les pones condiciones de visibilidad a los propios separadores. 

Es más complejo, más lento (tiene que cargar los dos separadores), más complicado de mantener... pero al menos, funciona.

Saludos,

Fran Varona

 


([N1] cristianvg2003) #4

ok Fran me parece muy adecuada esta alternativa,

 

Este es el tipo de cositas que no termino de entender de V7, aplaudo el esfuerzo por los estandares y la creación de nuevos componentes y controles, pero la calidad esta en los detalles y no deberiamos empezar por entregar una plataforma sin bugs, no deberia el vBugman solo tener los Bugs de la version Actual ?

No deberian de existir  ya =>

- La llamada "super-rejilla", la que se tiene a hoy escazamente mejora a la rejilla de v6 y no le hace honor a la V7.

- Un boton Deshacer.

- Un simple check de "separar por miles" en un edit de un campo numerico.

- Mas opciones para las carpetas en las que agrupamos nuestros componentes, colores e iconos para distinguir los componentes que contienen.

- Una forma mas adecuada de movernos por los diferentes Menus, al mejor estilo de la v6.

- Una forma mas adecuada de integrar los componentes para probar en desarrollo porque la secuencia, guarda, cierra vClient que seguramente lo tienes abierto, reinicia instancia, ingresa al vClient y prueba si lo que hiciste da resultado, es tediosa.

- Una metodologia para integrar maestros distribuidos, cual es la gracia de la herencia si no puedes extender los atributos de una determinada tabla en la caja de datos; porque con todo respeto la forma de dar de alta a las entidades en la vGestion es lo menos intuitivo que me he encontrado en mucho tiempo.

Una duda => Quienes prueban la plataforma no se quejan con el departamento de desarrollo de este tipo de cosas que son de base?

Que no se mal interprete aplaudo componentes como el vCurl, VImagenes, la dedicacion a la plantillas y los componentes nuevos como el objeto TCP, puerto serie, control SVG, etc.  pero en terminos de prioridad no deberian de estar estas cosas basicas antes de comenzar con la innovacion en componentes nuevos ?

Es mas ahora que le estoy dedicando mas tiempo a V7 que otras cosas que podrian considerarse "basicas" no estan implementadas para no perder el tiempo buscandolas ?

 

Saludos,

 

 


([N1] agustin) #5

:-)


([N4] mittosoftware) #6

Este hilo ya tiene casi TRES AÑOS de viejo, y acabo de darme cuenta, que con la 7.11 AUN SIGUE SIN RESOLVERSE la incidencia 1520 que se menciona.

¿Saldrá resuelta la 1520, para la 7.12? ¿Es obligatorio que crear una ‘idea’ para que se resuelva?

Sobre lo que dice Cristian de cosas básicas, ¿no es ULTRA-BÁSICO que no tengamos que crear 2 sistemas de usuarios, uno en vAdmin, y otro para las apliciones, es decir, no deberiamos poder agregarle permisos especiales, en base a lo ya creado en el vAdmin?

Si tan delicado es el API de los usuarios de vAdmin, ¿no puede Velneo habilitarnos en vDevelop, al menos poder acceder en SOLO-LECTURA a esos usuarios y grupos definidos en vAdmin? Nosotros podriamos con eso, armar un listado paralelo dentro de nuestra solución, y el cliente ‘administrador’ podria alli agregarle-denegarle permisos especificos de acceso.

Para quienes no han visto la idea, abajo se muestra.

http://velneo.zendesk.com/entries/21610342-api-para-gestionar-usuarios-del-sistema


([N4] amadis) #7

Uno de los fallos (en mi humilde opinión) que comete Velneo es es el de “arrastrar” determinados bugs demasiado tiempo (lo demuestran la antigüedad de este post y la situación en la que estamos actualmente) lo que deriva en una desinformación total para sus usuarios: no se sabe hasta el último momento cuándo se va a resolver un problema que, a lo mejor, para algunos, es de vital importancia.

En cuanto a lo comentado anteriormente, creo que deberían pararse un poco y revisar lo que hay hecho, dejar durante un tiempo de avanzar, de hacer la pelota más grande y resolver temas más básicos, como la usabilidad de los componentes ya existentes, por ejemplo…

Es una apreciación personal, nada más.


([N1] cristianvg2003) #8

Hola @cribera totalmente de acuerdo contigo, el tema de los usuarios y permisos del vAdmin es una piedra en el zapato y no pequeña, en mi caso particular ese tema de acceso a las funcionalidades de administración del vServer desde fuera (usuarios, permisos, instancias, carpetas, etc) ha sido un dolor de cabeza en la creación de vClouden y que aun no resuelvo del todo, pero lo que ofende es que estas funcionalidades YA EXISTEN , tanto que están disponibles en API de vCloud y ni señas de que vayan a estar disponibles para desarrolladores en el futuro cercano.

 

Un saludo,


([N3] blanyi) #9

Buenos días.

Y el equipo de Velneo nadie dice nada.

Como dicecribera no es posible que la incidencia 1520 lleve casi tres (3) años y que aun no la hayan resuelto y peor aun que durante todo este tiempo no hayan hecho siquiera un pronunciamiento al respecto.

Señores del Velneo, estamos a la espera de una solución.

YIMY MORA ACONCHA


([N3] blavan) #10

Pero este tema quedo resuelto con la conexion on show ¿no?


([N4] fgutierrez.velneo) #11

La condición de visibilidad para los pestañadores únicamente se evalúa en la creación del formulario. La sincronía de las pestañas se deja a los programadores, en realidad no se trata de un bug. Esta incidencia ya está cerrada desde que tuvisteis la opción de gestionarlas:

Para gestionar las pestañas y su visibilidad tenéis en el Api de Velneo la clase VStackedWidget (http://velneo.es/info_v7_711_es/velneo_vdevelop_v7/scripts/clases/vstackedwidget). Algunas de las funciones que encontraréis son: addForm(), insertForm(), removeForm().

Podéis encontrar un ejemplo en Velneo vBase (fichero javascript velneoTab.js).

Seguiremos trabajando para solucionar todas las incidencias y necesidades que tengáis, ese ha sido un esfuerzo de este pasado año en el que hemos solucionado, en tres versiones y varias subversiones, más de mil incidencias incluyendo mejoras y correcciones.

Y no dudéis en contactar con nosotros a través de soporte para cualquier información que necesitéis o en hacer uso del foro de ideas, para transmitirnos vuestras inquietudes.


([N3] blavan) #12

Hola, por favor si lograsteis aplicar la solución expuesta por velneo una breve ayuda de los pasos a seguir

Gracias


([N4] fgomes) #13

Basta crear un evento oninit en el formulario que llame a a un evento en javascrip.

Para obtener el control del separador de formularios puedes usar la instrución:

theRoot.dataView().control(‘ID_SEP_FORM’);

después en la ayuda de javascript que tiene v7 incorporada tienes todos los comandos necesários para hacer lo comentado en esta discusión.

De todas las formas si eres de nivel de pago, este tipo de cosas el suporte de velneo también te explica como funciona.


([N3] blavan) #14

Gracias Filipe, a ver si lo consigo

Por cierto acabo de dejar un comentario en tu blog que le va al pelo esta incidencia

Saludos