MISTAKE:

void* key_map[88
void* key_map_cache[88]

Should be...
void* key_map[MAX_KEY_POS];
void* key_map_cache[MAX_KEY_POS];

DON'T KNOW THAT GOT MESSED UP : (


The purpose of "void *" is the general specification for a function pointer, which the handlers are. All the def_* methods are default handlers defined in defaults.c, which is the reason for the "#ifdef default_c" (which gets defined if included). Haven't dug deep enough to know why def_video() and def_def_debug() crash when invoked in this code, as opposed to the setting them to their respective "nn_*" EVENT objects.

One odd thing is, Lite-C doesn't like locally defined function pointers, so you have to define one globally for use in functions... I hate this, but I guess this rule might relate of the "clean-up" methodology they built into the engine.

The use of a struct might be good to hold at least the key's literal name its corresponding handler's pointer. You wouldn't need to cache the key's name, so I would probably leave the caching array as is, but store the structs into the key_map[]. The key's name would only really be useful when providing an interface to see and change their key mapping, which is a good feature.

I'll keep playing and testing. I really need to learn how to effectly use debugging, which isn't as clean as I'm used to (Eclipse IDE, with JAVA).

With debugging I create temporary global variable with debug in the name and set them to the value I want to see. For example debugStartPoint=startPoint; I haven't found a way for the debugger to allow local variables to be seen so this is my reason for it. I'm hacking the struct now and will post shortly.

Great! It's to bad that the debugging capabilities aren't a little more robust. By the way, that fix to the index in the declaration of the 2 arrays fixed the problem with those couple def_* functions... I'm surprised it even ran at all! I tried to run again when I was playing with my struct idea, had problems, so commented out to original code and crashed before things even really got running, which caused me to reexamine my shortcomings : )

For debugging... you just create a panel to display your debug* vars?

Ok, I've hacked together a general on_anykey function which captures the scancode and resolves them via the key_mapping array. Anyway, here is what you were probably already thinking. As such I see no need for a struct at this time.

P.S. You have KB_C defined twice, once for the c key and once for the comma key. I changed it to KB_COMMA.


Implementation:

//Test Functions:
function BeepOnce()
{
beep();
}

function BeepTwice()
{
beep();
beep();
}
//End Test Functions

void gpFunction();//global function pointer

//function to handle input
function processInput(scancode)
{
gpFunction=key_map[scancode];
gpFunction();
}

function main()
{
map_key(KB_B, BeepOnce);
map_key(KB_C, BeepTwice);

on_anykey = processInput;
}

You got it right on the head! Now, I made one last change. I removed the call to disable_onkey_defaults() from the top of map_default_keys() and placed it at the top of init_key_map(). This makes more sense, since this is where we want to make sure the any on_* events are not set, while we are preping our own handling array. disable_onkey_defaults() is only called once, so it could really be removed, with its logic being moved to the top of init_key_map(). What do you think?

What got me going on this effort is, I was designing a intro splash screen, a main menu, with an options sub menu. I needed a way to turn off the keys during the splash screen display. I also want to add the ability to provide keyboard navigation of the menus when they're being displayed, but return back to the game mapping when they are closed.

Yes, disable_onkey_defaults() should only be called once. I also believe I see the value of this architecture. I think that we need an array of arrays allowing for several different key mapping "sets". For example:

//Pseudocode

#define MAIN_MENU, 0
#define OPTIONS_MENU,1

//individual key sets
var arKeySetMainMenu[88];
var arKeySetOptionsMenu[88];

//all key sets
var arKeySets[2][88];

arKeySets[MAIN_MENU][KB_A]=arKeySetMainMenu[KB_A];
arKeySets[MAIN_MENU][KB_B]=arKeySetMainMenu[KB_B];

arKeySets[OPTIONS_MENU][KB_A]=arKeySetOptionsMenu[KB_A];
arKeySets[OPTIONS_MENU][KB_B]=arKeySetOptionsMenu[KB_B];

Of course we'd write a function to assign the arrays to this multidimensional array.
Or we could simply forgo extra arrays and shove stuff directly into the multidimensional array.

I thought a bit about the possibility you speak of... multiple key mapping sets.

I had out-of-town guests and wasn't able to post another correction. I found another problem with the size specified for the arrays, which ripple down to the conditions tested. I noticed that your code is using the incorrect 88, which wouldn't include the mouse and joystick scancodes. The size of the arrays should be 116 as opposed to the earlier correction I made of 115. I noticed that your code is using the incorrect 88, which wouldn't include the mouse and joystick scancodes. If one did want to just include the keyboard, the 88 would have to be upped to 89 and the loop conditions would have to test for "< 89".

Here's the corrections I made to account for all scancodes:

EDITED: BETTER NAME FOR THE FOLLOWING WOULD BE KEY_MAP_SIZE...
#define MAX_KEY_POS 116

...

void init_key_map()
{
...
for( i = 0;i < MAX_KEY_POS; i++)
...
}


void cache_key_map()
{
...
for( i = 0; i < MAX_KEY_POS;i++)
...
}

void restore_key_map()
{
...
for( i = 0; i < MAX_KEY_POS; i++)
...
}

void map_key(var scode, void* funct)
{
if (scode > 0 && scode < MAX_KEY_POS )
...
}

I think this covers the array dimensioning problems. Recognized this problem when my code was crashing, in an attempt to work on navigation control. Saw the dimensioning problem and fixed it thinking it would correct my crash. Didn't correct the crash, but at least the subtle dimension problem is fix fixed.

For anyone that has been visiting this thread, I've placed a corrected code listing in the form of an includeable Lite-C module over in "Lite-C Contribuitions", under the topic of "Key Mapping Management".