한계: 아래에 기술하는 오토핫키의 리맵핑 특징은 일반적으로 윈도우즈 레지스트리를 통하여 리맵핑 하는 것에 비해 순수하지 못하며 효과도 그에 못 미칩니다. 각 접근법의 장점과 단점에 관한 것은 레지스트리 리맵핑을 참조하십시오.
내장 리맵핑 특징의 구문은 OriginKey::DestinationKey입니다. 예를 들어, 다음 줄만 들어있는 스크립트는 A를 마치 B 키처럼 행동하게 만듭니다:
a::b
위의 예제는 B 자체를 변경하지 않습니다. B 키는 계속해서 "b" 키눌림을 전송합니다. 다음 예제와 같이 다른 것에 리맵하지만 않는다면 말입니다:
a::b b::a
위의 예제는 소문자를 사용합니다. 대부분의 목적에 소문자를 권합니다. 왜냐하면 상응하는 대문자도 리맵되기 때문입니다 (즉, CapsLock이 "켜져" 있거나 Shift가 눌리면 대문자가 전송됩니다). 대조적으로, 대문자를 오른쪽에 지정하면 대문자를 강제합니다. 예를 들어, 다음 줄은 (CapsLock이 꺼져 있는 한) "a"나 "A"를 누를 때 대문자 B를 생산합니다:
a::B
However, a remapping opposite to the one above would not work as one might expect, as a remapping never "releases" the modifier keys which are used to trigger it. For example, A::b is typically equivalent to A::B and ^a::b is equivalent to ^a::^b. This is because each remapping internally uses {Blind} to allow the key or key combination to be combined with other modifiers.
키보드 대신에 마우스를 리맵하려면 같은 접근법을 사용합니다. 예를 들어:
| 예제 | 설명 |
|---|---|
MButton::Shift |
가운데 버튼을 마치 Shift 키처럼 행동하게 만듭니다. |
XButton1::LButton |
네 번째 마우스 버튼을 왼쪽 버튼처럼 행위하게 만듭니다. |
RAlt::RButton |
오른쪽 Alt를 오른쪽 마우스 버튼 처럼 행위하게 만듭니다. |
| 예제 | 설명 |
|---|---|
CapsLock::Ctrl |
CapsLock을 Ctrl가 되도록 만듭니다. CapsLock을 그대로 켜고 끌 수 있도록 하기 위해, 먼저 +CapsLock::Capslock 리맵핑을 추가합니다. 이렇게 하면 Shift를 누른 채 CapsLock을 누를 때 CapsLock을 토글합니다. 두 리맵핑 모두 추가 수식키가 눌려 있는 것을 허용하기 때문에, 더 구체적으로 +CapsLock::CapsLock 리맵핑을 먼저 배치해야 CapsLock::Ctrl이 작동할 수 있습니다. |
XButton2::^LButton |
Makes the fifth mouse button (XButton2) produce a control-click. |
RAlt::AppsKey |
오른쪽 Alt 키는Menu가 됩니다 (문맥 메뉴를 여는 키입니다). |
RCtrl::RWin |
오른쪽 Ctrl를 오른쪽 Win가 되도록 만듭니다. |
Ctrl::Alt |
Ctrl 키를 Alt 키처럼 행위하도록 만듭니다. 그렇지만, alt-tab 문제를 참조하십시오. |
^x::^c |
Ctrl+X가 Ctrl+C를 생산합니다. 또 Ctrl+Alt+X는 Ctrl+Alt+C, 등등을 생산합니다. |
RWin::Return |
오른쪽 Win를 불능으로 만듭니다. 단순히 return을 할당했습니다. |
이 예제들을 시험해 볼 수 있습니다. 새 텍스트 파일로 "Remap.ahk"와 같이 복사한 다음, 그 파일을 기동시킵니다.
완전한 키목록과 마우스 버튼 이름 목록은 키 리스트를 참조하십시오.
지시어 #IfWinActive/Exist를 사용하면 선택된 리맵핑을 지정한 창에 대해서만 켤 수 있습니다. 예를 들어:
#IfWinActive ahk_class Notepad a::b ; 'a'키가 'b' 키를 전송하도록 만들지만, 오직 노트 패드 안에서만 일어납니다. #IfWinActive ; 잇다르는 리맵핑과 핫키가 모든 창에 효력을 미칩니다.
키나 마우스를 리맵핑 하는 일은 다음과 같은 관점에서 "완벽합니다":
b::a는 Ctrl+B를 누르면 Ctrl+A를 생산합니다 .리맵된 키를 정상 키처럼 촉발시킬 수 있지만, 기본값으로 마우스 핫키나 갈고리 핫키는 촉발시킬 수 없습니다. (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 모드에서 제대로 작동하지 않을 수도 있습니다 (특, Ctrl, Shift, Alt, 그리고 Win). 이를 돌아가려면, 리맵핑을 사용할 때 SendPlay를 자동-실행 섹션에 사용하지 마십시오; 그 다음부터 다른 곳에는 명령어 SendPlay vs. Send를 사용하시면 됩니다. 대안적으로, 리맵핑을 핫키로 번역할 수 있습니다. (아래에 기술하는 바와 같이) 명시적으로 SendEvent vs. Send를 호출합니다.
스크립트가 기동할 때, 각 리맵핑은 한 쌍의 핫키로 번역됩니다. 예를 들어, a::b가 들어있는 스크립트는 실제로는 대신에 다음의 두 핫키가 들어 있습니다:
*a::
SetKeyDelay -1 ; 목표 키가 마우스 버튼이면, 대신에 SetMouseDelay가 사용됩니다.
Send {Blind}{b DownR} ; DownR는 Down과 같습니다. 단 다른 Send 명령어는 "b" 가 Send하는 동안 눌려 있을 것이라고 가정하지 않습니다.
return
*a up::
SetKeyDelay -1 ; 왜 눌림-지속시간이 이 SetKeyDelays 중 하나로 지정되지 않는지 그 이유는 아래를 보십시오.
Send {Blind}{b up}
return
그렇지만, 위의 핫키는 다음과 같은 상황에서 달라집니다:
Send {Blind}{LAlt DownR} is replaced by Send {Blind}{LCtrl up}{LAlt DownR}. The same is true if the source is the right Ctrl, except that {RCtrl up} is used.RCtrl::RButton), 위의 핫키는 SetKeyDelay 대신에 SetMouseDelay를 사용합니다. 게다가, 위의 첫 핫키는 다음으로 교체됩니다. 이 때문에 키보드의 자동-반복 특징은 반복적인 마우스 클릭을 만들어 내지 못합니다:
*RCtrl::
SetMouseDelay -1
if not GetKeyState("RButton") ; 즉, 오른쪽 버튼이 아직 눌리지 않았습다.
Send {Blind}{RButton DownR}
return
Prior to [v1.1.27], DownTemp was used instead of DownR.
SetKeyDelay의 두 번째 매개변수는 (눌림 지속 시간) 위의 핫키에서 생략됩니다. {b down}과 {b up}과 같이 누름만 있거나 뗌만 있는 이벤트에는 눌림 지속 시간이 적용되지 않기 때문입니다. However, it does apply to changes in the state of the modifier keys (Shift, Ctrl, Alt, and Win), which affects remappings such as a::B or a::^b. 결론적으로, 스크립트가 자동-실행 섹션를 통하여 효과를 준 모든 누름 지속 시간은 모든 리맵핑에 적용됩니다.
리맵핑은 위에 기술한 바와 같이 핫키로 번역되기 때문에, Suspend 명령어에 영향을 받습니다. 비슷하게, Hotkey 명령어는 리맵핑을 변경하거나 끌 수 있습니다. 예를 들어, 다음 두 명령어는 리맵핑 a::b를 끕니다.
Hotkey, *a, Off Hotkey, *a up, Off
Alt-tab 문제: 키나 마우스 버튼을 Alt가 되도록 리맵했다면, 그 키는 아마도 제대로 alt-tab을 작동시키지 못할 것입니다. A possible work-around is to add the hotkey *Tab::Send {Blind}{Tab} -- but be aware that it will likely interfere with using the real Alt to alt-tab. 그러므로, 오직 리맵된 alt-tab 핫키만 단독으로 사용할 경우에만 사용을 고려해야 합니다.
키 리스트 페이지에 나열된 키와 마우스 버튼 말고도, 소스 키로는 가상 키 (VKnn) 또는 스캔 코드 (SCnnn)도 가능합니다. 이는 특수 키 페이지에 기술되어 있습니다. 목표 키도 마찬가지입니다. 단, 목표 키는 선택적으로 가상 키 다음에 스캔 코드를 지정할 수도 있습니다. 예를 들어, sc01e::vk42sc030는 대부분의 키보드 배치도에서 a::b과 동등합니다.
키를 리맵하기 보다 끄려면, 그냥 반환되는 핫키로 만들면 됩니다. 예를 들어, F1::return는 F1를 불능으로 만듭니다.
다음 키는 내장 리맵핑 메쏘드가 지원하지 않습니다:
vk13 or the corresponding scan code can be used instead.x::+sc01A 그리고 y::+sc01B.키보드를 사용하여 마우스 커서를 이동할 수 있습니다. 예제는 완벽하게 기능을 갖춘 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
장점:
단점:
레지스트리에 변경을 적용하는 법: 레지스트리를 통하여 키를 리맵하는 데 적어도 두 가지 방법이 있습니다: