jk3t+@andrew.cmu.edu (Jonathan King) (01/17/90)
Looks like the head of my last message got chopped off. Here's what I meant to say: Jeanne A. E. Devoto answers the question: > >I am surprised nobody (else I have missed it, in this case please ignore) > >has mentioned that send doesn't work with arguments (parameters) > >(hypercard 1.2.2 and below). Am I correct or am I missing something ? > > send message_name arg1,arg2 to card card_name and the message > > doesn't get sent ??? > > send message_name to card works. > > What you're missing is that the argument to "send" must be a string > (or an expression that evaluates to a string). In other words, the > syntax of the send keyword looks like > send <message> to <object> > The easiest way to make a multi-word expression into a string is to enclose > it in double quotes. This is the right answer, but I can't help pointing out that the original author's confusion stems from the fact that you CAN say send mouseuUp to button "pushMe" [Hypertalk Script Language Guide p. 74] where mouseUp is certainly *not* a string. This works because "quotation marks around the message are not required if the message is a single word." [HSLG p. 74] I assume that this "feature" was designed to help out novice programmers write simple scripts, but the only thing I have seen it do is frustrate the hell out people before they finally figure out what is going on. And now, if you fixed the "feature", everybody's scripts would break in weird places. This problem with strings/quotation is not limited to the "send" keyword by any means; it screws up object naming, too. Thus while you would expect enclosing an expression in quotes would force hypercard to consider the expression a string, this won't always happen. Thus HSLG p. 35 notes that card "1812" doesn't refer to the card whose *name* is "1812" but to the card whose *number* is 1812 in that stack. Or is that the id number...hmm, better look that up again, I guess. Admittedly, this doesn't get you into trouble as often, but I still don't think it's very consistent. Another senseless "gotcha" is the fact that Hypercard silently assumes that when you write 'field "foo"' that you mean 'background field "foo"'. I suppose this "feature" saves a couple of key strokes now and then, but I know that it can cause very subtle bugs. [And let's not forget the 'card field id 7' problem mentioned on p. 36 of the HSLG.] > >Since the basic message passing routine fails, HC can't be a OOP language. > > Uh, yeah. It is true that message passing works, but HC certainly lacks many desireable features that an object-oriented programming language could have. Like, say, user-definable objects with local instance variables. I'm sure I'm not the only person who dislikes having to kludge objects together with hidden card fields, or unencapsulated global variables, or other weird tricks. I'm not saying that Hypercard has to be Smalltalk or CLOS, but let's get beyond the real weirdness. I also get depressed when I know *exactly* what the new button should look like, and where it should be, but I still have to 'domenu "New Button" etc.' This is really bad when a user is waiting. [NB--I have been using icon buttons that the user can move around as chess pieces in one program, and as animated objects that a user can create at will in another--when do we get sicn buttons? This, too, is slightly kludgey, but I don't mind yet because it's pretty neat :-).] > >Selecting the drawing tool, then drag > >the pointer and change the tools selection doesn't seem to be a speedy > >interface (it looks like I can draw faster). I am implementing a sailing > >simulator and drawing boat courses and moving boat icons around. The speed > >issue makes me wonder whether I want to continue and simulate more than > >ONE boat. > > Changing between tools is pretty slow, although it is considerably faster > in 1.2x than in previous versions. You may want to consider using card- > flipping techniques in addition to (or instead of) drawing on the screen; > if the animation you need to do is simple enough, flipping from card to > card is quite a bit faster than drawing. This is also true, but you have to draw those pictures sometime, and unless you have an application where you know *exactly* what you need to show beforehand, card-flipping can't hide the time you need to draw things on a card (not on the screeen, right?) And card-flipping itself isn't always as speedy as you would like (although it usually does the job). Quickdraw is really quick, and PICTs can be replayed... but you can't show a pict without writing an XCMD, and I feel squeamish about doing that since HC should (in my opinion) control this sort of thing itself. MACL does a great job with this kind of thing, and Apple liked THAT product so much that it bought the company. > -- > ====== jeanne a. e. devoto ======================================== > jdevoto@apple.com | You may not distribute this article under a > jdevoto@well.UUCP | compilation copyright without my permission. > ___________________________________________________________________ > Apple Computer and I are not authorized | CI$: 72411,165 > to speak for each other. | AppleLink: SQA.TEST I really do like Hypercard, but I would just love to see Hypertalk mature into something that's really powerful and really elegant; a language that other programmers would envy. Give us the tools and we can build incredible things. jking (jk3t+@andrew.cmu.edu) [sorry for the garbled original message]