More describable event actions

[Jeremy Hill]

Greetings Rom List,

Long question here..takes a little bit to set up the question(s) that I need to 
ask.  Please
bear with me!

I am working on modifying Kyndig's Event system a little to add some 
flexibility. Out of the
box, the event_data structure looks like (only relevant parts shown for this 
question):
struct event_data
{
    ...
   int      action;
};

Where action is assigned via:

#define ACTION_PRINT 1

eg. ev->action = ACTION_PRINT;

and is used in event_update as such:
void event_update(void)
{
...                        switch(ev->action)
                        {
                         case ACTION_PRINT:
                            ...<do the event, with this action's specific stuff>
                        }
}

Because I commonly find myself querying the event queue to see what's doing 
what for debug
reasons, I like to see what action is attached to each event.  Typically, since 
with the above
we only have an integer representing the action, we would have to do something 
like:

if (ev->action == ACTION_PRINT)
    send_to_char("Action type: print\n\r", ch);

I decided to move the actions into a table that looks like (structure and 
table):
struct event_action_type
{
    char *name;
    sh_int *pea; //Pointer-to-Event-Action [number]
};

const struct event_action_type event_action_table[] =
{
    {"print", &ea_print},
    {"wait", &ea_wait},
    {"act", &ea_act},
    {"function", &ea_function},
    {"kill_menu", &ea_killmenu},
    {"NULL", NULL}
};

This uses the same basic technique as the skill table; each 
event_action_table[].pea is assigned
a number on bootup. ea_print = 1, ea_wait = 2, etc.  Now ev->action = ea_print, 
for example.
The reason behind a table is that a table can be readily expanded as needs 
arise.  For example,
as more action types are added (and as they get more sophisticated), I'll add a 
function pointer
to simply dispatch an event function to handle the event rather than doing the 
handling in the
event_update itself (I realize that function calls are slower, but it would be 
much more sane to
manage).

In the meantime, I have run into a serious problem.  In event_update, a switch 
statement is used
to see what the ev->action is.  My cases are ea_print, ea_wait, etc, but I 
cannot use them as
case labels.  Eg.:

switch (ev->action)
    case ea_print:

This obviously won't work.

Finally, my questions:
Anything I can do to keep the switch, or will I need to resort to an ugly 
if/elseif block? (if
ev->action == ea_print...)
Do you think I should reconsider my design in the first place?  If so, what do 
you recommend?
I'm not quite sure I'm seeing appreciable gains for the work that has already 
been done. Plus I
am worried that once many events get up and running, this system may be much 
more slow than the
simplistic one of ACTION_XXXX.  What do you think?

I felt like I should ask the list, as many of the list members are way more 
experienced than
myself!

Thanks for your help,

Jeremy