I'm programming something that will have to take input of "international characters" (US-International layout), to put it short. For example, µ, altgr+m.
However, regardless of OS keyboard configuration, Allegro seams to react with keypresses anyway.
I've made the code to recognize a modifier + keypress, but my question is if there's a shortcut, so I don't have to code for all modifiers in specific. I mean, it clearly recognizes shift (event.keyboard.unichar will input both M and m just fine), so why not altgr too? Am I missing something?
Also, I wonder what's the case with non-QWERTY layouts and language support of other languages (say, Japanese keyboard layout).

If I switch to the US international layout, AltGr+M works fine in ex_keyboard_events. I get both a CHAR event for 'µ', and UP and DOWN events for both AltGr and M. My keyboard is actually French, don't know if that matters.

EDIT: Should mention that I'm on Windows 10. And tested with ex_keyboard_events from Allegro 5.0.5, that's what I had laying around.

Please Read The Fine <allegro> Manual here :

https://liballeg.org/a5docs/trunk/events.html#allegro_event_key_char

I edited something since I last posted this, forgot something important to add.

Instructions unclear: code now appends garbage whenever it stores a non-ASCII character (ex.: µ). (I'm joking, but it's true)

I tested ex_keyboard_events, on Windows, and it doesn't output the altgr characters, although I can see it (try to) render characters with accents (such as é).

The problem here is a bit tricky to explain. It seems to be appending some garbage character by the end of the string. When I type the non-ASCII character, it seemingly types two characters (because of the caret), which always remains on the end of the string. The string renders up to before the intended non-ASCII character, but shows up back if it's the last one.

If Ctrl sets event.keyboard.unichar to 13 (A = 1, B = 2, etc), what does AltGr change it to? Have you tried adding an else if AltGr is not pressed?

I figured out the issue. What DanielH mentioned is right, the code is also putting the key without altgr together, I need to make sure it doesn't.
The issue is this: it wasn't garbage. What happens is that in UTF-8, those non-ASCII characters are usually represented by 2 bytes, instead of just one in the case of ASCII. But then, I didn't account the extra length of such characters with the caret. In the end, the caret would then insert data IN BETWEEN the two bytes of the non-ASCII UTF-8 characters, resulting in usually unreadable characters, and corrupting the rest of the string for matters of rendering (or maybe rendering characters that the font didn't have).
I modified this code a bit too much to quote, but in short, it revolves around using al_ustr_offset. Whenever I need a specific position in the string, regarding characters, not bytes, using al_ustr_offset will count the characters in the string, not the bytes. So the caret logic stays the same, but al_ustr_insert_chr(text_typed, caret_position, event.keyboard.unichar); should use al_ustr_offset(text_typed,caret_position) instead of just caret_position.