I am trying to send the letter "a" when ALT is pressed and the mouse wheel is scrolled up.
This code works partially:
!WheelUp::
Send, a
return
In Vscode or just the plain Windows Texteditor however, I notice some scrolling if I scroll to hard with my mouse while pressing ALT.
Can this be fixed?
First thing is to check for running applications with high priority. These may interfere with AHK. For example I had similar issues while running AIMP (music player) in the background.
Setting the script's priority might be worth trying too.
Related
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.
I'm using GTK on Linux. (Both GTK2 and GTK3 exhibit this behavior.)
When you grab the window on some free space or menubar, the window itself gets dragged.
I'm using the window as a giant OpenGL canvas, and this prevents the primary mouse button presses from ever reaching the window. Double-clicks and secondary button presses arrive just fine.
How do I disable or work around this behavior? I've also tried adding a GtkDrawingArea to the window, but it still gets dragged.
This is not possible. GTK overrides the function of primary mouse button unconditionally. However, simply adding an empty GtkLabel to the window worked just well for me.
Edit: eventually I just used a GtkDrawingArea, because I also wanted a scroll/menubar. That works just as well.
Gtk does grab unconditionally, but you have full control of what that specific "click" will do.
Returning True from any "button-xxx" method will stop further processing from Gtk. See "Return type" here.
I'm using notepad++ (v6.5.3) and I constantly have to change the size of the tab for viewing some results. Not that it's taking me a lot of time to do it manually everytime, but it would be great if I could optimize that.
Is there a way to do so? Would a macro be the solution, or are they just for typing stuff?
Thanks a lot!
Ok, there's an easy way how you can achieve this - I have tested it right now:
Install AutoHotKey (or start portable version which runs without installation)
In Windows 7 and above, ensure you launched AutoHotKey as Administrator (otherwise you get inconsistencies in its behavior) - if not sure, exit it and restart it as administrator
Right click Autohotkey tray icon and select Edit This Script
Import the macro below this list at the end of the AutoHotKey script file and save the file
Right click Autohotkey tray icon and select Reload This Script.
–– This was end of general steps, now let's go with your macro: ––
In N++, display Preferences window and press its Close button1 at the bottom (NOT at the top-right corner)
Now you can use shortcuts Win+F2 and Win+F3 to switch different tab sizes instantly
SendMode Input
DetectHiddenWindows, On
SetTitleMatchMode, RegEx
;--------------------------------- Hotkeys for Notepad++ only
#IfWinActive ahk_class Notepad\+\+
#F2::Send {F10}{Right 6}{Down}{Enter}{Tab 2}{Space}16{Enter}{Tab 3}{Space}
#F3::Send {F10}{Right 6}{Down}{Enter}{Tab 2}{Space}4{Enter}{Tab 3}{Space}
#IfWinActive
1) Important: N++ user experience provided in dialog boxes is absolutely terrible. There are no anchors where you can fix focus when using keyboard. Thus you always need to perform step 4 manually when leaving Preferences dialog box otherwise the macros would send keys into incorect window page OR at correct page but incorrect control. Preferences dialog window remembers selected page and control. Macros I created for you therefore assume that correct page is already listed and button Close was recently focused.
Good news is Notepad++ windows with this weird behavior are rare exception from general user experience. In other places in N++ (or in other apps) where user interface components (menus, dialogs etc.) always start from the same point you do not need any special precautions like the one in step 4.
Adjust the macros as you like:
you can create more of them
you can adjust the numbers "16" and "4" typed into tab size input box
you can change shortcut keys to something else
you can replace sending keys with sending mouse clicks at desired screen/window positions
you can achieve many other useful shortcuts in N++ and in all other apps – check AHK deeper!
In gtk2 (.rc) and GTk3 (.css) how do you theme the default button in a dialog ?
(The one that will be activated when hitting enter)
In Lubuntu 12.10, the default theme (/usr/share/themes/Lubuntu-default) has a file in the gtk-2.0 folder called button.rc. There are five "states" listed: normal, prelight, insensitive, active, and focus. It is my impression (from a bit of fiddling), that the "focus" state represents the one you are interested in. In other words, if a window with a few buttons is present, it is the button in the focus state that will be "pressed" or "clicked" by hitting enter.
In Lubuntu 12.10, the screen that appears when you click "Logout" from the main menu (or run lubuntu-logout from a terminal) illustrates this well. Of the seven "buttons" that appear, the topmost one, Shutdown, is shaded slightly differently (or has a focus ring) whereas the other six are similar to each other except for the text. Hitting "enter" without doing anything else is equivalent to clicking the "Shutdown" button.
I too am trying to figure out how to make the button in focus, if we call it that, a bit more contrasty.
For the gtk2 side of things, if you're happy with making the focus ring more obvious (but a bit more ugly), editing the theme's gtkrc may be one way. Look for a section captioned style "default" and then for a line that has something like
GtkWidget ::focus-line-width = 1
Changing 1 to 2 or 3 will make the focus ring more obvious.
(I haven't got round to looking at gtk3 apps.)
I'm using iTerm2 on my mac to ssh into a Linux box and run emacs in the terminal. On a big monitor, I like to split the window to see multiple buffers side-by-side. I'd like to be able to switch to a particular buffer by clicking the mouse in it (rather than doing C-x o).
What seems to be happening is that if I click the mouse anywhere outside the currently active buffer e.g. in the next buffer, on the mode line etc., the click is being interpreted as which is bound to (tmm-menubar-mouse EVENT).
I have disabled the menubar by doing the following in my .emacs_d/init.el:
(menu-bar-mode -1)
This seems to disable the visible display of the menu bar at the top of the window, but the mouse click behavior I described is still happening.
I think what I need is to have the click interpreted as something other than and then bind that to some function that detects which buffer the click happened in and switch to it. But, I don't know how to do that and the searching I've done hasn't yielded any clear answer. Can anyone help?
Alternatively, I looked into using windmove to enable switching between buffers with SHIFT and the arrow keys. I did (windmove-default-keybindings) but emacs then seems to respond to SHIFT left-arrow by inserting "2C" into the buffer and SHIFT-right-arrow by inserting "2D". If anyone has any tips on making this work too, I'd love to hear them.
Thanks
I ran into this problem a while ago, where clicking on column > 95 was interpreted as <menu-bar> <mouse-1>, which invokes tmm-menubar-mouse. It turned out to be a bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6594
There hasn't been a formal release since this bug was fixed, but you can get the patch here:
http://bzr.savannah.gnu.org/lh/emacs/emacs-23/revision/100618
If I recall correctly, you should be able to just drop the modified file into your existing emacs installation and byte-compile it (assuming you're running the 23.3.1, the latest release).