Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!shelby!polya!ali
From: ali@polya.Stanford.EDU (Ali T. Ozer)
Newsgroups: comp.sys.next
Subject: Re: A Spirograph for the NeXT machine:  My first NeXT program.
Message-ID: <8827@polya.Stanford.EDU>
Date: 28 Apr 89 22:25:55 GMT
References: <569@hydra.gatech.EDU>
Sender: Ali T. Ozer <ali@polya.Stanford.EDU>
Reply-To: aozer@NeXT.com (Ali Ozer)
Distribution: usa
Organization: .
Lines: 76

In article <569@hydra.gatech.EDU> roy@prism.gatech.EDU (Roy Mongiovi) writes:
>This is my first excursion into programming on the NeXT.  It uses vector
>addition to draw a "spirograph."  Since I'm not terribly familiar with
>the NeXT and it's objects, I can't say whether or not I'm doing things
>in the politicaly correct manner, but the program seems to work (with
>a caveat or two that I'll mention in a moment).

Thanks for the program! I haven't had a chance to play with it
yet (not near a NeXT machine), but will soon... Hope you don't mind some
comments in the meantime.

>This application was developed under 0.8, and doesn't use a .nib file.
>I haven't gotten 0.9 yet, so I have no idea if it will work with it or
>not.  At least it won't cause problems with the new interface builder.
>I didn't use a .nib file for two reasons.  First, I really don't think
>that the interface builder gives me enough control over objects.  I'd
>rather create a window with the right background color in its content
>view than have the interface builder create a window with a light grey
>background and then change the color during initialization.  

One way to control any object in any way you want it to make it an outlet
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.

This might seem inefficient (why create the window with a light gray
background and then have it change color at runtime) --- but it isn't.
Windows (in the server) are not created until they are actually brought on
screen, and this does not happen until your application's "run" method is
invoked. Thus at the time the setxxx: methods are being called, only the 
window object exists, not the actual window memory. So changing the color 
(and other parameters, like size, contentView, etc), is not expensive --- 
you are just changing some instance variables in the window object.

Keeping your interface in .nib files gives you great flexibility. You
needn't worry about your 0.8 .nib file not working in 0.9; although
0.9 .nib format is different than the 0.8 one, 0.8 .nib files can still
be read in by the loadNibFile: method. Interface Builder can also
read 0.8 .nib files (as well as 0.9, of course); it saves 0.9 format.

If you are worried about having to keep one or more .nib files around
with the executable (admittedly a pain when you copy/move the 
application around) 0.9 provides a solution to that: You
can now include .nib files (and any other data file you might need)
in Mach-O segments of your executable. It's very easy to open a stream
bound to data stored in a Mach-O segment; thus you can read any random
data from the executable itself. Of course, there are "convenience" 
methods such as "loadNibSection:," "newFromMachO:," provided to
make it real easy to read common forms of data (such as .nib files,
TIFF bitmaps, sound data, etc) out. 

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." Then, in your timed entry function, 
graph() in your case, you can invoke a method as shown below:

void graph (DPSTimedEntry te, double now, id obj)
{
  [obj someMethod];
}

This would allow you to access "obj"s instance variables in "someMethod,"
making it unnecessary to have the globals you have in Spirograph.m. (Objects
whose state is contained totally within their instance variables are a lot
nicer to deal with...)

In the graph() function, it seems like you used code from a C function 
generated by pswrap; is that the case? Such generated code might not be very
portable (and not very pretty either); you probably want to keep the original 
pswraps around... 

Anyway, thanks again --- Can't wait to try the program out.

Ali