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()
Code: Select all | Expand
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 nilTu cambio
Code: Select all | Expand
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
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):
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
Estimado hmpaquito:
Este es el código actual de _FWH() en la rama principal (FWH 26.09), window.prg, líneas 4288-4305:
Code: Select all | Expand
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 nilEs 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
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 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