Re: Writing application without Interface Builder
Re: Writing application without Interface Builder
- Subject: Re: Writing application without Interface Builder
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 22 Jul 2006 10:43:03 -0700
On Jul 22, 2006, at 6:21 AM, Patrick Hartling wrote:
Bill Bumgarner wrote:
... lots of conjecture about threading, appkit, & the main menu
deleted ...
I apologize for being vague about the threading and all of that. I
will post
some code this time, though I hope not to make this message overly
long as a
result.
No need to apologize -- It wasn't meant as an accusation or insult,
just that I thought the thread would benefit from starting over with
a problem framed in slightly new terms.
OK -- it is pretty clear from your post that you don't have an full
understanding of the interaction between the AppKit, Threads, and the
Main Menu.
I'm sure that you are right. I am new to Cocoa programming, and it
seems
like what I want to do is not what people normally try to do with
Cocoa--and
not just because I started out by trying to write a lot of the code
by hand.
I have since used Interface Builder to set up the main menu, and it
generally works much better than what I was doing by hand.
To be fair -- it is a remarkably subtle aspect of Cocoa programming.
The docs do provide enough information, but it is
.... deleted a bunch of stuff because it looked correct ....
When the NSWindow instance is created, I set its content view and
first
responder to a subclass of NSView that calls NSLog() for keyboard
and mouse
events. All of this is in my helper function openWindow() so that I
can call
it from the primordial thread or from one of my spawned threads.
This implies that openWindow() sets up a view hierarchy and brings
the window on screen? ... potentially from a thread?
This could be problematic -- I haven't reviewed the documentation
closely enough to know exactly where the "thread safe" line cuts
through the AppKit.
Anyway, the main() from above works fine. The window that it opens
receives
events correctly, and the main menu behaves. If I change it so that
the call
to NSApplicationLoad() is uncommented, the creation of the
ThreadedWindow is
uncommented, and the call to openWindow() is commented out, I get
the window
processing events correctly in a thread, but there are basically
two main
menus. If I change it again so that the call to NSApplicationLoad()
is after
the call to [NSApplication sharedApplication], then the main menu
behaves
again, but my window spawned from the thread stops receiving events.
NSEvent processing must happen in the main event loop -- in the main
thread.
A thread's runloop can have "events" of its own, but not NSEvents.
It isn't clear why you are mixing Carbon and Cocoa. Is your C++
framework a Carbon framework? In any case, you can mix Carbon and
Cocoa, but it is tricky. There is documentation on the
http://developer.apple.com/ site.
I didn't intend to mix Carbon and Cocoa. As I said in my previous
post, I
read that NSApplicationLoad() is needed in order to allow Carbon
code to
utilize Cocoa. My goal here is not to use Carbon at all.
Ahh.. OK -- yes. NSApplicationLoad() is intended to initialize the
Cocoa stack to implement a Cocoa window within a Carbon App.
Ultimately, this is all an experiment because I want to learn more
about
Objective-C, Objective-C+=, and Cocoa and because I want to improve
the use
of the C++ software to which I have referred on Mac OS X. I'm quite
thankful
to Apple for the availability of X11 for OS X because this particular
software would not work without it, but I'd like not to be
dependent on X11
for OS X usage. If Cocoa doesn't end up working out, I'll most
likely have
to go the Carbon route. Cocoa just seems like more fun. :)
Heh -- yeah -- Cocoa is definitely the way to go to minimize the
amount of code required to implement any given UI while also
maximizing the feature set.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden