Formulario u otro objeto visual


([N4] SyP) #1

Tengo una tabla maestra, como articulos u una historica de caracteristicas con unas 10 caracteristicas. ¿se puede hacer un formulario que muestre esos valores como un campo, no como una lista? Es decir mostrar las caracteristicas todas juntas como campos para editarlas . Espero haberme explicado. Gracias


([N1] vlinares) #2

Buenas tardes…

Si es una vista de datos, puede indicar en la rejilla histórica en contenido:
#campo1+" “+#campo2+” "+etc…

Lo que quieres es que cuando se mueva por la rejilla maestra cambie el contenido de un campo,
deberás establecer un evento que cuando cambie la rejilla te llene un campo del formulario de la misma manera…

No se si me he explicado bien.

Ahora lo de editar lo tienes más crudo, no he probado (y no creo que se pueda en una rejilla editable), editar campos concatenados.
En el caso de trabajar sobre un objeto de texto, tedrías que montarte alguna argucia incluir caracteres no visibles, (p.e.)o “;” o “|”, y utilizarlos como puntos de control y según la posición luego partir esa cadena y actualizar los campos correspondientes.

Saludos
Vicente


([N4] SyP) #3

No entiendo lo que quieres decir. Gracias de todas formas.
La imagen 1 (art car list) es la lista de caracteristicas, de longitud indeterminada y lo que quiero es mostrar los datos (y editarlos si es posible) tal cual se muestra en la imagen 2 (art car for). Para hacer la imagen dos he creado un singular del plural por posicion, pero el problema lo tengo en que no se cuantos serán (aunque no creo que más de 20). Se podría hacer tal y como digo, pero ¿Existe alguna forma, sin tener que llenar la tabla de articulos de campos enlazados?

Gracias




([N1] vgegeo) #4

No se si te he entendido bien:
En lugar de mostrar una rejilla con los historicos, muestra un bloc de formulario con los historicos.

-Puedes hacer un formulario de la tabla de caracteristicas, en el que tengas el campo CARACTERISTICA y el campo VALOR.
-En la ficha del maestro, puedes mostrar los historicos con un BLOC DE FORMULARIOS, ¿no?

Con esto conseguiras tener un formulario para cada caracteristica y su valor, tantos como historicos tenga ese registro maestro, y podras moverte por ellos con las flechas que aporta este objeto.

¿No es eso lo que quieres conseguir?


([N2] jorge) #5

Hola, igual suena demasiado obvio, pero la rejilla de históricos poner editable la columna valor?


([N4] SyP) #6

Gracias a todos por vuestro tiempo.
Vgegeo, lo habia pensado, pero quieren ver todos los valores de un vistazo.
j.sotomayor. Lo mas practico seria eso, pero no lo quieren asi ( exigencias del cliente). Lo quieren como un formulario.
El tema es porque en la anterior app lo tenian como campos dentro de articulos. Al plantear el cambio les dije de hacerlo historico por las ventajas de no tener límites, pero el que tiene que picar y revisar datos lo quiere como formulario.


([N1] vgegeo) #7

Ya, es que la opcion del bloc de formularios es un poco absurda para el usuario poder ver todo de un vistazo.

Lo suyo es como campos del articulo


([N2] jorge) #8

Y cargar todos los datos del histórico en variables y mostrar las variables?


([N4] SyP) #9

Gracias a todos.
j.sotomayor de momento ire por ahi, porque no toco la tabla maestra y ademas con variables me permitiría editar con conexionrs de eventos. Es un coñazo hacerlo pero es la única opción que veo.


([N1] wikan) #10

Crea una tabla de extensión y así puedes editar los atributos como campos.
Tienes todos los atributos dentro de una sola tabla y te ahorras el tener que traer el valor de los históricos y luego volver a mandarlos.


([N1] wikan) #11

Otra opción quizás más complicada pero dinámica sería QML


([N4] SyP) #12

Gracias Wikan. Lo de la tabla extendida lo comentare con el cliente porque si no nos va a servir la historica como tal, quiza no valga la pena.
Lo de QML ahi si que me has pillado. Quiero sacar tiempo para ver como va porque no lo he podido estudiar todavia, pero de lo que queremos a lo que podemos hacer…


([N1] wikan) #13

Depende como montes los atributos, para el cliente será transparente.


([N2] Mgalvezh) #14

Otra opcion, una tabla dummy en memoria, con campos de sobra lo que pasa que tienes que cargarla con los registros de atributos y al guardar volver a su sitio los registros, depende de cuanto tarde…


([N3] pacosatu) #15

Hola SyP.

Si el número de características está acotado a 10 y el cliente quiere editarlas simultáneamente en una misma pantalla, entonces no hay ninguna duda, el cliente siempre tiene razón y lo demás es complicarse la vida.

Por lo tanto, añade los 10 campos a la tabla Artículos o como indica Manuel a una tabla de extensión, aunque si son campos obligatorios deberían ir en la misma tabla.

Saludos
Paco Satué


([N4] SyP) #16

Muchas gracias a todos. Al final serán campos de una tabla. Después de hablar con el cliente, entre características comerciales y de fabricación serán unas 40 características. Además habrá que indexar muchos de esos campos para posteriores búsquedas. Tendiendo en cuenta que también quiero usar el vErp en otros clientes, que recomendais, campos de la tabla o campos de una tabla extendia. Si es una extendia, que está en el proyecto del cliente o directamente en el ERP.

Muchas gracias por vuestras respuestas.