Re: Argument passing in Schedule

[glen e. p. ropella]

> Actually, I did. I tried it with (void) and (id) -- same results. The NeXT
> ObjC manual isn't clear if the return value affects the return value. In
> any case, gcc warns of messages returning different return values (as
> defined in @interface or @implementation). 

I apologize, but I have no idea what that means.... "if the return
value affects the return value." [grin]  It's late.  What I was
suggesting is that the selector might assume a return value of 
(id) and is therefore trying to send 

   (id) eventReceiveMessage: (RouterMessage *) msg

which the object doesn't accept.  And, since you're building this
call dynamically, the compiler might not know to check the target
for that message.  But, of course, I don't think that things would
go so smoothly during execution.  I would think you'd get a 
"target does not respond to ..." message.

So, that's probably a dead-end.

> > I would concentrate on checking the time at which you intend to send
> > the message and what time getCurrentTime() + 1 is returning.  BTW, in
> 
> I did that -- it looks fine. Of course, my only way of knowing that is
> approximating the time on the graphs... any way to check for the exact time?

Have you laced your code with print statements or walked through the
debugger?  I would place a 

  printf("getCurrentTime() = %d\n", getCurrentTime());

at the point where the message is to be placed on the schedule.  Then,
at least, if you get that print, then you can both confirm that control
is passing through that part of the code *and* find out what it's
interpretation of time is.

glen