А вот если в окне контролы, то непонятно как тут быть:

Вроде неплохой вариант без постоянной нагрузки таймером:

Gui, -Caption +HWNDhThisGui
OnMessage(0x200, "WM_MouseMove") 
Gui, Add, Edit, x0 y0 h111 w111 
Gui, Show, NA w222 h222 
return
 
WM_MouseMove(wParam, lParam, Msg, hwnd)   {  
    SetTimer, IsThisGui, -10
}
 
IsThisGui:
    MouseGetPos, , , WinID
    If (hThisGui = WinID)   {
        If !IsThisGuiScript
            Tooltip, % IsThisGuiScript := 1
        SetTimer, IsThisGui, -10 ; для надёжности, иногда "срывается"
    } Else 
        Tooltip, % IsThisGuiScript := 0
    return

Плюсы кое-какие есть. Вот в соседней теме я постил код, узнающий адрес загруженной в другой процесс DLL. Из x64 скрипта можно это узнавать как в 64-, так и в 32-битных процессах, а из x86 скрипта — только в 32-битных. В основном, наверно, такие вещи.

Ну и раз есть люди, использующие АНК64, то в новом коде, думаю, имеет смысл это учитывать.

Ну что ж, прекрасно, если работает.

А вот если в окне контролы, то непонятно как тут быть:

Gui, -Caption +HWNDhThisGui
OnMessage(0x200, "WM_MouseMove")
OnMessage(0x2A3, "WM_MouseLeave")  
Gui, Add, Edit, x0 y0 h122 w122 
Gui, Show, NA w200 h200 
return
 
WM_MouseMove(wParam, lParam, Msg, hwnd)
{ 
    Global hThisGui
    static TME, init:= VarSetCapacity(TME, 16, 0) NumPut(16, TME, 0) NumPut(2, TME, 4)   
    If (hwnd = hThisGui)
        NumPut(hwnd, TME, 8), DllCall("TrackMouseEvent", "uint", &TME)  
}
WM_MouseLeave(wParam, lParam, Msg, hwnd){ 
    ToolTip OnMouseLeave 
} 

Вопрос немного отвлечённый: за чем вообще люди используют x64 интерпретатор АНК, с ним же гемороя необерёшся по допиливанию других скриптов, что за такие большие плюсы в x64?

А проверка очереди сообщений не прерывает поток? Он же у скрипта один (см. Диспетчер задач). Таймер, скорее всего, запускается тоже по сообщению — WM_TIMER.

Зачем же тогда проверка очереди сообщений да ещё и бешеный таймер сверху?

Вариант без таймера вроде бы отлично работает:

Gui, -Caption 
OnMessage(0x200, "WM_MouseMove")
OnMessage(0x2A3, "WM_MouseLeave")  
Gui, Show, NA w200 h200 
return
 
WM_MouseMove(wParam, lParam, Msg, hwnd)
{ 
    static TME, init:= VarSetCapacity(TME, 16, 0) NumPut(16, TME, 0) NumPut(2, TME, 4)  
    NumPut(hwnd, TME, 8), DllCall("TrackMouseEvent", "uint", &TME) 
    ToolTip OnMouseMove
}

WM_MouseLeave(wParam, lParam, Msg, hwnd){ 
    ToolTip OnMouseLeave 
} 

Лучше получать моментальное сообщение по факту события, чем результат проверки, которая постоянно прерывает текущий поток.

А проверка очереди сообщений не прерывает поток? Он же у скрипта один (см. Диспетчер задач). Таймер, скорее всего, запускается тоже по сообщению — WM_TIMER.

Согласно описанию сообщений WM_NCMOUSELEAVE и WM_MOUSELEAVE, они требуют предварительного вызова функции TrackMouseEvent.

Причём вам нужно вызывать её заново каждый раз, как курсор возвращается в окно. А для отслеживания этого возвращения всё равно, видимо, понадобится таймер.

Интересует реализация в AutoHotkey - хука на такое событие.

GUI, show, w200 h100, AHK
SetTimer, LocalWatch, 10

LocalWatch:
MouseGetPos, , , WClass, CName
WinGetTitle, WName, ahk_id %WClass%
If (WName = "AHK")
Tooltip, Это окно GUI
Else Tooltip, Это другое окно
Return

Gui +HWNDhThisGui -Caption
Gui, Show, w111 h111
OnMessage(0x2A2, "WM_NCMOUSELEAVE")
return 

WM_NCMOUSELEAVE(wParam, lParam, msg, hwnd)
{              
    ToolTip % " wParam = " wParam " lParam = " lParam " msg = " msg " hwnd = " hwnd 
} 

Вопрос: как надёжно получать сообщения о выходе курсора за пределы GUI скрипта?