Using AutoHotKey to detect focus in Git Gui - focus

I'm trying to write an AutoHotKey script that will activate my Git Gui window, refresh it, and put the focus in the commit-comment text box. Activating and refreshing are no problem, but I'm not having any success changing focus. AutoHotKey doesn't seem to be correctly detecting the child controls in the Git Gui window.
If I run AutoHotKey's Window Spy utility, switch to the Git Gui window, and put the mouse over the commit-comment text box, Window Spy shows the following output (abbreviated):
>>>>>>>>>>( 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)
So it looks like the class name of that edit box is TkChild18, and I would expect to be able to write the following in my AutoHotKey script:
NumpadAdd::
ControlFocus, TkChild18, Git Gui (Tyler08) C:/svn/Tyler08
return
But when I start this script and then press Numpad +, nothing happens. I expected the focus to move to the commit-comment text box, but the focus doesn't change at all.
In trying to troubleshoot this, I built the following script based on the AutoHotKey docs for 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%
Now if I activate the Git Gui window and press Numpad +, AutoHotKey pops up a message box that says: "Control with focus = TkChild1". No matter where the focus is -- whether the focus is in the commit-comment text box, or in the diff pane, or in the "New Commit" or "Amend Last Commit" radio buttons, or in any of the buttons -- AutoHotKey always reports that the focus is TkChild1. This disagrees with Window Spy, which is able to see all the child windows (TkChild18, etc.)
The above script does work with at least some other apps (as long as I change the window title in the second line). It shows its "target window doesn't exist..." failure message if a WPF element has focus (e.g. the Output window in Visual Studio 2010) but it succeeds if a WinForms control has focus (e.g. VS2010's Properties grid). So I know I've got the right syntax for the ControlGetFocus command. I suspect that Git Gui is doing something strange with its child windows (it's built with the Tk framework, which may do something weird that AutoHotKey can't handle).
Anyone have any ideas on how I can get AutoHotKey to successfully change focus within the Git Gui window?
Using AutoHotKey Basic v1.0.48.00 and mSysGit version 1.7.3.1-preview20101002 on 64-bit Vista.

I suspect that Git Gui is doing something strange with its child windows (it's built with the Tk framework, which may do something weird that AutoHotKey can't handle).
I suspect you're right. Most of Autohotkey's commands are merely wrappers for MSFT Win32 api calls. In this case, ControlFocus probably just wraps SetFocus(). If the TK framework doesn't respond to normal windows messages such as WM_SETFOCUS then these won't work.
Your code fails on my computer too. I've tried for a half hour to find a workaround, with no luck other than hacks. Obviously you can just send TAB keypresses until your commit message editbox has focus, but this is unreliable since we cannot accurately check which control does have focus.
So, the best I could come up with is to just resort to sending a basic Click to the box. I tried ControlClick which would prevent mouse movement, but alas, it failed just like all the other Control commands. Ironically ControlGetPos works which allows this solution (otherwise if the Git Gui window is resized, a hardcoded coordinate would fail).
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

Related

How to restore/clear form position after multi-monitor setup change

Within the IDE, when F12 toggles between code and form,
the forms are displayed outside the monitor borders,
and therefore not visible.
This happens after a multi monitor setup has changed,
and the forms no longer open within the available new monitor screen areas.
One way to resolve this is to use the property inspector and
set the Top/Left properties to 4 to make the forms visible.
This is however a lot of work,
especially if many forms and possibly many projects are involved.
Is there a better way to reset the form locations once and for all,
so they are all visible with the new monitor setup?
There is nothing (AFAIK) in Delphi 6 IDE that would help. But assuming you are using Windows, the help is near, (tested on Windows 7):
Right-click on taskbar and select 'Cascade windows', this affects all windows in one go.
or
Alt-Tab to the window, press Alt-Space and then M (for move). Move the window with the arrow keys. This you would have to do seperately for each window.
Close your Delphi IDE. Then, if your current project group file is xyz.groupproj, open the file xyz.dsk with an text editor. Look for section [UndockedDesigner] entry "Count" and change its value to zero.
[UndockedDesigner]
Count=0
That will force all design window positions to 0,0 on your main monitor.

Can I have the build dialog in the center of the screen?

Ever since Delphi XE2 (or even before) the build dialog appears in the bottom right corner of the screen.
Because I'm a curious fellow I'd like to see what's going on.
But that's hard when it's way there in a corner.
If I move the dialog to the correct centered position the IDE does not register/remember this and keeps on putting in in the corner every time it compiles.
Is there a way/hack to make this dialog appear in the center of the screen?
You have enabled background compilation: Tools | Options | Environment Options | Background compilation.
The designers presumed that you did that because you did not want the compilation progress to disturb you, and stop you being able to see the editor window. The whole point of background compilation is for you to be able to carry on working in the IDE whilst compilation progresses. If the dialog was shown in the middle of the IDE window then you would not be able to see what you were working on.
If you disable background compilation then the dialog will appear in the centre of the monitor.

Eclipse - preview source in separate window on mouse click?

I'm looking for a way to be able to preview code related to what's under my cursor in a separate window when I click the mouse/touchpad. Eg. definition for methods / member variables etc.
Something like the results of Ctrl+Click but instead of opening the file in my main editor window, I'd like to see the results in a small window below the main editor window (a 'code preview' window).
Ideally, the 'code preview' window doesn't hide any code surrounding the preview of the item under the cursor.
This happens for eg. in Source Insight & VSlick. It gives the ability to browse another section of the code in a small window while the main source is open in the main window.
I find it very useful.
Is there any way / plugin etc to do this in ADT/Eclipse ?
I'm new to Eclipse and using the ADT flavor (Eclipse Platform 4.2.1.v20130118) for Android Java dev.
Thanks!
Press Shift and hover the mouse cursor over the method or variable - it will show a small popup with the source preview.
You must be sure it is enabled in Preferences (Preferences->Java->Editor->Hovers, "Source" line should be checked).
Checked with Eclipse 4.4.

How to prevent large popup hint in Messages Panel?

In my Delphi IDE (XE2) in the messages panel when hovering over the blank line before the Build Succeeded message, I get a very large popup hint displayed that covers the entire screen in which all my library paths are displayed. This occurs on the Output tab of the Messages pane.
Here is a screen shot of where this is happening:
It is very annoying.
I have some IDE Experts installed:
GExperts
JCL Options
I have looked through the settings and cannot see anything related to where this would be turned off.
Does this happen with anyone else and is there a way to stop it?
What you're seeing is the text of what command line would be sent to the command line compiler, being displayed in a hint window.
Before the hint:
With the hint:
If you look at the first part of that image, it starts with (on my system)
c:\rad studio\5.0\bin\dcc32.exe
which is the Delphi command line compiler.
The solution is to not put your mouse on the line right below the target compile line (which is the only place you can see this - by hovering the mouse over the line below 'Target SomethingCompileentry (in my second screen capture, it's the line belowTarget CoreCompile`).
If you don't want to see that hint window, don't hover your mouse over it in the first place. (It's like hint text over a label - if you don't want to see the hint, don't leave your mouse pointer over that label.) It's not like it's a huge area on the screen you have to avoid - it's just that single line of output in the window.

Separate mouse for debugger

I am programming a Delphi (XE3) application where mouse position is important, but I would like to be able with another mouse to be able to set breakpoints without moving the primary mouse position. I may be pressing shift or control in the application I am trying to debug, so alt-tabbing to the IDE and setting a breakpoint with the keyboard keyboard won't work. Can Windows 7 easily be set up to do this?
It's possible to attach multiple keyboards and mice to a computer, and various video games can take advantage of the multiple input devices, but the OS in general does not take advantage of that. No matter how many keyboards and mice you attach, there's still just one input queue and one cursor on the screen.
If all you need is to set breakpoints without moving the mouse, then you can navigate the input caret to the desired line with the keyboard and then press F5 to toggle breakpoints.
If you need to be able to debug without interfering with the program at all, then you might need to use remote debugging. Although the documentation suggests using Remote Desktop to operate the remote program while you're sitting at the local system, that's not what you want to do in this situation because you'll still have just one set of input devices. Instead, log on to the remote computer from elsewhere (either directly, or via Remote Desktop on a third computer). It'll help to have two computers you can access from the same chair.

Resources