OK let me take a stab.
This isn't going to be much prettier, but it'll let you use a switch
statement. You'll still need those constants, probably put an entry for
them in event_action_type. Then you'll need an array of integers you fill
in at boot time where
that_array[ACTION_TYPE] = &ea_type
So now you have a (fast) way to get to the table index from the constant.
Then in the switch statement,
switch(ev->action)
{
case ACTION_TYPE:
chprintf(ch, "Action type: %s\n\r",
event_action_table[that_array[ev->action]].name);
break;
}
Er.. that's not a very elegant solution, is it?
There's probably something better.
*wanders off, mumbling something about 5am and coffee*
--Palrich.
----- Original Message -----
From: "Jeremy Hill" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, August 30, 2003 3:52 AM
Subject: More describable event actions
> 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
>
>
> --
> ROM mailing list
> [email protected]
> http://www.rom.org/cgi-bin/mailman/listinfo/rom
