Xailer & OZ Software

Hola,
Si en un evento ONEXIT se devuelve .f. significa que el foco se mantiene
en ese control.
¿Bajo cuales circunstancias esto no se cumple (que devolviendo .F. el
evento ONEXIT el foco se va vaya a otro control)?
Saludos,
José Luis Capel

Disculpad.... donde pone devuelve .F. quiero decir 'osender:SetFocus()'
> Hola,
>
> Si en un evento ONEXIT se devuelve .f. significa que el foco se mantiene
> en ese control.
>
> ¿Bajo cuales circunstancias esto no se cumple (que devolviendo .F. el
> evento ONEXIT el foco se va vaya a otro control)?
>
> Saludos,
> José Luis Capel

José Luis,
No se puede FORZAR un cambio de foco en un OnExit por motivos obvios.
Un saludo,
"José Luis Capel" <joseluis@iaicom.com> escribió en el mensaje
news:[email=432A801C.5020501@iaicom.com...]432A801C.5020501@iaicom.com...[/email]
> Disculpad.... donde pone devuelve .F. quiero decir 'osender:SetFocus()'
>
>
>> Hola,
>>
>> Si en un evento ONEXIT se devuelve .f. significa que el foco se mantiene
>> en ese control.
>>
>> ¿Bajo cuales circunstancias esto no se cumple (que devolviendo .F. el
>> evento ONEXIT el foco se va vaya a otro control)?
>>
>> Saludos,
>> José Luis Capel

Ignacio,
>
> No se puede FORZAR un cambio de foco en un OnExit por motivos obvios.
>
Tienes razón. Con solo devolver .T./.F. haces que el control pierda o
no el foco.
Entonces la pregunta sigue siendo... ¿bajo cuales circunstancias eso no
se cumple?
Saludos y gracias,
José Luis Capel

José Luis,
Supongo que con un botón lCancel, o cierre del propio formulario. No se me
ocurre ninguno más.
Un saludo,
"José Luis Capel" <joseluis@iaicom.com> escribió en el mensaje
news:432a8428$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> Ignacio,
>
>>
>> No se puede FORZAR un cambio de foco en un OnExit por motivos obvios.
>>
>
> Tienes razón. Con solo devolver .T./.F. haces que el control pierda o no
> el foco.
>
>
> Entonces la pregunta sigue siendo... ¿bajo cuales circunstancias eso no se
> cumple?
>
> Saludos y gracias,
> José Luis Capel

José Luis,
> Entonces la pregunta sigue siendo... ¿bajo cuales circunstancias eso no se
> cumple?
Cuando el foco pasa a un control de otro formulario, tanto si es de la misma
aplicación o de otra. En ese caso no se llega a disparar el OnExit, pero en
cuanto ese formulario vuelve a recibir el foco, es ese control quien lo
recibe.
La otra circunstancia es cuando hay un botón con lCancel = .T.. Acuerdate lo
que vimos en mi casa, y lo fácil que era (usando cierto GUI) saltarse la
validación de un campo en este caso. A raiz de lo que vimos, ahora en
Xailer, al pulsar con el ratón sobre el botón cancel, éste toma el foco.
Pero si sueltas el ratón fuera del botón, entonces el foco vuelve
automáticamente al control que tenía originalmente el foco.
En definitiva, lo mires como lo mires, puedes usar la validación en el
OnExit siempre. Quédate seguro de que un usuario no se la puede saltar
La única excepción es si el usuario cierra el formulario con el botón de
cerrar (la X de la esquina), que tampoco dispara el OnExit. Pero eso también
puedes controlarlo por otro lado.
--
Un saludo,
José F. Giménez

José,
> Cuando el foco pasa a un control de otro formulario, tanto si es de la misma
> aplicación o de otra. En ese caso no se llega a disparar el OnExit, pero en
> cuanto ese formulario vuelve a recibir el foco, es ese control quien lo
> recibe.
Entonces añade estas otras circunstancias:
Situación: tMaskEdit con el Evento ONEXIT que _siempre_ devuelve .F.
a. Si hacemos dobleclick en un arraybrowse se dispara el evento del
arraybrowse.
b. Si hacemos click en un elemento de una optionlist, se dispara el evento.
c. Si hacemos click en un botón de una toolbar se ejecuta la opción.
Os mando un ejemplo (sin incluir la toolbar). Pulsais sobre el botón
'Checkstate True' y haceis click en el primer tMaskEdit. Es el que
tiene el ONEXIT con RETURN .F.
Una vez dentro, no podemos salir de ese control ni con tab, ni con enter
ni con el ratón pulsando sobre cualquier control de ese formulario
excepto en:
a. ArrayBrowse: si haces click, se mueve al registro indicado (pero con
color 'unselected'. Si haces doble click se dispara el evento que tengas.
b. OptionList. Puedes abrir/cerrar las option list. Puedes además
disparar el evento ONCLICK de cualquier elemento.
En cualquiera de los casos, el foco siempre retorna al tMaskEdit con el
ONEXIT a .F.
Desde mi humilde punto de vista, esos eventos no se deben disparar...
Saludos,
José Luis Capel
--

José Luis,
> a. ArrayBrowse: si haces click, se mueve al registro indicado (pero con
> color 'unselected'. Si haces doble click se dispara el evento que tengas.
Sí, tienes razón. Y lo peor no es eso, sino que se puede entrar en edición.
Vamos a corregirlo lo antes posible.
> b. OptionList. Puedes abrir/cerrar las option list. Puedes además
> disparar el evento ONCLICK de cualquier elemento.
Eso sí es normal. La explorerbar y optionlist deben funcionar como las rebar
y toolbar, que no cambian el foco, y por eso ni siquiera se dispara el
OnExit del control que lo tuviera.
--
Un saludo,
José F. Giménez