Propiedad lTabStop y lFocused

[aureliano.sanchezc]

Buenos dias
Hemos observado un comportamiento incoherente en al menos dos tipos de
controles (TMaskEdit y TSearchComboBox) que posiblemente sea debido a
algun tipo de error en las pruebas realizadas pero que me gustaria
exponer por existir la posibilidad de que sea debido a una incoherencia
entre los metodos y las datas de dichos controles.
La prueba realizada ha sido poner a ambos controles la propiedad
lTabStop a .F. y chequear el valor de la variable lFocused en los
diferentes estados del control (seleccionado y no seleccionado) mediante
la captura de la pulsación de una tecla.
El resultado fue que cuando la propiedad lTabStop era definida como .F.
la propiedad lFocused siempre arroja .F. esté o no esté el control
seleccionado.
Si por el contrario definimos lTabStop a .T. la propiedad lFocused
refleja perfectamente el estado del control devolviendo .T. en el caso
de estar seleccionado el control y .F. en el caso de no estarlo.
Agradeceriamos al equipo de Xailer revisara dicho comportamiento cuando
tenga oportunidad y comentara el resultado
Gracias de antemano
Un saludo

[jfgimenez]

Aureliano,
sí­, tiene razón en ese comportamiento aparentemente erróneo, pero que fue
necesario en su momento para poder controlar correctamente el comportamiento
de los eventos OnExit de los controles (no entraré en detalles porque es un
tema bastante complejo). No obstante, lo revisaremos para intentar reflejar
correctamente el estado del control. Gracias por el aviso.
Por cierto, si lo necesita urgentemente, puede controlar si un control tiene
el foco usando la función GetFocus(). P.ej.:
IF GetFocus() == ::oEdit1:Handle
...
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[aureliano.sanchezc]

Jose F. Gimenez,
Gracias por la pronta respuesta. Probaré la opción que me indica aunque
como comenté en un post anterior aun estamos en fase de evaluación del
producta y por tanto la necesidad aun no existe.
Un saludo
> Aureliano,
>
> sí­, tiene razón en ese comportamiento aparentemente erróneo, pero que
> fue necesario en su momento para poder controlar correctamente el
> comportamiento de los eventos OnExit de los controles (no entraré en
> detalles porque es un tema bastante complejo). No obstante, lo
> revisaremos para intentar reflejar correctamente el estado del control.
> Gracias por el aviso.
>
> Por cierto, si lo necesita urgentemente, puede controlar si un control
> tiene el foco usando la función GetFocus(). P.ej.:
>
> IF GetFocus() == ::oEdit1:Handle
> ...
>

[aureliano.sanchezc]

Jose F. Giemenez,
Como le comente no existe la necesidad solamente estamos comprobado.
Dicho esto hemos intentado seguir su indicación con el siguiente resultado :
En la metodo onKeyDown de un objeto oSearchComboBox hemos incluido el
siguiente codigo :
msginfo(::oSearchComboBox1:Handle,"Combobox")
msginfo(getfocus(),"GetFocus")
debiendo dar ambos el mismo resultado , cosa que muy a nuestro pesar no
conseguimos, dando valores distintos.
El resultado es el mismo si dicho codigo lo introducimos en el metodo
onKeyDown del formulario en lugar del control a vigilar.
Gracias por todo
Un saludo
Jose F. Gimenez escribió:
> Aureliano,
>
> sí­, tiene razón en ese comportamiento aparentemente erróneo, pero que
> fue necesario en su momento para poder controlar correctamente el
> comportamiento de los eventos OnExit de los controles (no entraré en
> detalles porque es un tema bastante complejo). No obstante, lo
> revisaremos para intentar reflejar correctamente el estado del control.
> Gracias por el aviso.
>
> Por cierto, si lo necesita urgentemente, puede controlar si un control
> tiene el foco usando la función GetFocus(). P.ej.:
>
> IF GetFocus() == ::oEdit1:Handle
> ...
>

[jfgimenez]

Aureliano,
> En la metodo onKeyDown de un objeto oSearchComboBox hemos incluido el
> siguiente codigo :
>
> msginfo(::oSearchComboBox1:Handle,"Combobox")
> msginfo(getfocus(),"GetFocus")
>
> debiendo dar ambos el mismo resultado , cosa que muy a nuestro pesar no
> conseguimos, dando valores distintos.
Da valores distintos porque al mostrar el mensaje, el foco ya ha cambiado a
la ventana del mensaje, y ya no está en el control. Para evitar estos
cambios de foco no deseados y que llevan a conclusiones erróneas, lo mejor
es utilizar la función LogDebug(), que muestra el resultado en la ventana
del debugger del IDE.
Por otro lado, el evento OnKeyDown de un control determinado sólo se puede
disparar si ese control tiene el foco. Por lo tanto, se puede tener la
certeza de que sí­ tiene el foco. Distinto es en el caso de ese mismo evento
pero para un control contenedor o el mismo formulario. El funcionamiento
general de Xailer con respecto al teclado es que cuando un control recibe
una pulsación de tecla, se dispara su evento OnKeyDown, y si la tecla no es
procesada se envia a su "padre" (el control que lo contiene). Si su "padre"
tampoco lo procesa, se vuelve a enviar al "padre" de su "padre", y así­
sucesivamente hasta llegar al formulario, que es el último que intenta
procesarla.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[aureliano.sanchezc]

Jose F. Gimenez,
Gracias por la información aportada en lo referente al comportamiento en
general de Xailer con respecto al teclado.
¿ Es asi su comportamiento en todos los aspectos ?
Jose F. Gimenez escribió:
> Aureliano,
>
>> En la metodo onKeyDown de un objeto oSearchComboBox hemos incluido el
>> siguiente codigo :
>>
>> msginfo(::oSearchComboBox1:Handle,"Combobox")
>> msginfo(getfocus(),"GetFocus")
>>
>> debiendo dar ambos el mismo resultado , cosa que muy a nuestro pesar
>> no conseguimos, dando valores distintos.
>
> Da valores distintos porque al mostrar el mensaje, el foco ya ha
> cambiado a la ventana del mensaje, y ya no está en el control. Para
> evitar estos cambios de foco no deseados y que llevan a conclusiones
> erróneas, lo mejor es utilizar la función LogDebug(), que muestra el
> resultado en la ventana del debugger del IDE.
>
> Por otro lado, el evento OnKeyDown de un control determinado sólo se
> puede disparar si ese control tiene el foco. Por lo tanto, se puede
> tener la certeza de que sí­ tiene el foco. Distinto es en el caso de ese
> mismo evento pero para un control contenedor o el mismo formulario. El
> funcionamiento general de Xailer con respecto al teclado es que cuando
> un control recibe una pulsación de tecla, se dispara su evento
> OnKeyDown, y si la tecla no es procesada se envia a su "padre" (el
> control que lo contiene). Si su "padre" tampoco lo procesa, se vuelve a
> enviar al "padre" de su "padre", y así­ sucesivamente hasta llegar al
> formulario, que es el último que intenta procesarla.
>

[aureliano.sanchezc]

Jose F. Gimenez,
No quisiera aburrir con el tema, pero nos parece importante tener una
vision clara de como funciona a nivel general los metodos de los
diferentes objetos en sus diferentes niveles.
Hemos realizado una prueba en el siguiente escenario :
Un formulario con varios controles y deseamos cerrar el formulario
cuando se pulsa la tecla Esc EXCEPTO cuando el objeto oSearchComboBox1
tenga el foco.
Para ello hemos implementado el siguiente codigo en los eventos
OnKeyDown de los objetos SearchComboBox y Form.
METHOD SearchComboBox1KeyDown( oSender, nKey, nFlags ) CLASS TPro
if nkey= 27
msginfo("paso por key combo")
endif
RETURN Nil
METHOD FormKeyDown( oSender, nKey, nFlags ) CLASS TPro
if nkey= 27 .and. (getfocus() != ::oSearchComboBox1:Handle)
msginfo("paso por key formulario")
::Close()
endif
RETURN Nil
El resultado ha sido el siguiente :
Por un lado aunque la tecla la procese el objeto hijo TAMBIEN es
procesada por el objeto padre. Al pulsar Esc en el objeto SearchComboBox
nos muestra los dos msginfo()
Por otro lado la expresion (getfocus() != ::oSearchComboBox1:Handle)
sigue evaluandola como .F. aunque sea el objeto oSearchComboBox1 el que
posea el foco.
Un saludo
Jose F. Gimenez escribió:
> Aureliano,
>
>> En la metodo onKeyDown de un objeto oSearchComboBox hemos incluido el
>> siguiente codigo :
>>
>> msginfo(::oSearchComboBox1:Handle,"Combobox")
>> msginfo(getfocus(),"GetFocus")
>>
>> debiendo dar ambos el mismo resultado , cosa que muy a nuestro pesar
>> no conseguimos, dando valores distintos.
>
> Da valores distintos porque al mostrar el mensaje, el foco ya ha
> cambiado a la ventana del mensaje, y ya no está en el control. Para
> evitar estos cambios de foco no deseados y que llevan a conclusiones
> erróneas, lo mejor es utilizar la función LogDebug(), que muestra el
> resultado en la ventana del debugger del IDE.
>
> Por otro lado, el evento OnKeyDown de un control determinado sólo se
> puede disparar si ese control tiene el foco. Por lo tanto, se puede
> tener la certeza de que sí­ tiene el foco. Distinto es en el caso de ese
> mismo evento pero para un control contenedor o el mismo formulario. El
> funcionamiento general de Xailer con respecto al teclado es que cuando
> un control recibe una pulsación de tecla, se dispara su evento
> OnKeyDown, y si la tecla no es procesada se envia a su "padre" (el
> control que lo contiene). Si su "padre" tampoco lo procesa, se vuelve a
> enviar al "padre" de su "padre", y así­ sucesivamente hasta llegar al
> formulario, que es el último que intenta procesarla.
>

[aureliano.sanchezc]

Hubo una errata en el mensaje anterior debiendo quedar el parrafo de la
siguiente forma
Por otro lado la expresion (getfocus() != ::oSearchComboBox1:Handle)
sigue evaluandola como .T. aunque sea el objeto oSearchComboBox1 el que
posea el foco. Si la evaluara como .F. ( serian iguales) no mostraria el
msginfo("paso por key formulario")
Disculpen la errata
Un saludo
ASC escribió:
> Por otro lado la expresion (getfocus() != ::oSearchComboBox1:Handle)
> sigue evaluandola como .F. aunque sea el objeto oSearchComboBox1 el que
> posea el foco.
>
> Un saludo

[jfgimenez]

Aureliano,
> ¿ Es asi su comportamiento en todos los aspectos ?
Hay muchas cosas y muchas veces unas cosas no tienen nada que ver con otras.
En cualquier caso, tratamos de ser coherentes con los comportamientos
generales de Xailer. Es decir, hay una serie de patrones de comportamiento
que tratamos de seguir en todo lo posible. Con respecto al manejo del
teclado, el comportamiento es el que apuntaba, pero en otras áreas hay otras
reglas.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[jfgimenez]

Aureliano,
> Por un lado aunque la tecla la procese el objeto hijo TAMBIEN es procesada
> por el objeto padre. Al pulsar Esc en el objeto SearchComboBox nos muestra
> los dos msginfo()
Uno de los patrones de comportamiento que indicaba en el otro mensaje tiene
que ver con el procesamiento de los eventos. La regla general es que si un
determinado evento no está asignado, o bien sí­ está asignado pero devuelve
el valor NIL, entonces Xailer actúa procesando él mismo el evento de forma
predeterminada.
En el ejemplo anterior, al retornar NIL en el evento OnKeyDown, Xailer asume
que debe ser él el que continue procesando el evento, y al tratarse de
OnKeyDown lo que hace es pasarle la pulsación de la tecla al formulario. Si
en vez de retornar NIL se retorna otro valor (p.ej. 0), entonces Xailer da
por finalizado el procesamiento del evento, y en ese caso no enviarí­a la
tecla al formulario.
Lógicamente, cada evento es distinto, y aunque la regla de dar por
finalizado el evento o continuar procesándolo depende directamente de si se
retorna NIL u otro valor, lo que haga Xailer después dependerá directamente
del evento implicado. En muchas ocasiones, el valor de retorno del evento
simplemente se envia a windows, sin que Xailer haga nada más.
> Por otro lado la expresion (getfocus() != ::oSearchComboBox1:Handle) sigue
> evaluandola como .F. aunque sea el objeto oSearchComboBox1 el que posea el
> foco.
Sí­, es cierto. Eso se debe a que un combo de estilo csDROPDOWN contiene
dentro de él a un control EDIT estándar, que es quien en realidad tiene el
foco.
No obstante, ya hemos corregido el problema de la propiedad lFocused y
publicaremos la corrección cuanto antes. Por lo tanto, se podrá usar
lFocused de forma totalmente fiable para saber si un control determinado
tiene el foco. También la propiedad oActiveControl del formulario refleja
correctamente qué control tiene el foco.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[zeasoftware]

METHOD FormKeyDown( oSender, nKey, nFlags ) CLASS TPro
if nkey= 27 .and. (getfocus() != ::oSearchComboBox1:Handle)
msginfo("paso por key formulario")
::Close()
Return ( 0 ) <-----Anexa esto para que ya no siga procesando
la tecla ESC.
endif
RETURN Nil
Saludos.
--
Ramón Zea
01.993.231-62-29
http://www.paginasprodigy.com/zeasoftware/
zeasoftware@prodigy.net.mx
zeasoftware@hotmail.com
ramonzea@yahoo.com
zeasoft.movil@hotmail.com