Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

German Umlaute Convenience Script


  • Please log in to reply
18 replies to this topic
ck
  • Members
  • 8 posts
  • Last active: Aug 29 2004 04:03 PM
  • Joined: 25 Jul 2004
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:
===

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;                                                   ;;
;; 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


Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Very professionally researched, written, and commented. Thanks for sharing that.

Beastmaster
  • Members
  • 191 posts
  • Last active: Apr 23 2007 02:58 PM
  • Joined: 15 Apr 2004
Wow, kann mich dem nur anschließen ! :D

ck
  • Members
  • 8 posts
  • Last active: Aug 29 2004 04:03 PM
  • Joined: 25 Jul 2004
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

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

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.

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

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... ... 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+ 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!

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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.

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.

ck
  • Members
  • 8 posts
  • Last active: Aug 29 2004 04:03 PM
  • Joined: 25 Jul 2004

Wow, talk about trying everything.


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

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.

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

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

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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.

ck
  • Members
  • 8 posts
  • Last active: Aug 29 2004 04:03 PM
  • Joined: 25 Jul 2004

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

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

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

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

it probably ©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.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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): €

delta
  • Members
  • 44 posts
  • Last active: Sep 14 2005 08:46 AM
  • Joined: 16 Feb 2005
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?

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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.

delta
  • Members
  • 44 posts
  • Last active: Sep 14 2005 08:46 AM
  • Joined: 16 Feb 2005
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
#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
#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
#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.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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.

delta
  • Members
  • 44 posts
  • Last active: Sep 14 2005 08:46 AM
  • Joined: 16 Feb 2005

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:

rsvelko
  • Members
  • 2 posts
  • Last active: Nov 06 2009 03:45 AM
  • Joined: 06 Nov 2009
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!