terranova@vms.macc.wisc.edu (07/05/88)
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? What's
it like in the real world (outside a university)? Are there any major
trends in this type of design philosophy?
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).
Comments, anyone?
------------------------+------------------------------------------------
John C. Terranova | I'd start a revolution, but I don't have time.
CS, BS to be | --Billy Joel, "Close to the Boarderline"
------------------------+------------------------------------------------
I speak for myself and all those listed below. And no one else.
1)
2)
3)leonardr@uxe.cso.uiuc.edu (07/05/88)
terranova@vms.macc.wisc.edu(John Terranova) in comp.sys.mac.programmer >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? What's >it like in the real world (outside a university)? Are there any major >trends in this type of design philosophy? > > 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). > >Comments, anyone? > Always comments on the net!! There are basically two really good reason for using resources over hard coded strings, etc. 1) You can edit them without having to recompile! 2) Other people can edit them without having access to the source code! This to me is the most important. As a programmer who does a lot of work in inter- nationalization of software, I have no need for the original source code. All I need is the program itself and ResEdit. I can then go in and change all of the textual items to the language that I am localizing for. No compiling!! As far as using resource any harder than using hard coded values. I have found the for many resource types, keep them as resource is MUCH easier than hard coding them. Dialogs and Alerts are two of the best examples. I, for one, do not like the idea of having to create a DITL on the fly!! And the standard Alert call only takes a ResID, so you need a resource for that one. Strings on the other hand are, in many cases (especially in C) easier to work with as defined items, but how could I go and change it to French without the code? +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + MacNET: MACgician + + Delphi: MACgician + + + + + +---------------------------------+-----------------------------------+
lsr@Apple.COM (Larry Rosenstein) (07/06/88)
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
blm@cxsea.UUCP (Brian Matthews) (07/06/88)
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
chow@batcomputer.tn.cornell.edu (Christopher Chow) (07/06/88)
In article <2425@cxsea.UUCP> blm@cxsea.UUCP (Brian Matthews) writes: |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. In the Macintosh market, is this (the "much" bigger part) really true? How numerious are Macs in Europe/Asia/Africa when compared to the US? I'm not sure about Asia and Africa, but I seem to recall that in Europe Macs cost at least twice that of their American counterparts. Somehow, with Apple's foreign market pricing, I'm not sure if the non American market is that large. Anyway, this is just my guess. Does anyone have the data to show if I'm right? Christopher Chow /---------------------------------------------------------------------------\ | Internet: chow@tcgould.tn.cornell.edu (128.84.248.35 or 128.84.253.35) | | Usenet: ...{uw-beaver|decvax|vax135}!cornell!batcomputer!chow | | Bitnet: chow@crnlthry.bitnet | | Phone: 1-607-272-8014 Address: 107 Catherine St, Ithaca NY 14850 | | Delphi: chow2 PAN: chow | \---------------------------------------------------------------------------/
ack@eleazar.dartmouth.edu (Andy J. Williams) (07/07/88)
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." You would then have to compile seperate versions for each language. To enable someone in another country to use your program, you would have to compile a brand new program to do this. It is a piece of cake to go through resources and change them to be what you want them to be, in fact it would be trivial to write a program to go through all the String resources and ask you to change each one. No mucking with ResEdit. On another level, it separates the processing from the display. Things which get shown on the screen (dialogs, windows) are all defined here while the routines (code and such) are defined elsewhere (incidently, the code gets compiled into resources anyway) It allows the user access to the display and some control over it (although some program licenses say you cannot change this at all). It also places the design of display in a different realm. When I write a program, I do not need to muck with the display things. I design my interface on paper, or hypercard, then I create them in resedit. From then on, it is done. I just write my code to use the resources when displaying or getting info from the user. It seems to me a cleaner way to program. >------------------------+------------------------------------------------ >John C. Terranova | I'd start a revolution, but I don't have time. > CS, BS to be | --Billy Joel, "Close to the Boarderline" >------------------------+------------------------------------------------ -Andy Andy J. Williams '90 |Ack Systems: ack@eleazar.dartmouth.edu| _ /| Software Development +--------------------------------------+ \`o_O' ACK! Kiewit Computation Ctr |Hello. Set $NAME='Iinigo Montoya' You | ( ) / Dartmouth College |kill -9 my process. Prepare to vi. | U
nick@lfcs.ed.ac.uk (Nick Rothwell) (07/07/88)
In article <13346@apple.Apple.COM> lsr@apple.apple.com.UUCP (Larry Rosenstein) writes: >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. > ... and others ... Surely a better reason is that you can use development tools to build these parts of your application, instead of having to do it by hand. If you want you program to have some icons, then fire up an icon builder, draw it, and paste it in as a resource. Ditto for pictures, characters, ... I wrote a synth voicing program for my old computer, and it required 32 intricate pictures of connected boxes containing numbers (DX7 algorithms, some of you might guess...). And I had to generate the bitmaps BY HAND! It took hours and hours. Had I a bitmap application, or MacDraw or something, that would have been a few minutes, and they would have been better, and I would have had the option to move/change/resize them. You wanna build all your graphical entities using #define and hex?? Be my guest... > Larry Rosenstein, Object Specialist Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...while the builders of the cages sleep with bullets, bars and stone, they do not see your road to freedom that you build with flesh and bone.
leonardr@uxe.cso.uiuc.edu (07/07/88)
chow@batcomputer.tn.cornell.edu(Chris Chow) in comp.sys.mac.programmer >In article <2425@cxsea.UUCP> blm@cxsea.UUCP (Brian Matthews) writes: > >|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. > >In the Macintosh market, is this (the "much" bigger part) really true? How >numerious are Macs in Europe/Asia/Africa when compared to the US? I'm not >sure about Asia and Africa, but I seem to recall that in Europe Macs cost >at least twice that of their American counterparts. Somehow, with Apple's >foreign market pricing, I'm not sure if the non American market is that >large. > Whether the 'non-US' sales are larger than the US sales, I do not know exactly. What I do know is that there are A LOT OF MACINTOSHS sold in other countries. If you want numbers, call Apple. But I have seen the figures before and know that they are out there. The largest target areas are Europe, Japan, and the Middle East. (ie. the reasons why the Japanese, Arabic, and Hebrew operating systems came first!) where many macs are sold. If you think about it, the Mac is really the computer of choice in many of these countries since it give them their native language in a very nice manner as well as the international business language- English. Most other machines that support foreign languages support only one or two (The native language and maybe English) while the Mac can do multiple languages which is handy in the middle east. Anyway, this is an IMPORTANT market and should be seriously considered. (Hey Jordan, How'd I do :-) +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + MacNET: MACgician + + Delphi: MACgician + + + + + +---------------------------------+-----------------------------------+