greg@harvard.ARPA (Greg) (11/18/85)
I am writing a desk accessory in which I would like to have my own custom window. Apparantly, the window tools are designed to let you put your custom window in a resource. Can desk accessories have their own resources in the system file? If not, how do I make my own type of window without making a resource? Secondly, since the window frame is rather complicated, I would like to keep track of some extra variables in windowdefsproc. Because I am only using one such window, I could probably do this with global and/or static variables. But I may wish to use several such windows at once in an application in the future. If I use static variables, then there will be a variable conflict, because the Window Manager will call the same routine for two windows of this kind. How do I get around this? -- gregregreg
awd@ut-ngp.UUCP (Andrew W. Donoho) (11/18/85)
Answers to your two questions: How can I use a custom windowProc from a desk accessory? Yes, Desk Accessories can have their own private resources, as described in the Resource Manager section of Inside Macintosh. However, the IDs that these "owned" resource can use restrict you so that you can not have a conventional "WDEF" resource for your window defProc. The best thing to do is to create the window using NewWindow or GetNewWindow and then replace the windowDefProc field with a handle your special window definition (this can be a resource handle, or just a normal handle: if it is a resource handle, LoadResource will be called each time it is dereferenced by the ROM). Where can I store special data for each window for a windowProc? There is a field in each window called dataHandle. This is intended to hold a handle (or any other 4 bytes) for the use of the windowDefProc. This means that the defProc should make a handle of the desired size and store it's globals there. By the way, LoadResource will be a no-op if the handle passed to it is not a resource or invalid. This is quite useful. Resource Manager routines, as a rule, are more tolerant of bad input than Memory Manager routines or even the other Toolbox routines. But don't make the mistake of passing NIL for the name of a resource in SetResInfo or AddResource. That is a common mistake (MDS Edit and the original RMover have or had this error). Darin Adler