What is wrong with my script?
Context: Inbox folder of Outlook. I want to click (focus) just only one email (the one with the gray color), but my script ALSO "colors" all emails the are above it. I'm not sure what is the matter.
#IfWinActive ahk_class rctrl_renwnd32
+F7::
PixelSearch, Px, Py, 14,98,754,962, 0xE1E1E1, 3, Fast
if ErrorLevel
MsgBox, That color was not found in the specified region.
else
Click, %Px%, %Py%
return
#IfWinActive
It seems that you are oh, say, scrolling or moving the cursor around in the preview panel, and now you want to jump the cursor to that same email's entry in the mailbox listing.
If this be the case, then here is a possible solution for you:
Okay, so we know that by default, whatever message you are viewing in the preview pane should be the highlighted entry in the mailbox list. That means all we have to do is to set focus to the mailbox list pane - when that pane receives focus, then the highlighted entry should be able to receive your immediate keyboard commands since it is already selected.
Therefore, all you need to do with your ahk script is create a hotkey that sets focus to the mailbox pane. Use your window spy to spy the class of the mailbox pane and just set focus to it. You shouldn't have to worry about colours at all.
Maybe something like this for Office 2010:
+F7::
ControlFocus, SUPERGRID2, ahk_class rctrl_renwnd32
return
or, for Office 2013:
+f7::
ControlFocus, OutlookGrid1, ahk_class rctrl_renwnd32
if ErrorLevel
MsgBox, You don't seem to be in context.
return
Or, instead of hacking the window, you could just push ctrl+1 - Outlook has a built-in keyboard command to set focus to the mailbox list.
Related
Question
How do I program AutoHotKey to detect the Microsoft Outlook Search field at the top of the window, so as to only enable hotkeys when outside of that window? That search field looks like this:
Details
I'm intending to add single-character hotkeys similar to what gmail has: https://support.google.com/mail/answer/6594?hl=en#zippy=%2Cactions , notably the # keybinding for deletion. I'm basing my experimentation with AutoHotKey scripts such as this one:
https://github.com/pimlottc-gov/gmailkeys/blob/master/gmailkeys-2013.ahk#L37
That script limits its hotkeys to the main Outlook window using #IfWinActive:
#IfWinActive, - Outlook ahk_class rctrl_renwnd32, NUIDocumentWindow ;for Outlook 2013, uncomment this line
However, if I do not change the above #IfWinActive statement, and then add the # hotkey via:
+3::Send {Delete} ; Means "#" key: Delete selected message(s)
then when running the script, then clicking in the above Search field, then typing #, then of course it sends the Delete key into that field, instead of just passing the # into the search field.
I've hacked around this by rebinding both Ctrl+e and / (the latter being the Gmail binding for searching/filtering) to a temporary input popup where I type in the search expression, and then let AutoHotKey type it into the field. But this of course is a hack:
; Search for some expression
;
; Hack: We have to popup an input dialog box, prompt for the
; search expression, and then when done, type it into the
; underlying search field. This is needed to avoid having other
; single-key bindings get "eaten" when needing to type into the
; Outlook search field, as as of 2021-05-23 I could not find a way
; to detect that specific input field.
;
^e::
/::
; Save current active (Outlook) window so we can return to after prompting for the search expression:
WinGet, winid ,, A ; <-- need to identify window A = active
; Prompt for the search expression:
InputBox, search_expr, Search Expression, Enter the search expression.
; Return to the Outlook window:
WinActivate ahk_id %winid%
; If the user presses Escape or clicks on the Cancel button, do nothing:
if (!ErrorLevel) {
; but if we are doing the search:
; Get into the search field:
Send ^e
; Select all prior text so we can wipe it out:
Send ^a
; ... by typing in all of the expression:
Send %search_expr%
; then do the search:
Send {Enter}
}
return
No matter where I click around in the main Outlook window, Window Spy (app that comes with AutoHotKey), the class always stays the same.
AutoHotkey version: 1.1.33.08
Note that Shift+3 only happens to produce a # on your keyboard layout. It would be more correct to actually use the # key as the hotkey.
Also, the code you're referencing is very legacy AHK. Quite a few things in there that don't belong to modern AHK.
I'd maybe also recommend just doing this with a context sensitive hotkey.
This way you'll retain the # key's native functionality.
The context sensitive hotkey could be done like this:
SetTitleMatchMode, 2
#If, WinActive("A") == WinExist("- Outlook ahk_exe OUTLOOK.EXE") && !SearchBarFocused()
#::SendInput, {Delete}
#If
SearchBarFocused()
{
ControlGetFocus, ctrl
return InStr("RICHEDIT60W1,RichEdit20WPT1", ctrl)
}
I'm also checking if Outlook is actually the active window first. Might be kind of redundant, but makes it so the remap couldn't be active in some other window that could have a control by that name.
I found the solution after some experimentation (including simplification from per 0x464e's answer), and essentially reversing the logic, somewhat, at https://github.com/pimlottc-gov/gmailkeys/blob/master/gmailkeys-2013.ahk#L76 via this:
; Outlook-specific Hotkeys:
;
; Reference material used in this implementation:
; https://autohotkey.com/board/topic/38389-archiving-email-in-outlook-with-a-single-keystroke/
;
; As best I can tell, the window text 'NUIDocumentWindow' is not present
; on any other items except the main window. Also, I look for the phrase
; ' - Outlook' in the title, which will not appear in the title (unless
; a user types this string into the subject of a message or task).
#IfWinActive - Outlook ahk_class rctrl_renwnd32, NUIDocumentWindow
#::
if (SentNormalKeyInOutlookEditControl("#"))
{
return
}
Send {Delete} ; Delete selected message(s)
return
#IfWinActive
SentNormalKeyInOutlookEditControl(normal_key)
{
; Find out which control in Outlook has focus
ControlGetFocus, currentCtrl
; ; set list of controls that should respond to specialKey. Controls are the list of emails and the main (and minor) controls of the reading pane, including controls when viewing certain attachments.
; ; The control 'RichEdit20WPT1' (email subject line) is used extensively for inline editing. Thus it had to be included in bad_ctrl_list.
; ctrlList = Acrobat Preview Window1,AfxWndW5,AfxWndW6,EXCEL71,MsoCommandBar1,OlkPicturePreviewer1,paneClassDC1, RichEdit20WPT2,RichEdit20WPT4,RichEdit20WPT5,RICHEDIT50W1,SUPERGRID1,_WwG1
bad_ctrl_list = RICHEDIT60W1,RichEdit20WPT1
; RICHEDIT60W1 is the search field at the top of the window
if currentCtrl in %bad_ctrl_list%
{
; MsgBox, BAD Control with focus = %currentCtrl% normal_key = %normal_key%
Send %normal_key%
return 1
}
return 0
}
Edit 2021-05-25 06:58:23: Replace legacy "+3" with "#" per 0x464e's answer.
Edit 2021-05-25 08:20:09: Prevent " - Message" windows from receiving the hotkeys (separate message windows, not main window)
I just want W to correspond to the Up Arrow key and S to correspond to the Down Arrow key, and work just like they do, and for A/D to move the focus to the last/next tab.
When i hold S, the page skips down erratically and then Firefox opens the "Save as" window multiple times.
When i hold W, the page skips up erratically and then multiple tabs are closed.
D does what it's supposed to, and A straight up doesn't work.
#IfWinActive ahk_exe firefox.exe
w::
Send {Up} ; Move page up.
s::
send {down} ; Move page down.
a::
send, ^{pgup} ; Go to tab on the left.
d::
send, ^{pgdn} ; Go to tab on the right.
#IfWinActive
Return
What exactly is happening? It should work normally but it isn't.
#IfWinActive ahk_exe firefox.exe
w:: Send {Up} ; Move page up.
s:: send {down} ; Move page down.
#IfWinActive ; turn off context sensitivity
The above examples are known as single-line hotkeys because each consists of only one command.
To have more than one command executed by a hotkey, put the first line beneath the hotkey definition and make the last line a return. For example:
#n::
Run http://www.google.com
Run Notepad.exe
return
https://autohotkey.com/docs/Hotkeys.htm#Intro
I am unable to perform multi-file text search and replace (in Visual Studio).
In the past, when I opened the "Replace in Files" dialog, there were 4 buttons in the lower right. One of the bottom two buttons allowed me to "Replace All".
The two lower buttons (including "Replace All") are no longer present.
I believe this occurred after I changed some Windows settings so that I could use menus without the Magnifier.
It is not just a matter of the buttons being off-screen because the window is too large (although it is too large - they would be off-screen, if they were present).
I can drag the window and see the bottom, even though the top is then off-screen (I use AltWindowDrag, allowing me to hold the ALT key, and drag by any part of the window, not just the title bar).
The two lower buttons are not present. I'm unable to resize the window - when I try, nothing happens, or the window repositions so that I can see the title bar, but can no longer see the bottom.
The two buttons that are still present (Find Next and Replace) don't have keyboard shortcuts, so I presume that Replace All doesn't either. Nor can I select either of those two buttons using Tab, so probably can't select an "invisible" "Replace All" button that way.
Any help appreciated.
You can use Find and Replace by pressing Ctrl+H and to Replace All just use Alt+A.
Can someone please clarify the default focus handling of the X11 server? My understanding is that the focus 'follows the mouse' and sure enough if I move the mouse between separate terminals I can see the cursor changing as each window aquires/loses the focus.
But when I run two xev windows and move the pointer between them, I see plenty of MotionNotify/EnterNotify/LeaveNotify as the pointer moves from one window to another - but FocusIn and FocusOut are nowhere to be seen. Is this an oddity in xev? Is there some special mask or property which needs to be applied in order for these events to be generated?
Many thanks, R.
While I do not fully understand the answer(s), I am grateful to parkydr, minitech and any others who may have stopped by.
Thanks again, R.
Having focus refers to the window which receives keyboard input when you press a key.
The focus handling depends on your window manager. The most common mode is click to focus, which your window manager is set to, where you only get focus when you click on the window. An alternative is that the keyboard focus follows the mouse, which is what you are expecting.
There should be a setting to change this in your window manager settings.
The cursor changing does not indicate focus, just that the terminal has defined a different cursor.
To demonstrate, open a terminal and an xev window.
Click on the xev window and press a key, you will see key events.
Move the mouse to the terminal window, you'll see the motion and leave events
Press a key and you'll still see key events from xev
Click on the terminal window, xev will give a focus out event
Press a key, the characters will be displayed in the terminal window
Move the mouse over the xev window and press a key, the character will still come out in the terminal window
When should I put ... at the end of a menu item? I seem to remember reading some rules but can't for the life of me find them.
For context - I'm adding a properties option to a right click menu and am wondering if it is appropriate to add them.
As I understand it it indicates that the option will ask you something else before actually doing anything. The 3 dots are actually called an ellipsis, and if you check out the English use it kind of makes sense:
http://en.wikipedia.org/wiki/Ellipsis
BTW I've noticed OpenOffice breaks this convention sometimes!
When the option will send the user to some sort of dialog where the user has to do something before a real change is made. Options without the ellipse take effect immediately.
For example, 'Save' doesn't have an ellipsis, while 'Save As...' does because the user has to input the new name/location of the file.
One exception to the first two answers: if the whole point of the menu command is to open a window or dialog, then you don't need an ellipsis. For example, a "Get Info" or "Properties" command shouldn't have it, even though it's opening a window which lets you edit things.
It's only when the menu command's purpose is to do something else, but it needs a dialog or confirmation in order to do it.
It means that there will be another dialog box after you select that option, it won't actually 'do' anything. There will be another prompt.
To be exact, the rule is that if more information is required from the user to complete an action, then include an ellipsis. In the MS Vista User Experience Guidelines, getting a confirmation qualifies as "more information" (see http://msdn.microsoft.com/en-us/library/aa511502.aspx). Commands to show Properties, About, Help, Options do not get ellipsis because no further information is needed to execute the command, which is "Show Properties" or "Show Documentation" or "Show Options." The File Open command gets an ellipsis because additional information is needed to open the file, namely the file name.
If the menu is an action that the user will be doing, but the action won't be completed until we get more information from the user, you show an ellipsis, e.g.:
Format Hard Drive… (we need to know which one, and the file system type)
Save As… (we need to know what filename and type to save as)
Print… (we need to know what printer and quality settings)
Find… (we show a text box asking for the text to search for, and where)
Rename… (rename to what)
As opposed to actions that will happen the moment you click the menu item, e.g.:
Save
Undo
Redo
Select All
Ellipses don't just indicate that a dialog will appear. i.e. if it's not an "action", then there's no ellipses, e.g.:
About Gizmo
Page Setup
Print Preview
Options
File Properties
And asking the user if they want to do something does not count as "getting more information from the user", e.g.:
Delete File
Recycle File
New Text Document
Whenever selecting that item results in another dialog box appearing. For actions that happen immediately (think Save vs. Save As), no ellipsis.
Originally, it meant:
An ellipsis (...) after a menu item means that after the item is chosen, the user will be asked for more information before the operation is carried out. Usually, the user must fill in a dialog box and click and OK button or its equivalent. Don't use the ellipsis when the dialog box that will appear is merely a confirmation or warning (for example, 'Save changes before quitting?').
(Apple Human Interface Guidelines, page 69)
Note that it did not mean "show a dialog box", even though that was often the consequence of this. For example, on Mac OS (not X), the "Options" button in the Page Setup window had no ellipsis, even though it showed a modal dialog box. No ellipsis is used because showing the options window is the operation.
(Tog on Interface, pages 46-47)
Of course, these days nobody cares about such things as human interface guidelines, not even Apple, so you can pretty much do what you want and still be more consistent than most any other application out there.
I've usually seen it in places where more input is required from the user before completing an operation. If your properties dialog is allowing the user to change properties, I would include the ellipses. If it's just displaying the information, don't include it.
It generally means that a Dialog will be shown when the item is clicked.
They usually signify that clicking on that entry will open a dialog window.
You should add ellipses to the end of text only if you're truncating the text (this applies anywhere). You should truncate the text if it's too long to reasonably fit where you're putting it.
Edit: interesting, I never noticed that menus in Windows use the ellipses to indicate truncated text, but also use the ellipses on short text to indicate that more information will be collected before the action is taken. This is inconsistent interface design, but since menus are under the control of individual programmers it's unavoidable.
It usually means it'll take your focus away from the current window. Like for example, notepad has a "Find..." which means you're going to focus on another window (ie dialog box) to enter something. But in firefox, it has just "Find" which then focuses on a text input on the same window.