Path: utzoo!mnetor!uunet!husc6!hao!ames!claris!apple!lsr From: lsr@Apple.COM (Larry Rosenstein) Newsgroups: comp.sys.mac.programmer Subject: Re: MacApp (was Prototyper vs. Doing it Yourself) Message-ID: <7745@apple.Apple.Com> Date: 21 Mar 88 22:46:28 GMT References: <3715@super.upenn.edu> Reply-To: lsr@apple.UUCP (Larry Rosenstein) Organization: Advanced Technology Group, Apple Computer Lines: 61 In article <3715@super.upenn.edu> mayerk@linc.cis.upenn.edu.UUCP (Kenneth Mayer) writes: > >come. My group has discovered several minor (and some not so minor) >bugs in MacApp. The MacApp team would like to hear about these, so that they can be fixed in MacApp 2.0. Send them to MacApp@Apple.COM. > MacApp, in addition, makes it very difficult to do things that you may >want to do, but was never in the original design. For example: it is >impossible to center dialog boxes dynamicly. That is, if you place a dialog >window in the center of MacPlus screen in your resource description file, >it will be in the upper left quadrant of a MacII display. Not pretty, and >NOT in accordance with Apple standards. And there is no workaround that we >have found. This is a problem with the Dialog Manager in general. The only complete workaround is to patch the NewDialog trap and modify the coordinates that are passed in there. The problem is that there are dialogs over which you have no control (eg, the print dialogs). MacApp exacerbates the problem by putting up dialogs itself. For application-specific dialogs, you can simply move the dialog window before you display it. (MacApp 2.0 has a totally rewritten dialog unit, which can automatically center dialogs if you choose. This dialog unit is a superset of the Toolbox Dialog Manager.) This still doesn't handle alerts, which will still be done using the the Toolbox. To handle these, you would have to read in the ALRT resource and modify the rectangle to center the alerts. It should be possible for your application to read in all the ALRT resoruces, center the rectangles, and make the resources non-purgeable. (For MacApp 2.0, it should be possible to put this code into MacApp.) >You may discover that the source code specific to your applicatio is smaller, >but that the overall source and object code is much larger. Object oriented >Pascal in MPW tends to be huge (a minimum of 100K). This is not true in general. There is nothing in Object Pascal (or object-oriented programming) that requires the code size to be excessively large. The MPW linker can strip out method tables that don't need to be there, which means you pay for the object-oriented features only when you use them. Even if you are talking about MacApp programs it is not true. Many people look at the size of their first MacApp program and don't realize that more than half of it is debugging code that is stripped out of the final version. (MacApp without debugging code is only about 50K.) Also, people compare a MacApp sample program with an equivalent non-MacApp sample, without realizing that the MacApp program does many more things. Unfortunately, it is difficult to throw out only the clipboard (or printing, or memory management, or ...) support in MacApp; we targetted MacApp for complete applications rather than small utilities. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr