// KEY_PHYS_IGNORE events must be mostly ignored because currently there is no way for a given

// hook instance to detect if it sent the event or some other instance. Therefore, to treat

// such events as true physical events might cause infinite loops or other side-effects in

// the instance that generated the event. More review of this is needed if KEY_PHYS_IGNORE

// events ever need to be treated as true physical events by the instances of the hook that

// didn't originate them. UPDATE: The foregoing can now be accomplished using SendLevel.

{

return aExtraInfo == KEY_IGNORE || aExtraInfo == KEY_PHYS_IGNORE || aExtraInfo == KEY_IGNORE_ALL_EXCEPT_MODIFIER;

{

if (aCode != HC_ACTION) // MSDN docs specify that both LL keybd & mouse hook should return in this case.

return CallNextHookEx(g_KeybdHook, aCode, wParam, lParam);

KBDLLHOOKSTRUCT &event = *(PKBDLLHOOKSTRUCT)lParam; // For convenience, maintainability, and possibly performance.

// Change the event to be physical if that is indicated in its dwExtraInfo attribute.

// This is done for cases when the hook is installed multiple times and one instance of

// it wants to inform the others that this event should be considered physical for the

// purpose of updating modifier and key states:

if (event.dwExtraInfo == KEY_PHYS_IGNORE)

event.flags &= ~LLKHF_INJECTED;

else if (event.dwExtraInfo == KEY_BLOCK_THIS)

return TRUE;

// Make all keybd events physical to try to fool the system into accepting CTRL-ALT-DELETE.

// This didn't work, which implies that Ctrl-Alt-Delete is trapped at a lower level than

// this hook (folks have said that it's trapped in the keyboard driver itself):

//event.flags &= ~LLKHF_INJECTED;

// Note: Some scan codes are shared by more than one key (e.g. Numpad7 and NumpadHome). This is why

// the keyboard hook must be able to handle hotkeys by either their virtual key or their scan code.

// i.e. if sc were always used in preference to vk, we wouldn't be able to distinguish between such keys.

bool key_up = (wParam == WM_KEYUP || wParam == WM_SYSKEYUP);

vk_type vk = (vk_type)event.vkCode;

sc_type sc = (sc_type)event.scanCode;

if (vk && !sc) // Might happen if another app calls keybd_event with a zero scan code.

sc = vk_to_sc(vk);

// MapVirtualKey() does *not* include 0xE0 in HIBYTE if key is extended. In case it ever

// does in the future (or if event.scanCode ever does), force sc to be an 8-bit value

// so that it's guaranteed consistent and to ensure it won't exceed SC_MAX (which might cause

// array indexes to be out-of-bounds). The 9th bit is later set to 1 if the key is extended:

sc &= 0xFF;

// Change sc to be extended if indicated. But avoid doing so for VK_RSHIFT, which is

// apparently considered extended by the API when it shouldn't be. Update: Well, it looks like

// VK_RSHIFT really is an extended key, at least on WinXP (and probably be extension on the other

// NT based OSes as well). What little info I could find on the 'net about this is contradictory,

// but it's clear that some things just don't work right if the non-extended scan code is sent. For

// example, the shift key will appear to get stuck down in the foreground app if the non-extended

// scan code is sent with VK_RSHIFT key-up event:

if ((event.flags & LLKHF_EXTENDED)) // && vk != VK_RSHIFT)

sc |= 0x100;

// The below must be done prior to any returns that indirectly call UpdateKeybdState() to update

// modifier state.

// Update: It seems best to do the below unconditionally, even if the OS is Win2k or WinXP,

// since it seems like this translation will add value even in those cases:

// To help ensure consistency with Windows XP and 2k, for which this hook has been primarily

// designed and tested, translate neutral modifier keys into their left/right specific VKs,

// since beardboy's testing shows that NT4 receives the neutral keys like Win9x does:

switch (vk)

{

case VK_SHIFT: vk = (sc == SC_RSHIFT) ? VK_RSHIFT : VK_LSHIFT; break;

case VK_CONTROL: vk = (sc == SC_RCONTROL) ? VK_RCONTROL : VK_LCONTROL; break;

case VK_MENU: vk = (sc == SC_RALT) ? VK_RMENU : VK_LMENU; break;

}

// Now that the above has translated VK_CONTROL to VK_LCONTROL (if necessary):

if (vk == VK_LCONTROL)

{

// The following helps hasten AltGr detection after script startup. It's kept to supplement

// LayoutHasAltGr() because that function isn't 100% reliable for the reasons described there.

// It shouldn't be necessary to check what type of LControl event (up or down) is received, since

// it should be impossible for any unrelated keystrokes to be received while g_HookReceiptOfLControlMeansAltGr

// is true. This is because all unrelated keystrokes stay buffered until the main thread calls GetMessage().

// UPDATE for v1.0.39: Now that the hook has a dedicated thread, the above is no longer 100% certain.

// However, I think confidence is very high that this AltGr detection method is okay as it is because:

// 1) Hook thread has high priority, which means it generally shouldn't get backlogged with buffered keystrokes.

// 2) When the main thread calls keybd_event(), there is strong evidence that the OS immediately preempts

// the main thread (or executes a SendMessage(), which is the same as preemption) and gives the next

// timeslice to the hook thread, which then immediately processes the incoming keystroke as long

// as there are no keystrokes in the queue ahead of it (see #1).

// 3) Even if #1 and #2 fail to hold, the probability of misclassifying an LControl event seems very low.

// If there is ever concern, adding a call to IsIgnored() below would help weed out physical keystrokes

// (or those of other programs) that arrive during a vulnerable time.

if (g_HookReceiptOfLControlMeansAltGr)

{

// But don't reset g_HookReceiptOfLControlMeansAltGr here to avoid timing problems where the hook

// is installed at a time when g_HookReceiptOfLControlMeansAltGr is wrongly true because the

// inactive hook never made it false. Let KeyEvent() do that.

Get_active_window_keybd_layout // Defines the variable active_window_keybd_layout for use below.

LayoutHasAltGr(active_window_keybd_layout, CONDITION_TRUE);

// The following must be done; otherwise, if LayoutHasAltGr hasn't yet been autodetected by the

// time the first AltGr keystroke comes through, that keystroke would cause LControl to get stuck down

// as seen in g_modifiersLR_physical.

event.flags |= LLKHF_INJECTED; // Flag it as artificial for any other instances of the hook that may be running.

event.dwExtraInfo = g_HookReceiptOfLControlMeansAltGr; // The one who set this variable put the desired ExtraInfo in it.

}

else // Since AltGr wasn't detected above, see if any other means is ready to detect it.

{

// v1.0.42.04: This section was moved out of IsIgnored() to here because:

// 1) Immediately correcting the incoming event simplifies other parts of the hook.

// 2) It allows this instance of the hook to communicate with other instances of the hook by

// correcting the bogus values directly inside the event structure. This is something those

// other hooks can't do easily if the keystrokes were generated/simulated inside our instance

// (due to our instance's KeyEvent() function communicating corrections via

// g_HookReceiptOfLControlMeansAltGr and g_IgnoreNextLControlDown/Up).

//

// This new approach solves an AltGr keystroke's disruption of A_TimeIdlePhysical and related

// problems that were caused by AltGr's incoming keystroke being marked by the driver or OS as a

// physical event (even when the AltGr keystroke that caused it was artificial). It might not

// be a perfect solution, but it's pretty complete. For example, with the exception of artificial

// AltGr keystrokes from non-AHK sources, it completely solves the A_TimeIdlePhysical issue because

// by definition, any script that *uses* A_TimeIdlePhysical in a way that the fix applies to also

// has the keyboard hook installed (if it only has the mouse hook installed, the fix isn't in effect,

// but it also doesn't matter because that script detects only mouse events as true physical events,

// as described in the documentation for A_TimeIdlePhysical).

if (key_up)

{

if (g_IgnoreNextLControlUp)

{

event.flags |= LLKHF_INJECTED; // Flag it as artificial for any other instances of the hook that may be running.

event.dwExtraInfo = g_IgnoreNextLControlUp; // The one who set this variable put the desired ExtraInfo in here.

}

}

else // key-down event

{

if (g_IgnoreNextLControlDown)

{

event.flags |= LLKHF_INJECTED; // Flag it as artificial for any other instances of the hook that may be running.

event.dwExtraInfo = g_IgnoreNextLControlDown; // The one who set this variable put the desired ExtraInfo in here.

}

}

}

} // if (vk == VK_LCONTROL)

return LowLevelCommon(g_KeybdHook, aCode, wParam, lParam, vk, sc, key_up, event.dwExtraInfo, event.flags);

{

// code != HC_ACTION should be evaluated PRIOR to considering the values

// of wParam and lParam, because those values may be invalid or untrustworthy

// whenever code < 0.

if (aCode != HC_ACTION)

return CallNextHookEx(g_MouseHook, aCode, wParam, lParam);

MSLLHOOKSTRUCT &event = *(PMSLLHOOKSTRUCT)lParam; // For convenience, maintainability, and possibly performance.

// Make all mouse events physical to try to simulate mouse clicks in games that normally ignore

// artificial input.

//event.flags &= ~LLMHF_INJECTED;

if (!(event.flags & LLMHF_INJECTED)) // Physical mouse movement or button action (uses LLMHF vs. LLKHF).

g_TimeLastInputPhysical = g_TimeLastInputMouse = GetTickCount();

// Above: Don't use event.time, mostly because SendInput can produce invalid timestamps on such events

// (though in truth, that concern isn't valid because SendInput's input isn't marked as physical).

// Another concern is the comments at the other update of "g_TimeLastInputPhysical" elsewhere in this file.

// A final concern is that some drivers might be faulty and might not generate an accurate timestamp.

if (wParam == WM_MOUSEMOVE) // Only after updating for physical input, above, is this checked.

return (g_BlockMouseMove && !(event.flags & LLMHF_INJECTED)) ? 1 : CallNextHookEx(g_MouseHook, aCode, wParam, lParam);

// Above: In v1.0.43.11, a new mode was added to block mouse movement only since it's more flexible than

// BlockInput (which keybd too, and blocks all mouse buttons too). However, this mode blocks only

// physical mouse movement because it seems most flexible (and simplest) to allow all artificial

// movement, even if that movement came from a source other than an AHK script (such as some other

// macro program).

// MSDN: WM_LBUTTONDOWN, WM_LBUTTONUP, WM_MOUSEMOVE, WM_MOUSEWHEEL [, WM_MOUSEHWHEEL], WM_RBUTTONDOWN, or WM_RBUTTONUP.

// But what about the middle button? It's undocumented, but it is received.

// What about doubleclicks (e.g. WM_LBUTTONDBLCLK): I checked: They are NOT received.

// This is expected because each click in a doubleclick could be separately suppressed by

// the hook, which would make it become a non-doubleclick.

vk_type vk = 0;

sc_type sc = 0; // To be overridden if this even is a wheel turn.

short wheel_delta;

bool key_up = true; // Set default to safest value.

switch (wParam)

{

case WM_MOUSEWHEEL:

case WM_MOUSEHWHEEL: // v1.0.48: Lexikos: Support horizontal scrolling in Windows Vista and later.

// MSDN: "A positive value indicates that the wheel was rotated forward, away from the user;

// a negative value indicates that the wheel was rotated backward, toward the user. One wheel

// click is defined as WHEEL_DELTA, which is 120." Testing shows that on XP at least, the

// abs(delta) is greater than 120 when the user turns the wheel quickly (also depends on

// granularity of wheel hardware); i.e. the system combines multiple turns into a single event.

wheel_delta = GET_WHEEL_DELTA_WPARAM(event.mouseData); // Must typecast to short (not int) via macro, otherwise the conversion to negative/positive number won't be correct.

if (wParam == WM_MOUSEWHEEL)

vk = wheel_delta < 0 ? VK_WHEEL_DOWN : VK_WHEEL_UP;

else

vk = wheel_delta < 0 ? VK_WHEEL_LEFT : VK_WHEEL_RIGHT;

// Dividing by WHEEL_DELTA was a mistake because some mice can yield deltas less than 120.

// However, this behavior is kept for backward compatibility because some scripts may rely

// on A_EventInfo==0 meaning "delta is between 1 and 119". WheelLeft/Right were also done

// that way because consistency may be more important than correctness. In the future, perhaps

// an A_EventInfo2 can be added, or some hotkey aliases like "FineWheelXXX".

sc = (wheel_delta > 0 ? wheel_delta : -wheel_delta) / WHEEL_DELTA; // See above. Note that sc is unsigned.

key_up = false; // Always consider wheel movements to be "key down" events.

break;

case WM_LBUTTONUP: vk = VK_LBUTTON; break;

case WM_RBUTTONUP: vk = VK_RBUTTON; break;

case WM_MBUTTONUP: vk = VK_MBUTTON; break;

case WM_NCXBUTTONUP: // NC means non-client.

case WM_XBUTTONUP: vk = (HIWORD(event.mouseData) == XBUTTON1) ? VK_XBUTTON1 : VK_XBUTTON2; break;

case WM_LBUTTONDOWN: vk = VK_LBUTTON; key_up = false; break;

case WM_RBUTTONDOWN: vk = VK_RBUTTON; key_up = false; break;

case WM_MBUTTONDOWN: vk = VK_MBUTTON; key_up = false; break;

case WM_NCXBUTTONDOWN:

case WM_XBUTTONDOWN: vk = (HIWORD(event.mouseData) == XBUTTON1) ? VK_XBUTTON1 : VK_XBUTTON2; key_up = false; break;

}

return LowLevelCommon(g_MouseHook, aCode, wParam, lParam, vk, sc, key_up, event.dwExtraInfo, event.flags);

, sc_type aSC, bool aKeyUp, ULONG_PTR aExtraInfo, DWORD aEventFlags)

// v1.0.38.06: The keyboard and mouse hooks now call this common function to reduce code size and improve

// maintainability. The code size savings as of v1.0.38.06 is 3.5 KB of uncompressed code, but that

// savings will grow larger if more complexity is ever added to the hooks.

{

WPARAM hotkey_id_to_post = HOTKEY_ID_INVALID; // Set default.

bool is_ignored = IsIgnored(aExtraInfo);

// The following is done for more than just convenience. It solves problems that would otherwise arise

// due to the value of a global var such as KeyHistoryNext changing due to the reentrancy of

// this procedure. For example, a call to KeyEvent() in here would alter the value of

// KeyHistoryNext, in most cases before we had a chance to finish using the old value. In other

// words, we use an automatic variable so that every instance of this function will get its

// own copy of the variable whose value will stays constant until that instance returns:

KeyHistoryItem *pKeyHistoryCurr, khi_temp; // Must not be static (see above). Serves as a storage spot for a single keystroke in case key history is disabled.

if (!g_KeyHistory)

pKeyHistoryCurr = &khi_temp; // Having a non-NULL pKeyHistoryCurr simplifies the code in other places.

else

{

pKeyHistoryCurr = g_KeyHistory g_KeyHistoryNext;

if ( g_KeyHistoryNext >= g_MaxHistoryKeys)

g_KeyHistoryNext = 0;

pKeyHistoryCurr->vk = aVK; // aSC is done later below.

pKeyHistoryCurr->key_up = aKeyUp;

g_HistoryTickNow = GetTickCount();

pKeyHistoryCurr->elapsed_time = (g_HistoryTickNow - g_HistoryTickPrev) / (float)1000;

g_HistoryTickPrev = g_HistoryTickNow;

HWND fore_win = GetForegroundWindow();

if (fore_win)

{

if (fore_win != g_HistoryHwndPrev)

{

// The following line is commented out in favor of the one beneath it (seem below comment):

//GetWindowText(fore_win, pKeyHistoryCurr->target_window, sizeof(pKeyHistoryCurr->target_window));

PostMessage(g_hWnd, AHK_GETWINDOWTEXT, (WPARAM)pKeyHistoryCurr->target_window, (LPARAM)fore_win);

// v1.0.44.12: The reason for the above is that clicking a window's close or minimize button

// (and possibly other types of title bar clicks) causes a delay for the following window, at least

// when XP Theme (but not classic theme) is in effect:

//#InstallMouseHook

//Gui, AlwaysOnTop

//Gui, Show, w200 h100

//return

// The problem came about from the following sequence of events:

// 1) User clicks the one of the script's window's title bar's close, minimize, or maximize button.

// 2) WM_NCLBUTTONDOWN is sent to the window's window proc, which then passes it on to

// DefWindowProc or DefDlgProc, which then apparently enters a loop in which no messages

// (or a very limited subset) are pumped.

// 3) If anyone sends a message to that window (such as GetWindowText(), which sends a message

// in cases where it doesn't have the title pre-cached), the message will not receive a reply

// until after the mouse button is released.

// 4) But the hook is the very thing that's supposed to release the mouse button, and it can't

// until a reply is received.

// 5) Thus, a deadlock occurs. So after a short but noticeable delay, the OS sees the hook as

// unresponsive and bypasses it, sending the click through normally, which breaks the deadlock.

// 6) A similar situation might arise when a right-click-down is sent to the title bar or

// sys-menu-icon.

//

// SOLUTION:

// Post the message to our main thread to have it do the GetWindowText call. That way, if

// the target window is one of the main thread's own window's, there's no chance it can be

// in an unresponsive state like the deadlock described above. In addition, do this for ALL

// windows because its simpler, more maintainable, and especially might solve other hook

// performance problems if GetWindowText() has other situations where it is slow to return

// (which seems likely).

// Although the above solution could create rare situations where there's a lag before window text

// is updated, that seems unlikely to be common or have significant consequences. Furthermore,

// it has the advantage of improving hook performance by avoiding the call to GetWindowText (which

// incidentally might solve hotkey lag problems that have been observed while the active window

// is momentarily busy/unresponsive -- but maybe not because the main thread would then be lagged

// instead of the hook thread, which is effectively the same result from user's POV).

// Note: It seems best not to post the message to the hook thread because if LButton is down,

// the hook's main event loop would be sending a message to an unresponsive thread (our main thread),

// which would create the same deadlock.

// ALTERNATE SOLUTIONS:

// - #1: Avoid calling GetWindowText at all when LButton or RButton is in a logically-down state.

// - Same as #1, but do so only if one of the main thread's target windows is known to be in a tight loop (might be too unreliable to detect all such cases).

// - Same as #1 but less rigorous and more catch-all, such as by checking if the active window belongs to our thread.

// - Avoid calling GetWindowText at all upon release of LButton.

// - Same, but only if the window to have text retrieved belongs to our process.

// - Same, but only if the mouse is inside the close/minimize/etc. buttons of the active window.

}

else // i.e. where possible, avoid the overhead of the call to GetWindowText().

*pKeyHistoryCurr->target_window = '\0';

}

else

_tcscpy(pKeyHistoryCurr->target_window, _T("N/A")); // Due to AHK_GETWINDOWTEXT, this could collide with main thread's writing to same string; but in addition to being extremely rare, it would likely be inconsequential.

g_HistoryHwndPrev = fore_win; // Updated unconditionally in case fore_win is NULL.

}

// Keep the following flush with the above to indicate that they're related.

// The following is done even if key history is disabled because firing a wheel hotkey via PostMessage gets

// the notch count from pKeyHistoryCurr->sc.

if (aVK == VK_PACKET) // Win2k/XP: VK_PACKET is used to send Unicode characters as if they were keystrokes. sc is a 16-bit character code in that case.

{

pKeyHistoryCurr->sc = aSC = (sc_type)((PKBDLLHOOKSTRUCT)lParam)->scanCode; // Get the full value; aSC was truncated by the caller.

pKeyHistoryCurr->event_type = 'U'; // Give it a unique identifier even though it can be distinguished by the 4-digit "SC". 'U' vs 'u' to avoid confusion with 'u'=up.

// Artificial character input via VK_PACKET isn't supported by hotkeys, since they always work via

// keycode, but hotstrings and Input are supported via the macro below when #InputLevel is non-zero.

// Must return now to avoid misinterpreting aSC as an actual scancode in the code below.

return AllowKeyToGoToSystem;

}

//else: Use usual modified value.

pKeyHistoryCurr->sc = aSC; // Will be zero if our caller is the mouse hook (except for wheel notch count).

// After logging the wheel notch count (above), purify aSC for readability and maintainability.

if (IS_WHEEL_VK(aVK))

aSC = 0; // Also relied upon by sc_takes_precedence below.

bool is_artificial;

if (aHook == g_MouseHook)

{

if ( !(is_artificial = (aEventFlags & LLMHF_INJECTED)) ) // It's a physical mouse event.

g_PhysicalKeyState[aVK] = aKeyUp ? 0 : STATE_DOWN;

}

else // Keybd hook.

{

// Even if the below is set to false, the event might be reclassified as artificial later (though it

// won't be logged as such). See comments in KeybdEventIsPhysical() for details.

is_artificial = aEventFlags & LLKHF_INJECTED; // LLKHF vs. LLMHF

// If the scan code is extended, the key that was pressed is not a dual-state numpad key,

// i.e. it could be the counterpart key, such as End vs. NumpadEnd, located elsewhere on

// the keyboard, but we're not interested in those. Also, Numlock must be ON because

// otherwise the driver will not generate those false-physical shift key events:

if (!(aSC & 0x100) && (IsKeyToggledOn(VK_NUMLOCK)))

{

switch (aVK)

{

case VK_DELETE: case VK_DECIMAL: sPadState[PAD_DECIMAL] = !aKeyUp; break;

case VK_INSERT: case VK_NUMPAD0: sPadState[PAD_NUMPAD0] = !aKeyUp; break;

case VK_END: case VK_NUMPAD1: sPadState[PAD_NUMPAD1] = !aKeyUp; break;

case VK_DOWN: case VK_NUMPAD2: sPadState[PAD_NUMPAD2] = !aKeyUp; break;

case VK_NEXT: case VK_NUMPAD3: sPadState[PAD_NUMPAD3] = !aKeyUp; break;

case VK_LEFT: case VK_NUMPAD4: sPadState[PAD_NUMPAD4] = !aKeyUp; break;

case VK_CLEAR: case VK_NUMPAD5: sPadState[PAD_NUMPAD5] = !aKeyUp; break;

case VK_RIGHT: case VK_NUMPAD6: sPadState[PAD_NUMPAD6] = !aKeyUp; break;

case VK_HOME: case VK_NUMPAD7: sPadState[PAD_NUMPAD7] = !aKeyUp; break;

case VK_UP: case VK_NUMPAD8: sPadState[PAD_NUMPAD8] = !aKeyUp; break;

case VK_PRIOR: case VK_NUMPAD9: sPadState[PAD_NUMPAD9] = !aKeyUp; break;

}

}

// Track physical state of keyboard & mouse buttons. Also, if it's a modifier, let another section

// handle it because it's not as simple as just setting the value to true or false (e.g. if LShift

// goes up, the state of VK_SHIFT should stay down if VK_RSHIFT is down, or up otherwise).

// Also, even if this input event will wind up being suppressed (usually because of being

// a hotkey), still update the physical state anyway, because we want the physical state to

// be entirely independent of the logical state (i.e. we want the key to be reported as

// physically down even if it isn't logically down):

if (!kvk[aVK].as_modifiersLR && KeybdEventIsPhysical(aEventFlags, aVK, aKeyUp))

g_PhysicalKeyState[aVK] = aKeyUp ? 0 : STATE_DOWN;

// Pointer to the key record for the current key event. Establishes this_key as an alias

// for the array element in kvk or ksc that corresponds to the vk or sc, respectively.

// I think the compiler can optimize the performance of reference variables better than

// pointers because the pointer indirection step is avoided. In any case, this must be

// a true alias to the object, not a copy of it, because it's address (&this_key) is compared

// to other addresses for equality further below.

}

// The following is done even if key history is disabled because sAltTabMenuIsVisible relies on it:

pKeyHistoryCurr->event_type = is_ignored ? 'i' : (is_artificial ? 'a' : ' '); // v1.0.42.04: 'a' was added, but 'i' takes precedence over 'a'.

// v1.0.43: Block the Win keys during journal playback to prevent keystrokes hitting the Start Menu

// if the user accidentally presses one of those keys during playback. Note: Keys other than Win

// don't need to be blocked because the playback hook defers them until after playback.

// Only block the down-events in case the user is physically holding down the key at the start

// of playback but releases it during the Send (avoids Win key becoming logically stuck down).

// This also serves to block Win shortcuts such as Win R and Win E during playback.

// Also, it seems best to block artificial LWIN keystrokes too, in case some other script or

// program tries to display the Start Menu during playback.

if (g_BlockWinKeys && (aVK == VK_LWIN || aVK == VK_RWIN) && !aKeyUp)

return SuppressThisKey;

// v1.0.37.07: Cancel the alt-tab menu upon receipt of Escape so that it behaves like the OS's native Alt-Tab.

// Even if is_ignored==true, it seems more flexible/useful to cancel the Alt-Tab menu upon receiving

// an Escape keystroke of any kind.

// Update: Must not handle Alt-Up here in a way similar to Esc-down in case the hook sent Alt-up to

// dismiss its own menu. Otherwise, the shift key might get stuck down if Shift-Alt-Tab was in effect.

// Instead, the release-of-prefix-key section should handle it via its checks of this_key.it_put_shift_down, etc.

if (sAltTabMenuIsVisible && aVK == VK_ESCAPE && !aKeyUp)

{

// When the alt-tab window is owned by the script (it is owned by csrss.exe unless the script

// is the process that invoked the alt-tab window), testing shows that the script must be the

// originator of the Escape keystroke. Therefore, substitute a simulated keystroke for the

// user's physical keystroke. It might be necessary to do this even if is_ignored==true because

// a keystroke from some other script/process might not qualify as a valid means to cancel it.

// UPDATE for v1.0.39: The escape handler below works only if the hook's thread invoked the

// alt-tab window, not if the script's thread did via something like "Send {Alt down}{tab down}".

// This is true even if the process ID is checked instead of the thread ID below. I think this

// behavior is due to the window obeying escape only when its own thread sends it. This

// is probably done to allow a program to automate the alt-tab menu without interference

// from Escape keystrokes typed by the user. Although this could probably be fixed by

// sending a message to the main thread and having it send the Escape keystroke, it seems

// best not to do this because:

// 1) The ability to dismiss a script-invoked alt-tab menu with escape would vary depending on

// whether the keyboard hook is installed (i.e. it's inconsistent).

// 2) It's more flexible to preserve the ability to protect the alt-tab menu from physical

// escape keystrokes typed by the user. The script can simulate an escape key to explicitly

// close an alt-tab window it invoked (a simulated escape keystroke can apparently also close

// any alt-tab menu, even one invoked by physical keystrokes; but the converse isn't true).

// 3) Lesser reason: Reduces code size and complexity.

HWND alt_tab_window;

if ((alt_tab_window = FindWindow(_T("#32771"), NULL)) // There is an alt-tab window...

&& GetWindowThreadProcessId(alt_tab_window, NULL) == GetCurrentThreadId()) // ...and it's owned by the hook thread (not the main thread).

{

KeyEvent(KEYDOWN, VK_ESCAPE);

// By definition, an Alt key should be logically down if the alt-tab menu is visible (even if it

// isn't, sending an extra up-event seems harmless). Releasing that Alt key seems best because:

// 1) If the prefix key that pushed down the alt key is still physically held down and the user

// presses a new (non-alt-tab) suffix key to form a hotkey, it avoids any alt-key disruption

// of things such as MouseClick that that subroutine might due.

// 2) If the user holds down the prefix, presses Escape to dismiss the menu, then presses an

// alt-tab suffix, testing shows that the existing alt-tab logic here in the hook will put

// alt or shift-alt back down if it needs to.

KeyEvent(KEYUP, (g_modifiersLR_logical & MOD_RALT) ? VK_RMENU : VK_LMENU);

return SuppressThisKey; // Testing shows that by contrast, the upcoming key-up on Escape doesn't require this logic.

}

// Otherwise, the alt-tab window doesn't exist or (more likely) it's owned by some other process

// such as crss.exe. Do nothing extra to avoid interfering with the native function of Escape or

// any remappings or hotkeys assigned to Escape. Also, do not set sAltTabMenuIsVisible to false

// in any of the cases here because there is logic elsewhere in the hook that does that more

// reliably; it takes into account things such as whether the Escape keystroke will be suppressed

// due to being a hotkey).

}

bool sc_takes_precedence = ksc[aSC].sc_takes_precedence;

// Check hook type too in case a script every explicitly specifies scan code zero as a hotkey:

key_type &this_key = *((aHook == g_KeybdHook && sc_takes_precedence) ? (ksc aSC) : (kvk aVK));

// Do this after above since AllowKeyToGoToSystem requires that sc be properly determined.

// Another reason to do it after the above is due to the fact that KEY_PHYS_IGNORE permits

// an ignored key to be considered physical input, which is handled above:

if (is_ignored)

{

// This is a key sent by our own app that we want to ignore.

// It's important never to change this to call the SuppressKey function because

// that function would cause an infinite loop when the Numlock key is pressed,

// which would likely hang the entire system:

// UPDATE: This next part is for cases where more than one script is using the hook

// simultaneously. In such cases, it desirable for the KEYEVENT_PHYS() of one

// instance to affect the down-state of the current prefix-key in the other

// instances. This check is done here -- even though there may be a better way to

// implement it -- to minimize the chance of side-effects that a more fundamental

// change might cause (i.e. a more fundamental change would require a lot more

// testing, though it might also fix more things):

if (aExtraInfo == KEY_PHYS_IGNORE && aKeyUp && pPrefixKey == &this_key)

{

this_key.is_down = false;

this_key.down_performed_action = false; // Seems best, but only for PHYS_IGNORE.

pPrefixKey = NULL;

}

return AllowKeyToGoToSystem;

}

if (!aKeyUp) // Set defaults for this down event.

{

this_key.hotkey_down_was_suppressed = false;

this_key.hotkey_to_fire_upon_release = HOTKEY_ID_INVALID;

// Don't do the following because of the keyboard key-repeat feature. In other words,

// the NO_SUPPRESS_NEXT_UP_EVENT should stay pending even in the face of consecutive

// down-events. Even if it's possible for the flag to never be cleared due to never

// reaching any of the parts that clear it (which currently seems impossible), it seems

// inconsequential since by its very nature, this_key never consults the flag.

// this_key.no_suppress &= ~NO_SUPPRESS_NEXT_UP_EVENT;

}

if (aHook == g_MouseHook)

{

// If no vk, there's no mapping for this key, so currently there's no way to process it.

if (!aVK)

return AllowKeyToGoToSystem;

// Also, if the script is displaying a menu (tray, main, or custom popup menu), always

// pass left-button events through -- even if LButton is defined as a hotkey -- so

// that menu items can be properly selected. This is necessary because if LButton is

// a hotkey, it can't launch now anyway due to the script being uninterruptible while

// a menu is visible. And since it can't launch, it can't do its typical "MouseClick

// left" to send a true mouse-click through as a replacement for the suppressed

// button-down and button-up events caused by the hotkey. Also, for simplicity this

// is done regardless of which modifier keys the user is holding down since the desire

// to fire mouse hotkeys while a context or popup menu is displayed seems too rare.

//

// Update for 1.0.37.05: The below has been extended to look for menus beyond those

// supported by g_MenuIsVisible, namely the context menus of a MonthCal or Edit control

// (even the script's main window's edit control's context menu). It has also been

// extended to include RButton because:

// 1) Right and left buttons may have been swapped via control panel to take on each others' functions.

// 2) Right-click is a valid way to select a context menu items (but apparently not popup or menu bar items).

// 3) Right-click should invoke another instance of the context menu (or dismiss existing menu, depending

// on where the click occurs) if user clicks outside of our thread's existing context menu.

HWND menu_hwnd;

if ( (aVK == VK_LBUTTON || aVK == VK_RBUTTON) && (g_MenuIsVisible // Ordered for short-circuit performance.

|| ((menu_hwnd = FindWindow(_T("#32768"), NULL))

&& GetWindowThreadProcessId(menu_hwnd, NULL) == g_MainThreadID)) ) // Don't call GetCurrentThreadId() because our thread is different than main's.

{

// Bug-fix for v1.0.22: If "LControl & LButton::" (and perhaps similar combinations)

// is a hotkey, the foreground window would think that the mouse is stuck down, at least

// if the user clicked outside the menu to dismiss it. Specifically, this comes about

// as follows:

// The wrong up-event is suppressed:

// ...because down_performed_action was true when it should have been false

// ...because the while-menu-was-displayed up-event never set it to false

// ...because it returned too early here before it could get to that part further below.

this_key.down_performed_action = false; // Seems ok in this case to do this for both aKeyUp and !aKeyUp.

this_key.is_down = !aKeyUp;

return AllowKeyToGoToSystem;

}

} // Mouse hook.

// Any key-down event (other than those already ignored and returned from,

// above) should probably be considered an attempt by the user to use the

// prefix key that's currently being held down as a "modifier". That way,

// if pPrefixKey happens to also be a suffix, its suffix action won't fire

// when the key is released, which is probably the correct thing to do 90%

// or more of the time. But don't consider the modifiers themselves to have

// been modified by a prefix key, since that is almost never desirable:

if (pPrefixKey && pPrefixKey != &this_key && !aKeyUp) // There is a prefix key being held down and the user has now pressed some other key.

if ( (aHook == g_KeybdHook) ? !this_key.as_modifiersLR : pPrefixKey->as_modifiersLR )

pPrefixKey->was_just_used = AS_PREFIX; // Indicate that currently-down prefix key has been "used".

// Formerly, the above was done only for keyboard hook, not the mouse. This was because

// most people probably would not want a prefix key's suffix-action to be stopped

// from firing just because a non-hotkey mouse button was pressed while the key

// was held down (i.e. for games). But now a small exception to this has been made:

// Prefix keys that are also modifiers (ALT/SHIFT/CTRL/WIN) will now not fire their

// suffix action on key-up if they modified a mouse button event (since Ctrl-LeftClick,

// for example, is a valid native action and we don't want to give up that flexibility).

// WinAPI docs state that for both virtual keys and scan codes:

// "If there is no translation, the return value is zero."

// Therefore, zero is never a key that can be validly configured (and likely it's never received here anyway).

// UPDATE: For performance reasons, this check isn't even done. Even if sc and vk are both zero, both kvk[0]

// and ksc[0] should have all their attributes initialized to FALSE so nothing should happen for that key

// anyway.

//if (!vk && !sc)

// return AllowKeyToGoToSystem;

if (!this_key.used_as_prefix && !this_key.used_as_suffix)

return AllowKeyToGoToSystem;

HotkeyIDType hotkey_id_with_flags = HOTKEY_ID_INVALID; // Set default.

HotkeyVariant *firing_is_certain = NULL; //

HotkeyIDType hotkey_id_temp; // For informal/temp storage of the ID-without-flags.

bool down_performed_action, was_down_before_up;

if (aKeyUp)

{

// Save prior to reset. These var's should only be used further below in conjunction with aKeyUp

// being TRUE. Otherwise, their values will be unreliable (refer to some other key, probably).

was_down_before_up = this_key.is_down;

down_performed_action = this_key.down_performed_action; // Save prior to reset below.

// Reset these values in preparation for the next call to this procedure that involves this key:

this_key.down_performed_action = false;

if (this_key.hotkey_to_fire_upon_release != HOTKEY_ID_INVALID)

{

hotkey_id_with_flags = this_key.hotkey_to_fire_upon_release;

// The line below is done even though the down-event also resets it in case it is ever

// possible for keys to generate multiple consecutive key-up events (faulty or unusual keyboards?)

this_key.hotkey_to_fire_upon_release = HOTKEY_ID_INVALID;

}

}

this_key.is_down = !aKeyUp;

bool modifiers_were_corrected = false;

if (aHook == g_KeybdHook)

{

// The below was added to fix hotkeys that have a neutral suffix such as "Control & LShift".

// It may also fix other things and help future enhancements:

if (this_key.as_modifiersLR)

{

// The neutral modifier "Win" is not currently supported.

kvk[VK_CONTROL].is_down = kvk[VK_LCONTROL].is_down || kvk[VK_RCONTROL].is_down;

kvk[VK_MENU].is_down = kvk[VK_LMENU].is_down || kvk[VK_RMENU].is_down;

kvk[VK_SHIFT].is_down = kvk[VK_LSHIFT].is_down || kvk[VK_RSHIFT].is_down;

// No longer possible because vk is translated early on from neutral to left-right specific:

// I don't think these ever happen with physical keyboard input, but it might with artificial input:

//case VK_CONTROL: kvk[sc == SC_RCONTROL ? VK_RCONTROL : VK_LCONTROL].is_down = !aKeyUp; break;

//case VK_MENU: kvk[sc == SC_RALT ? VK_RMENU : VK_LMENU].is_down = !aKeyUp; break;

//case VK_SHIFT: kvk[sc == SC_RSHIFT ? VK_RSHIFT : VK_LSHIFT].is_down = !aKeyUp; break;

}

}

else // Mouse hook

{

// If the mouse hook is installed without the keyboard hook, update g_modifiersLR_logical

// manually so that it can be referred to by the mouse hook after this point:

if (!g_KeybdHook)

{

g_modifiersLR_logical = g_modifiersLR_logical_non_ignored = GetModifierLRState(true);

modifiers_were_corrected = true;

}

}

modLR_type modifiersLRnew;

bool this_toggle_key_can_be_toggled = this_key.pForceToggle && *this_key.pForceToggle == NEUTRAL; // Relies on short-circuit boolean order.

///////////////////////////////////////////////////////////////////////////////////////

// CASE #1 of 4: PREFIX key has been pressed down. But use it in this capacity only if

// no other prefix is already in effect or if this key isn't a suffix. Update: Or if

// this key-down is the same as the prefix already down, since we want to be able to

// a prefix when it's being used in its role as a modified suffix (see below comments).

///////////////////////////////////////////////////////////////////////////////////////

if (this_key.used_as_prefix && !aKeyUp && (!pPrefixKey || !this_key.used_as_suffix || &this_key == pPrefixKey))

{

// v1.0.41: Even if this prefix key is non-suppressed (passes through to active window),

// still call PrefixHasNoEnabledSuffixes() because don't want to overwrite the old value of

// pPrefixKey (see comments in "else" later below).

// v1.0.44: Added check for PREFIX_ACTUAL so that a PREFIX_FORCED prefix will be considered

// a prefix even if it has no suffixes. This fixes an unintentional change in v1.0.41 where

// naked, neutral modifier hotkeys Control::, Alt::, and Shift:: started firing on press-down

// rather than release as intended. The PREFIX_FORCED facility may also provide the means to

// introduce a new hotkey modifier such as an "up2" keyword that makes any key into a prefix

// key even if it never acts as a prefix for other keys, which in turn has the benefit of firing

// on key-up, but only if the no other key was pressed while the user was holding it down.

bool has_no_enabled_suffixes;

if ( !(has_no_enabled_suffixes = (this_key.used_as_prefix == PREFIX_ACTUAL)

&& Hotkey::PrefixHasNoEnabledSuffixes(sc_takes_precedence ? aSC : aVK, sc_takes_precedence)) )

{

// This check is necessary in cases such as the following, in which the "A" key continues

// to repeat because pressing a mouse button (unlike pressing a keyboard key) does not

// stop the prefix key from repeating:

// $a::send, a

// a & lbutton::

if (&this_key != pPrefixKey)

{

// Override any other prefix key that might be in effect with this one, in case the

// prior one, due to be old for example, was invalid somehow. UPDATE: It seems better

// to leave the old one in effect to support the case where one prefix key is modifying

// a second one in its role as a suffix. In other words, if key1 is a prefix and

// key2 is both a prefix and a suffix, we want to leave key1 in effect as a prefix,

// rather than key2. Hence, a null-check was added in the above if-stmt:

pPrefixKey = &this_key;

// It should be safe to init this because even if the current key is repeating,

// it should be impossible to receive here the key-downs that occurred after

// the first, because there's a return-on-repeat check farther above (update: that check

// is gone now). Even if that check weren't done, it's safe to reinitialize this to zero

// because on most (all?) keyboards & OSs, the moment the user presses another key while

// this one is held down, the key-repeating ceases and does not resume for

// this key (though the second key will begin to repeat if it too is held down).

// In other words, the fear that this would be wrongly initialized and thus cause

// this prefix's suffix-action to fire upon key-release seems unfounded.

// It seems easier (and may perform better than alternative ways) to init this

// here rather than say, upon the release of the prefix key:

this_key.was_just_used = 0; // Init to indicate it hasn't yet been used in its role as a prefix.

}

}

//else this prefix has no enabled suffixes, so its role as prefix is also disabled.

// Therefore, don't set pPrefixKey to this_key because don't want the following line

// (in another section) to execute when a suffix comes in (there may be other reasons too,

// such as not wanting to lose track of the previous prefix key in cases where the user is

// holding down more than one prefix):

// pPrefixKey->was_just_used = AS_PREFIX

if (this_key.used_as_suffix) // v1.0.41: Added this check to avoid doing all of the below when unnecessary.

{

// This new section was added May 30, 2004, to fix scenarios such as the following example:

// a & b::Msgbox a & b

// $^a::MsgBox a

// Previously, the ^a hotkey would only fire on key-up (unless it was registered, in which

// case it worked as intended on the down-event). When the user presses A, it's okay (and

// probably desirable) to have recorded that event as a prefix-key-down event (above).

// But in addition to that, we now check if this is a normal, modified hotkey that should

// fire now rather than waiting for the key-up event. This is done because it makes sense,

// it's more correct, and also it makes the behavior of a hooked ^a hotkey consistent with

// that of a registered ^a.

// Prior to considering whether to fire a hotkey, correct the hook's modifier state.

// Although this is rarely needed, there are times when the OS disables the hook, thus

// it is possible for it to miss keystrokes. See comments in GetModifierLRState()

// for more info:

if (!modifiers_were_corrected)

{

modifiers_were_corrected = true;

GetModifierLRState(true);

}

// non_ignored is always used when considering whether a key combination is in place to

// trigger a hotkey:

modifiersLRnew = g_modifiersLR_logical_non_ignored;

if (this_key.as_modifiersLR) // This will always be false if our caller is the mouse hook.

// Hotkeys are not defined to modify themselves, so look for a match accordingly.

modifiersLRnew &= ~this_key.as_modifiersLR;

// For this case to be checked, there must be at least one modifier key currently down (other

// than this key itself if it's a modifier), because if there isn't and this prefix is also

// a suffix, its suffix action should only fire on key-up (i.e. not here, but later on).

// UPDATE: In v1.0.41, an exception to the above is when a prefix is disabled via

// has_no_enabled_suffixes, in which case it seems desirable for most uses to have its

// suffix action fire on key-down rather than key-up.

// UPDATE: Another exception was added so that the no-suppress prefix allows the key to function

// as if the custom combination wasn't defined. For example, ~x & y:: allows x:: to retain its

// normal behaviour, firing the subroutine on key-down and blocking the keystroke. This is more

// useful and intuitive/consistent than the old behaviour, which was to fire the suffix hotkey

// on key-up even though the key-down wasn't suppressed (unless either of the first two conditions

// below were met).

if (modifiersLRnew || has_no_enabled_suffixes || (this_key.no_suppress & NO_SUPPRESS_PREFIX))

{

// Check hook type too in case a script every explicitly specifies scan code zero as a hotkey:

hotkey_id_with_flags = (aHook == g_KeybdHook && sc_takes_precedence)

? Kscm(modifiersLRnew, aSC) : Kvkm(modifiersLRnew, aVK);

if (hotkey_id_with_flags & HOTKEY_KEY_UP) // And it's okay even if it's is HOTKEY_ID_INVALID.

{

// Queue it for later, which is done here rather than upon release of the key so that

// the user can release the key's modifiers before releasing the key itself, which

// is likely to happen pretty often. v1.0.41: This is done even if the hotkey is subject

// to #IfWin because it seems more correct to check those criteria at the actual time

// the key is released rather than now:

this_key.hotkey_to_fire_upon_release = hotkey_id_with_flags;

hotkey_id_with_flags = HOTKEY_ID_INVALID;

}

else // hotkey_id_with_flags is either HOTKEY_ID_INVALID or a valid key-down hotkey.

{

hotkey_id_temp = hotkey_id_with_flags & HOTKEY_ID_MASK;

if (hotkey_id_temp < Hotkey::sHotkeyCount)

this_key.hotkey_to_fire_upon_release = hotkey_up[hotkey_id_temp]; // Might assign HOTKEY_ID_INVALID.

// Since this prefix key is being used in its capacity as a suffix instead,

// hotkey_id_with_flags now contains a hotkey ready for firing later below.

// v1.0.41: Above is done even if the hotkey is subject to #IfWin because:

// 1) The down-hotkey's #IfWin criteria might be different from that of the up's.

// 2) It seems more correct to check those criteria at the actual time the key is

// released rather than now (and also probably reduces code size).

}

}

// Alt-tab need not be checked here (like it is in the similar section below) because all

// such hotkeys use (or were converted at load-time to use) a modifier_vk, not a set of

// modifiers or modifierlr's.

} // if (this_key.used_as_suffix)

if (hotkey_id_with_flags == HOTKEY_ID_INVALID)

{

if (has_no_enabled_suffixes)

{

this_key.no_suppress |= NO_SUPPRESS_NEXT_UP_EVENT; // Since the "down" is non-suppressed, so should the "up".

pKeyHistoryCurr->event_type = _T('#'); // '#' to indicate this prefix key is disabled due to #IfWin criterion.

}

// In this case, a key-down event can't trigger a suffix, so return immediately.

// If our caller is the mouse hook, both of the following will always be false:

// this_key.as_modifiersLR

// this_toggle_key_can_be_toggled

if (this_key.as_modifiersLR || (this_key.no_suppress & NO_SUPPRESS_PREFIX)

|| this_toggle_key_can_be_toggled || has_no_enabled_suffixes)

return AllowKeyToGoToSystem;

// Mark this key as having been suppressed. This currently doesn't have any known effect

// since the change to tilde (~) handling in v1.0.95 (commit 161162b8), but may in future.

// Search for "SEND_NOSUPPRESS_PREFIX_KEY_ON_RELEASE" for related comments.

//#define SEND_NOSUPPRESS_PREFIX_KEY_ON_RELEASE

// Without this next assignment, the following issues occur if the above line is uncommented:

// 1) ~prefixkey:: allows just a key-up to pass through, without first sending a key-down as

// originally intended.

// 2) #if false .. ~prefixkey:: causes the key-up to pass through when it should be suppressed.

this_key.hotkey_down_was_suppressed = true;

return SuppressThisKey;

}

//else valid suffix hotkey has been found; this will now fall through to Case #4 by virtue of aKeyUp==false.

}

//////////////////////////////////////////////////////////////////////////////////

// CASE #2 of 4: SUFFIX key (that's not a prefix, or is one but has just been used

// in its capacity as a suffix instead) has been released.

// This is done before Case #3 for performance reasons.

//////////////////////////////////////////////////////////////////////////////////

// v1.0.37.05: Added "|| down_performed_action" to the final check below because otherwise a

// script such as the following would send two M's for b, one upon down and one upon up:

// b::Send, M

// b & z::return

// I don't remember exactly what the "pPrefixKey != &this_key" check is for below, but it is kept

// to minimize the chance of breaking other things:

bool fell_through_from_case2 = false; // Set default.

if (this_key.used_as_suffix && aKeyUp && (pPrefixKey != &this_key || down_performed_action)) // Note: hotkey_id_with_flags might be already valid due to this_key.hotkey_to_fire_upon_release.

{

if (pPrefixKey == &this_key) // v1.0.37.05: Added so that scripts such as the example above don't leave pPrefixKey wrongly non-NULL.

pPrefixKey = NULL; // Also, it seems unnecessary to check this_key.it_put_alt_down and such like is done in Case #3.

// If it did perform an action, suppress this key-up event. Do this even

// if this key is a modifier because it's previous key-down would have

// already been suppressed (since this case is for suffixes that aren't

// also prefixes), thus the key-up can be safely suppressed as well.

// It's especially important to do this for keys whose up-events are

// special actions within the OS, such as AppsKey, Lwin, and Rwin.

// Toggleable keys are also suppressed here on key-up because their

// previous key-down event would have been suppressed in order for

// down_performed_action to be true. UPDATE: Added handling for

// NO_SUPPRESS_NEXT_UP_EVENT and also applied this next part to both

// mouse and keyboard.

// v1.0.40.01: It was observed that a hotkey that consists of a mouse button as a prefix and

// a keyboard key as a suffix can cause sticking keys in rare cases. For example, when

// "MButton & LShift" is a hotkey, if you hold down LShift long enough for it to begin

// auto-repeating then press MButton, the hotkey fires the next time LShift auto-repeats (since

// pressing a mouse button doesn't stop a keyboard key from auto-repeating). Fixing that type

// of firing seems likely to break more things than it fixes. But since it isn't fixed, when

// the user releases LShift, the up-event is suppressed here, which causes the key to get

// stuck down. That could be fixed in the following ways, but all of them seem likely to break

// more things than they fix, especially given the rarity that both a hotkey of this type would

// exist and its mirror image does something useful that isn't a hotkey (for example, Shift MButton

// is a meaningful action in few if any applications):

// 1) Don't suppress the physical release of a suffix key if that key is logically down (as reported

// by GetKeyState/GetAsyncKeyState): Seems too broad in scope because there might be cases where

// the script or user wants the key to stay logically down (e.g. Send {Shift down}{a down}).

// 2) Same as #1 but limit the non-suppression to only times when the suffix key was logically down

// when its first qualified physical down-event came in. This is definitely better but like

// #1, the uncertainty of breaking existing scripts and/or causing more harm than good seems too

// high.

// 3) Same as #2 but limit it only to cases where the suffix key is a keyboard key and its prefix

// is a mouse key. Although very selective, it doesn't mitigate the fact it might still do more

// harm than good and/or break existing scripts.

// In light of the above, it seems best to keep this documented here as a known limitation for now.

//

// v1.0.28: The following check is done to support certain keyboards whose keys or scroll wheels

// generate up events without first having generated any down-event for the key. UPDATE: I think

// this check is now also needed to allow fall-through in cases like "b" and "b up" both existing.

if (!this_key.used_as_key_up)

{

bool suppress_up_event;

if (this_key.no_suppress & NO_SUPPRESS_NEXT_UP_EVENT)

{

suppress_up_event = false;

this_key.no_suppress &= ~NO_SUPPRESS_NEXT_UP_EVENT; // This ticket has been used up.

}

else // the default is to suppress the up-event.

suppress_up_event = true;

return (down_performed_action && suppress_up_event) ? SuppressThisKey : AllowKeyToGoToSystem;

}

//else continue checking to see if the right modifiers are down to trigger one of this

// suffix key's key-up hotkeys.

fell_through_from_case2 = true;

}

//////////////////////////////////////////////