]]>NumPut(GuiThreadInfoSize, GuiThreadInfo, 0)Кажется понял: записывает в начало содержимого переменной ее собственный размер, видимо для того чтобы dllcall знал сколько он сможет туда записать (конечный адрес переменной).
]]>Понял, переменной присвоен адрес, по которому будет возращено значение.
Почему именно по этому адресу? Почему не по адресу 12345?
При создании любой переменной ей дается адрес в памяти процесса самого скрипта. (на сколько я знаю)
Номер адреса возврата должен всегда совпадать с размером возращаемой структуры?
Как я уже сказал выше, переменная получает адрес, затем VarSetCapacity расширяет место этой переменной (т.е. последующие адреса становятся частью переменной, например: адрес переменной 0x4000 -> соответственно 0x4001...0x4100 (смотря сколько дала VarSetCapacity) будет являться частью переменной).
Может я ошибаюсь в терминах, сам еще не разобрался во всем.
Функции данные взял из свежей справки и дописал к ним, чтобы можно было указывать hwnd окна, изначально функция использовала текущий поток.
NumPut(GuiThreadInfoSize, GuiThreadInfo, 0)
Меняет формат содержимого переменной насколько я знаю. (надо еще справку почитать...)
]]>Результат: ControlGetFocus - стабильные залипания; DllCall - залипаний не обнаружено.
Взял на вооружение, спасибо!
------------------------------------------------------------
Есть некоторые проблемы с понимаем DllCall.
Вот как я распарсил ваш код:
GuiThreadInfoSize := 24 + (A_PtrSize * 6); устанавливаем размер в 24+4*6 (32-bit)
; судя по тому, что в GUITHREADINFO structure 9 элементов
; из них 6 типа HWND, можно сделать вывод, что HWND зависит от битности системы, а DWORD и RECT занимают по 8 bit.
VarSetCapacity(GuiThreadInfo, GuiThreadInfoSize); объявляем перем. GuiThreadInfo размером %GuiThreadInfoSize%
NumPut(GuiThreadInfoSize, GuiThreadInfo, 0); присваиваем GuiThreadInfo значение GuiThreadInfoSize.
Но ведь туда будет возвращено значение из функции, т.е. она должна быть пустой. Понял, переменной присвоен адрес, по которому будет возращено значение.
Почему именно по этому адресу? Почему не по адресу 12345?
Номер адреса возврата должен всегда совпадать с размером возращаемой структуры?
GuiThreadID:=DllCall("GetWindowThreadProcessId",ptr, HwndMain,int,0)
; получаем Id процесса
if DllCall("GetGUIThreadInfo", uint, GuiThreadID, ptr, &GuiThreadInfo)
; передаем id, и указатель на структуру,
; куда будет возвращено значение
{
WinGet, ClassNNList, ControlList, ahk_id %HwndMain%
Loop, PARSE, ClassNNList, `n
{
ControlGet, hwnd, hwnd,,%A_LoopField%,ahk_id %HwndMain%
if (hWnd = NumGet(GuiThreadInfo, 8 + A_PtrSize))
; получаем id из структуры GuiThreadInfo со смещением 8 + A_PtrSize:
; понятно, там находится hwndFocus
}Выяснилось, что повинна в таком неподобающем поведении команда ControlGetFocus.
Вот замена для ControlGetFocus:
loop
{
sleep,30
mousegetpos,,,mwin,mctrl
fctrl:=GetFocusedClassNN(mwin)
tooltip,Под мышкой: "%mctrl%"`n В фокусе: "%fctrl%"
}
GetFocusedClassNN(hwindow)
{
GuiThreadInfoSize := 24 + (A_PtrSize * 6)
VarSetCapacity(GuiThreadInfo, GuiThreadInfoSize)
NumPut(GuiThreadInfoSize, GuiThreadInfo, 0)
GuiThreadID:=DllCall("GetWindowThreadProcessId",ptr, hwindow,int,0)
if DllCall("GetGUIThreadInfo", uint, GuiThreadID, ptr, &GuiThreadInfo)
{
WinGet, ClassNNList, ControlList, ahk_id %hwindow%
Loop, PARSE, ClassNNList, `n
{
ControlGet, hwnd, hwnd,,%A_LoopField%,ahk_id %hwindow%
if (hWnd = NumGet(GuiThreadInfo, 8 + A_PtrSize))
return A_LoopField
}
}
}
Что-то такое припоминаю, но без использования ControlGetFocus. В скрипте имеются горячие клавиши?
Имееются. У меня без использования ControlGetFocus все ок.
2 Drugoy: хорошо вам.
Про двойной клик это давно известная проблема, если увеличить интервал между командами, будет незаметно. А залипания (у меня) остаются.
Запустите и поработайте какое-то время. Используйте клавиши Ctrl, Alt и Shift.
Не залипают?
Нет, не залипают.
В момент "взятия фокуса" двойной клик не работает...
Подтверждаю. Но не везде: не могу открыть что-либо с рабочего стола двойным кликом и в TotalCommander'е перестал двойной клик работать, а в остальных местах вроде бы всё ок.
]]>Если во время работы команды была зажата клавиша-модификатор, вполне вероятно, что она залипнет.
Что-то такое припоминаю, но без использования ControlGetFocus. В скрипте имеются горячие клавиши?
]]>Loop {
Sleep 50
ControlGetFocus, focusElement, A
}Выяснилось, что повинна в этом поведении команда ControlGetFocus. Сама она клавиши не нажимает, но, каким-то образом, не дает отпускать нажатые(физически). Точнее, если во время работы команды была зажата клавиша-модификатор, есть вероятность, что она залипнет.
Небольшая функция, правящая сей недостаток —
— приводит логическое состояние клавиш к физическому:
ControlGetFixBugUnpressKeys() {
Static ArrayKeys
ArrayKeys:=Object()
ArrayKeys:=["RCtrl", "LCtrl", "LShift", "RShift", "RAlt", "LAlt"]
i:= ArrayKeys.MaxIndex()
Loop %i%
{
Key:=ArrayKeys[A_Index]
GetKeyStatePhys := GetKeyState(Key, "P")
GetKeyStateLogi := GetKeyState(Key)
DiffKeyState := GetKeyStateLogi-GetKeyStatePhys
if DiffKeyState {
Direction := (DiffKeyState=1) ? "Up" : "Down"
SendInput {%Key% %Direction%}
; MsgBox %Key% will be not %Direction%. I fix it.
}
}
}-----------------------------------------------
UPD: в другой ветке Irbis радикально сократил объем кода:
FixBugUnpressKeys() {
for key, key in ["RCtrl", "LCtrl", "LShift", "RShift", "RAlt", "LAlt"]
if Direction := [0,0,"Up"][2+GetKeyState(Key)-GetKeyState(Key, "P")]
SendInput {%Key% %Direction%}
}
-----------------------------------------------
UPD2: ниже Alectric предложил альтернативу ControlGetFocus с помощью DllCall,
почти? не страдающую этим недостатком,
+ работает двойной клик (известная проблема ControlGetFocus),
- работает на 16мс дольше.
controlgetfocus bug nipped pressed down keys
]]>