AutoHotkey Community

It is currently May 26th, 2012, 7:21 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: July 25th, 2004, 9:32 pm 
Offline

Joined: July 25th, 2004, 8:00 pm
Posts: 8
Background:
========
Some countries, like Germany, use Umlaut keys, e.g. ü etc. with special adopted keyboard layouts.
However, IMHO there is no shadow of a doubt that US English keyboard layouts have the highest usability and efficiency for typing code and for reaching the most common shortcuts. Just look at the loops you have to jump through to reproduce [] {} /\ on German keyboards. It's ridiculous.

Well, you could use an English US layout and just type "ue" instead of ü or ss instead of ß etc. and try to get along. This is fine for most correspondence and documents, but I deem it inappropriate in the "business world".

So what to do, instead? You could install both keyboard layouts on one physical keyboard. There is a default shortcut (ALT+SHIFT) to quickly swap between those 2 layouts. Unfortunately, this will result in many typing mistakes because the layouts differ quite a lot. Once you get used where to find your [z],[:],[(],[)],... and whatnot, you are well quite used to it.

Alternatively, there is the option of installing an US English International keyboard layout. It works somewhat but very painfully so. Here you have a special UMLAUTKEY which is ["], and cannot be changed. So you'd type ["] and then [u] to get ü. However for the ß you have to press [Ctrl]+[Alt]+s. Why they didn't just use ["] + s is beyond me. Additionally, ["] is a dumb frequently needed triggerkey because it requires two keypresses ([SHIFT]+[']) even on US English keyboard layouts.
To cut it short, there is no good solution for this misery out there.

Until now. I decided to write something on my own.

Idea:
===
When you write an ü by hand on paper, you first write an u and then add the two little dots. This is why I think it's much more intuitive to press the UMLAUTKEY after hitting u,a,o,s. This UMLAUTKEY should be easily reachable and not require another [SHIFT] operation. Of course the UMLAUTKEY should be the same for all Umlaute. No different handling for ß or ü.

In Germany you need the following 7 "Umlaute"

a -> ä
A -> Ä
u -> ü
U -> Ü
o -> ö
O -> Ö
s -> ß

I defined [1] as the Umlautkey and a delay of one second. That is you have to press [1] within DELAY seconds (=1, default) to get your Umlaut. Otherwise you will get e.g. u1, ...

I took great care to write the script in such a way that it won't influence typing speed in any way. The only problems are words which end with a potential umlaut and a "1" . But this is rather rare and can be redefined easily. Ideally, I would want the UMLAUTKEY to be [ALT] or something, which is why I requested InputAnyKey in the "WishList" forum.

The script can be easily adopted to any language which uses Umlauts, be it French or whatever. Feel free to do so.

Big thanks again to Chris for putting together this hell of a tool. I'm glad I didn't have to write my own keyboard proxy filter software and could just use the powerful scripting language of AutoHotKey. This has made my life in the business world much easier. :D

Without further ado, here the script:

Script:
===

Code:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;                                                   ;;
;; German Umlaute Convenience Script                 ;;
;; for Superior US English Keyboard Layouts          ;;
;;                                                   ;;
;; version 0.3 - 07/18/04                            ;;
;; ck <use www.autohotkey.com forum to contact me>   ;;
;;                                                   ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;; Usage Instructions:
;; -------------------
;; Load Script into AutoHotKey (only verified to work with 1.0.15 and Windows XP)
;; a) Press any of the TRIGGERKEYS [u,U,a,A,o,O,s] in any application of your choice
;; b) Within DELAY seconds, press the UMLAUTKEY to morph it into [ü,Ü,ä,Ä,ö,Ö,ß]

; after pressing a TRIGGERKEY, you have to wait DELAY seconds to press the UMLAUTKEY
; and make it appear normally (without triggering any Umlaut morphing)
DELAY = 1.0 ; default = 1
UMLAUTKEY = 1 ; default = 1

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; You shouldn't have to edit below this line
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;#NoTrayIcon

; remember the latest activated Umlaut
UMLAUT = x

$u::
; Above: Use the $ to force the hook to be used, which prevents an
; infinite loop since this subroutine itself sends Numpad0, which
; would otherwise result in a recursive call to itself.
; mirror self
Send, u
; initialize current Umlaut
UMLAUT = ü
Goto, WaitForUK

$+u::
Send, U
UMLAUT = Ü
Goto, WaitForUK

$o::
Send, o
UMLAUT = ö
Goto, WaitForUK

$+o::
Send, O
UMLAUT = Ö
Goto, WaitForUK

$a::
Send, a
UMLAUT = ä
Goto, WaitForUK

$+a::
Send, A
UMLAUT = Ä
Goto, WaitForUK

$s::
Send, s
UMLAUT = ß


WaitForUK:
; disable this and every other TRIGGERKEY to speed things up
Hotkey, $u, Off
Hotkey, $+u, Off
Hotkey, $o, Off
Hotkey, $+o, Off
Hotkey, $a, Off
Hotkey, $+a, Off
Hotkey, $s, Off

; Most editors can handle the fastest speed (-1)
SetKeyDelay, 0 ; 0 for reliability

; repeat until EITHER the UMLAUTKEY was hit or any other key breaking the sequence (non TRIGGERKEY)
Loop
{
   ; watch next input string (only wait for exactly one char, mirror input, ignore backspace and wait DELAY seconds)
   Input, UserInput, V L1 B T%DELAY%
   if UserInput = %UMLAUTKEY%
   {
       Send, {backspace 2}%UMLAUT%
       break
        }
        else if UserInput = u
      UMLAUT = ü
   else if UserInput = o
      UMLAUT = ö
   else if UserInput = +o
      UMLAUT = Ö
   else if UserInput = a
      UMLAUT = ä
   else if UserInput = A
      UMLAUT = Ä
   else if UserInput = s
      UMLAUT = ß
   else
      break
}

; re-enable all initial Umlaut TRIGGERKEYS
Hotkey, $u, On
Hotkey, $+u, On
Hotkey, $o, On
Hotkey, $+o, On
Hotkey, $a, On
Hotkey, $+a, On
Hotkey, $s, On

; finish this hotkey handling routine   
return


Last edited by ck on July 27th, 2004, 11:22 pm, edited 1 time in total.

Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 25th, 2004, 10:30 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Very professionally researched, written, and commented. Thanks for sharing that.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 26th, 2004, 12:41 am 
Offline

Joined: April 15th, 2004, 5:33 pm
Posts: 181
Wow, kann mich dem nur anschließen ! :D


Report this post
Top
 Profile  
Reply with quote  
 Post subject: "Send, " Bug? + fix
PostPosted: August 9th, 2004, 10:28 pm 
Offline

Joined: July 25th, 2004, 8:00 pm
Posts: 8
I have to do a short follow-up regarding my own little Umlaute script.
As some might have guessed I have used both my little scripts a LOT recently.

I found a single very annoying bug in both. :( But... read on ;)
The bug in my KDE Style Grab Move Window script only occurs with Autohotkey v1.0.15 but not on v1.0.16: When you locked your computer with the script running on v1.0.15 and logged on again you e.g. couldn't switch tasks leveraging the taskbar until after you moved at least one window with given script.
Well, problem solved with upgrading AutoHotkey. Maybe it is due to

Quote:
Fixed the ALT key so that if it is itself a hotkey that fires on key-down, keys sent by the Send command will not be modified by the ALT key. [thanks Wade]


I didn't bother looking further into it.

However, my GermanUmlaute.ahk bug was much uglier. Usually it worked beautifully. But in specific applications a single key sequence would never trigger the Umlaut but e.g. always open a Window which usually only triggered by pressing Ctrl-H. I nailed it down to

Code:
Send, ä


in this one sample specific application. I defined a hotkey for Control+h but it never got fired. Each and every other Umlaut was fine (in this app). Some other applications had other strange problems. I got so used to my script that I got infuriated when it didn't work everywhere. :evil:

I looked into Autohotkey how to do the same thing, but a little differently.

Code:
Send, {vkDEsc028}


worked great (bugfree). BUT it only worked when I had the German keyboard layout running. D'oh, next!

I fiddled around with the

Code:
Send, {Asc nnnn}


command. For the life of me I never figured out what kind of mapping applied when. I wrote a loop to get a Unicode mapping for every value from 256 to 65535. But the map looked very different in Winword and in Notepad. Given up on that.

I installed tons of additional codepages. Anything with "German" in it. :) None of this had any effect.

After some more exploring, I noticed that the script worked great when I had the "US - English - International" keyboard layout running. No bugs at all. For some reason the Umlauts are only properly send when the current keyboard layout knows about them. Bingo!

Unfortunately, the "US - English - International" keyboard layout really is a pain to use. Pressing {"} followed by an {a} will generate {ä}. Pressing {"} once will do nothing, you have to follow it up with {Space} to actually get a single {"}.... After all, I don't want to use its' international features, I just want it to know my Umlaut keys to handle them properly.

So then I looked into ways to either modify this keyboard layout to disable most of the internationalization functionality but still keeping the Umlauts in "memory", or well to create a complete new keyboard layout from scratch.

Well, you can. :D
I found a great, powerful, free tool from Microsoft to do just that. For a second, I even pondered if I should use it to to create a new layout and drop the Umlaute Autohotkey script altogether. But I decided not to, since I prefer the flexibility of the script (for now).

Follow these instructions to create your basic US keyboard layout with hidden German Umlauts:

Get this tool: http://www.microsoft.com/typography/lin ... x?NID=2900

a) Run Keyboard Layout Creator (v1.3.4073.0+)
b) File -> Load Existing Keyboard...
select: [US]
c) Shift states:
[x] Alt+Ctrl
Click any white keys (e.g. q-u) in order and provide the following Unicode Hex values
U+00e4 ä
U+00c4 Ä
U+00fc ü
U+00dc Ü
U+00f6 ö
U+00d6 Ö
U+00df ß
d) Project -> Properties...
Description: [US layout with hidden German Umlauts (Custom)]
Company: [Private]
e) Project -> Build DLL and Setup Package
f) run .msi file

Replace current keyboard layout with "English/US layout with hidden German Umlauts (Custom)"

Alt+Ctrl+<previously defined keys> will now trigger all German Umlauts.
But that's not really what we care about.

GermanUmlaute.ahk will now finally run bugfree in all applications. :)
Enjoy!


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 9th, 2004, 11:20 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Wow, talk about trying everything. I too am learning that the interactions between keyboard layouts, modifier keys, hotkeys, and the {Asc nnnn} method of producing international characters -- which AHK also uses internally, possibly explaining some of your issues -- can be devilishly tricky.

Quote:
When you locked your computer with the script running on v1.0.15 and logged on again...

FYI, that's probably due to the Windows key getting stuck down when you press Win-L to lock the computer. This and a similar Ctrl-Alt-Del issue were both fixed in one of the interim releases of v1.0.16.

Thanks for posting your findings.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 9th, 2004, 11:49 pm 
Offline

Joined: July 25th, 2004, 8:00 pm
Posts: 8
Chris wrote:
Wow, talk about trying everything.


It shows how much I cared to fix this annoying little bug. :)

Quote:
I too am learning that the interactions between keyboard layouts, modifier keys, hotkeys, and the {Asc nnnn} method of producing international characters -- which AHK also uses internally, possibly explaining some of your issues -- can be devilishly tricky.


Yep, something is seriously wrong there. It's obviously hell to debug this mess.

Quote:
FYI, that's probably due to the Windows key getting stuck down when you press Win-L to lock the computer. This and a similar Ctrl-Alt-Del issue were both fixed in one of the interim releases of v1.0.16.


Oops I missed

Quote:
In addition, activating the Ctrl-Alt-Del security screen no longer causes it to think that CTRL and ALT are stuck down. [thanks frk and beardboy]


when glimpsing over the Changelog. Thanks for fixing that! :D


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 10th, 2004, 12:58 am 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
You didn't really miss it since it was only announced in the ChangeLog today (previously it was only mentioned in the Announcements section, which is easily missed). Specifically:

Fixed Ctrl-Alt-Del security screen and Win+L (lock the computer) to prevent sticking keys. Both were partly broken by v1.0.16. [thanks frk]

In case anyone doesn't know, there's a small link on the forum's main page called "View posts since last visit". I think it requires that you be logged in (for cookies to be set), but it's pretty handy. And by the way, registering a username is pretty painless. It's instantanous since there is no validation e-mail sent to you.


Report this post
Top
 Profile  
Reply with quote  
PostPosted: August 10th, 2004, 11:37 am 
Offline

Joined: July 25th, 2004, 8:00 pm
Posts: 8
Chris wrote:
You didn't really miss it since it was only announced in the ChangeLog today


Ah okay. Thanks for fixing and adding more and more features in/to this wonderful tool. :)

I have yet again to follow up on my GermanUmlaute.ahk. I noticed strange bugs while typing in Winword today.

On my custom keyboard layout I had bound Ctrl+Alt+E to ü. In most applications the call of

Code:
Send, ü


did actually send an ü. However, in Winword Ctrl+Alt+E is internally bound to €. This is not defined in my custom keyboard layout! Anyway, so in Winword

Code:
Send, ü


will actually send an €.

Strange, eh?
My guess is that above Send command doesn't actually send the character. Instead, it triggers a virtual key pressing of whatever key combination is responsible in the current keyboard layout to produce this character. However in this case Winwords' internal hotkey fires and prints an €.

Solution 1:
------------

Bind the hidden Umlaut keys in your custom keyboard layout to hotkeys which are
a) hopefully not used in any application whatsoever
b) very unlikely to be fired by yourself

I found these keys

{Decimal Separator (numeric keypad)} (I don't even have this one my notebook)
Control+Alt+{q}
Control+Alt+{w}
Control+Alt+{a}
Control+Alt+{h}
Control+Alt+{j}
Control+Alt+{k}

map well to Umlaut keys on the keyboard layout without interfering with rule a) or b). (so far)



Solution 2:
------------

If AutoHotkey supported Hotkeys composed of 3 keys such as

Code:
Control & LAlt & e::
MsgBox, AutHotKey is even more powerful now
return


it probably (c)would overwrite Winwords tripple key combos.

Hopefully, this is the last amendment I have to do for this script. :)
Well, back to typing Umlaut riddled stuff in Winword.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 10th, 2004, 12:30 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Interesting. In case it's useful, I'll briefly describe what AHK does to send keys. By the way, there are still many gaps in my knowledge of this area, so enlightenment would be welcome.

When you provide a raw ASCII character to the Send command, the Windows function VkKeyScan() is called to see if that character has a virtual key. Since there are only 256 virtual keys (and some of them are reserved/unused), it is my understanding that any given keyboard layout will lack virtual keys for some characters.

Anyway, if no virtual key is found but that character is one of the "extended ASCII" characters (those whose ASCII value is between 128 and 255), AHK will use the Send {Asc nnnnn} method to produce the character. Specifically, it relies on the fact that most/all keyboard layouts produce the same ANSI characters when the Alt+Numpad sequence is typed, with the first digit being a leading zero and the other digits composing a number between 128 and 255.

Here is a complete list of the "extended ASCII" characters (not sure if they will display correctly on all browsers): €


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 8th, 2005, 9:14 pm 
Offline

Joined: February 16th, 2005, 5:32 pm
Posts: 44
Hm, I found out something strange, maybe a bug. Using MS Layout Creator I build a "US layout with hidden Umlauts"... actually I build lots of it. :lol: The problem is this: I tried to hide the umlauts on Shift-AltGr-Q and so on since I've never come across any application that uses that quirky hotkeys.

But autohotkey seems to loose the Shift somewhere. When there is no char assigned to AltGr-Q I simply get nothing when autohotkey should send a letter which is hidden on Shift-AltGr-Q. When there is, say, ä assigned to AltGr-Q and Ä to Shift-AltGr-Q then "Send, Ä" will produce an ä.

I use Win XP, SP2. Anyone can confirm this or is it just me?


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 9th, 2005, 5:31 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
If you ever observe this behavior on any standard keyboard layout, please say which layout and describe what steps can be used to reproduce the problem on other systems.

Thanks.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 12th, 2005, 4:01 pm 
Offline

Joined: February 16th, 2005, 5:32 pm
Posts: 44
Not sure what you mean by standard keyboard layouts. Well, let's give it a try:

My Windows XP comes with several keyboard layouts, one is called "Norwegisch mit Samish", which should translate to "Norwegian with Samish", I hope. :wink:

Activate this keyboard layout and with Notepad (e.g.) verify that "AltGr + apostrophe" (on a keyboard with "physical" US layout) or "AltGr + ä" (on a keyboard with German layout) produces a lower case a-umlaut (ä). Verify further that "AltGr + Shift + apostrophe" or "AltGr + Shift + ä" produces an upper case a-umlaut (Ä).

Suppose we want to use a script to remap the upper case a-umlaut (Ä) to "Win + Q", i.e. we use a script like
Code:
#UseHook on

#Q::
  Send, Ä
return

The Problem now is: Run this script with the "Norwegian with Samish" layout and Win+Q will falsely produce a lower case a-umlaut (ä)! However a work around is to use "Send, +ä", but this is no longer keyboard layout independent.



/edit
Ok, I can tell you even more: it's a letter specific problem. You can test this similarly with the layout "Samish-extended Finland-Sweden". Here AltGr+\ will produce an apostrophe (physical US layout on keyboard assumed) and AltGr+Shift+\ will produce an asterisk (*). But with this keyboard layout the script
Code:
#UseHook on

#Q::
  Send, *
return

will not produce an apostrophe (AltGr+/) but an asterisk (AltGr+Shift+/) when Win+Q is pressed.

On the other hand: A script like
Code:
#UseHook on

#Q::
  Send, A
return

will (with standard layouts) always produce "A" when Win+Q is pressed, no need to send an extra shift here. So we have some sort of asymmetry here between "normal" letters and umlauts.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 13th, 2005, 3:10 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
There was an uppercase vs. lowercase AltGr issue fixed in v1.0.36.06. If this didn't resolve it, please let me know and I'll research it further.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: July 18th, 2005, 11:31 am 
Offline

Joined: February 16th, 2005, 5:32 pm
Posts: 44
Chris wrote:
There was an uppercase vs. lowercase AltGr issue fixed in v1.0.36.06. If this didn't resolve it, please let me know and I'll research it further.

Ah, ok, it works now as it should. I thought I had the latest version since it was only about 2 weeks old. :roll: I promise to get updates before next time reporting bugs. :oops: :wink:


Report this post
Top
 Profile  
Reply with quote  
 Post subject: so?
PostPosted: November 6th, 2009, 4:45 am 
Offline

Joined: November 6th, 2009, 4:43 am
Posts: 2
so guys since I do not want to read the whole thread - what exactly should I do to make things work? What is the last version of this masterpiece?

Thanks!


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: Scratch, Xx7 and 18 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group