Re: What's the best practice to write some common tasks?

[Jens Alfke]

On Nov 15, 2011, at 7:17 PM, ico wrote:

> So what is the best practice to place these function? Simply write them as
> a C function or implement them in a common class and make them static?

Either way is OK, and you can find several examples of either technique in 
Apple’s APIs — look at NSFileManager and at NSGraphics.h.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

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

What's the best practice to write some common tasks?

[ico]

Hi all,

Suppose I have some common tasks, such as get user preferences and return
some value, or do some calculation then return the result.
I want to implement a function that do these kind of tasks so that I don't
need to write those codes again and again. However, this function seems
that it should not belong to any class, it is just a common task that many
classes will use them.

So what is the best practice to place these function? Simply write them as
a C function or implement them in a common class and make them static?

Thanks.

-- 
==
Life isn't about finding yourself.
Life is about creating yourself.
___

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

Please do not post 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

Thread safety of NSTreeNode?

[Sean McBride]

Hi all,

Unless I've missed it, the docs say nothing about the thread safety of 
NSTreeNode.

I'm hoping to be able to do the following: create and mutate an NSTreeNode on a 
background thread, where only this thread knows about the instance, then pass 
the instance off to the main thread, where thereafter only the main thread will 
use the instance.

From my reading of the general 'Thread Safety Summary' wrt mutable objects, I 
think this should be safe... but I'd appreciate begin corrected...

Thanks,

--

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

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

Re: 2 itunesconnect questions

[April]

While on this subject I just got the dreaded: Your app will now spend the next 
6-12 months in review round file hell before being rejected without further 
review:

"We are currently reviewing an app that you submitted for inclusion on the App 
Store, and want to let you know that the review process will require additional 
time"

email. 


Being that there is an iPad specific version that is only being kept up for 
existing customers and now a universal, iPhone/iPad version which I'm directing 
new iPad users too, I'm going to end up with both apps getting shot down aren't 
I?

Would I be better to reject both versions, then resubmit the universal one by 
itself and later the iPad specific with a novel in the reviewer comments about 
why it's being submitted?___

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

Please do not post 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: 2 itunesconnect questions

[April]

On Nov 14, 2011, at 5:32 PM, Conrad Shultz wrote:

> On 11/11/11 9:50 PM, April wrote:
>> Actually I had a long existing project that I start working on in 4.1
>> before the release and then 4.2 when I started icloud support up
>> until now. I've hit multiple delays and setbacks due to adding
>> features out of fear of 1 star ratings due to "It's useless cause I
>> cant..." Even though many of the features are simply moronic on a
>> touch platform. For instance the ability to draw freehand on an
>> iphone in an app for serious use.
> 
> As a user, I hope that if a developer considers a feature "moronic" then
> they wouldn't include it.  You of course can never satisfy everyone, so,
> IMHO, best not clutter an application with ill-advised features.

I'm working from past experience. I once released an app on mac that 
had nothing what-so-ever to do with movie editing (mpg,avi,quicktime etc) and 
because people could not use the app to string bunches of clips together I got 
flamed. Tons of support email, bad reviews and more than a few I WANT MY MONEY! 
Never mind the fact that after the first complaint I changed all the listing 
information and my own site so the first line of the description specifically 
said it could not string movie clips together.
Thus within a few weeks, I released an update with the completely 
moronic feature (in this app) of being able to string clips together. 
Anyway people loved it. I have never used the feature for anything outside 
of testing.

I think moronic is too strong of a word perhaps. But this is a touch 
platform, and it really has significant limits to pixel perfect editing. There 
are things it does that, I personally find I dunno... too ambitious for a touch 
platform. At least, in the case of a girl with medium length fingernails(me). 
Not sure if guys, and gals that trim their nails, will find these things easier 
than I do. Those that use a stylus will probably really like all the features. 
I know my stylus changes the playing field significantly. Still the freehand... 
Honestly even with a stylus, it's only there because I just know if I pull it 
i'll get slammed with "It's useless because I can't draw!" And those are always 
the words "It's useless because..." I'd rather risk loosing a star on an 
otherwise good review for having the feature than only get 1 star for not 
having it. :\ I know... I'm weighing asterisks at this point...

All that said though. If you have twenty minutes - half an hour (maybe a little 
more on iphone), you can create some absolutely stunning documents with the 
tools provided. Seriously. I was shocked at the results I was getting because I 
have such poor graphic design skills.


> 
>> Anyway all I did when I started working in xcode 4.2 was set the
>> base sdk to 5.0. I never changed the deployment target away from
>> actually, 3.2. Later I implemented ARC but only changed the
>> deployment target to 4.2. And this project was originally poorly
>> implemented in that there were 2 separate projects, 1 for iPad, 1 for
>> iPhone/iPod. So I brought all of the code under one roof and used a
>> simple ISIPAD definition (a macro for the interfaceidiom check) to
>> figure out what should do what. not that that matters. Anyway. In
> 
> OK, this is what I was getting at in my previous message.
> 
> Let me make sure that I understand correctly.  You started out with a
> *single UI idiom* (i.e. iPad or iPhone, but not both) project, then
> manually created a *universal* app (i.e. one for both iPhone and iPad)
> by merging code together?  That is to say you NEITHER started a new
> Xcode project of the "universal" type NOR ran the "upgrade to iPad" tool
> in Xcode?
> 
> If this interpretation is correct, then my previous point remains: you
> may have skipped over some important project settings that the build
> system is expecting to be configured but aren't (or are configured
> improperly).


You have it right. And you were right I misconfigured the build settings when I 
moved to XCode 4.2. (More accurately, did not do anything to them at all.) 
I know... It would have been much better to convert, or make a new project. I 
didn't. fortunately the challenges did not effect the performance of the app 
only getting it to actually be an app. 

> 
>> xcode 4.1 the arch had been armv6/armv7 and I never really bothered
>> to look at it again after installing the final xcode 4.2. I built and
>> ran.. according to the bundle version script's last incrementation at
>> release 2673 times over a 5 month period. Installed at least a dozen
>> or more adhoc builds via itunes to check some built for release
>> things. never got an actual error... though I was ignoring warnings
>> in the build window. Won't do that again. so last night I was
>> surprised. Like I said stack overflow had an answer, but since
>> starting this thread I now understand the problem, thanks both to you
>> and others. Had I changed the build target to

Re: About iVars declaration and property

[Jens Alfke]

On Nov 15, 2011, at 10:54 AM, Torsten Curdt wrote:

> But then again the compiler would know about these implementations.

No, it wouldn’t. The compiler has no idea how NSDictionary or NSWindow are 
implemented. All it knows about them is what’s given in their header files. 
(Worse, even if it did grope into the framework’s binary code to decompile the 
implementation, that implementation is guaranteed to change in the next OS 
release, and that might include the size of the instance data.)

The fragile base class problem in a nutshell:

- I’m generating 32-bit Mac OS machine code to read instance variable 
“self->_foo” in a method of class Bar.
- I have an imaginary internal struct that defines the data layout of Bar. It 
looks like:
struct BarInstanceData {
Class isa;
BarParentInstanceData inheritedData;
int _foo;
};
- The compiler can now interpret “self->_foo” as a regular C struct access and 
emits an instruction that loads an int from a hardcoded offset from the 
register holding ‘self’. Let’s say the offset is 48.
- In the next release of the OS, one of the base classes of Bar has added some 
instance variables, adding 8 bytes to its instance size.
- This means that at runtime the true offset of self->_foo is now 48+8 = 56.
- Unfortunately the old offset 48 is baked into the machine code of the 
app/library containing class Bar.
- This means that the implementation of Bar will read and write the wrong 
locations. Kaboom.

Note that if the compiler can’t work out the instance size of all the base 
classes of Bar, it can’t work out the size of that BarParentInstanceData struct 
in step 2, meaning it can’t compile Bar.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

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

Re: About iVars declaration and property

[Kyle Sluder]

On Tue, Nov 15, 2011 at 10:54 AM, Torsten Curdt  wrote:
>> There’s no requirement that there be such an ivar, only a method named
>> -window that returns an NSWindow*. The implementation of that method is
>> arbitrary. For example it might just look like
>> - (NSWindow*) window { return [_parent window];}
>
> But then again the compiler would know about these implementations.

You have some magical compiler that can not only access superclasses'
method definitions when all it sees is a header file, but has also
solved the halting problem in a way that allows it to determine how
the method uses instance storage?

--Kyle Sluder
___

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

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

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

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

Re: About iVars declaration and property

[Torsten Curdt]

> There’s no requirement that there be such an ivar, only a method named
> -window that returns an NSWindow*. The implementation of that method is
> arbitrary. For example it might just look like
> - (NSWindow*) window { return [_parent window];}

But then again the compiler would know about these implementations.

> Separating interface from implementation is a good thing and a keystone of
> OOP.

No one is questioning that :)

Anyway, not sure this discussion is really useful for the list anymore.
Happy to discuss further off list if someone is interested.

cheers,
Torsten
___

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

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

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

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

Re: About iVars declaration and property

[Jens Alfke]

On Nov 15, 2011, at 10:34 AM, Torsten Curdt wrote:

> How does
> 
> @property (nonatomic, assign) IBOutlet NSWindow *window;
> 
> not have the information that there would need to be an ivar
> 
> NSWindow *window;
> 
> on 32-bit?

There’s no requirement that there be such an ivar, only a method named -window 
that returns an NSWindow*. The implementation of that method is arbitrary. For 
example it might just look like
- (NSWindow*) window { return [_parent window];}

Separating interface from implementation is a good thing and a keystone of OOP.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

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

Re: About iVars declaration and property

[David Duncan]

On Nov 15, 2011, at 10:34 AM, Torsten Curdt wrote:

>> No it can't. @property only says "I have methods named -foo and -setFoo:". 
>> It implies absolutely nothing about storage.
> 
> How does
> 
> @property (nonatomic, assign) IBOutlet NSWindow *window;
> 
> not have the information that there would need to be an ivar
> 
> NSWindow *window;
> 
> on 32-bit?


Because you could implement this property by doing something like this:

- (NSWindow *)window
{
return [_internalDictionary objectForKey:@"window"];
}

- (void)setWindow:(NSWindow *)window
{
[_internalDictionary setObject:window forKey:@"window"];
}

And thus not increase the size of the object at all (i.e. all properties could 
in theory be entries in a _internalDictionary if the class decided to).

Properties are only interfaces.
--
David Duncan

___

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

Please do not post 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: About iVars declaration and property

[Jens Alfke]

On Nov 15, 2011, at 9:55 AM, Kyle Sluder wrote:

>> FWIW I check on the llvm IRC channel and the response was "I wouldn't
>> be surprised if there are annoying edge cases, but offhand I don't see
>> any reason it couldn't be done."
> 
> If it could've been done, they would have done it. The fragile base class 
> problem is a well-understood aspect of language design, and the compiler team 
> is full of smart people.

Yup. Rather, to be pedantic, it can be done, and they did do it, but at the 
cost of changes to object layout and the ABI. So to avoid breaking binary 
compatibility with all existing apps, they didn’t make these changes in the 
32-bit x86 runtime, only newer runtimes like 64-bit and iOS.

(In a nutshell: if a class doesn’t know the size of its base class’s instance 
data at compile time, it can’t look up its own instance variables as constant 
offsets from ‘self’, so this changes the machine instructions for getting and 
setting instance variables.)

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

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

Re: About iVars declaration and property

[Torsten Curdt]

> No it can't. @property only says "I have methods named -foo and -setFoo:". It 
> implies absolutely nothing about storage.

How does

 @property (nonatomic, assign) IBOutlet NSWindow *window;

not have the information that there would need to be an ivar

 NSWindow *window;

on 32-bit?

>> FWIW I check on the llvm IRC channel and the response was "I wouldn't
>> be surprised if there are annoying edge cases, but offhand I don't see
>> any reason it couldn't be done."
>
> If it could've been done, they would have done it. The fragile base class 
> problem is a well-understood aspect of language design, and the compiler team 
> is full of smart people.

FWIW the guy was from Apple. Quoting more "as far as I know the
decision to tie omitted ivars to non-fragile ivars was more one of
available engineering time and source compatibility than one of
technical possibility"

cheers,
Torsten
___

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

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

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

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

Re: Saving doc loses NSTextView position/selection Re: Lion autosave...

[Fritz Anderson]

On 15 Nov 2011, at 11:02 AM, Kyle Sluder wrote:

> Don't do this. Bindings really don't understad mutable value types like 
> NSTextStorage. This is going to call -setFoo: on your managed object, which 
> will fire KVO, which will call -setString: on your NSTextView, which will 
> reset the cursor position.
> 
> Instead, treat the NSTextStorage as your in-memory model and only push to 
> HTML as late as possible (probably during save).

It's obvious when you say it. Thank you.

The object in question is controlled by an NSArrayController that permits 
multiple selections, so this is going to be painful.

— F

___

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

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

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

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

Re: About iVars declaration and property

[Kyle Sluder]

On Nov 15, 2011, at 9:52 AM, Torsten Curdt  wrote:

>>> Think of it like the compiler generates the ivars from the property
>>> definitions. So the ivar would be indeed explicit ivars - just not
>>> defined as such in the classic way.
>> 
>> Doesn't matter. The subclass still needs to know the size of its superclass 
>> so that it generate the proper ivar offsets. If the ivar declarations are 
>> not visible to the compiler, it cannot know this information.
> 
> But there is the property declaration where it can derive that information 
> from.

No it can't. @property only says "I have methods named -foo and -setFoo:". It 
implies absolutely nothing about storage.


> 
> FWIW I check on the llvm IRC channel and the response was "I wouldn't
> be surprised if there are annoying edge cases, but offhand I don't see
> any reason it couldn't be done."

If it could've been done, they would have done it. The fragile base class 
problem is a well-understood aspect of language design, and the compiler team 
is full of smart people.

--Kyle Sluder___

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

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

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

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

Re: About iVars declaration and property

[Torsten Curdt]

>> Think of it like the compiler generates the ivars from the property
>> definitions. So the ivar would be indeed explicit ivars - just not
>> defined as such in the classic way.
>
> Doesn't matter. The subclass still needs to know the size of its superclass 
> so that it generate the proper ivar offsets. If the ivar declarations are not 
> visible to the compiler, it cannot know this information.

But there is the property declaration where it can derive that information from.

FWIW I check on the llvm IRC channel and the response was "I wouldn't
be surprised if there are annoying edge cases, but offhand I don't see
any reason it couldn't be done."
___

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

Please do not post 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: Troubles with Bold and Italic fonts - Cocoa

[Jens Alfke]

On Nov 15, 2011, at 12:13 AM, Dany Golubitsky wrote:

> As for render - we have a part of code that generates bitmap from it and we 
> draw it using OpenGL. I am not really familiar with this part of code.
> I do not think it is related, since, as I said some fonts do work, so it is 
> not render problem.

I do think it’s related. It sounds like the render code is able to handle style 
variants in some fonts but not others (maybe it’s PostScript vs TrueType vs 
OpenType, or something like that.) That would explain why you’re seeing this 
problem with very ordinary NSFont* calls, but no one else is.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

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

Re: Saving doc loses NSTextView position/selection Re: Lion autosave...

[Kyle Sluder]

On Nov 15, 2011, at 8:46 AM, Fritz Anderson  wrote:

> On 11 Nov 2011, at 11:23 AM, Fritz Anderson wrote:
> 
>> On 11 Nov 2011, at 11:00 AM, Fritz Anderson wrote:
>> 
>>> My application writes an XML document that includes styled text in the form 
>>> of HTML. At the user end is an NSTextView; I use an in-memory Core Data 
>>> store for working storage. The text view is bound to the backing 
>>> NSManagedObject through an NSArrayController.

Don't do this. Bindings really don't understad mutable value types like 
NSTextStorage. This is going to call -setFoo: on your managed object, which 
will fire KVO, which will call -setString: on your NSTextView, which will reset 
the cursor position.

Instead, treat the NSTextStorage as your in-memory model and only push to HTML 
as late as possible (probably during save).

--Kyle Sluder___

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

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

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

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

Re: About iVars declaration and property

[Kyle Sluder]

On Nov 15, 2011, at 8:44 AM, Torsten Curdt  wrote:

>> In four words: Fragile Base Class Problem.
>> 
>> The problem is that a subclass (in 32 bit OS X) needs to know the size of 
>> the superclass so it know how to lay out its ivars.  If there is no explicit 
>> ivars, there is no way for the compiler to know the size (since when it is 
>> compiling the subclass it doesn't see all the files that may potentially 
>> contain the parent's ivars).
> 
> Think of it like the compiler generates the ivars from the property
> definitions. So the ivar would be indeed explicit ivars - just not
> defined as such in the classic way.

Doesn't matter. The subclass still needs to know the size of its superclass so 
that it generate the proper ivar offsets. If the ivar declarations are not 
visible to the compiler, it cannot know this information.

The modern runtime sidesteps this issue by storing the offset of each ivar in a 
global variable and indirecting all ivar access through that.

--Kyle Sluder___

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

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

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

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

Saving doc loses NSTextView position/selection Re: Lion autosave...

[Fritz Anderson]

On 11 Nov 2011, at 11:23 AM, Fritz Anderson wrote:

> On 11 Nov 2011, at 11:00 AM, Fritz Anderson wrote:
> 
>> My application writes an XML document that includes styled text in the form 
>> of HTML. At the user end is an NSTextView; I use an in-memory Core Data 
>> store for working storage. The text view is bound to the backing 
>> NSManagedObject through an NSArrayController. I have an NSValueTransformer 
>> subclass between the text view and the array controller to translate between 
>> the attributed string and NSData containing the HTML.
> ...
>> Snatching the user's work from under his hands is a horrible experience. How 
>> can I fix this?
> 
> I hate it when people rapid-fire updates to their questions, but…
> 
> Removing the value transformer from the NSArray controller process between 
> the text view and the model object doesn't help.
> 
> In my model object, I added an NSAttributedString-valued on-demand @property; 
> the getter and setter rely on the transformer to get and set the HTML 
> string** CD attribute. The value still transits through the transformer, but 
> I hoped that hiding it from the controller might help.
> 
> It didn't. I still have the bug.

A further update. I turned autosave off; the bug doesn't trigger in the middle 
of work, but it does trigger on File > Save. Without autosave, the selection, 
scroll, and first responder status are lost _before_ entry to dataOfType:error:.

Autosave and -commitEditing were red herrings.

I'd like to provide a better experience than this. Can somebody please suggest 
a lead?

— F

___

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

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

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

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

Re: About iVars declaration and property

[Torsten Curdt]

> In four words: Fragile Base Class Problem.
>
> The problem is that a subclass (in 32 bit OS X) needs to know the size of the 
> superclass so it know how to lay out its ivars.  If there is no explicit 
> ivars, there is no way for the compiler to know the size (since when it is 
> compiling the subclass it doesn't see all the files that may potentially 
> contain the parent's ivars).

Think of it like the compiler generates the ivars from the property
definitions. So the ivar would be indeed explicit ivars - just not
defined as such in the classic way.
___

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

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

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

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

Re: About iVars declaration and property

[glenn andreas]

On Nov 15, 2011, at 9:48 AM, Torsten Curdt wrote:

>>> If you’re 64-bit only (or if you require Lion or better), there’s no real 
>>> reason to explicitly declare the ivars these days.
>> 
>> As others have pointed out, this is not true. There are practical 
>> differences between declaring and not declaring the ivar explicitly. I 
>> almost never declare the ivar explicitly, but once in a while I need it to 
>> show up in the debugger or to be available in a subclass, and then I must 
>> declare it explicitly. m.
> 
> TBH what I don't get is why this cannot be changed in LLVM instead -
> then we would not have the 64-bit/10.7 restrictions.
> 
> Of course it would not change what's happening in the runtime but I
> guess most of people only care what they need to type anyway.


In four words: Fragile Base Class Problem.

The problem is that a subclass (in 32 bit OS X) needs to know the size of the 
superclass so it know how to lay out its ivars.  If there is no explicit ivars, 
there is no way for the compiler to know the size (since when it is compiling 
the subclass it doesn't see all the files that may potentially contain the 
parent's ivars).

Glenn Andreas  gandr...@gandreas.com 
The most merciful thing in the world ... is the inability of the human mind to 
correlate all its contents - HPL

___

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

Please do not post 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: About iVars declaration and property

[Torsten Curdt]

>>If you’re 64-bit only (or if you require Lion or better), there’s no real 
>>reason to explicitly declare the ivars these days.
>
> As others have pointed out, this is not true. There are practical differences 
> between declaring and not declaring the ivar explicitly. I almost never 
> declare the ivar explicitly, but once in a while I need it to show up in the 
> debugger or to be available in a subclass, and then I must declare it 
> explicitly. m.

TBH what I don't get is why this cannot be changed in LLVM instead -
then we would not have the 64-bit/10.7 restrictions.

Of course it would not change what's happening in the runtime but I
guess most of people only care what they need to type anyway.
___

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

Please do not post 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: About iVars declaration and property

[Matt Neuburg]

On Sun, 13 Nov 2011 01:42:07 -0600, Charles Srstka  
said:
>On Nov 13, 2011, at 1:16 AM, ico wrote:
>
>> 
>> However, I just wonder, is it really true that there is no ANY different
>> between explicitly declaring iVars and not delaring it?
>> 
>
>If you’re 64-bit only (or if you require Lion or better), there’s no real 
>reason to explicitly declare the ivars these days.

As others have pointed out, this is not true. There are practical differences 
between declaring and not declaring the ivar explicitly. I almost never declare 
the ivar explicitly, but once in a while I need it to show up in the debugger 
or to be available in a subclass, and then I must declare it explicitly. m.

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

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

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

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

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

Re: capturing self is likely to lead to a retain cycle ..

[Matt Neuburg]

This is *very* well explained in the WWDC 2011 video on Objective-C advances. m.

On Sat, 12 Nov 2011 16:14:31 +0800, Roland King  said:
>
>With the code below I'm getting a warning "Automatic Reference Counting Issue: 
>Capturing 'self' strongly in this block is likely to lead to a retain cycle"
>
>
>-(BOOL)textFieldShouldReturn:(UITextField*)textField
>{
>   [ foo setTopicName:[ textField text ] completionHandler:^(BOOL)success{
>
>   if( !success )
>   {
>   // present an alert sheet
>   }
>   else
>   {
>   // onCancel is also the callback from the 'cancel' 
> button and dismissed this modally presented viewcontroller
>   [ self onCancel:nil ];  // <-- ARC not too happy with 
> this
>   }   
>   } ];
>}
>
>

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

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

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

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

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

Re: NSDateFormatter not working on iOS 5.

[Matt Neuburg]

By the way, I can readily confirm that the results differ on the simulator for 
4.3 vs. 5.0. m.

>On Fri, 11 Nov 2011 16:13:49 +0800, Kin Mak  said:
>>The following code used to work fine prior to iOS 5. The dateFromString 
>>method seems to stop working on iOS 5 and always returns null. I suspect this 
>>is a bug introduced in iOS 5.0. Have  anyone encountered the same issue? Or 
>>do I miss something here?
>>
>>  NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
>>  [dateFormatter setDateFormat:@"-MM-dd HH:mm:ss.SSS zzz"];
>>  
>>  .
>>  //E.g currentString = @"2011-11-11 11:00:00.000 CET";   
>>  NSDate *date = [dateFormatter dateFromString:currentString];
>
>It works for me if I substitute "PST" for your "CET" - could the "CET" be the 
>problem?
>
>I guess what I would do is start by testing whether the date formatter can 
>round-trip its own output, like this:
>
>NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
>[dateFormatter setDateFormat:@"-MM-dd HH:mm:ss.SSS zzz"];
>NSString* output = [dateFormatter stringFromDate:[NSDate date]];
>NSLog(@"%@", output);
>
>NSDate* date = [dateFormatter dateFromString: output];
>NSLog(@"%@", date);
>
>It can on my machine (PST). If it can't on your machine, that sounds like a 
>bug.
>
>Also, do try -[dateFormatter getObjectValue:forString:errorDescription:]; It 
>is definitely throwing an error (not very helpful, "The operation couldn't be 
>completed") for your string on my machine.
>
>m.


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

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

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

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

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

Cocoaheads - Silicon Valley still needs speakers

[Tedd Fox]

 If you are interested in putting on a presentation/ master class / show and 
tell for Thursdays meeting, let me know :-)

#awesome
Tedd

Sent from my iPad
___

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

Please do not post 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: NSOutlineView doesn't call outlineView:shouldSelectItem: after selectRowIndexes:byExtendingSelection:

[Motti Shneor]

Thanks Kyle. For some reason I missed the superclass (NSTableView) docs when 
trying to solve my NSOutlineView selection issues.

However --- I remember (our previous implementation) that when you use an 
NSTreeController (Or NSArrayController in the case of NSTableView) to control 
the NSOutLineView --- than calling the array controller to select an object --- 
would definitely cause a "shouldSelect" call on the view delegate.

And there is still the weirdness of the empty userInfo on the Selection related 
notifications. 


On Nov 15, 2011, at 5:24 AM, Kyle Sluder wrote:

> On Mon, Nov 14, 2011 at 6:18 AM, Motti Shneor  wrote:
>> However, if we need to PROGRAMMATICALLY set the selection, using 
>> selectRowIndexes:byExtendingSelection: for example,  
>> outlineView:shouldSelectItem: is never called.
> 
> From "Selecting and Deselecting Rows Programmatically" in the Table
> View Programming Guide:
> 
>> Note: It is important to note that when the row is changed programmatically 
>> the selectionShouldChangeInTableView: message is not sent to the delegate. 
>> This means that the application is responsible for ensuring the validity of 
>> the contents of the currently selected row if it is being edited.
> 
> http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/TableView/RowSelection/RowSelection.html#//apple_ref/doc/uid/1026i-CH6-SW6
> 
> The point is that you can make programmatic changes that the user
> can't make with the mouse. The most common case is to disallow the
> user from making any selection changes at all; only the program can
> change the selection.
> 
> Just reuse whatever logic you've put into
> -outlineView:shouldSelectItem:. If you want, factor out the validation
> logic into its own method. If the conditions aren't met, either pass a
> different set of row indexes to
> -selectRowIndexes:byExtendingSelection: or just don't call that method
> at all.
> 
> --Kyle Sluder

___

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

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

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

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

A handy console output category .

[John C. Randolph]

Hi All,

Recently, I was writing a command-line tool and I didn't feel like dropping 
down to printf() for console output,  so I wrote this category.

Drop this in your project…

> @interface NSString (console)
> 
> - (void) writeToFileHandle:(NSFileHandle *) handle;
> - (void) writeToStdOut;
> - (void) writeToStdErr;
> 
> @end
> 
> @implementation NSString (console)
> 
> - (void) writeToFileHandle:(NSFileHandle *) handle { [handle writeData:[self 
> dataUsingEncoding:NSUTF8StringEncoding]]; }
> - (void) writeToStdOut { [self writeToFileHandle:[NSFileHandle 
> fileHandleWithStandardOutput]]; }
> - (void) writeToStdErr { [self writeToFileHandle:[NSFileHandle 
> fileHandleWithStandardError]]; }
> 
> @end

…and you'll be able to tell strings to output themselves like so:

[@"Hello, World!\n" writeToStdOut];

[@"Oh, no!  Something broke!\n" writeToStdErr];

[[self description] writeToStdOut];

-jcr___

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

Please do not post 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: Troubles with Bold and Italic fonts - Cocoa

[Dany Golubitsky]

Hello Jens.
The documentation says Weight parameter is ignored when I use NSBoldFontMask.
Changing the weight will not affect the result - I tried it.

As for render - we have a part of code that generates bitmap from it and we 
draw it using OpenGL. I am not really familiar with this part of code.
I do not think it is related, since, as I said some fonts do work, so it is not 
render problem.

Thanks, anyway.


-Original Message-
From: cocoa-dev-bounces+danyg=waves@lists.apple.com 
[mailto:cocoa-dev-bounces+danyg=waves@lists.apple.com] On Behalf Of Jens 
Alfke
Sent: Monday, November 14, 2011 20:30
To: Steve Steinitz
Cc: Cocoa Dev
Subject: Re: Troubles with Bold and Italic fonts - Cocoa


>>   NSFontManager* fontManager = [NSFontManager sharedFontManager];
>>   NSFont* font   = [fontManager fontWithFamily:@"Helvetica" traits:fontStyle 
>> weight:5 size:12];
>> However, the displayed font is not always what I asked. For example, It 
>> works with Verdana (I see it bold). But it does not works with Helvetica. 
>> Although the name is converted to Helvetica-Bold, the fonts are still 
>> regular.

I haven't used that NSFontManager method before. My guess is that by specifying 
an explicit weight you've overridden the bold mask (although that's not quite 
what the docs say.)

How are you rendering the text?

-Jens

___

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

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

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

This email sent to da...@waves.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