Problema: un campo objeto texto, se inicializa a valor “1” sin venir a cuento.
Empiezo a buscar donde coño le añado el 1 al objeto texto, pero nada, el campo solo se usa en tres sitios, y nada de modificaciones (es un campo tecleado por el usuario).
Y venga a buscar, y venga a buscar… ni puta idea quien esta modificando ese campo. Yo no (al menos sabiendolo). Nada en los triggers, nada buscando +“1” en contenidos, na de na…
Por probar, hago un “Crear nueva ficha en memoria”, y sin modificar nada, hago un IF CAMPO_CABRON=“1” THEN MENSAJE. Bueno pues el puto mensaje sale. Los objetos texto no tiene valor inicial… Un poco raro, no?
Desesperado, se me ocurre la feliz idea de cambiarle el tipo al campo, y ponerlo alfa256. TACHAN, TACHAN. APARECIO.
EL PUTO 1 ESTABA PUESTO EN EL VALOR INICIAL DEL CAMPO ALFA, PERO AL CAMBIAR A OBJETO TEXTO LO OCULTA, PERO SIGUE OPERATIVO.
ME ENCANTA VELNEO. CADA VEZ MEJOR. Ademas, era un 1 numero, sin comillas.
VAMOS A MAS SIN DUDA, A MAS DESESEPERACION PARA LOS PROGRAMADORES. MEDIA MAÑANA PERDIDA POR ESTA GILIPOLLEZ.
HASTA EL CULO DE LOS PROBLEMAS CON LAS PROPIEDADES OCULTAS.
Esa “propiedad” me costó, en su momento, 3 días de trabajo e informé a soporte hace seguramente más de 2 años…
La solución debería ser tan simple como eliminar todas las propiedades no relevantes al tipo de objeto finalmente elegido al grabar el proyecto. Esta misma mañana me ha pasado que un Campo de una Tabla se usaba en un texto estático. Como ya me lo sé, cambié el tipo de objeto (que seguramente en su día era de tipo “Nombre de Campo”) y allí estaba…
El asunto en ocasiones simplemente molesta (como cuando un Campo de una Tabla aparece como usado en un texto estático) y otras veces directamente putea.
Para que lo resuelvan vamos a tener que poner una idea…
La idea consiste en que esten todas las propiedades de un objeto SIEMPRE visibles, pero estas estén ACTIVAS o NO ACTIVAS en funcion de otras propiedades definidas.
Estaria bien que las propiedades de los campos, esten activas o no activas, en funcion de si corresponde al tipo de campo seleccionado o no.
Por ejemplo, en una rejilla, cuando indicamos Pie activo = Verdadero, aparece una propiedad más para el pie, que es el Alto de pie.
A mi también me ha hecho perder tiempo esta situación.
Pero si usted le reclama a Velneo diciendolo que desde nuestro punto de vista es algo que deberían corregir en la próxima actualización ellos le responden que hay otras cosas mas importantes o delicadas que afectan a mas personas y que por eso estas situaciones ellos las consideran menores y que dan espera y las dejan allí sin resolver por años. Mientras tanto a nosotros nos toca perder muchas veces perder horas y quizas días de trabajo por algo que ellos bien pueden arreglar prontamente.
Estoy de acuerdo con la idea de Mgalvezh de mandar un número interesante de soportes (quizas 5000) para ver si de esa manera nos prestan atención.
No se, a mi me cuesta creer que sea facil de resolver y simplemente pasen de hacerlo.
Mas bien me inclino a pensar, que por problemas de la arquitectura interna de Velneo,
que nosotros desconocemos, pues son bugs mas bien complicados de resolver. O sea,
que si arreglan eso pueden estropear algo por otro sitio, mas importante.
O simplemente son las QT que funcionan asi y punto. Sabe dios (mejor dicho, Velneo).
Eso si, no me imagino que “problema de arquitectura” impide aplicar alguna solucion al tema,
por ejemplo la propuesta por Ramiro.
estoy de acuerdo y es un problema que yo también he reportado.
Pero también resulta que por accidente cambias es tipo de campo y tiene propiedades complicadas de reproducir, no puedes volver a los valores iniciales si al cambiarlo, los borra: Mi propuesta:
Como el cambio de esta propiedad es algo que no se hace de rutina porque se preselecciona antes de que se muestren las propiedades, debería de pedir confirmación antes y al salir de la edición de la propiedad, diciendo que se van a perder las propiedades no coincidentes y, desde luego, en caso de confirmación, borrarlas en el nuevo campo
