daniel@dolores.Stanford.EDU (Daniel Weise) (08/28/90)
I've never used hypertalk before, and am trying to build what will end up being a very large application (5000 cards). Therefore, I want to break it up into many different stacks. The problem is that I can't figure out how to send a message with parameters to a card not in the current stack. For example, I need to say something like send drawcharacter left, right, top, bottom to cd "mouth" of stack "Lesson 1". There seem to be two problems: 1) SEND won't allow parameters and 2) you can't send a message to a card not in the current stack. I've hacked up some kludges using global variables, trampolines, go cd's, and "this cd"s, but I want to know if maybe I'm just missing something. I really can't believe you can't send messages with parameters! And that you can't send messages! (I've used lots of other OO langauges.) Am I doing something wrong or is this a well recognized problem that's fixed in HC 2.0?? Daniel Weise
bc@Apple.COM (bill coderre) (09/12/90)
Dan Weise: |I've never used hypertalk before, and am trying to build what |will end up being a very large application (5000 cards). Therefore, |I want to break it up into many different stacks. The problem is |that I can't figure out how to send a message with parameters to |a card not in the current stack. First off, please remember that Hypercard is wonderful at managing "medium size" stacks like the one you're writing. There's no reason -- from Hypercard's point of view -- to split up the stack. But, if you have your reasons, you will be disappointed to know that what you want to do is not built-in-supported in Hypertalk. You'll have to write a handler to lock the screen, go to the right spot, send the message, get the result, and return. You'll also have to worry about making sure the other stack is initialized correctly and that the calling stack can handle the burden of being closed and reopened. In other words, it ain't easy, and that's the way it is. Hypercard 2.0 won't solve all your problems for you, but it does provide some help in the form of the "start using" command. That command adds the stack scripts and XCMDs/XFCNs of the given stack to the message routing, between the current stack and the home stack. One way I use it is to say "start using groupies" when I need Sioux Atkinson's k00l object grouping routines. You might use it to build libraries of insanely great handlers that you can invoke with NO recoding, overhead, or hassle. Just turn 'em on like a faucet. Please note that there are two ways of sending a message: either by simply writing it as a handler or function handler invocation, or by using the "send" command. The former method allows arguments to be passed and values to be returned, whereas the latter does not. The only real difference is that the first method always sends the message to "me," whereas the latter allows you to specify the object of your fondest desire, as it were. bill coderre a private consultant, not licensed to voice official apple opinion.
DN5@psuvm.psu.edu (09/13/90)
Hi: Normally I wouldn't follow this up, but as I have been using this property extensively, I thought I'd correct a possibly accidental misstatement. In article <44723@apple.Apple.COM>, bc@Apple.COM (bill coderre) says: >Please note that there are two ways of sending a message: either by >simply writing it as a handler or function handler invocation, or by >using the "send" command. The former method allows arguments to be >passed and values to be returned, whereas the latter does not. The >only real difference is that the first method always sends the message >to "me," whereas the latter allows you to specify the object of your >fondest desire, as it were. > >bill coderre >a private consultant, not licensed to voice official apple opinion. Sorry, but you can use parameters with SEND. Several places in a stack that I have developed to do testing, I wanted to use DOMENU, even though I have a domenu handler in my stack which overrides all the fun things (including quit, and just about any other useful item). I did this full well knowing that I was breaking the interface, because I needed the security for my testing package. The line send "DoMenu Quit HyperCard" to HyperCard works fine. In other words, you can use parameters with send. This was tested with HyperCard 1.2.5, but not with 2.0 (because I'm not about to force the university to use HyperCard 2.0 without being able to test my stacks with the official 2.0 final that will actually be running, assuming that it will run from a network on a 1 meg SE). ()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()() D. Jay Newman ! All syllogisms have three parts, dn5@psuvm.psu.edu ! therefore this is not a syllogism. CBEL--Teaching and Learning Technologies Group
bc@Apple.COM (bill coderre) (09/14/90)
D. Jay Newman: |Sorry, but you can use parameters with SEND. |The line | send "DoMenu Quit HyperCard" to HyperCard |works fine. Touche. My language was insufficiently precise. But let's look at the fully-precise specification, shall we? send <send-message> to <destination> destination may be any HC object in the current stack -- cd, btn, fld, bg, stack, Hypercard -- or to another stack as an entity. You can also send to "me," "the target," and, in 2.0, an "xwindoid." send-message contains a message name -- either a system message or the name of an "on" handler, and may contain parameters. (ie. "MyHandler 5,6,foo", "openCard"). It may NOT contain a function call (ie. "MyFunction(5)" will fail). You can certainly send to a handler that calls a function, though. send is considered a "keyword" in Hypertalk, which means that it does not change "it" or "the result." It also does not actually "go" to the location of the object specified, so it does not send "openCard", etc. Its function is to inject the specified message into the message order at the object specified, so if that particular object cannot handle the message, it flows up the message-routing in effect at the time, until it hits Hypercard, which will conveniently discard system messages and complain about other messages. OK? bill coderre all this info is published in Winkler & Kamins, and as such does not constitute release of confidential information.