When running a new XCMD, check the result of the command. Try placing this
statement into the script after executing the command:
"Put the result into the message"
Here are some possible problems and their solutions when the system locks
up:
1) The memory management system is purging needed data, because the XCMD
has not taken precautions to protect it.
2) The XCMD has broken the master pointer block, and the problem is not
uncovered until some random, future action.
3) The application stack has become fragmented causing an out-of-memory
error, because the XCMD has allocated memory, locked it down, and has not
removed the data after it was finished.
4) There just is not enough memory available.
There are several ways for XCMDs to crash. Almost all are due to bad
programming and trying to use HyperCard in ways for which it was not designed.
Anyone using an XCMD needs to test the XCMD in a stack by itself and slowly add
and execute other XCMDs. Any one of them may be fragmenting the stack,
corrupting the master pointer block, or using up memory by leaving data
floating around.
Apple does not support extensions that are not part of the HyperTalk
language. The ability to add extensions has been created so that programmers
can enhance their stacks. However, each programmer must take the
responsibility to check for errors and report any problems to the
user when writing the XCMD or XFCN. Programmers who are using
extensions from unknown sources must take on the consequences.
Finally, a user's needs may not be appropriate for the capabilities of
HyperCard. There are some supported XCMDs, like those available within
legitimate HyperCard software products. We suggest HyperTalk programmers
use only those XCMDs that they are confident with or that are supported if
any future problems develop.
There are many other programming environments that support and handle
advanced programming requirements. HyperTalk is not meant to be a
replacement for programming languages like Pascal or C.