swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Argument passing in Schedule


From: glen e. p. ropella
Subject: Re: Argument passing in Schedule
Date: Sun, 9 Feb 1997 14:53:13 -0700

> The way I coded my model, I have a two schedules under one ModelSwarm. One
> is the regular repeating schedule, and the other holds a discrete event
> "scratch schedule" a la mousetraps.
> 
> The repeating schedule controls the model's interval -- and since I'm
> using multiple model swarms, I can produce different interval ratios. But
> I still require a discrete event portion of the model, so I used a
> seperate (non-repeating, autodropping) schedule to handle that. 

How and where did you activate the scratch schedule?  Did you activateIn
on the modelSwarm (self) or the modelSwarm's activity?

> The repeating schedule works fine; however, the scratch schedule doesn't.
> 
> Specifically, I defined a function,
> 
> -(void) modelDeliverRouterMessage: (RouterMessage *) msg To: (id) target {
> 
>    [modelScratchSchedule at: (getCurrentTime() + 1
>     createActionTo: target
>     message: M(eventReceiveMessage:):msg];
> }
> 
> Here is the problem: I don't know if the message is being passed, or if
> the argument is being passed. I looked through a hard-copy of NeXT's ObjC
> manual, and they were pretty vague on the selector names. 
> 
> The definition for eventReceiveMessage is
> 
> -(int) eventReceiveMessage: (RouterMessage *) msg;
> 
> And looking through the manual and the demoes, I think what you put into
> the M() macro makes a difference. The runtime environment kicks out
> whenever an receiving object doesn't respond to a message, so I assume for
> the schedules, it is the same. (Is it?) If it is, then I'm doing something
> wrong with passing the argument; if it isn't, then I'm doing something
> wrong in naming the selector.


It looks to me like your selector is fine, at least in argument terms.
If it's the problem, I would suspect the (int) return value before I
would suspect the argument.

I would concentrate on checking the time at which you intend to send
the message and what time getCurrentTime() + 1 is returning.  BTW, in
your code fragment above, your parentheses are not closed around
getCurrentTime() +1.

Anyway, you might also put something on the schedule before it's
activated (so that it is non-zero to begin with) and see if it 
does that at least once.  

>  1) I added a nil check for both target and modelScratchSchedule. The
>     modelScratchSchedule wasn't nil, but the target was. So I said to
>     myself, "maybe this will work". When I fixed that bug, the debug message
>     still doesn't print out.

Are you saying that the target is no longer "nil?"  I.e. that a 
message is, in fact, being sent to a valid object?  

glen


reply via email to

[Prev in Thread] Current Thread [Next in Thread]