chi@cit-vax.Caltech.Edu (Curt Hagenlocher) (07/05/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." > > I am interested in other peoples thoughts on this. In my opinion, the Resource Manager is the one of the best ideas implemented on the Macintosh. This is for many reasons, including the possibility of modifying programs without recompilation, but mostly for the extremely easy to use interface. I think that concept deserves its own sentence. The Resource Manager is just plain easy to use! The Mac is almost based around the Resource Manager. Windows, menus, palettes, icons, patterns, controls et. al., are all set up to work smoothly with it. Programs such as ResEdit allow one to create resources simply, and modify them with a minimum amount of effort. Things just don't get any easier! > 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 don't share this opinion at all. All sorts of gross data structures have to be dealt with, and vast amounts of code are required to set up anything other than the simplest window. All this can be replaced to just a one-line call to the Resource Manager: "Handle = GetNewStructureOfYourChoice(resource #)". As to your question about "the REAL world," every program I've looked at uses the Resource Manager for all these things. I think it's actually required by the Apple Thought Police - er, I mean the Interface Guidelines. This is so that programs can be easily modified to work, say, for Arabic and Kanji. Finally, your friend was joking about the preprocessor, wasn't he? :-) -- ...!ames!elroy!cit-vax!chi "Although we held the whip, you chi@cit-vax.caltech.edu know we were the real slaves." Curt Hagenlocher -XTC
awd@dbase.UUCP (Alastair Dallas) (07/06/88)
If you're writing a "real" Mac application, you want to end up with all of your string literals as resources, for translation. Likewise, people have come to expect that your menus will be resources, as well, for command-key customization. Last-minute tweaking is really much easier with ResEdit than with many full re-compiles. But just because you want to end up that way, doesn't mean it should be that way from the start. Many things are easier to do inline at first, to speed up turnaround time--to get something working quicker. Then, when you're real proud of yourself, take a day and strip out everything you can into resources. This is similar to the custom MDEF debate described in the great "Tear-Off Menu" article in MacTutor recently. The authors explain that Apple wants you to compile MDEFs as separate projects that create code resources that you link with your main project. The problem is that this is a real pain when you're first debugging, so the authors explain a way to get around this and leave the code in your main project until you're sure it works. The IBM-PC trend is toward resource file concepts, by the way. I just got a C library called "C-Worthy" from the Programmer's Shop which includes facilities for creating and maintaining separate resource files of string literals simply for ease of translation and last minute editing. Without getting specific, I think I can say that we lean toward this approach on dBASE IV. So tell your friend that this is not what the preprocessor is for. Turning your back on any facility that the target machine provides is definately not "real world." /alastair/