Использование AutoHotKey для определения фокуса в Git Gui

Я пытаюсь написать сценарий AutoHotKey, который активирует мой Git Gui, обновите его и поместите фокус в текстовое поле коммит-комментарий. Активация и обновление не проблема, но мне не удалось изменить фокус. AutoHotKey, похоже, неправильно определяет дочерние элементы управления в окне Git Gui.

Если я запускаю утилиту Window Spy AutoHotKey, переключаюсь в окно Git Gui и наведу указатель мыши на текстовое поле коммита-комментария, Window Spy покажет следующий результат (сокращенно):

>>>>>>>>>>( Window Title & Class )<<<<<<<<<<<
Git Gui (Tyler08) C:/svn/Tyler08
ahk_class TkTopLevel

>>>>>>>>>>>>( Mouse Position )<<<<<<<<<<<<<
On Screen:  808, 727  (less often used)
In Active Window:   816, 735

>>>>>>>>>( Now Under Mouse Cursor )<<<<<<<<
ClassNN:    TkChild18
Text:   
Color:  0xF0F0F0  (Blue=F0 Green=F0 Red=F0)

Итак, похоже, что имя класса этого поля редактирования - TkChild18, и я ожидал, что смогу написать следующее в моем скрипте AutoHotKey:

NumpadAdd::
ControlFocus, TkChild18, Git Gui (Tyler08) C:/svn/Tyler08
return

Но когда я запускаю этот сценарий и затем нажимаю Numpad +, ничего не происходит. Я ожидал, что фокус переместится в текстовое поле фиксация-комментарий, но фокус вообще не изменился.

Пытаясь устранить это, я создал следующий сценарий на основе документации AutoHotKey для ControlGetFocus:

NumpadAdd::
ControlGetFocus, OutputVar, Git Gui (Tyler08) C:/svn/Tyler08
if ErrorLevel
    MsgBox, The target window doesn't exist or none of its controls has input focus.
else
    MsgBox, Control with focus = %OutputVar%

Теперь, если я активирую окно Git Gui и нажимаю Numpad +, AutoHotKey выдает сообщение с сообщением: «Control with focus = TkChild1». Независимо от того, где находится фокус - будь то фокус в текстовом поле фиксация-комментарий, или на панели различий, или в переключателях «Новая фиксация» или «Изменить последнюю фиксацию», или в любой из кнопок - AutoHotKey всегда сообщает, что фокус - TkChild1. Это не согласуется с Window Spy, который может видеть все дочерние окна (TkChild18 и т. Д.)

Приведенный выше сценарий действительно работает по крайней мере с некоторыми другими приложениями (если я изменяю заголовок окна во второй строке). Он показывает сообщение об ошибке «целевое окно не существует ...», если элемент WPF имеет фокус (например, окно вывода в Visual Studio 2010), но успешно, если фокус имеет элемент управления WinForms (например, сетка свойств VS2010). Итак, я знаю, что у меня правильный синтаксис для команды ControlGetFocus. Я подозреваю, что Git Gui делает что-то странное со своими дочерними окнами (он построен на платформе Tk, которая может делать что-то странное, с чем AutoHotKey не может справиться).

У кого-нибудь есть идеи о том, как я могу заставить AutoHotKey успешно менять фокус в окне Git Gui?

Используя AutoHotKey Basic v1.0.48.00 и mSysGit версии 1.7.3.1-preview20101002 в 64-битной Vista.


focus autohotkey
person Joe White    schedule 15.05.2011    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Я подозреваю, что Git Gui делает что-то странное со своими дочерними окнами (он построен на платформе Tk, которая может делать что-то странное, с чем AutoHotKey не может справиться).

Я подозреваю, что ты прав. Большинство команд Autohotkey являются просто оболочками для вызовов API MSFT Win32. В этом случае ControlFocus, вероятно, просто обертывает SetFocus (). Если структура TK не отвечает на обычные сообщения Windows, такие как WM_SETFOCUS, тогда они не будут работать.

Ваш код тоже не работает на моем компьютере. Я полчаса пытался найти обходной путь, но безуспешно, кроме хаков. Очевидно, вы можете просто отправлять TAB нажатия клавиш, пока ваше окно редактирования сообщения фиксации не будет в фокусе, но это ненадежно, поскольку мы не можем точно проверить, какой элемент управления имеет фокус.

Итак, лучшее, что я мог придумать, - это просто прибегнуть к отправке базового Click в ящик. Я пробовал ControlClick, который предотвращал движение мыши, но, увы, это не удалось, как и все другие команды управления. По иронии судьбы ControlGetPos работает, что позволяет это решение (в противном случае, если изменить размер окна Git Gui, жестко запрограммированная координата не сработает).

SetTitleMatchMode, 2             ;// allow partial window title matches

NumpadAdd::
   WinActivate, Git Gui
   ControlGetPos, control_x, control_y, , , TkChild18, Git Gui

   CoordMode, Mouse, Screen
   MouseGetPos, mouse_x, mouse_y    ;// grab current mouse screen position

   click_x := control_x + 5      ;// we'll click 5 pixels inside the control
   click_y := control_y + 5
   CoordMode, Mouse, Relative
   Click %click_x%, %click_y%   ;// click relative to active window (moves mouse)

   CoordMode, Mouse, Screen
   MouseMove, %mouse_x%, %mouse_y%, 0   ;// restore old mouse position
return
person mikew    schedule 16.05.2011
comment
Для справки, git-gui не менее проблематичен на своей домашней территории Linux / X11. Я написал инструмент, похожий на WinSplit Revolution, и git-gui дает ему проблемы, очень похожие на эту проблему. - person ssokolow; 02.02.2012