> that's why i don't use nib files honestly.

Signature
Michael Ash
Rogue Amoeba Software
> > These instructions are great! would you mind sending instructions on simply
> > launching a class when the main program launches? that's the only part i haven't
[quoted text clipped - 8 lines]
>
> http://www.cocoadev.com/index.pl?CocoaBooks
and what happens if i already HAVE the books and they still make no sense?
they are good for taking up room on the shelf but...
> You've been posting in here for well over a year and your understanding is
> still extremely weak. Your question isn't even sensical ("launch a class"
> is meaningless)
ok, let me make myself a bit more clear... i know i'm not that good at expressing myself
to all of you so let me explain what i'd like to know...
you run textedit or any basic app that you made using nibs and you can get something working
go to the file menu and select new and you got a new window and the initialization routine for
that window takes over and you start seeing things happen (or not).
now you want to run this game called halo or age of mythology. none of them require the user
to select new from the file menu to start their games.
i can handle my way around the nib files myself if i simply knew how the app starts up.
NONE of the books i've seen even remotely describe the startup process for an app (what
is loaded, when it's loaded, where your app startup routine goes)
do i simply write (take an app called "santa.app" as an example) a class called santa and
have that's initialization routine initialize my stuff, compile it ant it works?
i actually tried that aspect and it was a no-go
you all keep pointing me to a comprehensive list of books which i have no interest in buying
the whole set (nor do i have the money to buy the set). give me a book name and chapter my
questions would be answered by and i'll be happy to read it and if i don't have it, i'll buy it.
> > that's why i don't use nib files honestly.
>
> This is very bad. Cocoa is built around nibs in much the same way that
> UNIX is built around files or lisp is built around conses. You may be able
> to avoid using them, but you're fighting the system at a deep level and
> you will suffer greatly for it. Making such a gigantic design mistake
i see, having real-time menus that change with the contents of folders or other stuff
is against the "natural order" right? real-time button windows that have their pictures
change depending on data received is also against the natural order? Writing windows and
other stuff that LOOKS like it came from a nib file is easy to program NOW (i must admit,
earlier i had one heck of a time getting everything to work). since i mainly write an
expander for somebody else's work instead of an app, i didn't think nibs would work so i
didn't even try it. now that i need to write my own app, i would like to at least TRY the
suggested way of doing things. pardon me for asking and taking up so much of your time.
i was under the mistaken impression that this was the newsgroup comp.sys.mac.programmer.help
where you could ask questions without being blasted by folks calling you an idiot.
Robert Dell
Michael Ash - 29 Dec 2006 03:11 GMT
>> > These instructions are great! would you mind sending instructions on simply
>> > launching a class when the main program launches? that's the only part i haven't
[quoted text clipped - 11 lines]
> and what happens if i already HAVE the books and they still make no sense?
> they are good for taking up room on the shelf but...
Then you need to start thinking about what you're doing wrong. Maybe it's
a simple matter of devoting more effort, or maybe you need to look more at
examples and less at texts, or maybe you need to invest in an actual
real-world class. I don't know what your learning style is so I don't know
what you need to do, but clearly whatever it is you're doing now just
isn't working.
>> You've been posting in here for well over a year and your understanding is
>> still extremely weak. Your question isn't even sensical ("launch a class"
[quoted text clipped - 17 lines]
>
> i actually tried that aspect and it was a no-go
This is what I had guessed at what your question meant, as I indicated in
the parts of my message which you snipped. My point with the part you
quoted was simply that you're so confused your terminology makes no sense.
I realize that in some respects it's just semantics, but in a very real
sense if you make statements like "launch a class" then that means you
have, at best, an extremely shallow understanding of the fundamentals.
> you all keep pointing me to a comprehensive list of books which i have
> no interest in buying
> the whole set (nor do i have the money to buy the set). give me a book
> name and chapter my
> questions would be answered by and i'll be happy to read it and if i
> don't have it, i'll buy it.
I'm sure that *any* book which describes how to build a Cocoa application
will tell you how to execute code on application startup.
>> > that's why i don't use nib files honestly.
>>
[quoted text clipped - 8 lines]
> have their pictures
> change depending on data received is also against the natural order?
No. When did I say that this was the case? It is possible to write code
that both uses nibs and dynamically changing content. In fact, it is
easier to write this code than it is to write the equivalent code without
nibs.
You are imagining constraints ("no dynamic content with nibs") which don't
actually exist, simply because you haven't been able to figure out how.
> Writing windows and
> other stuff that LOOKS like it came from a nib file is easy to program
[quoted text clipped - 4 lines]
> nibs would work so i
> didn't even try it.
It really depends on what the stuff you're working with does. If it wants
to manually position every single button and field, yeah, nibs are pretty
much pointless. But if you have some freedom in building your own UI then
nibs are the way to go.
> now that i need to write my own app, i would like
> to at least TRY the
> suggested way of doing things. pardon me for asking and taking up so
> much of your time.
The suggested way of doing things is to use nibs. The suggested way of
doing things is also to learn the basics on your own and use newsgroups
and other resources as a place where you can ask hard questions when you
need expert help. Discovering applicationDidFinishLaunching: is not
something that requires expert help.
> i was under the mistaken impression that this was the newsgroup
> comp.sys.mac.programmer.help
> where you could ask questions without being blasted by folks calling
> you an idiot.
The first occurrence of the word "idiot" in this thread is right there in
your message, as far as I'm aware. If you don't like the tone of my post
then that's fine, some people just can't handle having their deficiencies
pointed out, but don't just make up things to make me look bad.

Signature
Michael Ash
Rogue Amoeba Software
Santa Claus - 29 Dec 2006 12:29 GMT
> It really depends on what the stuff you're working with does. If it wants
> to manually position every single button and field, yeah, nibs are pretty
> much pointless. But if you have some freedom in building your own UI then
> nibs are the way to go.
i agree, that's one of the main reasons i don't want to change one of my
windows with 14 buttons, dividing each one into 4 buttons (a daunting task)...
David Phillip Oster - 29 Dec 2006 03:32 GMT
> do i simply write (take an app called "santa.app" as an example) a class
> called santa and
> have that's initialization routine initialize my stuff, compile it ant it
> works?
1.) Create a New Cocoa Application Project in Xcode.
2.) Create a new class file. Name it MyApp.m Edit the top line of the .h
file so that it reads:
@interface MyApp : NSApplication
{
}
....
that is, inherit from NSApplication instead of NSObject
3.) This is the tricky part: Open the project's Info.plist and change the
value of the NSPrincipalClass <key> from NSApplication to MyApp
4.) In MyApp.m, add:
@implementation MyApp
- (void)awakeFromNib {
NSLog(@"Hello World");
}
@end
Run it and verify that you get control, that HelloWorld shows up in the
Xcode "Run Log" window (if running), or the Xcode "Console Log" window,
(id debugging). Now you can do what initialization you like.
------------------------------
More traditional would be to create a subclass of NSObject, open
MainMenu.nib, read the class .h file into the classes tab, instantiate
your class, and in the instances tab <Control>-Drag from File'sOwner to
your instance, and connect it as the app's delegate.
Once again, put your code in your class's
- (void)awakeFromNib {
}
------------------------------
Look at other people's sample code. Think about why you are finding the
books impenetrable.
Santa Claus - 29 Dec 2006 12:27 GMT
> > do i simply write (take an app called "santa.app" as an example) a class
> > called santa and
[quoted text clipped - 44 lines]
> Look at other people's sample code. Think about why you are finding the
> books impenetrable.
thank you, this is the precise information i needed that i couldn't figure out
from anywhere.
now to get a microphone for speech input that works under the
high magnetic fields of the power lines nearby... (yeah, i know... not part
of this discussion)...
Gregory Weston - 29 Dec 2006 13:39 GMT
> > > These instructions are great! would you mind sending instructions on
> > > simply
[quoted text clipped - 16 lines]
> and what happens if i already HAVE the books and they still make no sense?
> they are good for taking up room on the shelf but...
Either you've got the wrong books or you need to take a couple of steps
back in your training. The Hillegass books, for example, are quite
approachable and make very few assumptions.
> i can handle my way around the nib files myself if i simply knew how the app
> starts up.
[quoted text clipped - 6 lines]
> have that's initialization routine initialize my stuff, compile it ant it
> works?
Yep. Depending, largely, on what you think the class's "initialization
routine" is.
> > > that's why i don't use nib files honestly.
If you don't understand a tool, not using it is one response. Another is
to learn how to use it.
> > This is very bad. Cocoa is built around nibs in much the same way that
> > UNIX is built around files or lisp is built around conses. You may be able
[quoted text clipped - 3 lines]
> i see, having real-time menus that change with the contents of folders or
> other stuff is against the "natural order" right?
Depending on what you mean by "change" having menus that do it can be
good or bad, but it has nothing to do with "the natural order" and much
to do with effective and efficient user interaction. A menu ITEM whose
applicability and behavior may change contextually should change to
reflect that. That's why items dim when they are irrelevant and why in
decent apps the Undo command actually describes the activity it will
undo. Having MENUS that change, by the insertion or removal of items at
times that have no clear relationship to user activity is bad because it
destroys muscle memory. But whether you choose to do either of those has
not a thing to do with whether you use NIBs. How you create your objects
at launch has no bearing on what you do with them later on.
> real-time button windows that have their pictures
> change depending on data received is also against the natural order?
Nope. Not in the slightest.
> Writing
> windows and
> other stuff that LOOKS like it came from a nib file is easy to program NOW (i
> must admit,
> earlier i had one heck of a time getting everything to work).
I think that's a major point in this discussion. The time you spent
learning how to avoid using NIB files would probably have been much
better spent learning how to use them.
> i was under the mistaken impression that this was the newsgroup
> comp.sys.mac.programmer.help
> where you could ask questions without being blasted by folks calling you an
> idiot.
It's a microcosm. You'll find people across the whole continuum of
politeness and patience. And you often get what you give. One of the
things you'll find, though, is that when you ask for help in a help
group and then reject the responses you get, people tend to get less
friendly. The tone of your post is hostile. Don't be surprised if some
people react with hostility. (And looking at Google, not only has noone
called you an idiot...noone's been particularly rude or harsh so far.)

Signature
The best intentions in the world don't make a flawed argument magically valid.