Probé verificado el ID > 0 y no me resultó, esto me resultó muy complicado, en access existe una opción más sencilla, solamente le dice uno al formulario que es para edición y listo, no permite ni eliminar ni dar de altas.
Sigo intentando no me daré por vencido....!,
Hola:
He creado una entrada en mi blog para intentar explicar esta cuestión.
Un saludo
www.geproin.es
De hecho tenía algo similar a lo que publicaste en el blog, pero con esta solución publicada se me presenta lo mismo que con la mía. Se me despliegan tantas lineas en blanco como doble clic o clic derecho aplique sobre la rejilla y esto desubica al usuario y es poco estético.
Hola Victor:
Es raro. A mi no se me creaba ningún registro al probarlo. De todas formas te he ampliado la información aquí
Un saludo
www.geproin.es
@fjvila, @sistemastip
.
.
Creo que se refiere a la mejora incorporada y solicitada por muchos a partir de la versión 7.8.0
.
Alta de registros en rejilla con doble clic
Ahora haciendo doble clic en una zona del cuerpo de la rejilla que no tenga registros se lanza el formulario de alta que tenga asociado
.
.
http://velneo.es/foros/topic/listado-de-novedades-la-version-velneo-v7-78
.
Es una funcionalidad más, y es el coportamiento esperado. En v6, cuando damos doble click en una rejilla al final de la misma cuando no hay registros, ocurre lo mismo. De echo, para v7 se solicitó esta funcionalidad y queda implantada.
.
.
saludos
Antonio Vela
http://www.velavisual.com
Hola Antonio:
En el ejemplo planteado en el blog he supuesto (está informado) que la rejilla no tiene ningún formulario de alta ni de edición asociado. El único que tiene asociado es el de baja.
Un saludo
Gracias, lo solucione agregando la validación de un campo en vacio como se explica en el blog. Nuevametne gracias.
Refloto esto para pedir aclaraciones, por favor.
No se si entiendo algo mal, pero la ‘mejora’ que menciona velavisual no la veo como tal, pues nos carga de un problema adicional por cada rejilla que usemos, para implementar la solución que propone vila en su blog.
Es decir, ¿no debería uno tener una forma sencilla y estándar para que las rejillas sean SÓLIDAS y no estén creando estas altas indeseadas, sin tener que estar arreglando esto a mano?
Refloto el tema, para mostrar que hay una idea relacionada, y justamente en mi comentario, añado algo que no creo sea tan difícil de implementar, que el molesto doble click sea OPCIONAL, que se pueda evitar con un booleano, en las propiedades de la rejilla.
http://velneo.zendesk.com/entries/31279623-Permitir-insert-en-rejillas-editables
Pues es relativamente fácil controlar el que no se dé de alta con doble click en una rejilla editable sin formulario de alta y sin menús de contexto.
Como bien dice mi estimado fjvila, un evento, una señal, una expresión y punto.
No había tenido necesidad de implementar esto, pero hoy me surgio y pues más allá de los 5 minutos que me tomó entrar al foro, consultar y leer este hilo no le veo mayor problema.
Por si les sirve,
La conexción de evento vá con la señal “Edición iniciada”
y el proceso va:
Interfaz: Obtener la ficha en edicion de la rejilla()
If (#ID=0)
Set retorno proceso = NO
Finalizar proceso
Con esto evito el alta con doble click del registro que no quiero, y al mismo tiempo si el ID es distinto de 0 pues si me permite editar el o los campos.
A veces creo que nos ha acostumbrado tanto V7 a hacer tanto con tan poco esfuerzo que ya solo nos falta que hagan los desarrollos por nosotros.
Anoche tuve la oportunidad de platicar con un desarrollador Java, impresionado totalmente por la rápidez y facilidad para hacer muchas cosas en V7 comparado con su actual plataforma.
Saludos.
Martin Ibarra.
@aztecmexico El tema de la idea (que deberia llamarse EVITAR el insert…) http://velneo.zendesk.com/entries/31279623-Permitir-insert-en-rejillas-editables es que Velneo no te quite el tiempo que te hizo ganar en otras cosas, con detalles como este.
Con lo fácil que es poner un booleano, lo hace UNA SOLA VEZ el equipo I+D, y nunca mas a preocuparse de tema para los demas desarrolladores Velneo.
Imagínate en una app grande con cientos de rejillas embedidas en forms, esto que muestras lo tienes que hacer tropecientas veces.
Y aun siguiendo estas recomendaciones del hilo, yo sigo teniendo registros creados en cero, que me aparecen misteriosamente, algo que no me sucede en las rejillas no-editables. Es decir, hay que perder mas tiempo, mas bien que yo no uso mucho v7 ahora, por eso no he necesitado investigarlo.
No se esta pidiendo replicación aquí, solo un simple booleano. Algo tan simple debería estar resuelto hace tiempo, ¿no les parece?
Hola,
Como dicen por ahi, todos tenemos razón, y todos estamos equivocados.
Lo único, una cosa es pedir o exigir algo, comportamiento, funcionalidad, etc. yo constantemento lo hago, y otra muy distinta atrevernos a decír o suponer que implementar tal o cual cosa en V7 es sencillo.
La verdad no lo sabemos, ni tu, ni yo, ni nadie fuera del grupo comandado por el vArquitecto, creemos que es fácil, o suponemos que es sencillo, pero quien dice que es cierto.
A mi tambien algunos clientes, asesores de clientes (hijos, primos, etc.) o colados (abogados, médicos, contadores, etc. que no tienen NPI de desarrollo de sistemas) me dicen que porqué implementar tal o cual funcionalidad es o tan caro o tan tardado, qué que tanto es poner una o dos líneas de código a mis aplicaciones para que ellos puedan hacer algo, y la verdad no les contesto, porque hay una regla que dice que a mayor facilidad para el usuario, mayor dificultad para el programador.
Hasta aquí le dejo. Solo reitero que en lo personal podré exigirle, pedirle o quejarme a Velneo sobre el porqué no hace ciertas cosas o no tiene ciertos elementos, pero me ha quedado claro, que es un error de mi parte (y porqué no decirlo, de muchos colegas) el suponer que es tan “fácil” que ellos implementen lo que queremos, porque simplemente no sé, no conozco, no tengo ni idea de las tripas o como está construido V7, y al desconocer esto pues obviamente no sé que impacto tenga el mover aqui para descomponer allá.
Como dicen por aquí algunos colegas, “lo que hay es lo que hay” y lo que viene, pues ya llegará.
Saludos.
Martin Ibarra.
@aztecmexico En este caso, yo si tengo experiencia como programador (aunque ya no programo tanto ahora, si lo hacía en mi juventud) de C y C++ (no soy un abogado opinando de programación). Y eso mismo me hace pensar que es lógica básica, que no tiene porque ser complicado, partiendo DEL MISMO CODIGO QUE TIENEN AHORA (no tienen que crear nada nuevo).
Sino, digan si es absurdo este planteamiento que hago a continuación.
Se puede poner crear una propiedad booleana de TODA LA SOLUCION, o de todo un PROYECTO. Esta booleana podria llamarse,PERMITIR_INSERCION_EN REJILLAS_EDITABLES_GLOBAL, y uno puede definirla como verdadero o falso, y se convertirá en el default de todo objeto rejilla que se haga en la solución o proyecto.
Ahora, para cada objeto rejilla, existirá una propiedad booleana propia PERMITIR_INSERCION_EN REJILLAS_EDITABLES_REJILLA, que heredara de inicio el valor booleano global, pero el desarrollador puede cambiar ese valor entre verdadero o falso, haciendo un override. Si el desarrollador no toca nada alli, queda con el valor por default que definimos para la solución o proyecto.
Para lo demás, copio parte lo que dice la idea.
Cuando la rejilla es editable, si está en verdadero la booleana, se comporte como ahora (añade línea a la rejilla) y si está a falso que se comporte ante una inserción como si la rejilla no fuera editable (usando la propiedad del formulario de alta).
Ni el encapsulamiento, ni la herencia, ni el polimorfismo, te impiden encarar una solución así.
Es decir, ¿donde esta la graaaaan complejidad allí?, ¿que codigo nuevo hay que crear, salvo las propiedades booleanas y la evaluación de estas?, ¿acaso el resto del código no se mantiene sin alterar?
Como digo, lo hacen esto UNA SOLA VEZ y nunca mas hay que estar yendo rejilla por rejilla, poniendo la conexión de evento y el manejador de evento. Y no estamos mas pendiente de esa alta con doble click, que es tan molesta para quienes no la queremos.
Hola a todos:
El problema de esto es que Velneo (queramos o no) tiene unos recursos limitados. Os puede parecer que un booleano por defecto es “imprescindible” en una determinada propiedad de la rejilla… ok… ¿por qué no en cada una de las propiedades?
¿y en los formularios? yo hago muchos formularios con mas o menos las mismas funcionalidades (plantillas)…
Ya que estamos… también en las búsquedas ¿no? y en los procesos ¿también?
Eso es el problema… lo que puede ser “imprescindible” para unos… puede no serlo para otros.
Al final lo que necesita uno mismo es lo mas importante. Velneo supongo que tendrá un camino marcado y según recorra el camino irá incorporando lo que se encuentre a su paso.
Un saludo
@AyudaVelneo, las otras propiedades no generan registros en blanco, un comportamiento indeseado en CUALQUIER BD.
Creo que eso debería ser tenido en cuenta, al justificar porque aqui si usar un booleano, y no en otras propiedades, no les parece?
Y justamente como desarrollador, yo se que las prioridades van por ahi, donde consigo mejor ratio calidad/precio en el uso de los recursos (horas hombre de los programadores), y justo acá veo un buen ratio. Algo relativamente simple de hacer (crear una o 2 propiedades booleanas y evaluarlas en el objeto rejilla), y que elimina algo que para cualquier BD es considerado comportamiento indeseado, algo que atenta contra la imagen de solidez de la BD (la aparición de registros en blanco).
De todas maneras, me queda claro que al final es I+D quien tiene la ultima palabra. Solo intentaba agregar elementos de análisis.
Saludos.
Los recursos limitados de Velneo es justamente el tipo de problema que nadie de la comunidad le va a decir a Velneo cómo resolver. En cuanto al resto de problemas, sigue habiendo una nebulosa en la que se pierden: ideas, problemas, mejoras, jScripts varios, y demás “farfollas”.
Estoy contigo @cjribera. Cada uno tenemos nuestras necesidades, pero hay cosas que son “bug” encubiertos. Que no haya una propiedad para deshabilitar el alta de rejilla es una mejora, pero que no haya forma de evitar un alta es un bug; ya sea por que no se ha tenido en cuenta o porque se ha programado así a conciencia. Que haya que crear un proceso cada vez que se quiera lanzar una búsqueda en tercer plano es una especie de putada difícil de entender; ¿Es un bug, una idea, …?
En Velneo siguen sin “alinear” (como a ellos les gusta llamar) su roadmap con las necesidades de la comunidad. El servicio de Velneo, al menos para mi es de 10, pero el roadmap y estrategia de evolución sigo sin saber hacia dónde van.
cjribera,
El medio o mecanismo para evitar ese comportamiento existe, y es muuuuuuuy fácil de implementar que no lo quieras utilizar pues es otro rollo.
Coincido contigo en que sería una mejora interesante o necesaria, pero, no recuerdo que ningún objeto en V7 se pueda preconfigurar para que en adelante tenga o no ciertas propiedades activadas o desactivadas a nuestro gusto, si me equivoco haganme el favor de aclararmelo, porque yo no lo sé. Lo que si es que todos los objetos nuevos aparece con las propiedades preconfiguradas que Velneo les pone, no más.
Como mencionan otros colegas, puedes ir creando plantillas de formularios, rejillas, etc. vamos algo como el almacen de objetos de V6 y a partir de ahi irlos implementando en tus desarrollos.
Mi punto a final de cuentas y lo comenté más arriba es que ni tú, ni yo, ni nadie fuera del equipo de desarrollo de V7 y del vArquitecto conoce ni sabe como esta implementado o construido V7 y por lo tanto considero muy poco ético el presuponer que algo “es tan fácil” o que “no se estan pidiendo la perlas de la virgen”, cuando no sabemos en realidad si sea fácil o no hacerlo.
Tu quieres una mejora para la rejilla, yo quiero una mejora para otros objetos, bien, podemos pedirle a Velneo que los considere e implemente, hasta aqui, ya decir que es bien fácil es temerario porque insisto, desconocemos las tripas del gato y este gato en particular es bastante peculiar y se aparta mucho de los demás gatos.
Una cosa si me queda clara, ese pequeño bool tiene más impacto a nivel plataforma y arquitectura del que te imaginas, y por algo no lo han hecho, bien sea porque no han tenido el tiempo de analizar o porque ya lo hicieron y estan preparando el cambio o porque simplemente no lo quieren hacer de momento.
Respecto a la lógica básica, pues no creo que aplique aquí, más bien habria que hacer un modelo de programación lineal que incluya todas las variables posibles y veremos que impacto real tendría meter ese bool, no a nivel rejilla, sino a nivel plataforma.
Saludos cordiales.
Martin Ibarra.
Bonito debate, una pregunta, se puede negar el alta en un trigger, que siempre compruebe los campos ‘obligatorios’ ? de esta forma nos vale para todos los objetos, rejillas, procesos, form, etc.
Saludos.
Miguel.
@aztecmexico “Tu quieres una mejora para la rejilla, yo quiero una mejora para otros objetos”
Como dijo Miguel Delgado, en este caso no es un asunto de simple ‘mejora’, es mas un BUG que se te creen registros en blanco de forma involuntaria.
“Una cosa si me queda clara, ese pequeño bool tiene más impacto a nivel plataforma y arquitectura del que te imaginas, y por algo no lo han hecho,”
Tu mismo dijiste que no deberíamos suponer nada, y aqui dices que te queda claro. Si no estas suponiendo, ¿has visto el código entonces?
Lo que si se puede deducir de manera irrefutable, es que un IF booleana_local=true ELSE … no tendría porque funcionar de una forma en un sistema operativo X, y de otra en uno Y.
Si usaran polimorfismo (la forma mas probable de encarar la multiplataforma), la condición podrían usarla, o antes de llamar a la clase de turno, o dentro de la clase, según les sea mas cómodo, SIN TOCAR NADA DEL RESTO.
Sigo sin imaginarme un escenario de complejidad extrema allí, la verdad.
Nada mas por ahora.
Saludos.
César