[comp.sys.mac.hypercard] The card that would not die!

NUAPPLE@NDSUVM1.BITNET (M. G. Stinnett) (08/03/89)

I had a little problem the other day with a card.  It didn't do anything,
but I couldn't kill or delete it, either.

There was a card script:
on openCard
   global name,class
   ask "What is your name?" with "Type your name here"
   ask "What class?" with "Type your class name or number here"
   go next
end openCard

Of course, when you hit the card, it would ask both questions, the go
next.  Useless because tho it asked the questions, it did nothing with
the answers.

But the worst thing was that I couldn't get at the script to change it.
No matter which way I went at it, sending messages, trying to trap the
openCard message, sending messages to the card telling it to delete
itself, it would always pop the two dialogs, go next, and then execute
the message.  Fortunately, I was working on a copy of the stack, so all
the damage I did to the other cards didn't matter.

Finally, out of desperation, I used FEdit to find the "go next" bit on
the disk sector and wrote over it, changing it to "-- next".  This
crude method worked, with one problem.  When I opened the stack in
HyperCard after the mod, the "Can't Modify" box was checked, and would
not allow itself to be unchecked.

I made a copy of the stack, and the copy did not have this feature, so
I was finally able to go in and edit the script of the card, ending two
or three hours of frustration.

Now the question:  Was there a better way?  Could it have been done from
within HyperCard?

--M. G.
who hates to nuts and bolts anything

sean@eleazar.dartmouth.edu (Sean P. Nolan) (08/08/89)

From anywhere else in Hypercard, type:

     edit script of card "xxx" of stack "yyy"
 
That will let you get at the script without it being automatically invoked.
Alternatively, you could have hit Command-. while at one of the dialogs and
it should cancel execution of the script at that point.

Hope it helps (and hope it works...)

--- Sean

sirkm@ssyx.ucsc.edu (Greg Anderson) (08/08/89)

In article <14907@dartvax.Dartmouth.EDU> sean@eleazar.dartmouth.edu (Sean P. Nolan) writes:
>From anywhere else in Hypercard, type:
>
>     edit script of card "xxx" of stack "yyy"

You could also solve the problem by setting lockMessages to true.  If you
do that, no openCard, idle or other messages will be passed to your stacks.
After you've fixed the damage, set lockMessages back to false.

As a general rule, openStack handlers should never cause HyperCard to go
to another card.  Such methods are too easy to throw into endless loops
(as the original poster discovered).

Just use a "next" button on the background.

  ___\    /___               Greg Anderson              ___\    /___ 
  \   \  /   /         Social Sciences Computing        \   \  /   /
   \  /\/\  /    University of California, Santa Cruz    \  /\/\  /
    \/    \/              sirkm@ssyx.ucsc.edu             \/    \/

Athos@cup.portal.com (Richard Eames) (08/09/89)

In article <2665NUAPPLE@NDSUVM1> NUAPPLE@NDSUVM1.BITNET (M. G. Stinnett) 
writes:
> on openCard
>    global name,class
>    ask "What is your name?" with "Type your name here"
>    ask "What class?" with "Type your class name or number here"
>    go next
> end openCard
> 
> Of course, when you hit the card, it would ask both questions, the go
> next.  Useless because tho it asked the questions, it did nothing with
> the answers.
> 
> But the worst thing was that I couldn't get at the script to change it.
> No matter which way I went at it, sending messages, trying to trap the
> openCard message, sending messages to the card telling it to delete
> itself, it would always pop the two dialogs, go next, and then execute
> the message.  Fortunately, I was working on a copy of the stack, so all
> the damage I did to the other cards didn't matter.

You could do this in the message box:  "Edit the script of cd <whatever>" 
.  That works fine and allows you to change the script without actually 
going to the card...

-Rick


##############################################  These thoughts are mine, not
#  "Anyltus and Meletus have the Power to    #  Apple Computer's.  Blame me,
#   put me to death, but not to harm me." -- #  not them.
#                  SOCRATES                  #
##############################################
GEnie:  R.EAMES2   CI$: 73677,2777

dlugose@ecsvax.UUCP (Dan Dlugose) (08/10/89)

In article <2665NUAPPLE@NDSUVM1> NUAPPLE@NDSUVM1.BITNET (M. G. Stinnett) writes:
>I had a little problem the other day with a card.  It didn't do anything,
>but I couldn't kill or delete it, either.
>
>There was a card script:
>on openCard
>   global name,class
>   ask "What is your name?" with "Type your name here"
>   ask "What class?" with "Type your class name or number here"
>   go next
>end openCard
>
>But the worst thing was that I couldn't get at the script to change it.
>
>Now the question:  Was there a better way?  Could it have been done from
>within HyperCard?

   I think I've found the solution.  Put this in the stack or
backgrouns script:
on domenu x
  if x is "next" then beep
  else
    pass domenu
  end if
end domenu
   
SO that go next will NOT go next, and you can edit the script, then
take out the "domenu script".  I tested it once.

Dan Dlugose
UNC Educational Computing Service

taylorj@yvax.byu.edu (08/12/89)

Greg Anderson suggests solving the problem by setting lockMessages to true.

I'm afraid this will do no good.  LockMessages (just like lock screen and
lockRecent) is reset to false as soon as an idle message is sent.  LockMessages
does NOT prevent idle messages from being sent.  The only place lockMessages
does you any good is inside a script.  As soon as the script stops executing,
lockMessages is set back to false.


Jim Taylor
Microcomputer Support for Curriculum   |
Brigham Young University               |   Bitnet: taylorj@byuvax.bitnet
101 HRCB, Provo, UT  84602             |   Internet: taylorj@yvax.byu.edu