Re: schedules

[Roger M. Burkhart]

Doug Donalson writes:

>    I am running into an error trying to remove an event from
> an autodrop/concurrent group schedule.  You wrote:

[quote deleted]

> I coded this as: [[eventSchedule remove: eventId] drop];
> 
> where eventId is the id returned from create action.
> 
> This is what I get in response:
> 
> *** event raised for error: SourceMessage
> *** function: _i_ConcurrentSchedule_c__remove_(), file: Schedule.m, line: 619
> > A concurrent schedule requires either that a subclass override the method
> > that removes an action, or that all actions be removed from the group by
> > an explicit operation using the key of an action in the schedule.
> *** execution terminating due to error
> IOT trap (core dumped)
> 
> What am I doing wrong??

What I wrote about remove working on a concurrent group is correct, but
oversimplified.  It doesn't work if a concurrent group is actually a
schedule (ConcurrentSchedule or custom subclass, as opposed to
ConcurrentGroup or custom subclass, which is the default).

You are using a schedule as your concurrent group, I assume as part of
your two-level scheduling structure.  Since a schedule is a map from its
time value keys to its action members, a simple remove on its members is
not currently defined.

If you know the concurrent schedule level is always there, you can remove
the action from it directly, using the same techniques to get that internal
schedule as you use for inserting.  If you have the key value, you can
remove the internal schedule using removeKey:.  Otherwise you'd have to
search the schedule for the matching action using an index, and remove it
from there.  There's currently no remove: of a member of a Map collection
(which includes schedules), though if you want to define your own subclass
of ConcurrentSchedule and define a remove: message for the action on that
(as the error message suggests), that would work too.

For a generic Map collection, a remove: of a member doesn't necessarily
make sense, since the same member could be present in the Map under more
than one key.  A Schedule, however, has only actions as members and these
are required to be distinct irrespective of key.  So it probably makes
sense that some form of remove: be supported on a ConcurrentSchedule used
within another schedule, instead of this error message, but that's not the
way it is in the current version.

-Roger