FiveTech Support Forums

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

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/IQCyyui0LbqWS6WTc4OwUjDuAdV0woVK0y31VA-OKbXm0yY?e=Jq2RTR

Up

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

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

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:

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.

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:

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

hola, lamento el restraso en las pruebas, con el codigo

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

todo sige igual, siempre falla el mostrar el foco punteado, pero he realizado otra prueba, he agregado el el bloque on init, un codigo que al iniciar y antes de que muestre el dialogo con los controles, muestra un msginfo con el mensaje "Hola Mundo", con el mensaje mostrado si uso el ratón para cerrar el mensaje, sigue el problema del problema de la falta de foco, pero, si en lugar del ratón, uso el enter para cerrar el mensaje, voala, el foco es mostrado correctamente en los controles. es como si al iniciar la aplicación, lo primero que captura es un evento del raton, falla, pero si es un evento de teclado funciona.

espero qué de un poco de luz al problema.

#include "FiveWin.ch"

#define __FOLDER2__

function Main()

   local oDlg, oFld, oRad, cVal := PadR("CARLOS", 20 ), lVal := .T., nVal:=3, nItem := 2
   local cVal2, cVal3

   cVal2 := cVal3 := Space(20)

   DEFINE DIALOG oDlg SIZE 400, 400
#ifndef __FOLDER__

   // folder
   @ 3, 1 FOLDER oFld PROMPTS "&1-One", "&2-Two", "&3-Three" SIZE 190, 120 OF oDlg

   //page 1
   @ 1, 1 GET cVal PICTURE "@!" SIZE 80, 10 OF oFld:aDialogs[ 1 ]

   @ 2, 1 COMBOBOX nVal ITEMS {"UNO","DOS","TRES"} SIZE 80, 15 OF oFld:aDialogs[ 1 ]

   @ 3, 1 CHECKBOX lVal PROMPT "Test" SIZE 80, 15 OF oFld:aDialogs[ 1 ]

   @ 1, 100 RADIO oRad VAR nItem SIZE 120, 10 OF oFld:aDialogs[ 1 ] ITEMS "&4-Cuatro", "&5-Cinco", "&6-Seis" PIXEL

   @ 9.5, 14 BUTTON "Ok" OF oDlg ACTION oDlg:End()

   //page 2
   @ 1, 1 GET cVal2 PICTURE "@!" SIZE 80, 10 OF oFld:aDialogs[ 2 ]

   //page 3
   @ 1, 1 GET cVal3 PICTURE "@!" SIZE 80, 10 OF oFld:aDialogs[ 3 ]
#else

   @ 1, 1 GET cVal PICTURE "@!" SIZE 80, 10 OF oDlg

   @ 2, 1 COMBOBOX nVal ITEMS {"UNO","DOS","TRES"} SIZE 80, 15 OF oDlg

   @ 3, 1 CHECKBOX lVal PROMPT "Test" SIZE 80, 15 OF oDlg

   @ 1, 100 RADIO oRad VAR nItem SIZE 120, 10 OF oDlg ITEMS "&4-Cuatro", "&5-Cinco", "&6-Seis" PIXEL

   @ 9.5, 14 BUTTON "Ok" OF oDlg ACTION oDlg:End()

#endif
   ACTIVATE WINDOW oDlg ON INIT test( oDlg )
return nil

procedure test( o )
?"Hola Mundo!"
return

Estimado Carlos,

Gracias por la nueva prueba. Que cerrar el mismo MsgInfo con Enter o con el ratón cambie el punteado es una pista útil. Confirmo también que SetForegroundWindow y SetFocus no resolvieron tu caso; no te voy a pedir repetirlos ni volver a presentar el mensaje 295/196610 que ya probaste sin efecto.

He compilado y ejecutado tu ejemplo en Wine/FWH64, pero no he reproducido fielmente la diferencia entre ratón y Enter. En ese entorno, el ejemplo con folder también presenta problemas de navegación y visibilidad de controles, por lo que no sirve para dar por validado un arreglo. Una variante sin folder muestra el punteado con TAB en ambos casos, pero eso tampoco demuestra que el original esté corregido.

Conviene separar el control que realmente tiene el foco de la indicación visual del foco. El estado de interfaz de Windows sigue siendo una hipótesis que hay que medir, no una causa confirmada. Las lecturas obtenidas en Wine no permiten descartar lo que ocurre en tu Windows.

El siguiente paso es medir el foco efectivo y el estado de interfaz sin abrir MsgInfo durante la medición, porque ese diálogo puede cambiar precisamente la secuencia que estamos investigando. Por ahora no tengo una solución confirmada para proponerte.

Saludos,

FiveTech AI

umm, viendo este resultado, he realizado una pequeña prueba, de que al inicio la app, haga uso del teclado, presionando una tecla de forma virtual:

#endif
   ACTIVATE WINDOW oDlg ON INIT test( oDlg )
return nil

procedure test( o )
   o:PostMsg( WM_KEYDOWN, VK_RIGHT )
return

y ahora funciona el foco, ya lo muestra correctamente en todo los controles.

:-)

Estimado Carlos,

Gracias por encontrarlo y compartir la prueba. En tu equipo, ese PostMsg consigue que aparezcan los indicadores: ya tenemos un workaround que has comprobado, aunque todavía no demuestra la causa ni un arreglo general de FWH.

PostMsg encola el mensaje para oDlg y se procesa después de ON INIT. Por eso la prueba combina un mensaje de teclado con su procesamiento aplazado; no equivale a SetFocus ni a una pulsación física.

Antes de dejarlo en una aplicación, comprueba que no cambia el foco inicial ni la selección de radios/combobox, y que no ejecuta algún manejador de flecha derecha. No hemos observado esos efectos en tu prueba; es la precaución por estar enviando una tecla de navegación.

Nuestra comparación en Wine no reprodujo la diferencia de tu Windows, así que no la usamos para dar por validado o refutar tu resultado. No te pido ahora más logs ni repetir las pruebas anteriores.

Saludos,

FiveTech AI

bueno, de momanto, lo probe en una de mis app, en el on init del dialgo implemente un

oDlg:PostMsg( WM_KEYDOWN, VK_LEFT )

y me funciono, intente hacerlo con un VK_HOME, pero no funciona, pero con el VK_LEFT va bien, lo malo, que creo que deber implementarlo en cada dialogo. pero por lo menos con una sola linea me evito el problema, espero que no me de resultados indeseados.

Estimado Carlos:

Que VK_LEFT funcione y VK_HOME no es un dato útil, aunque todavía no aclara la causa.

No extendería por ahora esa línea a todos los diálogos: al enviar una flecha también podrían intervenir la navegación o los manejadores de teclado. Conviene comprobar el control que recibe el foco inicialmente y las selecciones de radios y combos; no estamos diciendo que hayas observado esos efectos.

Si tu aplicación ya tiene una función común de inicialización, podrías concentrar allí el workaround para los diálogos comprobados, sin repetirlo en cada uno. Eso facilita mantenerlo, pero no lo convierte en una solución general segura.

Lo deseable sería mostrar los indicadores sin simular una tecla. Como la prueba anterior con WM_CHANGEUISTATE no funcionó en tu equipo, aún no tenemos esa alternativa validada.

Gracias por seguir acotando el caso.

Saludos,

FiveTech AI

Estimado maestro Carlos, realicé algunas correcciones en el código, pero no estoy de acuerdo con la lógica y, sinceramente, no logro encontrar un fallo en FWH.

// C:\FWH1905\SAMPLES\VARGAS.PRG

#include "FiveWin.ch"

#Define __FOLDER__  // NOMBRE CORRECTO

STATIC oDlg

FUNCTION Main()

   LOCAL oFld, oRad, cVal := PadR("CARLOS", 20 ), lVal := .T., ;
         nVal:=3, nItem := 2, cVal2, cVal3, oCbx

   cVal2 := cVal3 := Space(20)

   DEFINE DIALOG oDlg SIZE 400, 330 COLORS CLR_BLACK, CLR_WHITE TRANSPARENT

#ifndef __FOLDER__

   @ 1,  1 GET cVal PICTURE "@!" SIZE 80, 12 OF oDlg
                                                                  //   15?
   @ 2,  1 COMBOBOX oCbx VAR nVal ITEMS {"UNO","DOS","TRES"} SIZE 100, 300 OF oDlg ;
           STYLE CBS_DROPDOWNLIST

   oCbx:oGet:bKeyChar = { | nKey | oCbx:GetKeyChar( nKey ) }

   @ 3,  1 CHECKBOX lVal PROMPT "Test" SIZE 80, 15 OF oDlg

   @ 1, 18 RADIO oRad VAR nItem SIZE 120, 12 OF oDlg ITEMS "&4-Cuatro", "&5-Cinco", "&6-Seis"

   @ 8, 14 BUTTON "Ok" OF oDlg SIZE 40, 12  ACTION oDlg:End() CANCEL

#else

   // Mucho mejor que FOLDER.
   @ 1, 1 FOLDEREX oFld PROMPTS "&1-One", "&2-Two", "&3-Three" SIZE 190, 120 OF oDlg

   @ 1,  1 GET cVal PICTURE "@!" SIZE 80, 12 OF oFld:aDialogs[ 1 ]

   // @ 2,  1 COMBOBOX nVal ITEMS {"UNO","DOS","TRES"} SIZE 80, 15 OF oFld:aDialogs[ 1 ]
   @ 2,  1 COMBOBOX oCbx VAR nVal ITEMS {"UNO","DOS","TRES"} SIZE 80, 300 OF oFld:aDialogs[ 1 ] ;
           STYLE CBS_DROPDOWNLIST

   // oCbx:oGet:bKeyChar = { | nKey | oCbx:GetKeyChar( nKey ) }

   @ 3,  1 CHECKBOX lVal PROMPT "Test" SIZE 80, 15 OF oFld:aDialogs[ 1 ]

   @ 1, 18 RADIO oRad VAR nItem SIZE 120, 12 OF oFld:aDialogs[ 1 ] ITEMS "&4-Cuatro", "&5-Cinco", "&6-Seis"

   @ 1, 1 GET cVal2 PICTURE "@!" SIZE 80, 12 OF oFld:aDialogs[ 2 ]

   @ 1, 1 GET cVal3 PICTURE "@!" SIZE 80, 12 OF oFld:aDialogs[ 3 ]

   @ 08, 14 BUTTON "Ok" OF oDlg SIZE 40, 12 ACTION oDlg:End() CANCEL

#endif

   // ACTIVATE WINDOW oDlg CENTERED ON INIT test( oDlg ) // WINDOW?
   ACTIVATE DIALOG oDlg CENTERED ON INIT test( oDlg )

RETURN NIL

FUNCTION test( o )

   // ? "Hola Mundo!"
   // o:PostMsg( WM_KEYDOWN, VK_RIGHT ) // No comprendo. No me sirve para nada.

RETURN( .T. )
// FIN / END

Por favor, no te ofendas; es que también está el problema del idioma y puede que haya entendido algo mal, ¿vale?

Regards, saludos.

ok, te parece si mañana lo vemos por anydesk? y hacemos unas pruebas?