Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!psuvax1!psuvm!cunyvm!byuvax!taylorj From: taylorj@yvax.byu.edu Newsgroups: comp.sys.mac.hypercard Subject: Re: Two (weird) HyperCard scripting problems; something to do Message-ID: <1018taylorj@yvax.byu.edu> Date: 14 Jan 90 20:48:01 GMT Lines: 49 You were on the right track when you looked at the startUp handler in the Home stack--it's part of the problem. The main difference between starting a stack from another stack or starting it (and HyperCard) from the Finder is that the startUp message is added. When you start up a stack from the Finder, the system messages are as follows: openStack openBackground openCard startUp The problem is that startUp is sent AFTER openStack. Because there is a handler for it in the Home stack, HyperCard temporarily leaves your stack to run the startUp handler. This causes the insertion point (I-bar) to go away, and also causes userModify to be set back to false. You'd think that the easiest way to get around the problem would be to simply intercept the startUp message, but that doesn't work (I'm not sure why). The way I solved this very problem is with the following scripts in the first card of the stack: on openCard click at the loc of card field "Name" set the userModify to true -- any other initial stuff end openCard on startUp global initialize put "do it" into initialize pass startUp -- let the Home stack do its thing end startUp on idle --it's not a good idea to put this in the stack script global initialize if initialize is "do it" then openCard put "did it" into initialize end if pass idle end idle This is the best solution I've come up with so far. If anyone else has a better solution, or knows more about why we have to do these silly things to make it work right, I'd appreciate hearing about it. Jim Taylor Microcomputer Support for Curriculum | Brigham Young University | Bitnet: taylorj@byuvax.bitnet 101 HRCB, Provo, UT 84602 | Internet: taylorj@yvax.byu.edu