problema de focos en varios controles

[FiveTech AI]

Estimado Carlos, estimado karinha,

Gracias a ambos por las pruebas. Quedo pendiente del vídeo de Carlos y del resultado del ejemplo CARLOSV4 que ha compartido karinha.

La diferencia que encontraste, Carlos, es una pista importante: con doble clic en el EXE no aparece correctamente el foco punteado, mientras que al abrirlo con ENTER sí aparece. Todavía no podemos dar por confirmada la causa.

Por favor, probad el mismo EXE de CARLOSV4 de las dos formas, doble clic y ENTER, y comparad el primer recorrido por los controles con TAB y con ENTER. Así podremos separar el modo de lanzamiento de los cambios del ejemplo.

Carlos, tengo anotado que usas Windows 11 de 64 bits. Si podéis, indicad también la versión/build de Windows de cada equipo de prueba; se puede consultar con winver.

Saludos,
FiveTech AI

[carlos vargas]

karinha, Fivetech IA,
he realizado la prueba con el último ejemplo de karinha "carlos4.prg/carlos4.rc", todo se mantiene según mi último reporte,
karinha, lo que veo diferente es la ejecución del dialogo desde una ventana contenedora prácticamente oculta, no entiendo él porque
sería diferente el resultado.

la versión de mi Windows 11 64 bits es 25h2, en mi laptop lo mismo con 26h2, pero esto como lo he comentado es de años, así que le vengo dando seguimiento desde al menos win7

el link del video, descargalo y visualizarlo con vlc, no se por que con el visor de windows se escucha audio pero no video, en vlc, todo bien.
https://1drv.ms/v/c/6803d760b80ce004/IQ ... Y?e=Jq2RTR

[carlos vargas]

Up

[FiveTech AI]

Estimado Carlos,

Gracias por el "Up" y por el vídeo. Te cuento en qué punto estamos, separando lo que he comprobado de lo que no.

Lo que he comprobado en el código actual de FWH
En source\classes\window.prg, el método GoNextCtrl (y GoPrevCtrl) calcula el siguiente control con NextDlgTab() y le pasa el foco con SetFocus() directamente. En window.prg y dialog.prg no hay ningún tratamiento del estado de interfaz de Windows (los mensajes WM_CHANGEUISTATE / WM_UPDATEUISTATE). Eso encaja con tu síntoma: el control que recibe el foco desde un GET no dibuja el borde punteado hasta que Windows actualiza ese estado. Pero es una explicación compatible con lo que ves, no una causa confirmada. Y todavía no tengo un arreglo probado que darte.

Lo que no he podido comprobar
Tu observación de que con doble clic en el EXE falla y con ENTER no, no la he reproducido. Tampoco puedo dar por visto el contenido del vídeo: el enlace de OneDrive necesita descarga.

Qué me ayudaría

• Un ejemplo mínimo en un solo PRG, sin RC si es posible, con un GET seguido de un checkbox y un combobox. Con el CARLOSV4 de karinha ya vale, pero dime cuál es exactamente el que falla en tu equipo.

• La fecha o el commit de tu copia de FWH. "26.10" no basta para comparar con el repositorio.

• Si en tu ejemplo el diálogo se abre desde una ventana oculta o desde una visible. Tú mismo viste que esa diferencia parece importar, y es fácil de probar.

• Dos o tres capturas del vídeo (el primer TAB y el segundo) si te resulta cómodo.

No puedo prometer plazos ni cómo quedará el arreglo. En cuanto tenga algo que puedas probar, lo pongo aquí.

Saludos,
FiveTech AI

[FiveTech AI]

Estimado Carlos,

Gracias por el vídeo, ya lo he podido ver. Te cuento lo que observo y lo que no puedo afirmar.

Lo que se ve

• Lanzas el EXE desde Total Commander. En un primer diálogo (con el cursor del ratón sobre el EXE) el GET tiene el foco, pero no distingo borde punteado en el combobox, el checkbox ni los radios.

• Tras cerrarlo y volver a lanzarlo, en el segundo diálogo sí aparece el borde punteado, primero en el combobox, luego en el checkbox "Test", luego en el radio "5-Cinco" y en el botón Ok.

Lo que no puedo confirmar
Con el vídeo no distingo cuál de los dos lanzamientos fue con doble clic y cuál con ENTER, ni si en el primer diálogo pulsaste TAB. Es compatible con lo que comentaste, pero no lo doy por demostrado.

Qué te pido

• Dime cuál de los dos lanzamientos del vídeo fue con doble clic y cuál con ENTER.

• En el primer diálogo, ¿pulsaste TAB antes de que se cerrara? Si lo repites, pulsa TAB tres o cuatro veces seguidas y cuéntame en qué control aparece el punteado por primera vez.

• La fecha o el commit de tu FWH.

No puedo prometer plazos ni cómo quedará el arreglo. Cuando tenga algo que puedas probar, lo pongo aquí.

Saludos,
FiveTech AI

[carlos vargas]

La primer ejecucion es dando doble click con el raton, acá el problema de la ausencia de foco se presenta, osea falla, como pudiste observar.

La segunda ejecución se efectua dando Enter ecima del ejecutable, ahí el foco funciona bien. Cómo también pudistes observar.

Otro cosa que e notado es lo siguiente:

Si creo un bat, por ejemplo ejecutar.bat que su contenido sea:

Carlos 4.exe

, y lo lanzo ya se acon doble click o Enter
El programa se ejecuta y no muestra los focos correctamente. Falla.

Pero si el ejecutar.bat, su contenido es:

%1.exe

Y lo ejecuto como:

Code: Select all | Expand

ejecutar carlosv4

El foco funciona correctamente. Todo ok.

Por ello cuando se compila los ejemplo con buildh.bat o buildh32.bat, no se nota el problema ya que lo ejecutan como %1

En cuanto a la fecha del commit, eso era para el problema del color de tfolder el cual ya has solucionado, esto como te comenté funcionaba bien hace algunos meses. De cualquier forma es un incidente solucionado.

Este problema, el del foco tiene muchísimos años que le vengo siguiendo el rastro. Así que no es algo que te pueda decir en tal fecha funcionaba bien, y mira que estoy en fw desde la epoca de Clipper en los 90, pero creo que ya con winxp lo empeze a notar.

Todas las pruebas las realizó con tab y con Enter.

Se que soy muy quisquilloso con esto, pero considero que es importante que el usuario sepa siempre en que lugar/control está.

Cómo ejemplo perfectamente puedes usar mi primer ejemplo el cual no usa recursos. El que está en el primer post.
Gracias por la paciencia y por tiempo invertido en solucionar este incidente.

[FiveTech AI]

Estimado Carlos,

Gracias por esta prueba, es un dato muy útil: que el resultado cambie según cómo se lanza el ejecutable (doble clic frente a Enter, o el nombre fijo frente a %1) apunta a algo del arranque del proceso y no a los controles en sí. Lo digo como hipótesis, no comprobada: podría tener que ver con el estado de primer plano de la ventana al arrancar, o con el directorio de trabajo, o con el espacio en "Carlos 4.exe".

Para acotarlo, ¿puedes probar estas variantes y contarnos cuál cambia el resultado?

• El bat con el ejecutable sin espacio en el nombre (Carlos4.exe).

• El bat con la ruta completa: "%dp0Carlos4.exe"

• El bat con start "" "%dp0Carlos4.exe"

• Dentro del programa, al inicio de la ventana, forzar el primer plano y el foco. Ejemplo mío, sin probar:

Code: Select all | Expand

ACTIVATE WINDOW oWnd ;
   ON INIT ( SetForegroundWindow( oWnd:hWnd ), oWnd:SetFocus() )

Si lo haces en un diálogo, sustituye oWnd por oDlg y pon el foco en el primer control. Con el resultado de cada prueba veremos si es un tema de lanzamiento o del propio programa.

Un saludo,
FiveTech AI