Re: Writing application without Interface Builder
Re: Writing application without Interface Builder
- Subject: Re: Writing application without Interface Builder
- From: Patrick Hartling <email@hidden>
- Date: Fri, 21 Jul 2006 21:05:49 -0500
Patrick Hartling wrote:
> Murat Konar wrote:
>> On Jul 17, 2006, at 7:52 PM, Patrick Hartling wrote:
>>
>>> [C++ based library makes it difficult to write Cocoa using Interface
>>> builder]
>> I tracked down an earlier post of yours which sheds a bit more light on
>> what you're doing
>>
>> <http://www.cocoabuilder.com/archive/message/cocoa/2006/2/6/156127>
>>
>> and in which you note that
>>
>>> (The application object derives from a base C++ class, the interface
>>> methods of which are invoked by the microkernel in a spawned thread.)
>> and
>>
>>> Then, I would see what it would take
>>> to get that to work in a spawned NSThread with no event processing
>>> happening
>>> in the primordial thread.
>> If I'm reading this right, you're hoping to run UI code (including
>> receiving events) in threads other than the main thread. You should know
>> that this unfortunately isn't supported.
>
> At the moment, I actually have things working the way that I need to with
> regard to the multi-threading. I am not sure that it is stable since I am
> only working with a simple test case that (more or less) acts like the full
> framework. So far, I have created one window from a spawned thread and
> successfully processed keyboard and mouse events in it, but there is still a
> lot more that I have to do before I will know for sure that things are going
> to work for me.
I believe that I have figured out my problem with the double menus. After
doing some tinkering with Interface Builder, I found that the problem is
that I am calling NSApplicationLoad() . I read somewhere that it was needed
for setting up initial application state, but this evening I read some
information about it being used to allow Carbon code to utilize Cocoa. This
suggests to me that Carbon and Cocoa are fighting to set the main menu.
Unfortunately, if I remove the call to NSApplicationLoad() or move it to be
after the [NSApplication sharedApplication] call, my multi-threading code
stops working. I have done some reading about run loops, and I thought that
had that detail worked out. Things were looking really good with the
combination of a Nib file to set up the menu connections and my own code for
multi-threading. Without the call to NSApplicationLoad(), however, things
are not looking so promising. Is there any hope at all for what I want to do
with multiple threads and Cocoa? If I could just get rid of the menu that is
added by NSApplicationLoad() without having to make that call after
[NSApplication sharedApplication], I think I could continue with my
experimentation.
>> It sounds like your microkernal wants to be in charge, and that what
>> you're trying to do is plug Cocoa into an already existing app
>> framework, yes? I wonder if splitting this up so that you have your C++
>> based "app" (with no visible manifestation) running in one process,
>> communicating with a Cocoa part that runs in another process is worth
>> investigating?
>
> That is a very interesting idea. I had not thought of that at all, and I
> will definitely ponder it some more. Thanks for the feedback.
I still need to give this more consideration.
-Patrick
--
Patrick L. Hartling | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________
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