send to program debuging

Mike McManus mcmanusm at kramergraphics.com
Fri Dec 13 06:19:01 EST 2002


Oh boy..this is not fun sounding. Yes the send command will not work. 
Need to use "send to program" Being a Mac guy I just understood that. 
Now The two runrevs, don't like that idea either, but it may come to 
that. Thinking about this option while I was driving today. I might be 
able to build a standalone. That simply accepts the send to program 
command. Puts it into a field, then sends an acknoledgement back to the 
development stack.

This way I should get what you were talking about. Get a clear 
understanding of what I need to parse and how the variables get 
passed(yes there will be variables, filenames, process codes, paths). 
Once I have those mastered in the main stack and the standalone, I will 
be able to code it properly and compile? Mostly what will be sent out 
is a command along with the parameters. The response should be a "yes I 
am done with process 10001" kinda thing or an error.

Does that sound reasonable to anybody other than me?

On Wednesday, December 11, 2002, at 11:20  AM, Jan Schenkel wrote:

> --- Mike McManus <mcmanusm at kramergraphics.com> wrote:
>> How would you debug "send to program" commands used
>> to send commands to
>> other stacks when you are developing? To be more
>> clear. My main stack
>> sends commands to other freestanding stacks, which
>> will be independent
>> applications when built. Buut during the development
>> process I don't
>> want to compile things everytime I want to test it.
>> Using IAC to create
>> a server application that controls other stacks.
>> They will talk between
>> each other.  Sending and replying after the
>> complication of certain
>> activities. The send command isn't exactly the
>> same...and of course
>> then I would have to go back and change the commands
>> before I built the
>> standalones.
>>
>> Ideas?
>>
>
> Well, like Rob pointed out, this will only work on a
> Mac. My approach to this particular situation would be
> to get hold of a second Mac, and run the 'main' and
> 'separate' stacks in a RunRev on each machine -- you
> _do_ have two licenses, don't you? *grin*
> Enter Script Debug Mode on each, and put a breakpoint
> on the AppleEvent handler in the stack script so that
> you can trap what message is actually sent and how it
> works its way from there.
> Reason: when you 'send to program', this is translated
> into sending an AppleEvent of class "misc" and type
> "dosc" -- unless you specify your own classID.
> You will have to resort to using AppleScript in order
> to get the correct name of the target program for the
> 'send to program' instruction, as the 'answer program'
> command is not supported in RunRev.
> Potentially useful link in the archives:
> http://lists.runrev.com/pipermail/use-revolution/2002-March/002882.html
>
> Hope this helped,
>
> Jan Schenkel.
>
> =====
> "As we grow older, we grow both wiser and more foolish at the same 
> time."  (La Rochefoucauld)
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>




More information about the use-livecode mailing list