You've got too many variables here for me to give a good answer.  So some hints and guesses:



schedule.scheduleOnce(schedule.getTime(), new Steppable() {

    public void step(SimState state) {

         // Stopping steppables in here

    }

}



Let's say that schedule.getTime() = t.  Then this code will stop any steppables scheduled for time t + epsilon and beyond.  However if a steppable is scheduled for time t it will still be stepped.



It's not clear what you mean by "stopping" the steppable in this context.  I presume it's scheduled repeating, so you're calling stop() on the Stoppable that was returned when you originally scheduled it.  Alternatively I suppose you could refer to having the Steppable wrapped in a TentativeStep and you're calling stop() on that.  Either way, just because you call stop() on the Steppable doesn't mean it's entirely deleted from the Schedule.  The object is dropped from the Schedule and can be garbage collected, but its outer wrapper (a TentativeStep or a Schedule.Repeat object) remains on the Schedule awaiting its final step() method, which will do nothing at all.



Since you mentioned Display2D I should remind you that visualization and GUI events should NOT be scheduled on the schedule but rather added to the "minischedule", part of the GUIState.  Make sure you're doing that.  Otherwise you won't be able to serialize models properly.  There's some discussion in the manual about this.



Last I'm wondering about when you're clicking on the objects -- I wonder if there's a fencepost error.  I suspect here's what might be happening.  When the GUISTate's step() method is called, it does the following:



	- call step() on all objects on the "before" minischedule  

	- advance the Schedule and step it

	- call step() on all objects on the "after" minischedule



The Display2D's step() method is scheduled on the "after" minischedule, and in the step() method it calls repaint(), which queues up a repaint event on the Swing event queue, along with your mouse clicks.  Thus at the time that your mouse clicks have any effect, the schedule has ALREADY stepped all Steppables which were scheduled for the current schedule time.  You should still be able to schedule for that time plus epsilon though. But instead of doing that, why not just call stop() from your mouse click?  You'd do it like this:



	synchronized(gui.state.schedule)  // so we're not modifying at the same time as the model

		{

		stop() all the objects of interest

		}



Anyway, that's all I can think of for now.



Sean



On Sep 21, 2011, at 4:01 PM, Sam Brett wrote:



> I am having a problem removing Steppables from the schedule dynamically. I

> am stopping them in an extension of the Display2D class which I called

> InteractiveDisplay2D where I can remove agents by clicking on the grid. But

> I find even when stopping these Steppables that they will linger on the

> schedule. For example, I am stopping them by means of:

> 

> schedule.scheduleOnce(schedule.getTime(), new Steppable() {

>     public void step(SimState state) {

>          // Stopping steppables in here

>     }

> }

> 

> I read that if you do a schedule once on the current time that the steppable

> will be put on the schedule at the current time plus epsilon. So I thought

> this should work as I will have always stopped the Steppables after they

> have executed and on the same thread. In that way, there should be no thread

> interference. But still I am having this problem. This must have something

> to do with the Display2D being on the event dispatch thread separate from

> the thread the schedule is operating on. I cannot understand why though,

> since I put the removal on the schedule itself.