er225711@unix.cis.pitt.edu (Martin NMN Thurn) (02/09/91)
We are "fixing" our stackware so that it will run on CD-ROM. We are using (and we must use) HC 1.2.5 and KanjiTalk 6.0.5. We got the Lock Disk cdev from Apple, but when we lock the disk and open HyperCard, it does nothing and exits back to the Finder. Are we doing something wrong, or does 1.2.5 not work on a locked volume? Thank any and all for suggestions. --Martin Thurn er225711@unix.cix.pitt.edu
ollef@sics.se (Olle Furberg) (02/09/91)
In <89373@unix.cis.pitt.edu> er225711@unix.cis.pitt.edu (Martin NMN Thurn) writes: >Are we doing something wrong, or does 1.2.5 >not work on a locked volume? Thank any and all for suggestions. This was discussed 6 months ago, Martin Gannholm then answered (in article <10286@goofy.Apple.COM>): >In HyperCard 1.2.5 and earlier Bill made a call to UnloadScrap to free up >the memory that the clipboard may be taking. If this returned an error >code (which will happen if the Scrap Manager can't write to the Clipboard >file), HyperCard would quit. Silly, eh? > >Well guess what? We thought it was silly too, and "fixed" it in 2.0. You >should be able to run HyperCard 2.0 with a locked startup disk. As far as I know there is no patch available for HC 1.x to get around this, the only solution seems to be to upgrade to HC 2.0 . If you have your stacks on a CD, the "set usermodify to true" makes them just as available for HC 1.* as for HC 2.0 . /Olle
John_Miller@mindlink.UUCP (John Miller) (02/11/91)
Yes, HyperCard 1.2.5 will work fine on a locked disk. > We are "fixing" our stackware so that it will run on CD-ROM. > We are using (and we must use) HC 1.2.5 and KanjiTalk 6.0.5. > We got the Lock Disk cdev from Apple, but when we lock the > disk and open HyperCard, it does nothing and exits back to > the Finder. Are we doing something wrong, or does 1.2.5 > not work on a locked volume? Thank any and all for > suggestions. > > --Martin Thurn er225711@unix.cix.pitt.edu A previous reply has already explained that the problem is not that HyperCard is locked but rather that the system disk is locked. HyperCard 1.2.5 (that is, the application itself) and stacks can reside on locked disks. The LockDisk cdev is overkill. Ignoring performance issues, you have to make sure that your stack will work when it is read-only. You can do this by using the "Can't modify" option in the Protect Stack dialog box. An alternative I prefer is, during testing, add the following statement to your openstack handler. set the cantModify of this stack to (the optionKey is up) When you open the stack without holding down the option key, the stack will be locked and you can test for compatibility problems. When you find a problem, you can go home and then, holding down the option key, go back. The stack will then be unlocked and you can fix the problem. Some other things to keep in mind 1) Do not assume that the user will be using the Home stack on the CD-ROM 2) If you need to use the userModify property, you have to trap it in both the openStack and startup handlers. The startup handler should send the startup message to the Home stack and then set the userModify property. If you don't do this, you stack will not work if it is the startup stack. This is related to the startUp/openstack message sequencing problem in 1.2.x. ---------------------------------------------------------------------- John Miller (604) 433-1795 Symplex Systems AppleLink (rarely) CDA0461 Burnaby, British Columbia Fax: (604) 430-8516 Canada usenet: john_miller@mindlink.uucp ----------------------------------------------------------------------
John_Miller@mindlink.UUCP (John Miller) (02/11/91)
> 2) If you need to use the userModify property, you have > to trap it in both the openStack and startup handlers. > The startup handler should send the startup message > to the Home stack and then set the userModify property. > If you don't do this, you stack will not work if it is > the startup stack. This is related to the > startUp/openstack message sequencing problem in 1.2.x. To clarify this a bit, the userModify property is a global property that is reset each time a new stack is opened. The messaging sequence in HyperCard 1.2.5 sends the openStack message before the startup message. Your openStack handler can set the userModify, but the standard HyperCard startUp handler jumps to the preferences card (with locked screen) and then jumps back. This switching between stacks resets the userModify property. The standard startUp handler does not restore the userModify value.