duggie@jessica.Stanford.EDU (09/10/88)
I have an XCMD that uses several resources-- specifically, DITl, PICT, and ICON resources for dialogs. This had made some aspects of Hypercard's resource file behavior quite troublesome. When I launch hypercard from a stack, what apparently happens is that the stack resource file is opened, the OpenStack handler is called for that stack, this resource file is closed and the one for the Home stack is opened, other initialization gets done, and finally the original stack resource file is opened again. What this means is that if any initialization using resources from the first stack is done in the OpenStack handler, these resources are tossed away, leaving pointers to those resources aiming at random bits of memory. When you launch Hypercard directly or from the Home stack, whatever initialization needs to get done happens first, so the resource file is never closed after OpenStack. This lulled me into a false sense of security at first :-). I would prefer it if the resource file of a stack were not closed between OpenStack and CloseStack. It seems that instead, the initialization that needs to be done with the Home stack could be done first, and then the launched stack is opened and its OpenStack handler called. The other behavior I have noticed is that the CloseStack handler is called before the open file dialog for Open Stack is put up. If the user chooses cancel, OpenStack is called again. Unfortunately this means I have to deallocate and then reinitialize code that uses resources. I think CloseStack should not be called until the Open dialog has confirmed that the user does intend to go to another existing stack. For those who are wondering why I don't detach resources, the answer is that I do with some already. I would prefer not to sneak around behind the dialog manager's back detaching resources and then freeing them, or having several copies of large (20K) resources floating around int the application heap. Of course I could just get smart and not use the dialog manager :-). Have any other XCMD writers run into these types of problems? Any suggestions? Doug Felt Courseware Authoring Tools Project Sweet Hall 3rd Floor Stanford University Stanford, CA 94305 duggie@jessica.stanford.edu