Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!ssc-vax!cxsea!blm From: blm@cxsea.UUCP (Brian Matthews) Newsgroups: comp.sys.mac.programmer Subject: Re: Design Philosophy Message-ID: <2425@cxsea.UUCP> Date: 5 Jul 88 20:23:19 GMT References: <434@dogie.edu> Reply-To: blm@cxsea.UUCP (Brian Matthews) Organization: Computer X Inc. Lines: 81 terranova@vms.macc.wisc.edu writes: |Greetings, | 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." | I am interested in other peoples thoughts on this. Aside from |being able to modify parts of the program without recompilation, what |advantages are there to putting everything into resources? What |disadvantages are there to having all code with no other resources? Some reasons to use the resource manager: 1. As you state, there's no need to recompile to localize a program. Also, even if your friend never plans on producing non-English versions of his programs, that doesn't mean that someone else might not. With resources, anyone with the program and a resource editor (at least 3 of which exist that I know of) can do the localization. Without resources, whoever does the localization has to have the source code, a compiler appropriate to the language and dialect the source code was written in, and enough knowledge of that language and dialect to be able to make the changes and still have some small hope that the application will still function. 2. Even if someone doesn't want to localize, it's quite common to add or change command key equivalents on menu items, move dialog boxes about, etc. I do this all the time, and it wouldn't be possible if the software didn't use resources. Again, even if I could get the source (which I most certainly can't for things like the Finder, Excel, etc.), I certainly don't want the vast array of compilers I would need. 3. Because resources can be released or purged so as to not take up memory, your application will generally use less memory if it makes proper use of resources. Consider error message strings. Putting the strings in the code means that they are sitting in the Mac's memory whenever your application is running, even though they may never or only rarely be used. If they're in resources, they only get pulled into memory the few times they're needed. Same with dialog and alert templates, windows, pictures, etc. 4. Other applications can access the data your program uses if it's in resources. The most obvious example is the Finder. The Finder can grab the icon and version string (in System 6.0) from an application because they are stored in resources. If they're stored as part of the application's code, the Finder won't know where to look, so it won't be able to display anything for that application. |What's |it like in the real world (outside a university)? There are very few commercial applications that don't make full use of resources. The only one I can think of is from a big software company in Redmond, WA. Other than that, all commercial applications, and most shareware/freeware/public domain applications use resources. Resources certainly aren't just curiousities that only Apple software uses. | His method is simpler to get some code running. In fact, I use |quite regularly for this purpose. Then, once the code runs the way I want |it, I move data and def/filter procs into a resource and change NewControl() |to GetNewControl() (for example). I suppose this is a matter of taste, but I find it's much easier just to use resources from the start. Getting menus, dialogs, windows, etc. to look right is much easier to do by twiddling with them in ResEdit and actually seeing what they'll look like than compiling some code, making some changes, compiling some code, making some changes.... Also, if you care about testing your software, you'll have to retest everything once you move to resources, so why not just start there? Also, I don't care how fast your compiler compiles, the less source it has to compile, the faster it will do so. It's clear that if your application (or computer) supports languages other than English (and scripts other than Roman), you have a much bigger potential market. Apple recognized this, and came up with a very clean solution to the problem, namely resources. -- Brian L. Matthews blm@cxsea.UUCP ...{mnetor,uw-beaver!ssc-vax}!cxsea!blm +1 206 251 6811 Computer X Inc. - a division of Motorola New Enterprises