Me observan en Velneo que la idea solo tenia 6 votos, como de alguna forma, justificando su demora.
.
A mi al menos me afecta DEMASIADO, pero no la voté porque al ser un BUG gigante, y data del 2011, y que encima aparece 'planificada' hace tiempo, creí que estaba ya al salir. Pero ahora tuve que darle 3 votos.
.
¿A ustedes no les afecta de verdad que todas las validaciones que quieran ponerle al cancelar una transacción, se vayan al garete porque el usuario final cierra con 'X' en vez de cancelar?
.
¿Como solucionan en v7 cuando hay diversos tipos plurales, y hasta hijos de plurales, y quieren que su transacción tenga atomicidad (una característica inexcusable en aplicaciones profesionales, o se confirma todo, o se cancela todo)?
Un ejemplo, han agregado plurales, y si se cancela el formulario, que no queden plurales 'huerfanos'.
.
Gracias de antemano por las respuestas.
Hola, a bote pronto, se puede controlar que el usuario ha salido por el botón cancelar de la siguiente manera
Un evento inicio formulario que pone la varible local cancel=0
Un evento en el botón cancelar que pone la varible local cancel=1
Si sale por la x, cancel sigue teniendo 0, a partir de ahí se ejecutan unos procesos u otros
Con respecto al tema de los plurales que comentas, no entiendo bien como lo haces, pero lo que si te puedo asegurar, es que cuando abro un formulario de alta de un maestro y ese formulario tiene rejillas de plurales, incluso en el caso de que no modifique ningun campo de la tabla maestra y ni siquiera pulsando Aceptar, solo con agregar registros a cualquiera de las rejillas de sus plurales, el maestro se graba y las lineas no quedan huerfanas.
Pero dicha funcionalidad esta incluida en la herramienta, y no es necesario programar absolutamente nada, simplemente funciona.
@benito.lavandeira
Yo he enviado una idea similar a Velneo, pero que se incorpore en el vClient, al cerrar sesión, que cualquier transaccionID cuyo bandera (bandera que controle si el usuario usó cancelar o aceptar, la idea es que sea un campo del registro de transacción) no este usada, haga algo tipo una garbage collection y haga rollback de todas las transacciones cerradas con X, al cerrar la sesión del vClient.
.
No se si entendi bien, creo que algo parecido propones, pero que lo haga el usuario en cada formulario, cierto?
.
Si es así, donde se haría? Porque si un usuario sale con X, ya estarías fuera del formulario, cierto? Dispararías los procesos desde fuera?
.
EDITO. @Pepeto, no había visto tu mensaje. Si te fijas en las incidencias 2918 y 3009, me había visto obligado a hacer cosas vía eventos dentro del formulario o eventos de tabla, al cancelar un formulario que involucraba un marco transaccional medianamente complejo (tampoco era tan complejo me parece, una tabla padre y varios plurales que debian agregarse desde un evento).
.
El problema es que esas acciones que se ejecutaban al cancelar, no puedo hacerlas si el usuario cierra el formulario con la 'X' en vez de cerrar con el botón 'Cancelar'.
.
Me avisan si no me he explicado bien.
Saludos.
Creo que deberías explicar detalladamente en el foro con un ejemplo concreto, cual es tu necesidad.
Me temo que estas pasando algo por alto o estas haciendo las cosas de una forma muy rara.
En Velneo y si juntamos Velneo 6.x, hay cientos de miles de aplicaciones, pequeñas, grandes y muy grandes, de uso por un solo usuario y por cientos de ellos simultaneamente.
Y sinceramente y como puedes ver en el foro, el tema del aspa no es ningún problema para nadie o casi nadie y en todo caso en alguna situación muy especifica.
Pero lo que es seguro es que impedir cerrar una ventana con un click en la X, sea un Bug. En todo caso una funcionalidad más y que no dudo que para alguna cosa especial, puede venir bien, como todas, pero muy especial.
Desde luego no es el camino para asegurar la trasnsaccionabilidad,o que esta tenga atomicidad.
Creo que lo mejor es que expongas claramente tu necesidad en el foro, pro que creo que estas pasando algo por alto y desde luego, si por algo es Velneo maravilloso es por que su gestión de la transacionabilidad creo que es muy buena y como programador incluso te puedes olvidar en el 90% de la casuística de ella , Velneo te la resuelve y cuando no, si entiendes Velneo, la solución suele ser muy sencilla.
Hola, mira por mi forma de expresarme parece que cuando intento colaborar lo que genero es polémica y de verdad que esa no es mi intención
Como seguir charlando sobre el tema lo considero útil porque siempre dará lugar a conclusiones pues te vuelvo a contestar
Si el formulario lo lanzas con Crear manejador de objeto, Disparar objeto, con get variable local del objeto ya controlas si la variable cancel viene a 0 ó a 1 y a partir de ahí operas.
Parece que tu te refieres a que ejecutas eventos sobre el botón cancelar y claro con la X pues no se ejecutan.. si parece que tienes razón, bueno pero si en lugar de eventos utiliza procesos si que lo podrías controlar ¿no?, Inicio formulario con cancel=2, si salgo por aceptar Cancel=0, si salgo por Cancelar Cancel=1
Pero yo desde que cogí soltura con crear manejador de objeto, disparar objeto.. tiendo a orientar todo mi trabajo sobre esa línea y logro un mayor dominio de los sucesos
@Miguel Por si acaso, si fuera algo solo mío, no se hubieran creado las incidencias 2055, 2918 y 3009. Puedes verlas con el vBugMan tu mismo.
.
Y fueron admitidas como problemas de transacciones por el soporte oficial de Velneo, pues se crearon varios hilos para ir solucionando los problemas que aparecían (GPF dentro de un bloqueo duro, Actualizaciones que no actualizan), si hubiera sido que mi forma de resolver es 'rara' me lo hubieran dicho para simplificar el soporte ¿no te parece?.
.
Si pregunté aquí, es porque quería buscar opciones sobre como sortearon el problema otros desarrolladores.
.
De hecho, agradezco a quienes respondieron, y voy a probar las sugerencias, espero que puedan salvar el problema hasta que esas 3 incidencias estén resueltas.
.
Saludos a todos.
@Benito
Para nada es crear polemica, si de los mensajes podemos sacar conclusiones que nos lleven a algo positivo.
@Cesar
Entiendo el problema, de cancelar con la "X", y no lo paso por alto. Pero para mi no tiene quiza tanta importancia como para ti.
De echo, en el articulo de la semana pasada, escribia sobre una solución a ese respecto: "Mejoras en formularios de V7", porque lo principal no es quitar la "X", sino poder controlar lo que debemos hacer cuando el formulario se cancela, se cual sea el boton pulsado (en el punto 5).
De todas formas, una vez que tengamos vJavaScript, también podremos controlar estas opciones del formulario, solo hay que esperar un poco más.
Pero si tan importante es controlar esto, requiere un poco mas de trabajo pero yo lo he solucionado de la siguiente forma:
- Uso una tabla temporal para rellenar los datos del formulario principal, y si finalmente se acepta el formulario, guardo los datos en la tabla definitiva, y si se cancela, me da exactamente igual, porque como tabla temporal que es, no tengo que controlar absolutamente nada, ni siquiera borrar el registro. Si ademas, usas una tabla en memoria, estos registros se eliminan solos al finalizar la ejecucion.
Hola cjribera, seguí dándole vueltas a lo tuyo y te comento que utilizo velneo desde los 90 con bases de datos muy gordas y nunca se me planteo lo que entiendo que expones es decir desde Cancelar actuar sobre los históricos a nivel formulario.
Desde los formularios fundamentalmente actúo sobre rejiillas de históricos y históricos de históricos pero lo hago con botones en donde especifico el proceso a ejecutar, para ello la herramienta desde botón me permite lanzar procesos sobre la rejilla que yo quiero y sobre los registros que yo quiero, todos o tres ó cuatro y esos funciona de maravilla.
Te lo expongo porque hace cuestión de un mes también te sugerí como solucionar un proceso creo que con multipartir lista y me decias que muchas gracias pero que aún no estabas muy ducho con la herramienta.
@benito.lavandeira Gracias por tus aportes. Lo de multipartir lista no lo he probado aun, quizá no era conmigo. Pero en base a lo que planteas, haré un escenario de pruebas y utilizaré el soporte oficial para que me ayude donde me quede bloqueado.
.
Asi he aprendido hasta ahora, armando ejemplos en base a las necesidades propias. Espero poder hacerlo ahora.
.
Eso si, el problema fue que en teoría, al menos si uno ve los videos tutoriales (por ejemplo, ver 2 imagenes adjuntas, como utilizan el paradigma rejilla->formulario->rejilla embedida(para los plurales) y hacen las altas, bajas y modificaciones de ficha con los botones estándar de v7, según eso, debería haber funcionado como lo intenté, y esas 3 incidencias no deberían existir (incluso en mis inicios con v7, se me habló del poderío del bloqueo duro en la v7 cuando pregunté si iba a necesitar tablas en memoria para garantizar atomicidad transaccional).
.
Entonces, si esas incidencias son insalvables, quizá los tutoriales deberían ser en base a lo que dices "con crear manejador de objeto, disparar objeto.. tiendo a orientar todo mi trabajo sobre esa línea y logro un mayor dominio de los sucesos".
¿No crees que sería una buena idea que los tutoriales se reorienten así? Haciendo lo mismo pero con manejadores de objeto? ¿No se ahorrarían tiempo los desarrolladores y los de soporte?
Sobre este tema de la famosa "X" del formulario, mi opinión es que en verdad es muy necesario poder atrapar el evento de cierre de un formulario antes de que suceda "before-close".
Esto no solo ayudaría a poder controlar varias cosas a nivel de datos, sino que además se le puede dar otros usos muy provechosos. Pongo un ejemplo, podríamos controlar que no se abra más de una vez un formulario o rejilla, esto registrando en una variable tipo array el ID de cada formulario abierto. Si se trata de abrir nuevamente el mismo formulario, solo se pasaría el foco al mismo; y una ves cerrado se borraría el registro correspondiente.