I was reading through AHK documentation but couldn't find one where it explains how to define the coordinates WITHIN a certain application window.
For example, I want to be able to minimize/maximize the ribbon in all microsoft office apps (top right corner). This should work reliably no matter whether the window is maximized or not, and the mouse cursor should not shift (or at least it should shift back) while doing so.
Any idea how i can achieve this?
If you want coordinates to be relative to the active window, you need to use the CoordMode command at the top of your script. The second parameter specifies the coordinate mode will be for mouse coordinates. The third parameter you can specify either Screen or Relative. Relative is what you are looking for.
CoordMode, Mouse, Relative
Related
So I need to automate some button clickings on a java program. I tried ahks/autoit's controlclick but it doesn't really work (normal clicks do work, but I require no mouse movement).
I tried to get some information from window detective / window spy, etc. but not much is displayed apart from the window name and ahk_class
Java Ferret shows quite a lot more information though: https://gyazo.com/3539415488ce3e03c90f3532327419f2
How can I trigger one of these "push button" actions? (say "Descendent 19 role")
If you can get the X and Y coordinates of the control along with the window name, you could use a mouse click event.
Other than that, you can try using an image search to find the control's X and Y and perform a mouse click.
Problem
My PowerShell script generates a Form Window (with a fix startup location) and has a CMD Prompt window that is displayed alongside it that is used to display certain actions. However, with each successive launch of the PowerShell script, even though the Form Window stays in one place, the CMD Prompt window moves lower and lower as it makes its way systematically to the center of the screen. Once it reaches the center of the screen, it resets its position to the top left corner of the screen, only to repeat the process all over.
Question
Is it possible to designate the starting position of CMD Prompt Window, like you can with the Form window, so that I have more control over it?
I made a quick ahk script that moved the mouse and found that the mouse wasn't getting moved to the desired location. I set up a loop that continually moved the cursor to the same position every couple of seconds, and the mouse would be moved to different, seemingly-random positions instead. I found that this was only the case with a specific program's window focused and if I had any other program focused the mouse moved as expected. I tried using Click/MouseMove, and they both exhibited this behavior. I also tried DllCall("SetCursorPosition"), but that wouldn't even move the mouse. Just to further clarify, all three of those worked fine when the problem program wasn't focused -- I only had issues when the problem program was focused.
Upon further inspection, this seemed to be due to the program's custom mouse sensitivity implementation. If I used MouseMove to move the cursor 1 pixel down relative to the current position, it'd move down ~50. If I increased the program's mouse sensitivity, it'd move down even further. I assume this is also why I was getting seemingly-random mouse positions with Click.
For now I've implemented a custom click function which unfocuses the program, moves the mouse, re-focuses the program, and then clicks, but the program doesn't like that. Sometimes it works, but sometimes the program will ignore mouse clicks from the position the mouse was when the window was focused, leading to the script not being able to do the things I want it to be able to do.
Is there a way for me to take into account this program's mouse sensitivity while using Click x,y/MouseMove? Or maybe an alternative method of moving the mouse that isn't affected by the program's mouse sensitivity. I've tried using all types of CoordMode, but all of them have the same problem.
Edit: Script I'm using
CoordMode, Mouse,Screen ; I've tried every CoordMode but none solve the problem
AppsKey::
while true {
Click 500,500,0
sleep,2000
}
Return
Or, it could be that you are not making use of CoordMode, and by default when you don't specify this, unfortunately mouse positions are reliant on the active window, which can cause unpredictable results as you discovered. For more reliability, I like to always precede my mouse movement commands with this command that sets the coordinate system of the mouse to the refer to the screen instead:
CoordMode, Mouse
Explanation
Documentation about CoordMode:
If this command is not used, all commands except those documented otherwise (e.g. WinMove and InputBox) use coordinates that are relative to the active window.
The full command is
CoordMode, Mouse, Screen
But documentation says we can omit the second parameter and it defaults to Screen:
If Param2 is omitted, it defaults to Screen.
So for more consistent results, use CoordMode command.
Try it with SendPlay (but see below if you use UAC):
AppsKey::
while true {
SetMouseDelay, 20, Play ; or play around with the delay amt
sleep, 50 ; or play around with the sleep amt
SendPlay {Click 500,500,0}
sleep, 50 ; or play around with the sleep amt
SetMouseDelay, 0
sleep,2000
}
Return
SendPlay [v1.0.43+]
SendPlay's biggest advantage is its ability to "play back" keystrokes and mouse clicks in a broader variety of games than the other modes. For example, a particular game may accept hotstrings only when they have the SendPlay option. However, SendPlay may have no effect at all on Windows Vista or later if User Account Control is enabled, even if the script is running as an administrator. The following script provides a workaround for this problem: http://www.autohotkey.com/forum/topic75595.html.
Of the three sending modes, SendPlay is the most unusual because it does not simulate keystrokes and mouse clicks per se. Instead, it creates a series of events (messages) that flow directly to the active window (similar to ControlSend, but at a lower level). Consequently, SendPlay does not trigger hotkeys or hotstrings.
This is driving me mad! I love the new layout options in Word 2013, but when a callout gets to a certain size the icon for it obscures the end of the arrow, and you can't move the arrow:
Don't suppose anyone knows either how to get rid of the icon, how to click and drag on the yellow end of the arrow, or how to stop the icon appearing in the first place?
Thanks in advance.
Here are two answers that helped me. The second option gets rid of the floating Layout Options button, but at the cost of disabling some features of Word 2013.
First Option:
http://answers.microsoft.com/en-us/office/forum/office_2013_release-word/any-way-to-disable-the-layout-options-button/47f6af4a-2acd-483e-a953-6415c8530554
It might help to increase the zoom (use the slider at the right end of the status bar) while you work with the picture.
Second Option:
http://answers.microsoft.com/en-us/office/forum/office_2013_release-word/layout-options-icon-word-2013-suddenly-missing/ce304589-9db2-44c5-b1e1-8fd6596b70c4
Is the document in Compatibility Mode (shown by those words appearing in the title bar along with the document name)? If that's the case, click File and then click the Convert button. That will make the Layout Options button appear when a picture is selected, as well as turning on other features that are available only in the 2013 format. When you save, the document file will change to the .docx extension.
I know the second quote is about turning the Layout Options button on, but it works backwards, too. I saved my file as a *.doc instead of a *.docx and the floating button went away.
When you're finished editing your callouts, you can save it again as a *.docx.
One method that helped me was to flip horizontal, change the leader position, then flip back. That way the leader line is temporarily on the opposite side of the layout button, and both handles of the leader line are accessible, then can flip back. It is an extra step, but is another alternative.
In an attempt to automate this to quickly flip the object back and forth, I couldn't find a macro command to make a shortcut, or anything under Customize Ribbon with custom Keyboard Shortcuts to Flip Horizontal (MoreRotationOption opens up a dialog which does not give an option to flip).
The Flip Horizontal command could be called by pressing ALT JD (Format) AY (Rotate Objects) H (Horizontal) when the object is selected...
The best I could do was to add Rotate Objects to the Quick Access Toolbar, then the Flip Horizontal command could be called by pressing ALT # (whatever number you assign) H (Horizontal) which is three keystrokes.
I'm working on an intellisense or code-completion capability for C#.
So far, so good. Right now I have basic completion working. There are 2 ways to request completion. The first cycles through all the potential matches. The second presents a popup menu of the matches. It works for types:
And also for local and instance variables:
I'm confronting two problems with x-popup-menu:
the popup menu can expand to consume all available screen space, when the number of choices is large. Literally it can consume the entire screen, and obscure everything else, including the entire emacs window and every other window.
The silly thing is, it's scrollable. First it expands to consume all available space, then it also becomes scrollable. Seems like it would make sense for it to expand to a certain point, and then become scrollable, rather than expanding to take all available space.
Is there a way I can limit the maximum size of x-popup-menu?
To specify the position of the popup menu, I pass in a position, and x-popup-menu uses that as the *middle*, not the left, of the top line of the menu. Why middle? who knows.
What this means is, if I specify (40 . 60) for the location of the menu, and the menu happens to be 100 pixels wide, the menu will extend beyond the left border of the emacs window. You can see this in the 2nd image above.
If I knew how wide the popup would be before specifying the position, I could compensate. But I don't.
Is there a workaround? Is there a way to get x-popup-menu to take its position as the LEFT rather than the middle?
Addendum: Doc for x-popup-menu
x-popup-menu is a built-in function in `C source code'.
(x-popup-menu POSITION MENU)
Pop up a deck-of-cards menu and return user's selection.
PO SITION is a position specification. This is either a mouse button
event or a list ((XOFFSET YOFFSET) WINDOW) where XOFFSET and YOFFSET
are positions in pixels from the top left corner of WINDOW's frame
(WINDOW may be a frame object instead of a window). This controls the
position of the center of the first line in the first pane of the
menu, not the top left of the menu as a whole. If POSITION is t, it
means to use the current mouse position.
Some people like Emacs because it doesn't provide popup windows (see e.g. this blog entry). The more "emacsy" way of presenting your list of possible completions is to show them in a split buffer. That way you would automatically avoid all of the above issues (screen real estate & scrolling) and would probably attract more of the die-hard Emacs users.
But that's pure speculation :-)
You can base your autocompletion backend on company or autocomplete where display of suggestions is handled for you.