Re: Argument passing in Schedule

[Ho-Sheng Hsiao]

On Sun, 9 Feb 1997, glen e. p. ropella wrote:
> > 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

I apologize too: I have no idea what I wrote :) I think I meant, "if
different return values affect a selector".

> suggesting is that the selector might assume a return value of 
> (id) and is therefore trying to send 
>    (id) eventReceiveMessage: (RouterMessage *) msg

Yes... but I do see examples in the ObjC manual with different return
values. I've also tried your suggestion of putting something in the
schedule. The selector I used returns something not an id, and it works.

> 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.

One would get that; the only problem is, I didn't get that message. I
really don't think gcc computes the return value into a selector: gcc
*does* warn if two identical messages (except for the return values) in
two different objects... 

> So, that's probably a dead-end.

Agreed.

> Have you laced your code with print statements or walked through the
> debugger?  I would place a 
>   printf("getCurrentTime() = %d\n", getCurrentTime());

I was raised on Borland IDE -- so I'm lazy when it comes to gdb. (I've
never even invoked it ... ) On the other hand, I did lace my code with
print messages. Here's my results:

   1) pointers are Ok. They arn't nil, and they do respond to the messages
      I'm trying to sent. Adding in actions *after* buildActions but
      *before* activateIn:, it works.

   2) The modelDeliverRouterMessage works. I printed out a message whent
      it gets invoked, and it does.

> 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.

Did that, and it *does* do the correct time. I even tried

[[self getActivity] getCurrentTime]

 in place of getCurrentTime() -- to the same effect.

---hhh