Re: A Question on estimating +arrayWithCapacity
On Jan 9, 2009, at 7:11 PM, Ashley Clark wrote: This should apply to NSNumber and NSDecimalNumber too right? Yet the NSNumber +numberWith... methods are declared to return (NSNumber *) and when called on NSDecimalNumber they return NSDecimalNumber objects which then have to be typecast. The need for a typecast indicates that you are using the API incorrectly. That the +numberWith...: variants are declared as returning (NSNumber *) is very likely an explicit indication as to their purpose and limitations. That it seemingly works by the use of typecasting is a coincidence of implementation. Instead, you should use one of the following methods to create NSDecimalNumbers: + (NSDecimalNumber *)decimalNumberWithMantissa:(unsigned long long)mantissa exponent:(short)exponent isNegative:(BOOL)flag; + (NSDecimalNumber *)decimalNumberWithDecimal:(NSDecimal)dcm; + (NSDecimalNumber *)decimalNumberWithString:(NSString *)numberValue; + (NSDecimalNumber *)decimalNumberWithString:(NSString *)numberValue locale:(id)locale; + (NSDecimalNumber *)zero; + (NSDecimalNumber *)one; + (NSDecimalNumber *)minimumDecimalNumber; + (NSDecimalNumber *)maximumDecimalNumber; + (NSDecimalNumber *)notANumber; If you don't like the declared behavior of the classes, file a bug -- http://bugreporter.apple.com/ -- with a description of the change desired (and an example, if possible). 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
Thanks for all your responses. I am indeed using synthesized properties which hopefully will free me from having to do play around with retain/release. How anyone can get any work done without an automatic GC is unclear to me - you guys are hard core ;) Prior to embarking on Cocoa development, I was sceptical about the garbage collector - like, it's still very much possible to create memory leaks. It's not the end of memory leaks, as the Java docs made it out to be. However, now that I am without it, I can fully appreciate how great it really is ;) I am just going to use the aParameter naming scheme, since that seems to be the standard. The trick with naming the member variable _memberVar is a little bit too clever for me, I think ;) Nik ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On 10 Jan 2009, at 00:11, Adam Foltzer wrote: I've noticed a pattern in some Apple code where the instance variables are all prefixed with an underscore, but the property name, and therefore the accessors, are what you'd expect. Except that there's a long-standing rule that we shouldn't use leading underscores for either member variable names or private method names because names beginning with underscore are reserved for Apple's own use (even member variable names, IIRC). So if you're going to use a prefix, it's probably best to pick something like m (for member). But in general I think it's better not to prefix the names of member variables, and then in your initialisers, to use a different name for the argument. Kind regards, Alastair. -- http://alastairs-place.net ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On 10 Jan 2009, at 00:40, Kyle Sluder wrote:
On Fri, Jan 9, 2009 at 7:11 PM, Adam Foltzer acfolt...@gmail.com
wrote:
- (id)initWithInt:(int)foo
{
if (![super init])
return nil;
[self setFoo:foo];
return self;
}
Do not use getters and setters in -init. You should be accessing the
ivars directly.
While we're on this topic, I think a more important problem with the
above is the assumption that [super init] either returns nil or the
current value of self.
It should of course be
if ((self = [super init])) {
// Initialise
}
return self;
or some equivalent construct.
Kind regards,
Alastair.
--
http://alastairs-place.net
___
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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Jan 10, 2009, at 6:45 AM, Alastair Houghton wrote:
On 10 Jan 2009, at 00:11, Adam Foltzer wrote:
I've noticed a pattern in some Apple code where the instance
variables are
all prefixed with an underscore, but the property name, and
therefore the
accessors, are what you'd expect.
Except that there's a long-standing rule that we shouldn't use
leading underscores for either member variable names or private
method names because names beginning with underscore are reserved
for Apple's own use (even member variable names, IIRC). So if
you're going to use a prefix, it's probably best to pick something
like m (for member).
But in general I think it's better not to prefix the names of member
variables, and then in your initialisers, to use a different name
for the argument.
My personal pattern is to leave the ivars as-is. Then, for
parameters, I prefix with 'a' or 'an'. Local variables are prefixed
with 'the':
'value' is the name of the ivar...
- (void)incrementBy:(int)aValue
{
int theOldValue = value;
value = aValue;
if (aValue != theOldValue)
...
}
___
Ricky A. Sharp mailto:rsh...@instantinteractive.com
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 arch...@mail-archive.com
Re: changeKeyPath method documentation
On Jan 9, 2009, at 1:44 PM, Russell Martin wrote: Hi. I'm completely new to the list and this is my first question. I'm working through Aaron Hillegass' Cocoa Programming For Mac OS X (3rd Ed) and I'm near the end of chapter 9 (pg 148) where it is shown to make use of the changeKeyPath method. I'm in the habit of right clicking on method names and choosing Find selected text in API reference/in documenation. When I do this for changeKeyPath, nothing comes up on my machine? Can anyone enlighten me as to where changeKeyPath is documented? I'm neurotic in that, I don't like seeing something said in a language and not knowing how/where I can reference the docs myself. Thanks in advance to any kind knowledgeable person out there who will shed some light on this for me. :-) I believe that this is a method that you define as part of the exercise and is not part of the API. ___ 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 arch...@mail-archive.com
Re: changeKeyPath method documentation
I'm working through Aaron Hillegass' Cocoa Programming For Mac OS X (3rd Ed) and I'm near the end of chapter 9 (pg 148) where it is shown to make use of the changeKeyPath method. I'm in the habit of right clicking on method names and choosing Find selected text in API reference/in documenation. When I do this for changeKeyPath, nothing comes up on my machine? This is because changeKeyPath:ofObject:toValue is new method in the application. It is a little confusing. The implementation of the Cocoa method observeValueForKeyPath:ofObject:change:context registers the call to changeKeyPath:ofObject:toValue to be called later if an undo occurs. It is all a bit confusing since the book shows the implementation of the changeKeyPath:ofObject:toValue: before it shows how it will get called. Read about this in the Undo Architecture documentation. mkd ___ 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 arch...@mail-archive.com
Re: Any nice way to quit a background/helper app?
On Sat, Jan 10, 2009 at 10:15 AM, Jerry Krinock je...@ieee.org wrote: Is there a way to quit a background app, other than having NSTask send a unix 'kill' ? Yeah: you can call the function kill(). man 2 kill ___ 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 arch...@mail-archive.com
Re: accessing ivars in - (id)init
On Sat, Jan 10, 2009 at 12:09 AM, Kyle Sluder kyle.slu...@gmail.com wrote: On Fri, Jan 9, 2009 at 11:49 PM, Michael Ash michael@gmail.com wrote: Note that the problems, such as they are, with calling setters only show up if your class is subclassed and the subclass does something weird that doesn't like being called when the rest of the subclass isn't initialized. If you're not subclassing your own class (or you are but you aren't doing anything weird like this in it) then you are perfectly safe. So what happens if Apple changes your superclass to observe itself? All of a sudden you start firing KVO notifications off when you didn't mean to. Your superclass is fully initialized by this point. It should be able to handle any KVO notifications arriving without any trouble. Furthermore, if it's observing itself it's presumably because it wants to know when the value changes. (That's the whole point of the thing, after all.) Triggering the observer is therefore a *good* thing, and bypassing it is likely to cause problems. The problem isn't with superclasses, it's with subclasses. And they only have a problem if they are behaving in a manner which, in my opinion, is buggy. Opinions may vary there, but regardless of that, the facts are that calling your superclass's setter is the right way to do things. Mike ___ 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 arch...@mail-archive.com
Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]
On Sat, Jan 10, 2009 at 12:56 AM, Andrew Farmer andf...@gmail.com wrote: Not to mention, there is no guarantee that future versions of the compiler will behave identically when processing code that generates warnings. It is not uncommon for warnings to later turn into errors, or (worse!) incorrect behavior, especially when optimizations are involved. Just to pick a nit, this depends greatly on what the warning is about. A lot of warnings are actually about code whose behavior is fully specified by the standard but which is still considered to be iffy. For example, writing if(a = b) will generate a warning under -Wall but its behavior is fully specified and cannot change in any conforming compiler. However it's still a good idea to fix them, and many warnings *are* about code whose behavior could change. Mike ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Sat, Jan 10, 2009 at 7:45 AM, Alastair Houghton alast...@alastairs-place.net wrote: On 10 Jan 2009, at 00:11, Adam Foltzer wrote: I've noticed a pattern in some Apple code where the instance variables are all prefixed with an underscore, but the property name, and therefore the accessors, are what you'd expect. Except that there's a long-standing rule that we shouldn't use leading underscores for either member variable names or private method names because names beginning with underscore are reserved for Apple's own use (even member variable names, IIRC). So if you're going to use a prefix, it's probably best to pick something like m (for member). But in general I think it's better not to prefix the names of member variables, and then in your initialisers, to use a different name for the argument. Personally I have found that prefixing my instance variables is one of the best things I've ever done for code clarity. Being able to instantly tell that a particular variable is an instance variable or not is extremely valuable, at least to me. Tastes may vary. As for underscore being reserved, I have never been able to figure out any consequence of a conflict with an Apple ivar name. It may cause your source to fail to compile, but it won't cause any *binary* compatibility problems, which is the real menace. Mike ___ 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 arch...@mail-archive.com
Re: Any nice way to quit a background/helper app?
Stephen J. Butler (stephen.but...@gmail.com) on 2009-01-10 11:18 AM said:
Is there a way to quit a background app, other than having NSTask send a
unix 'kill' ?
Yeah: you can call the function kill(). man 2 kill
That's not a 'nice way', as requested in the subject. :)
The nice way is to send a quit AppleEvent, which you can do like so:
static OSStatus SendQuitAppleEventToProcess (ProcessSerialNumber psn)
{
OSStatuserr = paramErr;
NSAppleEventDescriptor* applicationDesc = [NSAppleEventDescriptor
descriptorWithDescriptorType:typeProcessSerialNumber
bytes:psn
length:sizeof(psn)];
if (applicationDesc) {
NSAppleEventDescriptor* quitAppAppleEvent =
[NSAppleEventDescriptor
appleEventWithEventClass:kCoreEventClass
eventID:kAEQuitApplication
targetDescriptor:applicationDesc
returnID:kAutoGenerateReturnID
transactionID:kAnyTransactionID];
AppleEvent* quitApplicationAppleEventPtr =
(AEDesc*)[quitAppAppleEvent
aeDesc];
if (quitApplicationAppleEventPtr) {
AppleEvent replyEvent;
err = AESendMessage (quitApplicationAppleEventPtr,
replyEvent,
kAEWaitReply, kAEDefaultTimeout);
if (!err) {
AEDisposeDesc (replyEvent);
}
}
}
return err;
}
You can usually get a psn event for 'background apps'. See
GetProcessForPID(). There's also KillProcess() if it does not respond
to the quit event.
Sean
___
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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On 10 Jan 2009, at 16:48, Michael Ash wrote: As for underscore being reserved, I have never been able to figure out any consequence of a conflict with an Apple ivar name. It may cause your source to fail to compile, but it won't cause any *binary* compatibility problems, which is the real menace. I *think* the problem here is introspection... if you subclass an Apple provided class and add an instance variable with the same name as one of theirs, it's possible that any of the dynamic mechanisms the frameworks (or, for that matter, your own code) use to get the value of an object property might use the wrong variable, with unexpected results. Kind regards, Alastair. -- http://alastairs-place.net ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Sat, Jan 10, 2009 at 12:08 PM, Alastair Houghton alast...@alastairs-place.net wrote: On 10 Jan 2009, at 16:48, Michael Ash wrote: As for underscore being reserved, I have never been able to figure out any consequence of a conflict with an Apple ivar name. It may cause your source to fail to compile, but it won't cause any *binary* compatibility problems, which is the real menace. I *think* the problem here is introspection... if you subclass an Apple provided class and add an instance variable with the same name as one of theirs, it's possible that any of the dynamic mechanisms the frameworks (or, for that matter, your own code) use to get the value of an object property might use the wrong variable, with unexpected results. Not using an underscore won't save you here. Mechanisms like KVC will look for ivars both with and without the underscore. In fact, leaving off the underscore makes things worse: with the underscore, the compiler will at least error when you try to recompile later on, whereas without it the conflict will exist silently. A cow-orker just pointed out to me that Apple does not, in fact, recommend against an underscore prefix for instance variables. They do recommend against them for private methods, but that's a completely different question. It seems that the well-known recommendation against _ivars is actually a misconception! If I'm wrong and just missed it, I'd like to know where it says so. But no trace of such a recommendation in Coding Guidelines for Cocoa: Naming Instance Variables and Data Types: http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284 Mike ___ 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 arch...@mail-archive.com
performSelectorOnMainThread
-performSelectorOnMainThread:withObject:waitUntilDone:, according to
Apple docs, is passed a SEL method that should not have a significant
return value.
I wish it to return a INT and I figure that that qualifies as in-
significant. Given that assumption, my real question is how to
implement it. I call:
[self performSelectorOnMainThread:@selector:mySimpleSelector
withObject:nil waitUntilDone:YES];
(int) mySimpleSelector {
if (whatever) return 0;
else return 1;
}
via my call to -performSelectorOnMainThread, just how do I access -
mySimpleSelector's returned INT? The simplest answer is to not have a
return value at all, but rather store the INTs in a global; but I
figure there is no time like the present to learn to solve this
problem the right 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 arch...@mail-archive.com
Re: performSelectorOnMainThread
Don't try to return it but work with 'call by reference' (in stead of
call by value).
Note: use also a class and not a primitive type, for example: NSNumber
CodingMammoth
Jelle De Laender
i...@codingmammoth.com
On 10 Jan 2009, at 20:00, John Love wrote:
-performSelectorOnMainThread:withObject:waitUntilDone:, according to
Apple docs, is passed a SEL method that should not have a
significant return value.
I wish it to return a INT and I figure that that qualifies as in-
significant. Given that assumption, my real question is how to
implement it. I call:
[self performSelectorOnMainThread:@selector:mySimpleSelector
withObject:nil waitUntilDone:YES];
(int) mySimpleSelector {
if (whatever) return 0;
else return 1;
}
via my call to -performSelectorOnMainThread, just how do I access -
mySimpleSelector's returned INT? The simplest answer is to not have
a return value at all, but rather store the INTs in a global; but I
figure there is no time like the present to learn to solve this
problem the right 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/info%40codingmammoth.com
This email sent to i...@codingmammoth.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 arch...@mail-archive.com
Re: performSelectorOnMainThread
On Jan 10, 2009, at 1:00 PM, John Love wrote:
-performSelectorOnMainThread:withObject:waitUntilDone:, according to
Apple docs, is passed a SEL method that should not have a
significant return value.
I wish it to return a INT and I figure that that qualifies as in-
significant. Given that assumption, my real question is how to
implement it. I call:
[self performSelectorOnMainThread:@selector:mySimpleSelector
withObject:nil waitUntilDone:YES];
(int) mySimpleSelector {
if (whatever) return 0;
else return 1;
}
via my call to -performSelectorOnMainThread, just how do I access -
mySimpleSelector's returned INT? The simplest answer is to not have
a return value at all, but rather store the INTs in a global; but I
figure there is no time like the present to learn to solve this
problem the right way.
The most general solution is to make an NSInvocation (a bit of a pain
the first dozen times you do it), and then have that invocation
performSelectorOnMainThread, with the @selector(invoke). Afterwards,
you can extract the return value from the invocation. This also gives
you the advantage of being able to call things with a much wider range
of number of parameters and parameter types (e.g., passing an NSRect).
(If waitUntilDone: NO is used, it's a bit trickier to figure out when
the thing is done - you'd probably want to use a semaphore - which is
one of the reasons that, in general, you shouldn't have a return value).
Glenn Andreas gandr...@gandreas.com
http://www.gandreas.com/ wicked fun!
JSXObjC | the easy way to unite JavaScript and Objective C
___
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 arch...@mail-archive.com
Re: performSelectorOnMainThread
On Jan 10, 2009, at 11:00, John Love wrote:
-performSelectorOnMainThread:withObject:waitUntilDone:, according to
Apple docs, is passed a SEL method that should not have a
significant return value.
I wish it to return a INT and I figure that that qualifies as in-
significant. Given that assumption, my real question is how to
implement it. I call:
[self performSelectorOnMainThread:@selector:mySimpleSelector
withObject:nil waitUntilDone:YES];
(int) mySimpleSelector {
if (whatever) return 0;
else return 1;
}
via my call to -performSelectorOnMainThread, just how do I access -
mySimpleSelector's returned INT? The simplest answer is to not have
a return value at all, but rather store the INTs in a global; but I
figure there is no time like the present to learn to solve this
problem the right way.
Here's how I do it. If someone has a cleverer way, I'd be happy to
adopt it. :)
- (void) doSomethingOnMainThread: (NSValue*) resultValue {
int* result = resultValue.pointerValue;
*result = // result of doing something ...
}
- (int) doSomething {
int result;
NSValue* resultValue = [NSValue valueWithPointer: result];
if (!resultValue)
return // something suitable
[self performSelectorOnMainThread: @selector
(doSomethingOnMainThread:) withObject: resultValue waitUntilDone:
YES];
return result;
}
___
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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Sat, Jan 10, 2009 at 12:39 PM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: On 10 Jan 2009, at 17:18, Michael Ash wrote: On Sat, Jan 10, 2009 at 12:08 PM, Alastair Houghton alast...@alastairs-place.net wrote: On 10 Jan 2009, at 16:48, Michael Ash wrote: As for underscore being reserved, I have never been able to figure out any consequence of a conflict with an Apple ivar name. It may cause your source to fail to compile, but it won't cause any *binary* compatibility problems, which is the real menace. I *think* the problem here is introspection... if you subclass an Apple provided class and add an instance variable with the same name as one of theirs, it's possible that any of the dynamic mechanisms the frameworks (or, for that matter, your own code) use to get the value of an object property might use the wrong variable, with unexpected results. Not using an underscore won't save you here. Mechanisms like KVC will look for ivars both with and without the underscore. In fact, leaving off the underscore makes things worse: with the underscore, the compiler will at least error when you try to recompile later on, whereas without it the conflict will exist silently. A cow-orker just pointed out to me that Apple does not, in fact, recommend against an underscore prefix for instance variables. They do recommend against them for private methods, but that's a completely different question. It seems that the well-known recommendation against _ivars is actually a misconception! If I'm wrong and just missed it, I'd like to know where it says so. But no trace of such a recommendation in Coding Guidelines for Cocoa: Naming Instance Variables and Data Types: http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284 For what it's worth Anguish et al states (p99) that Apple reserves the right to change private instance variables that begin with an underscore and no prefix. Anguish et al recommend and _ + unique prefix for ivars. I don't have whichever book you're referring to so I can't see what it actually says, but your summary makes no sense. Apple can't change *your* ivars. If it means they reserve the right to change their own private instance variables that begin with an underscore and no prefix, well of course, that's what private means. That's why you should never directly twiddle another class's ivars. But that has nothing to do with how you should name your own ivars. Mike ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Saturday, January 10, 2009, at 12:39PM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: For what it's worth Anguish et al states (p99) that Apple reserves the right to change private instance variables that begin with an underscore and no prefix. On Saturday, January 10, 2009, at 02:40PM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: I agree that it is confusing, or meaningless, but I thought it might have contributed to the _ misconception. A Google for - anguish underscores and usage - will show the passage I referred to. It sounds like the risk is that Apple could rename one of their _ivars so the new name collides with one of your _ivars that previously was okay. You would quickly discover this the next time you compile, but I assume existing users of your app would find it suddenly crashes after their last OS update. Anguish et al. recommend mitigating this risk by using a unique prefix in addition to the underscore. I personally don't worry too much about it. I doubt Apple would change the name of an ivar from _forFutureUse13 to _name. --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 arch...@mail-archive.com
Re: Any nice way to quit a background/helper app?
On 2009 Jan, 10, at 9:07, Sean McBride wrote: You can usually get a psn event for 'background apps'. See GetProcessForPID(). Thank you, Sean. The documentation for struct ProcessSerialNumber implied to me that background apps do not have a process serial number, and -[NSWorkspace launchedApplications] does not return them either. But using GetProcessForPID() as you suggested, I find that background apps do have a process serial number. I submitted Document Feedback on struct process serial number. Thanks, Jerry ___ 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 arch...@mail-archive.com
Re: What is the best way to copy files
David (enki1...@gmail.com) on 2009-01-10 4:23 PM said: I'm looking for what I think are some fairly common requirements from a file copy mechanism. - simple. Why write something if you can reuse. - support multi-threading so that you can stay responsive to the UI while copying large files. - good error handling. To be able to clearly handle and report errors. - provides ways to control, ie cancel a large file copy in progress. In that case, Foundation APIs will not help you. I suggest FSCopyObjectAsync or similar File Manager APIs. There are async options, good error reporting, etc. (The fact that these APIs are 'Carbon' (a vague term anyway) does not mean they are obsolete, a claim you may see sometimes.) Sean ___ 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 arch...@mail-archive.com
Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]
Michael Ash (michael@gmail.com) on 2009-01-10 11:46 AM said: However it's still a good idea to fix them, and many warnings *are* about code whose behavior could change. Then there is the annoying situation of a warning that is in general very useful, but sometimes warns in cases where you really don't want it to. My favourite example is when Cocoa has two methods with the same name that return different types. Like -(NSRect)frame vs -(CGRect)frame, or - (id)window vs -(NSWindow*)window, or -(NSUInteger)count vs -(size_t)count. For example: NSArrayController* controller = nil; NSUInteger c = [[controller arrangedObjects] count]; gives warning: multiple methods named '-count' found :( Sean ___ 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 arch...@mail-archive.com
Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]
On Sat, Jan 10, 2009 at 6:20 PM, Sean McBride cwat...@cam.org wrote: Michael Ash (michael@gmail.com) on 2009-01-10 11:46 AM said: My favourite example is when Cocoa has two methods with the same name that return different types. Like -(NSRect)frame vs -(CGRect)frame, or - (id)window vs -(NSWindow*)window, or -(NSUInteger)count vs -(size_t)count. If both methods don't return the same kind of thing (scalar vs. struct vs. float) then your program might go kablooey. --Kyle Sluder ___ 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 arch...@mail-archive.com
Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]
On 10 Jan 09, at 08:46, Michael Ash wrote: Just to pick a nit, this depends greatly on what the warning is about. A lot of warnings are actually about code whose behavior is fully specified by the standard but which is still considered to be iffy. For example, writing if(a = b) will generate a warning under -Wall but its behavior is fully specified and cannot change in any conforming compiler. However it's still a good idea to fix them, and many warnings *are* about code whose behavior could change. Excellent point. As you mention, though, it's usually best to just work around these sorts of warnings (in this case, with an extra set of parentheses), as it's quite common that this sort of code *is* a mistake on the part of the author. :) On 10 Jan 09, at 15:20, Sean McBride wrote: Then there is the annoying situation of a warning that is in general very useful, but sometimes warns in cases where you really don't want it to. My favourite example is when Cocoa has two methods with the same name that return different types. Like -(NSRect)frame vs -(CGRect)frame, or - (id)window vs -(NSWindow*)window, or -(NSUInteger)count vs - (size_t)count. For example: NSArrayController* controller = nil; NSUInteger c = [[controller arrangedObjects] count]; gives warning: multiple methods named '-count' found :( You can silence this one by casting the return value of the inner method to a more specific type. In this case, the fix is: NSUInteger c = [(NSArray *)[controller arrangedObjects] count]; As Kyle Sluder mentions, this warning has the potential to generate incorrect code, so the warning is entirely appropriate. ___ 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 arch...@mail-archive.com
CALayer, CATextLayer, and inheritance . . .
Ok, I think I'm hosed but I need one of you bright people to tell me just how bad it is. I'm working on a avionics simulation project that leverages Core Animation and layers in order to composite various elements of the display. These elements all have various behaviors and attributes based on the information they are meant to convey to the person reading them. For example, a compass displays directional information using values ranging from 0 to 359. I decided to abstract away the standard rotational transformation interface on a CALayer by creating a sub-class that knows about the compass interface. This subclass automatically converts degrees to radians, performs coordinate transformations in order to get rotation to happen in the proper direction, and sets up the associated animation, as well as handing delegate callbacks. At first it all seemed to work well, but when I created my first derived CATextLayer class, I began to have strange issues. I won't bore you with the details on that but here is the question: I'm allocating and initializing my sub-classed layers using the alloc and init methods: @interface CompassLayer : CALayer . . . @interface SpeedInfoLayer : CATextLayer . . . CompassLayer* c = [[CompassLayer alloc] init]; SpeedInfoLayer* si = [[SpeedInfoLayer alloc] init]; I know that the documentation states the CALayer entities are to be allocated with class methods: CALayer* l = [CALayer layer]; CATextLayer* tl = [CATextLayer layer]; Am I creating a problem by not allocating and initializing my layers using the class methods? -Michael -- We know as much about software quality problems as they knew about the Black Plague in the 1600s. We've seen the victims' agonies and helped burn the corpses. We don't know what causes it; we don't really know if there is only one disease. We just suffer - and keep pouring our sewage into our water supply. -- Unknown 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 arch...@mail-archive.com
Re: What's the most cocoa-ey pattern for this?
So I believe I figured out the most Cocoa-ey pattern to do this
tracking of time ranges. In 10.5, Apple added the NSTrackingArea to
NSView. This is exactly the analogous pattern; except in a view it's
2D with an offset, while what I'm interested in is time:1D with an
offset. To make it even more concrete, if the equivalent capability
was on QTMovie, I'd have what I want. To be specific, here's the bug
(radar 6487403) need QTTrackingTimeRange for QTMovie, like
NSTrackingArea for NSView
comments welcome (or file duplicate bug reports to express your
interest in seeing this as well :-)):
---
I propose a new class, called a QTTrackingTimeRange, modeled after
NSTrackingArea.
Analogous to how tracking rects are used in a NSView, this would be
used for time ranges in a QTMovie.
// note: I don't know what the QTTrackingTimeRangeOptions would be, if
any - assuming some bitwise-OR-able flags, probably expressing
interest in direction
@interface QTTrackingTimeRange : NSObject NSCopying, NSCoding {
}
- (QTTrackingTimeRange *)initWithTimeRange:(QTTimeRange)range options:
(QTTrackingTimeRangeOptions)options owner:(id)owner userInfo:
(NSDictionary *)userInfo;
@property QTTimeRange range;
@property (readonly) QTTrackingTimeRangeOptions options;
@property (readonly) owner;
@property (readonly) NSDictionary* userInfo;
@property (readonly) BOOL active;
@end
// category we are proposing for QTMovie:
@interface QTMovie(TrackingTimeRange)
- addTrackingTimeRange:(QTTrackingTimeRange*)trackingTimeRange;
- removeTrackingTimeRange:(QTTrackingTimeRange*)trackingTimeRange;
@end
// protocol for the owner object to implement to be notified as
these time ranges are exited or entered and from what direction (if
known)
@protocol QTTrackingTimeRangeOwner
- trackingTimeRangeEntered:(QTTrackingTimeRange*)trackingTimeRange
direction:(QTTrackingTimeRangeDirection)direction;
- trackingTimeRangeExited:(QTTrackingTimeRange*)trackingTimeRange
direction:(QTTrackingTimeRangeDirection)direction;
@end
enum {
QTTrackingTimeRangeDirectionForward,
QTTrackingTimeRangeDirectionBackward,
QTTrackingTimeRangeDirectionUnknown
};
typedef NSUInteger QTTrackingTimeRangeDirection;
-- Michael B. Johnson, PhD
-- http://homepage.mac.com/drwave (personal)
-- http://xenia.media.mit.edu/~wave (alum)
-- MPG Lead
-- Pixar Animation Studios
___
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 arch...@mail-archive.com
Re: IKImageBrowserView and the View Hierarchy
I finally came up with a simple work around to this problem, one which actually works better for my purposes: instead of adding a view to the window's view hierarchy, add a new child window to the window. The view ordering then works as expected and doesn't break (or get broken by) IKImageBrowserView. Hope that helps someone else, Jeffrey On Dec 28, 2008, at 11:02 PM, Jeffrey J. Early wrote: I have had a number of troubles with IKImageBrowserView not respecting other views trying to draw over the top of it. I have worked around some of the issues, but this latest I can't seem to resolve. I am trying to dim several of the views in my window by simply placing a translucent view over the top of them. This works as expected, *except* for the IKImageBrowserView... it always shines through and appears to be the top-most view. I did find that if I force the translucent view to be layer backed by -setWantLayer:YES, then the *background* of the IKImageBrowserView becomes appropriately dimmed, but the loaded images just disappear! This is *almost* repeatable with zero lines of code just using Interface Builder. You can drag an instance of IKImageBrowserView on a new window, then try to overlay another view, like an ImageWell or something. You'll see that the ImageWell is always below the IKImageBrowserView unless you tell it to be layer backed (although the layer-backing trick doesn't work in the simulator). What's going on here? IKImageBrowserView is clearly doing something fancy -- any ideas what that is and how I can get it to behave like a normal NSView? Thanks, Jeffrey ___ 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/jeffrey%40jeffreyearly.com This email sent to jeff...@jeffreyearly.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 arch...@mail-archive.com
Using Keychain during login
All, Is it possible to access the Keychain from an Authentication plugin during log in? I have the username and password from the plugin so I assume I can just use these to access the users keychain. Thanks for any help. Regards, Patrick ___ 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 arch...@mail-archive.com
Re: changeKeyPath method documentation
So, are you saying that changeKeyPath isn't an override or a delegate method? If so, then why don't I have to put a stub in the .h file? I thought that unless I was implementing an override or delegate method that the stub in the .h was required. Is my thinking wrong on this? And, if so, when is the stub in the .h file required and not required? Again, thanks for any info. --- On Sat, 1/10/09, Michael Donegan inva...@alumni.rice.edu wrote: From: Michael Donegan inva...@alumni.rice.edu Subject: Re: changeKeyPath method documentation To: cocoa-dev@lists.apple.com Date: Saturday, January 10, 2009, 8:46 AM I'm working through Aaron Hillegass' Cocoa Programming For Mac OS X (3rd Ed) and I'm near the end of chapter 9 (pg 148) where it is shown to make use of the changeKeyPath method. I'm in the habit of right clicking on method names and choosing Find selected text in API reference/in documenation. When I do this for changeKeyPath, nothing comes up on my machine? This is because changeKeyPath:ofObject:toValue is new method in the application. It is a little confusing. The implementation of the Cocoa method observeValueForKeyPath:ofObject:change:context registers the call to changeKeyPath:ofObject:toValue to be called later if an undo occurs. It is all a bit confusing since the book shows the implementation of the changeKeyPath:ofObject:toValue: before it shows how it will get called. Read about this in the Undo Architecture documentation. mkd ___ 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/russell_martin%40yahoo.com This email sent to russell_mar...@yahoo.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 arch...@mail-archive.com
Using UIImageView for animations
Hi! I'm taking a set of 10-20 jpegs that I'd like to animate. I started out just using a UIImageView using setAnimationImages: and everything worked fantastically in the simulator but testing it on my device basically makes it slow to the point where it is unresponsive. I've done some searching around and some people indicate that they are able to use CALayers to get this same effect but before going down that path I thought I would ask you folks. What is the best way of doing this? Alex ___ 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 arch...@mail-archive.com
Re: CALayer, CATextLayer, and inheritance . . .
I would definitely recommend using the factory methods. You have no idea of what is going on inside those methods, but you better believe you need it, whatever it is. Also, I've found that some of those methods don't even cal init, which I found out when my own iVars were not getting initialized when I overrode init. You can use the factory methods for your own subclass. We had that discussion here recently. Apparently, almost all of the factory methods use self in the class method when creating the object, so it will still work for your own subclass. On 1/10/09 9:08 PM, cocoa-dev-requ...@lists.apple.com cocoa-dev-requ...@lists.apple.com wrote: Ok, I think I'm hosed but I need one of you bright people to tell me just how bad it is. I'm working on a avionics simulation project that leverages Core Animation and layers in order to composite various elements of the display. These elements all have various behaviors and attributes based on the information they are meant to convey to the person reading them. For example, a compass displays directional information using values ranging from 0 to 359. I decided to abstract away the standard rotational transformation interface on a CALayer by creating a sub-class that knows about the compass interface. This subclass automatically converts degrees to radians, performs coordinate transformations in order to get rotation to happen in the proper direction, and sets up the associated animation, as well as handing delegate callbacks. At first it all seemed to work well, but when I created my first derived CATextLayer class, I began to have strange issues. I won't bore you with the details on that but here is the question: I'm allocating and initializing my sub-classed layers using the alloc and init methods: @interface CompassLayer : CALayer . . . @interface SpeedInfoLayer : CATextLayer . . . CompassLayer* c = [[CompassLayer alloc] init]; SpeedInfoLayer* si = [[SpeedInfoLayer alloc] init]; I know that the documentation states the CALayer entities are to be allocated with class methods: CALayer* l = [CALayer layer]; CATextLayer* tl = [CATextLayer layer]; Am I creating a problem by not allocating and initializing my layers using the class methods? ___ 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 arch...@mail-archive.com
Re: changeKeyPath method documentation
On Jan 10, 2009, at 10:06, Russell Martin wrote: So, are you saying that changeKeyPath isn't an override or a delegate method? If so, then why don't I have to put a stub in the .h file? I thought that unless I was implementing an override or delegate method that the stub in the .h was required. Is my thinking wrong on this? And, if so, when is the stub in the .h file required and not required? I think maybe you have two different things tangled up. 1. Your 'changeKeyPath' method isn't part of the Cocoa frameworks. That's why looking for it in the Cocoa documentation produces no results. It's something that Hillegass designed and wrote, so presumably its source code is given to you to use or copy. 2. Methods are just like everything else in C -- they must be *either* declared *or* defined before they can be referenced (or both). Declarations (what you're calling stubs) are typically placed in .h files, but not always. (Sometimes they're earlier in the .m file where they're used.) If your file compiles without errors, then if you right-click 'changeKeyPath' and choose Jump to Definition, you should get a popup menu with at least two entries. One will take you to the place where the method is declared (in some .h file, probably) and the other will take you to the place where the method is defined (in some .m file). If you're getting a compile error for 'changeKeyPath', then presumably you missed a step somewhere in Hillegass's instructions for setting up your project (e.g. you missed a #import at the top of the .m file). ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Sat, Jan 10, 2009 at 3:33 PM, Andy Lee ag...@mac.com wrote: On Saturday, January 10, 2009, at 12:39PM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: For what it's worth Anguish et al states (p99) that Apple reserves the right to change private instance variables that begin with an underscore and no prefix. On Saturday, January 10, 2009, at 02:40PM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: I agree that it is confusing, or meaningless, but I thought it might have contributed to the _ misconception. A Google for - anguish underscores and usage - will show the passage I referred to. It sounds like the risk is that Apple could rename one of their _ivars so the new name collides with one of your _ivars that previously was okay. You would quickly discover this the next time you compile, but I assume existing users of your app would find it suddenly crashes after their last OS update. Anguish et al. recommend mitigating this risk by using a unique prefix in addition to the underscore. Except that if Apple renames one of their ivars to match the name of one of your subclass's ivars nothing happens. You don't crash, you don't misbehave. Everything continues on like usual. Unlike methods, ivars are *not* looked up by name, but rather by offset. (This is no longer true if you're using KVC direct ivar access but, well, just another reason why you shouldn't do that.) Mike ___ 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 arch...@mail-archive.com
Re: CAD programming.
On 09 Jan 09, at 22:03, Brian Bruinewoud wrote: I'm an experienced C++ developer but a relative newbie to Objective- C and Cocoa and am learning my way. I'm porting a program to Mac OS X Cocoa and part of the requirements is a CAD-like functionality. A substantial part of the rest of the program is already written in Cocoa. I've browsed the example programs that come with XCode and it looks like AppKit/Sketch or Quartz/CarbonSketch are the best to base my implementation from, except that AppKit/Sketch is pure Cocoa and Quartz/CarbonSketch contains no Cocoa. Quartz/CarbonSketch is - as the name suggests - a Carbon application. Integrating it into an existing Cocoa application will be substantially more difficult than integrating the AppKit sketch example. :) I've heard that there are some 'gotchas' when it comes to using Quartz directly from Cocoa- is this true? What are they? I've used Quartz directly from Cocoa and didn't run into any particular difficulties in doing so. ___ 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 arch...@mail-archive.com
How to add a -(unsigned long long)unsignedLongLongValue method to NSString
Hello all,
I have a Cocoa app that performs some computations on
large integers (but still in the unsigned long long range), some
of which are entered by the user in a NSTextField.
The problem , of course, is that NSControl has no
-(unsigned long long)unsignedLongLongValue method, and
as specified in the documentation, if the user writes too many digits
the -(int)intValue method just returns UINT_MAX.
It seems logical to deal with this problem by calling the
-(NSString*)stringValue method of NSControl, and implementing
a -(unsigned long long)unsignedLongLongValue method for
NSString.
This is what I did in my project, using the code below. I can't
help feeling that this code is dirty because it relies on the character
for the j digit being indexed as unichar number j+48. Can anyone
tell me what would be the clean way to do this ?
TIA,
Ewan
//
/* contents of NSString_UnsignedLongLongValue.h */
extern int const GGCharacterIsNotADigit;
@interface NSString (UnsignedLongLongValue)
+(unsigned)digitValue: (unichar) c;
-(unsigned long long)unsignedLongLongValue;
@end
/* contents of NSString_UnsignedLongLongValue.m */
@implementation NSString (UnsignedLongLongValue)
int const GGCharacterIsNotADigit=10;
+(unsigned)digitValue: (unichar) c
{
if ((c47)(c58)) {
return (c-48);
}
return GGCharacterIsNotADigit;
+(unsigned long long)unsignedLongLongValue
{
unsigned n=[self length];
unsigned long long v,a;
unsigned small_a,j;
v=0;
for (j=0;jn;j++) {
unichar c=[self characterAtIndex:j];
small_a=[self digitValue:c];
if (small_a==GGCharacterIsNotADigit) continue;
a=(unsigned long long)small_a;
v=(10*v)+a;
}
return v;
}
@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 arch...@mail-archive.com
Re: CALayer, CATextLayer, and inheritance . . .
On 10-Jan-09, at 7:26 PM, Michael A. Crawford wrote: I know that the documentation states the CALayer entities are to be allocated with class methods: CALayer* l = [CALayer layer]; CATextLayer* tl = [CATextLayer layer]; Am I creating a problem by not allocating and initializing my layers using the class methods? No. it is perfectly valid to do that. init is the designated initializer for CALayer. +layer is simply a convenience. The header shows this, although the doc didn't (until just now -- so next push it will show the below) what you are not supposed to do is use initWithLayer:, that's a special method only used when you create custom presentation layers for a model layer (i.e. very, very rarely) (see the doc for more information). init Returns an initialized CALayer object. - (id)init Return Value An initialized CALayer object. Discussion This is the designated initializer for CALayer. See Also • + layer Declared InCALayer.h___ 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 arch...@mail-archive.com
Re: How to add a -(unsigned long long)unsignedLongLongValue method to NSString
On Sun, Jan 11, 2009 at 12:24 AM, ewan.dela...@math.unicaen.fr wrote: I have a Cocoa app that performs some computations on large integers (but still in the unsigned long long range), some of which are entered by the user in a NSTextField. The problem , of course, is that NSControl has no -(unsigned long long)unsignedLongLongValue method, and as specified in the documentation, if the user writes too many digits the -(int)intValue method just returns UINT_MAX. It seems logical to deal with this problem by calling the -(NSString*)stringValue method of NSControl, and implementing a -(unsigned long long)unsignedLongLongValue method for NSString. This is what I did in my project, using the code below. I can't help feeling that this code is dirty because it relies on the character for the j digit being indexed as unichar number j+48. Can anyone tell me what would be the clean way to do this ? Take a look at +[NSDecimalNumber decimalNumberWithString:] http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSDecimalNumber_Class/Reference/Reference.html#//apple_ref/doc/uid/2179-decimalNumberWithString_ Since it is a subclass of NSNumber, it implements unsignedLongLongValue. ___ 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 arch...@mail-archive.com
Re: How to add a -(unsigned long long)unsignedLongLongValue method to NSString
On Jan 11, 2009, at 12:24 AM, ewan.dela...@math.unicaen.fr wrote: I have a Cocoa app that performs some computations on large integers (but still in the unsigned long long range), some of which are entered by the user in a NSTextField. Do you really need to exceed the long long range? NSString does support -longLongValue. It seems logical to deal with this problem by calling the -(NSString*)stringValue method of NSControl, and implementing a -(unsigned long long)unsignedLongLongValue method for NSString. This is what I did in my project, using the code below. I can't help feeling that this code is dirty because it relies on the character for the j digit being indexed as unichar number j+48. Can anyone tell me what would be the clean way to do this ? Definitely don't write your own parser that way. If you can, use NSScanner or sscanf. If you must work character-by-character, use character constants (e.g. '0' or '9') rather than the specific numeric Unicode code point values. However, in this case you avoid even that. You can use something like: [[NSDecimalNumber decimalNumberWithString:aString] unsignedLongLongValue] You could also use a NSNumberFormatter. Associate it with your NSTextField. Then, you can retrieve an NSNumber using the - objectValue method of the control, and ask it for its - unsignedLongLongValue. 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 arch...@mail-archive.com
Re: How to add a -(unsigned long long)unsignedLongLongValue method to NSString
Thanks Ken and Steve, for the variety of clean solutions you offered. Just out of curiosity, I should like to return to a point mentioned by Ken : If you must work character-by-character, use character constants (e.g. '0' or '9') In that (unlikely) situation, how would I test, say, equality of characters ? For example, if I needed to know whether character number j in aString is '7', writing ([aString characterAtIndex:j]=='7') wouldn't work, would it ? Ewan ___ 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 arch...@mail-archive.com
Re: How to add a -(unsigned long long)unsignedLongLongValue method to NSString
On Jan 11, 2009, at 1:28 AM, ewan.dela...@math.unicaen.fr wrote: If you must work character-by-character, use character constants (e.g. '0' or '9') In that (unlikely) situation, how would I test, say, equality of characters ? For example, if I needed to know whether character number j in aString is '7', writing ([aString characterAtIndex:j]=='7') wouldn't work, would it ? Sure it would. Both unichar (as typedef'd) and char are integer types in C. '7' is another way of writing a number, although not the number 7. Which number depends on the encoding of your source file, but in most modern systems it would be ASCII or UTF-8. (I don't know if, for example, EBCDIC is still used on any modern systems.) In either of those, '7' is the same as 0x37 or 55. 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 arch...@mail-archive.com
