Strange property/synthesized accessor behaviour

[Philipp Leusmann]

Today I wanted to override the - (void) isEqual:(id) method of a 
custom, but very simple subclass of NSObject:


@interface Resolution : NSObject {
NSUInteger mWidth;
NSUInteger mHeight;
}
-(id) initWithWidth:(NSUInteger) width andHeight:(NSUInteger) height;
-(BOOL) isValidResolution;

@property NSUInteger width;
@property NSUInteger height;
@end


All the custom implementation of - (void) isEqual:(id) performs, 
is to compare width and height.

This simple comparison failed. To find out, where I expanded it to 

 
- (BOOL)isEqual:(id)object {
if ([object isKindOfClass:[Resolution class]]){
NSUInteger oWidth = [object width];
NSUInteger oHeight = [object height];
NSUInteger sWidth = [self width];
NSUInteger sHeight = [self height];
BOOL isSameWidth = oWidth == sWidth;
BOOL isSameHeight = oHeight == sHeight;
return isSameWidth && isSameHeight;
}
return NO;
}


Surprisingly, oWidth was 0 instead of the expected value of 300. BUT, according 
to gdb, object.mWidth was 300.

See a screenshot in this blog post: http://freies-blasen.de/?p=39 

Finally, the method succeeded, when it was changed to 


- (BOOL)isEqual:(id)object {
if ([object isKindOfClass:[Resolution class]]){
Resolution *cmpRes = (Resolution*) object;
NSUInteger oWidth = cmpRes.width;
NSUInteger oHeight = cmpRes.height;
NSUInteger sWidth = self.width;
NSUInteger sHeight = self.height;
BOOL isSameWidth = oWidth == sWidth;
BOOL isSameHeight = oHeight == sHeight;
return isSameWidth && isSameHeight;
}
return NO;
}


Who can explain this behavior to me? Why is oWidth != object.mWidth ? How can 
that happen?

Thanks,
 Philipp
___

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 Increment CALayer Retain Count?

[Lee Ann Rucker]

What does your @property line look like for your variables? If it's retain, 
then "(x) = nil;" in your macro is releasing it again. That's the magic of dot 
operator assign in ObjC.

I imagine those macros exist because using "self.foo = nil" in dealloc can have 
unwanted side effects, so they're a convenient shortcut for not having to write 
the same two lines over and over.


From: cocoa-dev-bounces+lrucker=vmware@lists.apple.com 
[cocoa-dev-bounces+lrucker=vmware@lists.apple.com] On Behalf Of Jeffrey 
Walton [noloa...@gmail.com]
Sent: Saturday, April 09, 2011 11:17 PM
Cc: cocoa-dev@lists.apple.com
Subject: Re: How To Increment CALayer Retain Count?

On Fri, Apr 8, 2011 at 8:27 AM, Matt Neuburg  wrote:
> On Thu, 07 Apr 2011 07:15:20 -0400, Jeffrey Walton  said:
>>Hi All,
>>
>>I have a UIViewController as follows. Its just an "About Box", with a
>>navigation bar and button (to cancel) and two labels.
>>
>>The controller was built with Interface Builder. The Navigation Bar
>>and two labels are IBOutlets. According to IB, they are properly
>>connected. I did not know what to connect the Navigation Items outlet
>>to, so they are currently unconnected (formerly, they were connected
>>to File's Owner which did not help).
>>
>>+ File's Owner
>>+ First Responder
>>+ View
>>  + Navigation Bar
>>+ Navigation Item (Title)
>>  + Bar Button
>>  + Label 1
>>  + Label 2
>>
>>When the app starts, I tap a button and bring up the About box. Then I
>>dismiss it. That is it.
>>
>>When the view is dismissed by tapping Cancel, NSZombie reports:
>>-[UINavigationBar willMoveToSuperview:]: message sent to
>>deallocated instance
>
> You're posing your question very oddly, since you say "I have a 
> UIViewController" but then you never show anything about any view controller. 
> Thus it is impossible to say what you actually have. How does this view 
> controller get instantiated? Who is retaining it? (If no one, then it and the 
> whole kit and caboodle it loads from the nib could just vanish in a puff of 
> smoke.) It has to be someone's job to retain the view controller, and it is 
> the view controller's job to retain its view (which it will do if you are 
> loading the nib correctly, but you don't show that, so who's to say?). Since 
> everything else is inside the view, it is retained automatically.
>
> It sounds a little like you're confused between outlets and memory 
> management. They really don't have much to do with each other. Outlets are 
> ways of getting references and setting instance variables as a nib loads. 
> Memory management is, uh, memory management. I mean, sure, you might need an 
> outlet to something in order to be able to refer to it in order to manage its 
> memory, but they are still different worlds of thought. The only item in the 
> nib that you should be managing the memory of is the View, because it's a 
> top-level object - and the view controller should be doing that, assuming 
> that the First Responder is of the view controller's class and assuming that 
> the view controller's view outlet is connected to the View and assuming that 
> you're loading the nib correctly...
>
> Anyway, the CALayer is surely a total red herring.
>
> m.
>
Thanks to all who responded. I tried to build a minimal test case
which reproduced the problem - no joy (the test code worked fine).

The problem was prefixing the various IBOutlets with "self.". To add
insult to injury, I added "self." to nearly all interface variables to
ensure disambiguation when I first encountered EXC_BAD_ACCESS.

According to Hillegass, "self" is equivalent to "this". So I'm not
sure what is going on with the dot operator (or I don't have the
correct understanding in Obj C).

Jeff

The difference between the test case and the real code was:

*** Test code ***

- (void) dealloc
{
// OK???
[navigationBar release];
navigationBar = nil;

[dismissButton release];
dismissButton = nil;

[super dealloc];
}

*** Real code ***

#define SAFE_RELEASE(x) { ASSERT(x); if((x) != nil) { [(x) release],
(x) = nil; } }
#define QUIET_RELEASE(x) { if((x) != nil) { [(x) release], (x) = nil; } }

- (void) dealloc
{
// Crash
QUIET_RELEASE(self.navigationBar);
QUIET_RELEASE(self.dismissButton);
...

[super dealloc];
}
___

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/lrucker%40vmware.com

This email sent to lruc...@vmware.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.

RE: Strange property/synthesized accessor behaviour

[Lee Ann Rucker]

Unless you've got

@synthesize width = mWidth;

ObjC has created a second set of variables for you named width and height with 
no connection to mWidth and mHeight.

From: cocoa-dev-bounces+lrucker=vmware@lists.apple.com 
[cocoa-dev-bounces+lrucker=vmware@lists.apple.com] On Behalf Of Philipp 
Leusmann [m...@byteshift.eu]
Sent: Saturday, April 09, 2011 7:52 AM
To: cocoa-dev@lists.apple.com
Subject: Strange property/synthesized accessor behaviour

Today I wanted to override the - (void) isEqual:(id) method of a 
custom, but very simple subclass of NSObject:


@interface Resolution : NSObject {
NSUInteger mWidth;
NSUInteger mHeight;
}
-(id) initWithWidth:(NSUInteger) width andHeight:(NSUInteger) height;
-(BOOL) isValidResolution;

@property NSUInteger width;
@property NSUInteger height;
@end


All the custom implementation of - (void) isEqual:(id) performs, 
is to compare width and height.

This simple comparison failed. To find out, where I expanded it to


- (BOOL)isEqual:(id)object {
if ([object isKindOfClass:[Resolution class]]){
NSUInteger oWidth = [object width];
NSUInteger oHeight = [object height];
NSUInteger sWidth = [self width];
NSUInteger sHeight = [self height];
BOOL isSameWidth = oWidth == sWidth;
BOOL isSameHeight = oHeight == sHeight;
return isSameWidth && isSameHeight;
}
return NO;
}


Surprisingly, oWidth was 0 instead of the expected value of 300. BUT, according 
to gdb, object.mWidth was 300.

See a screenshot in this blog post: http://freies-blasen.de/?p=39

Finally, the method succeeded, when it was changed to


- (BOOL)isEqual:(id)object {
if ([object isKindOfClass:[Resolution class]]){
Resolution *cmpRes = (Resolution*) object;
NSUInteger oWidth = cmpRes.width;
NSUInteger oHeight = cmpRes.height;
NSUInteger sWidth = self.width;
NSUInteger sHeight = self.height;
BOOL isSameWidth = oWidth == sWidth;
BOOL isSameHeight = oHeight == sHeight;
return isSameWidth && isSameHeight;
}
return NO;
}


Who can explain this behavior to me? Why is oWidth != object.mWidth ? How can 
that happen?

Thanks,
 Philipp
___

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/lrucker%40vmware.com

This email sent to lruc...@vmware.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: Strange property/synthesized accessor behaviour

[Stephen J. Butler]

On Sat, Apr 9, 2011 at 9:52 AM, Philipp Leusmann  wrote:
> Who can explain this behavior to me? Why is oWidth != object.mWidth ? How can 
> that happen?

It's an artifact of how Objective-C searches for selector
implementations. You're calling @selector(width) on an "id", and of
course "id" doesn't implement @selector(width).

So what Objective-C does is search for the first implementation of
@selector(width) that it finds. My guess is it finds the one in AppKit
first (greping the frameworks):

NSTableColumn.h:- (CGFloat)width;

Then when the compiler sets up the call site it does it expecting a
CGFloat return and that is handled differently than an integer. So the
call site and the implementation of how your width is done disagree
and you get some strange heisenvalue back.

When you cast the variable to "Result*", Objective-C now knows to use
YOUR implementation of @selector(width) and it sets up the call site
properly.
___

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 Increment CALayer Retain Count?

[Jeffrey Walton]

On Sun, Apr 10, 2011 at 3:54 AM, Lee Ann Rucker  wrote:
> What does your @property line look like for your variables? If it's retain, 
> then "(x) = nil;" in your macro is releasing it again. That's the magic of 
> dot operator assign in ObjC.
@property (retain, nonatomic) IBOutlet UINavigationBar* navigationBar;

That probably explains it. I imagine I read it in one of my books, but
did not appreciate what was being said at the time.

> I imagine those macros exist because using "self.foo = nil" in dealloc can 
> have unwanted side effects, so they're a convenient shortcut for not having 
> to write the same two lines over and over.

I know its not very popular, but I've disciplined myself to set all
variables (including stack) to their low or unused state when finished
with them. It helps locate reuse problems in Debug builds (and I
really don't care a bit about the 3 cycles). The optimizer can remove
it later if it desires.

Jeff

> 
> From: cocoa-dev-bounces+lrucker=vmware@lists.apple.com 
> [cocoa-dev-bounces+lrucker=vmware@lists.apple.com] On Behalf Of Jeffrey 
> Walton [noloa...@gmail.com]
> Sent: Saturday, April 09, 2011 11:17 PM
> Cc: cocoa-dev@lists.apple.com
> Subject: Re: How To Increment CALayer Retain Count?
>
> On Fri, Apr 8, 2011 at 8:27 AM, Matt Neuburg  wrote:
>> On Thu, 07 Apr 2011 07:15:20 -0400, Jeffrey Walton  said:
>>>Hi All,
>>>
>>>I have a UIViewController as follows. Its just an "About Box", with a
>>>navigation bar and button (to cancel) and two labels.
>>>
>>>The controller was built with Interface Builder. The Navigation Bar
>>>and two labels are IBOutlets. According to IB, they are properly
>>>connected. I did not know what to connect the Navigation Items outlet
>>>to, so they are currently unconnected (formerly, they were connected
>>>to File's Owner which did not help).
>>>
>>>+ File's Owner
>>>+ First Responder
>>>+ View
>>>  + Navigation Bar
>>>    + Navigation Item (Title)
>>>      + Bar Button
>>>  + Label 1
>>>  + Label 2
>>>
>>>When the app starts, I tap a button and bring up the About box. Then I
>>>dismiss it. That is it.
>>>
>>>When the view is dismissed by tapping Cancel, NSZombie reports:
>>>    -[UINavigationBar willMoveToSuperview:]: message sent to
>>>deallocated instance
>>
>> You're posing your question very oddly, since you say "I have a 
>> UIViewController" but then you never show anything about any view 
>> controller. Thus it is impossible to say what you actually have. How does 
>> this view controller get instantiated? Who is retaining it? (If no one, then 
>> it and the whole kit and caboodle it loads from the nib could just vanish in 
>> a puff of smoke.) It has to be someone's job to retain the view controller, 
>> and it is the view controller's job to retain its view (which it will do if 
>> you are loading the nib correctly, but you don't show that, so who's to 
>> say?). Since everything else is inside the view, it is retained 
>> automatically.
>>
>> It sounds a little like you're confused between outlets and memory 
>> management. They really don't have much to do with each other. Outlets are 
>> ways of getting references and setting instance variables as a nib loads. 
>> Memory management is, uh, memory management. I mean, sure, you might need an 
>> outlet to something in order to be able to refer to it in order to manage 
>> its memory, but they are still different worlds of thought. The only item in 
>> the nib that you should be managing the memory of is the View, because it's 
>> a top-level object - and the view controller should be doing that, assuming 
>> that the First Responder is of the view controller's class and assuming that 
>> the view controller's view outlet is connected to the View and assuming that 
>> you're loading the nib correctly...
>>
>> Anyway, the CALayer is surely a total red herring.
>>
>> m.
>>
> Thanks to all who responded. I tried to build a minimal test case
> which reproduced the problem - no joy (the test code worked fine).
>
> The problem was prefixing the various IBOutlets with "self.". To add
> insult to injury, I added "self." to nearly all interface variables to
> ensure disambiguation when I first encountered EXC_BAD_ACCESS.
>
> According to Hillegass, "self" is equivalent to "this". So I'm not
> sure what is going on with the dot operator (or I don't have the
> correct understanding in Obj C).
>
> Jeff
>
> The difference between the test case and the real code was:
>
> *** Test code ***
>
> - (void) dealloc
> {
>        // OK???
>        [navigationBar release];
>        navigationBar = nil;
>
>        [dismissButton release];
>        dismissButton = nil;
>
>        [super dealloc];
> }
>
> *** Real code ***
>
> #define SAFE_RELEASE(x) { ASSERT(x); if((x) != nil) { [(x) release],
> (x) = nil; } }
> #define QUIET_RELEASE(x) { if((x) != nil) { [(x) release], (x) = nil; } }
>
> - (void) dealloc
> {
>        // Crash
>        QUIET_RELEASE(self.navigation

RE: How To Increment CALayer Retain Count?

[Lee Ann Rucker]

From: Jeffrey Walton [noloa...@gmail.com]
Sent: Sunday, April 10, 2011 1:03 AM
To: Lee Ann Rucker
Cc: cocoa-dev@lists.apple.com
Subject: Re: How To Increment CALayer Retain Count?

On Sun, Apr 10, 2011 at 3:54 AM, Lee Ann Rucker  wrote:
> What does your @property line look like for your variables? If it's retain, 
> then "(x) = nil;" in your macro is releasing it again. That's the magic of 
> dot operator assign in ObjC.
@property (retain, nonatomic) IBOutlet UINavigationBar* navigationBar;

That probably explains it. I imagine I read it in one of my books, but
did not appreciate what was being said at the time.

> I imagine those macros exist because using "self.foo = nil" in dealloc can 
> have unwanted side effects, so they're a convenient shortcut for not having 
> to write the same two lines over and over.

I know its not very popular, but I've disciplined myself to set all
variables (including stack) to their low or unused state when finished
with them. It helps locate reuse problems in Debug builds (and I
really don't care a bit about the 3 cycles). The optimizer can remove
it later if it desires.

---

Sure, setting the variable to nil in dealloc is good practice, just either do 
it with
[foo release];
foo = nil;

or 
self.foo = nil;
if you're sure there's no side effects. But not both 
:)___

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 Increment CALayer Retain Count?

[Quincey Morris]

On Apr 9, 2011, at 23:17, Jeffrey Walton wrote:

> The problem was prefixing the various IBOutlets with "self.". To add
> insult to injury, I added "self." to nearly all interface variables to
> ensure disambiguation when I first encountered EXC_BAD_ACCESS.
> 
> According to Hillegass, "self" is equivalent to "this". So I'm not
> sure what is going on with the dot operator (or I don't have the
> correct understanding in Obj C).

I'm not sure if you got your full answer yet, so I'm going to try to lay this 
out in some detail:

-- Your problem was that you used those release macros incorrectly. They were 
solely for instance variables, and were simply wrong if you specified property 
references.

-- It's not entirely your fault -- IMO those are terrible, terrible macros, 
because they're terribly, terribly dangerous. If you know how to use them 
safely, you don't need them at all. If you don't know how to use them safely, 
you shouldn't use them at all. :)

-- Your conceptual confusion is common amongst developers new to Objective-C 
(and TBH quite a lot of long-time ones, too), but it's vital that it's cleared 
up if you're going to continue writing Objective-C code without tearing your 
hair out.

Properties are *behavior* of a class, not *things*. They *have* values, and 
"get" and "set" values, whatever that means in the property's API, but don't 
reveal to the outside world anything about how (or if) those values are stored 
by the class's implementation.

Instance variables are things, not behavior. They are, potentially, *backing 
storage* for properties. As such, they're an implementation detail. A property 
may, as implementation detail, use a same-named instance variable, or a 
different-named instance variable, or multiple instances variables, or no 
instance variables, as its backing storage. Clients of the class don't care. 
Only the implementor of the class should care.

As class implementor, it's best to think of the ivar name as something 
completely different from the property name. If you had, you'd never have been 
tempted to 'add "self." to nearly all interface variables'.

Once you get this distinction clear, things should fall into place.

Being uncertain about this isn't entirely your fault either***. @synthesize's 
default behavior (assuming or creating a same-named instance variable) is an 
inducement to confuse properties with ivars.

Also, though this may not have been in play in this case, there's a really 
confusing shortcut in KVC property access that conflates properties with ivars, 
as a "help" to the developer. You should routinely disable it by adding + 
(BOOL) accessInstanceVariablesDirectly {return NO;} to all your classes.

Finally, the general practice is now to avoid using property getters and 
setters in 'init' and 'dealloc' methods. There has historically been some 
controversy over this question, but under normal circumstances it's the 
instance variables you want to manage in those methods, not the property values.

HTH



*** You aren't alone. For a while, the gcc 4.2 compiler itself had a bug where 
it confused ivars and properties of the same 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 arch...@mail-archive.com

Re: Strange property/synthesized accessor behaviour

[Philipp Leusmann]

Stephen,

thanks to your detailed answer. This absolutely explains the observed behavior, 
but still leaves me wondering about the feature of sending messages to id. 
While I am still new to programming in objective-c and only having read the 
basic language documentation, I remember this feature to be pointed out as a 
helpful tool. But after this discovery, I can only mark it as a "don't use" 
language feature.

Regards,
 Philipp
  
Am 10.04.2011 um 10:00 schrieb Stephen J. Butler:

> On Sat, Apr 9, 2011 at 9:52 AM, Philipp Leusmann  wrote:
>> Who can explain this behavior to me? Why is oWidth != object.mWidth ? How 
>> can that happen?
> 
> It's an artifact of how Objective-C searches for selector
> implementations. You're calling @selector(width) on an "id", and of
> course "id" doesn't implement @selector(width).
> 
> So what Objective-C does is search for the first implementation of
> @selector(width) that it finds. My guess is it finds the one in AppKit
> first (greping the frameworks):
> 
> NSTableColumn.h:- (CGFloat)width;
> 
> Then when the compiler sets up the call site it does it expecting a
> CGFloat return and that is handled differently than an integer. So the
> call site and the implementation of how your width is done disagree
> and you get some strange heisenvalue back.
> 
> When you cast the variable to "Result*", Objective-C now knows to use
> YOUR implementation of @selector(width) and it sets up the call site
> properly.

___

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: Strange property/synthesized accessor behaviour

[Anders Norlander]

You should get a warning about ambiguous messages, and it also tells you which 
selector is actually used:
Multiple methods named 'width' found
Using '-(CGFloat)width'

Then use static typing to resolve the ambiguity (i.e [(Resolution*)object 
width])
'treat warnings as errors' is a big help in avoiding issues like this.

-Anders

On 2011-04-10, at 12:25 , Philipp Leusmann wrote:

> Stephen,
> 
> thanks to your detailed answer. This absolutely explains the observed 
> behavior, but still leaves me wondering about the feature of sending messages 
> to id. 
> While I am still new to programming in objective-c and only having read the 
> basic language documentation, I remember this feature to be pointed out as a 
> helpful tool. But after this discovery, I can only mark it as a "don't use" 
> language feature.
> 
> Regards,
> Philipp
> 
> Am 10.04.2011 um 10:00 schrieb Stephen J. Butler:
> 
>> On Sat, Apr 9, 2011 at 9:52 AM, Philipp Leusmann  wrote:
>>> Who can explain this behavior to me? Why is oWidth != object.mWidth ? How 
>>> can that happen?
>> 
>> It's an artifact of how Objective-C searches for selector
>> implementations. You're calling @selector(width) on an "id", and of
>> course "id" doesn't implement @selector(width).
>> 
>> So what Objective-C does is search for the first implementation of
>> @selector(width) that it finds. My guess is it finds the one in AppKit
>> first (greping the frameworks):
>> 
>> NSTableColumn.h:- (CGFloat)width;
>> 
>> Then when the compiler sets up the call site it does it expecting a
>> CGFloat return and that is handled differently than an integer. So the
>> call site and the implementation of how your width is done disagree
>> and you get some strange heisenvalue back.
>> 
>> When you cast the variable to "Result*", Objective-C now knows to use
>> YOUR implementation of @selector(width) and it sets up the call site
>> properly.
> 
> ___
> 
> 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/ano%40bahnhof.se
> 
> This email sent to a...@bahnhof.se

___

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

Remove KVO for MKAnnotationViews

[Philip Vallone]

Hi,

I am in need of some help. I have a MKMapView object, which allows the user to 
add, move and delete MKAnnotationViews. When an Annotation is added to the map, 
I use KVO to track if the Annotation was moved or selected:


for (MKAnnotationView *anAnnotationView in views) {

[anAnnotationView addObserver:self forKeyPath:@"selected" 
options:NSKeyValueObservingOptionNew context:@"MapAnnontationSelected"];

}

Here is how I add the annotation:

- (MKAnnotationView *) mapView:(MKMapView *)mapView viewForAnnotation:(id ) 
annotation{

MKPinAnnotationView *annView=[[MKPinAnnotationView alloc] 
initWithAnnotation:annotation reuseIdentifier:@"currentloc"];
annView.animatesDrop= YES;
annView.canShowCallout = YES;
annView.draggable = YES;
UIImage *image = [UIImage imageNamed:@"gps_add.png"];   
UIImageView *imgView = [[[UIImageView alloc] initWithImage:image] 
autorelease];
annView.leftCalloutAccessoryView = imgView; 
annView.rightCalloutAccessoryView = [UIButton 
buttonWithType:UIButtonTypeDetailDisclosure];
annView.pinColor = MKPinAnnotationColorGreen;
return [annView autorelease];

}

The problem occurs when I delete the Annotation. Since the MKPinAnnotationView 
is set to auto release, the object is deallocated with the observer still 
attached. 

"An instance 0xb323890 of class MKPinAnnotationView was deallocated while key 
value observers were still registered with it. Observation info was leaked, and 
may even become mistakenly attached to some other object. Set a breakpoint on 
NSKVODeallocateBreak to stop here in the debugger. Here's the current 
observation info:"


I tried to remove the observer when the pin gets deleted, but that still gives 
the error:

for (id  annotation in mapView.annotations) { 
[[mapView viewForAnnotation:annotation] removeObserver:self 
forKeyPath:@"selected"];
}


Any help would be greatly appreciated. 

Thx.

Phil



___

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: Strange property/synthesized accessor behaviour

[Philipp Leusmann]

In this situation XCode4 did not show a warning. 

Philipp


Am 10.04.2011 um 13:44 schrieb Anders Norlander:

> You should get a warning about ambiguous messages, and it also tells you 
> which selector is actually used:
> Multiple methods named 'width' found
> Using '-(CGFloat)width'
> 
> Then use static typing to resolve the ambiguity (i.e [(Resolution*)object 
> width])
> 'treat warnings as errors' is a big help in avoiding issues like this.
> 
> -Anders
> 
> On 2011-04-10, at 12:25 , Philipp Leusmann wrote:
> 
>> Stephen,
>> 
>> thanks to your detailed answer. This absolutely explains the observed 
>> behavior, but still leaves me wondering about the feature of sending 
>> messages to id. 
>> While I am still new to programming in objective-c and only having read the 
>> basic language documentation, I remember this feature to be pointed out as a 
>> helpful tool. But after this discovery, I can only mark it as a "don't use" 
>> language feature.
>> 
>> Regards,
>> Philipp
>> 
>> Am 10.04.2011 um 10:00 schrieb Stephen J. Butler:
>> 
>>> On Sat, Apr 9, 2011 at 9:52 AM, Philipp Leusmann  wrote:
 Who can explain this behavior to me? Why is oWidth != object.mWidth ? How 
 can that happen?
>>> 
>>> It's an artifact of how Objective-C searches for selector
>>> implementations. You're calling @selector(width) on an "id", and of
>>> course "id" doesn't implement @selector(width).
>>> 
>>> So what Objective-C does is search for the first implementation of
>>> @selector(width) that it finds. My guess is it finds the one in AppKit
>>> first (greping the frameworks):
>>> 
>>> NSTableColumn.h:- (CGFloat)width;
>>> 
>>> Then when the compiler sets up the call site it does it expecting a
>>> CGFloat return and that is handled differently than an integer. So the
>>> call site and the implementation of how your width is done disagree
>>> and you get some strange heisenvalue back.
>>> 
>>> When you cast the variable to "Result*", Objective-C now knows to use
>>> YOUR implementation of @selector(width) and it sets up the call site
>>> properly.
>> 
>> ___
>> 
>> 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/ano%40bahnhof.se
>> 
>> This email sent to a...@bahnhof.se

___

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

NSManagedObjected isInserted

[Carter R. Harrison]

Can anybody ever think of a scenario where [NSManagedObject isInserted] equals 
NO for an object that is initially fetched from the context?  And no the object 
has not been deleted from the context prior to calling isInserted.
___

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: Storing a block in a CF/NSMutableDictionary?

[Fritz Anderson]

On 8 Apr 2011, at 7:51 PM, Kyle Sluder wrote:

> As explained in the Blocks Programming Guide, you should not allow
> blocks that reference stack storage to escape that scope. See
> "Patterns to Avoid":
> http://developer.apple.com/library/ios/#documentation/cocoa/Conceptual/Blocks/Articles/bxUsing.html

I am grateful you called this to my attention, as I had been thinking that 
blocks were closures, in which referencing (but not, usefully, changing) 
stack-local variables would work. I'd been thrown by the existence of the 
__block attribute, which permits referencing a stack-local variable as an 
lvalue. I had reasoned that if a __block variable _is_ obviously a reference to 
that memory, a non-__block variable (whose value does _not_ propagate to the 
stack variable when a block changes it) obviously _couldn't_ be a reference.

One of the examples is:

void dontDoThis() {
void (^blockArray[3])(void);  // an array of 3 block references
 
for (int i = 0; i < 3; ++i) {
blockArray[i] = ^{ printf("hello, %d\n", i); };
// WRONG: The block literal scope is the "for" loop
}
}

... which would be useful, and a perfectly sensible thing to want to do. I'd 
hope the block literal would copy the stack context to the block structure, 
cutting the block free of its initialization context. As in fact it does for 
NSObjects.

So my question is: Can a block be made to do that useful and perfectly sensible 
thing I'd thought it did? Is the only solution wrapping the value in an NSValue?

— F

___

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: Controller Selection Synchronization

[Richard Somers]

On Apr 9, 2011, at 18:00, Richard Somers wrote:

> I have a primary view which displays all objects using a primary controller. 
> Both 'A' and 'B' objects are included in the controller content. This is 
> accomplished by using an abstract class in the managed object model that is a 
> parent of both 'A' and 'B' objects. The primary array controller content is 
> the abstract class, so we get all objects.


On Apr 9, 2011, at 10:12 PM, Quincey Morris wrote:

> Are you talking about selecting rows in a table view or an outline view, or 
> selecting objects in a custom view?

The primary view is a custom view that displays objects spatially according to 
their position in x, y, z coordinate space. The secondary views are table type 
views.

> If you're talking about a table/outline view, I'd just use the "selection did 
> change" delegate methods to propagate selections from one list to another.
> 
> If not, but the selection is part of the state of a window controller, I'd 
> make a window controller property for each list, and observe those 
> properties, either in the window controller or the individual views.
> 
> Or, if the selection is to be saved with the data model, I'd put a (probably 
> just one) selection set property in the data model, and use the window 
> controller (for example) as a mediating controller to propagate derived 
> properties to the views.

I currently have a transient selection property for each object in the data 
model which helps in restoring the selection when undoing an object delete. The 
primary controller (for the custom primary view) is a custom programatic 
subclass of NSArrayController that synchronizes the primary controller 
selection with the transient selection property.

The secondary controllers (NSArrayController and NSObjectController) and 
secondary views (table views) are all standard Interface Builder objects.

The problem is how to synchronizing the selection among all the various 
controllers.

--Richard Somers

___

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: Storing a block in a CF/NSMutableDictionary?

[Ken Thomases]

On Apr 10, 2011, at 9:49 AM, Fritz Anderson wrote:

> On 8 Apr 2011, at 7:51 PM, Kyle Sluder wrote:
> 
>> As explained in the Blocks Programming Guide, you should not allow
>> blocks that reference stack storage to escape that scope. See
>> "Patterns to Avoid":
>> http://developer.apple.com/library/ios/#documentation/cocoa/Conceptual/Blocks/Articles/bxUsing.html

The above link does not say "you should not allow blocks that reference stack 
storage to escape that scope" or anything like that.  It explains that a block 
literal expression -- the block itself, not anything it references -- is only 
valid within its scope, unless copied.  The problem in those examples is that 
references to blocks survive beyond the lifetime of the blocks themselves.


> I am grateful you called this to my attention, as I had been thinking that 
> blocks were closures, in which referencing (but not, usefully, changing) 
> stack-local variables would work.

Blocks are closures and referencing stack-local variables does work.  For 
non-__block variables, the block has a const copy of the value, just as though 
it were passed by value into a function.

> I'd been thrown by the existence of the __block attribute, which permits 
> referencing a stack-local variable as an lvalue. I had reasoned that if a 
> __block variable _is_ obviously a reference to that memory, a non-__block 
> variable (whose value does _not_ propagate to the stack variable when a block 
> changes it) obviously _couldn't_ be a reference.

You had been correct.  Kyle just confused you.


> One of the examples is:
> 
> void dontDoThis() {
>void (^blockArray[3])(void);  // an array of 3 block references
> 
>for (int i = 0; i < 3; ++i) {
>blockArray[i] = ^{ printf("hello, %d\n", i); };
>// WRONG: The block literal scope is the "for" loop
>}
> }
> 
> ... which would be useful, and a perfectly sensible thing to want to do. I'd 
> hope the block literal would copy the stack context to the block structure, 
> cutting the block free of its initialization context.

It does.  The problem in this example is simply that the block itself does not 
survive the specific pass through the "for" loop.  If the code above had copied 
the block (with a corresponding release, later), all would be fine.


I should say that there is a sense in which "you should not allow blocks that 
reference stack storage to escape that scope": if a block ends up holding a 
_pointer_ to a stack-local variable.  Then, of course, the block has a copy of 
the pointer, but not the pointed-to storage, so the pointer is a dangling 
pointer once control leaves the local scope.

Regards,
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: Remove Duplicates in a NSArray

[Christopher Nagel]

Could you just add each dictionary to a single dict and then have a  
globally unique set of keys?  This would presuppose you know which  
value of testKey is the one you wan to retain, and you'd add that one  
last.


Chris

On Oct 1, 2008, at 7:29 AM, Rashmi Vyshnavi wrote:


Hi All,

Is there a way to remove dictionary item containing same values for  
a key

from a array of dictionaries?

E.g.
   NSDictionary *dict1 = [NSDictionary dictionaryWithObjectsAndKeys:@
"testVal",@"testKey",,nil];
   NSDictionary *dict2 = [NSDictionary dictionaryWithObjectsAndKeys:@
"testVal1",@"testKey",,nil];
   NSDictionary *dict3 = [NSDictionary dictionaryWithObjectsAndKeys:@
"testVal3",@"testKey",,nil];
   NSDictionary *dict4 = [NSDictionary dictionaryWithObjectsAndKeys:@
"testVal",@"testKey",,nil];

   NSArray *arrDicts = [NSArray
arrayWithObjects:dict1,dict2,dict3,dict4,nil];

In the above code I want to remove the multiple dictionaries  
containing
"testVal" and maintain only one dictionary containing "testVal" in  
the array

"arrDict".

--
Rashmi
___

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/chris%40cnagel.com

This email sent to ch...@cnagel.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: Strange property/synthesized accessor behaviour

[Quincey Morris]

On Apr 10, 2011, at 03:25, Philipp Leusmann wrote:

> This absolutely explains the observed behavior, but still leaves me wondering 
> about the feature of sending messages to id. 
> While I am still new to programming in objective-c and only having read the 
> basic language documentation, I remember this feature to be pointed out as a 
> helpful tool. But after this discovery, I can only mark it as a "don't use" 
> language feature.

The general rule is to avoid defining any method whose selector is the same as 
another method with the same selector but incompatible parameter/return types. 
That's not unexpected in a C-based language, because polymorphism can't work 
unless there are some rules about compatibility of calling/return conventions.

The case you ran into is an unfortunate corner case (which has caught lots of 
experienced Objective-C developers too), because in the architecture you were 
compiling for, sizeof (NSUInteger) == sizeof (CGFloat), and by default the 
compiler doesn't complain in that case, if the message is sent to a receiver of 
type 'id' in the source code method invocation.

On Apr 10, 2011, at 05:45, Philipp Leusmann wrote:

> In this situation XCode4 did not show a warning. 


There a couple of things you should do:

1. Turn on the "strict selector matching" compiler warning in your build 
settings.

2. Try to avoid naming your methods with names that seem likely to conflict 
with declarations already in the frameworks. Yes, I know this is ridiculous 
advice, because you can't be expected to know the name of every method that's 
already been declared, but in practical terms it's worth avoiding simple 
one-word method names like "width" or "size" or "name". The more specific your 
own method names are, the more likely you are to avoid clashes. Plus, it 
enhances your code's self-documentation characteristics! 

3. Pay attention to syntax coloring. In your preferences, make sure the 
"project" colors are different from the "other" colors. (They were by default 
in Xcode 3. I'm not sure they are different by default in Xcode 4).

In this case, if the color preferences were different, you would have noticed 
that the width/height invocations were the "wrong" color, and that would have 
been a clue to figure out why your own method signatures weren't being used.


___

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: NSManagedObjected isInserted

[Quincey Morris]

On Apr 10, 2011, at 06:52, Carter R. Harrison wrote:

> Can anybody ever think of a scenario where [NSManagedObject isInserted] 
> equals NO for an object that is initially fetched from the context?  And no 
> the object has not been deleted from the context prior to calling isInserted.

What do you mean by "initially fetched"? The object should return YES for 
"isInserted" from the time it's inserted to the time the store is 
committed/saved. It's not clear where in this timeline your "initially" is 
pointing.


___

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: Controller Selection Synchronization

[Quincey Morris]

On Apr 10, 2011, at 07:56, Richard Somers wrote:

> The primary view is a custom view that displays objects spatially according 
> to their position in x, y, z coordinate space. The secondary views are table 
> type views.

> I currently have a transient selection property for each object in the data 
> model which helps in restoring the selection when undoing an object delete. 
> The primary controller (for the custom primary view) is a custom programatic 
> subclass of NSArrayController that synchronizes the primary controller 
> selection with the transient selection property.
> 
> The secondary controllers (NSArrayController and NSObjectController) and 
> secondary views (table views) are all standard Interface Builder objects.
> 
> The problem is how to synchronizing the selection among all the various 
> controllers.

In the primary views, objects can get their selection status the same way they 
get (for example) their xyz position, whatever that is. For example, view 
objects could be KVO observers of their data model properties, or the custom 
view could do this on their behalf, or something could be pushing property 
value updates out to the UI objects.

For the other views, I'd suggest making 2 selectionIndexes properties (assuming 
NSTableView -- outline views are slightly different) in the window controller, 
and binding the array controllers to these properties. Whatever mechanism is 
getting selection status to your primary view objects should also maintain 
these 2 properties, KVO compliantly of course. The last piece would be to use 
the table view delegate method to push changes of selection in the table to 
your main view. (That would apparently send you round in a loop updating the 2 
properties, so you'd probably want to check whether the 2 properties really 
need updating before doing it, rather than relying on the frameworks doing 
nothing if you set the selectionIndexes properties to the current selection 
indexes.) Or, you could observe the properties instead of using the delegate 
method.


___

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

Mac App Store requirements

[Artemiy Pavlov]

Hey all,

I am not yet a member of the Mac Developer program, but I am experimenting with 
my own Cocoa OS X app and I would like to know what are the requirements on 
getting it into the Mac App Store.

I mean, I have a 32/64 bit Intel build of a vanilla Cocoa app in XCode. Where 
will I go from there? Apart from signing the code with a certificate that you 
receive from Apple, what one needs to do to get his app bundle into the Mac App 
Store? 

Thanks a lot!


All the best,

Artemiy.___

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: Mac App Store requirements

[Laurent Daudelin]

There is a set of guidelines about things you should avoid if you don't want 
your app to be rejected. Not sure if it's available to non-registered Mac 
developers but I think it should.

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com

On Apr 10, 2011, at 11:16, Artemiy Pavlov wrote:

> Hey all,
> 
> I am not yet a member of the Mac Developer program, but I am experimenting 
> with my own Cocoa OS X app and I would like to know what are the requirements 
> on getting it into the Mac App Store.
> 
> I mean, I have a 32/64 bit Intel build of a vanilla Cocoa app in XCode. Where 
> will I go from there? Apart from signing the code with a certificate that you 
> receive from Apple, what one needs to do to get his app bundle into the Mac 
> App Store? 

___

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: NSManagedObjected isInserted

[Carter R. Harrison]

On Apr 10, 2011, at 1:29 PM, Quincey Morris wrote:

> On Apr 10, 2011, at 06:52, Carter R. Harrison wrote:
> 
>> Can anybody ever think of a scenario where [NSManagedObject isInserted] 
>> equals NO for an object that is initially fetched from the context?  And no 
>> the object has not been deleted from the context prior to calling isInserted.
> 
> What do you mean by "initially fetched"? The object should return YES for 
> "isInserted" from the time it's inserted to the time the store is 
> committed/saved. It's not clear where in this timeline your "initially" is 
> pointing.
> 

I'm creating and NSManagedObject with [NSManagedObject 
initWithEntity:insertIntoManagedObjectContext:] and for the context I'm passing 
nil.  Later I call [NSManagedObjectContext insertObject:] and pass in the same 
NSManagedObject that was initialized earlier.

On a subsequent run of my application I fetch the object from the store and 
call [NSManagedObject isInserted].  Without fail it always returns NO.



___

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: Mac App Store requirements

[Jason Harris]

Is it about as easy / difficult as adding say Sparkle support to your app? 
Easier? More difficult? (I also don't know this and I have been planning to add 
MacHg to the MacApp store at some stage in the not too distant future...)

Thanks!
  Jas

On Apr 10, 2011, at 8:47 PM, Laurent Daudelin wrote:

> There is a set of guidelines about things you should avoid if you don't want 
> your app to be rejected. Not sure if it's available to non-registered Mac 
> developers but I think it should.
> 
> -Laurent.
> -- 
> Laurent Daudelin
> AIM/iChat/Skype:LaurentDaudelin   
> http://www.nemesys-soft.com/
> Logiciels Nemesys Software
> laur...@nemesys-soft.com
> 
> On Apr 10, 2011, at 11:16, Artemiy Pavlov wrote:
> 
>> Hey all,
>> 
>> I am not yet a member of the Mac Developer program, but I am experimenting 
>> with my own Cocoa OS X app and I would like to know what are the 
>> requirements on getting it into the Mac App Store.
>> 
>> I mean, I have a 32/64 bit Intel build of a vanilla Cocoa app in XCode. 
>> Where will I go from there? Apart from signing the code with a certificate 
>> that you receive from Apple, what one needs to do to get his app bundle into 
>> the Mac App Store? 
> 
> ___
> 
> 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/jason%40jasonfharris.com
> 
> This email sent to ja...@jasonfharris.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

AVFoundation and OpenGL?

[John Michael Zorko]

Hello, all ...

I've been playing with Core Animation and AVFoundation to get some interesting 
results. I've a question, though, with regards to AVFoundation and OpenGL:

Can I make OpenGL work with AVPlayerLayer?

Regards,

John


___

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: Mac App Store requirements

[Artemiy Pavlov]

I am aware of this, and I meant only the technical side. So I built a Cocoa app 
with XCode, so I can join the developer programme and I am ready to go just 
like that?

A.

On 10 Apr 2011, at 21:47, Laurent Daudelin wrote:

> There is a set of guidelines about things you should avoid if you don't want 
> your app to be rejected. Not sure if it's available to non-registered Mac 
> developers but I think it should.
> 
> -Laurent.
> -- 
> Laurent Daudelin
> AIM/iChat/Skype:LaurentDaudelin   
> http://www.nemesys-soft.com/
> Logiciels Nemesys Software
> laur...@nemesys-soft.com
> 
> On Apr 10, 2011, at 11:16, Artemiy Pavlov wrote:
> 
>> Hey all,
>> 
>> I am not yet a member of the Mac Developer program, but I am experimenting 
>> with my own Cocoa OS X app and I would like to know what are the 
>> requirements on getting it into the Mac App Store.
>> 
>> I mean, I have a 32/64 bit Intel build of a vanilla Cocoa app in XCode. 
>> Where will I go from there? Apart from signing the code with a certificate 
>> that you receive from Apple, what one needs to do to get his app bundle into 
>> the Mac App Store? 
> 

___

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

AVAssetImageGenerator and HTTP-Live streams

[John Michael Zorko]

Hello again ...

I've found that when I use AVAssetImageGenerator to try to create a thumbnail 
from an HTTP-Live video stream, it fails, yet it works for basic M4V streams. I 
suspect that the multiple-bitrate nature of HTTP-Live is messing with it. I 
suppose I can parse the M3U8 myself and choose one of the bitrate streams, then 
parse the M3U8 for that stream and make an asset of one segment just to get the 
thumbnail, but i'm wondering if there's an easier way?

The URL of the stream i'm trying to generate a thumbnail for is:

http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8

Regards,

John

___

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: Mac App Store requirements

[Tom Hohensee]

Not yet. You have some setup work to do in itunesconnect.  
Apple provides a step by step guideline for submission

Sent from my iPhone

On Apr 10, 2011, at 2:28 PM, Artemiy Pavlov  wrote:

> I am aware of this, and I meant only the technical side. So I built a Cocoa 
> app with XCode, so I can join the developer programme and I am ready to go 
> just like that?
> 
> A.
> 
> On 10 Apr 2011, at 21:47, Laurent Daudelin wrote:
> 
>> There is a set of guidelines about things you should avoid if you don't want 
>> your app to be rejected. Not sure if it's available to non-registered Mac 
>> developers but I think it should.
>> 
>> -Laurent.
>> -- 
>> Laurent Daudelin
>> AIM/iChat/Skype:LaurentDaudelinhttp://www.nemesys-soft.com/
>> Logiciels Nemesys Software  laur...@nemesys-soft.com
>> 
>> On Apr 10, 2011, at 11:16, Artemiy Pavlov wrote:
>> 
>>> Hey all,
>>> 
>>> I am not yet a member of the Mac Developer program, but I am experimenting 
>>> with my own Cocoa OS X app and I would like to know what are the 
>>> requirements on getting it into the Mac App Store.
>>> 
>>> I mean, I have a 32/64 bit Intel build of a vanilla Cocoa app in XCode. 
>>> Where will I go from there? Apart from signing the code with a certificate 
>>> that you receive from Apple, what one needs to do to get his app bundle 
>>> into the Mac App Store? 
>> 
> 
> ___
> 
> 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/tom.hohensee%40gmail.com
> 
> This email sent to tom.hohen...@gmail.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: Can an image be "rejected" by CALayer?

[Gabriel Zachmann]

>> I am creating CA layers like so:
>> 
>>   CALayer * imgLayer = [CALayer layer];
>>   imgLayer.contents  = (id) image;   
>>   imgLayer.contentsGravity   = kCAGravityResizeAspect;
>>   imgLayer.delegate  = nil;
>>   imgLayer.opacity   = 1.0;  
>>   imgLayer.position  = CGPointMake( drawRect_.size.width/2.0, 
>> drawRect_.size.height/2.0 );
>>   imgLayer.anchorPoint   = CGPointMake( 0.5, 0.5 );
>>   imgLayer.zPosition = -1.0; 
>> 
>> Now, sometimes, the image does not get displayed (most images do get 
>> displayed).=
> 
> What is "image"?

Sorry for forgetting to tell:  'image' is a CGImageRef, which I create like so:

CGImageRef imageRef = CGImageSourceCreateImageAtIndex( sourceRef, 0, 
NULL );

Any ideas what might go wrong?

Best regards,
Gabriel.



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: Mac App Store requirements

[davelist]

And you also have add code to verify a valid receipt. There's a few samples of 
how to do this on github (you should modify them to make the app more difficult 
to crack unless you're giving the app away for free). Apple has more about this 
that you can read once you join the developer program.

Dave

On Apr 10, 2011, at 3:48 PM, Tom Hohensee wrote:

> Not yet. You have some setup work to do in itunesconnect.  
> Apple provides a step by step guideline for submission
> 
> Sent from my iPhone
> 
> On Apr 10, 2011, at 2:28 PM, Artemiy Pavlov  wrote:
> 
>> I am aware of this, and I meant only the technical side. So I built a Cocoa 
>> app with XCode, so I can join the developer programme and I am ready to go 
>> just like that?
>> 
>> A.
>> 
>> On 10 Apr 2011, at 21:47, Laurent Daudelin wrote:
>> 
>>> There is a set of guidelines about things you should avoid if you don't 
>>> want your app to be rejected. Not sure if it's available to non-registered 
>>> Mac developers but I think it should.
>>> 
>>> -Laurent.
>>> -- 
>>> Laurent Daudelin
>>> AIM/iChat/Skype:LaurentDaudelinhttp://www.nemesys-soft.com/
>>> Logiciels Nemesys Software  laur...@nemesys-soft.com
>>> 
>>> On Apr 10, 2011, at 11:16, Artemiy Pavlov wrote:
>>> 
 Hey all,
 
 I am not yet a member of the Mac Developer program, but I am experimenting 
 with my own Cocoa OS X app and I would like to know what are the 
 requirements on getting it into the Mac App Store.
 
 I mean, I have a 32/64 bit Intel build of a vanilla Cocoa app in XCode. 
 Where will I go from there? Apart from signing the code with a certificate 
 that you receive from Apple, what one needs to do to get his app bundle 
 into the Mac App Store? 
>>> 
>> 
>> ___
>> 
>> 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/tom.hohensee%40gmail.com
>> 
>> This email sent to tom.hohen...@gmail.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/davelist%40mac.com
> 
> This email sent to davel...@mac.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: Mac App Store requirements

[Todd Heberlein]

On Apr 10, 2011, at 4:32 PM, davel...@mac.com wrote:

> And you also have add code to verify a valid receipt. There's a few samples 
> of how to do this on github (you should modify them to make the app more 
> difficult to crack unless you're giving the app away for free). Apple has 
> more about this that you can read once you join the developer program.

Validating the receipt is optional.

Having recently gone through this with my first application, I generally would 
not recommend it for version 1.0 of someone's first app (unless it is a very 
expensive app). It is surprisingly complex and poorly documented, and there are 
too many other things to worry about when getting your first app through the 
approval process.

If you want copy protection (which is what receipt validation in about), I 
would leave it until the first update to your application or the second app you 
submit.

Todd

___

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: Mac App Store requirements

[Tom Hohensee]

Yes
I second what Todd has said.  I am currently working on receipt  
validation for my third app store app.  I did not do it for my first  
two apps, too many other thinks to worry about.   The documentation is  
not very good at this point.


Tom

On Apr 10, 2011, at 6:45 PM, Todd Heberlein wrote:



On Apr 10, 2011, at 4:32 PM, davel...@mac.com wrote:

And you also have add code to verify a valid receipt. There's a few  
samples of how to do this on github (you should modify them to make  
the app more difficult to crack unless you're giving the app away  
for free). Apple has more about this that you can read once you  
join the developer program.


Validating the receipt is optional.

Having recently gone through this with my first application, I  
generally would not recommend it for version 1.0 of someone's first  
app (unless it is a very expensive app). It is surprisingly complex  
and poorly documented, and there are too many other things to worry  
about when getting your first app through the approval process.


If you want copy protection (which is what receipt validation in  
about), I would leave it until the first update to your application  
or the second app you submit.


Todd

___

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/tomhoh%40mac.com

This email sent to tom...@mac.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

file done writing?

[Rainer Standke]

Hello,

I have an application that needs to wait for a file to be fully written. I 
tried this by getting an NSFilehandle, and with open() and fopen(), hoping that 
a failure of these would indicate that they are not done writing yet. However, 
I get only successes, even if the file is clearly still copying.

Is there any way to tell if a file is done being written?

Thanks,

Rainer

___

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: Mac App Store requirements

[Laurent Daudelin]

On Apr 10, 2011, at 16:45, Todd Heberlein wrote:

> On Apr 10, 2011, at 4:32 PM, davel...@mac.com wrote:
> 
>> And you also have add code to verify a valid receipt. There's a few samples 
>> of how to do this on github (you should modify them to make the app more 
>> difficult to crack unless you're giving the app away for free). Apple has 
>> more about this that you can read once you join the developer program.
> 
> Validating the receipt is optional.
> 
> Having recently gone through this with my first application, I generally 
> would not recommend it for version 1.0 of someone's first app (unless it is a 
> very expensive app). It is surprisingly complex and poorly documented, and 
> there are too many other things to worry about when getting your first app 
> through the approval process.
> 
> If you want copy protection (which is what receipt validation in about), I 
> would leave it until the first update to your application or the second app 
> you submit.

Don't forget that verifying the receipt doesn't get you much. A user can still 
install an unlimited number of copies on any Macs he wants. He just has to 
enter his iTunes Apple ID and password, that's it. I didn't think it was worth 
the effort for my first app.

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.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: file done writing?

[Scott Ribe]

On Apr 10, 2011, at 5:57 PM, Rainer Standke wrote:

> Is there any way to tell if a file is done being written?

In general, no. There are lots of "maybe kind of" solutions, including trying 
to open for exclusive access. But there is absolutely no way, nor can there be, 
to know when to read a file that is being written by another app--which is what 
I think you're asking for--unless the other app provides some protocol for that.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.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 arch...@mail-archive.com

Re: Using selectedMenuItemColor

[Eric Gorr]

On Apr 10, 2011, at 2:13 AM, Lee Ann Rucker wrote:

> Interesting - if you set the view so its Y origin is zero, it draws as 
> expected.

Hummm...I can't seem to get it to do much. If I alter the code to:

[self setFrameOrigin:NSMakePoint( 0, 0 )];

for ( x = 0; x < 10; x++ )
{   
blockFrame.origin.x = ( x * xOffset ) + NSMinX( secondThird );
blockFrame.origin.y = ( x * yOffset ) + NSMinY( secondThird );

NSRectFill( blockFrame );

}

The smaller rectangles all come out black.

I've tried variations on this, including using setBoundsOrigin

I know I am missing something obvious...

> BTW, you should be using [self bounds], not [self frame].

Thanks...ya, corrected that soon after I uploaded the code.

___

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: Using selectedMenuItemColor

[Graham Cox]

On 11/04/2011, at 11:33 AM, Eric Gorr wrote:

> Hummm...I can't seem to get it to do much. If I alter the code to:


Have you tried using NSAffineTransform to offset the coordinate system to where 
you want to draw? You probably don't need or want to mess with your view 
coordinates or frame, you just need to move the coordinate system around within 
the view using the CTM.

e.g. if you want to highlight the rect  (typed into mail, untested):

NSRect hr = NSMakeRect( 100, 100, 200, 120 );

[NSGraphicsContext saveGraphicsState];

NSAffineTransform* tfm = [NSAffineTransform transform];
[tfm translateXBy:hr.origin.x yBy:hr.origin.y];
[tfm concat];

hr.origin = NSZeroPoint;

NSRectFill( hr );

[NSGraphicsContext restoreGraphicsState];



So you offset to the rect origin, then draw at 0,0. 

--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 arch...@mail-archive.com

Re: Using selectedMenuItemColor

[Eric Gorr]

On Apr 10, 2011, at 10:09 PM, Graham Cox wrote:

> 
> On 11/04/2011, at 11:33 AM, Eric Gorr wrote:
> 
>> Hummm...I can't seem to get it to do much. If I alter the code to:
> 
> 
> Have you tried using NSAffineTransform to offset the coordinate system to 
> where you want to draw? You probably don't need or want to mess with your 
> view coordinates or frame, you just need to move the coordinate system around 
> within the view using the CTM.
> 
> e.g. if you want to highlight the rect  (typed into mail, untested):
> 
> NSRect hr = NSMakeRect( 100, 100, 200, 120 );
> 
> [NSGraphicsContext saveGraphicsState];
> 
> NSAffineTransform* tfm = [NSAffineTransform transform];
> [tfm translateXBy:hr.origin.x yBy:hr.origin.y];
> [tfm concat];
> 
> hr.origin = NSZeroPoint;
> 
> NSRectFill( hr );
> 
> [NSGraphicsContext restoreGraphicsState];
> 
> So you offset to the rect origin, then draw at 0,0. 


Thanks Graham.

I changed the code to:

for ( x = 0; x < 10; x++ )
{   
blockFrame.origin.x = ( x * xOffset ) + NSMinX( secondThird );
blockFrame.origin.y = ( x * yOffset );

[NSGraphicsContext saveGraphicsState];
NSAffineTransform* tfm = [NSAffineTransform transform];

[tfm translateXBy:blockFrame.origin.x yBy:blockFrame.origin.y];

[tfm concat];

blockFrame.origin = NSZeroPoint;

NSRectFill( blockFrame );

[NSGraphicsContext restoreGraphicsState];
}

However, it had no effect.

I'll keep playing with this until a solution is found - if there is one.

Oh, I did figure out that, after calling setBoundsOrigin, to have the rectangle 
filled with something other then black, one needs to call [[NSColor 
selectedMenuItemColor] set] again. But, I still couldn't get it to do what I 
wanted it to do.

Seems to be an interesting problem. Perhaps the only solution is the NSImage 
route...


___

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: Can an image be "rejected" by CALayer?

[Matt Neuburg]

On Sun, 10 Apr 2011 22:29:55 +0200, Gabriel Zachmann  
said:
>>> I am creating CA layers like so:
>>> 
>>>   CALayer * imgLayer= [CALayer layer];
>>>   imgLayer.contents = (id) image;   
>>>   imgLayer.contentsGravity  = kCAGravityResizeAspect;
>>>   imgLayer.delegate = nil;
>>>   imgLayer.opacity  = 1.0;  
>>>   imgLayer.position = CGPointMake( drawRect_.size.width/2.0, 
>>> drawRect_.size.height/2.0 );
>>>   imgLayer.anchorPoint  = CGPointMake( 0.5, 0.5 );
>>>   imgLayer.zPosition= -1.0; 
>>> 
>>> Now, sometimes, the image does not get displayed (most images do get 
>>> displayed).=
>> 
>> What is "image"?
>
>Sorry for forgetting to tell:  'image' is a CGImageRef, which I create like so:
>
>   CGImageRef imageRef = CGImageSourceCreateImageAtIndex( sourceRef, 0, 
> NULL );
>
>Any ideas what might go wrong?

Well, my next guess is the frame. I don't see you setting the layer's frame 
anywhere, so its size is zero by zero, which means that it is effectively 
invisible.

Show all the code by which the layer is configured and put into the interface 
if you want a more educated response. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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: Strange property/synthesized accessor behaviour

[Matt Neuburg]

On Sun, 10 Apr 2011 14:45:12 +0200, Philipp Leusmann  said:
>In this situation XCode4 did not show a warning. 

This reminds me of this:



I was tromping on an undocumented existing ivar and I didn't get any warning. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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: Remove Duplicates in a NSArray

[Matt Neuburg]

On Sun, 10 Apr 2011 12:42:50 -0400, Christopher Nagel  said:
>Could you just add each dictionary to a single dict and then have a  
>globally unique set of keys?  This would presuppose you know which  
>value of testKey is the one you wan to retain, and you'd add that one  
>last.
>
>On Oct 1, 2008, at 7:29 AM, Rashmi Vyshnavi wrote:

I'm betting that after two and a half years he probably solved it somehow. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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

OCMock in Xcode 4

[qvacua]

Hi,

I'm trying to to get OCMock to work with Xcode 4. I created a new
blank project with unit tests enabled. I added OCMock.framework file
to the test target. What I get is that the framework cannot be loaded
because the image is not found. I tried with a copy phase to copy the
framework to the test target, but it did not help. The framework
search path is automatically adapted when I add the framework to the
target. What's wrong? How can I use OCMock with Xcode 4?

Thanks in advance.

Best.
___

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

blocks and NSInvocation question

[John Michael Zorko]

Hello, all ...

I'm stumped as to why this generates a warning when I compile. Do I need to do 
something special with my AVURLAsset * to be able to access it from inside the 
block in order to add it to an NSInvocation?

for (int index = 0; index < [assetsToLoad count]; index ++)
{
NSURL *streamURL = [assetsToLoad objectAtIndex:index];
AVURLAsset *asset = [AVURLAsset URLAssetWithURL:streamURL options:nil];
NSString *tracks = @"tracks";

[asset loadValuesAsynchronouslyForKeys:[NSArray arrayWithObject:tracks] 
completionHandler:^
 {
 SEL sel = @selector(setupPlayerForAsset:withIndex:);
 NSMethodSignature *sig = [self methodSignatureForSelector:sel];
 NSInvocation *inv = [NSInvocation 
invocationWithMethodSignature:sig];
 NSNumber *invNumber = [NSNumber numberWithInt:index];
 [inv setTarget:self];
 [inv setSelector:sel];
 [inv setArgument:&asset atIndex:2];// warning: passing 
argument 1 of 'setArgument:atIndex:' discards qualifiers from pointer target 
type



 [inv setArgument:&invNumber atIndex:3];
 [inv retainArguments]; 
 [inv performSelectorOnMainThread:@selector(invoke) withObject:nil 
waitUntilDone:YES];
 [self performSelectorOnMainThread:sel withObject:asset 
waitUntilDone:YES];
 }];
}
}

Regards,

John

___

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: file done writing?

[Rainer Standke]

Thanks Scott,

this is helpful and good to know. In the meantime I have played a little with 
lsof on the command line, and it seems to sort of answer the question wether or 
not someone has a file open with authority... but it's very slow.

Just to enlighten me, why can't there be no absolute way to know when a file 
has been completed? I'm not doubting you, just trying to learn... is it because 
you can't predict what's going to happen right the second after you look?

Your idea to have the other app flag me makes a lot of sense to me, thanks 
again,

Rainer


On Apr 10, 2011, at 17:53, Scott Ribe wrote:

> On Apr 10, 2011, at 5:57 PM, Rainer Standke wrote:
> 
>> Is there any way to tell if a file is done being written?
> 
> In general, no. There are lots of "maybe kind of" solutions, including trying 
> to open for exclusive access. But there is absolutely no way, nor can there 
> be, to know when to read a file that is being written by another app--which 
> is what I think you're asking for--unless the other app provides some 
> protocol for that.
> 
> -- 
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-dev.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 arch...@mail-archive.com

Re: NSManagedObjected isInserted

[Jerry Krinock]

On 2011 Apr 10, at 11:52, Carter R. Harrison wrote:

> On Apr 10, 2011, at 1:29 PM, Quincey Morris wrote:
> 
>> The object should return YES for "isInserted" from the time it's inserted to 
>> the time the store is committed/saved.
> 
> On a subsequent run of my application I fetch the object from the store and 
> call [NSManagedObject isInserted].  Without fail it always returns NO.

If you read Quincey's post, he answers your question … after the store has been 
saved, its new objects return NO to -isInserted.

The documentation for -isInserted makes no mention of this.  But it wouldn't be 
the first time that Quincey was better than documentation.

___

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: file done writing?

[Gary L. Wade]

If you have full control of both applications, try making the writer do
its work on a temporary file and move it in place when done.  Look at the
atomic writing messages that do a flavor of this.  You might find the
FSEvents mechanism something to consider if you're watching a dump folder
where the originator application is something you have no control over.
There are also very-Darwin-level mechanisms for seeing if a file is open,
but those are not guaranteed to remain the same from one patch release to
the next.  Also, getting back to your open-test mechanism, see if it is
not possible to move a file that's open; if that guarantees only to work
if the file is not opened, then maybe you should try moving the file to a
"waiting room" folder to work on it.

On 04/10/2011 10:04 PM, "Rainer Standke"  wrote:

>Thanks Scott,
>
>this is helpful and good to know. In the meantime I have played a little
>with lsof on the command line, and it seems to sort of answer the
>question wether or not someone has a file open with authority... but it's
>very slow.
>
>Just to enlighten me, why can't there be no absolute way to know when a
>file has been completed? I'm not doubting you, just trying to learn... is
>it because you can't predict what's going to happen right the second
>after you look?
>
>Your idea to have the other app flag me makes a lot of sense to me,
>thanks again,
>
>Rainer


___

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: Framework Installation Directory

[Jerry Krinock]

On Friday, April 8, 2011, Mr. Gecko  wrote:

> I need help with the Installation Directory for a framework that will be 
> shared between a application and 2 daemons within side it. I think I may be 
> able to do it if I were to have the 2 daemons executables in the MacOS path 
> or another folder such as one named Daemons in the Contents folder. I am 
> needing at least 1 of the daemons to be a bundle based daemon as it'll have 
> some UI elements and such. The installation directory that I have been doing 
> is "@executable_path/../Frameworks" which according to this, it'll go back 1 
> directory from the path of the executable and into the Frameworks directory 
> to find the framework. The reason I am thinking in doing this as a framework 
> is because some of the code I am using will be used in the daemons such as 
> core code.

I have built an app like this and it works; however at the time, I was advised 
to put the Helper in Contents/Helpers instead of MacOS.

Read these:

http://www.cocoabuilder.com/archive/cocoa/233139-getprocessbundlelocation-no-good-in-background-agents.html#233141

http://lists.apple.com/archives/apple-cdsa/2009/May/msg00031.html

and there may be code signing implications too

http://developer.apple.com/library/mac/#technotes/tn2206/_index.html

Early on, test and see if +[NSBundle mainBundle] gives the expected result.  It 
did not for me.  After considering the various bad alternatives, I decided to 
do a method replacement on +[NSBundle mainBundle].  There may be a better 
alternative today.

___

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