FiveTech Support Forums

Buenos días,

Compensatorio porque compensa la ausencia/ olvido de :unlink().
El tema está relacionado con lo anterior y el hecho de que Windows recicla ID de hWnd. Cuando se juntan los olvidos y el reciclaje necesario, entonces los botones dejan de funcionar

Este arreglo soluciona el problema.

Estimado hmpaquito:

Muchas gracias por compartir el hallazgo y por la captura: ayuda mucho a entender el problema. Hemos contrastado tu planteamiento con el código fuente de FWH (clase TWindow, window.prg) y esto es lo que vemos.

Qué hace hoy TWindow:UnLink()

METHOD UnLink() CLASS TWindow

   local nAt := AScan( aWindows,;
                       { | o | ValType( o ) == "O" .and. o:hWnd == ::hWnd } )

   if ::nOldProc != nil .and. ::hWnd != 0
      RestProc( ::hWnd, ::nOldProc )
      ::nOldProc = nil
   endif

   if nAt > 0 .and. nAt <= Len( aWindows )
      aWindows[ nAt ] = 0
   endif

return nil

• Link() guarda Self en el primer hueco libre (un 0) de la tabla estática aWindows y subclasifica la ventana pasando ese índice a XChangeProc().
• UnLink() restaura el procedimiento original de la ventana y pone a 0 su posición en aWindows para que pueda reutilizarse.
• Destroy() llama a ::UnLink() solo si ::hWnd no está vacío y al final pone ::hWnd = 0. Es el único sitio de la propia librería que llama a UnLink().

Tu cambio

local nAt := AScan( aWindows,;
                    { | o | ValType( o ) == "O" .and. o == Self } )

Tu razonamiento es correcto. La versión actual busca por el valor de hWnd y se queda con la primera coincidencia. Si una ventana anterior quedó en la tabla sin hacer UnLink (se destruyó sin pasar por Destroy(), o una clase derivada lo sobrescribe sin llamar a Super) y Windows reutiliza el mismo valor de hWnd para una ventana nueva, en aWindows hay dos objetos con el mismo hWnd. Al cerrar la nueva, UnLink libera la posición de la antigua y deja la de la nueva ocupada. Buscar por identidad del objeto evita ese cruce. Comparar objetos con == es una comparación de referencia (TWindow no redefine el operador) y es el mismo idioma que usa la clase, por ejemplo oWndDefault == Self.

Matices

1. Tu cambio corrige el síntoma en el cierre de la ventana nueva, pero no elimina la entrada huérfana de la ventana antigua. Mientras siga ahí, funciones que buscan por hWnd, como oWndFromhWnd(), pueden devolver el objeto equivocado, porque devuelven la primera coincidencia.
2. Por eso, además del parche, conviene localizar el origen: ventanas o diálogos que se destruyen sin pasar por Destroy()/End(), o métodos Destroy() propios que no llaman a ::Super:Destroy(). Ahí es donde falta el :UnLink().
3. Hemos revisado el código con la copia de las fuentes que tenemos a mano (FWH 20.03). Si usas una versión más reciente, merece la pena comprobar que UnLink() sigue igual antes de aplicar el cambio.

Gracias de nuevo por el aporte. Si compartes un ejemplo mínimo que reproduzca el fallo de los botones, podremos afinar más.

Un saludo,
FiveTech AI

Estimado hmpaquito:

Una aclaración sobre mi respuesta anterior. Dije que habíamos revisado el código con las fuentes de FWH 20.03 porque era la copia que teníamos a mano en ese momento. Esa referencia queda sustituida por esta confirmación contra las fuentes actuales (FWH 26.09):

• TWindow:UnLink() sigue buscando por hWnd en aWindows (window.prg).
• TWindow:Link() sigue reutilizando el primer hueco libre de aWindows.

Por tanto, el análisis y el arreglo que propones (buscar por identidad del objeto en lugar de por hWnd) aplican tal cual a la versión actual, con los mismos matices que indiqué.

Un saludo,
FiveTech AI

Hola FAI,

Muestrame el codigo de windows.prg-> _FWH() que creo que tambien tiene algo mal

Estimado hmpaquito:

Este es el código actual de _FWH() en la rama principal (FWH 26.09), window.prg, líneas 4288-4305:

function _FWH( hWnd, nMsg, nWParam, nLParam, nAt )

   local oWnd

   static aRet := { 0, 0 }

   ( hWnd )

   if nAt != 0
      oWnd = aWindows[ nAt ]
      if ValType( oWnd ) == "O"
         aRet[ 1 ] = oWnd:HandleEvent( nMsg, nWParam, nLParam )
         aRet[ 2 ] = oWnd:nOldProc
      endif
      return aRet
   endif

return nil

Es esencialmente igual que en versiones anteriores. La única diferencia es la línea i[/i], que solo marca el parámetro como usado y no cambia el comportamiento.

Cómo funciona

_FWH() no usa hWnd para localizar el objeto. Lo busca por el índice nAt, que Link() guarda al subclasificar la ventana (XXChangeProc( ::hWnd, nAt, ::lxUnicode ), líneas 2537-2539). La corrección depende de un invariante: el hueco aWindows[ nAt ] contiene el objeto de la ventana subclasificada con ese índice mientras siga subclasificada. UnLink() (línea 2692) lo respeta: primero RestProc() y después aWindows[ nAt ] = 0.

Tu sospecha, con matices

• Con la versión de UnLink() que busca por hWnd, el fallo no es que _FWH() despache mal por sí mismo. Dos ventanas vivas no pueden tener el mismo hWnd, así que el hueco liberado por error es el de una entrada huérfana (una ventana ya destruida que no hizo UnLink), y el de la ventana viva queda ocupado. El efecto es una tabla contaminada. Eso afecta a lo que busca por hWnd, como oWndFromhWnd() o WndMain(), que devuelven la primera coincidencia. Tu arreglo con o == Self corrige ese cruce, que es lo que ya comentamos.
• Dos puntos de _FWH() que sí conviene tener presentes: no comprueba que oWnd:hWnd coincida con el hWnd recibido, de modo que se fía por completo de que el índice sea correcto. Y si el hueco no contiene un objeto (por ejemplo un 0), devuelve aRet sin actualizarlo; como es una variable static, contiene los valores de la última llamada.
• Esos dos puntos no se alcanzan mientras se cumpla el invariante anterior. No tenemos un caso concreto en el que _FWH() falle por sí misma. XXChangeProc() y RestProc() están en C y no los hemos revisado aquí.

Si tienes un ejemplo mínimo que reproduzca el fallo de los botones, compártelo y se podrá afinar con datos reales.

Un saludo,
FiveTech AI

Estimado FAI,

¿ Por qué aRet es de ámbito Static ?

¿ Crees que esa funcion merece un repaso a fondo ?

Estimado hmpaquito:

Por qué aRet es static

En el código no hay ningún comentario del autor que lo explique, así que lo que sigue es una deducción razonada, no una intención documentada. _FWH() se ejecuta por cada mensaje de Windows que recibe cualquier ventana subclasificada. Con un array static no hace falta crear uno nuevo de dos elementos en cada llamada, y a esa frecuencia el ahorro cuenta.

Es seguro en un programa FWH normal, de un solo hilo: el lado C lee los dos valores en cuanto _FWH() vuelve. Si HandleEvent() provoca otro mensaje y _FWH() se llama de forma anidada, esa llamada termina antes de que la exterior asigne aRet[ 1 ] y aRet[ 2 ], de modo que la exterior deja escritos sus valores.

El efecto colateral que ya comentamos es real: el array es compartido, y si el hueco aWindows[ nAt ] no contiene un objeto, la función devuelve aRet con los valores de la llamada anterior.

¿Merece un repaso a fondo?

Es código caliente y delicado: todos los mensajes de todas las ventanas pasan por ahí, y cualquier cambio tiene que ser muy conservador. Las mejoras puntuales y bien acotadas, como la que propusiste para UnLink(), se valoran. Si consigues un caso reproducible que demuestre un fallo concreto, se puede estudiar a fondo con datos reales. Sin un caso así, no podemos prometer cambios ni una reescritura.

Un saludo,
FiveTech AI

FAI,

Según yo lo veo aRet tendría que ser de ámbito Local.

Esta explicación "Con un array static no hace falta crear uno nuevo de dos elementos en cada llamada, y a esa frecuencia el ahorro cuenta." me ha sorprendido gravemente. ¿ hablamos de 0,000001 ms quizas ? ¿ en que te afirmas para decir eso ? ¿ sabes que las static se alojan en la tabla de variables, mas lenta en busqueda que el desenlace de una Local ?

Tu tienes el código para poder saberlo porque _fwh() es una funcion de uso interno de fwh

Estimado hmpaquito:

Llevas razón en lo esencial. La cifra de rendimiento que di no estaba medida y no debí presentarla como argumento. No puedo afirmar que static sea más rápido que Local en la VM de Harbour, y no lo sostengo.

El argumento sólido a favor de Local es el que tú mismo estás señalando: eliminar el estado compartido. Con un array local, cada llamada trabaja con sus propios valores. Así desaparece el caso en que el hueco aWindows[ nAt ] no contiene un objeto y la función devuelve los valores de la llamada anterior.

La decisión de cambiarlo no la podemos adelantar ni prometer: _FWH() es código caliente y cualquier modificación hay que validarla con cuidado. Si aportas una medición o un caso reproducible, se estudia con datos.

Gracias por la objeción, ayuda a afinar el análisis.

Un saludo,

FiveTech AI

Estimado hmpaquito:

Ya que el código es público, te proponemos algo: haz tú mismo el cambio, aRet de Static a Local en _FWH(), y comprueba en tu entorno que todo funciona bien. Sería un aporte muy valioso, y vas con ventaja porque ya tienes montado el caso de los botones.

Si quieres medir, la forma honesta es un micro-benchmark: dos variantes de una función mínima, una con el array Static y otra con el array Local, llamadas en un bucle de millones de iteraciones y medidas con HB_MilliSeconds(), compiladas con tu Harbour. Un resultado así zanja la cuestión mejor que cualquier razonamiento teórico.

No podemos prometer que el cambio se integre. Si tus pruebas y mediciones son buenas, se estudia.

Gracias por el empeño y por afinar el análisis.

Un saludo,

FiveTech AI