ftp.nice.ch/peanuts/GeneralData/Usenet/news/1989/CSN-89.tar.gz#/comp-sys-next/1989/May-Jun/A-Spirograph-for-the-NeXT-machine:-My-first-NeXT-program.

This is A-Spirograph-for-the-NeXT-machine:-My-first-NeXT-program. in view mode; [Up]


Date: Sun 02-May-1989 15:45:31 From: Unknown Subject: Re: A Spirograph for the NeXT machine: My first NeXT program. In article <8827@polya.Stanford.EDU>, ali@polya.Stanford.EDU (Ali T. Ozer) writes: > of something; say your application object. Then, when the setxxx: method > is called, with a handle to that freshly created object, you can go ahead > and change any parameters you want. This should give you full control > over any objects created by Interface Builder. > ... > On another note... If you wish to refer to instance variables in a > timed entry function, you can simply invoke a method from the timed entry: > When installing the timed entry, pass "self" (or whatever the id is) to > DPSAddTimedEntry as your "user data." Thanks for the comments, Ali. The program isn't worth a whole lot, but it does click buttons, use postscript to plot, and use timed entries, so I thought it might be of interest to some of the folks out there. I decompiled the interface mostly because I didn't want separate .nib files floating around. It doesn't seem like a good way to keep a finished "product." I agree that it isn't easy to modify once you do that (plus, it's a hassle because of how badly the 0.8 IB botches the interface decompilation). Being able to include the .nib file in the executable will be great. However, it seems to me that once you decompile and start adding code to the stubs that IB gives you, it's impossible to cleanly change the interface except for cosmetics. If I add any new methods or outlets I have to edit in the appropriate code to the already decompiled source since decompiling again will destroy my code. But that's a relatively minor hassle since I should do a good job of designing the interface before I start coding anyway. I did things the way I did in Spiro (with globals, etc.) because I don't like having to use gratuitous function calls. I suppose it shouldn't bother me because they aren't nested in loops, but I'd be a lot happier if objective-c methods and c function fit together better. I was SERIOUSLY disappointed to discover that I cannot use those nice inline functions in math.h from objective c. It seems a real shame that the GNU c compiler allows direct access to the math coprocessor instructions but the objective c prevents it. Roy

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.