Re: [GREAT]NSScroller trackKnob

[koko]

Thanks to all, Graham too!
All aspects work just fine.

-koko

On Nov 18, 2010, at 9:24 PM, k...@highrolls.net wrote:


Yes, my action is being called.

So, I must find the part and if line or page figure my scroll amount  
and then set the knob.


Thx,

-koko


On Nov 18, 2010, at 9:09 PM, Graham Cox wrote:



On 19/11/2010, at 3:05 PM, Graham Cox wrote:

The usual MO is to set the range of the scroller to the total  
height of the view to be scrolled, less the height of the frame  
through which it is viewed. You change the value of the scroller  
to the amount you want to scroll, typically one line (however you  
define it) for the buttons and one page for the page regions. By  
using setKnobProportion: you can have a proportional knob as well.



Actually, that seems not to be true these days. NSScroller has a  
fixed range from 0..1, and your client is responsible for scaling  
the value to whatever the range needed to scroll the view. This is  
easier than what I described, which is how it was done in the old  
days (Mac OS 9 and earlier, which had integer based controls).


--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/koko%40highrolls.net

This email sent to k...@highrolls.net



___

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

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

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

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

Re: [GREAT]NSScroller trackKnob

[koko]

Yes, my action is being called.

So, I must find the part and if line or page figure my scroll amount  
and then set the knob.


Thx,

-koko


On Nov 18, 2010, at 9:09 PM, Graham Cox wrote:



On 19/11/2010, at 3:05 PM, Graham Cox wrote:

The usual MO is to set the range of the scroller to the total  
height of the view to be scrolled, less the height of the frame  
through which it is viewed. You change the value of the scroller to  
the amount you want to scroll, typically one line (however you  
define it) for the buttons and one page for the page regions. By  
using setKnobProportion: you can have a proportional knob as well.



Actually, that seems not to be true these days. NSScroller has a  
fixed range from 0..1, and your client is responsible for scaling  
the value to whatever the range needed to scroll the view. This is  
easier than what I described, which is how it was done in the old  
days (Mac OS 9 and earlier, which had integer based controls).


--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: [GREAT]NSScroller trackKnob

[Graham Cox]

On 19/11/2010, at 3:05 PM, Graham Cox wrote:

> The usual MO is to set the range of the scroller to the total height of the 
> view to be scrolled, less the height of the frame through which it is viewed. 
> You change the value of the scroller to the amount you want to scroll, 
> typically one line (however you define it) for the buttons and one page for 
> the page regions. By using setKnobProportion: you can have a proportional 
> knob as well.


Actually, that seems not to be true these days. NSScroller has a fixed range 
from 0..1, and your client is responsible for scaling the value to whatever the 
range needed to scroll the view. This is easier than what I described, which is 
how it was done in the old days (Mac OS 9 and earlier, which had integer based 
controls).

--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: [GREAT]NSScroller trackKnob

[Graham Cox]

On 19/11/2010, at 2:51 PM, k...@highrolls.net wrote:

> Next question ... how do I get called for the buttons (line up down) and the 
> page up down?


You should be called for all of the parts of the scroller. You can call 
-hitPart to find out which part of the control was hit. (I just found this out 
by reading the class documentation, why don't you try that?)

The usual MO is to set the range of the scroller to the total height of the 
view to be scrolled, less the height of the frame through which it is viewed. 
You change the value of the scroller to the amount you want to scroll, 
typically one line (however you define it) for the buttons and one page for the 
page regions. By using setKnobProportion: you can have a proportional knob as 
well.

--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: [GREAT]NSScroller trackKnob

[koko]

Works great ... thanks !

Next question ... how do I get called for the buttons (line up down)  
and the page up down?


-koko





On Nov 18, 2010, at 8:39 PM, Graham Cox wrote:



On 19/11/2010, at 2:30 PM, k...@highrolls.net wrote:


Should the action look like this:

- (void)action:(id)sender;

i.e will sender be the NSScroller?



Yes, though if you do this:

- (IBAction) action:(id) sender;

Then it will be visible to IB and you can connect it up there,  
instead of having to code it. Target/Action is a fundamental Cocoa  
technique - you really ought to read up on it and have it down pat,  
you won't get far without knowing it well.


--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: NSScroller trackKnob

[Conrad Shultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/18/10 7:30 PM, k...@highrolls.net wrote:
> Should the action look like this:
> 
> - (void)action:(id)sender;
> 
> i.e will sender be the NSScroller?

Please see the section titled "The Target-Action Mechanism" at
http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/CocoaFundamentals/CommunicatingWithObjects/CommunicateWithObjects.html

A little documentation goes a long way...

- -- 
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFM5fG1aOlrz5+0JdURAg/QAJ41EDwr/sCuT6d84VispIi2/5F2GgCbBFDO
CHHpa0PMfeoSqD9+VUJwtw4=
=nYS5
-END PGP 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: NSScroller trackKnob

[Graham Cox]

On 19/11/2010, at 2:30 PM, k...@highrolls.net wrote:

> Should the action look like this:
> 
> - (void)action:(id)sender;
> 
> i.e will sender be the NSScroller?


Yes, though if you do this:

- (IBAction) action:(id) sender;

Then it will be visible to IB and you can connect it up there, instead of 
having to code it. Target/Action is a fundamental Cocoa technique - you really 
ought to read up on it and have it down pat, you won't get far without knowing 
it well.

--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: NSScroller trackKnob

[koko]

Should the action look like this:

- (void)action:(id)sender;

i.e will sender be the NSScroller?

-koko


On Nov 18, 2010, at 8:14 PM, Graham Cox wrote:



On 19/11/2010, at 2:02 PM, k...@highrolls.net wrote:

I only get the log output when the mouse button is released ...  
this is not continuous to me.


Clearly I am missing something.




-trackKnob is an internal method that performs the tracking - it's  
not where you get the stream of value changes from the scroller.  
There is no reason to override it, and all you're doing is calling  
super, which keeps control until the mouse is released, when it  
returns, triggering your log. In other words, you're getting exactly  
what I'd expect to see.


If you set a target and action on the scroller, you should find that  
the target's action is called repeatedly while you drag the  
scroller. No subclassing of the control is required.


--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: NSScroller trackKnob

[Graham Cox]

On 19/11/2010, at 2:02 PM, k...@highrolls.net wrote:

> I only get the log output when the mouse button is released ... this is not 
> continuous to me.
> 
> Clearly I am missing something.
> 


-trackKnob is an internal method that performs the tracking - it's not where 
you get the stream of value changes from the scroller. There is no reason to 
override it, and all you're doing is calling super, which keeps control until 
the mouse is released, when it returns, triggering your log. In other words, 
you're getting exactly what I'd expect to see.

If you set a target and action on the scroller, you should find that the 
target's action is called repeatedly while you drag the scroller. No 
subclassing of the control is required.

--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

Why UIBarButtonItemStyleBordered?

[Laurent Daudelin]

Why this style if it doesn't make any difference with a bar button based on a 
custom view?

I want to put an activity indicator on a bar button but it seems I can't. Well, 
I can but when I switch the right bar button item to the bar button item with 
the activity indicator, no border is drawn. I don't like the button that seems 
to disappear and reappear. Any way to do that?

-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: NSScroller trackKnob

[koko]

Maybe I spoke too soon.

I have subclassed NSScroller and set my scroller to this class.

Then this code:

- (void)awakeFromNib {  [self setContinuous:YES]; }


- (void)trackKnob:(NSEvent *)theEvent {

[super trackKnob:theEvent]; 
NSLog(@"trackKnob");
}

I only get the log output when the mouse button is released ... this  
is not continuous to me.


Clearly I am missing something.

Any suggestions?

-koko

On Nov 18, 2010, at 7:45 PM, Graham Cox wrote:



On 19/11/2010, at 1:36 PM, k...@highrolls.net wrote:


How does one get continuous tracking from an NSScroller?

-trackKnob only gives control when the mouse button is released.

There  must be a method as normal scroll view behaviour is  
continuous scrolling.


So I want to have a scroller, not associated with a scroll view and  
get continuous call backs as the knob is moved.


Is there a way?



-setContinuous:YES


BUT, don't use a scrollbar when you really want a slider. Users hate  
that, and the HIG police will be after you as well.


--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: NSScroller trackKnob

[koko]

Thanks Graham !

NOTE:  This is a scroller for a view, not a slider requirement, no HIG  
police problems!


-koko

On Nov 18, 2010, at 7:45 PM, Graham Cox wrote:



On 19/11/2010, at 1:36 PM, k...@highrolls.net wrote:


How does one get continuous tracking from an NSScroller?

-trackKnob only gives control when the mouse button is released.

There  must be a method as normal scroll view behaviour is  
continuous scrolling.


So I want to have a scroller, not associated with a scroll view and  
get continuous call backs as the knob is moved.


Is there a way?



-setContinuous:YES


BUT, don't use a scrollbar when you really want a slider. Users hate  
that, and the HIG police will be after you as well.


--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: readonly property which is a mutable array

[Ken Thomases]

On Nov 18, 2010, at 9:33 AM, Keary Suska wrote:

> On Nov 18, 2010, at 5:35 AM, Remco Poelstra wrote:
> 
>> Hi,
>> 
>> I've a object like to following:
>> @interface  {
>>  NSMutableArray *items;
>> }
>> @property (nonatomic,readonly) NSMutableArray *items;
>> @end
>> 
>> I also have a protocol as follows:
>> @protocol Proto
>> @property (nonatomic,readonly) NSArray *items;
>> @end
>> 
>> I of course want the items to be read only for the outside world, but the 
>> object itself should be able to modify it. Now the compiler complains about 
>> the properties not matching. How should I solve this? Make a custom getter 
>> that returns an immutable array? Make the property refer to a mutable array? 
>> Make the property an immutable array and make copies of the array while 
>> modifying it?
> 
> The ivar type and the property type don't have to match. In fact, there does 
> not need to be any ivar backing whatsoever to properties.
> 
> Change your property declaration to NSArray *, and implement the getter with 
> [[array copy] autorelease] or similar.

You don't need to implement the getter.  The Cocoa docs are very clear that 
callers must respect the declared type of properties (i.e. return type of 
getters).  That is, if the getter is declared to return an immutable NSArray, 
then callers must not interrogate the returned object to determine if it's 
really mutable nor invoke mutation methods on it.  It may be, and often is 
(even in framework classes), that such a method returns an object that is, in 
fact, an NSMutableArray.  That's an irrelevant implementation detail.

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: unit test exit's abnormally with code 5

[Shane]

Shameless bump. Anyone have ideas on this thread?

On Sun, Nov 14, 2010 at 4:33 PM, Shane
 wrote:
> I'm trying to put a unit test together, so I've created a new target,
> added my files to compile and frameworks to link to, then commented
> out all of my code to where I have an empty setUp, tearDown, and
> testFunc, but still getting the following error.
>
> /Developer/Tools/RunPlatformUnitTests.include:419: note: Running tests
> for architecture 'x86_64' (GC OFF)
> objc[13117]: GC: forcing GC OFF because OBJC_DISABLE_GC is set
> 2010-11-14 16:22:29.300 otest-x86_64[13117:903] The test bundle at
> /Users/shane/Projects/HHI/hhi/build/Release/UnitTests.octest could not
> be loaded because its Objective-C runtime information does not match
> the runtime information required by the test rig.  This is likely
> because the test rig is being run with Objective-C garbage collection
> disabled, but the test bundle requires Objective-C garbage collection.
>  To enable Objective-C garbage collection for the test rig, run it in
> an environment without the OBJC_DISABLE_GC environment variable.
> 2010-11-14 16:22:29.307 otest-x86_64[13118:203] *** NSTask: Task
> create for path
> '/Users/shane/HHI/Projects/HHI/hhi/build/Release/UnitTests.octest/Contents/MacOS/UnitTests'
> failed: 22, "Invalid argument".  Terminating temporary process.
> /Developer/Tools/RunPlatformUnitTests.include:451: error: Test rig
> '/Developer/Tools/otest' exited abnormally with code 5 (it may have
> crashed).shane
>
> My unit test is an obj-c file with the *.mm extension because I'm
> testing obj-c as well as some c++ calls to a dyld file.
>
> Guess I'm having a hard time interpreting this error.
>
___

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: NSScroller trackKnob

[Graham Cox]

On 19/11/2010, at 1:36 PM, k...@highrolls.net wrote:

> How does one get continuous tracking from an NSScroller?
> 
> -trackKnob only gives control when the mouse button is released.
> 
> There  must be a method as normal scroll view behaviour is continuous 
> scrolling.
> 
> So I want to have a scroller, not associated with a scroll view and get 
> continuous call backs as the knob is moved.
> 
> Is there a way?


-setContinuous:YES


BUT, don't use a scrollbar when you really want a slider. Users hate that, and 
the HIG police will be after you as well.

--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: On self = [super init...] ...

[Bill Bumgarner]

On Nov 18, 2010, at 2:34 PM, John Engelhart wrote:

> method is just going to -dealloc my object and do something else (you know, 
> basically exactly what I'm trying to do with my own object substitution, hint 
> hint), then what's the point in even trying to do object substitution in the 
> first place?

The documentation says:

In general, if there is a problem during an initialization 
method, you should call [self release]and return nil.
Thus, no, there is no problem if multiple classes in the hierarchy participate. 
   The only stumbling point is that this:

self = [super init];

May cause 'self' to be released;   if you have code that is still referring to 
self via some other means, it better had darned well retained it before making 
that call.

b.bum

___

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

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

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

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

NSScroller trackKnob

[koko]

How does one get continuous tracking from an NSScroller?

-trackKnob only gives control when the mouse button is released.

There  must be a method as normal scroll view behaviour is continuous  
scrolling.


So I want to have a scroller, not associated with a scroll view and  
get continuous call backs as the knob is moved.


Is there a way?

-koko
___

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: App Store code signing

[James Walker]

On 11/18/2010 3:43 PM, Chris Idou wrote:


Is this the right forum to ask about the whole business of verifying signatures
etc for apps in the app store for Mac? I've been trying to get the code to work,
but I'm stumped.


If you log in at devforums.apple.com, you'll find a folder devoted to 
the Mac App Store.



--
  James W. Walker, Innoventive Software LLC
  
___

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: App Store code signing

[davelist]

On Nov 18, 2010, at 6:43 PM, Chris Idou wrote:

> 
> 
> Is this the right forum to ask about the whole business of verifying 
> signatures 
> etc for apps in the app store for Mac? I've been trying to get the code to 
> work, 
> but I'm stumped.
> 


You should probably use http://devforums.apple.com which requires a paid 
developer account. There's a section in it for the Mac App Store to discuss app 
submission, code signing, etc. Discussion of it on this list may even be 
disallowed, but I don't know that for certain.

Dave

___

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

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

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

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

Font panel accessory view problem

[Graham Cox]

I'm adding an accessory view to the font panel which includes some NSColorWells.

The problem I'm having is that if the standard 'text colour' button is clicked, 
it links the Color Panel to the Font Panel in a way that is not friendly to 
standard colour wells - once the connection is established, clicking a standard 
colour well doesn't disconnect it. I end up with the Color Panel driving two 
colour properties simultaneously - the standard text colour plus the extra one 
I'm setting from the accessory view.

Is there a supported way to disconnect the Color Panel from the Font Panel's 
text colour button? It's actually unclear how the font panel works with respect 
to the text colour, so I'm not even sure what to try. The standard colour 
button is weird in that just a button - it doesn't have a state indication to 
show that it's active or selected, like a color well. This sort of ad-hoc UI 
makes it hard to customise the Font Panel.

--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

App Store code signing

[Chris Idou]

Is this the right forum to ask about the whole business of verifying signatures 
etc for apps in the app store for Mac? I've been trying to get the code to 
work, 
but I'm stumped.



___

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: On self = [super init...] ...

[Charles Srstka]

On Nov 18, 2010, at 4:34 PM, John Engelhart wrote:

> But your objection is still from the perspective of the "tail end".  It still 
> doesn't address the case when I'm performing object substitution "above you" 
> and I really, really need you to honor my choice.  In this case, if you 
> decide to substitute a different object after I've already done so, and I 
> made my choice for reasons that are not available to you, we've got problems. 
>  Not only that, it is impossible for you to even tell that I'm in the middle 
> of performing object substitution "above you" and not just performing the 
> required self = [super init...].
> 
> At some point, someone is going to require either the choice be honored at 
> the "head" or at the "tail", and possibly both.

That just sounds like making bad assumptions to me. If you have special needs 
that subclasses have to be aware of beyond the usual things, then you should be 
documenting these requirements, just like Apple does with many classes which 
tell you the designated initializer that you should use, what primitives need 
to be overridden, or in some cases, that a class is not meant to be subclassed.

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

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

Re: On self = [super init...] ...

[John Engelhart]

On Thu, Nov 18, 2010 at 4:16 PM, Bill Bumgarner  wrote:

>
> On Nov 18, 2010, at 1:10 PM, John Engelhart wrote:
>
> The basic premise behind self = [super init...] is that the "lower levels
> of initialization are free to return a different object than the one passed
> in".
>
> However, there is an unstated assumption in this reasoning: whatever object
> is returned by [super init...] is the one that will be used.
>
>
> I don't understand the above claim; Why must the object returned by [super
> init*] be the one that is used?
>

That's a fair question.  I can see two general cases:

1) It doesn't matter at all if the object you return is used.
2) It really matters whether or not the object you return is used.

For the first case, it seems fair to ask the question "If you choose to
return a different object than the 'original' one, and it doesn't matter
that that choice be honored, then why are you returning a different object
in the first place?"

This leads directly to the second case: It really matters whether or not the
object you return is the one that is used.

Now, can both policies be supported using the same init... interface?
 Probably not.  In fact, just about anyone or anything that's going to do
object substitution is doing it for a reason, and that reason really
matters.  If it doesn't, then I should be able to take NSMangedObjects,
ignore and discard the returned object, instantiate another object (which
may not be of the NSMangedObject class), and just magically have everything
"work".

If it truly doesn't matter whether or not the choice of which object is
returned be honored, you're going to have an awful lot of people complaining
about why the object they substituted isn't the one that's being used.

Let's face it: From a pragmatic perspective, there's only one policy that
makes any sense: if a object substitution is permitted, then the substituted
object is the one that has to be used.

But your objection is still from the perspective of the "tail end".  It
still doesn't address the case when I'm performing object substitution
"above you" and I really, really need you to honor my choice.  In this case,
if you decide to substitute a different object after I've already done so,
and I made my choice for reasons that are not available to you, we've got
problems.  Not only that, it is impossible for you to even tell that I'm in
the middle of performing object substitution "above you" and not just
performing the required self = [super init...].

At some point, someone is going to require either the choice be honored at
the "head" or at the "tail", and possibly both.


> I'm certainly not aware of any limitation on an init method that would
> prevent it from… say… calling [super init], releasing whatever is returned
> if deemed unfit and then allocating an initializing some other instance.
>

I am.  Lets say I made an object substitution for "some reason", and I
really need my substituted object to be the one that's used because it has
red racing stripes or something. Then if your lower in the class hierarchy
init... method is just going to -dealloc my object and do something else
(you know, basically exactly what I'm trying to do with my own object
substitution, hint hint), then what's the point in even trying to do object
substitution in the first place?

Someones object substitution choice needs to "stick".  And I'm willing to
bet that anyone or anything that is doing any form of object substitution
does not correctly handle the case when their choice isn't the one that
"wins".


> The documentation (
> http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html)
> doesn't seem to make any such claim either.
>
> I haven't read beyond the above yet.  Maybe the unstated assumption is
> explained?
>

Ok, let's assume three uncoordinated (that is to say, nothing more that the
self = [super init...] requirement) classes within some class init...
hierarchy are all attempting to do object substitution, and each of the
classes is doing object substitution "for a reason" (i.e., the case where it
really matters).  Do you see a problem?

It works great if you're the only class in the init... hierarchy that's
doing it.  As soon as two or more classes within a init... hierarchy start
doing object substitution, there's a problem.
___

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

Accessing the NSImageNameRefreshTemplate image on iOS?

[Laurent Daudelin]

Is there an equivalent of this OS X default image on iOS? The refresh image? 
Like the one that appears on a UIBarButtonItem that you choose to be of style 
"UIBarButtonSystemItemRefresh"?

-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: Calling a class method with the runtime ObjC API

[Greg Parker]

On Nov 18, 2010, at 1:18 PM, vincent habchi wrote:
> I supposed I couldn't do such a simple thing as [MyClass perform:selector] 
> because the perform: method is an instance one. So I wrote this:

All class objects are also instances of NSObject. That means any instance 
method from NSObject is also available for class objects.

(More precisely, a class object is an instance of its root class, but root 
classes other than NSObject are uncommon.)

http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html


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

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

Re: On self = [super init...] ...

[Thomas Davie]

On 18 Nov 2010, at 21:16, Bill Bumgarner wrote:

> 
> On Nov 18, 2010, at 1:10 PM, John Engelhart wrote:
> 
>> The basic premise behind self = [super init...] is that the "lower levels of 
>> initialization are free to return a different object than the one passed in".
>> 
>> However, there is an unstated assumption in this reasoning: whatever object 
>> is returned by [super init...] is the one that will be used.
> 
> 
> I don't understand the above claim; Why must the object returned by [super 
> init*] be the one that is used?
> 
> I'm certainly not aware of any limitation on an init method that would 
> prevent it from… say… calling [super init], releasing whatever is returned if 
> deemed unfit and then allocating an initializing some other instance.
> 
> The documentation 
> (http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html)
>  doesn't seem to make any such claim either.
> 
> I haven't read beyond the above yet.  Maybe the unstated assumption is 
> explained?

Indeed, the behaviour of immutable strings and containers seem to back up this 
assertion

#import 

int main (int argc, char ** argv)
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

NSString *s1 = @"";
NSString *s2 = [NSString stringWithString:s1];
NSString *s3 = [NSString alloc];
NSString *s4 = [s3 initWithString:s2];

NSLog(@"%p, %p, %p, %p", s1, s2, s3, s4);

[pool drain];
}

prints 2010-11-18 21:39:35.767 Test[18767:a0f] 0x11050, 0x11050, 
0x10010d470, 0x11050

So our allocated string is certainly substituted during initialisation.

Bob___

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: Calling a class method with the runtime ObjC API

[vincent habchi]

Le 18 nov. 2010 à 22:31, Joar Wingfors a écrit :

>> I supposed I couldn't do such a simple thing as [MyClass perform:selector] 
>> because the perform: method is an instance one.
> 
>   [MyClass performSelector:theSelector];
> Works like a charm.

Thanks Joar, next time I shall be more adventurous. :)

Vincent___

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: Calling a class method with the runtime ObjC API

[Joar Wingfors]

On 18 nov 2010, at 13.18, vincent habchi wrote:

> I supposed I couldn't do such a simple thing as [MyClass perform:selector] 
> because the perform: method is an instance one.


Sure you can:

[MyClass performSelector:theSelector];

Works like a charm.

j o a r


___

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

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

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

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

Calling a class method with the runtime ObjC API

[vincent habchi]

Hi there,

this is more a style question than anything else, but I'm sometimes 
perfectionist. ;) I am also aware it is somewhat borderline with Cocoa (belongs 
more to ObjC in general); sorry for this.

I have designed a kind of a fake class which is, in reality, a simple 
collection of algorithms implemented as class methods. They all take the same 
three arguments, however. The user can pick up an algorithm by selecting a 
conventional name in a popup button. Then the code is supposed to call the 
selected class method, whose selector is known through a simple dictionary 
lookup.

I supposed I couldn't do such a simple thing as [MyClass perform:selector] 
because the perform: method is an instance one. So I wrote this:

Method  theAlgorithmMethod = class_getClassMethod ([MyClass class], 
theAlgorithm);
IMP itsImplementation = method_getImplementation (theAlgorithmMethod);
result = (* itsImplementation)(self, algorithm, …)

which works fine. But is there a clever way to achieve this?

Thanks a lot,
Vincent___

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: On self = [super init...] ...

[Bill Bumgarner]

On Nov 18, 2010, at 1:10 PM, John Engelhart wrote:

> The basic premise behind self = [super init...] is that the "lower levels of 
> initialization are free to return a different object than the one passed in".
> 
> However, there is an unstated assumption in this reasoning: whatever object 
> is returned by [super init...] is the one that will be used.


I don't understand the above claim; Why must the object returned by [super 
init*] be the one that is used?

I'm certainly not aware of any limitation on an init method that would prevent 
it from… say… calling [super init], releasing whatever is returned if deemed 
unfit and then allocating an initializing some other instance.

The documentation 
(http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html)
 doesn't seem to make any such claim either.

I haven't read beyond the above yet.  Maybe the unstated assumption is 
explained?

b.bum



___

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

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

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

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

Re: Core Data: During Migration, should use Primitive Accessors only?

[Quincey Morris]

On Nov 18, 2010, at 06:17, Jerry Krinock wrote:

> My claims are that such usage should not happen, and indeed you don't want it 
> to happen, but if you're not careful, it will happen…
> 
> 1.  If you invoke -(set)foo of -(setValue:)forKey: during a migration, and 
> you have overridden accessors with custom accessors, Core Data will find the 
> custom accessors and use them.
> 
> 2.  This will cause undesirable results.
> 
> 3.  To prevent Core Data from using the custom accessors during migration, 
> use the "…Primitive…" accessors instead.

Well, I apologize if I'm going round in a circle here, but if you have an 
object that executes the overrides instead of the Core-Data-provided accessors, 
you must have an object of the custom subclass of NSManagedObject.

How did such an object come to exist? Adam's point was that during migration 
the object is actually of class NSManagedObject, not the subclass. It shouldn't 
be possible to legally create an instance of the subclass.


___

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: Core Data: During Migration, should use Primitive Accessors only?

[Adam Swift]

On Nov 18, 2010, at 6:17 AM, Jerry Krinock wrote:

> 
> On 2010 Nov 16, at 16:51, Quincey Morris wrote:
> 
>> 2. If you have a *custom* NSManagedObject subclass (i.e. whose subclass name 
>> is known to the Core Data entity), you can of course override the 
>> Core-Data-supplied accessor methods by writing your own. Adam was saying 
>> that there isn't supposed to be any legal way to use such custom subclasses 
>> during migration.
> 
> Thanks, Quincey.  My claims are that such usage should not happen, and indeed 
> you don't want it to happen, but if you're not careful, it will happen…
> 
> 1.  If you invoke -(set)foo of -(setValue:)forKey: during a migration, and 
> you have overridden accessors with custom accessors, Core Data will find the 
> custom accessors and use them.
> 
This is absolutely untrue - CoreData is not going to use instances of your 
custom subclass during migration - your subclasses implementation of 
foo/setFoo: are not going to be wired up on NSManagedObject.  

> 2.  This will cause undesirable results.
> 
> 3.  To prevent Core Data from using the custom accessors during migration, 
> use the "…Primitive…" accessors instead.

This isn't necessary - but if you choose to call the primitives you need to 
first call willAccessValueForKey: and then after didAccessValueForKey:.  See 
the managed object accessor methods documentation I referred to: 

If you want to implement your own attribute or to-one relationship 
accessor methods, you use the primitive accessor methods to get and set values 
from and to the managed object's private internal store. You must invoke the 
relevant access and change notification methods


http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreData/Articles/cdAccessorMethods.html#//apple_ref/doc/uid/TP40002154-SW9

 
> 
> ___
> 
> 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/aswift%40apple.com
> 
> This email sent to asw...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSTimer firedate randomly changes

[jonat...@mugginsoft.com]

On 18 Nov 2010, at 15:10, lorenzo7...@gmail.com wrote:

> Thanks everyone for all the replies. I've read through the docs again (its 
> been years since I first set this up) and think I have a better understanding 
> of how timers should work. I see now that the timer will fire once the 
> computer is awakened from sleep, but it does take some time, maybe twenty 
> minutes or so from what I've seen so far. I've also noticed that the timer 
> does not fire during sleep though. Should it? From the replies and the docs, 
> it seems that it should, but I see no evidence of it either in the console or 
> the data.
> 

Check out Mr Noodle with regard to sleepy timers:

http://www.noodlesoft.com/blog/2010/07/01/playing-with-nstimer/

Regards

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

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

Re: NSBrowser

[Bruno Causse]

yes i found, thank a lot

Le 17 nov. 10 à 18:27, Dave DeLong a écrit :

NSBrowser is a subclass of NSControl, which happens to have a target  
and action mechanism.  Have you tried hooking up your browser's  
target and action?


Dave

On Nov 17, 2010, at 8:52 AM, Bruno Causse wrote:


i can navigate in a tree through the NSbrowser (mouse or keyboard),
I would like to view the properties of representedObject during my  
browsing.
but I don't find delegate's method (passif delegate).  ( kind:  
selectedDidChange:)

___

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/bcausse%40lepoint.fr

This email sent to bcau...@lepoint.fr




___

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: readonly property which is a mutable array

[Keary Suska]

On Nov 18, 2010, at 5:35 AM, Remco Poelstra wrote:

> Hi,
> 
> I've a object like to following:
> @interface  {
>   NSMutableArray *items;
> }
> @property (nonatomic,readonly) NSMutableArray *items;
> @end
> 
> I also have a protocol as follows:
> @protocol Proto
> @property (nonatomic,readonly) NSArray *items;
> @end
> 
> I of course want the items to be read only for the outside world, but the 
> object itself should be able to modify it. Now the compiler complains about 
> the properties not matching. How should I solve this? Make a custom getter 
> that returns an immutable array? Make the property refer to a mutable array? 
> Make the property an immutable array and make copies of the array while 
> modifying it?

The ivar type and the property type don't have to match. In fact, there does 
not need to be any ivar backing whatsoever to properties.

Change your property declaration to NSArray *, and implement the getter with 
[[array copy] autorelease] or similar.

You don't have much choice if you want a public immutable, but private mutable.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

___

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: Variable declaration in "for" loop initialization expression?

[Scott Ribe]

It's early in the morning for me and I mis-phrased it. I meant "pre-C99 
quirks", not "C99 quirks".

On Nov 18, 2010, at 8:21 AM, Oleg Krupnov wrote:

> Err... not sure I've understood... Is C99 very old and quirky? I
> thought it was a good idea to use it since it's set by default in
> XCode and therefore probably is the newest. What is the newest
> preferable dialect in this case?
> 
> Oleg.
> 
> On Thu, Nov 18, 2010 at 5:16 PM, Scott Ribe  
> wrote:
>> On Nov 18, 2010, at 4:57 AM, Oleg Krupnov wrote:
>> 
>>> What are the possible
>>> scenarios when I may need to use another dialect?
>> 
>> If you have a lot of very very old code that depends on C99 quirks and not 
>> enough time to fix 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Variable declaration in "for" loop initialization expression?

[Scott Ribe]

On Nov 18, 2010, at 4:57 AM, Oleg Krupnov wrote:

> What are the possible
> scenarios when I may need to use another dialect?

If you have a lot of very very old code that depends on C99 quirks and not 
enough time to fix 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Re: NSTimer firedate randomly changes

[lorenzo7620]

Thanks everyone for all the replies. I've read through the docs again (its  
been years since I first set this up) and think I have a better  
understanding of how timers should work. I see now that the timer will fire  
once the computer is awakened from sleep, but it does take some time, maybe  
twenty minutes or so from what I've seen so far. I've also noticed that the  
timer does not fire during sleep though. Should it? From the replies and  
the docs, it seems that it should, but I see no evidence of it either in  
the console or the data.




On Nov 17, 2010 4:17pm, Greg Parker  wrote:

On Nov 17, 2010, at 2:12 PM, Kyle Sluder wrote:
On Wed, Nov 17, 2010 at 2:07 PM, Dave DeLong davedel...@me.com> wrote:



Here's what I got from that documentation:





- An NSTimer is a run loop source.



Ah, I think this is where my brain went all funny, because the NSRunLoop  
documentation mentions multiple times that "A timer is not considered an  
input source."  
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSRunLoop_Class/Reference/Reference.html




I suspect what is meant is that it's not considered an input source for  
the purpose of deciding when to stop looping and return from the -run…  
methods.




A timer is a "source" but not an "input source". "The Run Loop Sequence  
of Events" says that both timers and port-based input sources are able to  
wake a sleeping run loop.






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

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

Re: Variable declaration in "for" loop initialization expression?

[Jerry Krinock]

On 2010 Nov 18, at 03:57, Oleg Krupnov wrote:

> It seems that C99 is set by default in XCode. What are the possible
> scenarios when I may need to use another dialect?

The only scenario I know of is: in case you want your code to be reuseable by 
other people/projects that are not using C99.

___

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: Core Data: During Migration, should use Primitive Accessors only?

[Jerry Krinock]

On 2010 Nov 16, at 16:51, Quincey Morris wrote:

> 2. If you have a *custom* NSManagedObject subclass (i.e. whose subclass name 
> is known to the Core Data entity), you can of course override the 
> Core-Data-supplied accessor methods by writing your own. Adam was saying that 
> there isn't supposed to be any legal way to use such custom subclasses during 
> migration.

Thanks, Quincey.  My claims are that such usage should not happen, and indeed 
you don't want it to happen, but if you're not careful, it will happen…

1.  If you invoke -(set)foo of -(setValue:)forKey: during a migration, and you 
have overridden accessors with custom accessors, Core Data will find the custom 
accessors and use them.

2.  This will cause undesirable results.

3.  To prevent Core Data from using the custom accessors during migration, use 
the "…Primitive…" accessors instead.

___

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: readonly property which is a mutable array

[jonat...@mugginsoft.com]

On 18 Nov 2010, at 13:01, jonat...@mugginsoft.com wrote:

> 
> On 18 Nov 2010, at 12:35, Remco Poelstra wrote:
> 
>> Hi,
>> 
>> I've a object like to following:
>> @interface  {
>>  NSMutableArray *items;
>> }
>> @property (nonatomic,readonly) NSMutableArray *items;
>> @end
>> 
>> I also have a protocol as follows:
>> @protocol Proto
>> @property (nonatomic,readonly) NSArray *items;
>> @end
>> 
>> I of course want the items to be read only for the outside world, but the 
>> object itself should be able to modify it. Now the compiler complains about 
>> the properties not matching. How should I solve this? Make a custom getter 
>> that returns an immutable array? Make the property refer to a mutable array? 
>> Make the property an immutable array and make copies of the array while 
>> modifying it?
>> Any insight would be appreciated.
>> 
> 
> Define a class extension (an unnamed category) within your implementation .m 
> file:
> 
> @interface  ()
> @property (nonatomic. readwrite) NSMutableArray *items;
> @end
> 
> Your object will have readwrite access.
> 
> See http://www.friday.com/bbum/2009/09/11/class-extensions-explained

Sorry. Wrong answer. Didn't read the question properly.

Don't make items a property if you don't want to advertise it to the outside 
world.

I would have a custom getter called items which returns [items copy].
When you modify items raise manual KVO notifications to inform observers of 
your changes.

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

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

Re: readonly property which is a mutable array

[jonat...@mugginsoft.com]

On 18 Nov 2010, at 12:35, Remco Poelstra wrote:

> Hi,
> 
> I've a object like to following:
> @interface  {
>   NSMutableArray *items;
> }
> @property (nonatomic,readonly) NSMutableArray *items;
> @end
> 
> I also have a protocol as follows:
> @protocol Proto
> @property (nonatomic,readonly) NSArray *items;
> @end
> 
> I of course want the items to be read only for the outside world, but the 
> object itself should be able to modify it. Now the compiler complains about 
> the properties not matching. How should I solve this? Make a custom getter 
> that returns an immutable array? Make the property refer to a mutable array? 
> Make the property an immutable array and make copies of the array while 
> modifying it?
> Any insight would be appreciated.
> 

Define a class extension (an unnamed category) within your implementation .m 
file:

@interface  ()
@property (nonatomic. readwrite) NSMutableArray *items;
@end

Your object will have readwrite access.

See http://www.friday.com/bbum/2009/09/11/class-extensions-explained/


Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.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

readonly property which is a mutable array

[Remco Poelstra]

Hi,

I've a object like to following:
@interface  {
NSMutableArray *items;
}
@property (nonatomic,readonly) NSMutableArray *items;
@end

I also have a protocol as follows:
@protocol Proto
@property (nonatomic,readonly) NSArray *items;
@end

I of course want the items to be read only for the outside world, but the 
object itself should be able to modify it. Now the compiler complains about the 
properties not matching. How should I solve this? Make a custom getter that 
returns an immutable array? Make the property refer to a mutable array? Make 
the property an immutable array and make copies of the array while modifying it?
Any insight would be appreciated.

Kind regards,

Remco Poelstra
___

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: Variable declaration in "for" loop initialization expression?

[Oleg Krupnov]

Thanks Graham!

I think I will stick to the more restricted version. It's more compact
and reliable indeed.

It seems that C99 is set by default in XCode. What are the possible
scenarios when I may need to use another dialect?

Oleg.

On Thu, Nov 18, 2010 at 1:52 PM, Graham Cox  wrote:
>
> On 18/11/2010, at 10:47 PM, Graham Cox wrote:
>
>> I don't think there is any significant advantage to either form, except the 
>> latter is perhaps a bit more compact in source code. It shouldn't make any 
>> difference to the object code.
>
>
> I should also point out that there is a scope difference - in the second form 
> the counter variable only has the scope of the for{...} statement whereas the 
> first form has the scope of the enclosing statement. Arguably the more 
> restricted scoping can help eliminate bugs.
>
> --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: Variable declaration in "for" loop initialization expression?

[Graham Cox]

On 18/11/2010, at 10:47 PM, Graham Cox wrote:

> I don't think there is any significant advantage to either form, except the 
> latter is perhaps a bit more compact in source code. It shouldn't make any 
> difference to the object code.


I should also point out that there is a scope difference - in the second form 
the counter variable only has the scope of the for{...} statement whereas the 
first form has the scope of the enclosing statement. Arguably the more 
restricted scoping can help eliminate bugs.

--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: Variable declaration in "for" loop initialization expression?

[Graham Cox]

On 18/11/2010, at 10:28 PM, Oleg Krupnov wrote:

> Hi,
> 
> I know, this is a very basic question, but after learning so many
> programming languages, my head seems like a mess.
> 
> In C that is in Objective-C, what is the correct/preferable way to
> declare the counter variable in a for loop?
> 
> Type i;
> for (i = 0; i < N; ++ i) { statements }
> 
> or
> 
> for (Type i = 0; i < N; ++i) { statements }


Both are correct, but the latter form is only legal in C99, so if you do not 
have C99 enabled, you'll get a syntax error. I don't think there is any 
significant advantage to either form, except the latter is perhaps a bit more 
compact in source code. It shouldn't make any difference to the object code.

> But what about for (;;) ? The compiler does not point to it as an
> error if I declare the counter inside the for () brackets, but I want
> to make sure!

Again, it's only legal in C99.

--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

Variable declaration in "for" loop initialization expression?

[Oleg Krupnov]

Hi,

I know, this is a very basic question, but after learning so many
programming languages, my head seems like a mess.

In C that is in Objective-C, what is the correct/preferable way to
declare the counter variable in a for loop?

Type i;
for (i = 0; i < N; ++ i) { statements }

or

for (Type i = 0; i < N; ++i) { statements }



Regarding for...in... loop, the docs are very clear that both the
following declarations are valid:

Type existingItem;
for ( existingItem in expression ) { statements }

and

for ( Type newVariable in expression ) { statements }

But what about for (;;) ? The compiler does not point to it as an
error if I declare the counter inside the for () brackets, but I want
to make sure!

Thanks

Oleg.
___

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: Detecting shared folders

[Leo]

Greg and Ken:

Thanks a lot for answering my question about shared folders, that's exactly
what I needed!

Best,
Leo


> From: Greg Nelson 
> Date: Wed, 17 Nov 2010 00:01:24 -0500
> To: Leo , 
> Subject: Re: Detecting shared folders

> From: Ken Thomases 
> Date: Wed, 17 Nov 2010 00:33:02 -0600
> To: Leo 
> Cc: 
> Subject: Re: Detecting shared folders

___

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: error: synthesized properties 'foo' and 'bar' both claim ivar 'myIvar'

[Quincey Morris]

On Nov 18, 2010, at 00:43, Andreas Grosam wrote:

> Found this bug report related to this issue and the following explanation:
> :
> 
>> --- Comment #1 from Fariborz Jahanian   2009-06-22 
>> 21:34:42 ---
>> This is part of the language spec. and cannot be changed. Two properties 
>> cannot use the same 'ivar'
>> for their setter/getter synthesis. This is deemed necessary because it will 
>> be extremely error prone to
>> allow the ivar changed via unrelated property operations.
> 
> 
> Error prone for whom? The compiler writer or the programmer?
> 
> IMHO, if this is error prone for the programmer, the rationale doesn't seem 
> to be reasonable enough to me, especially when the properties are readonly.

Really, there's no such thing as a readonly property, only a property that may 
or may not have a setter as well as a getter, and the compiler cannot determine 
absolutely whether or not there is a setter. (That's a consequence of the 
equivalence of @property-related and old-style property definition syntax, at 
least.) If setters are present at runtime, @synthesized ivar-sharing would 
certainly break KVO, and possibly would break @synthesized property atomicity.

If ivar sharing is not allowed for @synthesize, the penalty to the programmer 
is having to write one set of accessors manually -- a trivial task. If ivar 
sharing were allowed, the penalty would be to open up the code to a number of 
KVO notification and multi-threading issues, especially when more code was 
added later -- a distinctly non-trivial burden. 

Are you sure the rationale is so insufficient?


___

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