Re: Helping Arc with: "PerformSelector may cause a leak because its selector is unknown"

[Gerriet M. Denkmann]

On 22 Oct 2013, at 13:48, Gideon King  wrote:

> You can tell it to ignore the warning like this:
> 
> #pragma clang diagnostic push
> #pragma clang diagnostic ignored "-Warc-performSelector-leaks"
>   NSNumber *status = [ self performSelector: aSelector  withObject: a  
> withObject: b ];
> #pragma clang diagnostic pop
> 
> Hope that helps.

This certainly helps: at least I get a clean compile.
But telling the compiler about the type of selector to expect would be even 
better.
Can this be done?

Kind regards,

Gerriet.


> 
> On 22/10/2013, at 4:37 PM, "Gerriet M. Denkmann"  wrote:
> 
>> 
>> Xcode 5.0 complains: "PerformSelector may cause a leak because its selector 
>> is unknown"
>> 
>> Is there a way to tell the compiler that "aSelector" returns an object which 
>> does NOT need to get released by the caller ? 
>> I saw something like "__autoreleasing", but don't know how to apply this in 
>> my case.
>> 
>> Gerriet.
>> 
> 


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Helping Arc with: "PerformSelector may cause a leak because its selector is unknown"

[Igor Elland]

> This certainly helps: at least I get a clean compile.
> But telling the compiler about the type of selector to expect would be even 
> better.
> Can this be done?

You might want to look into using NSInvocation instead.

Best,
Elland
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Arc: Switch case is in protected scope

[Gerriet M. Denkmann]

Converting to Arc (Xcode 5.0).

This works fine without Arc (regardless whether TRIGGER_ERROR is defined or 
not):

NSMutableString *mus = [ NSMutableString string ];
NSString *word = @"abc";

switch( self.colourType )
{
case colour_link:   
[ mus appendString: @"https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[ChanMaxthon]

Just put a set of braces after every case: and it should be okay. A set of 
braces here actually sets up a mini stack frame that makes ARC work.

Sent from my iPhone

> On 2013年10月22日, at 15:41, "Gerriet M. Denkmann"  wrote:
> 
> Converting to Arc (Xcode 5.0).
> 
> This works fine without Arc (regardless whether TRIGGER_ERROR is defined or 
> not):
> 
> NSMutableString *mus = [ NSMutableString string ];
> NSString *word = @"abc";
> 
> switch( self.colourType )
> {
>case colour_link:
>[ mus appendString: @"#defineTRIGGER_ERROR
>#ifdefTRIGGER_ERROR
>NSString *urlStr = [ word stringByAddingPercentEscapesUsingEncoding: 
> NSUTF8StringEncoding ];
>[ mus appendString: urlStr ];
>#else//no_ERROR
>[ mus appendString: [ word stringByAddingPercentEscapesUsingEncoding: 
> NSUTF8StringEncoding ] ];
>#endif//no_ERROR
>
>break;
>
>default: 
>[ mus appendString: word ];
> };
> 
> But with Arc, if TRIGGER_ERROR is defined, I get an error: "Switch case is in 
> protected scope" with the further explanation: "Jump bypasses initialization 
> of retaining variable".
> 
> 
> Was the old (non-arc) code faulty (but the compiler did not notice this)?
> Why is the arc-version (with TRIGGER_ERROR defined) wrong?
> 
> Gerriet.
> 
> 
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com
> 
> This email sent to xcvi...@me.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Helping Arc with: "PerformSelector may cause a leak because its selector is unknown"

[ChanMaxthon]

I suggest against NSInvocation. I will just throw in a direct call to 
objc_msgSend.

Sent from my iPhone

On 2013年10月22日, at 15:33, Igor Elland  wrote:

>> This certainly helps: at least I get a clean compile.
>> But telling the compiler about the type of selector to expect would be even 
>> better.
>> Can this be done?
> 
> You might want to look into using NSInvocation instead.
> 
> Best,
> Elland
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com
> 
> This email sent to xcvi...@me.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Helping Arc with: "PerformSelector may cause a leak because its selector is unknown"

[Igor Elland]

> I suggest against NSInvocation. I will just throw in a direct call to 
> objc_msgSend.

Care to elaborate? 
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[ChanMaxthon]

This problem comes from C variable scopes regarding braces. For most cases it 
is just fine but for switch() all cases are in the same scope, jumping around. 
ARC inserts code at beginning and end of scopes (mini stack frames here) so if 
a new ARC variable is defined in switch() it gets confused.

Sent from my iPhone

> On 2013年10月22日, at 15:41, "Gerriet M. Denkmann"  wrote:
> 
> Converting to Arc (Xcode 5.0).
> 
> This works fine without Arc (regardless whether TRIGGER_ERROR is defined or 
> not):
> 
> NSMutableString *mus = [ NSMutableString string ];
> NSString *word = @"abc";
> 
> switch( self.colourType )
> {
>case colour_link:
>[ mus appendString: @"#defineTRIGGER_ERROR
>#ifdefTRIGGER_ERROR
>NSString *urlStr = [ word stringByAddingPercentEscapesUsingEncoding: 
> NSUTF8StringEncoding ];
>[ mus appendString: urlStr ];
>#else//no_ERROR
>[ mus appendString: [ word stringByAddingPercentEscapesUsingEncoding: 
> NSUTF8StringEncoding ] ];
>#endif//no_ERROR
>
>break;
>
>default: 
>[ mus appendString: word ];
> };
> 
> But with Arc, if TRIGGER_ERROR is defined, I get an error: "Switch case is in 
> protected scope" with the further explanation: "Jump bypasses initialization 
> of retaining variable".
> 
> 
> Was the old (non-arc) code faulty (but the compiler did not notice this)?
> Why is the arc-version (with TRIGGER_ERROR defined) wrong?
> 
> Gerriet.
> 
> 
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com
> 
> This email sent to xcvi...@me.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Gerriet M. Denkmann]

On 22 Oct 2013, at 14:48, ChanMaxthon  wrote:

> Just put a set of braces after every case: and it should be okay. A set of 
> braces here actually sets up a mini stack frame that makes ARC work.
> 

非常感谢
Works perfectly now.
(I still would like to know whether my code was faulty, or whether this is a 
compiler bug)


Kind regards

Gerriet.

>> On 2013年10月22日, at 15:41, "Gerriet M. Denkmann"  wrote:
>> 
>> Converting to Arc (Xcode 5.0).
>> 
>> This works fine without Arc (regardless whether TRIGGER_ERROR is defined or 
>> not):
>> 
>> NSMutableString *mus = [ NSMutableString string ];
>> NSString *word = @"abc";
>> 
>> switch( self.colourType )
>> {
>>   case colour_link:
>>   [ mus appendString: @">   #defineTRIGGER_ERROR
>>   #ifdefTRIGGER_ERROR
>>   NSString *urlStr = [ word stringByAddingPercentEscapesUsingEncoding: 
>> NSUTF8StringEncoding ];
>>   [ mus appendString: urlStr ];
>>   #else//no_ERROR
>>   [ mus appendString: [ word stringByAddingPercentEscapesUsingEncoding: 
>> NSUTF8StringEncoding ] ];
>>   #endif//no_ERROR
>> 
>>   break;
>> 
>>   default: 
>>   [ mus appendString: word ];
>> };
>> 
>> But with Arc, if TRIGGER_ERROR is defined, I get an error: "Switch case is 
>> in protected scope" with the further explanation: "Jump bypasses 
>> initialization of retaining variable".
>> 
>> 
>> Was the old (non-arc) code faulty (but the compiler did not notice this)?
>> Why is the arc-version (with TRIGGER_ERROR defined) wrong?
>> 


___

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

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

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

This email sent to arch...@mail-archive.com

Re: Helping Arc with: "PerformSelector may cause a leak because its selector is unknown"

[ChanMaxthon]

Giving a mini performance boost. NSInvocation is utterly slow (multiple memory 
allocations asking for syscalls, and a chain of function calls including at 
least two objc_msgSends to invoke a method.) but good for IMP caching

performSelector methods are slightly slower than direct calls since there are 
two calls to objc_msgSend

Sent from my iPhone

> On 2013年10月22日, at 15:55, Igor Elland  wrote:
> 
> 
>> I suggest against NSInvocation. I will just throw in a direct call to 
>> objc_msgSend.
> 
> Care to elaborate? 

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[ChanMaxthon]

Compiler issue. All cases in a switch statement shares a same scope, and ARC 
works by inserting code into beginning and end of scopes. switch() statement 
jumps around, making code path very unpredictable, confusing ARC.

Sent from my iPhone

> On 2013年10月22日, at 16:02, "Gerriet M. Denkmann"  wrote:
> 
> 
>> On 22 Oct 2013, at 14:48, ChanMaxthon  wrote:
>> 
>> Just put a set of braces after every case: and it should be okay. A set of 
>> braces here actually sets up a mini stack frame that makes ARC work.
> 
> 非常感谢
> Works perfectly now.
> (I still would like to know whether my code was faulty, or whether this is a 
> compiler bug)
> 
> 
> Kind regards
> 
> Gerriet.
> 
>>> On 2013年10月22日, at 15:41, "Gerriet M. Denkmann"  
>>> wrote:
>>> 
>>> Converting to Arc (Xcode 5.0).
>>> 
>>> This works fine without Arc (regardless whether TRIGGER_ERROR is defined or 
>>> not):
>>> 
>>> NSMutableString *mus = [ NSMutableString string ];
>>> NSString *word = @"abc";
>>> 
>>> switch( self.colourType )
>>> {
>>>  case colour_link:
>>>  [ mus appendString: @">>  #defineTRIGGER_ERROR
>>>  #ifdefTRIGGER_ERROR
>>>  NSString *urlStr = [ word stringByAddingPercentEscapesUsingEncoding: 
>>> NSUTF8StringEncoding ];
>>>  [ mus appendString: urlStr ];
>>>  #else//no_ERROR
>>>  [ mus appendString: [ word stringByAddingPercentEscapesUsingEncoding: 
>>> NSUTF8StringEncoding ] ];
>>>  #endif//no_ERROR
>>> 
>>>  break;
>>> 
>>>  default: 
>>>  [ mus appendString: word ];
>>> };
>>> 
>>> But with Arc, if TRIGGER_ERROR is defined, I get an error: "Switch case is 
>>> in protected scope" with the further explanation: "Jump bypasses 
>>> initialization of retaining variable".
>>> 
>>> 
>>> Was the old (non-arc) code faulty (but the compiler did not notice this)?
>>> Why is the arc-version (with TRIGGER_ERROR defined) wrong?
> 

___

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

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

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

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Graham Cox]

On 22/10/2013, at 9:02 AM, "Gerriet M. Denkmann"  wrote:

> (I still would like to know whether my code was faulty, or whether this is a 
> compiler bug


Your code was faulty, at least according to the rules of C (which could be 
argued about, but not fruitfully). If you insert temporary variables within a 
particular case, you need to put braces around the code for that case.

--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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Daniel Höpfl]

Hi,

On 2013-10-22 09:41, Gerriet M. Denkmann wrote:

Converting to Arc (Xcode 5.0).

This works fine without Arc (regardless whether TRIGGER_ERROR is
defined or not):

NSMutableString *mus = [ NSMutableString string ];
NSString *word = @"abc";

switch( self.colourType )
{
case colour_link:   
[ mus appendString: @"Was the old (non-arc) code faulty (but the compiler did not notice 
this)?

Why is the arc-version (with TRIGGER_ERROR defined) wrong?


It is wrong in the non-arc world, too. (ISO/IEC 9899:2011 AKA C11, 
6.8.6.1: "A goto statement shall not jump from outside the scope of an 
identifier having a variably modified type to inside the scope of that 
identifier" - switch is a special case of goto.)


In other words: urlStr is declared and initialized in the 
colour_link-case:. Since there is no scope limiting block in this case:, 
urlStr is in scope in the default-case. Now imagine urlStr was used in 
the default-case: What value would you expect it to have?


Sure, the compiler could detect that urlStr is never used in your 
default: (and/or that there is no way to get to default: from 
colour_link-case:) but I'm not sure if this can be done in all cases.


Bye,
   Daniel


___

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

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

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

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Daniel Höpfl]

Hi,

On 2013-10-22 10:06, ChanMaxthon wrote:

Compiler issue. All cases in a switch statement shares a same scope,
and ARC works by inserting code into beginning and end of scopes.
switch() statement jumps around, making code path very unpredictable,
confusing ARC.


It is a compiler issue. But as I wrote in my other post, the posted code 
is invalid C, so it is a compiler issue with the non-arc compiler.


Bye,
   Daniel

___

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

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

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

This email sent to arch...@mail-archive.com

I can't use man command to find c api manuals in Mavericks GM

[li shunnian]

Dear list,

After I updated to Mavericks GM, I can not use man command to find the manuals 
of the C api.
Can anyone tell me how to solve this problem?

Regards,
Li Shunnian.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: I can't use man command to find c api manuals in Mavericks GM

[Maxthon Chan]

Well you need Xcode and maybe the Command Line Tools package.

On Oct 22, 2013, at 16:56, li shunnian  wrote:

> Dear list,
> 
> After I updated to Mavericks GM, I can not use man command to find the 
> manuals of the C api.
> Can anyone tell me how to solve this problem?
> 
> Regards,
> Li Shunnian.
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com
> 
> This email sent to xcvi...@me.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSDocument save customisation and -fileModificationDate

[jonat...@mugginsoft.com]

In my document app I prompt users to save when switching views via:
NSDocument -canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo

I can call this once successfully after which I receive a sheet saying:
This document’s file has been changed by another application since you opened 
or saved it.

I figure this is related to -fileModificationDate, but I do update this 
(without effect) when saving (see below).

I also note that in -saveToURL:etc I don't actually need or want to create the 
file indicated by the url argument.
So perhaps that triggers the file modification warning?

And so it turns out; the following NSDocument override prevents the display of 
the warning sheet:

- (NSDate *)fileModificationDate
{
return nil;
}

This question is whether the above is just a rotten hack or is actually 
consistent with the internal operation of NSDocument.

I have customised NSDocument saving like so:

- (void)saveDocument:(id)sender
{
[self saveDocumentModel:self];
}

- (void)saveToURL:(NSURL *)url ofType:(NSString *)typeName 
forSaveOperation:(NSSaveOperationType)saveOperation completionHandler:(void 
(^)(NSError *errorOrNil))completionHandler
{
// this method will be called when attempting to close an edited document
[self saveDocumentModel:self];

// the completion handler will close the window if required
completionHandler(nil);
}

- (void)saveDocumentModel:(id)sender
{
// persist changes in the managed data store.
[self.entities saveChanges];

// clear the document edited status
[self updateChangeCount:NSChangeCleared];

[self setFileModificationDate:[NSDate date]]; // likely pointless in this 
case
}

Jonathan












___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to change highlight colour on NSTableView row

[Darren Wheatley]

Hi,

Thanks for the reply.

I tried the code sample you suggested but can't get it to work.

When running the default highlighting is being layered on top of this custom 
highlighting (I can see part of the custom highlighting where the rects are not 
quite overlapping). Do you know how I prevent the standard formatting from 
being displayed?

Also, (might be a symptom of the above) the custom highlighting is not always 
removed when I click on a new row. If I scroll those rows off the screen and 
back on the highlighting is fixed, so there is some sort of display refresh 
problem.

I have tried standard and source list highlighting (set in the xib), and both 
display the same behaviour.

Do you know what might be going on here, or anything I should check in my code? 
Any suggestions you could make would be very much appreciated.

FYI, I am developing on 10.8.5 and targeting 10.7.

Regards

Darren.



On 21 Oct 2013, at 17:23,  wrote:

> On 21 Oct 2013, at 16:19, Darren Wheatley  
> wrote:
> 
>> Hi,
>> 
>> I have a custom subclass of NSTableView in my app.
>> 
>> Can anyone suggest a method that will allow me to set a custom highlight 
>> colour on on a row when the user clicks on it?
>> 
>> I've Googled for a solution, but haven't been able to find anything that 
>> works.
>> 
>> 
> For cell based tables try:
> 
> - (void)highlightSelectionInClipRect:(NSRect)clipRect
> 
> There is a sample implementation at 
> http://stackoverflow.com/questions/7038709/change-highlighting-color-in-nstableview-in-cocoa.
> You may need to set selectionHighlightStyle to 
> NSTableViewSelectionHighlightStyleSourceList
> 
> Note: This method should not be subclassed or overridden for a view-base 
> table view. Instead, row drawing customization should be done by subclassing 
> NSTableRowView.
> 
> Jonathan
> 
> 
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/darren%40tenjinconsulting.co.uk
> 
> This email sent to dar...@tenjinconsulting.co.uk


___

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

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

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

This email sent to arch...@mail-archive.com

Re: How to change highlight colour on NSTableView row

[Darren Wheatley]

Hi,

Thanks for the reply.

I tried the code sample you suggested but can't get it to work.

When running the default highlighting is being layered on top of this custom 
highlighting (I can see part of the custom highlighting where the rects are not 
quite overlapping). Do you know how I prevent the standard formatting from 
being displayed?

Also, (might be a symptom of the above) the custom highlighting is not always 
removed when I click on a new row. If I scroll those rows off the screen and 
back on the highlighting is fixed, so there is some sort of display refresh 
problem.

I have tried standard and source list highlighting (set in the xib), and both 
display the same behaviour.

Do you know what might be going on here, or anything I should check in my code? 
Any suggestions you could make would be very much appreciated.

FYI, I am developing on 10.8.5 and targeting 10.7.

Regards

Darren.



On 21 Oct 2013, at 17:23,  wrote:

> On 21 Oct 2013, at 16:19, Darren Wheatley  
> wrote:
> 
>> Hi,
>> 
>> I have a custom subclass of NSTableView in my app.
>> 
>> Can anyone suggest a method that will allow me to set a custom highlight 
>> colour on on a row when the user clicks on it?
>> 
>> I've Googled for a solution, but haven't been able to find anything that 
>> works.
>> 
>> 
> For cell based tables try:
> 
> - (void)highlightSelectionInClipRect:(NSRect)clipRect
> 
> There is a sample implementation at 
> http://stackoverflow.com/questions/7038709/change-highlighting-color-in-nstableview-in-cocoa.
> You may need to set selectionHighlightStyle to 
> NSTableViewSelectionHighlightStyleSourceList
> 
> Note: This method should not be subclassed or overridden for a view-base 
> table view. Instead, row drawing customization should be done by subclassing 
> NSTableRowView.
> 
> Jonathan
> 
> 
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/darren%40tenjinconsulting.co.uk
> 
> This email sent to dar...@tenjinconsulting.co.uk


___

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

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

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

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Sean McBride]

On Tue, 22 Oct 2013 10:31:01 +0200, Daniel Höpfl said:

>> Was the old (non-arc) code faulty (but the compiler did not notice 
>> this)?
>> Why is the arc-version (with TRIGGER_ERROR defined) wrong?
>
>It is wrong in the non-arc world, too. (ISO/IEC 9899:2011 AKA C11, 
>6.8.6.1: "A goto statement shall not jump from outside the scope of an 
>identifier having a variably modified type to inside the scope of that 
>identifier" - switch is a special case of goto.)

Daniel,

I don't think you can quote the Standard about 'goto' and just wave your hands 
and say it applies to 'switch' also.  :)  The Standard's description of 
'switch' should contain the answer.

However, it does seem to me there is a clang bug here somewhere.

I've made a shorter compilable example:

--
#import 

int main (void)
{
int x = 0;
switch(x)
{
case 1:
x++;
#if 0 // toggle me
NSObject* foo = nil;
#else
int* foo = 0;
#endif
(void)foo;
break;

default: 
x++;
};

return 0;
}
--

Then build with both:
$ xcrun clang -fsyntax-only -Weverything test.m
$ xcrun clang -fsyntax-only -Weverything -fobjc-arc test.m

If 'foo' is int*, clang has no complaints in non-ARC and ARC.

If 'foo' is NSObject*, clang has no complaints in non-ARC, but errors in ARC.

IMHO, that's pretty weird!

The only bug I can find in llvm bugzilla that looks related was fixed years ago:


Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Scott Ribe]

On Oct 22, 2013, at 9:50 AM, Sean McBride  wrote:

> I don't think you can quote the Standard about 'goto' and just wave your 
> hands and say it applies to 'switch' also.  :)  The Standard's description of 
> 'switch' should contain the answer

Switch is just a pile of goto, and I'm pretty sure the standard says so 
somewhere.

> However, it does seem to me there is a clang bug here somewhere.

I don't think so. It's perhaps worth noting that in C++ or Objective-C++ you 
get a similar warning when you do this with an instance that has a constructor 
or destructor, and this goes back to versions of GCC from at least several 
years ago--trust me, I know about 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: I can't use man command to find c api manuals in Mavericks GM

[Todd Heberlein]

On Oct 22, 2013, at 2:19 AM, Maxthon Chan  wrote:

> Well you need Xcode and maybe the Command Line Tools package.

Yes, when I installed to Mavericks GM and put on the latest Xcode, a lot of my 
man pages for C APIs went away. There is a discussion on this about 2 weeks ago 
in the Xcode mailing list.

One person suggested the following command (probably the easiest way):

$ xcode-select --install

I pulled down the package from the Apple’s developer site.

https://developer.apple.com/downloads/index.action

In the search field on the left, enter

Command

and all the Command Line Tools packages for various OS X versions should show 
up.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: I can't use man command to find c api manuals in Mavericks GM

[Kyle Sluder]

Mavericks is still under NDA. Can’t you all wait (most likely) a few hours? ;-)

--Kyle Sluder

> On Oct 22, 2013, at 9:25 AM, Todd Heberlein  wrote:
> 
>> On Oct 22, 2013, at 2:19 AM, Maxthon Chan  wrote:
>> 
>> Well you need Xcode and maybe the Command Line Tools package.
> 
> Yes, when I installed to Mavericks GM and put on the latest Xcode, a lot of 
> my man pages for C APIs went away. There is a discussion on this about 2 
> weeks ago in the Xcode mailing list.
> 
> One person suggested the following command (probably the easiest way):
> 
>$ xcode-select --install
> 
> I pulled down the package from the Apple’s developer site.
> 
>https://developer.apple.com/downloads/index.action
> 
> In the search field on the left, enter
> 
>Command
> 
> and all the Command Line Tools packages for various OS X versions should show 
> up.
> 
> 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Clark S. Cox III]

On Oct 22, 2013, at 08:50, Sean McBride  wrote:

> On Tue, 22 Oct 2013 10:31:01 +0200, Daniel Höpfl said:
> 
>>> Was the old (non-arc) code faulty (but the compiler did not notice 
>>> this)?
>>> Why is the arc-version (with TRIGGER_ERROR defined) wrong?
>> 
>> It is wrong in the non-arc world, too. (ISO/IEC 9899:2011 AKA C11, 
>> 6.8.6.1: "A goto statement shall not jump from outside the scope of an 
>> identifier having a variably modified type to inside the scope of that 
>> identifier" - switch is a special case of goto.)
> 
> Daniel,
> 
> I don't think you can quote the Standard about 'goto' and just wave your 
> hands and say it applies to 'switch' also.  :)  The Standard's description of 
> 'switch' should contain the answer.

You are correct that that text doesn’t apply to switch statements. The closest 
is:

6.8.4.2 2:
“If a switch statement has an associated case or default label within the scope 
of an identifier with a variably modified type, the entire switch statement 
shall be within the scope of that identifier"

> However, it does seem to me there is a clang bug here somewhere.
> 
> I've made a shorter compilable example:
> 
> --
> #import 
> 
> int main (void)
> {
>   int x = 0;
>   switch(x)
>   {
>   case 1:
>   x++;
> #if 0 // toggle me
>   NSObject* foo = nil;
> #else
>   int* foo = 0;
> #endif
>   (void)foo;
>   break;
>   
>   default: 
>   x++;
>   };
> 
>   return 0;
> }
> --
> 
> Then build with both:
> $ xcrun clang -fsyntax-only -Weverything test.m
> $ xcrun clang -fsyntax-only -Weverything -fobjc-arc test.m
> 
> If 'foo' is int*, clang has no complaints in non-ARC and ARC.
> 
> If 'foo' is NSObject*, clang has no complaints in non-ARC, but errors in ARC.
> 
> IMHO, that's pretty weird!

The difference is that in non-ARC, both int* and NSObject* are allowed to be 
uninitialized, so jumping over the initialization of foo isn’t an issue. 
However, under ARC, object pointers must be initialized and cannot have an 
indeterminate value (even if you don’t provide an initial value at the 
definition, it is implicitly set to nil). It is not legal to jump over the 
initialization in that case (in much the same way as in C++ it is not legal to 
jump over the construction of a variable).

-- 
Clark Smith Cox III
clarkc...@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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Clark S. Cox III]

On Oct 22, 2013, at 09:16, Scott Ribe  wrote:

> On Oct 22, 2013, at 9:50 AM, Sean McBride  wrote:
> 
>> I don't think you can quote the Standard about 'goto' and just wave your 
>> hands and say it applies to 'switch' also.  :)  The Standard's description 
>> of 'switch' should contain the answer
> 
> Switch is just a pile of goto, and I'm pretty sure the standard says so 
> somewhere.

It does not. Switch is defined without referencing goto at all.

-- 
Clark Smith Cox III
clarkc...@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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Maxthon Chan]

As I said, either ARC or C++ objects with constructors and destructors requires 
compiler to insert code into the beginning and ending of the current scope (For 
C++, it is calls to constructors and destructors; for Objective-C ARC, it is 
ARC release/autorelease function calls.). As a rule of thumb, scope is defined 
by braces.

To explain this, here is an example:

- (void)method
{ // Begin of scope. Here I used a Objective-C method implementation, but 
anything that involves a set of braces count.
NSString *objcString = CFBridgingRelease(CFSTR(“string”)); // Guarantee a 
new object, ARC managed.
std::string cxxString = “string”;

// …

// At the end of scope, as like the end of this method, code like following 
will be inserted:
// cxxString.dtor(); // There is no formal way to call C++ destructor, but 
you get the idea.
// objc_release(objcString); // This is indeed what the compiler inserts. 
Just check the assembler from clang -S
} // End of scope.

But this gets confusing when switch statement is involved. The beginning of the 
braces certainly is not the start point of execution, the end of braces may not 
be the end of execution as well, and if you count the declare-before-use rule 
of C, the thing becomes extremely difficult to follow.

For Java, they require every case (or set of cases) in switch statement be 
terminated with a break statement, essentially implying a set of braces between 
case and break, the situation is better to understand. However with falling 
through of C, it is impossible to imply scope. Hence, C++ compiler emits a 
warning on that (they don’t leak objects, just at most some uninitialised 
objects, since all objects are stack-based) and Objective-C ARC just flat out 
rejecting this (since that leaks memory.)

By introducing a set of braces there, it makes another scope so that ARC (or 
C++) can insert the code appropriately. Also for some memory optimisations, 
this new scope can be a good place to introduce a new stack frame for locals.

On Oct 23, 2013, at 0:16, Scott Ribe  wrote:

> On Oct 22, 2013, at 9:50 AM, Sean McBride  wrote:
> 
>> I don't think you can quote the Standard about 'goto' and just wave your 
>> hands and say it applies to 'switch' also.  :)  The Standard's description 
>> of 'switch' should contain the answer
> 
> Switch is just a pile of goto, and I'm pretty sure the standard says so 
> somewhere.
> 
>> However, it does seem to me there is a clang bug here somewhere.
> 
> I don't think so. It's perhaps worth noting that in C++ or Objective-C++ you 
> get a similar warning when you do this with an instance that has a 
> constructor or destructor, and this goes back to versions of GCC from at 
> least several years ago--trust me, I know about 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:
> https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com
> 
> This email sent to xcvi...@me.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: I can't use man command to find c api manuals in Mavericks GM

[Maxthon Chan]

Mavericks deeds can be implied from iOS 7, I think. :-P

On Oct 23, 2013, at 0:31, Kyle Sluder  wrote:

> Mavericks is still under NDA. Can’t you all wait (most likely) a few hours? 
> ;-)
> 
> --Kyle Sluder
> 
>> On Oct 22, 2013, at 9:25 AM, Todd Heberlein  wrote:
>> 
>>> On Oct 22, 2013, at 2:19 AM, Maxthon Chan  wrote:
>>> 
>>> Well you need Xcode and maybe the Command Line Tools package.
>> 
>> Yes, when I installed to Mavericks GM and put on the latest Xcode, a lot of 
>> my man pages for C APIs went away. There is a discussion on this about 2 
>> weeks ago in the Xcode mailing list.
>> 
>> One person suggested the following command (probably the easiest way):
>> 
>>   $ xcode-select --install
>> 
>> I pulled down the package from the Apple’s developer site.
>> 
>>   https://developer.apple.com/downloads/index.action
>> 
>> In the search field on the left, enter
>> 
>>   Command
>> 
>> and all the Command Line Tools packages for various OS X versions should 
>> show up.
>> 
>> Todd



signature.asc
Description: Message signed with OpenPGP using GPGMail
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Scott Ribe]

On Oct 22, 2013, at 10:46 AM, Maxthon Chan  wrote:

> As I said, either ARC or C++ objects with constructors and destructors 
> requires compiler to insert code into the beginning and ending of the current 
> scope

For C++, the constructor is inserted at the call point, not at the beginning of 
the scope. Which actually makes it more clear what the problem with switch is. 
(If the constructor were inserted at the beginning of the scope, there would be 
no problem with potentially skipping over it.)

-- 
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[ChanMaxthon]

ARC have more insertion points - beginning of scope retaining all passed-in 
arguments or used objects, call point creating objects, and end of scope 
(auto)releasing objects. A missed retain causes race issues, a missed 
(auto)release leaks objects and an extra release makes dangling pointers, 
possibly busts a lot later making it almost impossible to trace and debug.

Sent from my iPhone

> On 2013年10月23日, at 0:57, Scott Ribe  wrote:
> 
>> On Oct 22, 2013, at 10:46 AM, Maxthon Chan  wrote:
>> 
>> As I said, either ARC or C++ objects with constructors and destructors 
>> requires compiler to insert code into the beginning and ending of the 
>> current scope
> 
> For C++, the constructor is inserted at the call point, not at the beginning 
> of the scope. Which actually makes it more clear what the problem with switch 
> is. (If the constructor were inserted at the beginning of the scope, there 
> would be no problem with potentially skipping over it.)
> 
> -- 
> 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Scott Ribe]

On Oct 22, 2013, at 11:08 AM, ChanMaxthon  wrote:

> ARC have more insertion points - beginning of scope retaining all passed-in 
> arguments or used objects, call point creating objects, and end of scope 
> (auto)releasing objects.

OK, and it's the ones at call points that cause problems in switch cases, 
correct?

-- 
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Daniel Höpfl]

Hi,

On 2013-10-22 17:50, Sean McBride wrote:

On Tue, 22 Oct 2013 10:31:01 +0200, Daniel Höpfl said:


Was the old (non-arc) code faulty (but the compiler did not notice
this)?
Why is the arc-version (with TRIGGER_ERROR defined) wrong?


It is wrong in the non-arc world, too. (ISO/IEC 9899:2011 AKA C11,
6.8.6.1: "A goto statement shall not jump from outside the scope of an
identifier having a variably modified type to inside the scope of that
identifier" - switch is a special case of goto.)


Daniel,

I don't think you can quote the Standard about 'goto' and just wave
your hands and say it applies to 'switch' also.  :)  The Standard's
description of 'switch' should contain the answer.


OK ... but as you say, the standard should contain the answer. Next try:


C11, 6.8.4.2, paragraph 7 (The example): "the object whose identifier is 
i exists with automatic storage duration (within the block) but is never 
initialized, and thus if the controlling expression has a nonzero value, 
the call to the printf function will access an indeterminate value."
(Using this paragraph because it compresses the scope/initializing topic 
into one sentence.)



In your shorter example, the compiler does not complain for int*, 
because it is okay for foo to be uninitialized.


If we use NSObject* as type of foo, this is okay for non-ARC, too.


With ARC, we have to include the ARC specification: "A retainable object 
pointer is either a null pointer or a pointer to a valid object." - 




Back to your example: foo is in scope but not initialized.
This is not acceptable for ARC (even if foo is not used in the scope).


So: clang is right. :-)

Maybe clang/ARC should simply init NSObject *foo with nil (even when the 
Cxx standard says it is uninitialized in this case).




IMHO, that's pretty weird!


It is ... if you move the "default:" label to the top, it works with 
ARC, too: C11, 6.8.4.2, p. 2 not met, foo's scope is now limited to 
"case 1:".



Bye,
   Daniel

___

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

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

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

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[ChanMaxthon]

Both call points and end of scope, not counting bigger troublemakers like 
fall-throughs and use of variables defined in a previous case, which is 
strangely valid in C.

Sent from my iPhone

> On 2013年10月23日, at 1:14, Scott Ribe  wrote:
> 
>> On Oct 22, 2013, at 11:08 AM, ChanMaxthon  wrote:
>> 
>> ARC have more insertion points - beginning of scope retaining all passed-in 
>> arguments or used objects, call point creating objects, and end of scope 
>> (auto)releasing objects.
> 
> OK, and it's the ones at call points that cause problems in switch cases, 
> correct?
> 
> -- 
> 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

MODERATOR: (Temporary) End of Thread (was Re: I can't use man command to find c api manuals in Mavericks GM)

[Chris Hanson]

Until OS X Mavericks becomes available to everyone via the App Store, it's 
still under NDA. Once it's available it can be discussed here, until then it 
can't.

  -- Chris, Cocoa-Dev co-mod


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: MODERATOR: (Temporary) End of Thread (was Re: I can't use man command to find c api manuals in Mavericks GM)

[Shazron]

If I do a search on the MAS, it lists it (I signed out first to verify):
https://itunes.apple.com/us/app/os-x-mavericks/id675248567?mt=12


On Tue, Oct 22, 2013 at 11:56 AM, Chris Hanson  wrote:

> Until OS X Mavericks becomes available to everyone via the App Store, it's
> still under NDA. Once it's available it can be discussed here, until then
> it can't.
>
>   -- Chris, Cocoa-Dev co-mod
>
>
> ___
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/shazron%40gmail.com
>
> This email sent to shaz...@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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: MODERATOR: (Temporary) End of Thread (was Re: I can't use man command to find c api manuals in Mavericks GM)

[Charles Srstka]

On Oct 22, 2013, at 1:56 PM, Chris Hanson  wrote:

> Until OS X Mavericks becomes available to everyone via the App Store, it's 
> still under NDA. Once it's available it can be discussed here, until then it 
> can't.

Isn't it available on the App Store now? It's showing up for me:

https://itunes.apple.com/us/app/os-x-mavericks/id675248567?mt=12

Charles


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: MODERATOR: (Temporary) End of Thread (was Re: I can't use man command to find c api manuals in Mavericks GM)

[Jean Suisse]

Actually, it sounds like it's available from the app store now.

Jean

On Oct 22, 2013, at 20:56 , Chris Hanson  wrote:

> Until OS X Mavericks becomes available to everyone via the App Store, it's 
> still under NDA. Once it's available it can be discussed here, until then it 
> can't.
> 
>  -- Chris, Cocoa-Dev co-mod
> 
> 
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/jean.lists%40gmail.com
> 
> This email sent to jean.li...@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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Confirm 10.9 GM build number?

[Jens Alfke]

Can someone who’s installed the public release of Mavericks reply with the 
build number (e.g. from the About This Mac panel)? I’m running the GM seed, 
13A598, and I’d like to make sure it’s the same as the actual release. Thanks.

—Jens
___

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

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

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

This email sent to arch...@mail-archive.com

Re: Confirm 10.9 GM build number?

[Robert Martin]

13A603 is the last GM seed I downloaded…


On Oct 22, 2013, at 3:21 PM, Jens Alfke  wrote:

> Can someone who’s installed the public release of Mavericks reply with the 
> build number (e.g. from the About This Mac panel)? I’m running the GM seed, 
> 13A598, and I’d like to make sure it’s the same as the actual release. Thanks.
> 
> —Jens
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/robmartin%40frontiernet.net
> 
> This email sent to robmar...@frontiernet.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to change highlight colour on NSTableView row

[Corbin Dunn]

On Oct 22, 2013, at 5:36 AM, Darren Wheatley  
wrote:

> Hi,
> 
> Thanks for the reply.
> 
> I tried the code sample you suggested but can't get it to work.
> 
> When running the default highlighting is being layered on top of this custom 
> highlighting (I can see part of the custom highlighting where the rects are 
> not quite overlapping). Do you know how I prevent the standard formatting 
> from being displayed?

Your cell is drawing that part; Override:

- (NSColor *)highlightColorWithFrame:(NSRect)cellFrame inView:(NSView 
*)controlView;

and return nil as an easy work around.

> 
> Also, (might be a symptom of the above) the custom highlighting is not always 
> removed when I click on a new row. If I scroll those rows off the screen and 
> back on the highlighting is fixed, so there is some sort of display refresh 
> problem.

If you are drawing outside of the “normal” highlight area, then you are 
responsible for invalidating it when selection changes.

corbin

> 
> I have tried standard and source list highlighting (set in the xib), and both 
> display the same behaviour.
> 
> Do you know what might be going on here, or anything I should check in my 
> code? Any suggestions you could make would be very much appreciated.
> 
> FYI, I am developing on 10.8.5 and targeting 10.7.
> 
> Regards
> 
> Darren.
> 
> 
> 
> On 21 Oct 2013, at 17:23,  wrote:
> 
>> On 21 Oct 2013, at 16:19, Darren Wheatley  
>> wrote:
>> 
>>> Hi,
>>> 
>>> I have a custom subclass of NSTableView in my app.
>>> 
>>> Can anyone suggest a method that will allow me to set a custom highlight 
>>> colour on on a row when the user clicks on it?
>>> 
>>> I've Googled for a solution, but haven't been able to find anything that 
>>> works.
>>> 
>>> 
>> For cell based tables try:
>> 
>> - (void)highlightSelectionInClipRect:(NSRect)clipRect
>> 
>> There is a sample implementation at 
>> http://stackoverflow.com/questions/7038709/change-highlighting-color-in-nstableview-in-cocoa.
>> You may need to set selectionHighlightStyle to 
>> NSTableViewSelectionHighlightStyleSourceList
>> 
>> Note: This method should not be subclassed or overridden for a view-base 
>> table view. Instead, row drawing customization should be done by subclassing 
>> NSTableRowView.
>> 
>> Jonathan
>> 
>> 
>> ___
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/darren%40tenjinconsulting.co.uk
>> 
>> This email sent to dar...@tenjinconsulting.co.uk
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com
> 
> This email sent to corb...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: MODERATOR: (Temporary) End of Thread (was Re: I can't use man command to find c api manuals in Mavericks GM)

[Chris Hanson]

OS X Mavericks is available on the App Store now.

  -- Chris, cocoa-dev co-mod
  -- who would like to point out the timestamp when he posted the original 
message


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: MODERATOR: (Temporary) End of Thread (was Re: I can't use man command to find c api manuals in Mavericks GM)

[Lee Ann Rucker]

Timestamp only shows delivery time, even in the extended headers - which is a 
general Apple mailing list complaint; sometimes it's seriously laggy.

On Oct 22, 2013, at 1:06 PM, Chris Hanson wrote:

> OS X Mavericks is available on the App Store now.
> 
>  -- Chris, cocoa-dev co-mod
>  -- who would like to point out the timestamp when he posted the original 
> message
> 
> 
> ___
> 
> 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:
> https://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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Confirm 10.9 GM build number?

[Bill Cheeseman]

I just finished installing it. It's 13A603, the same as the update to the GM 
release a couple of days ago.

On Oct 22, 2013, at 3:21 PM, Jens Alfke  wrote:

> Can someone who’s installed the public release of Mavericks reply with the 
> build number (e.g. from the About This Mac panel)? I’m running the GM seed, 
> 13A598, and I’d like to make sure it’s the same as the actual release. Thanks.

-- 

Bill Cheeseman - b...@cheeseman.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Deadlock during NSCache flush

[Greg Parker]

On Oct 21, 2013, at 10:14 PM, Jens Alfke  wrote:
> As for autorelease: "This has come up once before for me, and I was able to 
> work around it by making the cache-owner object call -autorelease instead of 
> -release on the NSCache, to defer the call to the cache’s dealloc. But I’m 
> now using ARC so that isn’t an option.”
> 
> Although there’s probably some hacky way to force an autorelease…

The supported way to force autorelease in ARC is to write a function in a 
non-ARC file that calls retain/autorelease.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arc: Switch case is in protected scope

[Scott Ribe]

On Oct 22, 2013, at 11:17 AM, Daniel Höpfl  wrote:

> OK ... but as you say, the standard should contain the answer. Next try:

Well, there's some evolution there, and this new Objective-C feature which kind 
of falls in between different versions of traditional C, ANSI C, C++.

-- 
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Deadlock during NSCache flush

[Maxthon Chan]

Despite ARC banned retain/release/autorelease functions, there are still 
alternatives there in the form of C functions:

From CoreFoundation :
CFRetain() = retain
CFRelease() = release
CGBridgingRelease() = autorelease

From LLVM’s requirements to runtime for ARC to work, as prototyped in GNUstep’s 
:
objc_retain() = retain
objc_release() = release
objc_autorelease() = autorelease

Prototypes:
id objc_retain(id);
void objc_release(id);
id objc_autorelease(id);

All six functions exist in Apple runtime, in CoreFoundation.framework and 
libobjc.dylib respectively. CoreFoundation ones call libobjc ones internally.

On Oct 23, 2013, at 5:10, Greg Parker  wrote:

> On Oct 21, 2013, at 10:14 PM, Jens Alfke  wrote:
>> As for autorelease: "This has come up once before for me, and I was able to 
>> work around it by making the cache-owner object call -autorelease instead of 
>> -release on the NSCache, to defer the call to the cache’s dealloc. But I’m 
>> now using ARC so that isn’t an option.”
>> 
>> Although there’s probably some hacky way to force an autorelease…
> 
> The supported way to force autorelease in ARC is to write a function in a 
> non-ARC file that calls retain/autorelease.
> 
> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com