Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!decwrl!nsc!voder!apple!lsr From: lsr@Apple.COM (Larry Rosenstein) Newsgroups: comp.sys.mac.programmer Subject: Re: Design Philosophy Message-ID: <13346@apple.Apple.COM> Date: 5 Jul 88 18:36:10 GMT References: <434@dogie.edu> Reply-To: lsr@apple.apple.com.UUCP (Larry Rosenstein) Organization: Advanced Technology Group, Apple Computer Lines: 49 In article <434@dogie.edu> terranova@vms.macc.wisc.edu writes: > A friend of mine recently expressed his disapproval of the standard >Macintosh program design. Rather than putting windows, menus, icons, >def procs, strings, controls, etc. in resources he would prefer to >hard code everything into the program and make heavy use of #define >statements. He would change the #defines instead of the resources. >"That's why they made the preprocessor." The main motivation for using resources was to allow programs to be customized for international markets without recompiling them. All that you need to localize a progam for France, for example, is the original English version and a resource manipulation tool (ResEdit, etc.). This is very important for commercial applications, because non-US markets are significant, and it is impractical to recompile the code for each country. It is also convenient to place user configuration information in resources. Because the Resource Manager looks for resources along a path of open files, you can put the default resource in the application, and override the default with a resource in the preferences file, or in the document file (to override on a per-document basis). In many cases, placing this information in a resource (as data) takes up less space than spcifying the equivalent information programmatically. The more information you put in the resource the more this savings will be. Imagine creating a dialog box programmtically vs. specifying a dialog template. The only disadvantage of using resources is that it requires another step in the application build process. On the other hand, once you have the resources defined, it is not necessary to rebuild them. If you embed the equivalent information one of your code files, it will be rebuilt whenever that code file is recompiled. I can see how it might be easier to get things running without using resource if you were using Lightspeed C, because LSC doesn't have a resource compiler/editor integrated in the environment. Unless you were using MultiFinder, you would need to exit LSC to create the resources. Another factor in using LSC is that compilations are so fast, that it doesn't matter if you have to recompile a file to change the position of a window. In MPW, however, it takes less time to recompile your resource file than recompiling and relinking your code. Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 27-AJ Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr