weird Alt+8 or Alt+9 behavior
Hello everybody,
the Alt+8 and Alt+9 key combinations are not catched by the _key() and _keyfilter() routine at first; they're catched only when the 8 or 9 key is pressed once more. I'm on a MacBookPro.
I guess this has to do with the fact that on macintosh Alt+8 and Alt+9 will create accents on the next letter, as `+a = à, and so on. Yet this is extremely annoying, and also it doesn't makes that much sense (since I might want to use key mappings for everything but writing in a text box...).
I need to map all numbers 1 to 9, and the last two behaving oddly is not what I'd love to expect: is there a way to bypass this issue?
Thanks,
Daniele
What OS, Max version, SDK version etc? I'm assuming Windows, but it is helpful not to make us guess these things.
It looks like you're running into dead keys. Dead keys are used for generating accented characters with dual keystrokes, which is what you're reporting. The thing with dead keys is that they are, um, *dead*. Most OS key-reporting functions will not report a keystroke to the application until the second character of the dual-stroke has been made. Even if the user enters an invalid dual-stroke combination, thereby generating two separate key events, they can't be reported until the second stroke has been made.
There may be a low-level OS API for getting reports of dead keystrokes. But if we don't know which OS you're on…
Hi Peter, thanks for your answer. I said I was on MacBookPro, so that could hardly be Windows :-)
I'm on Mac OS X 10.6.8, last Max 5 release, latest Max 5 SDK.
The fact is that many other Mac applications correctly use the Alt+8 or Alt+9 keys, so I assume there has to be a way to catch the events?
Thanks again,
Daniele
I'm guessing you are not using a US keyboard layout—since for me Alt-8/9 do different stuff. I'd be curious what happens if you switch keyboard layouts. Some other time when I have the time I will try some tests on my US keyboard in that I'm curious if alt has problems with the keys US layout uses for accents.
I'm sure there is some solution, but I've seen other strange stuff with other keyboard layouts (for some strange reason two different people I was working with on a project using French keyboard layouts had different behavior in Eclipse when trying to use Command-/ (probably something to with the fact that / is the shift-symbol on the : key on the AZERTY keyboard—but I have no idea why it was behaving differently on their two computers)).
You are right, I'm on Italian keyboard layout: with USA keyboard, the Alt+8 and Alt+9 keys work perfectly. Weird.
Other software, such as Finale, intercept them also on Italian keyboard. Is there a way to intercept them no matter the keyboard layout?
Do you have the smame problem when you do ALT+ (I mean the key to the left of the 1 key which I think is on your keyboard) when using the US keyboard layout have the same problem? That is is the key used to type à è etc (you could also try ALT+i and ALT+u and ALT+n for other accent characters on the US keyboard to check for that problem)
Scusami, I missed the word "MacBook", but we also needed to know things like the keyboard layout. In principle the exact behavior can also depend upon which OS X version you are running (although this particular issue has not changed for quite a few years). Finally, it's quite possible to run Windows on a MacBook (although not the most common combination;-)
But it boils down to an issue with dead keys, as I wrote in my previous post. If you want to subvert dead key processing, you'll have to go into deeper levels of the OS API than the Max SDK key() and keyfilter() functions go. That, I am afraid, is the long and short of it. Finale, the counter-example you cite, doesn't rely on the Max SDK, but talks directly to the host OS.
AFAIK the hi object provides this lower level access to keyboards, at least on Mac, as they're seen as hi devices there.