date:20080514


On May 15, 2008, at 12:15 AM, Alex Esplin wrote:

Everything compiles, and when I run it, the Console tells me that
debugging completed normally.  However, I'm getting nothing in the way
of output from any of the threads:


Is your main function waiting for the threads to complete, or is it  
just exiting?  When your main function returns, there's an implicit  
exit() call and your whole process exits.  There's no implicit  
waiting for all threads to complete.


So, I suspect your threads are never getting a chance to run because  
main is exiting.


Cheers,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: any help with [NSThread initWithTarget:selector:object]???

2008-05-14 Thread Bill Bumgarner


On May 14, 2008, at 10:15 PM, Alex Esplin wrote:

Everything compiles, and when I run it, the Console tells me that
debugging completed normally.  However, I'm getting nothing in the way
of output from any of the threads:


Does your main thread wait until the background threads are done?

b.bum

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Guidance for Cocoa's steep learning curve

2008-05-14 Thread David Wilson

On Wed, May 14, 2008 at 11:33 PM, Scott Ribe <[EMAIL PROTECTED]> wrote:
>>> === If you are primarily an experienced C++ programmer (In my
>>> experience you will have the hardest time)
>>
>>
>> (2) I will have to personally disagree with this.
>
> I wonder, seriously, if it doesn't depend somewhat on whether or not you're
> a really good C++ programmer...
>

I'd say it depends more on the type of C++ programming you're coming
from. If you're coming from a purely procedural background with no
event-driven experience, some pretty fundamental Coca concepts are
going to be problematic. If you're comfortable with C++ strict typing
rules, Objective-C may appear to have too much runtime magic going on.
On the other hand, if you've spent a lot of time abusing void * to
hack runtime dynamism into C++, Objective-C will be a breath of fresh
air ("You mean I can do this with sane syntax rather than lots of
casts and abuses of types?"). Also, memory management may throw you
for a loop if you haven't seen reference counting before; if you've
implemented it in C++ out of frustration, however, it's quite clear.

When I was first learning Cocoa and Objective-C, coming from more of a
systems programming background, what made sense of it was to
understand the runtime itself- and there is documentation on it- so
that things ceased to be "black boxes" and I could trace program
control flow without gaps. Once it's clear that methods are just
virtual functions with a different syntax and the ability to actually
determine whether or not they exist at runtime rather than crash,
objective-c is identical to c++ object oriented programming (okay, for
loose definitions of "identical", I don't want to get into the
details; given that insight there are clear broad similarities in
implementation).

So, from a C++ perspective, I'd offer the following points:

1) The type "id" is just void *, except the compiler doesn't complain
when you don't cast it to something real before calling functions on
it as an object.
2) Method calls are just calls to virtual functions, with a little
more runtime support to make them less fragile. In effect,
*everything* in Objective-C is a virtual function; you can't have
non-virtual functions.
3) Instance methods (with the -) are virtual functions. Class methods
(with the +) are static functions.
4) Outlets are just pointers. When your nib gets instantiated with
your object as File's Owner, your outlets (just member variable
pointers) have their values set to point to the things you told them
to point to in the nib.
5) Target-Action setup is just a pointer to an object + a function
pointer. You're telling something "Hey, when X happens, call this
function on this object." Think of callback functions.

There are others, but those are the most basic. Once you can map the
Objective-C constructs onto what's happening under the hood, it
becomes more clear how to take advantage of them.

-- 
- David T. Wilson
[EMAIL PROTECTED]
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

any help with [NSThread initWithTarget:selector:object]???

2008-05-14 Thread Alex Esplin

Hey all,

Sorry if this has been answered before, I've been googling and not
coming up with a direct answer to my problem.

I'm working on a (should be) trivial Vote Counter program for a class.
 I've elected to implement the project in Objective-C/Foundation
because I already know how to do something like this in C and I'd like
to learn something new.

I have a VoteList class that multiple threads will be adding votes to.
 I have locks around the code that adds a Vote to the list, so only
one thread can add a Vote at a time.  In testing this class, I'm
trying to start 4 threads that will add some votes to the list so I
can test the locks and make sure everything is getting counted.
Here's the relevant code:

NSLog(@"\n\n== testVoteList Phase 2 ==\n\n");
list2 = [[VoteList alloc] init];
NSThread* thread1 = [[NSThread alloc] initWithTarget:self
selector:@selector(phase2:) object:list2];
NSThread* thread2 = [[NSThread alloc] initWithTarget:self
selector:@selector(phase2:) object:list2];
NSThread* thread3 = [[NSThread alloc] initWithTarget:self
selector:@selector(phase2:) object:list2];
NSThread* thread4 = [[NSThread alloc] initWithTarget:self
selector:@selector(phase2:) object:list2];

[thread1 start];
[thread2 start];
[thread3 start];
[thread4 start];

The selector(phase2:) is here:

-(void) phase2: (id) arg {
VoteList* list = arg;
NSLog(@"Thread checking in...");
printf("Thread checking in...\n");

return;
}

Everything compiles, and when I run it, the Console tells me that
debugging completed normally.  However, I'm getting nothing in the way
of output from any of the threads:

== testVoteList Phase 2 ==


The Debugger has exited with status 0.


Any ideas?

Thanks
-- 
Alex Esplin
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: basic bindings question


On May 14, 2008, at 11:43 PM, Daniel Child wrote:


On May 15, 2008, at 12:09 AM, Ken Thomases wrote:

Can you be more specific about why you want your controller to  
observe its own number property?  What are you trying to  
accomplish?  I suspect there's another way to accomplish what  
you're interested in.
I'm simply trying to reduce bindings to the most basic case: type  
into a text field, have that value observed, and then reflect it  
somewhere else (as in another text field). The actual application I  
have in mind uses text fields to enable the user to specify sort  
fields, and rather than have a bunch of methods to check those  
values prior to sorting, I thought I could use bindings to  
automatically have those values set as soon as the user types them  
in. (I've used textDidChange in the past to accomplish something  
similar, but I thought this would be an easy case to try bindings.  
Especially since I might want to provide a more elegant interface  
for specifying sort fields prior to the sort.


First, bindings are implemented using KVO, but KVO is not the same as  
bindings.


Second, to do what you're talking about, you'd bind the text field's  
value binding to the controller-model.  There's no reason to have the  
controller observe its own property in this scenario.


Third, while you can definitely set bindings up in code, that's not  
"reduc[ing] bindings to the most basic case".  Setting the binding up  
via IB is the most basic case.



In other words, your "myFoo addObserver: self   
forKeyPath: @"number" becomes


- (void) awakeFromNib {
	[self addOberver: self forKeyPath: @"number" options: 0 context:  
NULL];


There's a typo there.  You've missed the "s" in "addObserver".

Oops. Sorry about that, but I get a runtime error all the same:

[ valueForUndefinedKey:]: this class is not  
key value coding-compliant for the key values.
2008-05-15 00:32:19.909 StringBinding[564:10b] *** Terminating app  
due to uncaught exception 'NSUnknownKeyException', reason:  
'[ valueForUndefinedKey:]: this class is  
not key value coding-compliant for the key values.'


This seems to have nothing to do with the above code.  First, the key  
involved is called "values" not "number".  Second, the receiver is  
the NSApplication instance.  So, why is something trying to access a  
non-existent "values" property of the NSApplication class?


NSUserDefaultsController has a "values" property.  I wonder if you  
temporarily had a binding to that which you attempted to redirect  
toward File's Owner but you didn't change it properly.


-Ken
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: basic bindings question



On May 15, 2008, at 12:09 AM, Ken Thomases wrote:

Can you be more specific about why you want your controller to  
observe its own number property?  What are you trying to  
accomplish?  I suspect there's another way to accomplish what you're  
interested in.
I'm simply trying to reduce bindings to the most basic case: type into  
a text field, have that value observed, and then reflect it somewhere  
else (as in another text field). The actual application I have in mind  
uses text fields to enable the user to specify sort fields, and rather  
than have a bunch of methods to check those values prior to sorting, I  
thought I could use bindings to automatically have those values set as  
soon as the user types them in. (I've used textDidChange in the past  
to accomplish something similar, but I thought this would be an easy  
case to try bindings. Especially since I might want to provide a more  
elegant interface for specifying sort fields prior to the sort.


In other words, your "myFoo addObserver: self   
forKeyPath: @"number" becomes


- (void) awakeFromNib {
	[self addOberver: self forKeyPath: @"number" options: 0 context:  
NULL];


There's a typo there.  You've missed the "s" in "addObserver".

Oops. Sorry about that, but I get a runtime error all the same:

[ valueForUndefinedKey:]: this class is not  
key value coding-compliant for the key values.
2008-05-15 00:32:19.909 StringBinding[564:10b] *** Terminating app due  
to uncaught exception 'NSUnknownKeyException', reason:  
'[ valueForUndefinedKey:]: this class is not  
key value coding-compliant for the key values.'


Thanks!
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

[ANN] DrawKit beta 3 now available


The third beta of DrawKit is now available from 
http://apptree.net/drawkitmain.htm

While still beta, this is generally bug free (unless I'm told  
different) and is likely to represent the final architecture, feature  
set and class design.


What is it?

DrawKit is a Cocoa framework for implementing the core drawing engine  
for a vector drawing application. It provides a set of interacting  
classes and objects for handling this task in a general and flexible  
way, without assuming too much about the final end-use of the  
application. It provides no user interface of its own beyond the  
direct manipulation of the drawn objects. It handles:


• any number of layers, grouped hierarchically if required
• interactive creation of shapes such as rects, ovals, regular  
polygons, round rects and many others (you can also define your own)
• interactive creation of paths such as bezier curves, lines,  
irregular polygons

• interactive positioning, resizing and rotation of objects
• grouping to any degree of nesting
• image and text shapes
• boolean operations on paths using GPC library
• vectorisation of images using potrace library
• tool-based drawing for creating and editing objects and other  
actions (e.g. zoom tool, which operates on the UI not the data model).
• separates geometry of objects from their appearance using styles,  
which can embody any number of arbitrary "rasterizers" giving an  
enormous range of graphical effects.
• designed to work at a high level - set up target/action on the view  
for many predefined built-in operations
• supports any number of simultaneous views, in different windows or  
the same (e.g. split views)
• works analogously to NSTextView - create a DKDrawingView in IB and  
it builds a working system for you, but you can customise this or  
build by hand if you want.
• Makes no assumptions about your UI - go wild. Where is has its own  
UI-type stuff (selection handles etc) these are highly customisable.



hope it's useful,

thanks, Graham___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: window controller's [self window] not working


On May 14, 2008, at 11:23 PM, Daniel Child wrote:
I am just getting used to IB3 but don't see what or how I could  
have broken the connection. Are there any obvious culprits?


The first thing to check is if the "window" outlet of the  
NSWindowController (probably File's Owner) is connected to the window  
object in the nib.


Another possibility is if the nib has an error (due to corruption or  
something like that) and can't load.  Is anything being written to  
the console output?


-Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: window controller's [self window] not working

2008-05-14 Thread j o a r



On May 14, 2008, at 9:23 PM, Daniel Child wrote:

This exact same code used to work in previous incarnations of the  
program, and it seems that it simply "broke" when I opened the nib  
in IB3 and added a text field. (It was originally created in IB2 and  
worked fine in Leopard and XCode 3 until I modified it.)


I am just getting used to IB3 but don't see what or how I could have  
broken the connection. Are there any obvious culprits?



Double-check that the "window" property of the window controller  
(files owner) is connected to the window in your nib file.



j o a r


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Assertion failure in -[NSNextStepFrame lockFocus]



On 14 May '08, at 9:17 PM, Apparao Mulpuri wrote:


** Assertion failure in -[NSNextStepFrame lockFocus],
/SourceCache/AppKit/AppKit-949.27/AppKit.subproj/NSView.m:4751
May 14 17:37:39 apparao-power-mac-g5 MyCocoaApp[123]:
-[NSNextStepFrame(0x143610) lockFocus] failed with window=0x142e60,
windowNumber=62, [self isHiddenOrHasHiddenAncestor]


What's the backtrace?
Set a breakpoint at objc_exception_throw to find out.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

window controller's [self window] not working

I have a window controller that I initialize using  
initWithWindowNibName.


To improve readability later in the code, I try to cache the window  
outlet to another variable. [self window] returns no value, however.


This exact same code used to work in previous incarnations of the  
program, and it seems that it simply "broke" when I opened the nib in  
IB3 and added a text field. (It was originally created in IB2 and  
worked fine in Leopard and XCode 3 until I modified it.)


I am just getting used to IB3 but don't see what or how I could have  
broken the connection. Are there any obvious culprits?


Thanks.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSRange

On 14 May '08, at 4:25 PM, Mr. Gecko wrote:

text I want
so I want to get the text in the middle of points title="Ttitle">
and

Trying to parse HTML by hand like this is a good way to lose your
mind. Seriously, don't try it. Simple searching through strings
looking for delimiters doesn't always work, due to quoting and things
like that. The only way to do it reliably is to write a parser that
knows the rules of HTML, and even then you have to deal with the fact
that many, many websites are full of really broken HTML.

And you don't need to do that, when NSXML will do the parsing for you.
Learn XPath and you can extract things like your example in one line
of code.

I have heard of NSRange but I can't find documentation to it in xcode.

Just open the documentation window and type "NSRange" into the search
field.

Or find the word NSRange in an editor window and option-double-click it.
Or go here:
file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/Reference/reference.html
#//apple_ref/doc/uid/2018-DontLinkElementID_14

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Assertion failure in -[NSNextStepFrame lockFocus]

2008-05-14 Thread Apparao Mulpuri

Is it a known issue on Leopard. Is there any fix?

I am planning to file a bug in apple bugreporter. Is any one filed it already?.

- Apparao.

On Wed, May 14, 2008 at 7:00 PM, Apparao Mulpuri
<[EMAIL PROTECTED]> wrote:
> HI,
>
>   I have a Cocoa based multi monitor application,which will run on
> Mac OS X 10.3.9 onwards.
>
>   It is working as expected in 10.3.9  and Tiger os versions. But, in
> Leopard 10.5.2, its giving following exception:
>
> ** Assertion failure in -[NSNextStepFrame lockFocus],
> /SourceCache/AppKit/AppKit-949.27/AppKit.subproj/NSView.m:4751
> May 14 17:37:39 apparao-power-mac-g5 MyCocoaApp[123]:
> -[NSNextStepFrame(0x143610) lockFocus] failed with window=0x142e60,
> windowNumber=62, [self isHiddenOrHasHiddenAncestor]
>
>  For single monitor with Leopard its working fine. With secondary
> monitor, its throwing above exception. In Secondary monitor case, i am
> doing window(which is custom class of NSWindow and created in IB) copy
> operation(using achieving and unarchieving) and displaying it on
> secondary monitor.
>
>  I am not getting any idea from the above exception. By google, i
> found that, some one is experienced the same exception with custom
> window creation on Leopard.
>
>  Any pointers on this is really appreciated.
>
> Thanks,
> - Apparao.
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: basic bindings question


On May 14, 2008, at 10:54 PM, Daniel Child wrote:
If I want to observe the property of an object, and in my case, it  
turns out that the M and C are collapsed into a model-controller,  
then it's basically a case of asking something to observe itself.


Well, it is sometimes desirable for an object to observe itself for  
changes to its properties.  However, it is often not necessary.  In  
particular, an object's properties should only be modified by  
messaging the object, which gives you a perfect way to "notice" that  
the change is being made -- right in the method which is invoked by  
the message.


For example, if your controller's number property is being changed,  
then something should be invoking its -setNumber: method.  In that  
case, you can just add your code for coping with a change to that  
method:


- (void) setNumber:(NSNumber*)newNumber
{
if (newNumber != number && ![number isEqualToNumber:newNumber])
{
[number release];
number = [newNumber retain];
// Add code to cope with a change in the number property here
}
}


Can you be more specific about why you want your controller to  
observe its own number property?  What are you trying to accomplish?   
I suspect there's another way to accomplish what you're interested in.



In other words, your "myFoo addObserver: self   
forKeyPath: @"number" becomes


- (void) awakeFromNib {
	[self addOberver: self forKeyPath: @"number" options: 0 context:  
NULL];


There's a typo there.  You've missed the "s" in "addObserver".


}

I tried that and got the same message as before ( may not  
respond to addObserver), only this time the receiver is the  
controller instead of number.


Can you report the exact message you're getting?  Is it a compile- 
time warning or a run-time exception?



Is it not possible to collapse M and C for a case where you want to  
track a simple text field. It seems it must be.


It is possible.  We'll have to see what's going wrong in your  
particular case.


Cheers,
Ken
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: basic bindings question

I think I understood the first half of what you said, and can now see  
why making number the receiver of addObserver was totally wrong.


But I seem to have a problem.

If I want to observe the property of an object, and in my case, it  
turns out that the M and C are collapsed into a model-controller, then  
it's basically a case of asking something to observe itself. In other  
words, your "myFoo addObserver: self  forKeyPath:  
@"number" becomes


- (void) awakeFromNib {
[self addOberver: self forKeyPath: @"number" options: 0 context: NULL];
}

I tried that and got the same message as before ( may not  
respond to addObserver), only this time the receiver is the controller  
instead of number.


Is it not possible to collapse M and C for a case where you want to  
track a simple text field. It seems it must be.


On May 14, 2008, at 5:11 PM, Ken Thomases wrote:


To illustrate:

@interface Foo : NSObject
{
NSNumber* number;   //  <--  This is NOT the property
}

// _These_ are the property:
- (NSNumber*) number;
- (void) setNumber:(NSNumber*)newNumber;

@end


// ... in some other code somewhere

Foo* myFoo = /* ... */
[myFoo addObserver:self forKeyPath:@"number"];

This object (self) is observing the myFoo object for changes in its  
"number" property.



Think also about the KVO notifications you will receive:

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject: 
(id)object change:(NSDictionary *)change context:(void *)context;


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder



On 15 May 2008, at 12:54 pm, Johnny Lundy wrote:

Just another note - the reason that I asked this is that I finally  
added a second class to my project. I had never had 2 classes in a  
project before because I didn't understand how to have them  
communicate. Actually, I still don't - I just try everything until  
something works.


If you mean this literally, I doubt that it's ever going to work.  
Software's like this: there are millions of ways for it to fail, and a  
handful of ways for it to work. The chances of stumbling across one of  
the working ways in the vast sea of possible non-working ways purely  
at random is negligible.


I wrote the interface and implementation files, and the app would  
not load. Of course, I had not instantiated the class because  
although I knew that myInstance = [MyClass new]; would make an  
instance, I did not know where to put this code. It seemed recursive  
to put it in the implementation of itself.


So I dragged out an NSObject in IB, named it the class name, and  
everything worked. I still don't understand why. I presume it was  
that dragging it out instantiated it. Or maybe having an -init  
method instantiated it. Class browser doesn't show instances, so  
can't check there.



Dragging it out caused it to exist, yes. A nib file contains objects.  
When the nib is loaded, those objects are attached to your program as  
real live instances.


The reason I want a name for the instance is so I can use it as the  
receiver when I send messages to it from another class's methods.


Right, but understand, the name of the object in IB is not this. It is  
nothing of any use to your code, nor does it mean anything  
significant. It's merely a name - rename it "donkey kong" if you want,  
it makes no difference.


In your code, you have, somewhere (in a suitable object):

IBOutlet id myObjectInstance;


In IB, you connect (ctrl-drag) from "somewhere", myObjectInstance to  
the object it refers to. "Somewhere" could usefully be File's Owner,  
but since for MainMenu.nib this is NSApp(lication), you would need to  
be subclassing NSApplication to add the myObjectInstance outlet. Apart  
from being not a very good approach, I infer from your email that you  
wouldn't know how to do that anyway. Instead you might get further by  
using an application delegate, but you would still need to define this  
and write code for it before trying to connect to it in IB.  
Ultimately, to be useful, an object in IB MUST be connected to an  
outlet, or to another object that is connected to an outlet. If not,  
there is no way for your code to refer to it - it might exist in  
memory but it's an orphan.


To send a message to your object, elsewhere in your code, you can  
write [myObjectInstance doSomething];


Maybe you are expecting too much of Interface Builder. Its job is to  
build interfaces. It doesn't write any code, and it doesn't do  
anything magic. Maybe you'd be better off starting with writing some  
non-interface code so you can understand how objects are instantiated,  
how they are assigned to variables, and how you send messages to them.  
Once you get this, it should be clearer what IB can, and can't do for  
you.



hth,

G.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Guidance for Cocoa's steep learning curve

2008-05-14 Thread Scott Ribe

>> === If you are primarily an experienced C++ programmer (In my
>> experience you will have the hardest time)
> 
> 
> (2) I will have to personally disagree with this.

I wonder, seriously, if it doesn't depend somewhat on whether or not you're
a really good C++ programmer...

-- 
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder

2008-05-14 Thread Johnny Lundy

Just another note - the reason that I asked this is that I finally  
added a second class to my project. I had never had 2 classes in a  
project before because I didn't understand how to have them  
communicate. Actually, I still don't - I just try everything until  
something works.


I wrote the interface and implementation files, and the app would not  
load. Of course, I had not instantiated the class because although I  
knew that myInstance = [MyClass new]; would make an instance, I did  
not know where to put this code. It seemed recursive to put it in the  
implementation of itself.


So I dragged out an NSObject in IB, named it the class name, and  
everything worked. I still don't understand why. I presume it was that  
dragging it out instantiated it. Or maybe having an -init method  
instantiated it. Class browser doesn't show instances, so can't check  
there.


The reason I want a name for the instance is so I can use it as the  
receiver when I send messages to it from another class's methods.


On May 14, 2008, at 9:23 PM, I. Savant wrote:


On 15 May 2008, at 10:51 am, I. Savant wrote:


And if I want to refer by name to that instance in my code, what is
the name of the instance?


Nothing. That is, not until you add an IBOutlet in whatever class
you want to connect to that instance. Say "AppController" has an
outlet called "thingController". You can then connect the
AppController's someThingController outlet to the "Some Thing
Controller" instance. Now, anywhere within your AppController class,
you can send messages to the "Some Thing Controller" instance by its
shiny new name:


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder


On 15 May 2008, at 0:29, Graham Cox <[EMAIL PROTECTED]> wrote



I have no idea how the rest of you gained your expertise but working
on my own, even with the help of books and the internet it has been
an absolute nightmare.


I imagine it can be hard without a structured approach to learning it
- there's a lot there and without a guide it's impossible to know
where to "jump in". I doubt that IB or Xcode is intuitive enough to
guess.
I'm not sure it is the structured approach as such but rather the  
existence of someone one can bounce one's ideas off and ask question  
of that is needed.


IB is interesting as an Interface design problem.
One might think that because the interfaces are visual a "visual  
programming" tool would be ideal.

 It is ideal when it comes to lay out.
So what about the linking of outlets and actions?
 A picture is worth a thousand words and frequently when having to  
document code relating to operations involving geometry a diagram is  
indispensable. However, maybe it is only useful as an object to  
reference and not as a thing to be manipulated.


It seems reasonable to suppose that the inventors of IB had the  
notion of an information flow and the idea that this could be modeled  
using some kind of plumbing metaphor. And the parallels with  
diagramatic notations like UML possibly are also in there.
It is possible however that programming is primarily a linguistic  
symbol manipulation activity whereas drawing or manipulating bits of  
plumbing is not,. This might then explain why the attempt to force a  
visual, quasi "fix the u-bend" way of thinking onto a programming  
task gives rise to difficulties. For me these disappeared as soon as  
I realised that all I needed to do was  to define the actual  
interface parameters in the .h file! That said there is still a mass  
of stuff there I have not even looked at.




I recommend Aaron Hillegasse's book "Cocoa Programming for Mac OS  
X" (http://www.amazon.com/Cocoa-Programming-Mac-OS-3rd/dp/ 
0321503619/ref=pd_lpo_k2_dp_k2a_3_txt?pf_rd_p=304485601&pf_rd_s=lpo- 
top- 
stripe-2&pf_rd_t=201&pf_rd_i=0201726831&pf_rd_m=ATVPDKIKX0DER&pf_rd_r= 
1BBG60H7AHDA15M6M1VJ

)

Personally I found using this book I could start writing useful code
with Cocoa and IB after about a week (simple stuff, at that stage).
That said, I did also attend a course at Apple Munich on Cocoa way
back in 1997 not long after the NeXT merger, which involved running a
very early version of the Yellow Box on Intel PCs - all a bit weird,
but again, it was a structured introduction which was a good mix of
actually using the tools like IB and lectures giving a glimpse of the
potential. It was another 5 years before I looked at any of that
again, so I'd forgotten the details but remembered some of the core
concepts. Hillegass took me the rest of the way.
Simple code yes. But that's the thing. The way the book teaches makes  
generalisation very difficult. It is possible that the diagrams  
interrupt the flow of the description, the flow of one's thinking, so  
it becomes difficult to see it all together in one's head.  
Additionally and strangely the diagrams make it difficult to remember  
precisley where in the book a particular piece of information is to  
be found. The book is a brave attempt and lots of people seem to  
swear by it but for me it just had me ripping my hair out.


It might be worthwhile attending a course if you can find one - do
Apple still run them? That can often cut through months of frustration
trying to struggle on ones own.
Aye, if you have the dosh that's fine but I think the cost of courses  
is likely to make one's eyes water.




and books like Cocoa Programming for Mac OSX and Vermont recipes
were very hard going. Perhaps it was their verbosity, or the
learning by rote


I've already talked up this book, so I'm surprised you feel this way
about it. It's not verbose, it's concise and clearly written.
The Hillglass does not have that many words but many of those there  
are in my view superfluous - the text is to friendly by half.  
O'Reilly in a nutshell would be my prefered format.
The vermont recipies . 700 + words, detours, explanaitions  
everywhere - I'm a programmer, I have a grasp of the nature of  
programming, of what programs look like. The fact that it takes 700  
pages to describe something which to my mind ought to be   
straightforward is a big indicator of things not being quite right.
For instance , The O'Reilly Java in Nutshell books, they're pretty  
thick dense tomes and it took me three months to get a handle on the  
api but I wan't screaming in frustration all the time.
Is it possible that the MVC model which emerged from that thick  
german book (Design Patterns: Elements of Reusable Object-Oriented  
Software - Gamma et al) and the whole notion of ready made templates  
so to speak had not quite synthesised within people's minds  
sufficiently to allow easy expression?

You can
choose to learn by rote or

Re: Bypassing Interface Builder

2008-05-14 Thread Johnny Lundy

Actually, I have read that many times. My reason for reading it was  
that so many example codes and tutorials say to bind an interface item  
to File's Owner, but don't say why or what that binding accomplishes.


So it's the application instance. I don't understand what the  
application instance is. I can recite the documentation, which says it  
is a shared instance of NSApplication, also known as NSApp which is a  
global variable, none of which help me.


Why would someone bind to File's Owner? What specifically is it? My  
current trial-and-error practice is to make an NSObject in IB and name  
it one of my classes and then bind to a property through that NSObject  
instance - this lets me bind to my ivars. There is no controller,  
however (or at least nothing NAMED "NSxxxController"), so I don't know  
if I am violating MVC by essentially connecting the view to the model  
through this NSObject.


What I meant by IB won't let me make 2 instances of a class is - try  
and type the same class name in a second time - it disappears when you  
end editing. E.g. if I want 2 NSObjects that both have MyClass as  
their class, it will take the first one but erase the textfield when I  
finish editing the second one.



On May 14, 2008, at 9:23 PM, [EMAIL PROTECTED] wrote:



Message: 6
Date: Wed, 14 May 2008 21:06:06 -0400
From: Andy Lee <[EMAIL PROTECTED]>
Subject: Re: Bypassing Interface Builder
To: Cocoa-dev 
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

On May 14, 2008, at 8:51 PM, I. Savant wrote:

Also, the documentation only says about File's Owner that it is the
object that loaded the nib file. What is that object, if my nib
file just gets loaded at application launch?


Your app's NSApplication instance. This is in the documentation.


It can be a little tricky to find, though.  I found it in the first
hit from Googling "cocoa file's owner":

Re: Guidance for Cocoa's steep learning curve

2008-05-14 Thread Ricky Sharp



On May 14, 2008, at 8:19 PM, Erik Buck wrote:




I would just like to add the following:

(1) It also depends upon prior framework experience as to how easy or  
difficult it will be to dive into Cocoa.  I learned event-driven  
programming very early and had the advantage of either using or  
authoring ten other frameworks prior to using Cocoa.


For me, Cocoa was just another new framework to learn.  I thus had  
experience in ramping up to frameworks and found the transition quite  
easy.


=== If you are primarily an experienced C++ programmer (In my  
experience you will have the hardest time)



(2) I will have to personally disagree with this.  I found the  
transition from C++ to Obj-C to again be easy.  I also chose to go  
pure Obj-C rather than mix in existing C++ classes.  This was a  
personal choice and by no means would I recommend this path for  
everyone; mixing in C++ is often the right thing to do.


I will agree though that you have to throw certain C++ mindsets out  
the window.  But, as with any new language/framework, there are always  
different philosophies of what one should/shouldn't do.


FYI, my personal path of languages has been: AppleSoft and other forms  
of BASIC; Assembly (mostly 6502); Pascal; C; C with objects*; C++;  
Java; Obj-C.  Along the way, dabbled a tiny bit in Scheme, ADA,  
Smalltalk and Prograf.


* I purchased the follow-on product to Think C which sometimes  
referred to as "C+".  It had a very small set of keywords added to  
provide developers with basic OO support.


___
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm)   http://www.instantinteractive.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: how to update the view of NSPrintOperation ?

2008-05-14 Thread debin lei

   You are kind to give me more detail about it.
   I know the panel will update the preview when some printInfo changed.
What 's the attribute will affecte the preview can set with the
function keyPathsForValuesAffectingPreview . It is ok.
   But in my app, the preview changes without any printInfo changed. For
example , i offer an button option to print the doc without tables. So when
user press the button, i will remove the tables in the print view and no
printInfo changed. And the preview did not change.
  What should i do? it must offer a fake attribute,ex Margin,update it
without useful? Then let the preview update?

2008/5/15 douglas a. welton <[EMAIL PROTECTED]>:

>
>  On May 14, 2008, at 9:13 AM, debin lei wrote:
>
>   Thank you for your infomation, i know the function
> keyPathsForValuesAffectingPreview, however, i did not know how to use it.
>
> <<<>>>
>
> Can you give me more detail about it? I want the preview NSView call its
> drawrect function when i press the button in the accessory view . How to do
> this?
>
>
> Below you'll find a copy the implementation file from my Print Panel's
> accessory view controller.
>
> The gist is this:
>
> 1)  My accessory panel has one button, a check box (bound to the sizeToFit
> property).  When that button changes value my setter method is called.  This
> method will manual trigger KVO for the localizedSummaryItems, then update
> the designated NSPrintInfo object.
>
> 2) the keyPathsForValuesAffectingPreview returns a set of NSPrintInfo
> properties that need to be observed KVO-style (by the Preview View?) so that
> when changes occur, the preview view can be updated.
>
> Hope this helps.
>
> regards,
>
> douglas
>
> ---
>  //
> //  PrintAccessory_ViewController.m
> //  LightTable
> //
> //  Created by Douglas Welton on 4/28/08.
> //  Copyright 2008 __MyCompanyName__. All rights reserved.
> //
>
> #import "PrintAccessory_ViewController.h"
>
> @implementation PrintAccessory_ViewController
>
> @synthesize sizeToFit;
> @synthesize windowController;
> @synthesize printOperation;
>
> //+
> //  Method: setSizeToFit: (BOOL) New_Value
> //
> //  Function: Change the appropriate print info settings
> //-
>
> - (void) setSizeToFit: (BOOL) New_Value
> {
> NSPrintInfo *Current_PrintInfo;
>
>
> //+
> //  Update the value of the sizeToFit flag and manually trigger the KVO for
> the summary items key
> //-
>
>
> [self willChangeValueForKey: @"localizedSummaryItems"];
> sizeToFit = New_Value;
> [self didChangeValueForKey: @"localizedSummaryItems"];
>
>
> //+
> //  Update the PrintInfo from the attributes that affect this change, then
> update the print operation
> //-
>
>
> Current_PrintInfo = [self.printOperation printInfo];
>
>
> if ( sizeToFit )
>   {
> [Current_PrintInfo setHorizontalPagination: NSFitPagination];
> [Current_PrintInfo setVerticalPagination: NSFitPagination];
> }
>   else
>   {
> [Current_PrintInfo setHorizontalPagination: NSAutoPagination];
> [Current_PrintInfo setVerticalPagination: NSAutoPagination];
> }
>
>
> [self.printOperation setPrintInfo: Current_PrintInfo];
> }
>
> #pragma mark -
> #pragma mark NSPrintPanelAcessorizing Protocol Support
>
>
> //+
> //  Method: keyPathsForValuesAffectingPreview
> //
> //  Function: Tells "whoever" is observing for the print preview which
> keys to observe for changes
> //-
>
> - (NSSet *) keyPathsForValuesAffectingPreview
> {
> return [NSSet setWithObjects: @"representedObject.horizontalPagination",
> @"representedObject.verticalPagination", nil];
> }
>
> //+
> //  Method: localizedSummaryItems
> //
> //  Function:
> //-
>
> - (NSArray *) localizedSummaryItems
> {
> NSString *Description;
>
>
> //+
> //  Based on the value of sizeToFit, set the description string
> appropriately
> //-
>
>
> if ( self.sizeToFit )
> Description = @"Scale canvas to fit paper size";
>   else
> Description = @"Natural pagination";
>
>
> return [NSArray arrayWithObject: [NSDictionary
> dictionaryWithObjectsAndKeys: @"Canvas Scaling",
> NSPrintPanelAccessorySummaryItemNameKey,
> Description, NSPrintPanelAccessorySummaryItemDescriptionKey,
> nil]];
> }
>
>
> @end
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder

Or if you're trying to tell someone where he would have found the  
answer if he'd read the conceptual documentation methodically.  :)


  Touché. Though under protest: your original point started with the  
fact that it's tricky to "find". ;-)


Fair point, and the distinction between concepts docs and API  
reference is an important one.


  Now if only you could create and distribute an app that makes the  
long slog through the copious conceptual documentation as easy as the  
one you have for the API reference. For free, please. ;-)


  Oh, and make it animate. It's gotta' animate its a** off.

--
I.S.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder



On 14 May 2008, at 22:55, Torsten Curdt <[EMAIL PROTECTED]> wrote

This mailing list is a great resource ...but maybe there is a reason
why even simple things get asked again and again.
Yes, exactly. I think there is a dearth of good examples and a  
difficulty in finding the keywords to use when googling.
The apple docuentation pages are good but if they are to be truly  
informative then they should provide examples - after all, who can  
get back into documentation even of things they know about without  
having to take some time to revise the subject and a picture, aka  
example, is wortth a thousand words.



I just can't believe how long it took me come up get shell script
executed without all pipe filling deadlock problems and so on. This is
so basic stuff and I wasted hours on that.

Wasted hours, that's exactly it, and I feel so incredibly stupid.
I had thought of getting to grips with cocoa quite a few times over  
the past few years but  each time i dived in i had to get out because  
the learning curve was way too steep. This last time I could not see  
any other way of achieving the software i'm building so I had to  
grasp the nettle but just the "tearing one's hair out by the roots"  
rage and frustration


Julius


http://juliuspaintings.co.uk



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: cross-development Problems

2008-05-14 Thread Celery01 Lin

Thank you Nick , I'm searching it now~

On Wed, May 14, 2008 at 6:02 PM, Nick Zitzmann <[EMAIL PROTECTED]> wrote:

>
> On May 14, 2008, at 6:59 PM, Celery01 Lin wrote:
>
>  This is a very wired problem . HIShapeCreateWithRect is inside
>> Carbon.framework. Why the linker trys to resolve it in
>> ApplicationServices?
>>
>> Dose anyone have any suggestion ?
>>
>
>
> Try searching the xcode-users list archives; this problem has come up there
> before.
>
> 
>
> Nick Zitzmann
> 
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder


On May 14, 2008, at 9:15 PM, I. Savant wrote:

On May 14, 2008, at 9:06 PM, Andy Lee wrote:


It can be a little tricky to find, though.


 That's only if you're searching myopically for that one answer.


Or if you're trying to tell someone where he would have found the  
answer if he'd read the conceptual documentation methodically.  :)


Fair point, and the distinction between concepts docs and API  
reference is an important one.


--Andy

If, on the other hand, you read the conceptual documentation all the  
way through as you're meant to, you should definitely come across it  
in context and in a reasonably good order.


 As the author of AppKiDo, I know you understand the importance of  
effective research, so I'm not being dismissive. I say that because  
this really is more of a conceptual topic and that's exactly why the  
conceptual documentation is there. It's meant to be consumed first  
(chew thoroughly), then referenced later. Contrast with the API  
reference, which really is meant for just that.


--
I.S.





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: how to update the view of NSPrintOperation ?

2008-05-14 Thread debin lei

no, i know how to printed document without UI, just set
[printOp setShowsPrintPanel:NO];

i realy want to close the dialog with programtically, is it possiable?

2008/5/14 Rimas <[EMAIL PROTECTED]>:

> What are you trying to achieve? Get printed document without UI?
>
> > 2.
> >  when we implement printing with cocoa,
> >  an NSPrintOperation object is created to control the print operation .
> >  NSPrintOperation * printOp = [NSPrintOperation
> >  printOperationWithView:viewToPrint printInfo:printInfo];
> >  [printOp setShowsPrintPanel:YES];
> >  [printOp runOperation];
> >
> >  I got a native printing dialog, So how can I cancel this programtically?
> Is
> >  it possiable?
> >
>
> Rimas
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Guidance for Cocoa's steep learning curve

2008-05-14 Thread Erik Buck



The obstacles, misconceptions, and prerequisite concepts that need to  
be mastered when learning Cocoa vary dramatically based on the past  
experience of the learner.  I am a very experienced Cocoa programmer.  
I am also an author of the thickest Cocoa Programming book and have  
another Cocoa book due out real soon.  I have some guidance.


To relate my background, I started using NeXTstep (the precursor to  
Cocoa) that included Interface Builder and Objective-C and App Kit in  
late 1988.  I had heard of object oriented programming but didn't "get  
it".  I had attended a one day seminar on "C with Classes" which later  
became C++.  I left the seminar no wiser than when I arrived.  I had  
worked for eight years with C and a variety of assembly languages.  I  
had been using Ada for a year.


I became excited about NeXTstep software development, worked on many  
hobby projects, and from 1991 on I worked extensively with NeXTstep/ 
Openstep/YelowBox/Cocoa as well as C++ and many other technologies.  I  
founded a company in the early 90s and developed an industry leading  
application.  I sold the intellectual property to a Fortune 500  
company in 1996, and my company continued to work in the industry  
until late 2002.  I am now "Senior Staff" for a different Fortune 500  
company in a related industry.


Here is my guidance based on some arbitrarily chosen categories of  
learners:


=== If you have never programmed before
1) Learn any programming language (it may seem hard, but every 'real'  
programmer knows many languages and you have to start somewhere)
2) Learn C and at least learn to recognize low level operations like  
bit manipulation, pointers, intrinsic types, pointers to pointers,  
pointers to functions, etc.  Without this, you will be lost and  
dangerous when writing Cocoa programs in Objective-C.
3) Learn Objective-C.  It takes about 1 day for an experienced C  
programmer.
4) Start the long process of learning the Cocoa frameworks, the C  
standard library, and some of the Unix libraries.
4A) Learn Cocoa conventions and common patterns.  These are not  
optional.  Clear understanding of the following is required to write  
graphical Cocoa applications: two stage allocation and initialization,  
designated initializers, memory management, selectors, dynamic  
messaging, accessors, the responder chain, delegates, target/action,  
data sources, archiving & unarchiving (e.g. freeze dried objects  
in .nib files), the view hierarchy, key and main windows, and above  
all the Model View Controller pattern.
4B) Study Apple's sample applications, work tutorials, experiment, and  
build a few hobby projects.


=== If you are primarily an experienced "dynamic" language programmer  
(perl, Ruby, Python, Smalltalk, TCL, etc)
1) Learn C and at least learn to recognize low level operations like  
bit manipulation, pointers, intrinsic types, pointers to pointers,  
pointers to functions, etc.  Without this, you will be lost and  
dangerous when writing Cocoa programs in Objective-C.
2) Learn why C and therefore Objective C use a pre-processor with  
separate headers and separate implementation files.  Come to grips  
with the edit, COMPILE, link, debug cycle.
3) Learn Objective-C.  It takes about 1 day.  You will realize the  
Objective-C is very dynamic and flexible but has its own idioms.
4) Start the long process of learning the Cocoa frameworks, the C  
standard library, and some of the Unix libraries.
4A) Learn Cocoa conventions and common patterns.  Many will be  
familiar to a Smalltalk programmer.  These are not optional.  Clear  
understanding of the following is required to write graphical Cocoa  
applications: two stage allocation and initialization, designated  
initializers, memory management, selectors, dynamic messaging,  
accessors, the responder chain, delegates, target/action, data  
sources, archiving & unarchiving (e.g. freeze dried objects in .nib  
files), the view hierarchy, key and main windows, and above all the  
Model View Controller pattern.
4B) Study Apple's sample applications, work tutorials, experiment, and  
build a few hobby projects.
4C) If you object to Cocoa's memory management conventions, learn to  
love them because in the world of C, automatic garbage collection can  
not solve all of your problems.


=== If you are primarily an experienced C++ programmer (In my  
experience you will have the hardest time)
1) Forget everything you think you know about Object Oriented  
programming (no offense intended).
2) Break every ingrained C++ habit and idiom because the design  
philosophy of Objective-C and Cocoa is exactly the opposite of almost  
everything C++ encourages.
3) Learn Objective-C.  It takes about 1 day for an experienced C  
programmer.  You will realize the Objective-C is very dynamic an  
flexible.  Many patterns and idioms in C++ are unneeded in Objective- 
C.  Objective-C classes tend to be more high level and straight  
forward, and you tend

Dynamic message typing problem


Hi,
It would be great if someone would kindly tell me what I'm doing wrong.

Something like the much simplified code below used to work under  
Tiger in 10.4 running on antique 400 MHz G4.
The idea is that the program passes the id of an  
anonTargetClassObject to a calling object which then sends a message  
to that anonTargetClassObject id.
What seems to be happening is that I am not getting the compiler to  
generate the correct type information for the float and unsigned char  
message parameter.

The code is implemented in Leopard running on a mac Pro.

In the build info I have
Instruction scheduling = PowerPC G5 - I've tried several of the  
options without success

Objective-C Garbage Collection = Required
Optimisation Level = Fastest, smallest

C language dialect = Compiler Default
Compile Sources as = Objective-C

Everything else is set to the default.

I'm sure I'm giving you more code than you need but here goes 
===
//the .h and .m files of object to which the message is sent

#import 
@interface AnonTargetClass : NSObject {
}
- (void) printSimple;
- (void) printString:(NSString *)pS;
- (void) printFloat:(float)pF;
- (void) printInt:(int)pI;
- (void) printUnsignedChar:(unsigned char)pC;
- (void) printUnsignedCharRef:(unsigned char *)pC;
@end

#import "AnonTargetClass.h"
@implementation AnonTargetClass
- (void) printSimple;
{
NSLog(@"AnonTargetClass printSimple =Hi from AnonTarget");
}

- (void) printString:(NSString *)pS;
{
NSLog(@"AnonTargetClass printString = %@",pS);
}

- (void) printFloat:(float)pF;
{
NSLog(@"AnonTargetClass printFloat = %7.3f",pF);
}

- (void) printInt:(int)pI;
{
NSLog(@"AnonTargetClass printInt = %6d",pI);
}

- (void) printUnsignedChar:(unsigned char)pC;
{
NSLog(@"AnonTargetClass printUnsignedChar = %6d",pC);
}

- (void) printUnsignedCharRef:(unsigned char *)pC
{
NSLog(@"AnonTargetClass printUnsignedCharRef = %6d",*pC);
}

@end


//the .h and .m files of calling object
#import 
@interface CallingClass : NSObject {
}
- (void) callPrintSimple:(id)pId;
- (void) callPrintConstString:(id)pId;
- (void) callPrint:(id)pId zString:(NSString *)pS;
- (void) callPrintConstFloat:(id)pId;
- (void) callPrint:(id)pId zFloat:(float)pF;
- (void) callPrintConstInt:(id)pId;
- (void) callPrint:(id)pId zInt:(int)pI;
- (void) callPrintConstUnsignedChar:(id)pId;
- (void) callPrint:(id)pId zUnsignedChar:(unsigned char)pI;
- (void) callPrintConstUnsignedCharRef:(id)pId;
- (void) callPrint:(id)pId zUnsignedCharRef:(unsigned char *)pI;

@end

#import "CallingClass.h"
@implementation CallingClass
- (void) callPrintSimple:(id)pId
{
[pId printSimple];
}

- (void) callPrintConstString:(id)pId
{
[pId printString:@"Hi from PrintConstString"];
}

- (void) callPrint:(id)pId zString:(NSString *)pS
{
[pId printString:pS];
}

- (void) callPrintConstFloat:(id)pId
{
[pId printFloat:12.34];
}

- (void) callPrint:(id)pId zFloat:(float)pF
{
[pId printFloat:pF];
}

- (void) callPrintConstInt:(id)pId
{
[pId printInt:5];
}

- (void) callPrint:(id)pId zInt:(int)pI
{
[pId printInt:pI];
}

- (void) callPrintConstUnsignedChar:(id)pId;
{
[pId printUnsignedChar:222];
}

- (void) callPrint:(id)pId zUnsignedChar:(unsigned char)pCh;
{
[pId printUnsignedChar:pCh];
}

- (void) callPrintConstUnsignedCharRef:(id)pId;
{
unsigned char * tvarUnsignedChar= 123;
[pId printUnsignedCharRef:&tvarUnsignedChar];
}

- (void) callPrint:(id)pId zUnsignedCharRef:(unsigned char *)pChRef;
{
[pId printUnsignedCharRef:pChRef];
}

@end


// main.m
#import 
#import "AnonTargetClass.h"
#import "CallingClass.h"

int main(int argc, char *argv[])
{
AnonTargetClass * anonObjToBeCalled = [[AnonTargetClass alloc]init];
CallingClass* callingObj= [[CallingClass alloc]init];

float tvarFloat = 6.54;
int tvarInt = 321;
unsigned char tvarUnsignedChar= 255;
NSLog(@"Check the methods of AnonTargetClass");
[anonObjToBeCalled printSimple];
[anonObjToBeCalled printString:@"String direct from main"];
[anonObjToBeCalled printFloat:98.76];
[anonObjToBeCalled printFloat:tvarFloat];
[anonObjToBeCalled printInt:55];
[anonObjToBeCalled printInt:tvarInt];
[anonObjToBeCalled printUnsignedChar:tvarUnsignedChar];
[anonObjToBeCalled printUnsignedCharRef:&tvarUnsignedChar];
NSLog(@"End checking methods of AnonTargetClass");

NSLog(@"calling the methods dynamically");
[callingObj callPrintSimple:
(id)anonObjToBeCalled ];
[callingObj callPrintConstString:   
(id)anonObjToBeCalled];
// just testing the lack of coersion
	[callingObj callPrint:		anonObjToBeCalled zString:@"This string  
passed from main 1"];
	[callingObj callPrint:		(id)anonObjToBeCalled zString:@

Re: Bypassing Interface Builder


On May 14, 2008, at 9:06 PM, Andy Lee wrote:


It can be a little tricky to find, though.


  That's only if you're searching myopically for that one answer. If,  
on the other hand, you read the conceptual documentation all the way  
through as you're meant to, you should definitely come across it in  
context and in a reasonably good order.


  As the author of AppKiDo, I know you understand the importance of  
effective research, so I'm not being dismissive. I say that because  
this really is more of a conceptual topic and that's exactly why the  
conceptual documentation is there. It's meant to be consumed first  
(chew thoroughly), then referenced later. Contrast with the API  
reference, which really is meant for just that.


--
I.S.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: cross-development Problems

2008-05-14 Thread Jack Repenning


On May 14, 2008, at 5:59 PM, Celery01 Lin wrote:


But When I switch to tiger , MyTest crashs because of
"dyld: lazy symbol binding failed: symbol not found:  
HIShapeCreateWithRect

..
Expected in :
/system/library/Frameworks/ApplicationService.framework/Versions/A/ 
ApplicationServices

"

This is a very weird problem . HIShapeCreateWithRect is inside
Carbon.framework. Why the linker trys to resolve it in  
ApplicationServices?


Dose anyone have any suggestion ?


dyld searches several places before giving up, at which point it seems  
to complain only about the last spot it looked.  Of course, this is  
not the spot where the library actually is, since if it had found the  
library it wouldn't be complaining in the first place!  You should  
ignore the curious location in the error message, and just understand  
that the desired library was not found.  Since you know it's in  
Carbon.framework, check again your arrangements for making that  
framework available.


-==-
Jack Repenning
[EMAIL PROTECTED]
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder

Actually I wonder if this could be a useful enhancement to IB? Say  
if you've never edited the object's name from the default, but then  
drag-connect an outlet to it, the label changed to the name of the  
outlet. That would be a quick and easy way to see at a glance what  
object it is *in terms of your own ivar identifiers*. If you edit it  
anyway, before or after, it just uses your label.


  Probably a topic for the xcode-users list (not to mention an  
enhancement request at bugreport.apple.com ), but many different  
object instances can have many different names for the same thing.  
Which name wins? ;-)


--
I.S.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder

It might get confusing if you have multiple objects with differently  
named outlets pointing to the same thing.


--Andy

On May 14, 2008, at 9:02 PM, Graham Cox wrote:

Actually I wonder if this could be a useful enhancement to IB? Say  
if you've never edited the object's name from the default, but then  
drag-connect an outlet to it, the label changed to the name of the  
outlet. That would be a quick and easy way to see at a glance what  
object it is *in terms of your own ivar identifiers*. If you edit it  
anyway, before or after, it just uses your label.


Just an idea,

G.


On 15 May 2008, at 10:51 am, I. Savant wrote:

And if I want to refer by name to that instance in my code, what  
is the name of the instance?


Nothing. That is, not until you add an IBOutlet in whatever class  
you want to connect to that instance. Say "AppController" has an  
outlet called "thingController". You can then connect the  
AppController's someThingController outlet to the "Some Thing  
Controller" instance. Now, anywhere within your AppController  
class, you can send messages to the "Some Thing Controller"  
instance by its shiny new name:


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder


On May 14, 2008, at 8:51 PM, I. Savant wrote:

And if I want to refer by name to that instance in my code, what is  
the name of the instance?


 Nothing. That is, not until you add an IBOutlet in whatever class  
you want to connect to that instance.


  Let me clarify this a bit further. An instance that's unarchived  
from a loaded nib can easily have no reference to it at all from your  
own code. It's analogous to having a program that does this at launch:


[[NSObject alloc] init];

  Note there's no pointer like this:

NSObject * myObject = [[NSObject alloc] init];

  If the first (no-pointer) line is run at application launch, you've  
got an NSObject instance floating around somewhere you can no longer  
reach. Other objects may have a reference to this (such as this case):


[[[NSObject alloc] init] autorelease];

  Your own code has no reference to this object and it's just set  
adrift immediately upon creation. Other objects (such as an  
NSAutoreleasePool instance) have can have references to it. Perhaps  
some other object to which you have a reference may reference it, but  
if not, you've lost the ability talk directly to it.


  Of course the use of mechanisms such as KVO, message centers and  
such makes such a scenario fairly common. If I have a basic array  
controller that works perfectly in its default configuration, why  
should I need an outlet with which to send it messages? If, however, I  
need to 'kick' it by sending it a -fetch: message from within my code,  
an outlet would sure make that easier ...


--
I.S.




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder


On May 14, 2008, at 8:51 PM, I. Savant wrote:
Also, the documentation only says about File's Owner that it is the  
object that loaded the nib file. What is that object, if my nib  
file just gets loaded at application launch?


 Your app's NSApplication instance. This is in the documentation.


It can be a little tricky to find, though.  I found it in the first  
hit from Googling "cocoa file's owner":



"Each Cocoa application has a main nib file that contains the  
application-specific menus and possibly one or more windows. NSApp is  
File's Owner of the main nib file. When an application launches, NSApp  
loads the main nib file, unarchiving it, and displays the menus and  
initial windows. Many applications have auxiliary nib files for such  
things as documents and panels; these nib files are loaded on demand  
(that is, when the user requests behavior provided by objects in the  
nib file)."


--Andy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: cross-development Problems



On May 14, 2008, at 6:59 PM, Celery01 Lin wrote:


This is a very wired problem . HIShapeCreateWithRect is inside
Carbon.framework. Why the linker trys to resolve it in  
ApplicationServices?


Dose anyone have any suggestion ?



Try searching the xcode-users list archives; this problem has come up  
there before.




Nick Zitzmann


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder

Actually I wonder if this could be a useful enhancement to IB? Say if  
you've never edited the object's name from the default, but then drag- 
connect an outlet to it, the label changed to the name of the outlet.  
That would be a quick and easy way to see at a glance what object it  
is *in terms of your own ivar identifiers*. If you edit it anyway,  
before or after, it just uses your label.


Just an idea,

G.


On 15 May 2008, at 10:51 am, I. Savant wrote:

And if I want to refer by name to that instance in my code, what is  
the name of the instance?


 Nothing. That is, not until you add an IBOutlet in whatever class  
you want to connect to that instance. Say "AppController" has an  
outlet called "thingController". You can then connect the  
AppController's someThingController outlet to the "Some Thing  
Controller" instance. Now, anywhere within your AppController class,  
you can send messages to the "Some Thing Controller" instance by its  
shiny new name:


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder


On May 14, 2008, at 8:45 PM, Graham Cox wrote:

On 15 May 2008, at 10:15 am, Johnny Lundy wrote:
Also, the documentation only says about File's Owner that it is the  
object that loaded the nib file. What is that object, if my nib  
file just gets loaded at application launch?


It depends. It's the file's (nib's) owner. If you are talking about  
MainMenu.nib, its owner is the application instance. For typical  
document nibs, it's the NSDocument instance. For others, it's  
whatever you pass as "owner" in the NSBundle class method  
+loadNibNamed:owner:


You may not be aware that you can create nibs that are *not* loaded at  
application launch, but only when you use +loadNibNamed:owner:.  For  
example, you might put resources for your application's About box in a  
separate nib that is only loaded when the user chooses "About..." from  
the menu.  This would speed up launch time slightly and would avoid  
allocating memory for the About box until absolutely necessary.


Note also that you can load a nib file multiple times, and each time a  
brand new set of objects will be instantiated and interconnected using  
the object descriptions in the nib file.  NSDocument-based  
applications use this fact when you create a new document.


--Andy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

cross-development Problems

2008-05-14 Thread Celery01 Lin

Hi all
I have a framework "A" depends on a static lib "slib" . My Testapp depends
on Framework "A" and it use a method inside the "slib", which call
HIShapeCreateWithRect.

I built my Testapp using 10.5sdk on leopard and set the Deployment Target as
10.4 Tiger. Everything works well on leopard .
But When I switch to tiger , MyTest crashs because of
"dyld: lazy symbol binding failed: symbol not found: HIShapeCreateWithRect
..
Expected in :
/system/library/Frameworks/ApplicationService.framework/Versions/A/ApplicationServices
"

This is a very wired problem . HIShapeCreateWithRect is inside
Carbon.framework. Why the linker trys to resolve it in ApplicationServices?

Dose anyone have any suggestion ?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder


On May 14, 2008, at 8:45 PM, Graham Cox wrote:

It depends. It's the file's (nib's) owner. If you are talking about  
MainMenu.nib, its owner is the application instance. For typical  
document nibs, it's the NSDocument instance. For others, it's  
whatever you pass as "owner" in the NSBundle class method  
+loadNibNamed:owner:


  Well, yeah, this. ;-) Sorry for the imprecision.

--
I.S.




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder



On this topic, when I drag an object out of the Library and set its  
class, IB sets the label of the object to the Class Name. Since this  
is an instance of the class, and not the Class Object itself, why is  
the name capitalized?


  It's just a convenient label. If you have two ThingController  
instances and one controls SomeThing and the other controls  
AnotherThing, you'll want to name them something easily identifiable:  
SomeThing Controller and AnotherThing Controller. It's just for easy  
identification during developer editing.


And if I want to refer by name to that instance in my code, what is  
the name of the instance?


  Nothing. That is, not until you add an IBOutlet in whatever class  
you want to connect to that instance. Say "AppController" has an  
outlet called "thingController". You can then connect the  
AppController's someThingController outlet to the "Some Thing  
Controller" instance. Now, anywhere within your AppController class,  
you can send messages to the "Some Thing Controller" instance by its  
shiny new name:


[someThingController doSomeThing];

Also, I found out that IB will not let me make 2 instances of the  
same Class. In code, I could say myClassInstance1 = [MyClass new];  
and MyClassInstance2 = [MyClass new];, but apparently not in IB.


  Sure you can. Exactly the same way you did it the first time. A   
new instance is created. Whether you use the "Instantiate ..." menu  
item or drag an NSObject instance into your nib and change its class,  
doing it a second time creates a new instance.


  Are you doing something differently or getting an error?


This has been a mystery to me for six years now.


  Ouch.


Also, the documentation only says about File's Owner that it is the  
object that loaded the nib file. What is that object, if my nib file  
just gets loaded at application launch?


  Your app's NSApplication instance. This is in the documentation.

--
I.S.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder



On 15 May 2008, at 10:15 am, Johnny Lundy wrote:


Hi,

On this topic, when I drag an object out of the Library and set its  
class, IB sets the label of the object to the Class Name. Since this  
is an instance of the class, and not the Class Object itself, why is  
the name capitalized? And if I want to refer by name to that  
instance in my code, what is the name of the instance?


The name of an object in IB is not accessible to your code, generally  
speaking. It's just a convenience so you can tell things apart in IB.  
You can change that label in IB by editing it directly, but it's not  
important. It certainly doesn't mean that this is the variable  
name for that object instance.


Say I drag out an object and set its class to MyClass. IB dutifully  
names the object MyClass also. So in my code if I code [MyClass  
somemessage], does that message go to the Class Object or to the  
instance made in IB? If to the Class Object, how do I code to refer  
to the instance?


The name is irrelevant (see above). You refer to it by having an  
IBOutlet which is connected to that instance. If you are talking about  
class methods, then there's no ambiguity anyway - there are no  
"instances" of class methods, by definition - so messages to the class  
go to the, err... class.


Also, I found out that IB will not let me make 2 instances of the  
same Class. In code, I could say myClassInstance1 = [MyClass new];  
and MyClassInstance2 = [MyClass new];, but apparently not in IB.


Sure you can. Not sure why you think this, but maybe the confusion  
about the IB name is misleading you. Once you realise that the name  
shown in IB has no significance whatsoever, it may release you from  
this confusion.



This has been a mystery to me for six years now.


That is indeed a long time to be this muddled. My sympathies.

Also, the documentation only says about File's Owner that it is the  
object that loaded the nib file. What is that object, if my nib file  
just gets loaded at application launch?




It depends. It's the file's (nib's) owner. If you are talking about  
MainMenu.nib, its owner is the application instance. For typical  
document nibs, it's the NSDocument instance. For others, it's whatever  
you pass as "owner" in the NSBundle class method +loadNibNamed:owner:




hth,


G.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder



  Graham, your responses were very well-put. I had to step away from  
this thread to meet some deadlines today and I'm glad to see where  
it's gone for the most part. I rushed to the defense of IB because,  
for what it is intended, it really is a powerful and useful tool.  
Unnecessary struggle is silly, more so on a device designed to  
eliminate just that.


  Now to my point:

You probably didn't mean what you wrote, but if you did, then you  
would have had trouble - IB doesn't *ever* want you to do this. You  
drag FROM outlet TO control. You drag FROM control TO target +  
action method. It's always FROM source TO destination.


  I'd like to expand on this a bit. It's important to think of  
"messaging objects" here. In Objective-C we are supposed to refer to a  
method call as a "message".


[someObject performSomeAction];

  In this sense, we can easily visualize a "flow" of messages from a  
sender to a receiver. In Interface Builder, this concept is key to  
understanding the "connections" you establish by ctl-dragging from one  
object to another.


  The two types of connections Interface Builder allows serve two  
different purposes to achieve and/or facilitate this flow. An IBOutlet  
gives you the ability to name an object instance so you can send it  
messages by name. An IBAction allows you "codelessly" specify both the  
target and action of a control.


  In the case of IBOutlet, an example of this is creating a  
"nextButton" outlet in an AssistantWindowController object and  
connecting an instance of it to a "Next" button in an assistant window  
so that you can enable or disable the button (or change its title to  
"Finish") when certain things happen (of course you can use Bindings  
for this). In this case, the owner of the outlet wants to be the sender.


  In the case of an IBAction, an example is the -nextPage: method of  
an "AssistantWindowController". Connecting the button's action to the  
AssistantWindowController's -nextPage: method means that when the  
button's action is fired, that AssistantWindowCotroller instance  
receives the -nextPage: action with the next button as its sender. In  
this case the owner of the action wants to be the receiver.


  Interface Builder is just a GUI tool (in two senses) that lets you  
instantiate views and controllers and wire them up with names and  
actions mostly through drag-and-drop. Doing so entirely in code is  
ridiculously tedious by comparison.


--
I.S.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder

Do join the DK mailing list if you haven't already. (http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net
) I'm very willing to help people out with learning the framework, and
I don't want to pollute cocoa-dev with DK related stuff.

A new beta and a start on the documentation is coming (maybe today if
I can get moving).

I recognise the difficulty in figuring out how things work, especially
with little or no docs, but I'm not sure that trying to hack it down
to a smaller case is likely to be all that fruitful. For example, if
you tried to strip out or bypass the controllers you'd find nothing
would work, because the connection between the view and the data model
would be gone, and the controller implements the tool(s) that are used
to draw new objects. The pathways that a mouse event, for example,
takes from a click or drag in the view to creating an object in the
drawing is logical, but not absolutely direct - various objects get a
pop at it and all with good reason. Unfortunately the price of
flexibility is often added complexity. My suggestion would be to let
DKDrawingView set everything up for you, then you could try exploring
using gdb.

Anyway, this is off-topic. Feel free to take it up on the DK mailing
list.

On 15 May 2008, at 10:14 am, colo wrote:

On Wed, May 14, 2008 at 7:41 PM, Graham Cox <[EMAIL PROTECTED]>
wrote:
One thing to point out here (as the author of DrawKit) is that
DrawKit
doesn't use INTERFACE builder to any great extent because it is 95%
data
model. In the model-view-controller architecture, Interface Builder
is
useful mostly for V, and to some extent for C and very little for
M. So

trying to use IB for something it isn't useful for is a sure route to
frustration and misunderstanding.

That's what I noticed mostly from reading your source example app. I
started to try and hack "out" features so I could get it to the core
of just drawing a box so I can see the root code of what calls it up
and stuff. But thats where my lack of real cocoa comes into play atm.
And it not compiling :P

But I did not want to bother you on it per request message on your
website, and the fact that I just need to learn more still.

You might want to look for a local CocoaHeads or NSCoderNight
chapter for

where you live.

j o a r

Sadly joar there are zilch in Portland, ME, and I know of zilch cocoa
programers besides Rails people.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Conditionally modifying NIBs?

2008-05-14 Thread Jonathan Hess



On May 14, 2008, at 4:10 PM, Hamish Allan wrote:

On Wed, May 14, 2008 at 11:25 PM, Mike Fischer  
<[EMAIL PROTECTED]> wrote:


(I know this can be hacked, and that while verbose it's only xml.  
But I'd

want my apps building in the next Xcode (sub-)release as well.)


Sure, well, you can't eat your cake and have it ;)

I'd have thought that you could maybe try to automate "Whenever any of
the parts of nib N1 and N2 change that are identical in both nibs I
have to remember to make the changes in both."

You can also use ibtool for verification


How so?


, so I don't buy that
"extremely dangerous" stuff


Just because a tool doesn't crash reading the file, and everything  
appears to work normally doesn't mean that the file is correct and  
valid.


As for the original question, you can modify an IB file, to some  
extent, using ibtool --import and ibtool --export. For example, you  
might consider placing all of your views and objects in the XIB/NIB,  
and then using these options to control the isHidden property of  
various views. That won't be easy though, as it isn't an intended  
usage of ibtool. I think the best option here is to make the changes  
in code, and to only use on IB file.


Good Luck -
Jon Hess


, and the bit about backwards compatibility
is irrelevant.


Hamish
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/jhess%40apple.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: show/hide NSTabView


Hey David,

Thanks for the suggestion. But it's the window height. And that does  
indeed change properly.

It's just the controls (the NSTabView) that misbehaves.

Please see my other mail.

cheers
--
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder

2008-05-14 Thread Johnny Lundy


Hi,

On this topic, when I drag an object out of the Library and set its  
class, IB sets the label of the object to the Class Name. Since this  
is an instance of the class, and not the Class Object itself, why is  
the name capitalized? And if I want to refer by name to that instance  
in my code, what is the name of the instance?


Say I drag out an object and set its class to MyClass. IB dutifully  
names the object MyClass also. So in my code if I code [MyClass  
somemessage], does that message go to the Class Object or to the  
instance made in IB? If to the Class Object, how do I code to refer to  
the instance?


Also, I found out that IB will not let me make 2 instances of the same  
Class. In code, I could say myClassInstance1 = [MyClass new]; and  
MyClassInstance2 = [MyClass new];, but apparently not in IB.


This has been a mystery to me for six years now.

Also, the documentation only says about File's Owner that it is the  
object that loaded the nib file. What is that object, if my nib file  
just gets loaded at application launch?


Thanks
Johnny
On May 14, 2008, at 2:32 PM, Andy Lee wrote:


When your application *loads* a nib, it:

(3a) instantiates the objects,
(3b) sets their attributes, and
(3c) connects them both to each other and to certain things in your
application (in particular, File's Owner, which you should
definitely understand).




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder

2008-05-14 Thread colo

On Wed, May 14, 2008 at 7:41 PM, Graham Cox <[EMAIL PROTECTED]> wrote:
> One thing to point out here (as the author of DrawKit) is that DrawKit
> doesn't use INTERFACE builder to any great extent because it is 95% data
> model. In the model-view-controller architecture, Interface Builder is
> useful mostly for V, and to some extent for C and very little for M. So
> trying to use IB for something it isn't useful for is a sure route to
> frustration and misunderstanding.
>

That's what I noticed mostly from reading your source example app. I
started to try and hack "out" features so I could get it to the core
of just drawing a box so I can see the root code of what calls it up
and stuff. But thats where my lack of real cocoa comes into play atm.
And it not compiling :P

But I did not want to bother you on it per request message on your
website, and the fact that I just need to learn more still.

> You might want to look for a local CocoaHeads or NSCoderNight chapter for
> where you live.
>
> j o a r

Sadly joar there are zilch in Portland, ME, and I know of zilch cocoa
programers besides Rails people.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSRange


On May 14, 2008, at 7:25 PM, Mr. Gecko wrote:
Hello I am trying to find out how to get characters in the middle of  
two characters I have heard of NSRange but I can't find  
documentation to it in xcode.


Enter "NSRange" in the search field of the Xcode documentation window  
and do an "API" search.  The first hit is the doc for NSRange.


Or, look at the documentation for -rangeOfString: and note that  
NSRange is a clickable link.  Click on it.


Or, Google for "NSRange".

--Andy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder

One thing to point out here (as the author of DrawKit) is that DrawKit  
doesn't use INTERFACE builder to any great extent because it is 95%  
data model. In the model-view-controller architecture, Interface  
Builder is useful mostly for V, and to some extent for C and very  
little for M. So trying to use IB for something it isn't useful for is  
a sure route to frustration and misunderstanding.


Also, DrawKit *can* use IB, where it makes sense to do so. For  
example, you can set up a custom view in IB to be a DKDrawingView  
instance and ... umm, you're done. That is enough to create a fully  
functioning layered vector drawing editor in its entirety. For a real  
app you'd probably want to have more control and build some or all of  
the "back end" yourself, but the above is a good start as it will show  
that things are working, and puts the various objects together in the  
correct relationships. In this sense it's conceptually similar to  
NSTextView - you can set up an NSTextView in IB and it will build a  
complete text editor for you, but for more control you need to put  
together NSLayoutManager, NSTextContainer and so forth yourself.


hth,

G.

On 15 May 2008, at 12:36 am, colo wrote:


My goal is to make a drawing app from the Drawkit framework but for
the life of me I just can't get past the use IB but Drawkit does not
use IB but the books do and swear that I should fiasco! Ah ha ha ha ha
h haha h  hah aa haa


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSRange

2008-05-14 Thread Mr. Gecko


I figured it out
NSString *s = [NSString stringWithContentsOfURL:[NSURL URLWithString:@"http://www.example.com/file.html 
"]];

NSRange f, l;

f = [s rangeOfString:@" title=\"Title\">"];
if (f.location == NSNotFound) NSLog(@"failed");
s = [s substringFromIndex:f.location + f.length];

l = [s rangeOfString:@""];
if (l.location == NSNotFound) NSLog(@"failed");
s = [s substringWithRange:NSMakeRange(0, l.location)];
On May 14, 2008, at 6:33 PM, Randall Meadows wrote:


On May 14, 2008, at 5:25 PM, Mr. Gecko wrote:

Hello I am trying to find out how to get characters in the middle  
of two characters I have heard of NSRange but I can't find  
documentation to it in xcode.


>


So here is what I am trying to do in this html page on line there  
are to points which stays the same and in the middle of the points  
is what I need here is an example.

text I want
so I want to get the text in the middle of points  title="Ttitle">  
and 

Here is what I tried and did not work

NSString *url = [NSString stringWithContentsOfURL:[NSURL  
URLWithString:@"http://www.example.com/file.html";]];

NSString *s = url;
NSRange f, l;

f = [url rangeOfString:@"{\" title=\"Ttitle\">"];


Maybe it failed because your source string ("url", which is not a  
URL, BTW) does NOT have a { character in it?  (I'm thinking perhaps  
you accidently added the { when you typed the ".)





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: show/hide NSTabView

2008-05-14 Thread David Dumaresq

Just a guess, but perhaps try not adding fullSize.height to  
windowFrame.size.height, just assign it the value of fullSize.height.

Or initialize its value to zero before the if(show) condition.

Instead of

windowFrame.size.height += fullSize.height;

^^^

try:

windowFrame.size.height = fullSize.height;



Regards,
Dave
On 14-May-08, at 12:03 PM, [EMAIL PROTECTED] wrote:


While the code below seemed to have worked OK for showing/hiding a
NSTextView I am now not really sure what's going on when using it on a
NSTabView.

- (void) showDetails:(BOOL)show animate:(BOOL)animate
{
NSSize fullSize = NSMakeSize(455, 302);

NSRect windowFrame = [[self window] frame];

if (show) {

[tabView setFrameSize:fullSize];
[tabView setNeedsDisplay:YES];
windowFrame.origin.y -= fullSize.height;
windowFrame.size.height += fullSize.height;
[[self window] setFrame: windowFrame
display: YES
animate: animate];

} else {
[tabView setFrameSize:NSMakeSize(0,0)];
[tabView setNeedsDisplay:YES];
windowFrame.origin.y += fullSize.height;
windowFrame.size.height -= fullSize.height;
[[self window] setFrame: windowFrame
display: YES
animate: animate];

}



--
Understanding is the ultimate seduction of the mind.
Go to the truth
beyond the mind.
Love is the bridge.
- Stephen Levine








___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSRange

2008-05-14 Thread Randall Meadows


On May 14, 2008, at 5:25 PM, Mr. Gecko wrote:

Hello I am trying to find out how to get characters in the middle of  
two characters I have heard of NSRange but I can't find  
documentation to it in xcode.


>


So here is what I am trying to do in this html page on line there  
are to points which stays the same and in the middle of the points  
is what I need here is an example.

text I want
so I want to get the text in the middle of points  title="Ttitle">  
and 

Here is what I tried and did not work

NSString *url = [NSString stringWithContentsOfURL:[NSURL  
URLWithString:@"http://www.example.com/file.html";]];

NSString *s = url;
NSRange f, l;

f = [url rangeOfString:@"{\" title=\"Ttitle\">"];


Maybe it failed because your source string ("url", which is not a URL,  
BTW) does NOT have a { character in it?  (I'm thinking perhaps you  
accidently added the { when you typed the ".)



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: show/hide NSTabView

OK ...I got a little further. Turns out the resize of the window  
should be enough.
The size of the tabView should get adjusted automatically because of  
the autosize settings.



   - (void) showDetails:(BOOL)show animate:(BOOL)animate
   {
   NSSize fullSize = NSMakeSize(455, 302);

   NSRect windowFrame = [[self window] frame];

   if (show) {

   windowFrame.origin.y -= fullSize.height;
   windowFrame.size.height += fullSize.height;
   [[self window] setFrame: windowFrame
   display: YES
   animate: animate];

   } else {
   windowFrame.origin.y += fullSize.height;
   windowFrame.size.height -= fullSize.height;
   [[self window] setFrame: windowFrame
   display: YES
   animate: animate];

   }
   }


BUT ...I so don't get the autosize behavior!! Check out this little  
screencast


 http://vafer.org/pub/autosize.mov

The first part is as expected. But once the height of the NSTabView  
has been zero - it's getting ugly.


Seems like I am not alone on this

 http://katidev.com/blog/2008/02/12/why-i-say-no-to-autoresizing/

What's the best way around this for my case? I just want to show/hide  
the NSTabView.


cheers
--
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder

On 15 May 2008, at 6:05 am, Julius Guzy wrote:

I have no idea how the rest of you gained your expertise but working
on my own, even with the help of books and the internet it has been
an absolute nightmare.

I imagine it can be hard without a structured approach to learning it
- there's a lot there and without a guide it's impossible to know
where to "jump in". I doubt that IB or Xcode is intuitive enough to
guess.

I recommend Aaron Hillegasse's book "Cocoa Programming for Mac OS X" (http://www.amazon.com/Cocoa-Programming-Mac-OS-3rd/dp/0321503619/ref=pd_lpo_k2_dp_k2a_3_txt?pf_rd_p=304485601&pf_rd_s=lpo-top-stripe-2&pf_rd_t=201&pf_rd_i=0201726831&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1BBG60H7AHDA15M6M1VJ
)

Personally I found using this book I could start writing useful code
with Cocoa and IB after about a week (simple stuff, at that stage).
That said, I did also attend a course at Apple Munich on Cocoa way
back in 1997 not long after the NeXT merger, which involved running a
very early version of the Yellow Box on Intel PCs - all a bit weird,
but again, it was a structured introduction which was a good mix of
actually using the tools like IB and lectures giving a glimpse of the
potential. It was another 5 years before I looked at any of that
again, so I'd forgotten the details but remembered some of the core
concepts. Hillegass took me the rest of the way.

It might be worthwhile attending a course if you can find one - do
Apple still run them? That can often cut through months of frustration
trying to struggle on ones own.

One problem intially was with IB itself which wanted me to drag from
controls to outlets etc. and which I found very hard to learn

You probably didn't mean what you wrote, but if you did, then you
would have had trouble - IB doesn't *ever* want you to do this. You
drag FROM outlet TO control. You drag FROM control TO target + action
method. It's always FROM source TO destination.

and books like Cocoa Programming for Mac OSX and Vermont recipes
were very hard going. Perhaps it was their verbosity, or the
learning by rote

I've already talked up this book, so I'm surprised you feel this way
about it. It's not verbose, it's concise and clearly written. You can
choose to learn by rote or you can take the underlying concepts, ideas
and principles and use those to explore other things more appropriate
to the tasks you want to accomplish. This sort of exploration may not
work for everybody, but it did for me. It's a little like doing
science - the book gives you some theory, a selection of scattered
facts, but you extrapolate from that to your own situation, test your
understanding by testing new "what if" cases and thus gradually expand
the theory and your own understanding. I personally feel that this is
the point of these books - they are not intended to give you a
tutorial for all of Cocoa, they show you a few pertinent examples and
expect you to use some induction to extend that to other parts they
don't specifically cover. I would imagine that reading Hillegasse from
cover to cover and typing in every example would be extremely dull
indeed, and I doubt you'd really absorb all that much. Instead, have a
goal of your own and use the book as a reference to explore certain
concepts then use your own project to try and apply them. Sure you'll
make lots of mistakes, and from time to time there will be
frustration, but those moments when you extrapolate from principle A
and B to guess that C and D will happen - AND IT DOES! - will make it
all worthwhile ;-)

hth,

G.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

NSRange

2008-05-14 Thread Mr. Gecko

Hello I am trying to find out how to get characters in the middle of  
two characters I have heard of NSRange but I can't find documentation  
to it in xcode.
So here is what I am trying to do in this html page on line there are  
to points which stays the same and in the middle of the points is what  
I need here is an example.

text I want
so I want to get the text in the middle of points  title="Ttitle"> and  


Here is what I tried and did not work

NSString *url = [NSString stringWithContentsOfURL:[NSURL  
URLWithString:@"http://www.example.com/file.html";]];

NSString *s = url;
NSRange f, l;

f = [url rangeOfString:@"{\" title=\"Ttitle\">"];
if (f.location == NSNotFound) NSLog(@"failed");
s = [s substringFromIndex:f.location + f.length];

l = [s rangeOfString:@",\"\""];
if (l.location == NSNotFound) NSLog(@"failed");
s = [s substringFromIndex:f.location + l.location];

I wanted s to equal the text in the middle but it does not.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Conditionally modifying NIBs?

On Wed, May 14, 2008 at 11:25 PM, Mike Fischer <[EMAIL PROTECTED]> wrote:

> (I know this can be hacked, and that while verbose it's only xml. But I'd
> want my apps building in the next Xcode (sub-)release as well.)

Sure, well, you can't eat your cake and have it ;)

I'd have thought that you could maybe try to automate "Whenever any of
the parts of nib N1 and N2 change that are identical in both nibs I
have to remember to make the changes in both."

You can also use ibtool for verification, so I don't buy that
"extremely dangerous" stuff, and the bit about backwards compatibility
is irrelevant.

Hamish
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder

2008-05-14 Thread colo

Well. Huh. After reading all of that. I wish there was sorta mentor
program. Ah but where would be the fun in that. Any way thats off
topic.

Nothing more to say other than back to the books. And pray that I
"get" IB soon enough, cause this is my third round at cramming this
in.



On Wed, May 14, 2008 at 4:49 PM, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> ...also late joing this thread
>
>> I have just spent the best part of five months learning enough objective-c
>> and cocoa to create useful apps.
>> I have been programming for 30 plus years and this has been the most
>> difficult learning experience of my life.
>> It is not just IB but also Project Builder and Xcode and now Xcode under
>> Leopard. And Objective-C also has its little ways.
>>
>> I have no idea how the rest of you gained your expertise but working on my
>> own, even with the help of books and the internet it has been an absolute
>> nightmare. One problem intially was with IB itself which wanted me to drag
>> from controls to outlets etc. and which I found very hard to learn and books
>> like Cocoa Programming for Mac OSX and Vermont recipes were very hard going.
>> Perhaps it was their verbosity, or the learning by rote. The examples on the
>> internet are not that plentiful and it takes a long time to find one's way
>> around.
>>
>> Now under Leopard people should find IB easier to learn because the
>> emphasis is on creating the header files first and this is easier to
>> understand. I could say masses more about this learning hell but will desist
>> except to say it is not over yet. When I moved over to Leopard the compiler
>> ceased to assign the proper type to the variables passed in dynamically
>> typed  messages. And I still have not solved this!!!
>>
>> So I write merely to give heart to others. The learning nightmare does
>> ease over time but never forget the system's tendency every now and then to
>> send you right back to square one.
>>
>>
>> All this said, cocoa and Objective-C is beautiful. I just wish it were
>> easier to learn.
>
> Big +1 to all you just said.
>
> As soon as it gets a little more complicated or something is not working as
> you would expect I get this "blackbox" feeling. Just today IB3.1 failed on
> me miserably ...and I had no clue what to do. After some fiddling "ibtool"
> saved the day. But hell - while it's slowly getting better, really good
> examples and docs are still scarce.That said the cocoacast screencast are
> priceless. And http://www.cocoadev.com has some good information behind its
> ugly shell. The Apple docs are extensive but it's hard to start from there.
> Sucks that some of their videos are only available with (paid) ADC
> membership. This mailing list is a great resource ...but maybe there is a
> reason why even simple things get asked again and again.
>
> I just can't believe how long it took me come up get shell script executed
> without all pipe filling deadlock problems and so on. This is so basic stuff
> and I wasted hours on that. Or take NSMailDelivery ...it's deprecated -
> great. But do the docs state what else to use? Just last week this came up a
> couple of times.
>
> Well, lots of Cocoa tips and tricks to blog about I guess ;)
>
> It surely is a steep learning curve - somehow I still like getting into it.
> Scary! See you at WWDC :)
>
> cheers
> --
> Torsten
> http://vafer.org/blog
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/colo0logo%40gmail.com
>
> This email sent to [EMAIL PROTECTED]
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Setting default application for URL scheme



On May 14, 2008, at 4:23 PM, Jens Alfke wrote:

The proper UI is to show a pop-up menu (in your app's prefs) of  
applications that handle this scheme, with the current default one  
selected, and let the user pick. That's what Safari, iChat, Mail,  
etc. all do.



In theory, that's how it's supposed to happen. Then there's the Finder  
and iCal, in which case overriding them requires a tug of war using  
Launch Services.


Nick Zitzmann


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Conditionally modifying NIBs?

2008-05-14 Thread Mike Fischer


Am 15.05.2008 um 00:07 schrieb Hamish Allan:

On Wed, May 14, 2008 at 6:37 PM, Mike Fischer  
<[EMAIL PROTECTED]> wrote:


I remember in the very dim past (when MacApp was still a modern  
framework
;-) that I had text based resource files (.r) to build the 'View'  
resources
(rough analog to nibs) which included preprocessor macros to  
control which
parts/features where active. These would be compiled into .rsrc  
files using
the current build settings. This mechanism was very flexible when  
it came to
building different variants of an application. (I admit though  
that the
source was hard to read and edit due to all of the conditional  
stuff.)


Is there any way to achieve someting similar in our modern Cocoa/ 
Xcode/IB

world? How do others handle this problem?


You could use XIB files instead of NIB files, and write a script to
process them as a build step before they are compiled...


Sure, that would be fine.

Do you happen to have the official format description handy?

The only thing I found was this:

XIB files are not human editable
XIB files are the result of writing an in-memory object graph to  
disk, by using a custom serialization protocol. Editing XIB files  
by hand is not suggested, extremely dangerous, and can lead to  
corrupted interfaces

XIB 3.x and NIB 3.x files are not backward compatible for development
There are some features that can only be developed using the XIB  
3.x or NIB 3.x formats. Support for these features—such as support  
for toolbars, and the promotion of cells to first-class citizens— 
either required underlying changes in AppKit to support, or  
introduced new content into the document hierarchy that previous  
versions of Interface Builder can not handle. Interface Builder 3.0  
includes an automatic compatibility check, performed before saving,  
which will inform you of items which affect the file format  
compatibility.


From 


(I know this can be hacked, and that while verbose it's only xml. But  
I'd want my apps building in the next Xcode (sub-)release as well.)



Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Web: 
Note: I read this list in digest mode!
  Send me a private copy for faster responses.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Setting default application for URL scheme



On 14 May '08, at 2:25 PM, Nick Zitzmann wrote:

That's the best way to do it. However, some programs tend to  
override the user's choices for default URL handlers.


The proper UI is to show a pop-up menu (in your app's prefs) of  
applications that handle this scheme, with the current default one  
selected, and let the user pick. That's what Safari, iChat, Mail, etc.  
all do.


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Can I use NSString classes SYNCHRONOUSLY?

2008-05-14 Thread Dave Dribin


On May 14, 2008, at 5:11 PM, Jens Alfke wrote:

On 14 May '08, at 10:03 AM, [EMAIL PROTECTED] wrote:

Essentially I want to mimic the Java HTTPConnect example I gave.
I also want to be able to change the request property to POST, as in
the Java equivalent:  
connection.setRequestMethod(HttpConnection.POST);


If you're doing HTTP, use NSURLConnection instead of trying to re- 
invent your own HTTP support on top of the basic stream classes.

It has a class method that does synchronous requests.


Agreed.  You can use -[NSMutableURLRequest setHTTPMethod:] to use POST.

-Dave

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Efficient XML loading [continuation of NSString from mapped NSData thread]



On 14 May '08, at 8:08 AM, Matt Gough wrote:

Well, if iTunes is already running, why don't you just do it via  
Scripting Bridge?


Because it would be orders of magnitude slower. Even the property list  
parser can read the iTunes library in a few seconds. Extracting all  
that information via AppleEvents would certainly take minutes.
Taking that amount of time, it would be subject to race conditions,  
since the library might change while your script is iterating it.
It also requires that iTunes be running, which is a bad assumption if  
you have an app that wants to grab an MP3 to use on its own (i.e. like  
a slideshow soundtrack in iPhoto.)


Trust me; I've done this before.

Relying on the XML format of the iTunes library staying the same for  
all future versions of iTunes is going to be more troublesome than  
the worries you have of the file being overwritten.


No. That file exists specifically for interoperability. (iTunes itself  
uses a separate database file in some funky binary format; it only  
emits the XML file for other apps to read.) If it ever changed  
incompatibly, any number of 3rd party apps would break, and even Apple  
apps (like all of iLife) would have to change their code and complain  
bitterly to the iTunes folks about screwing up their release  
schedules. In other words, it isn't going to happen. What does happen  
is that new keys get added to the plist over time.


You also don't need to worry yourself about the location of 'iTunes  
Music Library.xml' - Mine exists on a volume connected to an Airport  
Extreme, not in ~/Music/iTunes Music/


Good point that the location is not hardwired! A lot of developers  
don't know that and their apps end up not working for people who've  
moved their music folders elsewhere.


The location of the XML file is stored in user defaults. If you use  
code like the snippet below you'll always be able to find it:


+ (NSURL*) currentITunesLibraryURL
{
[[NSUserDefaults standardUserDefaults] synchronize];
NSArray *dbs = [[[NSUserDefaults standardUserDefaults]
persistentDomainForName: @"com.apple.iApps"]
objectForKey: @"iTunesRecentDatabases"];
if( [dbs count] > 0 ) {
NSURL *url = [NSURL URLWithString: [dbs objectAtIndex: 0]];
if( [url isFileURL] )
return url;
}
return nil;
}


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Can I use NSString classes SYNCHRONOUSLY?



On 14 May '08, at 10:03 AM, [EMAIL PROTECTED] wrote:


Essentially I want to mimic the Java HTTPConnect example I gave.
I also want to be able to change the request property to POST, as in
the Java equivalent: connection.setRequestMethod(HttpConnection.POST);


If you're doing HTTP, use NSURLConnection instead of trying to re- 
invent your own HTTP support on top of the basic stream classes.

It has a class method that does synchronous requests.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Conditionally modifying NIBs?

On Wed, May 14, 2008 at 6:37 PM, Mike Fischer <[EMAIL PROTECTED]> wrote:

> I remember in the very dim past (when MacApp was still a modern framework
> ;-) that I had text based resource files (.r) to build the 'View' resources
> (rough analog to nibs) which included preprocessor macros to control which
> parts/features where active. These would be compiled into .rsrc files using
> the current build settings. This mechanism was very flexible when it came to
> building different variants of an application. (I admit though that the
> source was hard to read and edit due to all of the conditional stuff.)
>
> Is there any way to achieve someting similar in our modern Cocoa/Xcode/IB
> world? How do others handle this problem?

You could use XIB files instead of NIB files, and write a script to
process them as a build step before they are compiled...

Hamish
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Capture screenshot

2008-05-14 Thread brett

>
> Am 14.05.2008 um 14:48 schrieb john muchow:
>> My question for this group is if anyone is aware of a Cocoa
>> API/library call to capture a screenshot.

Check out the sample code at

http://developer.apple.com/samplecode/OpenGLScreenSnapshot/index.html

and

http://developer.apple.com/samplecode/SonOfGrab/index.html

Cheers,
Brett



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSRectFillListWithColors question

On Wed, May 14, 2008 at 6:47 PM, Nick Zitzmann <[EMAIL PROTECTED]> wrote:

> On May 14, 2008, at 11:19 AM, Davide Scheriani wrote:
>
>> okkei,good,this is working,but I wanted to use NSArray instead a simple
>> C-style array.
>> In many case I have NSArray it hold NSValue for each NSRect.
>
> You could write a category that does this.

Don't lose sight of what you were originally trying to do, though. I'd
recommend that for now, you just iterate over the array and draw each
rect using NSRectFill(). If, later, when you run your app through
Shark, that turns out to be a performance bottleneck, then is the time
to try other approaches.

Hamish
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Launching Cocoa Application externally (Yann Disser)

Please stop copying Yann Disser's name into the subject line! It
breaks up threads unnecessarily.

Hamish
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: WWDC ticket needed

2008-05-14 Thread Pablo Pons Bordes


Hi,

The sell out caught by surprice me to, so if anyone have one more to  
sell (or James you receive more than you need) please contact me at [EMAIL PROTECTED]


thanks

Pablo Pons


El 14/05/2008, a las 22:25, James Gregurich escribió:


greetings.

Markzware is in need of a WWDC ticket. If anyone wants to sell one,  
please contact me at [EMAIL PROTECTED] The sellout caught us by  
surprise.


thanks,

James Gregurich
Engineering Manager
Markzware


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/pablo.mailinglists%40gmail.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Setting default application for URL scheme



On May 14, 2008, at 3:16 PM, Ken Thomases wrote:

Do you really need to set the default handler?  Generally, Mac  
applications merely advertise that they are capable of handling a  
given URL scheme and it's left to the user to pick the default  
handler.  To merely advertise the capability, see the documentation  
of the CFBundleURLTypes key of the Info.plist file:



That's the best way to do it. However, some programs tend to override  
the user's choices for default URL handlers. I've noticed that the  
Finder, for example, is very adamant about making itself the default  
FTP URL handler.


Nick Zitzmann


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

WWDC ticket needed

2008-05-14 Thread James Gregurich

greetings.

Markzware is in need of a WWDC ticket. If anyone wants to sell one, please 
contact me at [EMAIL PROTECTED] The sellout caught us by surprise.

thanks,

James Gregurich
Engineering Manager
Markzware


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Setting default application for URL scheme


On May 14, 2008, at 3:06 PM, Nick Zitzmann wrote:


On May 14, 2008, at 1:16 PM, Matthew Gertner wrote:


I'd like to set the application that should be run when a URL with a
given scheme is opened. The only way I've found to do this is
_LSSetDefaultSchemeHandlerURL, but I'd rather not go with an
undocumented API if it can be avoided. Is there a Cocoa API or
something for this that I haven't been able to find? Or would I be
better off using the Cocoa APIs to modify the launch services  
database

directly?



There is no Cocoa API. The only supported way of doing this is to  
use LSSetDefaultHandlerForURLScheme(), which requires Tiger or  
later. Prior to Tiger, you had to use Internet Config to do that.


Do you really need to set the default handler?  Generally, Mac  
applications merely advertise that they are capable of handling a  
given URL scheme and it's left to the user to pick the default  
handler.  To merely advertise the capability, see the documentation  
of the CFBundleURLTypes key of the Info.plist file:


http://developer.apple.com/documentation/MacOSX/Conceptual/ 
BPRuntimeConfig/Articles/PListKeys.html#//apple_ref/doc/uid/ 
20001431-102207


http://developer.apple.com/documentation/Carbon/Conceptual/ 
LaunchServicesConcepts/LSCConcepts/chapter_2_section_4.html#// 
apple_ref/doc/uid/TP3999-CH202-CIHFEEAD


Cheers,
Ken
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: basic bindings question


On May 14, 2008, at 2:08 PM, Daniel Child wrote:
All I'm trying to do is to replace the target-action-outlet  
approach with bindings in the simplest case I can think of: a text  
field whose value would correspond to an ivar in the controller.  
One text field would receive the number, a button would click, pass  
the number to the ivar, and redisplay that value in another text  
field.


Actually, requiring the button click to perform the transfer is going  
to make it harder.  It will be easier to just have the field directly  
update the ivar when editing completes.


First off, is it possible possible to bind directly to an instance  
variable in the controller? In my hyper-basic example, I'm  
collapsing M and C. I thought doing so should be OK, so I tried:


Bind to: Controller
Model Key Path: self.number (number is the ivar) (self presumably  
being the controller)


This didn't work.


Leave out the "self.".  Just use "number".


Unfortunately, I am also confused about the intended receiver for  
addObserver: forKeyPath:. I thought it would be the ivar (number),  
but I get a warning that NSNumber may not respond to that method  
(and sure enough the docs show that it doesn't). Logically, the  
second text field should "observe" that the model/controller ivar  
(number) has changed. But I thought you were not supposed to use  
outlets either.


There are two common misconceptions here:

1) KVO is not for observing properties, as such.  It's for observing  
the object which _has_ the property.  To put it another way: I don't  
observe the number, I observe the controller for changes in its  
number property.


2) A property is _not_ the ivar.  The ivar, if it exists at all, is  
an implementation detail of how the class implements the property.  A  
property is part of the interface of the object.  You will find it  
much easier if you conceptualize a property as the set of KVC- 
conforming methods in the object's interface.  A "key" is a string  
naming or identifying a property.  (Yes, KVC and KVO provide built-in  
support for properties which don't have accessor methods.  They will  
access the ivar directly.  However, this is just a convenience and a  
fall-back position.  It doesn't materially change how you should  
conceptualize properties.)


To illustrate:

@interface Foo : NSObject
{
NSNumber* number;   //  <--  This is NOT the property
}

// _These_ are the property:
- (NSNumber*) number;
- (void) setNumber:(NSNumber*)newNumber;

@end


// ... in some other code somewhere

Foo* myFoo = /* ... */
[myFoo addObserver:self forKeyPath:@"number"];

This object (self) is observing the myFoo object for changes in its  
"number" property.



Think also about the KVO notifications you will receive:

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id) 
object change:(NSDictionary *)change context:(void *)context;


Think about what you will be receiving in the "object" parameter of  
that.  You're not interested in knowing that some anonymous, free- 
floating NSNumber object has changed; you need to be informed which  
object has had its "number" property changed.  So, in this case, it  
would be the Foo object which was myFoo in the above snippet.  That's  
why you need to conceptualize KVO as observing the object which has  
the property, not as observing the property (or ivar) itself.


Consider the possibility that I use a plain "int" instead of an  
NSNumber as the backing store for the number property of a Foo.   
Surely, the "object" parameter of the observeValueForKeyPath...  
method can't be that int, because an int isn't an object.   
Furthermore, consider if there is _no_ backing storage for the number  
property of a Foo.  What if I changed the above @interface to omit  
the "number" ivar.  Foo still has a "number" property.  Its meaning/ 
value is whatever results from the semantics of the two methods - 
number and -setNumber:.  In theory, they could compute the value on  
the fly, call some library API, or even query a remote server to  
determine the value.  They could do anything and it need not involve  
an ivar of any sort.



Lastly, I want to address a confusion that I've seen at other times  
on this list (but which you didn't express).  Often people have a  
class with an NSMutableArray ivar, and they get confused as to why  
modifications that they make directly to that ivar (as by - 
addObject:, for example) don't result in KVO notifications and  
updates to the bound GUI elements.  The reason is that nothing is  
observing that array.  They are observing the owning object for  
changes of the property for which that ivar is backing storage.


The array does not (and can not) send out KVO notifications.  For one  
thing, it doesn't know what object owns it nor what property it  
represents.  The owning object is what sends out the KVO  
notifications.  In order for it to do that, the owning object must be  
messaged.  It might be messaged with a KV

Re: Bypassing Interface Builder


...also late joing this thread

I have just spent the best part of five months learning enough  
objective-c and cocoa to create useful apps.
I have been programming for 30 plus years and this has been the most  
difficult learning experience of my life.
It is not just IB but also Project Builder and Xcode and now Xcode  
under Leopard. And Objective-C also has its little ways.


I have no idea how the rest of you gained your expertise but working  
on my own, even with the help of books and the internet it has been  
an absolute nightmare. One problem intially was with IB itself which  
wanted me to drag from controls to outlets etc. and which I found  
very hard to learn and books like Cocoa Programming for Mac OSX and  
Vermont recipes were very hard going. Perhaps it was their  
verbosity, or the learning by rote. The examples on the internet are  
not that plentiful and it takes a long time to find one's way around.


Now under Leopard people should find IB easier to learn because the  
emphasis is on creating the header files first and this is easier to  
understand. I could say masses more about this learning hell but  
will desist except to say it is not over yet. When I moved over to  
Leopard the compiler ceased to assign the proper type to the  
variables passed in dynamically typed  messages. And I still have  
not solved this!!!


So I write merely to give heart to others. The learning nightmare  
does ease over time but never forget the system's tendency every now  
and then to send you right back to square one.



All this said, cocoa and Objective-C is beautiful. I just wish it  
were easier to learn.


Big +1 to all you just said.

As soon as it gets a little more complicated or something is not  
working as you would expect I get this "blackbox" feeling. Just today  
IB3.1 failed on me miserably ...and I had no clue what to do. After  
some fiddling "ibtool" saved the day. But hell - while it's slowly  
getting better, really good examples and docs are still scarce.That  
said the cocoacast screencast are priceless. And http:// 
www.cocoadev.com has some good information behind its ugly shell. The  
Apple docs are extensive but it's hard to start from there. Sucks that  
some of their videos are only available with (paid) ADC membership.  
This mailing list is a great resource ...but maybe there is a reason  
why even simple things get asked again and again.


I just can't believe how long it took me come up get shell script  
executed without all pipe filling deadlock problems and so on. This is  
so basic stuff and I wasted hours on that. Or take  
NSMailDelivery ...it's deprecated - great. But do the docs state what  
else to use? Just last week this came up a couple of times.


Well, lots of Cocoa tips and tricks to blog about I guess ;)

It surely is a steep learning curve - somehow I still like getting  
into it. Scary! See you at WWDC :)


cheers
--
Torsten
http://vafer.org/blog
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Problem binding to recreated NSCollectionView

2008-05-14 Thread David Carlisle

I'm trying to recreate NSCollectionView from scratch so I can  
customize the animations.  I have a problem in binding the array  
controller arrangedObjects to the content of MyCollectionView.


In a test situation where I have an instance of both MyCollectionView  
and NSCollectionView bound to the same array controller, when the  
content of the array controller is updated, it will call  
NSCollectionView setContent, content, content, content.  Then it will  
call MyCollectionView content.  It should be calling MyCollectionView  
setContent, but it doesn't.


NSCollectionView is bound to the array controller through IB.   
MyCollectionView is bound manually to the array controller in  
windowDidLoad of the window controller.  At the time of binding,  
MyCollectionView setContent is called, allowing me to create the  
initial content of the view from the array passed to setContent.   
Updates to the content of the array controller are not forwarded to  
MyCollectionView.


F-Script says the content of both views are bound to the same array  
controller at path arrangedObjects.  In the case of NSCollectionView  
it adds that the value class is NSObject, a detail which does not  
appear in the case of MyCollectionView.  The dictionary shows the same  
options in both cases.


Any thoughts?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Launching Cocoa Application externally (Yann Disser)

2008-05-14 Thread Peter Hudson


Here's a few suggestions

a) Check your settings in project   ( as in project -> edit project  
settings )

Check that your target platform and  lib selection is OK.
Ensure that you are not zero linking.

b) Do a completely clean build -  i.e. close the project and drop the  
build directory into the trash.

Do a deployment build.

c) Do you get anything written to the system log from the app  
( before it crashes )  ?


d) If your NSApp has a delegate, try and put an NSLog or two into it  
somewhere and see if they get printed out.



(PH)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Setting default application for URL scheme



On May 14, 2008, at 1:16 PM, Matthew Gertner wrote:


I'd like to set the application that should be run when a URL with a
given scheme is opened. The only way I've found to do this is
_LSSetDefaultSchemeHandlerURL, but I'd rather not go with an
undocumented API if it can be avoided. Is there a Cocoa API or
something for this that I haven't been able to find? Or would I be
better off using the Cocoa APIs to modify the launch services database
directly?



There is no Cocoa API. The only supported way of doing this is to use  
LSSetDefaultHandlerForURLScheme(), which requires Tiger or later.  
Prior to Tiger, you had to use Internet Config to do that.


Nick Zitzmann


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Bypassing Interface Builder


Might there be not a tutorial but more documented examples of creating
a window, calling to the window, adding widgets(buttons and such) and
altering an NSCustomView.

My goal is to make a drawing app from the Drawkit framework but for
the life of me I just can't get past the use IB but Drawkit does not
use IB but the books do and swear that I should fiasco! Ah ha ha ha ha
h haha h  hah aa haa
Sorry to be coming in late when this discussion seems all over and  
especially that I have nothing technical to contribute.

I do want however to say that I understand colo's frustration with IB.

I have just spent the best part of five months learning enough  
objective-c and cocoa to create useful apps.
I have been programming for 30 plus years and this has been the most  
difficult learning experience of my life.
It is not just IB but also Project Builder and Xcode and now Xcode  
under Leopard. And Objective-C also has its little ways.


I have no idea how the rest of you gained your expertise but working  
on my own, even with the help of books and the internet it has been  
an absolute nightmare. One problem intially was with IB itself which  
wanted me to drag from controls to outlets etc. and which I found  
very hard to learn and books like Cocoa Programming for Mac OSX and  
Vermont recipes were very hard going. Perhaps it was their verbosity,  
or the learning by rote. The examples on the internet are not that  
plentiful and it takes a long time to find one's way around.


Now under Leopard people should find IB easier to learn because the  
emphasis is on creating the header files first and this is easier to  
understand. I could say masses more about this learning hell but will  
desist except to say it is not over yet. When I moved over to Leopard  
the compiler ceased to assign the proper type to the variables passed  
in dynamically typed  messages. And I still have not solved this!!!


So I write merely to give heart to others. The learning nightmare  
does ease over time but never forget the system's tendency every now  
and then to send you right back to square one.


All this said, cocoa and Objective-C is beautiful. I just wish it  
were easier to learn.


Julius


http://juliuspaintings.co.uk



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: messaging the object that allocated an object


On May 14, 2008, at 12:43 PM, James Churchman wrote:
WebViewController *webViewController = [[WebViewController alloc]  
init];



So now i have all my code running in my "webViewController" controller
object, but i really need to call a method that is in the "
MainViewController", which is in the the class "above",
that actually initialized the "webViewController".

(in fact i really want to message something in AppDelegate but  
allowing me

to message the class "above" should allow me
to extend this principle up future)


How is this posible, can i pass an id of the "parent"
(MainViewController) object
to the webViewController that will allow it to pass messages back  
to it?


There's no "automatic" way for an object to receive a pointer to the  
object which allocated it.  You can pass it in explicitly.  To  
accomplish that, you would implement an alternative initializer  
method which takes the pointer as a parameter.  Something like:


- (id) initWithRelatedObject:(MyClass*)relatedObject
{
// ...
}

The internals of that initializer method would look mostly the same  
as a typical initializer but would probably make use of relatedObject  
somehow.  You should read up on the whole topic of designated  
initializers, though, to make sure you cover your bases properly.   
You want to take care of the possibility that a client of your  
WebViewController will try to use one of the initializers of the  
superclass, and you want your new initializer to invoke the proper  
initializer of the superclass.



That said, if you want to access the delegate of the main application  
object, you can just use [NSApp delegate] to obtain it.  That may be  
a more appropriate design, depending on what you're actually trying  
to achieve.


Cheers,
Ken
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Setting default application for URL scheme

2008-05-14 Thread Matthew Gertner

Hi,

I'd like to set the application that should be run when a URL with a
given scheme is opened. The only way I've found to do this is
_LSSetDefaultSchemeHandlerURL, but I'd rather not go with an
undocumented API if it can be avoided. Is there a Cocoa API or
something for this that I haven't been able to find? Or would I be
better off using the Cocoa APIs to modify the launch services database
directly?

Thanks,
Matt
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

basic bindings question


Hi All,

I'm trying to get my feet wet with bindings and want to try something  
simpler than the mail example provided online.


All I'm trying to do is to replace the target-action-outlet approach  
with bindings in the simplest case I can think of: a text field whose  
value would correspond to an ivar in the controller. One text field  
would receive the number, a button would click, pass the number to the  
ivar, and redisplay that value in another text field.


First off, is it possible possible to bind directly to an instance  
variable in the controller? In my hyper-basic example, I'm collapsing  
M and C. I thought doing so should be OK, so I tried:


Bind to: Controller
Model Key Path: self.number (number is the ivar) (self presumably  
being the controller)


This didn't work.

Unfortunately, I am also confused about the intended receiver for  
addObserver: forKeyPath:. I thought it would be the ivar (number), but  
I get a warning that NSNumber may not respond to that method (and sure  
enough the docs show that it doesn't). Logically, the second text  
field should "observe" that the model/controller ivar (number) has  
changed. But I thought you were not supposed to use outlets either.


Does this mean you can only use bindings for arrays? Clearly that  
can't be right


If anyone knows of a "hyper-simple" example dispensing with tables and  
arrays, I'd really appreciate the link


Thanks.

Daniel
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Launching Cocoa Application externally

2008-05-14 Thread Jean-Daniel Dupas



Le 14 mai 08 à 19:56, Stuart Malin a écrit :



On May 14, 2008, at 5:55 AM, [EMAIL PROTECTED] wrote:


The App runs fine in gdb and even writes the output file.

Still the same error (crash and no output written) when running it
with "open MyApp.app".

Yann


Have you built a deployment (Release) version? Unless you have done  
so, a Debug version will run fine under Xcode, but not standalone  
because of zerolink (possibly among other reasons). Use the  
"Project" menu --> "Set Active Build Configuration" to set this.



Note that zero-link was removed in Xcode 3.0 and no longer exists.

As I said, the crash log will probably help to find what goes wrong.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

show/hide NSTabView

While the code below seemed to have worked OK for showing/hiding a  
NSTextView I am now not really sure what's going on when using it on a  
NSTabView.


- (void) showDetails:(BOOL)show animate:(BOOL)animate
{
NSSize fullSize = NSMakeSize(455, 302);

NSRect windowFrame = [[self window] frame];

if (show) {

[tabView setFrameSize:fullSize];
[tabView setNeedsDisplay:YES];
windowFrame.origin.y -= fullSize.height;
windowFrame.size.height += fullSize.height;
[[self window] setFrame: windowFrame
display: YES
animate: animate];

} else {
[tabView setFrameSize:NSMakeSize(0,0)];
[tabView setNeedsDisplay:YES];
windowFrame.origin.y += fullSize.height;
windowFrame.size.height -= fullSize.height;
[[self window] setFrame: windowFrame
display: YES
animate: animate];

}

NSRect tabFrame = [tabView frame];

NSLog(@"(%f,%f) (%fx%f)", tabFrame.origin.x,  
tabFrame.origin.y, tabFrame.size.width, tabFrame.size.height);

}

While hiding works just fine ...when shown again the tabFrame height  
turns out to be 604 ...so double of what I was setting.


Now I thought that this might be related to the "autoresize subviews"  
setting in IB. But for whatever reason I cannot unset it.

I save it and when I open the NIB in IB again ...it's back checked.

What's going on?

cheers
--
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Conditionally modifying NIBs?

2008-05-14 Thread Mike Fischer


Am 14.05.2008 um 20:11 schrieb David Wilson:

On Wed, May 14, 2008 at 1:37 PM, Mike Fischer  
<[EMAIL PROTECTED]> wrote:


Details:
Let's say I have a project which includes a nib N1 which builds a  
target T1.
Now I want to add a new target T2 which builds a variant of of T1  
that adds

some elements to nib N1 and removes some others (N2).


Given that you don't want to maintain two separate nibs, I would boil
down the overlap between N1 and N2 into a new nib, N0, that contains
only those elements that exist in both. Depending on the extent of the
non-overlapping pieces, they can either be created programmatically
after N0 is loaded depending on which target is running, or nibs N1
and N2 can contain the remaining pieces such that they can be loaded
in and spliced into N0 (adding new views to tab views, etc etc. If you
design the nib and interface properly to segregate the common and
target-specific functionality, this should be fairly straightforward.


Yes, I had thought about that possibility. If it is just a view or a  
subview (an area in a view) this is probably easy to do. It gets more  
complicated if there are other objects in the nib that need to be  
connected. Not impossible to do though.


Also it moves the work needed to "do" the target specific  
modification to run-time instead of build-time. Not that this would  
usually be a huge amount of much work, but it is somewhat wasteful.  
In addition to the work special code is also needed for this,  
bloating the app with stuff that should not really be necessary.



Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Note: I read this list in digest mode!
  Send me a private copy for faster responses.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: xcode crashes on adding an embedded framework

2008-05-14 Thread j o a r



On May 14, 2008, at 11:23 AM, Albert Jordan wrote:

I'm having a problem with crashes with xcode.  how can i post the  
problem?


over the week-end I downloaded and used Skype framework in some  
applications.  Then, by accident, I believe I delete the skype  
framework.  I discovered this by noticing the Skype framework was  
highlighted in red.  I deleted the framework in xcode, and attempted  
to add the framework again.  Now xcode crashes anytime I'm trying to  
do this.  Even if I open a brand new application, and try and add a  
framework xcode crashes.



Please file a bug report here:



In the future, you might want to direct messages of this type to the  
"Xcode-Users" mailing list.
If you post more information about your crash there, someone might be  
able to suggest a workaround. But even so, you should still file a  
formal bug report. Don't forget to include information about the  
version of Mac OS X and Xcode that you're using.


Thanks,

j o a r


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: xcode crashes on adding an embedded framework

On Wed, May 14, 2008 at 2:23 PM, Albert Jordan <[EMAIL PROTECTED]> wrote:
> I'm having a problem with crashes with xcode.  how can i post the problem?

  There've been few XCode-specific threads on this list lately that
have nothing to do with Cocoa. You'd probably get better help posting
to the xcode-users list, where it's more on-topic.

--
I.S.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

xcode crashes on adding an embedded framework

2008-05-14 Thread Albert Jordan

I'm having a problem with crashes with xcode.  how can i post the  
problem?


over the week-end I downloaded and used Skype framework in some  
applications.  Then, by accident, I believe I delete the skype  
framework.  I discovered this by noticing the Skype framework was  
highlighted in red.  I deleted the framework in xcode, and attempted  
to add the framework again.  Now xcode crashes anytime I'm trying to  
do this.  Even if I open a brand new application, and try and add a  
framework xcode crashes.


I need help.

Thanks

Albert Jordan


albert jordan
[EMAIL PROTECTED]



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Efficient XML loading [continuation of NSString from mapped NSData thread]

2008-05-14 Thread Louis Gerbarg

NSXMLParser needs to load everything into ram first, then it starts
generating its stream of events. I recommend filing a bug asking for
it to be enhanced to support incrementally available data. It will
definitely be a dupe (I've filed it, among others I am sure)., but the
more people who ask for it, the more likely it will get engineering
resources.

For situations where you have slow connections, high latency, large
documents, and/or limited ram being able to work with the file as a
stream is definitely a competitive advantage. While I (and a lot of
other people, I am certain) have written libxml2 interfaces to achieve
that, I would much rather just use NSXMLParser in the future.

Louis

On Wed, May 14, 2008 at 11:04 AM, Jens Alfke <[EMAIL PROTECTED]> wrote:

> I am nearly always cheerfully willing to give out source code, but in this
> case I kind of see this as a competitive advantage for a product I might
> release in the future, so I'm going to keep the code to myself. It isn't
> brain surgery, or even rocket science, but it took some work; libxml2 is a
> lot lower-level than the plist API. (I didn't try using NSXMLParser, which
> is an Obj-C wrapper around libxml2; that might get you comparable
> performance with less pain.)
>
> —Jens
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/lgerbarg%40gmail.com
>
> This email sent to [EMAIL PROTECTED]
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Conditionally modifying NIBs?

2008-05-14 Thread David Wilson

On Wed, May 14, 2008 at 1:37 PM, Mike Fischer <[EMAIL PROTECTED]> wrote:
>
> Details:
> Let's say I have a project which includes a nib N1 which builds a target T1.
> Now I want to add a new target T2 which builds a variant of of T1 that adds
> some elements to nib N1 and removes some others (N2).

Given that you don't want to maintain two separate nibs, I would boil
down the overlap between N1 and N2 into a new nib, N0, that contains
only those elements that exist in both. Depending on the extent of the
non-overlapping pieces, they can either be created programmatically
after N0 is loaded depending on which target is running, or nibs N1
and N2 can contain the remaining pieces such that they can be loaded
in and spliced into N0 (adding new views to tab views, etc etc. If you
design the nib and interface properly to segregate the common and
target-specific functionality, this should be fairly straightforward.

-- 
- David T. Wilson
[EMAIL PROTECTED]
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Launching Cocoa Application externally

2008-05-14 Thread Stuart Malin



On May 14, 2008, at 5:55 AM, [EMAIL PROTECTED] wrote:


The App runs fine in gdb and even writes the output file.

Still the same error (crash and no output written) when running it
with "open MyApp.app".

Yann


Have you built a deployment (Release) version? Unless you have done  
so, a Debug version will run fine under Xcode, but not standalone  
because of zerolink (possibly among other reasons). Use the "Project"  
menu --> "Set Active Build Configuration" to set this.




On 14. May 2008, at 16:47, Jens Alfke wrote:



On 14 May '08, at 6:48 AM, Yann Disser wrote:


How can I debug my App from Finder (or Terminal) to see where it
crashes? (printf("hallo\n") doesn't work either)


From a shell, enter "gdb MyApp.app", then "run".

I would suspect a dyld error, like a framework/library not found.
The Finder / LaunchServices is really bad at reporting these.
Running the app from a shell or gdb should report more useful info.


On 14 May '08, at 6:55 AM, Stéphane wrote:

There's a bug in your code or in your Info.plist.


Actually I think we could answer almost all of the questions on this
list that way ;-)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSRectFillListWithColors question