
[RESUELTO] Comportamiento diferente al presionar ENTER
#1
Escrito 02 febrero 2011 - 03:16
El asunto es que cuando hago cualquier cambio me manda un error de Stack Overflow, pero sólo si presiono ENTER, si me cambio de casilla con las flechas funciona correctamente y sin errores.
¿ Alguien sabe porque el comportamiento de la tecla ENTER es diferente a las otras ?
No pongo el código porque este asunto es parte de otro hilo donde pregunto sobre la creación de campos calculados en tiempo de ejecución, que me imagino algo tiene que ver con este asunto, mas bien lo que quiero saber es que hace la tecla enter que las demas no hacen.
Salud OS
#2
Escrito 02 febrero 2011 - 03:46
..... mas bien lo que quiero saber es que hace la tecla enter que las demas no hacen.
Salud OS
Mandarte un error !!!!




Lo siento, mi estrés está a todo lo que da, así que necesito reír un poco

Saludox !

#3
Escrito 02 febrero 2011 - 03:52
Yo me se esta adivinanza: ENTER...... mas bien lo que quiero saber es que hace la tecla enter que las demas no hacen.


Estoy como Fenareth

Saludos
#4
Escrito 03 febrero 2011 - 06:04
¿Cuál es el código del evento KeyDown, KeyPress o KeyUp?
#5
Escrito 03 febrero 2011 - 08:46
Saludos.
¿Cuál es el código del evento KeyDown, KeyPress o KeyUp?
No hay tal código, el asunto sucede en el evento OnChange de los campos.
Lo que hago es validar lo que se captura en el campo y actúo en consecuencia, por ejemplo:
if valor1 < 0 then valor1 := 500; if valor1 = 0 then valor1 := 100; valor2 := valor1
Ejemplo:
valor1 = 4
valor2 = valor1
[ENTER] ***OK***
[UP,DOWN,LEFT,RIGHT] ***OK***
valor1 = -1
valor2 = valor1
[ENTER] ***ERROR Overflow***
[UP,DOWN,LEFT,RIGHT] ***OK***
valor1 = 0
valor2 = valor1
[ENTER] ***ERROR Overflow***
[UP,DOWN,LEFT,RIGHT] ***OK***
Es decir, el asunto es cuando valor1 coincide con alguna de las condiciones.
Salud OS
#6
Escrito 04 febrero 2011 - 11:28

Saludos
#7
Escrito 04 febrero 2011 - 11:35
¿Cómo te fue con esto, amigo Egostar? Yo estuve haciendo pruebas sobre un TDBGrid (te sucede en una rejilla ¿verdad?) y no me salta ningún error de ese tipo, ni con ENTER ni con las teclas de cursor, en el OnChange del campo actualizaba tanto su valor como el de otro campo del mismo DataSet, pero no logro reproducir el problema
![]()
Saludos
Que tal amigo Andrés, pues sigo con el problema, sin embargo, no he podido profundizar en el asunto porque he tenido unos días (mas bien noches



No se si el problema tiene que ver que es un ClientDataSet con campos creados en tiempo de ejecución, hoy por la tarde/noche le daré otro vistazo

Salud OS
#8
Escrito 04 febrero 2011 - 11:44
La diferencia entre ENTER y usar las teclas de cursor está en que no se cambia de celda, mira si tienes algún evento sospechoso en el TDBGrid, o prueba de hacer lo mismo desde los TDBEdits, donde ENTER también valida y el tabulador te pasa de uno a otro, a ver si sigue pasando lo mismo ...
... son ideas para cuando tengas tiempo y recuperado parte del sueño, que suele el mejor remedio anti-bugs


#9
Escrito 04 febrero 2011 - 11:50
Lo de OVERFLOW sugiere que entra en un bucle infinito, revisa si en el Campo 2 lanzas otra comprobación del mismo tipo y este a su vez llama a Campo1, aunque tampoco esto aclara mucho de por qué sucede al dar a ENTER.
La diferencia entre ENTER y usar las teclas de cursor está en que no se cambia de celda, mira si tienes algún evento sospechoso en el TDBGrid, o prueba de hacer lo mismo desde los TDBEdits, donde ENTER también valida y el tabulador te pasa de uno a otro, a ver si sigue pasando lo mismo ...
... son ideas para cuando tengas tiempo y recuperado parte del sueño, que suele el mejor remedio anti-bugs![]()
![]()
No había pensado en la tecla Tab, hoy hago la prueba

Y si, necesito dormir, ayer ya no aguanté y me fuí a dormir a la 1AM.

Salud OS
#10
Escrito 07 febrero 2011 - 06:50
He hecho la prueba con la tecla TAB que me has recomendado amigo Andrés y efectivamente el comportamiento es el mismo que el de la tecla ENTER.
Y analizando el punto pensé que tenía que ver con la asignación del evento OnChange del campo, es decir, el proceso que sigue es el siguiente:
1. Cambio el valor del campo
2. Entra al evento OnChange
3. El campo cumple con La condición de filtrado
4. Cambio el valor del campo.
5. Realizo un cálculo con el nuevo valor del campo y lo asigno a otro campo (Error de Overflow)
Bueno, pues era obvio que el problema estaba en la nueva asignación del campo al cumplir la condición de filtrado, por lo que deshabilité momentáneamente el evento OnChange del campo antes de cambiar nuevamente el valor (Paso 4), hago el cálculo correspondiente y ya no mandó error, a finalizar el proceso vuelvo a asignar el evento OnChange al campo.
Intenté realizar esto mismo a través de campos calculados sin resultados satisfactorios. Por el momento no he tenido problemas al respecto y aunque coloco este hilo como resuelto, si hay algunas otras ideas serán bien recibidas.
Muchas Gracias

Salud OS
#11
Escrito 08 febrero 2011 - 01:57
Celebro que hayas resuelto el problema, aunque SIEMPRE nos quedará la duda de por qué sucedía con ENTER y no con las teclas de cursor


Hay que ir con mucho ojo a la hora de asignar eventos OnChange y similares a campos, una de las aspectos más peligrosos de la programación orientada a eventos es que entras en una maraña de eventos que se disparan unos a otros y a los que es muy difícil seguir la pista, obligándonos a mirar la VCL para ver quién llama a quién, cuándo y cómo


Saludos
#12
Escrito 08 febrero 2011 - 02:07
No se nada sobre semáforos, pero si he escuchado el término, le daré una buena leída.

Salud OS
#13
Escrito 08 febrero 2011 - 02:40
lo que se puede hacer en ese caso como bien lo dice Andres es un semaforo o flag, para saber si ya entro o no.
#14
Escrito 09 febrero 2011 - 01:47
Bueno, hay semáforos de muchos tipos, los hay del sistema, pero yo no los he usado. A lo que me refería (ver imagen inferior) es a poner indicadores booleanos, o variables de estado para controlar ciertas situaciones en que quiero evitar que se disparen más eventos de los recomendables. En tu caso deshabilitas el manejador del evento OnChange, otra forma sería poner una variable booleana que evitara cierto código cuando se están realizando otras comprobaciones.No se nada sobre semáforos, pero si he escuchado el término, le daré una buena leída.
![]()
Sí, estoy de acuerdo, lo expresé de pena, con lo de bug me quise referir a que suceda al pulsar la tecla ENTER y no al cambiar con las teclas del cursor, eso me parece extraño, aunque quizás esto también tenga su explicación lógica y tampoco se trate de un bugPienso que no es un bug, porque segun entiendo lo que sucedia es que dentro del evento onchange del campo lo modificaba a el mismo, esto lo que hace es llamarse de nuevo infinitas veces. Por eso el overflow.

Saludos
Archivos adjuntos
#15
Escrito 10 febrero 2011 - 08:34
He tenido un error "tipográfico" y mental al decir que lo estaba haciendo con Delphi 2007, no; el frame lo hice con Turbo Delphi y me parece que me he topado con otro BUG de mi Turbo Delphi, porque ya he incluido el frame en el proyecto completo (que este si está en Delphi2007) y tuve que quitar las lineas de quitar y asignar el evento OnChange, tenia un efecto raro a la hora de dar ENTER, necesitaba 2 ENTER para salir del campo

Pues, nada, muchas gracias por la ayuda

Salud OS
#16
Escrito 12 febrero 2011 - 05:35
Pues habrá que quitarle el tag de [RESUELTO] a este hilo porque empieza a parecerse a uno de esos casos de estudio para la parapsicología y otras ciencias de lo ocultoHola
He tenido un error "tipográfico" y mental al decir que lo estaba haciendo con Delphi 2007, no; el frame lo hice con Turbo Delphi y me parece que me he topado con otro BUG de mi Turbo Delphi, porque ya he incluido el frame en el proyecto completo (que este si está en Delphi2007) y tuve que quitar las lineas de quitar y asignar el evento OnChange, tenia un efecto raro a la hora de dar ENTER, necesitaba 2 ENTER para salir del campo![]()
Pues, nada, muchas gracias por la ayuda![]()
Salud OS




