Jump to content

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

Accent circonflexe


  • Please log in to reply
24 replies to this topic
PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005

I believe "Suspend" would work around this problem because hotstrings are disabled during Suspend (if anyone finds out otherwise, please let me know).

I tried before I suggested it, and it didn't worked... Otherwise, I would have given that as a functionnal workaround. :-)

Tried your new binary, it is better, but still with some misses:
ôaâêîaâaâôoôoöööôîiï
All of them were typed with a dead key...
That's not important as you don't want to implement this solution, but it is a good proof of concept.
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

I tried [Suspend] before I suggested it, and it didn't worked

Are you sure you had only one hotstring script running? If you had more than one, you'd have to suspend them all. Also, the Input command is likely to cause the same issue.

I confirmed in debug mode that ToAsciiEx is not called while hotstrings are all suspended (but this requires that no hotstrings have Suspend as their first line). So in theory, Suspend should be a work-around.

Tried your new binary, it is better, but still with some misses.

Thanks for the feedback. I'll comment it in the code as research.

numEric
  • Members
  • 30 posts
  • Last active: Feb 24 2008 04:46 PM
  • Joined: 27 Aug 2004

I've made a longshot attempt to fix this by suppressing/blocking the up-events of dead keys to match that fact that their down-events are blocked.

If anyone has time, please test the following version, perhaps by using the numbered steps in my post above: http://www.autohotke... ... ressed.zip

The changes in this version don't make any difference; unlike PhiLho, I couldn't get even a single letter with diacritic in the Java app :?
This is the result we could expect as the test below, which sends the same key events at the same speed, had failed:
SendInput, {vkDDsc01A}{vk41sc010}

I believe "Suspend" would work around this problem because hotstrings are disabled during Suspend (if anyone finds out otherwise, please let me know).

I have checked that, and I confirm that the problem still occurs when the script is suspended (and of course, no other instance of AutoHotkey is running at the same time). Dead keys start working again only when the AutoHotkey process is terminated.

Here's another modified version:
http://www.autohotke... ... leep20.zip

This one solves the problem; unlike PhiLho again, it has never failed during my test :)

However, even if it solves it, it might be best not to use this fix [...]

I agree with that point, so I'd like to suggest an alternate method to get keyboard input for use with hotstrings:
couldn't AutoHotkey hook the message queue of the thread that owns the currently active window and monitor it for WM_CHAR messages?
This method has the advantage of not disrupting anything; it doesn't require calling ToAsciiEx() and thus avoids the resulting limitation that involve suppressing/injecting key events, etc..
I think this might be worth a try... :idea:

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

The changes in this version don't make any difference; unlike PhiLho, I couldn't get even a single letter with diacritic in the Java app,

Thanks for confirming it (I'd realized while changing it that it was a longshot).

...the problem still occurs when the script is suspended (and of course, no other instance of AutoHotkey is running at the same time). Dead keys start working again only when the AutoHotkey process is terminated.

That's baffling. I ran the program again in debug mode, which confirms that ToAsciiEx() is never called while hotstrings are suspended. I can think of only two explanations:
[*:1oso4yhy]Hotstrings aren't the culprit for the Java issue; instead, it's the mere presence of the keyboard hook (but the fact that Sleep 20 solves it seems to disprove this).
[*:1oso4yhy]Java somehow remembers that hotstrings were disrupting it and stays traumatized unless you restart it after suspending your hotstrings.

couldn't AutoHotkey hook the message queue of the thread that owns the currently active window and monitor it for WM_CHAR messages?
This method has the advantage of not disrupting anything; it doesn't require calling ToAsciiEx() and thus avoids the resulting limitation that involve suppressing/injecting key events, etc..

Possibly, but even if it worked completely for both Hotstrings and the Input command, it would be a major redesign into an area unfamiliar to me. Furthermore, adding a new kind of hook to the program would impact system performance, probably more than the keyboard hook does (I believe that monitoring the messages of window(s) is an especially large drain on system performance, especially windows that sometimes receive thousands of messages per second). Furthermore, there's a good chance it won't work in all of the games that the current method works in (due to DirectX, etc.). That's a lot of uncertainty and R&D to expend on an issue that has gone unreported for nearly two years and that affects only Java apps on some systems.

Even so, I'll add it to my notes as an alternative approach. Thanks.

numEric
  • Members
  • 30 posts
  • Last active: Feb 24 2008 04:46 PM
  • Joined: 27 Aug 2004

I ran the program again in debug mode, which confirms that ToAsciiEx() is never called while hotstrings are suspended. I can think of only two explanations [...]

I'm afraid both are wrong! The key history shows that your workaround to the ToAsciiEx() problem is still active when hotkeys are suspended or when the script is paused...

[*:3jmcwh5x]Hotstrings aren't the culprit for the Java issue; instead, it's the mere presence of the keyboard hook (but the fact that Sleep 20 solves it seems to disprove this).

Yes, now there's no doubt the Java issue is due to letting no delay at all between sending a dead key and the subsequent key.

couldn't AutoHotkey hook the message queue of the thread that owns the currently active window and monitor it for WM_CHAR messages?
This method has the advantage of not disrupting anything; it doesn't require calling ToAsciiEx() and thus avoids the resulting limitation that involve suppressing/injecting key events, etc..

Possibly, but even if it worked completely for both Hotstrings and the Input command

I've done some testing using Winspector, and couldn't find a case where it didn't work. (I didn't test with apps that use DirectInput, though.)

, it would be a major redesign into an area unfamiliar to me.

It seems rather simple to implement; the outline would look like this:
- When a window gets focus, call SetWindowsHookEx() to install a WH_GETMESSAGE hook procedure for the thread owning the window
- When the window loses focus, release the hook procedure by calling UnhookWindowsHookEx()
- Provide a GetMsgProc() callback function to handle the hooked messages. (Of course this function should return as fast as possible to minimize the performance impact.)

http://msdn.microsof... ... sgproc.asp
http://msdn.microsof... ... ghooks.asp

there's a good chance it won't work in all of the games that the current method works in (due to DirectX, etc.).

I'm not convinced that hotstrings and the Input command are mostly used in games :wink: However, it shouldn't be too hard to deal with this case: if the low-level keyboard hook sees a keystroke and the message hook can't find a corresponding WM_KEYDOWN message, it would just have to revert back to calling ToAsciiEx() as it currently does.

[...] an issue that has gone unreported for nearly two years and that affects only Java apps on some systems.

It affects all systems with a french keyboard layout I could test it on so far, and probably concerns other layouts too...

Even so, I'll add it to my notes as an alternative approach. Thanks.

Thanks :)
This "high-level keyboard hook" approach seems like an interesting area to explore, and if it doesn't affect performance too badly, it may help simplify things...

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

The key history shows that your workaround to the ToAsciiEx() problem is still active when hotkeys are suspended...

I see the problem: I was testing a script that consisted only of hotstrings. When such a script is suspended, the keyboard hook is deactivated, which also disables the ToAsciiEx() section.

In the next release, Suspend will disable the ToAsciiEx() section unconditionally (as long as no Hotstrings are exempt by means of having Suspend as their first line).

I didn't test with apps that use DirectInput, though.
...
It seems rather simple to implement; the outline would look like this:

Thanks for the details, which I've added to my notes. In my experience, the implementation of a hook feature like this is only a small part of the battle; it's the testing and debugging that winds up taking much longer (for me anyway).

I'm not convinced that hotstrings and the Input command are mostly used in games

I never said they were. I just didn't want to release a fix for Java apps that broke Hotstrings in DirectInput games. Also, the idea of message-monitoring hook feels high-overhead to me. For example, when I run Spy++ to monitor messages, the target window's performance slows down noticeably.

Finally, until this gets fixed I've documented it as a known limitation on the Hotstrings page:

On some systems in Java applications, hotstrings might interfere with the user's ability to type diacritical letters (via dead keys). To work around this, Suspend can be turned on temporarily (which disables all hotstrings).

(I left it as "some systems" because the problem is still not reproducible in French on my fairly typical PC. Maybe it has something to do with the fact that my default keyboard layout is English, even though I switched to French in Java.)

Thanks for everything.

numEric
  • Members
  • 30 posts
  • Last active: Feb 24 2008 04:46 PM
  • Joined: 27 Aug 2004

The key history shows that your workaround to the ToAsciiEx() problem is still active when hotkeys are suspended...

I see the problem: I was testing a script that consisted only of hotstrings. When such a script is suspended, the keyboard hook is deactivated, which also disables the ToAsciiEx() section.

The mystery is over :lol:

Thanks for the details, which I've added to my notes. In my experience, the implementation of a hook feature like this is only a small part of the battle; it's the testing and debugging that winds up taking much longer (for me anyway).

Probably, though I think it would likely be easier to debug than something implemented at a lower level.

I'm not convinced that hotstrings and the Input command are mostly used in games :wink:

I never said they were. I just didn't want to release a fix for Java apps that broke Hotstrings in DirectInput games.

Of course, and that's not what I meant: it was an ironical way to say that making hotstrings/Input work unconditionally should have at least the same priority for Java apps than for DirectInput games since they are probably more useful with Java apps.

Also, the idea of message-monitoring hook feels high-overhead to me. For example, when I run Spy++ to monitor a window's messages, the target window's performance slows down noticeably.

Maybe Spy++ hook's callback function is too heavy? The effects on performance would be one of the first things to check after implementing a hook which callback function, unlike Spy++'s, would return immediately on all messages except WM_KEYDOWN and WM_CHAR; if it causes a noticeable slowdown, this method would be inappropriate, of course.

Besides that, the only other solution I can think of would be to code your own ToAsciiEx()-like function that would do the same as Microsoft's without resetting the dead-key state. (Sorry I have no idea about something easier to do :mrgreen: ) At least this one would have no impact at all on performance!

Philipp007
  • Guests
  • Last active:
  • Joined: --
I know this thread is old but I have a very similar problem. If I'm running a simple one line script with a hotkey accents act very unreliable in every program. I'm using Vista with a German keyboard layout.

This is produced by trying to type a lot of á-characters:
aáááaaaaáaaááaáááááaaaaaaááaaáaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaáaaa

The same happens with â, à and accents on other letters like i and o.

The problem occurs only if there are hotstrings in the script. Unfortunately I use a lot of hotkeys :( So it's clear that I still want to use them.

Here is my (a little bit weird) key history. I pressed the ´-key three times. There are four down/up-events instead of three. And the order doesn't seem to be correct either.

DD  00D	s	d	2.73	AKUT           	
DD  00D	 	u	0.08	AKUT           	
DD  00D	 	d	0.33	AKUT           	
DD  00D	i	d	0.00	AKUT           	
DD  00D	i	u	0.00	AKUT           	
DD  00D	 	u	0.09	AKUT           	
DD  00D	 	d	0.25	AKUT           	
DD  00D	 	u	0.08	AKUT


Just while I wrote this lines I got a idea for a work-around. Maybe it helps somebody.

SC00D::
		StringCaseSense, On
		Input, UserInput, T3 L1,{enter}
		
		if userinput = a
			send {á}
		else if userinput = A
			send {Á}
		else if userinput = e
			send {é}
		else if userinput = E
			send {É}
		else if userinput = i
			send {í}
		else if userinput = I
			send {Í}
		else if userinput = o
			send {ó}
		else if userinput = O
			send {Ó}
		else if userinput = u
			send {ú}
		else if userinput = U
			send {Ú}
		else if userinput = %A_Space%
			send, ´´{bs} 
		else
			send, %userinput%
	return      

	SC029::
		StringCaseSense, On
		Input, UserInput, T3 L1,{enter}
		
		if userinput = a
			send {â}
		else if userinput = A
			send {Â}
		else if userinput = e
			send {ê}
		else if userinput = E
			send {Ê}
		else if userinput = i
			send {î}
		else if userinput = I
			send {Î}
		else if userinput = o
			send {ô}
		else if userinput = O
			send {Ô}
		else if userinput = u
			send {û}
		else if userinput = U
			send {Û}
		else if userinput = %A_Space%
			send, ^^^^{bs 1}
		else
			send, %userinput%
	return

	+SC00D::
		StringCaseSense, On
		Input, UserInput, T3 L1,{enter}
		
		if userinput = a
			send {à}
		else if userinput = A
			send {À}
		else if userinput = e
			send {è}
		else if userinput = E
			send {È}
		else if userinput = i
			send {ì}
		else if userinput = I
			send {Ì}
		else if userinput = o
			send {ò}
		else if userinput = O
			send {Ò}
		else if userinput = u
			send {ù}
		else if userinput = U
			send {Ù}
		else if userinput = %A_Space%
			send, ````{bs 1}
		else
			send, %userinput%
	return

Now, the try to write a lot of accents looks like that :D
áááááááááááááááááááááááááááááááááááááááááááááááááááááááááááááá

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Nice workaround.

I'm pretty sure the issue doesn't occur on Windows XP because I have tested the German keyboard layout with various hotstring and hotkey configurations.

It would be good to get confirmation that this issue affects all Vista users who type dead keys while hotstrings are in effect. So if anyone ever gets a chance to do more testing, please post here.

Thanks for the report.

Lucas Repolês
  • Guests
  • Last active:
  • Joined: --
Hi.

The last message was sent in 2004. We are in 2010 now and I think this issue wasn't fixed yet.

I'm trying Autohotkey, It's great tool! But all the time I need to use Java programs like IntelliJ IDEA, Eclipse and DbVisualizer. And in those programs, it's impossible to write accented caracteres like á é í ó ú ã â.

Does anybody know how to fix this? Philipp007 workaround doesn't work for me.

Thanks.