Re: Traversing Schedules

[Roger M. Burkhart]

The trouble with your loop that traverses schedules and tests for
concurrent groups is the line:

    if ( [actionAtTime respondsTo: M(begin:)] )

The action that fires a concurrent group at a time value is an ordinary
action; it contains the group in an instance variable but does not itself
respond to messages on the group, such as begin:.  I'm not sure if this was
ever the case but it's definitely not in the current release.

Unfortunately, in the current release the concurrent action was stripped
to be just like any other action without a lot more built-in support than
just to execute it.  To get the concurrent group inside the action (on
which you can perform the action) you'll have to break the encapsulation
and look inside the action.  Your code will need to include the following
two #include statements:

#include <activity/Schedule.h>
#include <activity/classes.h>

Then you can perform the test and initial processing of the concurrent
group as follows:

  if ( [actionAtTime getClass] == id_ActionConcurrent_c ) {
    groupIndex = [((ActionConcurrent_c *)actionAtTime)->concurrentGroup
                   begin: [self getZone]];
    ...

I haven't actually compiled this fragment, but it's very close to code
inside the activity library so should be close.  Keep in mind that it's
referring to internals inside the classes so could be subject to breaking
on further maintenance of the activity library, and so is not a permanent
solution.

A concurrent action should provide a supported method for getting its
associated group (the collection of actions to be run at that time).  If
there was a special message for that, it could be used as the argument of
a respondsTo: test as you were doing for begin:.  There was nothing wrong
with your use of respondsTo:, and this is the way I prefer to test the type
of objects (as long as there's some message unique to what you're testing
for); it's just that begin: doesn't happen to be supported on concurrent
action.  I've specifically reimplemented respondsTo: in defobj to work fast
so that it can be used for these kinds of routine tests.

Then again, instead of your having to do all this work, we could incorporate
your printSchedule directly as one of our standard debug print messages that
can be called from your own code or from the debugger.  In this case, we'd
probably make it the "xfprint" message supported on any collection object.
If you get a working printSchedule method please pass it along and we'll
see about including it in the standard library; could be our very first
crude form of a schedule "browser" we've talked about for a long time.

-Roger