I've just noticed that my textbox, in OSX started writing those square [] looking characters when I pressed the arrow keys in OSX. Therefore the unichar field was non zero which is not consistent with Windows.

Up : 63232
Down : 63233
F1 : 63236

Docs say: This may be zero or negative if the event was generated for a non-visible "character", such as an arrow key.

Those numbers don't look zero or non negative

Since it happens in KeyChar, I have no way of filtering out these keys other than checking each one which seems wrong.

Thanks

Could you possibly filter out Apple's special Unicode range and return 0 when you hit a key in that range?

ex:

if(unicode > xxxxx && unicode < yyyyy)
{
   //Apple being *special*
   unicode = 0;
}

What do these give for you on OSX? this is why in my gui I do if(unichar >= ' ') and that works on Linux and Windows.

I've attached a patch that fixes my problem, and should make Allegro consistent with Windows and Linux, I basically filter out Apple's specialness.

Well, in OSX backspace gives me 127 instead of 8 it seems - so the <= 32 would not work for it either.

I think it would be nice to have Backspace return 8 on OS X as well.

On X we return 127 for Delete. On Windows (wine) we return 0.

Oww, after a very short googling I find that the key labeled 'delete' on a MacBook is the one that performs a backspace : To erase current character you'd do fn+Delete (*).
No that wonder that it gets confusing for cross-platform libraries...
Should allegro tell which key the user pressed ('delete') or what he wanted to do ?

(*) Does fn+Delete cause an event with unicode = 'the character for delete', different from 'the character for backspace' ?

On my mac mini (using a normal, non-mac keyboard plugged into the USB port) the Backspace key produces 127 and the DEL key produces 63272. Both keys work as expected in native OSX applications. If we document Allegro to produce 8 for backspace and 127 for delete it seems we'd have to adjust for that.

An alternative solution would be to get rid of control codes and return 0 for backspace and delete as well as tab, return and esc. It seems to have things working on Macs you have to check the key code anyway - so allowing those ASCII codes under windows and linux would just mean more broken keyboard input code.

So the keycode is always correct and the unichar is bogus?

I think the only thing that makes sense in 5.0 is to either a) document it, or b) convert OS X unichars to something sensible.

This is how I have always been doing it:

if (keycode == ALLEGRO_KEY_BACKSPACE)
{
}
else if (unichar >= 32)
{
}

I realize not all unichar >= 32 are going to be true printable characters, but that doesn't bother me. The point is, checking for non-zero isn't very correct anyway.

I don't think it should be assumed that Allegro translates or modifies the unichar in any way whatsoever. And I really don't think we should go about changing 5.0's behavior.

For 5.2 if the consensus is to zero out the unichar, then go for it. But I don't see why it's absolutely necessary. To me the field should simply be what the OS reports as the printable unichar. I don't consider LEFT/RIGHT/DELETE printable characters, so why would I ever think to use unichar for them?

To me, this is primarily a documentation issue.

There's possibly more keys, maybe F keys produce non-standard unicode as well under OSX.

I don't really care... Unless I'm checking every unichar code to see if it maps to some printable character with the font I'm using at the time, whether or not we mask some keys or not is irrelevant.

And if I do that (validate that the unichar key is in the font), then it doesn't matter if Apple uses strange characters. They wouldn't exist in the font, and they would be ignored.

To me unichar == something to be printed. The only time I would use unichar is if I want to print a string to the screen. If the user presses F1 when entering his name and that produces some strange symbol on OS X, I couldn't care less. If I'm looking for function keys or anything else that maps to a physical key, I'm just using the keycode constants.

Backspace, Tab, Enter, Escape, etc. have ASCII codes associated with them, so to me, that's what they should produce if you "type" them. Ctrl-A also produces 1, Ctrl-B produces 2, etc.

I can see the reasoning for all three choices, but my preferences would be: C, B, A.