키와 버튼 리맵하기

들어가는 말

한계: 아래에 기술하는 오토핫키의 리맵핑 특징은 일반적으로 윈도우즈 레지스트리를 통하여 리맵핑 하는 것에 비해 순수하지 못하며 효과도 그에 못 미칩니다. 각 접근법의 장점과 단점에 관한 것은 레지스트리 리맵핑을 참조하십시오.

키보드와 마우스 리맵하기

내장 리맵핑 특징의 구문은 OriginKey::DestinationKey입니다. 예를 들어, 다음 줄만 들어있는 스크립트는 "a" 키를 마치 "b" 키처럼 행동하게 만듭니다:

a::b

위의 예제는 "b" 키 자체를 변경하지 않습니다. "b" 키는 계속해서 "b" 키눌림을 전송합니다. 다음 예제와 같이 다른 것에 리맵하지만 않는다면 말입니다:

a::b
b::a

위의 예제는 소문자를 사용합니다. 대부분의 목적에 소문자를 권합니다. 왜냐하면 상응하는 대문자도 리맵되기 때문입니다 (즉, Capslock이 "켜져" 있거나 Shift 키가 눌리면 대문자가 전송됩니다). 대조적으로, 대문자를 오른쪽에 지정하면 대문자를 강제합니다. 예를 들어, 다음 줄은 (Capslock이 꺼져 있는 한) "a"나 "A"를 누를 때 대문자 B를 생산합니다:

a::B

마우스 리맵핑: 키보드 대신에 마우스를 리맵하려면 같은 접근법을 사용합니다. 예를 들어:

MButton::Shift	가운데 버튼을 마치 Shift 키처럼 행동하게 만듭니다.
XButton1::LButton	네 번째 마우스 버튼을 왼쪽 버튼처럼 행위하게 만듭니다.
RAlt::RButton	오른쪽 Alt 키를 오른쪽 마우스 버튼 처럼 행위하게 만듭니다.

다른 유용한 리맵핑:

Capslock::Ctrl	Capslock을 Control 키가 되도록 만듭니다. Capslock을 그대로 켜고 끌 수 있도록 하기 위해, 먼저 `+Capslock::Capslock` 리맵핑을 추가합니다. 이렇게 하면 Shift 키를 누른 채 Capslock을 누를 때 Capslock을 토글합니다. 두 리맵핑 모두 추가 수식키가 눌려 있는 것을 허용하기 때문에, 더 구체적으로 `+Capslock::Capslock` 리맵핑을 먼저 배치해야 `Capslock::Ctrl`이 작동할 수 있습니다.
XButton2::^LButton	다섯 번째 마우스 버튼을 (XButton2) Control-LeftClick이 되도록 만듭니다.
RAlt::AppsKey	오른쪽 Alt 키는Apps 키가 됩니다 (문맥 메뉴를 여는 키입니다).
RCtrl::RWin	오른쪽 Control 키를 오른쪽 Windows 키가 되도록 만듭니다.
Ctrl::Alt	Control 키를 Alt 키처럼 행위하도록 만듭니다. 그렇지만, alt-tab 문제를 참조하십시오.
^x::^c	Control-X가 Control-C를 생산합니다. 또 Control-Alt-X는 Control-Alt-C, 등등을 생산합니다.
RWin::Return	오른쪽 Windows 키를 불능으로 만듭니다. 단순히 return을 할당했습니다.

이 예제들을 시험해 볼 수 있습니다. 새 텍스트 파일로 "Remap.ahk"와 같이 복사한 다음, 그 파일을 기동시킵니다.

완전한 키목록과 마우스 버튼 이름 목록은 키 리스트를 참조하십시오.

논평

지시어 #IfWinActive/Exist를 사용하면 선택된 리맵핑을 지정한 창에 대해서만 켤 수 있습니다. 예를 들어:

#IfWinActive ahk_class Notepad
a::b  ;  'a'키가 'b' 키를 전송하도록 만들지만, 오직 노트 패드 안에서만 일어납니다.
#IfWinActive  ; 잇다르는 리맵핑과 핫키가 모든 창에 효력을 미칩니다.

키나 마우스를 리맵핑 하는 일은 다음과 같은 관점에서 "완벽합니다":

Control나 Shift 같은 수식 키를 누른 채로 원래의 키를 타자하면 그 수식키가 목표 키에 효과를 발휘합니다. 예를 들어, b::a는 Control-B를 누르면 Control-A를 생산합니다 .
Capslock은 일반적으로 리맵된 키에 정상 키와 마찬가지 방식으로 영향을 미칩니다.
원래 키를 계속 누르고 있는 동안 목표 키나 목표 버튼이 눌려집니다. 그렇지만, 어떤 게임은 리맵핑을 지원하지 않습니다; 그런 경우, 키보드와 마우스는 리맵되지 않은 것처럼 행위합니다.
리맵된 키는 눌려 있는 동안 자동으로 반복합니다 (마우스 버튼이 되도록 리맵된 키는 제외).

리맵된 키를 정상 키처럼 촉발시킬 수 있지만, 기본값으로 마우스 핫키나 갈고리 핫키는 촉발시킬 수 없습니다. (ListHotkeys를 사용하면 어느 핫키가 "갈고리")인지 알 수 있습니다. 예를 들어, 리맵핑 a::b가 작동 중일 때, Ctrl-Alt-A를 누르면 ^!b 핫키가 촉발됩니다. 오직 ^!b가 갈고리 핫키가 아닐 경우에만 그렇습니다. ^!b가 갈고리 핫키일 경우, ^!a를 핫키로 정의하면 Ctrl-Alt-A 는 Ctrl-Alt-B와 같은 행위를 수행합니다. 예를 들어:

a::b
^!a::
^!b::
ToolTip You pressed %A_ThisHotkey%.
return

대안적으로, v1.1.06 이후에서, #InputLevel를 사용하면 기본 행위를 오버라이드할 수 있습니다. 예를 들어:

#InputLevel 1
a::b

#InputLevel 0
^!b::
ToolTip You pressed %A_ThisHotkey%.
return

SendMode가 자동 실행 섹션에 사용중이면 (스크립트 상단 부분), 모든 리맵핑에 영향을 미칩니다. 그렇지만, 리맵핑은 Send {Blind}를 사용하고 SendPlay mode는 완전하게 {Blind}를 지원하지는 못하기 때문에, 어떤 리맵핑은 SendPlay 모드에서 제대로 작동하지 않을 수도 있습니다 (특, Control, Shift, Alt, 그리고 Win). 이를 돌아가려면, 리맵핑을 사용할 때 SendPlay를 자동-실행 섹션에 사용하지 마십시오; 그 다음부터 다른 곳에는 명령어 SendPlay vs. Send를 사용하시면 됩니다. 대안적으로, 리맵핑을 핫키로 번역할 수 있습니다. (아래에 기술하는 바와 같이) 명시적으로 SendEvent vs. Send를 호출합니다.

스크립트가 기동할 때, 각 리맵핑은 한 쌍의 핫키로 번역됩니다. 예를 들어, a::b가 들어있는 스크립트는 실제로는 대신에 다음의 두 핫키가 들어 있습니다:

*a::
SetKeyDelay -1   ; 목표 키가 마우스 버튼이면, 대신에 SetMouseDelay가 사용됩니다.
Send {Blind}{b DownTemp}  ; DownTemp는 Down과 같습니다. 단, 다른 Send 명령어는 "b"가 전송되는 동안 눌려 있을 것이라고 가정하지 않습니다.
return

*a up::
SetKeyDelay -1  ; 왜 눌림-지속시간이 이 SetKeyDelays 중 하나로 지정되지 않는지 그 이유는 아래를 보십시오.
Send {Blind}{b Up}
return

그렇지만, 위의 핫키는 다음과 같은 상황에서 달라집니다:

소스 키가 LCtrl이고 목표 키가 Alt 키일 때, 줄 Send {Blind}{LAlt DownTemp}는 Send {Blind}{LCtrl Up}{LAlt DownTemp}로 교체됩니다. 소스가 RCtrl일 경우도 마찬가지입니다. 단, {RCtrl up}이 사용되는 경우는 예외입니다.
키보드 키가 마우스 버튼으로 리맵중일 때 (예, RCtrl::RButton), 위의 핫키는 SetKeyDelay 대신에 SetMouseDelay를 사용합니다. 게다가, 위의 첫 핫키는 다음으로 교체됩니다. 이 때문에 키보드의 자동-반복 특징은 반복적인 마우스 클릭을 만들어 내지 못합니다:
```
*RCtrl::
SetMouseDelay -1
if not GetKeyState("RButton")  ; 즉, 오른쪽 버튼이 아직 눌리지 않았습다.
    Send {Blind}{RButton DownTemp}
return
```

SetKeyDelay의 두 번째 매개변수는 (눌림 지속 시간) 위의 핫키에서 생략됩니다. {b down}과 {b up}과 같이 누름만 있거나 뗌만 있는 이벤트에는 눌림 지속 시간이 적용되지 않기 때문입니다. 그렇지만, Shift/Ctrl/Alt/Win 키의 상태 변화에는 적용됩니다. 예를 들어 a::B나 a::^b와 같은 리맵핑에 영향을 미칩니다. 결론적으로, 스크립트가 자동-실행 섹션를 통하여 효과를 준 모든 누름 지속 시간은 모든 리맵핑에 적용됩니다.

한 쌍의 키를 직접적으로 하나의 키에 리맵할 수는 없지만 (예, a & c::b와 같이 작성하는 것은 무효입니다), 명시적으로 저 위에 있는 예제로부터 위 아래 핫키를 추가하면 이 효과를 얻을 수 있습니다: 그냥 *a::를 with a & c::로, 그리고 *a up::를 a & c up::로 교체하기만 하면 됩니다.

리맵핑은 위에 기술한 바와 같이 핫키로 번역되기 때문에, Suspend 명령어에 영향을 받습니다. 비슷하게, Hotkey 명령어는 리맵핑을 변경하거나 끌 수 있습니다. 예를 들어, 다음 두 명령어는 리맵핑 a::b를 끕니다.

Hotkey, *a, off
Hotkey, *a up, off

Alt-tab 문제: 키나 마우스 버튼을 Alt 키가 되도록 리맵했다면, 그 키는 아마도 제대로 alt-tab을 작동시키지 못할 것입니다. 가능한 해결책은 핫키 *Tab::Send {Blind}{Tab}를 추가하는 것입니다 -- 그러나 진짜 핫키가 알트 탭을 수행할 때 간섭을 일으킬 가능성이 높다는 점을 명심하십시오. 그러므로, 오직 리맵된 alt-tab 핫키만 단독으로 사용할 경우에만 사용을 고려해야 합니다.

키 리스트 페이지에 나열된 키와 마우스 버튼 말고도, 소스 키로는 가상 키 (VKnn) 또는 스캔 코드 (SCnnn)도 가능합니다. 이는 특수 키 페이지에 기술되어 있습니다. 목표 키도 마찬가지입니다. 단, 목표 키는 선택적으로 가상 키 다음에 스캔 코드를 지정할 수도 있습니다. 예를 들어, sc01e::vk42sc030는 대부분의 키보드 배치도에서 a::b과 동등합니다.

키를 리맵하기 보다 끄려면, 그냥 반환되는 핫키로 만들면 됩니다. 예를 들어, F1::return는 F1 키를 불능으로 만듭니다.

다음 키는 내장 리맵핑 메쏘드가 지원하지 않습니다:

마우스 휠 (WheelUp/Down/Left/Right).
Pause 그리고 Break를 목표 키로 불가 (명령어 이름에 일치하기 때문에 불가).
활괄호 {}를 목표 키로 불가. 대신에 VK/SC 방법을 사용하십시오; 예, x::+sc01A 그리고 y::+sc01B.
퍼센트 사인(%)을 목표 키로 불가. 대신에 VK/SC 방법을 사용하십시오.
"Return"을 목표 키로 사용 불가. 대신에 "Enter"를 사용하십시오.

키보드로 마우스 커서 이동하기

키보드를 사용하여 마우스 커서를 이동할 수 있습니다. 예제는 완벽하게 기능을 갖춘 Keyboard-To-Mouse 스크립트를 보십시오. 스크립트는 부드러운 마우스 이동과, 가속, 기타 특징을 제공하기 때문에, 키보드로 마우스 작업을 많이 할 계획이 있다면 권장하는 접근법입니다. 대조적으로, 다음 예제는 좀 간단합니다:

*#up::MouseMove, 0, -10, 0, R  ; Win+UpArrow hotkey => 커서를 위로 이동시킵니다
*#Down::MouseMove, 0, 10, 0, R  ; Win+DownArrow => 커서를 아래로 이동시킵니다
*#Left::MouseMove, -10, 0, 0, R  ; Win+LeftArrow => 커서를 위로 왼쪽으로시킵니다
*#Right::MouseMove, 10, 0, 0, R  ; Win+RightArrow => 커서를 위로 오른쪽으로시킵니다

*<#RCtrl::  ; LeftWin + RightControl => Left-click (Control/Shift을 누른 채로 Control-Click 또는 Shift-Click).
SendEvent {Blind}{LButton down}
KeyWait RCtrl  ; 키보드 자동-반복이 마우스 클릭을 반복시키지 못하도록 막습니다.
SendEvent {Blind}{LButton up}
return

*<#AppsKey::  ; LeftWin + AppsKey => Right-click
SendEvent {Blind}{RButton down}
KeyWait AppsKey  ; 키보드 자동-반복이 마우스 클릭을 반복시키지 못하도록 막습니다.
SendEvent {Blind}{RButton up}
return

레지스트리의 "스캔코드 맵" 리맵핑하기

장점:

레지스트리 리맵핑은 일반적으로 오토핫키의 리맵핑보다 더 순수하고 효과적입니다. 예를 들어 더 넓은 범위의 게임에 작동하고, alt-tab 문제도 없는 것으로 알려져 있으며, 그리고 AutoHotkey의 갈고리 핫키를 촉발시킬 수 있습니다 (반면 오토핫키의 리맵핑은 우회책이 필요합니다).
레지스트리 엔트리를 손수 만들기로 결정했더라도 (아래에 설명), 키보드를 리맵하는데 절대 외부 소프트웨어가 필요하지 않습니다.KeyTweak을 사용하여 레지스트리 엔트리를 만든다고 할지라도, KeyTweak이 항상 실행중이어야 할 필요는 없습니다 (AutoHotkey와 다릅니다).

단점:

레지스트리 리맵핑은 상대적으로 영구적입니다: 변경을 언두하거나 새 변경이 효과가 있으려면 재부팅해야 할 필요가 있습니다.
그의 효과는 전역적입니다: 특정한 사용자나 어플리케이션 또는 로케일에 맞게 리맵핑을 만드는 것은 불가능합니다.
Shift, Control, Alt, 또는 AltGr 으로 수식된 키눌림은 전송하지 않습니다. 예를 들어, 소문자를 대문자로 리맵할 수 없습니다.
키보드만 지원합니다 (AutoHotkey는 마우스 리맵핑과 제한적이나마 조이스틱 리맵핑을 지원합니다).

레지스트리에 변경을 적용하는 법: 레지스트리를 통하여 키를 리맵하는 데 적어도 두 가지 방법이 있습니다:

KeyTweak (무료웨어)와 같은 프로그램을 사용하여 시각적으로 키를 리맵합니다. 대신 레지스트리를 변경해 줍니다.
수동으로 키를 리맵합니다. .reg 파일 (평범한 텍스트)를 만들어 레지스트리 안으로 적재하면 됩니다. 이 방법은 www.autohotkey.com/forum/post-56216.html#56216에 예시되어 있습니다.

키와 버튼 리맵하기

들어가는 말

키보드와 마우스 리맵하기

논평

키보드로 마우스 커서 이동하기

레지스트리의 "스캔코드 맵" 리맵핑하기

관련 주제