mi@chyde.uwasa.fi (Matti Inkinen LST) (08/17/89)
Hello! I've just heard about ProtoTyper 2.0. Does it create c source code as my sources told me? How does it work (comments), please. Thanks in advance /-------------------------------------------------------\ | Matti Inkinen | e-mail | | University of Vaasa | mi@chyde.uwasa.fi | | Vaasa, FINLAND | | \-------------------------------------------------------/
steve@cpdaux.UUCP (Steve Lemke) (08/23/89)
In article <702@chyde.uwasa.fi> mi@chyde.uwasa.fi (Matti Inkinen LST) writes: }I've just heard about ProtoTyper 2.0. Does it create c source code as my }sources told me? How does it work (comments), please. Yes, it can generate either MPW "C" code or THINK "C" (formerly LightSpeed). It can also generate either flavor of Pascal (or even Turbo Pascal, though that may or may not continue to be supported by Prototyper). With Proto- typer, I was able to completely lay out a program I was to write, generate all of the windows, buttons, menus, alerts, and dialogs, and was also able to link them together and actually run my "program" from within Prototyper without generating a single line of code. Once convinced that it was right (or at least as close as I needed to be for the time being), I generated the THINK Pascal code, and have been adding in my little sections of code where Prototyper leaves comments like {add code here for this function}. Sure was nice to have it do all the Mac basics for me. -- ----- Steve Lemke ------------------- "MS-DOS (OS/2, etc.) - just say no!" ----- Internet: cpdaux!steve@apple.com GEnie: LEMKE ----- Or try: apple!cpdaux!steve CompuServe: 73627,570 ----- Quote: "What'd I go to college for?" "You had fun, didn't you?"
hoffman@ux1.cso.uiuc.edu (08/28/89)
Well, I've used the prototyper 2.0 also, and it does, in fact, create code for the Mac. But, the amount of redundant and unnecessary code it generates, it's not really worth it. The only thing I see prototyper good for is a tutorial to learn the routines in the first place (since Inside Mac isn't any good at it). For instance, if you want to learn how to add a list window to a dialog, use the prototyper to see what the code needs to do, but don't use that code. It's will generate tons of unreferenced local variables. Steve ___________________________________________________________________ | Steve M. Hoffman | email: hoffman@ux1.cso.uiuc.edu | | University of Illinois | internet: hoffman%ux1@uxc.cso.uiuc.edu | | Champaign/Urbana | uucp: uunet!uiucuxc!ux1!hoffman | |________________________| usmail: 515 Bach Ct. #24 | | I haven't a clue what | Champaign, IL 61820 | | I'm doing here | (217)/359-7448 | |________________________|________________________________________|
dave@PRC.Unisys.COM (David Lee Matuszek) (08/30/89)
In article <18000005@ux1.cso.uiuc.edu> hoffman@ux1.cso.uiuc.edu writes: > >Well, I've used the prototyper 2.0 also, and it does, in fact, create >code for the Mac. But, the amount of redundant and unnecessary code it >generates, it's not really worth it. The only thing I see prototyper >good for is a tutorial to learn the routines in the first place >(since Inside Mac isn't any good at it). For instance, if you want >to learn how to add a list window to a dialog, use the prototyper to see >what the code needs to do, but don't use that code. It's will generate >tons of unreferenced local variables. > >Steve I have to disagree, a little. Yes, the code is redundant; in particular, for each window you define, it creates a standard package of routines that are tailored to that window, and often the tailoring is minimal. Also, it puts lots of hooks in for your code--probably more than you will use. This may be esthetically displeasing to those who emphasize efficiency in their programs. I'm not one; my time is more important to me than the computer's time. Now if the performance of the program were significantly impaired, I would want to bring it up to snuff, but: (1) It would take an awfully complex interface before the amount of extra memory required became a problem; (2) Milliseconds really don't matter much when interfacing to a human; and (3) You have to hack the code anyway (to add your stuff in), and I haven't found it difficult just to discard portions of the code I knew I wouldn't need. I'd be happy for SmetherBarnes to work on producing more efficient interface code. But I think it's more important that they work on producing a cleaner interface between their generated code and my application code; it's currently more work than it should be to reconnect my application to a modified human interface. As for "tons of unreferenced variables"--I don't know what you mean. The Think Pascal code that it generates for me contains only (1) variables that are clearly used in its code, and (2) variables that I am likely to want to reference in my application. Maybe I missed some, but if so, I don't care--the code is error-free and does the job. I think it's a matter of programmming style. Prototyper code tries to be relatively clear, at the expense of efficiency. I don't need the efficiency, but at this stage in my learning to program the Mac, I do need the clarity. So I like it. -- Dave Matuszek (dave@prc.unisys.com) -- Unisys Corp. / Paoli Research Center / PO Box 517 / Paoli PA 19301 -- Any resemblance between my opinions and those of my employer is improbable. * 20th anniversary? Yeah, but it's 17 years since the LAST man on the moon! *