date:20081121



Le 21 nov. 08 à 10:42, spsaxena a écrit :


Hi all,
I am working on making my application carbon free. I could not find  
any
replacement for the API GetApplicationTextEncoding probably  
because this
API has not been marked as deprecated yet. Because of this API I  
need to
link with the carbon framework which I don't want. Can you please  
suggest

any non-carbon API as a replacement for this API.

Thanks,
S!


Is there any valid reason you do not want to link on Carbon at all ?
Some functionality are only available in Carbon.

I don't see what is bad in using a function that is not deprecated and  
marked as available on 64bits.


___

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 [EMAIL PROTECTED]

RE: Problem using GCC 4.2

2008-11-21 Thread Luca Ciciriello


I'd a similar problem. I've solved it removing all the pre-define preprocessor 
macro expecially __gnu_debug_def. Try this way.
 
Luca.
www.mitosrl.com Date: Fri, 21 Nov 2008 10:23:56 +0100 From: [EMAIL 
PROTECTED] To: cocoa-dev@lists.apple.com Subject: Problem using GCC 4.2  I 
tried to upgrade a small test project from gcc 4.0 to gcc 4.2 by changin the 
compiler version in the Project Info window but I get a strange compiler 
error:  error: current namespace 'std' does not enclose strongly used 
namespace '__gnu_debug_def'  ... in the file c++config.h which is included 
from string. If I change back to gcc 4.0 the build succeeds and if I try to 
get the error in a new project it works as well.  Any ideas?  / Påhl 
___  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/luca_ciciriello%40hotmail.com 
 This email sent to [EMAIL PROTECTED]
_
See the most popular videos on the web 
http://clk.atdmt.com/GBL/go/115454061/direct/01/___

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 [EMAIL PROTECTED]

Re: GetApplicationTextEncoding carbon free

2008-11-21 Thread spsaxena

As per my understanding Carbon framework will be deprecated or completely
removed in future versions of OSX. Well that's the only reason I wish to
remove the carbon framework from my application now.

On Fri, Nov 21, 2008 at 3:21 PM, Jean-Daniel Dupas
[EMAIL PROTECTED]wrote:


 Le 21 nov. 08 à 10:42, spsaxena a écrit :


  Hi all,
 I am working on making my application carbon free. I could not find any
 replacement for the API GetApplicationTextEncoding probably because this
 API has not been marked as deprecated yet. Because of this API I need to
 link with the carbon framework which I don't want. Can you please suggest
 any non-carbon API as a replacement for this API.

 Thanks,
 S!


 Is there any valid reason you do not want to link on Carbon at all ?
 Some functionality are only available in Carbon.

 I don't see what is bad in using a function that is not deprecated and
 marked as available on 64bits.


___

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 [EMAIL PROTECTED]

[Job] Cocoa developer at RealVNC

2008-11-21 Thread Mike Bellerby


Mac Software Engineer

RealVNC, the inventor of VNC, has an opening for a Cocoa developer  
based in Cambridge (UK) to work on VNC-based technology for the Mac  
and iPhone.


Skills Required

•A minimum of 2 years experience of software development for Mac  
OS X using Cocoa and Objective-C
•Understanding of network programming, protocol design, user- 
interface design, compression and security all in a multi-threaded  
programming


Experience

•Experience of product development and release to customers
•Exposure to other platforms, such as mobile devices, and other  
development languages, such as C++ and Java, is highly desirable
•A good computer science or similar relevant degree to at least  
2.1 level



Please visit our website for more information and to apply for this  
vacancy:


http://www.realvnc.com/company/vacancies/index.html

___

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 [EMAIL PROTECTED]

Re: NSURLConnection: Change HTTP Basic Auth Credentials

2008-11-21 Thread Johannes Fahrenkrug

Hi again,

after much wailing and gnashing of teeth, I think I've figured it out.
The solution is adding a # to the end of the URL:
http://blog.springenwerk.com/2008/11/i-am-currently-building-iphone.html

I'm pretty sure this is a bug, though.

- Johannes

On Thu, Nov 20, 2008 at 3:38 PM, Johannes Fahrenkrug
[EMAIL PROTECTED] wrote:
 Hi,

 I'm working on a piece of code that connects to a RESTful webservice
 and authenticates via HTTP basic. This works great, I get the
 - (void)connection:(NSURLConnection *)connection
 didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge
 *)challenge
 message, provide my credentials and get a successful response from the
 server. So far so good.

 BUT...
 I want to be able to change the credentials while the app is running.
 But when after the first successful didReceiveAuthenticationChallenge
 call, my delegate never receives that message again.
 This is my code:

 - (void)connection:(NSURLConnection *)connection
 didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge
 *)challenge {
 #ifdef DEBUG
NSLog(@got auth challange);
 #endif
if ([challenge previousFailureCount] == 0) {
[[challenge sender]  useCredential:[NSURLCredential
 credentialWithUser:[usernameTextField text]
 password:[passwordTextField text]
 persistence:NSURLCredentialPersistenceNone]
 forAuthenticationChallenge:challenge];
} else {
// this indicates that the connection failed because of bad 
 credentials
authFailed = YES;
[[challenge sender] cancelAuthenticationChallenge:challenge];
}
 }

 I've even tried setting persistence to
 NSURLCredentialPersistenceForSession and programmatically reset the
 stored NSURLCredentials before each request:

 // reset the credentials cache...
NSDictionary *credentialsDict = [[NSURLCredentialStorage
 sharedCredentialStorage] allCredentials];

if ([credentialsDict count]  0) {
// the credentialsDict has NSURLProtectionSpace objs 
 as keys and
 dicts of userName = NSURLCredential
NSEnumerator *protectionSpaceEnumerator = 
 [credentialsDict keyEnumerator];
id urlProtectionSpace;

// iterate over all NSURLProtectionSpaces
while (urlProtectionSpace = [protectionSpaceEnumerator 
 nextObject]) {
NSEnumerator *userNameEnumerator = 
 [[credentialsDict
 objectForKey:urlProtectionSpace] keyEnumerator];
id userName;

// iterate over all usernames for this 
 protectionspace, which are
 the keys for the actual NSURLCredentials
while (userName = [userNameEnumerator 
 nextObject]) {
NSURLCredential *cred = 
 [[credentialsDict
 objectForKey:urlProtectionSpace] objectForKey:userName];
NSLog(@cred to be removed: %@, cred);
[[NSURLCredentialStorage 
 sharedCredentialStorage]
 removeCredential:cred forProtectionSpace:urlProtectionSpace];
}
}
}


 But that didn't help either.

 SO: my question is: how do I force an NSURLConnection to send my
 delegate the didReceiveAuthenticationChallenge message so I can change
 my credentials?

 Thanks!

 - Johannes

 --
 http://blog.springenwerk.com




-- 
http://blog.springenwerk.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 [EMAIL PROTECTED]

Cocoa canvas view ?

2008-11-21 Thread Guillaume Laurent


Hi all,

I'm currently looking for a Cocoa NSView-like object which would  
manage several (read lots of) objects of various shape and kind  
(lines, polygons, ellipses, sprites, text...) placed on a large view,  
dealing with redisplay, collision detection (so it can tell me which  
object a user has clicked on for instance).


For those who know Qt (the cross-platform toolkit, not Quicktime), I'm  
looking for an equivalent of QGraphicsView (formerly known as QCanvas).


Any suggestions ?

Thanks,

--
Guillaume
http://telegraph-road.org





___

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 [EMAIL PROTECTED]

Problem archiving/unarchiving object graph containing NSMutableArray

2008-11-21 Thread Mikael Wämundson


Hi experienced developers!

I'm trying to archive/unarchive an object graph using  
archivedDataWithRootObject: aRootObject.
aRootObject has two instance variables of type NSMutableArray. Each  
mutable array contains customs objects of different types (subclasses  
of NSObject). For aRootObject and the custom objects in the mutable  
arrays I have implemeted encodeWithCoder and initWithCoder. When  
archiving encodeWithCoder gets called for the root object but not for  
the custom objects in the arrays. Same when unarchiving. Am I missing  
something?


/wamund
___

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 [EMAIL PROTECTED]

Re: Problem archiving/unarchiving object graph containing NSMutableArray

2008-11-21 Thread Mike Abdullah

You're almost certainly going to need to post some code for us to  
figure it out.


On 21 Nov 2008, at 13:12, Mikael Wämundson wrote:


Hi experienced developers!

I'm trying to archive/unarchive an object graph using  
archivedDataWithRootObject: aRootObject.
aRootObject has two instance variables of type NSMutableArray. Each  
mutable array contains customs objects of different types  
(subclasses of NSObject). For aRootObject and the custom objects in  
the mutable arrays I have implemeted encodeWithCoder and  
initWithCoder. When archiving encodeWithCoder gets called for the  
root object but not for the custom objects in the arrays. Same when  
unarchiving. Am I missing something?


/wamund
___

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/cocoadev%40mikeabdullah.net

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Jason Stephenson


Luke Hiesterman wrote:
So thinking gets in the way of understanding and not thinking is the 
path to enlightenment?


Yes, Grasshopper. You must stop thinking about the rules. You must stop 
thinking about the code. You must stop thinking about the computer. You 
must instead *become* the rules, become the code, become the computer. 
Only then is true enlightenment achieved.


Sorry, couldn't resist




Sent from my iPhone.


___

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 [EMAIL PROTECTED]

BOOL value in Dictionary

2008-11-21 Thread Richard S. French

How does one get a boolean value from a dictionary object?
My XML dictionary contains the value /true under the given key.
Should this be retrieved as NSNumber or some other object?

I am trying to set the state of a checkbox button based on the value as
below:

// return syntax coloring switch
BOOL *colorSwitch = NO;
colorSwitch = [NSNumber numberWithBOOL:[temp
objectForKey:@BBLMColorsSyntax]];
NSLog(@Color: %@, colorSwitch);
if ( colorSwitch == YES) {
[colorBox setState:NSOnState];
}
else {
[colorBox setState:NSOffState];
}


___

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 [EMAIL PROTECTED]

Re: BOOL value in Dictionary

2008-11-21 Thread Ken Thomases


On Nov 21, 2008, at 7:48 AM, Richard S. French wrote:


How does one get a boolean value from a dictionary object?
My XML dictionary contains the value /true under the given key.
Should this be retrieved as NSNumber or some other object?

I am trying to set the state of a checkbox button based on the value  
as

below:


Lots of confusion here.




   // return syntax coloring switch
   BOOL *colorSwitch = NO;


A BOOL is a scalar value.  It's not a class.  You don't typically  
declare a pointer to a BOOL for such simple purposes as you're using  
here.


Even if you do declare a pointer-to-BOOL, initializing it with NO  
isn't doing what you think it is.  You don't have a false boolean  
value, you have a null pointer.


   colorSwitch = [NSNumber numberWithBOOL:[temp  
objectForKey:@BBLMColorsSyntax]];


The subexpression [temp objectForKey:@BBLMColorsSyntax] already  
gives you an object.  If the object is what you think it is, then it's  
already an NSNumber, so there's no need to try to construct an  
NSNumber from it.


Next, even if you did want to construct an NSNumber from it, it's not  
a BOOL.  So +numberWithBOOL: wouldn't be appropriate.  Any non-nil  
object pointer would result in a true-valued NSNumber, even if [temp  
objectForKey:@BBLMColorsSyntax] had given you a false-valued NSNumber.


Third, you can't take the NSNumber which you're constructing (or  
retrieving with -objectForKey:) and assign it to colorSwitch, which is  
a pointer to BOOL, not a pointer to an object type.  Since colorSwitch  
ought not be a pointer, you definitely don't want to do that.



   NSLog(@Color: %@, colorSwitch);


Again, colorSwitch isn't an object pointer, so %@ isn't an appropriate  
format specifier for it.



   if ( colorSwitch == YES) {


As colorSwitch is a pointer-to-BOOL rather than a BOOL, testing it for  
equality to YES won't do what you want.


Even if colorSwitch were a BOOL rather than a pointer, your boolean  
test should probably not compare for equality to YES.  Just test the  
value of colorSwitch as the conditional (no comparison necessary).




   [colorBox setState:NSOnState];
   }
   else {
   [colorBox setState:NSOffState];
   }


You're looking for something like:

BOOL colorSwitch = [[temp objectForKey:@BBLMColorsSyntax] boolValue];
if (colorSwitch)
[colorBox setState:NSOnState];
else
[colorBox setState:NSOffState];

The above could be simplified by eliminating the colorSwitch variable  
entirely and just putting the expression directly into the 'if'.  You  
could also use the ternary conditional operator (?:) so there would be  
only one invocation of -setState:.


On the other hand, if you want to go belt-and-suspenders, you could  
test that the dictionary really contained the type of object you  
thought it should:


id colorState = [temp objectForKey:@BBLMColorsSyntax];
	if ([colorState isKindOfClass:[NSNumber class]]  [colorState  
boolValue])

[colorBox setState:NSOnState];
else
[colorBox setState:NSOffState];


Cheers,
Ken

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: BOOL value in Dictionary

2008-11-21 Thread Graham Cox



On 22 Nov 2008, at 12:48 am, Richard S. French wrote:


How does one get a boolean value from a dictionary object?
My XML dictionary contains the value /true under the given key.
Should this be retrieved as NSNumber or some other object?


Yes, that's right.


I am trying to set the state of a checkbox button based on the value  
as

below:

   // return syntax coloring switch
   BOOL *colorSwitch = NO;
   colorSwitch = [NSNumber numberWithBOOL:[temp
objectForKey:@BBLMColorsSyntax]];
   NSLog(@Color: %@, colorSwitch);
   if ( colorSwitch == YES) {
   [colorBox setState:NSOnState];
   }
   else {
   [colorBox setState:NSOffState];
   }



Unfortunately, this is just wrong.

BOOL is a scalar type, not an object. BOOL* is a pointer to a BOOL -  
such a thing is almost never used.


NSNumber is an object, so NSNumber* is your object reference.

So either you want:

BOOL colourSwitch = [[temp objectForKey:@blah] boolValue];

or

NSNumber* colourSwitch = [temp objectForKey:@blah];
BOOL csBool = [colourSwitch boolValue];

Tip:

option-double-click stuff to reveal it in the documentation, command- 
double-click to reveal it in the headers. That will save you a ton of  
grief.



hth,

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 [EMAIL PROTECTED]

Re: Cocoa canvas view ?

2008-11-21 Thread Graham Cox



On 21 Nov 2008, at 11:36 pm, Guillaume Laurent wrote:


Hi all,

I'm currently looking for a Cocoa NSView-like object which would  
manage several (read lots of) objects of various shape and kind  
(lines, polygons, ellipses, sprites, text...) placed on a large  
view, dealing with redisplay, collision detection (so it can tell me  
which object a user has clicked on for instance).


For those who know Qt (the cross-platform toolkit, not Quicktime),  
I'm looking for an equivalent of QGraphicsView (formerly known as  
QCanvas).


Any suggestions ?



There is nothing in Apple's frameworks, but you could look at my  
DrawKit project:


http://apptree.net/drawkitmain.htm


hth, 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 [EMAIL PROTECTED]

main thread communicating with background thread and vice-versa

2008-11-21 Thread John Love


From the main Thread, I call:



[NSThread detachNewThreadSelector:@selector(bgThread:) toTarget:self  
withObject:nil];




- (void) bgThread:(NSConnection*)connection {

NSAutoreleasePool *pool;

pool = [[NSAutoreleasePool alloc] init];



[self doCalculation];



[self performSelectorOnMainThread:@selector(endBgCalculation:)  
withObject:nil waitUntilDone:NO];




[pool release];

}



- (void) endBgCalculation:(id)obj {

// stuff

}



I believe this is fairly standard way to institute a background thread …



The problem centers on letting the background Thread look at a parm  
set in the main Thread and break out of the background Thread when the  
background Thread sees a certain value.




Specifically, my –doCalculation is just one great time-consuming for- 
loop that looks at mainThreadParm  and breaks depending on the value  
of mainThreadParm.




I change mainThreadParm in the main Thread and I expect the background  
Thread to break when the background Thread sees a certain value of  
mainThreadParm.




The background thread sees the initial value of mainThreadParm, but  
does not break when the main Thread changes it.




This sounds so basic and fundamental that I really feel lacking on  
this subject.




John Love

 ___

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 [EMAIL PROTECTED]

Re: Autorelease Question

On Thu, Nov 20, 2008 at 11:53 PM, Luke Hiesterman [EMAIL PROTECTED] wrote:
 So thinking gets in the way of understanding and not thinking is the path to
 enlightenment?

This is a bogus question.  You're thinking incorrectly.  There's a
reason the memory management rules don't explicitly call for things to
be autoreleased.  Following good OO principles, you shouldn't care how
things are memory managed within the framework; just make sure you're
doing the right thing and following the rules, and everyone's a
winner.

--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 [EMAIL PROTECTED]

Re: GetApplicationTextEncoding carbon free

On Fri, Nov 21, 2008 at 5:14 AM, spsaxena [EMAIL PROTECTED] wrote:
 As per my understanding Carbon framework will be deprecated or completely
 removed in future versions of OSX. Well that's the only reason I wish to
 remove the carbon framework from my application now.

Not all of Carbon is deprecated, just the UI bits.  The rest is
available in 64-bit as well as 32-bit.

--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 [EMAIL PROTECTED]

Tabbing to Placeholders

2008-11-21 Thread Greg Deward


Good morning!

This may be more of an XCode question, however the XCode list appears  
to be for people who are developing for or extending XCode.  Sorry if  
this isn't a good place to post this.


While going through Aaron's Cocoa book, I'm using the code assist  
feature of XCode a lot.  Is it possible to tab or jump to the next  
placeholder in the selector?  For example:


		[tableView editColumn:0 row:#(NSInteger)row# withEvent:#(NSEvent  
*)theEvent# select:#(BOOL)select#]


In the snippet above, I just finished typing 0 for editColumn.  I  
would love to be able to jump to the variable for row.   
Unfortunately, hitting tab just inserts an actual tab.


Thanks, in advance.

-- Greg
___

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 [EMAIL PROTECTED]

Re: Cocoa canvas view ?

2008-11-21 Thread Guillaume Laurent



On Nov 21, 2008, at 15:17 , Graham Cox wrote:

There is nothing in Apple's frameworks, but you could look at my  
DrawKit project:


http://apptree.net/drawkitmain.htm




Indeed I could :-). This is a very impressive work, thank you for it.  
Can you tell me more about its scalability ? What I'm planning to  
write is a music classical notation editor, so I'll typically need to  
handle a number of objects in the 10k order of magnitude, in a very  
large view.


--
Guillaume
http://telegraph-road.org





___

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 [EMAIL PROTECTED]

Re: main thread communicating with background thread and vice-versa

2008-11-21 Thread Joseph Kelly

How is your mainThreadParm declared? If it's a file global scope non- 
pointer value, it could be getting optimized away.


Try declaring it static or volatile.

Also, if threads are changing mainThreadParm independently in non- 
atomic ways, you will want to put locks around the critical sections.


Joe K.



On Nov 21, 2008, at 6:24, John Love [EMAIL PROTECTED] wrote:


From the main Thread, I call:



[NSThread detachNewThreadSelector:@selector(bgThread:) toTarget:self  
withObject:nil];




- (void) bgThread:(NSConnection*)connection {

   NSAutoreleasePool *pool;

   pool = [[NSAutoreleasePool alloc] init];



   [self doCalculation];



   [self performSelectorOnMainThread:@selector(endBgCalculation:)  
withObject:nil waitUntilDone:NO];




   [pool release];

}



- (void) endBgCalculation:(id)obj {

   // stuff

}



I believe this is fairly standard way to institute a background  
thread …




The problem centers on letting the background Thread look at a parm  
set in the main Thread and break out of the background Thread when  
the background Thread sees a certain value.




Specifically, my –doCalculation is just one great time-consuming for 
-loop that looks at mainThreadParm  and breaks depending on the valu 
e of mainThreadParm.




I change mainThreadParm in the main Thread and I expect the  
background Thread to break when the background Thread sees a certain  
value of mainThreadParm.




The background thread sees the initial value of mainThreadParm, but  
does not break when the main Thread changes it.




This sounds so basic and fundamental that I really feel lacking on  
this subject.




John Love

___

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

This email sent to [EMAIL PROTECTED]

___

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 [EMAIL PROTECTED]

Re: Tabbing to Placeholders



Le 21 nov. 08 à 15:50, Greg Deward a écrit :


Good morning!

This may be more of an XCode question, however the XCode list  
appears to be for people who are developing for or extending XCode.   
Sorry if this isn't a good place to post this.


isn't the list name xcode-users ? And extending Xcode is not really  
supported, the Xcode Users list would be empty if it was only for  
poeple trying to extending it ;-)





While going through Aaron's Cocoa book, I'm using the code assist  
feature of XCode a lot.  Is it possible to tab or jump to the next  
placeholder in the selector?  For example:


		[tableView editColumn:0 row:#(NSInteger)row#  
withEvent:#(NSEvent *)theEvent# select:#(BOOL)select#]


Yes, it corresponds to the Edit  Next Completion menu item, but I  
changed the default shortcut and don't remeber what it was (I just  
remember it was something not usable on azerty keyboard).



___

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 [EMAIL PROTECTED]

Re: Tabbing to Placeholders

2008-11-21 Thread Greg Deward



On Nov 21, 2008, at 10:00 AM, Jean-Daniel Dupas wrote:


isn't the list name xcode-users ?



You are absolutely correct.  When I read the description of the list,  
I saw components of the Xcode Tools development system and  
misinterpreted the rest.


Sorry to bother you.
___

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 [EMAIL PROTECTED]

Re: Tabbing to Placeholders

2008-11-21 Thread DKJ


On 21-Nov-08, at 6:50 , Greg Deward wrote:
 Is it possible to tab or jump to the next placeholder in the  
selector?



Control-/ does it on my keyboard.



___

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 [EMAIL PROTECTED]

Re: Tabbing to Placeholders

2008-11-21 Thread Joseph Crawford


Yes you would just have to change your keybindings in preferences

On Nov 21, 2008, at 10:12 AM, DKJ wrote:


On 21-Nov-08, at 6:50 , Greg Deward wrote:
Is it possible to tab or jump to the next placeholder in the  
selector?



Control-/ does it on my keyboard.



___

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/codebowl%40gmail.com

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]

Re: Cocoa canvas view ?

2008-11-21 Thread Graham Cox



On 22 Nov 2008, at 1:50 am, Guillaume Laurent wrote:



On Nov 21, 2008, at 15:17 , Graham Cox wrote:

There is nothing in Apple's frameworks, but you could look at my  
DrawKit project:


http://apptree.net/drawkitmain.htm




Indeed I could :-). This is a very impressive work, thank you for  
it. Can you tell me more about its scalability ? What I'm planning  
to write is a music classical notation editor, so I'll typically  
need to handle a number of objects in the 10k order of magnitude, in  
a very large view.



Well, I suspect you'd have to expect to work on some optimisations.  
While it only draws what it has to draw, 10K objects might start to  
get slow, possibly. That said there is plenty of scope for  
optimisations!


If you are interested in investigating further it might be best to  
take any discussion off-list. There is a developer mailing list for  
the framework also.


cheers, 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 [EMAIL PROTECTED]

Re: GetApplicationTextEncoding carbon free

On Fri, Nov 21, 2008 at 4:42 AM, spsaxena [EMAIL PROTECTED] wrote:
 Hi all,
 I am working on making my application carbon free. I could not find any
 replacement for the API GetApplicationTextEncoding probably because this
 API has not been marked as deprecated yet. Because of this API I need to
 link with the carbon framework which I don't want. Can you please suggest
 any non-carbon API as a replacement for this API.

May I suggest simply removing it and *not* replacing it?

Language-specific text encodings are evil. Sometimes you have to deal
with them, of course. But if you do, then you should already know what
encoding you're dealing with and shouldn't need an API to give you an
application encoding. For places where you are able to choose the
encoding, UTF-8 is the only reasonable ASCII-compatible encoding to
use.

Mike
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Adam Leonard

Ok, so my point with all this is that the documentation should not say  
that all class factory methods always return autoreleased objects  
because that is an implementation detail that (a) is not required by  
the memory management rules, (b) is something that the programmer  
should not care about, and (c) is not even true in the case of some  
methods, including [NSString string]


So I'll file a bug.

Adam Leonard

On Nov 21, 2008, at 9:43AM, Kyle Sluder wrote:

On Thu, Nov 20, 2008 at 11:53 PM, Luke Hiesterman  
[EMAIL PROTECTED] wrote:
So thinking gets in the way of understanding and not thinking is  
the path to

enlightenment?


This is a bogus question.  You're thinking incorrectly.  There's a
reason the memory management rules don't explicitly call for things to
be autoreleased.  Following good OO principles, you shouldn't care how
things are memory managed within the framework; just make sure you're
doing the right thing and following the rules, and everyone's a
winner.

--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/adam%40caffeinatedcocoa.com

This email sent to [EMAIL PROTECTED]



___

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 [EMAIL PROTECTED]

Re: Autorelease Question



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:21, Adam Leonard wrote:

Ok, so my point with all this is that the documentation should not  
say that all class factory methods always return autoreleased  
objects because that is an implementation detail that (a) is not  
required by the memory management rules, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]


So I'll file a bug.



You will file a bug ?
I really do not see the bug here...

And for the very last time in this discussion... Where do you people  
get the fact that [NSString string] doesn't call autorelease ?
It might call it, and just have its retaincount fixed to a certain  
number...



Adam Leonard

On Nov 21, 2008, at 9:43AM, Kyle Sluder wrote:

On Thu, Nov 20, 2008 at 11:53 PM, Luke Hiesterman  
[EMAIL PROTECTED] wrote:
So thinking gets in the way of understanding and not thinking is  
the path to

enlightenment?


This is a bogus question.  You're thinking incorrectly.  There's a
reason the memory management rules don't explicitly call for things  
to
be autoreleased.  Following good OO principles, you shouldn't care  
how

things are memory managed within the framework; just make sure you're
doing the right thing and following the rules, and everyone's a
winner.

--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/adam%40caffeinatedcocoa.com

This email sent to [EMAIL PROTECTED]



___

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/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]

WebServices / SOAP / REST

2008-11-21 Thread Greg Deward


Good morning!

Does anyone have any good tutorials on building nTier applicaitons  
using REST and Cocoa?  I'm coming from .NET/C# and Visual Studio takes  
care of all of the WebServices magic using SOAP.  Everything there is  
just a simple method call.  The book I am using now is teaching basic  
Cocoa and Objective-C, but I really need to satisfy my curiosity.


Thanks, in advance.

-- Greg
___

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 [EMAIL PROTECTED]

Re: BOOL value in Dictionary

2008-11-21 Thread Heinrich Giesen



Hi,
besides what Ken Thomases and Graham Cox already said, I have a  
remark concerning programming style:

if ( colorSwitch == YES) {
[colorBox setState:NSOnState];
}
else {
[colorBox setState:NSOffState];
}



It is bad to test a Boolean value with colorSwitch==NO and it is a  
very very bad habit to test
a Boolean value with == YES (there is a longer thread in this  
forum). It is not that difficult to
smoothly deal with Boolean expressions. It's not a question of  
efficiency but a question of style,

so the above snippet is equivalent (and more Boolean-like):


[colorBox setState: colorSwitch ? NSOnState : NSOffState];


Heinrich

--
Heinrich Giesen
[EMAIL PROTECTED]

___

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 [EMAIL PROTECTED]

NSIndexSet

2008-11-21 Thread David Blanton



How would one construct an NSIndexSet containing the indices 2,4,5 ?

I did:

NSRange two = NSMakeRange(2, 1);
NSRange four = NSMakeRange(4, 1);
NSRange five = NSMakeRange(5, 1);
NSRange u1 = NSUnionRange(two,four);
NSRange u2 = NSUnionRange(u1,five);
id indices = [NSIndexSet indexSetWithIndexesInRange:u2];
But, of course, NSUnionRange adds 3 so indices becomes 2,3,4,5.

Or, should one even use NSIndexSet?




___

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 [EMAIL PROTECTED]

Re: Autorelease Question



On Nov 21, 2008, at 7:33 AM, Filip van der Meeren wrote:

Ok, so my point with all this is that the documentation should not  
say that all class factory methods always return autoreleased  
objects because that is an implementation detail that (a) is not  
required by the memory management rules, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]

So I'll file a bug.

You will file a bug ?
I really do not see the bug here...


I do, and I already filed a bug.

Cocoa Fundamentals Guide states:

Class Factory Methods

Class factory methods are implemented by a class as a convenience for  
clients. They combine allocation and initialization in one step and  
return the created object autoreleased. These methods are of the form  
+ (type)className... (where className excludes any prefix).
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_6.html 



It should probably not explicitly state autoreleased — it should  
simply state that — in accordance with standard memory management  
rules, in a reference counted environment — the receiver does not own  
the returned object.



mmalc

___

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 [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Adam Leonard


Ok, yeah, it could call autorelease, but that would amount to a noop.
My problem with this documentation is that if I created a class that  
had a method just like the one you mentioned:


+ (Foo*)foo
{
static Foo *result = nil;
if(!result)
{
// Go freaky...

// Something like this
result = [[Foo alloc] initWithBytes:nil];
[result setThisRetainCountToMax];
}

return result;
}

This documentation would say this code is wrong for two reasons:
- It does not call autorelease
- Except for the first time it is called, it does not combine  
allocation and initialization (It just returns the singleton instance)


Now, I think this code is totally fine (though for an actual  
singleton, you would not set the retain count, but rather just  
override -retain, -release-, -autorelease, and -retainCount).


The rules of memory management suggest this code is fine too.

Therefore, I can only conclude that the generalization made by this  
page in the documentation (for beginners no less) is simply wrong.


Adam Leonard

On Nov 21, 2008, at 10:33AM, Filip van der Meeren wrote:



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:21, Adam Leonard wrote:

Ok, so my point with all this is that the documentation should not  
say that all class factory methods always return autoreleased  
objects because that is an implementation detail that (a) is not  
required by the memory management rules, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]


So I'll file a bug.



You will file a bug ?
I really do not see the bug here...

And for the very last time in this discussion... Where do you people  
get the fact that [NSString string] doesn't call autorelease ?
It might call it, and just have its retaincount fixed to a certain  
number...



Adam Leonard

On Nov 21, 2008, at 9:43AM, Kyle Sluder wrote:

On Thu, Nov 20, 2008 at 11:53 PM, Luke Hiesterman [EMAIL PROTECTED] 
 wrote:
So thinking gets in the way of understanding and not thinking is  
the path to

enlightenment?


This is a bogus question.  You're thinking incorrectly.  There's a
reason the memory management rules don't explicitly call for  
things to
be autoreleased.  Following good OO principles, you shouldn't care  
how
things are memory managed within the framework; just make sure  
you're

doing the right thing and following the rules, and everyone's a
winner.

--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/adam%40caffeinatedcocoa.com

This email sent to [EMAIL PROTECTED]



___

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/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]





___

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 [EMAIL PROTECTED]

Apple-like chat bubbles

2008-11-21 Thread bin chen

Hi all,
Recently I'm trying to make a apple-like chat bubble on Iphone.
After some search, I got some hints.
I displayed the message in a uitableviewcell and a background bubble image
using stretchableImageWithLeftCapWidth: leftCapWidth method. It works well
but i don't understand well the 2 parameters. Sometimes i changed them, and
the image didn't change much.
And another problem, i'd like to display some smilleys in these cells. I
don't think i can add a UIImageView of smilley and position it in the cells.
Some get some advices?

Any response will be appriciated.
--
Austin
___

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 [EMAIL PROTECTED]

MVC in Cocoa?

2008-11-21 Thread Michael Hines

Hey guys,

This is my first message to the mailing list, so please let me know if
I violate any form of etiquette. I apologize ahead of time.

This is also my first Obj-C and Cocoa application.

My application is basically a client for a text-protocol TCP server.
If you are familiar with freechess.org, this is what I'm consuming.

I want to have several views for the application. For example I want
to have a login view, console view, a game board view, a chat view,
etc.

I have experience in Ruby on Rails, so I have an intuition that
somehow I should implement models for Commands, Chats, Games, etc.,
but I'm having trouble imagining how exactly this should be done.

Specifically, who should own the connection?
How should it communicate with the models?
How will the controllers get the same instances of the models?
How can I have the views update dynamically when the models change?

Or maybe I'm wrong, and the connection should have nothing to do with
the models.

Even though this is my first Obj-C/Cocoa program, I don't want it to
be a hack. I want it to be a learning experience.

Any pointers anyone has, or if there are white-papers out there about
something like this would be fantastic.

By the way, currently I am trying to use the NSSocketPort with
NSFileHandle as demonstrated on this page:
http://etutorials.org/Programming/Cocoa/Part+I+Introducing+Cocoa/Chapter+6.+Networking/6.5+NSFileHandle/

Thanks,

Mike
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Cocoa canvas view ?

2008-11-21 Thread Paul Tomlin


On 21 Nov 2008, at 2:36 PM, Guillaume Laurent wrote:

I'm currently looking for a Cocoa NSView-like object which would  
manage several (read lots of) objects of various shape and kind  
(lines, polygons, ellipses, sprites, text...) placed on a large  
view, dealing with redisplay, collision detection (so it can tell me  
which object a user has clicked on for instance).


Core Animation?

http://www.apple.com/macosx/technology/coreanimation.html
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreAnimation_guide/Introduction/Introduction.html
http://theocacao.com/document.page/595
___

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 [EMAIL PROTECTED]

in NSTextView :Attributes of pasted Text different from original Text

2008-11-21 Thread rajesh


Hi,

I am working on parsing a piece of text, based on Attributes

, when I copy a piece of text and paste it , the pasted text seems to  
lose certain attributes , ( especially and only the Color attributes )

here is the piece of code and lines from log

[[[txtView attributedString] attributesAtIndex:selRange.location  
effectiveRange:rng] valueForKey:@NSColor];
[[[txtView attributedString] attributesAtIndex:selRange.location  
effectiveRange:rng] valueForKey:@NSFont];


2008-11-21 15:41:31.966  text Attribute (null)
2008-11-21 15:41:31.968  text Attribute Helvetica-BoldOblique 21.00  
pt. P [] (0x001aa6c0) fobj=0x0014f030, spc=5.83


2008-11-21 15:42:40.081  text Attribute NSCalibratedRGBColorSpace 0 0  
0 1
2008-11-21 15:42:40.082  text Attribute Helvetica-BoldOblique 21.00  
pt. P [] (0x001e6960) fobj=0x0014f030, spc=5.83



just implemented - (void)textDidChange:(NSNotification *)aNotification  
to see the attribute changes


any suggestion is appreciated

Thanks in advance
Devi
___

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 [EMAIL PROTECTED]

NSTextView :Attributes of pasted text different from original Text

2008-11-21 Thread rajesh


Hi,

I am working on parsing a piece of text, based on Attributes

, when I copy a piece of text and paste it , the pasted text seems to  
lose certain attributes , ( especially and only the Color attributes )

here is the piece of code and lines from log

[[[txtView attributedString] attributesAtIndex:selRange.location  
effectiveRange:rng] valueForKey:@NSColor];
[[[txtView attributedString] attributesAtIndex:selRange.location  
effectiveRange:rng] valueForKey:@NSFont];


2008-11-21 15:41:31.966  text Attribute (null)
2008-11-21 15:41:31.968  text Attribute Helvetica-BoldOblique 21.00  
pt. P [] (0x001aa6c0) fobj=0x0014f030, spc=5.83


2008-11-21 15:42:40.081  text Attribute NSCalibratedRGBColorSpace 0 0  
0 1
2008-11-21 15:42:40.082  text Attribute Helvetica-BoldOblique 21.00  
pt. P [] (0x001e6960) fobj=0x0014f030, spc=5.83



just implemented - (void)textDidChange:(NSNotification *)aNotification  
to see the attribute changes


any suggestion is appreciated

Thanks in advance
Devi
___

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 [EMAIL PROTECTED]

Re: BOOL value in Dictionary

On Fri, Nov 21, 2008 at 9:13 AM, Ken Thomases [EMAIL PROTECTED] wrote:
 Next, even if you did want to construct an NSNumber from it, it's not a
 BOOL.  So +numberWithBOOL: wouldn't be appropriate.  Any non-nil object
 pointer would result in a true-valued NSNumber, even if [temp
 objectForKey:@BBLMColorsSyntax] had given you a false-valued NSNumber.


Wandering off the track a bit, but I think this is interesting

It's actually not true that any non-nil object pointer will result in
a true-valued NSNumber. BOOL is not a true boolean yes/no type, but
rather it's just a signed char. This means that when you assign, pass,
or return a different numerical or pointer type in a place where BOOL
is expected the compiler will simply chop off the top bits to make it
fit. So if the last eight bits of your pointer all happen to be 0
(which is not that unlikely!) then your BOOL will be false instead of
true.

This can bite you if you try to take shortcuts with comparisons. For example:

- (BOOL)isNotNil:(id)obj {
return obj != nil;
}

Pretend for a moment that this method is not actually completely
pointless. So you say, but any non-nil value for 'obj' is always true,
so I can remove the comparison and just write this:

- (BOOL)isNotNil:(id)obj {
return obj;
}

Now you've set yourself up for a nasty intermittent failure. This will
work correctly, *most* of the time. But on a significant percentage of
non-nil 'obj' values, you'll get NO back.

Yeah, I did this once (with a less-pointless method, of course) and it
bit me. Fun times debugging that

Mike
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: NSIndexSet

2008-11-21 Thread Nick Zitzmann

First of all, when you want to create a new topic, please do not ever  
reply to an existing message. This breaks threading, since this thread  
now has two topics instead of one. Thanks.


On Nov 21, 2008, at 8:44 AM, David Blanton wrote:


How would one construct an NSIndexSet containing the indices 2,4,5 ?



There are several ways, like this:

NSMutableIndexSet *set = [NSMutableIndexSet  
indexSetWithIndexesInRange:NSMakeRange(2,5)];


[set removeIndex:3];

Or like this:

NSMutableIndexSet *set = [NSMutableIndexSet indexSet];

[set addIndex:2];
[set addIndex:4];
[set addIndex:5];

etc.

Nick Zitzmann
http://www.chronosnet.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 [EMAIL PROTECTED]

Re: NSIndexSet



Le 21 nov. 08 à 16:44, David Blanton a écrit :



How would one construct an NSIndexSet containing the indices 2,4,5 ?



I did:

NSRange two = NSMakeRange(2, 1);
NSRange four = NSMakeRange(4, 1);
NSRange five = NSMakeRange(5, 1);
NSRange u1 = NSUnionRange(two,four);
NSRange u2 = NSUnionRange(u1,five);
id indices = [NSIndexSet indexSetWithIndexesInRange:u2];
But, of course, NSUnionRange adds 3 so indices becomes 2,3,4,5.

Or, should one even use NSIndexSet?


Yes and no, It should use an NSMutableIndexSet.


___

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 [EMAIL PROTECTED]

Re: BOOL value in Dictionary

2008-11-21 Thread David Blanton


Why is :

if ( boolVar == YES) or if ( boolVar == NO)

bad form?

David Blanton

David Blanton




___

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 [EMAIL PROTECTED]

Re: NSIndexSet

On Fri, Nov 21, 2008 at 10:44 AM, David Blanton [EMAIL PROTECTED] wrote:

 How would one construct an NSIndexSet containing the indices 2,4,5 ?

 I did:

NSRange two = NSMakeRange(2, 1);
NSRange four = NSMakeRange(4, 1);
NSRange five = NSMakeRange(5, 1);
NSRange u1 = NSUnionRange(two,four);
NSRange u2 = NSUnionRange(u1,five);
id indices = [NSIndexSet indexSetWithIndexesInRange:u2];
 But, of course, NSUnionRange adds 3 so indices becomes 2,3,4,5.

 Or, should one even use NSIndexSet?

Use NSMutableIndexSet.

Mike
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

Sorry to be this crude, but the documentation isn't created for  
beginners.
If I would have documentation for beginners, then I would never take  
look at it!

There are excellent books for beginners from Wrox and O'reilly...

Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:45, Adam Leonard wrote:


Ok, yeah, it could call autorelease, but that would amount to a noop.
My problem with this documentation is that if I created a class that  
had a method just like the one you mentioned:


+ (Foo*)foo
{
static Foo *result = nil;
if(!result)
{
// Go freaky...

// Something like this
result = [[Foo alloc] initWithBytes:nil];
[result setThisRetainCountToMax];
}

return result;
}

This documentation would say this code is wrong for two reasons:
- It does not call autorelease
- Except for the first time it is called, it does not combine  
allocation and initialization (It just returns the singleton  
instance)


Now, I think this code is totally fine (though for an actual  
singleton, you would not set the retain count, but rather just  
override -retain, -release-, -autorelease, and -retainCount).


The rules of memory management suggest this code is fine too.

Therefore, I can only conclude that the generalization made by this  
page in the documentation (for beginners no less) is simply wrong.


Adam Leonard

On Nov 21, 2008, at 10:33AM, Filip van der Meeren wrote:



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:21, Adam Leonard wrote:

Ok, so my point with all this is that the documentation should not  
say that all class factory methods always return autoreleased  
objects because that is an implementation detail that (a) is not  
required by the memory management rules, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]


So I'll file a bug.



You will file a bug ?
I really do not see the bug here...

And for the very last time in this discussion... Where do you  
people get the fact that [NSString string] doesn't call autorelease ?
It might call it, and just have its retaincount fixed to a certain  
number...



Adam Leonard

On Nov 21, 2008, at 9:43AM, Kyle Sluder wrote:

On Thu, Nov 20, 2008 at 11:53 PM, Luke Hiesterman [EMAIL PROTECTED] 
 wrote:
So thinking gets in the way of understanding and not thinking is  
the path to

enlightenment?


This is a bogus question.  You're thinking incorrectly.  There's a
reason the memory management rules don't explicitly call for  
things to
be autoreleased.  Following good OO principles, you shouldn't  
care how
things are memory managed within the framework; just make sure  
you're

doing the right thing and following the rules, and everyone's a
winner.

--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/adam%40caffeinatedcocoa.com

This email sent to [EMAIL PROTECTED]



___

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/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]







___

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 [EMAIL PROTECTED]

Re: NSIndexSet

2008-11-21 Thread Greg Titus


On Nov 21, 2008, at 7:44 AM, David Blanton wrote:


How would one construct an NSIndexSet containing the indices 2,4,5 ?

I did:

NSRange two = NSMakeRange(2, 1);
NSRange four = NSMakeRange(4, 1);
NSRange five = NSMakeRange(5, 1);
NSRange u1 = NSUnionRange(two,four);
NSRange u2 = NSUnionRange(u1,five);
id indices = [NSIndexSet indexSetWithIndexesInRange:u2];
But, of course, NSUnionRange adds 3 so indices becomes 2,3,4,5.

Or, should one even use NSIndexSet?


The easiest way is to make a mutable index set:

NSMutableIndexSet *indices = [NSMutableIndexSet indexSet];
[indices addIndex:2];
[indices addIndex:4];
[indices addIndex:5];

Hope this helps,
- Greg
___

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 [EMAIL PROTECTED]

Re: NSIndexSet

2008-11-21 Thread Randall Meadows


On Nov 21, 2008, at 8:44 AM, David Blanton wrote:


How would one construct an NSIndexSet containing the indices 2,4,5 ?

I did:

NSRange two = NSMakeRange(2, 1);
NSRange four = NSMakeRange(4, 1);
NSRange five = NSMakeRange(5, 1);
NSRange u1 = NSUnionRange(two,four);
NSRange u2 = NSUnionRange(u1,five);
id indices = [NSIndexSet indexSetWithIndexesInRange:u2];
But, of course, NSUnionRange adds 3 so indices becomes 2,3,4,5.


Use an NSMutableIndexSet:

NSRange range = NSMakeRange(2, 4);
NSMutableIndexSet *mutSet = [[NSMutableIndexSet alloc]  
initWithIndexesInRange:range];

[mutSet removeIndex:3];

And if for some reason you really need it as a non-mutable version:

NSIndexSet *set = [[NSIndexSet alloc] initWithIndexSet:set];


Compiled in Mail.app; caveat emptor.
___

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 [EMAIL PROTECTED]

Re: WebServices / SOAP / REST

2008-11-21 Thread Nick Zitzmann



On Nov 21, 2008, at 8:34 AM, Greg Deward wrote:

Does anyone have any good tutorials on building nTier applicaitons  
using REST and Cocoa?  I'm coming from .NET/C# and Visual Studio  
takes care of all of the WebServices magic using SOAP.



This might be a good place to start: http://code.google.com/p/wsdl2objc/ 



Nick Zitzmann
http://www.chronosnet.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 [EMAIL PROTECTED]

Re: Cocoa canvas view ?

2008-11-21 Thread Guillaume Laurent



On Nov 21, 2008, at 14:15 , Paul Tomlin wrote:


On 21 Nov 2008, at 2:36 PM, Guillaume Laurent wrote:

I'm currently looking for a Cocoa NSView-like object which would  
manage several (read lots of) objects of various shape and kind  
(lines, polygons, ellipses, sprites, text...) placed on a large  
view, dealing with redisplay, collision detection (so it can tell  
me which object a user has clicked on for instance).


Core Animation?



Not really, no, but thanks anyway :-).

--
Guillaume
http://telegraph-road.org





___

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 [EMAIL PROTECTED]

Re: NSTextView :Attributes of pasted text different from original Text

2008-11-21 Thread rajesh


Sorry for spam,

I canceled the previous request but it appeared back in the list.

Though question is still open :)



On Nov 21, 2008, at 4:34 PM, rajesh wrote:


Hi,

I am working on parsing a piece of text, based on Attributes

, when I copy a piece of text and paste it , the pasted text seems  
to lose certain attributes , ( especially and only the Color  
attributes )

here is the piece of code and lines from log

[[[txtView attributedString] attributesAtIndex:selRange.location  
effectiveRange:rng] valueForKey:@NSColor];
[[[txtView attributedString] attributesAtIndex:selRange.location  
effectiveRange:rng] valueForKey:@NSFont];


2008-11-21 15:41:31.966  text Attribute (null)
2008-11-21 15:41:31.968  text Attribute Helvetica-BoldOblique 21.00  
pt. P [] (0x001aa6c0) fobj=0x0014f030, spc=5.83


2008-11-21 15:42:40.081  text Attribute NSCalibratedRGBColorSpace 0  
0 0 1
2008-11-21 15:42:40.082  text Attribute Helvetica-BoldOblique 21.00  
pt. P [] (0x001e6960) fobj=0x0014f030, spc=5.83



just implemented - (void)textDidChange:(NSNotification  
*)aNotification to see the attribute changes


any suggestion is appreciated

Thanks in advance
Devi
___

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/rajesh%40vangennep.nl

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]

Re: Autorelease Question



On Nov 21, 2008, at 7:56 AM, Filip van der Meeren wrote:

I quote: For objects that never get released, this method should  
return UINT_MAX. So where do you see your bug ?



The bug is in the description, and the expectations it gives rise to.

There should be no need for any of this discussion.  As others have  
also said, you should be thinking simply in terms of ownership, not in  
terms of whether or not something is autoreleased per se.  Changing  
the documentation will help prevent a counter-productive line of  
thinking.


mmalc

___

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 [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Devon Ferns


The docs say autoreleased as he already said which may not always be true.

Devon

Filip van der Meeren wrote:



I quote: For objects that never get released, this method should return 
UINT_MAX. So where do you see your bug ?



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:44, mmalcolm crawford wrote:





I do, and I already filed a bug.

Cocoa Fundamentals Guide states:

Class Factory Methods

Class factory methods are implemented by a class as a convenience for 
clients. They combine allocation and initialization in one step and 
return the created object autoreleased. These methods are of the form 
+ (type)className... (where className excludes any prefix).
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_6.html 



It should probably not explicitly state autoreleased — it should 
simply state that — in accordance with standard memory management 
rules, in a reference counted environment — the receiver does not own 
the returned object.



mmalc



___

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/dferns%40devonferns.com

This email sent to [EMAIL PROTECTED]

___

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 [EMAIL PROTECTED]

Re: Autorelease Question


I agree, but what would you have the documentation say ?

Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 17:08, mmalcolm crawford wrote:



On Nov 21, 2008, at 7:56 AM, Filip van der Meeren wrote:

I quote: For objects that never get released, this method should  
return UINT_MAX. So where do you see your bug ?



The bug is in the description, and the expectations it gives rise to.

There should be no need for any of this discussion.  As others have  
also said, you should be thinking simply in terms of ownership, not  
in terms of whether or not something is autoreleased per se.   
Changing the documentation will help prevent a counter-productive  
line of thinking.


mmalc



___

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 [EMAIL PROTECTED]

Re: Autorelease Question

Ok, lets say that [NSString string] creates a new object each and  
every time a framework/Application needs an empty string (like about a  
billion times). Then the RAM would be stuffed with empty string  
objects that are useless for everyone.
Now they have created a fix for this, one size fits all. They did this  
in a special way, by fixing there retainCount in a special subclass of  
NSString:


retainCount
Returns the receiver’s reference count.

- (NSUInteger)retainCount

Return Value
The receiver’s reference count.

Discussion
You rarely send a retainCount message; however, you might implement  
this method in a class to implement your own reference-counting  
scheme. For objects that never get released (that is, their release  
method does nothing), this method should returnUINT_MAX, as defined in  
limits.h.


The retainCount method does not account for any pending autorelease  
messages sent to the receiver.


This method is typically of limited value in debugging memory  
management issues.



I quote: For objects that never get released, this method should  
return UINT_MAX. So where do you see your bug ?



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:44, mmalcolm crawford wrote:



On Nov 21, 2008, at 7:33 AM, Filip van der Meeren wrote:

Ok, so my point with all this is that the documentation should not  
say that all class factory methods always return autoreleased  
objects because that is an implementation detail that (a) is not  
required by the memory management rules, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]

So I'll file a bug.

You will file a bug ?
I really do not see the bug here...


I do, and I already filed a bug.

Cocoa Fundamentals Guide states:

Class Factory Methods

Class factory methods are implemented by a class as a convenience  
for clients. They combine allocation and initialization in one step  
and return the created object autoreleased. These methods are of the  
form + (type)className... (where className excludes any prefix).
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_6.html 



It should probably not explicitly state autoreleased — it should  
simply state that — in accordance with standard memory management  
rules, in a reference counted environment — the receiver does not  
own the returned object.



mmalc



___

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 [EMAIL PROTECTED]

Re: Autorelease Question

But the docs also say Another purpose for a class factory method is  
to ensure that a certain class (NSWorkspace, for example) vends a  
singleton instance.


Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 17:12, Devon Ferns wrote:

The docs say autoreleased as he already said which may not always be  
true.


Devon

Filip van der Meeren wrote:

I quote: For objects that never get released, this method should  
return UINT_MAX. So where do you see your bug ?

Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter
On 21 Nov 2008, at 16:44, mmalcolm crawford wrote:





I do, and I already filed a bug.

Cocoa Fundamentals Guide states:

Class Factory Methods

Class factory methods are implemented by a class as a convenience  
for clients. They combine allocation and initialization in one  
step and return the created object autoreleased. These methods are  
of the form + (type)className... (where className excludes any  
prefix).
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_6.html 



It should probably not explicitly state autoreleased — it should  
simply state that — in accordance with standard memory management  
rules, in a reference counted environment — the receiver does not  
own the returned object.



mmalc


___
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/dferns%40devonferns.com
This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]

Re: BOOL value in Dictionary

2008-11-21 Thread Nick Zitzmann



On Nov 21, 2008, at 8:54 AM, David Blanton wrote:


Why is :

if ( boolVar == YES) or if ( boolVar == NO)

bad form?



It's not bad form per se, but the former is unnecessarily redundant   
the == YES can be eliminated, and the latter can be shortened using  
a !.


Nick Zitzmann
http://www.chronosnet.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 [EMAIL PROTECTED]

Re: Autorelease Question



Le 21 nov. 08 à 16:56, Filip van der Meeren a écrit :

Ok, lets say that [NSString string] creates a new object each and  
every time a framework/Application needs an empty string (like about  
a billion times). Then the RAM would be stuffed with empty string  
objects that are useless for everyone.
Now they have created a fix for this, one size fits all. They did  
this in a special way, by fixing there retainCount in a special  
subclass of NSString:


retainCount
Returns the receiver’s reference count.

- (NSUInteger)retainCount

Return Value
The receiver’s reference count.

Discussion
You rarely send a retainCount message; however, you might implement  
this method in a class to implement your own reference-counting  
scheme. For objects that never get released (that is, their release  
method does nothing), this method should returnUINT_MAX, as defined  
in limits.h.


The retainCount method does not account for any pending autorelease  
messages sent to the receiver.


This method is typically of limited value in debugging memory  
management issues.



I quote: For objects that never get released, this method should  
return UINT_MAX. So where do you see your bug ?





Just here in your quote. UINT_MAX is a bug IMHO. It should be  
NSUIntegerMax as defined in Foundation/NSObjCRuntime.h



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: BOOL value in Dictionary

2008-11-21 Thread Ed Wynne



On Nov 21, 2008, at 10:54 AM, David Blanton wrote:


Why is :

if ( boolVar == YES) or if ( boolVar == NO)

bad form?


if (boolVar == YES) is bad form, but if (boolVar == NO) and if  
(boolVar != NO) is not.


In C the concept of false has one and only one value, 0, which is  
#defined to be NO / false, etc. The concept of true, on the other  
hand, is defined as its complement. Any non-0 value. The YES check  
misses most of the not-false space.


A lot of people will argue about the relative merits of BOOL vs bool  
vs a true boolean type and how they can only have two possible  
meanings, but that is all superceded by the fact that we are  
discussing a C type language. You don't always know where your values  
are coming from, whether they respect the types you've somewhat  
arbitrarily chosen to label them, and as such, there are no guarantees  
as to their validity. You should check the C assumptions as to their  
truthiness, not arbitrary and unenforced type assumptions.


-Ed



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 [EMAIL PROTECTED]

Re: Cocoa canvas view ?

On Fri, Nov 21, 2008 at 9:50 AM, Guillaume Laurent
[EMAIL PROTECTED] wrote:
 Indeed I could :-). This is a very impressive work, thank you for it. Can
 you tell me more about its scalability ? What I'm planning to write is a
 music classical notation editor, so I'll typically need to handle a number
 of objects in the 10k order of magnitude, in a very large view.

In your position I would hesitate to actually model your graphical
elements as objects.  Rather, I would just have my view figure out
what portion of the score needs to be drawn, and then just draw to the
view.  Perhaps I would use a cell class like NoteCell to do the dirty
work.  My view would know how to convert bounds-oriented coordinates
into sections of staffs, and then would draw the staves, followed by
iterating through each note in each staff, calling -setObjectValue: on
the view's cell and then drawing the cell at the appropriate place.

This is conceptually similar to how NSTableView works.  It doesn't
really care about objects; the OO illusion is not necessary at the
level it's dealing with, and the complexity of dealing with it will
probably make your head spin, your app slow, or both.

--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 [EMAIL PROTECTED]

Re: Autorelease Question


Ok, you got me there...
But in my own defense it could still be to make sure that people are  
still able te retain the object without creating an overflow... ;-)


Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 17:19, Jean-Daniel Dupas wrote:



Le 21 nov. 08 à 16:56, Filip van der Meeren a écrit :

Ok, lets say that [NSString string] creates a new object each and  
every time a framework/Application needs an empty string (like  
about a billion times). Then the RAM would be stuffed with empty  
string objects that are useless for everyone.
Now they have created a fix for this, one size fits all. They did  
this in a special way, by fixing there retainCount in a special  
subclass of NSString:


retainCount
Returns the receiver’s reference count.

- (NSUInteger)retainCount

Return Value
The receiver’s reference count.

Discussion
You rarely send a retainCount message; however, you might implement  
this method in a class to implement your own reference-counting  
scheme. For objects that never get released (that is, their release  
method does nothing), this method should returnUINT_MAX, as defined  
in limits.h.


The retainCount method does not account for any pending autorelease  
messages sent to the receiver.


This method is typically of limited value in debugging memory  
management issues.



I quote: For objects that never get released, this method should  
return UINT_MAX. So where do you see your bug ?





Just here in your quote. UINT_MAX is a bug IMHO. It should be  
NSUIntegerMax as defined in Foundation/NSObjCRuntime.h





___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: BOOL value in Dictionary

2008-11-21 Thread Ken Thomases


On Nov 21, 2008, at 9:54 AM, David Blanton wrote:


Why is :

if ( boolVar == YES) or if ( boolVar == NO)

bad form?



Let me ask you this: why wouldn't you use:

if ( (boolVar == YES) == YES )

or

if ( ( (boolVar == YES) == YES ) == YES )

?


boolVar is already a boolean expression.  Comparing it to YES forms  
another boolean expression, but it's redundant and more complex than  
necessary.


In addition, although a BOOL variable arguably _should_ only contain  
YES or NO (or TRUE or FALSE), it might contain other values.  Any non- 
zero value should be interpreted as YES because that's the convention  
for booleans in C, but it may not necessarily equal YES.


Consider:

if ((boolVar == YES) || (boolVar == NO))
doSomething();
else
{
// We _should_ never get here, but we might!
breakHorribly();
}


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 [EMAIL PROTECTED]

Re: MVC in Cocoa?

2008-11-21 Thread Sherm Pendley


On Nov 20, 2008, at 7:13 PM, Michael Hines wrote:


Any pointers anyone has, or if there are white-papers out there about
something like this would be fantastic.


Have you read the MVC introduction from Apple?

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/chapter_5_section_4.html 



sherm--

___

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 [EMAIL PROTECTED]

Re: WebServices / SOAP / REST

On Fri, Nov 21, 2008 at 10:34 AM, Greg Deward [EMAIL PROTECTED] wrote:
 Does anyone have any good tutorials on building nTier applicaitons using
 REST and Cocoa?  I'm coming from .NET/C# and Visual Studio takes care of all
 of the WebServices magic using SOAP.  Everything there is just a simple
 method call.  The book I am using now is teaching basic Cocoa and
 Objective-C, but I really need to satisfy my curiosity.

So do you want SOAP or REST?  Cocoa's native RPC mechanism is known as
Distributed Objects (DO), but it's not nearly as Internet-friendly as
SOAP and REST.  Cocoa does do WSDL, supported by the Web Services
Core, though the documentation is a bit out of date:
http://developer.apple.com/documentation/Networking/Conceptual/UsingWebservices/1_intro_folder/chapter_1_section_1.html

--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 [EMAIL PROTECTED]

Re: BOOL value in Dictionary

2008-11-21 Thread Gary L. Wade

Another interesting thing I've seen with some compilers is when a bit flag
is defined with a signed type:

short someflag : 1;

a value of it being set may be -1 rather than 1, so the only way to compare
it according to how you want it to work is by comparing it against 0 in some
way:

if (!someflag) ...
if (0 == someflag) ...
if (false == someflag) ...
if (0 != someflag) ...
if (false != someflag) ...

After all, zero is always zero, but true-ness can be anything else, unless
you're talking probability.

On 11/21/2008 8:51 AM, Michael Ash [EMAIL PROTECTED] wrote:

 On Fri, Nov 21, 2008 at 9:13 AM, Ken Thomases [EMAIL PROTECTED] wrote:
 Next, even if you did want to construct an NSNumber from it, it's not a
 BOOL.  So +numberWithBOOL: wouldn't be appropriate.  Any non-nil object
 pointer would result in a true-valued NSNumber, even if [temp
 objectForKey:@BBLMColorsSyntax] had given you a false-valued NSNumber.
 
 
 Wandering off the track a bit, but I think this is interesting
 
 It's actually not true that any non-nil object pointer will result in
 a true-valued NSNumber. BOOL is not a true boolean yes/no type, but
 rather it's just a signed char. This means that when you assign, pass,
 or return a different numerical or pointer type in a place where BOOL
 is expected the compiler will simply chop off the top bits to make it
 fit. So if the last eight bits of your pointer all happen to be 0
 (which is not that unlikely!) then your BOOL will be false instead of
 true.
 
 This can bite you if you try to take shortcuts with comparisons. For example:
 
 - (BOOL)isNotNil:(id)obj {
 return obj != nil;
 }
 
 Pretend for a moment that this method is not actually completely
 pointless. So you say, but any non-nil value for 'obj' is always true,
 so I can remove the comparison and just write this:
 
 - (BOOL)isNotNil:(id)obj {
 return obj;
 }
 
 Now you've set yourself up for a nasty intermittent failure. This will
 work correctly, *most* of the time. But on a significant percentage of
 non-nil 'obj' values, you'll get NO back.
 
 Yeah, I did this once (with a less-pointless method, of course) and it
 bit me. Fun times debugging that
 
 Mike


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question



On Nov 21, 2008, at 7:59 AM, Filip van der Meeren wrote:

Sorry to be this crude, but the documentation isn't created for  
beginners.


Sorry to be blunt, but some of it is.  And Cocoa Fundamentals in  
particular is intended for newcomers to the platform and comparative  
newcomers to programming.


Whether for newcomers or not, though, the documentation should not be  
misleading or wrong.  In this case, it's at least misleading (if for  
no other reason than that it encourages an unproductive line of  
thought).



I agree, but what would you have the documentation say ?

Per my previous reply, it should simply state that — in accordance  
with standard memory management rules, in a reference counted  
environment — the receiver does not own the returned object.


That accurately describes the situation in all cases, and doesn't  
encourage the reader to unnecesarily and unproductively start thinking  
about autorelease.


mmalc

___

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 [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Sherm Pendley


On Nov 20, 2008, at 11:53 PM, Luke Hiesterman wrote:

So thinking gets in the way of understanding and not thinking is the  
path to enlightenment?


Not thinking about *irrelevancies* is the path to enlightenment. It  
allows you to focus on the things you actually *do* need to understand.


sherm--

___

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 [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Sherm Pendley


On Nov 21, 2008, at 10:33 AM, Filip van der Meeren wrote:


On 21 Nov 2008, at 16:21, Adam Leonard wrote:

Ok, so my point with all this is that the documentation should not  
say that all class factory methods always return autoreleased  
objects because that is an implementation detail that (a) is not  
required by the memory management rules, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]


So I'll file a bug.


You will file a bug ?
I really do not see the bug here...


The bug reporter is also used to report bugs in the documentation.

sherm--


___

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 [EMAIL PROTECTED]

Re: NSIndexSet

2008-11-21 Thread David Blanton


The easiest way is to make a mutable index set:

NSMutableIndexSet *indices = [NSMutableIndexSet indexSet];
[indices addIndex:2];
[indices addIndex:4];
[indices addIndex:5];


Looks like the way ... thanks all!

David Blanton




___

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 [EMAIL PROTECTED]

Programmatic control of NSTableView selection?

2008-11-21 Thread Brent Burton

(Moderator, I never heard why the first attempt didn't get to the
list. Too verbose?)

All,
I have a question about programmatically controlling the currently
selected object displayed in a table view.

In short, the table displays lines of text to be spoken by the speech
synthesizer. As each line is spoken, I want it to be the selected line
in the table, and when the next line is spoken, the selection changes.
The lines of text are in an array controller.

Once the process starts, whichever object is currently selected is the
first spoken item. When speech finishes, the code attempts to select
the next one via array controller's canSelectNext and selectNext
methods. If the selection is updated to the next item, it waits until
tableViewSelectionDidChange: is invoked.

Is this the normal way of programmatically interacting with a
selection, or is there a better way?

thanks,
-Brent
___

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 [EMAIL PROTECTED]

Re: Difference between Target and Executable ?

2008-11-21 Thread Stuart Malin



On Nov 20, 2008, at 5:06 PM, [EMAIL PROTECTED] wrote:


Also, what exactly is the difference between Targets and
executables ?? Seems like I am always editing/configuring the Target
but never the executable...? What is the purpose of the executable
anyway?


I know there were several meaningful replies yesterday, but... the ADC  
document Understanding Xcode Projects explains and shows (see Figure  
1) the distinctions and relationships quite clearly:


http://developer.apple.com/tools/xcode/xcodeprojects.html


___

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 [EMAIL PROTECTED]

NSCollectionView woes

2008-11-21 Thread Cem

I'm slowly working my way through Aaron Hillegass' Cocoa Programming  
for Mac OS X and just completed the CarLot program (Chapter 11 in the  
3rd edition).  I decided to challenge myself and try to change the  
interface to use NSCollectionView instead of the interface in the  
book.  In order to do this, I bound the NSCollectionView itself to my  
NSArrayController (which is called Cars) with a keypath of  
arrangedObjects.condition.  I then created a new NSObjectController  
(called 'A car'), set it to entity mode, and set the entity name to  
Car (the same as what Cars has).  I bound its Content Object to  
Cars.selection.  I then bound the GUI elements to the appropriate keys  
in Car (such as car.selection.makeModel).


This, of course, didn't work.  Since Car is bound to the  
Cars.selection, whenever the selection changes, ALL views in my  
NSCollectionView change at the same time.  I then tried a number of  
variants, none of which worked.  What I want is for each subview in my  
NSCollectionView to see the data relating to a different car, not all  
reflect the same car.  What am I doing wrong?


BTW, if anyone wants the current project/code, the whole thing is  
about 32 KB tarballed, so I can email it anywhere anyone wants it.


Thanks,
Cem Karan
___

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 [EMAIL PROTECTED]

Re: NSCollectionView woes

2008-11-21 Thread Volker in Lists


Hi Cem,

the CollectionView needs only to be pointed to the cars  
ArrayController and uses a rather obfuscated way of binding each of  
its subviews fields to the appropriate car entries. you will have to  
bind your prototype view controls to  
CollectionView.representedObjects.key. The CollectionView is aware  
of the arrangedObjects - if bound to them - and automagically creates  
as many views as needed from your view prototype. I recommend to take  
a look at the available examples provided by Apple or read through  
Cocoadevs page on NSCollectionView.


HTH,
Volker


Am 21.11.2008 um 19:47 schrieb Cem:

I'm slowly working my way through Aaron Hillegass' Cocoa Programming  
for Mac OS X and just completed the CarLot program (Chapter 11 in  
the 3rd edition).  I decided to challenge myself and try to change  
the interface to use NSCollectionView instead of the interface in  
the book.  In order to do this, I bound the NSCollectionView itself  
to my NSArrayController (which is called Cars) with a keypath of  
arrangedObjects.condition.  I then created a new NSObjectController  
(called 'A car'), set it to entity mode, and set the entity name to  
Car (the same as what Cars has).  I bound its Content Object to  
Cars.selection.  I then bound the GUI elements to the appropriate  
keys in Car (such as car.selection.makeModel).


This, of course, didn't work.  Since Car is bound to the  
Cars.selection, whenever the selection changes, ALL views in my  
NSCollectionView change at the same time.  I then tried a number of  
variants, none of which worked.  What I want is for each subview in  
my NSCollectionView to see the data relating to a different car, not  
all reflect the same car.  What am I doing wrong?


BTW, if anyone wants the current project/code, the whole thing is  
about 32 KB tarballed, so I can email it anywhere anyone wants it.


Thanks,
Cem Karan
___

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/volker_lists%40ecoobs.de

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]

Re: BOOL value in Dictionary

2008-11-21 Thread Clark Cox

On Fri, Nov 21, 2008 at 7:54 AM, David Blanton [EMAIL PROTECTED] wrote:
 Why is :

 if ( boolVar == YES) or if ( boolVar == NO)

 bad form?

(boolVar == NO) is fine.
(boolVar == YES) is bad form (and could lead to incorrect results)


In C, any non-zero value evaluates to true in a boolean context, so
all of these if statements are equivalent to if(true):

if(YES)
if(42)
if(3.14159)

So it is entirely possible that you may encounter a true boolean
value that isn't equal to 1:

BOOL b = 42; //This is a true boolean, but it is not equal to YES

if(b == YES) //This is false
if(b) //This is true

So, the moral of the story is *never* compare a boolean value against
YES. At best it is redundant, and at worst it is incorrect.

That is, never write if(b == YES). Instead, it's best to write
if(b), if(b != 0) or if(b != NO)


-- 
Clark S. Cox III
[EMAIL PROTECTED]
___

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 [EMAIL PROTECTED]

Re: release and reference counting query

2008-11-21 Thread Marc Stibane


Am 19.11.2008 um 10:05 schrieb mmalcolm crawford:


On Nov 18, 2008, at 10:33 AM, Marc Stibane wrote:
Lets forget for a moment that the dealloc never get's called at all  
on the iPhone

This is simply untrue.


Nope.
Try to set a breakpoint inside the dealloc in the same file as  
applicationDidFinishLaunching, run your app and press the home button.
Never called, and purposely so - the application finishes anyway, so  
why spend cycles deallocating small blocks one-by-one when you can  
just throw away all memory the app used in one block...




So why the local var?
3 lines of code instead of 1...
Isn't a main goal of Cocoa to write *less* code?


Because:
Cocoa strongly advocates you use accessor methods to set instance  
variables(*);
You are discouraged from setting instance variables directly  
anywhere other than in initializers and dealloc(*);


For me, applicationDidFinishLaunching IS an initializer...



On iPhone in particular, you should avoid the use of autorelease.
The latter point in particular means that this alternative:
   self.viewController = [[[UIViewController alloc]
initWithNibName:@MoveMeView bundle:[NSBundle  
mainBundle]] autorelease];

does not follow best practice.
Thus -- almost by a process of elimination -- you're left with the  
pattern shown in iPhone samples.


I stick with my applicationDidFinishLaunching implementation - 1 line  
instead of 3.
Of cause you're right were it some other method which could be called  
more than once and not applicationDidFinishLaunching, which is only  
called once and - as stated above - never paired with dealloc  
(however, applicationWillTerminate is called).


--

In a world without walls and fences,
   who needs windows and gates?




___

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 [EMAIL PROTECTED]

Re: release and reference counting query



On Nov 21, 2008, at 11:15 AM, Marc Stibane wrote:


Am 19.11.2008 um 10:05 schrieb mmalcolm crawford:


On Nov 18, 2008, at 10:33 AM, Marc Stibane wrote:
Lets forget for a moment that the dealloc never get's called at  
all on the iPhone

This is simply untrue.

Nope.
Try to set a breakpoint inside the dealloc in the same file as  
applicationDidFinishLaunching, run your app and press the home button.
Never called, and purposely so - the application finishes anyway, so  
why spend cycles deallocating small blocks one-by-one when you can  
just throw away all memory the app used in one block...


I'm perfectly well aware of that optimisation; as an unconstrained  
statement, however, dealloc never get's called at all on the iPhone  
is untrue.  There are many situations when dealloc *will* be called,  
and so you should take that into account.




Because:
Cocoa strongly advocates you use accessor methods to set instance  
variables(*);
You are discouraged from setting instance variables directly  
anywhere other than in initializers and dealloc(*);

For me, applicationDidFinishLaunching IS an initializer...

You're free to hold your own views; as far as Cocoa is concerned,  
however, it is *not* an initialiser.




On iPhone in particular, you should avoid the use of autorelease.
The latter point in particular means that this alternative:
  self.viewController = [[[UIViewController alloc]
   initWithNibName:@MoveMeView bundle:[NSBundle  
mainBundle]] autorelease];

does not follow best practice.
Thus -- almost by a process of elimination -- you're left with the  
pattern shown in iPhone samples.


I stick with my applicationDidFinishLaunching implementation - 1  
line instead of 3.


Again you're welcome to do so, and you're welcome to deal with any  
bugs that arise as a result.


Of cause you're right were it some other method which could be  
called more than once and not applicationDidFinishLaunching, which  
is only called once and - as stated above - never paired with  
dealloc (however, applicationWillTerminate is called).



@interface MyObject : MySuperClass {
NSString *string;
}
@property (nonatomic, retain) NSString *string;
@end;

@implementation MyObject
@synthesize string;

- (id)init {

if (self = [super init]) {
// a poor example for several reasons, but take this just as  
a way

// to crease a new, owned, object
string = [[NSString alloc] initWithFormat:@now: %@, [NSDate  
date]);

}
return self;
}

- (void)applicationDidFinishLaunching:(UIApplication *)application {

string = [[NSString alloc] initWithFormat:@now: %@, [NSDate  
date]);

}

You just leaked the first value of string.

And to preempt the assertion that this would never happen --  
precisely this *did* happen to someone else who made exactly your  
point, within a week of their having made it.


mmalc




___

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 [EMAIL PROTECTED]

Re: GetApplicationTextEncoding carbon free

2008-11-21 Thread Aki Inoue


Hi,

Mike's comment is right on.
The sole purpose of GetApplicationTextEncoding() is to provide  
functional compatibility with OS 9-era localization resources such as  
STR#.
There really shouldn't be any need to make your app rely on the single  
script approach even for a modern CFString-based Carbon apps.


For Cocoa apps, you shouldn't have to even bother with localization- 
specific string encodings.


If you have any need to store text data by yourself, UTF-16 is the  
recommended storage encoding on Mac OS X.
If the file format requires to be a superset of ASCII, you can use  
UTF-8 as Mike described.


Aki

On 2008/11/21, at 7:27, Michael Ash wrote:

On Fri, Nov 21, 2008 at 4:42 AM, spsaxena [EMAIL PROTECTED]  
wrote:

Hi all,
I am working on making my application carbon free. I could not find  
any
replacement for the API GetApplicationTextEncoding probably  
because this
API has not been marked as deprecated yet. Because of this API I  
need to
link with the carbon framework which I don't want. Can you please  
suggest

any non-carbon API as a replacement for this API.


May I suggest simply removing it and *not* replacing it?

Language-specific text encodings are evil. Sometimes you have to deal
with them, of course. But if you do, then you should already know what
encoding you're dealing with and shouldn't need an API to give you an
application encoding. For places where you are able to choose the
encoding, UTF-8 is the only reasonable ASCII-compatible encoding to
use.

Mike
___

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

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

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

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]

Re: Blue default button style hangs. (THREADED DRAWS!)

2008-11-21 Thread Russ


I've been investigating further on my problem where the app hangs if I 
configure any button to be a blue default button. I had a breakpoint set in 
some of my stuff and noticed the nasty cause ---

The blue default button is being drawn from a separate thread, under the 
auspices of NSUIHeartbeat, as has been described elsewhere on the net. This 
causes a deadlock, however  when the hearbeat triggers a redraw of the 
button (on thread 21), it needs to redraw the view  underneath the button in 
order to composite correctly. I have one of my views underneath, and its 
drawrect gets called from thread 21. That drawrect sends a message to the 
backing object for my view. However, the message handling code knows to look 
for this sort of thing (normally it is used for worker threads to send status 
updates to the main UI thread) --- so here's the fun part --- the message 
sending code drops the call down onto the main thread, ultimately with a 
performSelectorOnMainThread.

It looks like the main thread and the heartbeat thread then deadlock trying to 
access the same display rectangle (the button's).

My message-handling code is doing the 100% logical and correct thing --- the 
drawRect for the view underneath the button HAS to be drawn by the thread that 
owns it --- you can see that easily if you consider that the view is drawing 
from various program data elements that are designed to accomodate the single 
UI thread event flow, and the main UI thread is still running asynchronously as 
the button is doing its pretty blue heartbeat.

Offhand I'd say that a separate thread should be drawing to its own separate 
buffer, and then composited by a master thread that can handle the interlock 
properly. Though having the heartbeat thread call the drawRect routines of 
other threads may work most of the time when the button is sitting over a plain 
uni-color background, I'm inclined to call this an architectural defect.


So far my ideas on workarounds are
1) see if there's something to be done to make the draw work when it is 
executed by the main thread
2) pre-emptively trap the cross-thread draw before it is flipped to the other 
thread, and generate a flat fall-back background.

Better ideas or further explanation?


- Original Message 
From: j o a r [EMAIL PROTECTED]
To: Russ [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2008 3:51:14 PM
Subject: Re: Blue default button style hangs.


On Nov 12, 2008, at 12:27 PM, Russ wrote:

 All the UI stuff runs on one thread, it's very simple in that sense. There's 
 a main [NSApp run] and when you push a button, the modal window pops up from 
 inside the left-mouse-down event handler --- creates and populate the modal 
 window then does runModalForWindow. The modal window is displayed, but trying 
 to click on anything gives you the hung cursor, and pausing the app gives the 
 stack trace summarized below.


If you could reproduce this problem in a very small sample project and send it 
to me I could take a look. It seems to me that there's something special about 
your environment that I'm not aware of, but I'm not sure what it could be.

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 [EMAIL PROTECTED]

CGPoint and CGRect

2008-11-21 Thread DKJ

I want to determine whether a line between two CGPoints in a view  
intersects with a given CGRect. There's nothing in the CGGeometry  
reference that does this specifically, and I don't yet see how to use  
the functions that are there to figure this out.


Before I dust off my Euclid (a rare first edition), has anyone got a  
quick solution? It seems the sort of thing that would be handy in many  
situations.


dkj
___

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 [EMAIL PROTECTED]

Re: CGPoint and CGRect

2008-11-21 Thread Greg Titus



On Nov 21, 2008, at 3:19 PM, DKJ wrote:

I want to determine whether a line between two CGPoints in a view  
intersects with a given CGRect. There's nothing in the CGGeometry  
reference that does this specifically, and I don't yet see how to  
use the functions that are there to figure this out.


Before I dust off my Euclid (a rare first edition), has anyone got a  
quick solution? It seems the sort of thing that would be handy in  
many situations.


dkj


BOOL lineIntersectsRect(CGPoint a, CGPoint b, CGRect rect)
{
float lineSlope = (b.y - a.y) / (b.x - a.x);
float yIntercept = a.y - lineSlope * a.x;
float leftY = lineSlope * NSMinX(rect) + yIntercept;
float rightY = lineSlope * NSMaxX(rect) + yIntercept;

if (leftY = NSMinY(rect)  leftY = NSMaxY(rect))
return YES;
if (rightY = NSMinY(rect)  rightY = NSMaxY(rect))
return YES;
return NO;
}

Here's something I just wrote in email (so may be totally wrong), but  
basically you determine the slope and y-intercept of the line formed  
by the two points, then see where that line's Y-position would be on  
each of the left and right sides of the rectangle. If the Y-position  
hits the left or right edges of the rect, then the line intersects the  
rect.


Note that this is line intersection, not line _segment_ intersection.  
If the line doesn't extend beyond the two points given, you'll need a  
couple extra checks in this code.


Hope this helps,
- Greg
___

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 [EMAIL PROTECTED]

Objective-C variadic methods vs. NSArray et al.

2008-11-21 Thread Scott Thompson

Technical QA 1405 concerns the creation of Objective-C methods that  
take variable number of arguments... so called variadic methods.   
Happily the mechanisms just use the standard C mechanisms (va_start  
and friends).


That being the case, why is it that methods like arrayWithObjects:  
require you to nil terminate the list of arguments?  Is it simply  
tradition, or some kind of optimization?


I don't need to know... I'm just curious.

Scott


___

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 [EMAIL PROTECTED]

Re: Objective-C variadic methods vs. NSArray et al.

2008-11-21 Thread Bill Bumgarner


On Nov 21, 2008, at 5:40 PM, Scott Thompson wrote:
Technical QA 1405 concerns the creation of Objective-C methods that  
take variable number of arguments... so called variadic methods.   
Happily the mechanisms just use the standard C mechanisms (va_start  
and friends).


That being the case, why is it that methods like arrayWithObjects:  
require you to nil terminate the list of arguments?  Is it simply  
tradition, or some kind of optimization?


I don't need to know... I'm just curious.


Without a count, how would the array know how many objects it should  
pop off the stack?


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 [EMAIL PROTECTED]

Re: Objective-C variadic methods vs. NSArray et al.

2008-11-21 Thread Clark Cox

On Fri, Nov 21, 2008 at 3:40 PM, Scott Thompson [EMAIL PROTECTED] wrote:
 Technical QA 1405 concerns the creation of Objective-C methods that take
 variable number of arguments... so called variadic methods.  Happily the
 mechanisms just use the standard C mechanisms (va_start and friends).

 That being the case, why is it that methods like arrayWithObjects: require
 you to nil terminate the list of arguments?  Is it simply tradition, or some
 kind of optimization?

Without the nil, how would the method know when to stop fetching
arguments with va_arg? This is true in C too, you have to have some
way that tells you how many parameters are being passed and what types
they are, and there are generally only two ways to do this:

1) Have the information encoded in the first parameter (like a printf
format string)
2) Have some sentinel value marking the end of the list (like the nil
passed to arrayWithObjects:)

-- 
Clark S. Cox III
[EMAIL PROTECTED]
___

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 [EMAIL PROTECTED]

Re: Objective-C variadic methods vs. NSArray et al.

2008-11-21 Thread Scott Thompson



On Nov 21, 2008, at 5:52 PM, Clark Cox wrote:


On Fri, Nov 21, 2008 at 3:40 PM, Scott Thompson [EMAIL PROTECTED] wrote:
Technical QA 1405 concerns the creation of Objective-C methods that  
take
variable number of arguments... so called variadic methods.   
Happily the

mechanisms just use the standard C mechanisms (va_start and friends).

That being the case, why is it that methods like arrayWithObjects:  
require
you to nil terminate the list of arguments?  Is it simply  
tradition, or some

kind of optimization?


Without the nil, how would the method know when to stop fetching
arguments with va_arg? This is true in C too, you have to have some
way that tells you how many parameters are being passed and what types
they are, and there are generally only two ways to do this:

1) Have the information encoded in the first parameter (like a printf
format string)
2) Have some sentinel value marking the end of the list (like the nil
passed to arrayWithObjects:)


Ah... I see.

___

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 [EMAIL PROTECTED]

Re: Objective-C variadic methods vs. NSArray et al.

2008-11-21 Thread Bill Bumgarner


On Nov 21, 2008, at 3:52 PM, Clark Cox wrote:

two ways to do this:

1) Have the information encoded in the first parameter (like a printf
format string)
2) Have some sentinel value marking the end of the list (like the nil
passed to arrayWithObjects:)


3) Have a second parameter that provides the count:

- (void) readCount: (unsigned int) count stuffs: (Stuff *) aStuff, ...;

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 [EMAIL PROTECTED]

Interface Builder simulator

2008-11-21 Thread Boyd Collier

When I run Interface Simulator with one of my nibs, it is displayed in  
a semi-transparent form, though all the parts can be seen and work as  
expected.  This (i.e. the transparency) is not the case for other nibs  
in the same project. But when I run the project that these nibs are a  
part of, they all look normal.  I guess I messed something up in a  
setting within Interface Builder, but I've not been able to figure out  
what it might be.  Suggestions...??


Thanks,
Boyd
___

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 [EMAIL PROTECTED]

Re: Interface Builder simulator

On Fri, Nov 21, 2008 at 7:22 PM, Boyd Collier
[EMAIL PROTECTED] wrote:
 When I run Interface Simulator with one of my nibs, it is displayed in a
 semi-transparent form, though all the parts can be seen and work as
 expected.  This (i.e. the transparency) is not the case for other nibs in
 the same project. But when I run the project that these nibs are a part of,
 they all look normal.  I guess I messed something up in a setting within
 Interface Builder, but I've not been able to figure out what it might be.

IB does this for View objects.

--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 [EMAIL PROTECTED]

Re: Objective-C variadic methods vs. NSArray et al.

2008-11-21 Thread Clark Cox

On Fri, Nov 21, 2008 at 4:02 PM, Bill Bumgarner [EMAIL PROTECTED] wrote:
 On Nov 21, 2008, at 3:52 PM, Clark Cox wrote:

 two ways to do this:

 1) Have the information encoded in the first parameter (like a printf
 format string)
 2) Have some sentinel value marking the end of the list (like the nil
 passed to arrayWithObjects:)

 3) Have a second parameter that provides the count:

 - (void) readCount: (unsigned int) count stuffs: (Stuff *) aStuff, ...;

Which is covered by my #1, ... for very simple meanings of the word encode :)



-- 
Clark S. Cox III
[EMAIL PROTECTED]
___

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 [EMAIL PROTECTED]

Re: Blue default button style hangs. (THREADED DRAWS!)

2008-11-21 Thread Corbin Dunn


Can you provide your sample of the hang?
.corbin


Le Nov 21, 2008 à 2:36 PM, Russ a écrit :



I've been investigating further on my problem where the app hangs if  
I configure any button to be a blue default button. I had a  
breakpoint set in some of my stuff and noticed the nasty cause ---


The blue default button is being drawn from a separate thread, under  
the auspices of NSUIHeartbeat, as has been described elsewhere on  
the net. This causes a deadlock, however  when the hearbeat  
triggers a redraw of the button (on thread 21), it needs to redraw  
the view  underneath the button in order to composite correctly. I  
have one of my views underneath, and its drawrect gets called from  
thread 21. That drawrect sends a message to the backing object for  
my view. However, the message handling code knows to look for this  
sort of thing (normally it is used for worker threads to send status  
updates to the main UI thread) --- so here's the fun part --- the  
message sending code drops the call down onto the main thread,  
ultimately with a performSelectorOnMainThread.


It looks like the main thread and the heartbeat thread then deadlock  
trying to access the same display rectangle (the button's).


My message-handling code is doing the 100% logical and correct thing  
--- the drawRect for the view underneath the button HAS to be drawn  
by the thread that owns it --- you can see that easily if you  
consider that the view is drawing from various program data elements  
that are designed to accomodate the single UI thread event flow, and  
the main UI thread is still running asynchronously as the button is  
doing its pretty blue heartbeat.


Offhand I'd say that a separate thread should be drawing to its own  
separate buffer, and then composited by a master thread that can  
handle the interlock properly. Though having the heartbeat thread  
call the drawRect routines of other threads may work most of the  
time when the button is sitting over a plain uni-color background,  
I'm inclined to call this an architectural defect.



So far my ideas on workarounds are
1) see if there's something to be done to make the draw work when it  
is executed by the main thread
2) pre-emptively trap the cross-thread draw before it is flipped to  
the other thread, and generate a flat fall-back background.


Better ideas or further explanation?


- Original Message 
From: j o a r [EMAIL PROTECTED]
To: Russ [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2008 3:51:14 PM
Subject: Re: Blue default button style hangs.


On Nov 12, 2008, at 12:27 PM, Russ wrote:

All the UI stuff runs on one thread, it's very simple in that  
sense. There's a main [NSApp run] and when you push a button, the  
modal window pops up from inside the left-mouse-down event handler  
--- creates and populate the modal window then does  
runModalForWindow. The modal window is displayed, but trying to  
click on anything gives you the hung cursor, and pausing the app  
gives the stack trace summarized below.



If you could reproduce this problem in a very small sample project  
and send it to me I could take a look. It seems to me that there's  
something special about your environment that I'm not aware of, but  
I'm not sure what it could be.


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 [EMAIL PROTECTED]

Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)


Context:

UIViewController provides a method, didReceiveMemoryWarning, which is  
invoked on view controllers when the amount of memory available to the  
application is severely constrained.  The goal of the method is to  
allow view controllers to dispose of resources that are currently not  
needed and that can be recreated later if required.  One such resource  
is the view controller's view itself.  Assuming that it does not have  
a superview, the view is disposed of ([self setView:nil];).


A issue arises in that outlets to elements within the nib file are  
typically declared as follows:


@property (nonatomic, retain) IBOutlet ElementClass *element;

Thus even though the main view is disposed of, absent any further  
action the outlets are still retained.  This is not in and of itself a  
problem -- if and when the main view is reloaded, they will simply be  
replaced -- but it does mean that the beneficial effect of the  
didReceiveMemoryWarning is reduced.


There are, currently, a couple of possible remedies...

On Nov 19, 2008, at 12:59 AM, mmalcolm crawford wrote:


This leaves us for now with two solutions:
(a) Greg's (override setView:) which is more future-proof but is in  
many respects academically unsatisfying.




- (void)setView:(UIView *)aView;
{
if (!aView) {
// set outlets to nil, e.g.
self.anOutlet = nil;
}
// Invoke super's implementation last
[super setView:aView];
}


Unfortunately, although in principle this is correct, in practice it  
may fall foul of another issue.


Because UIViewController currently implements its dealloc method using  
the setView: accessor method (rather than simply releasing the  
variable directly...), self.anOutlet = nil will be called in dealloc  
as well as in response to a memory warning... This will lead to a  
crash in dealloc.


The remedy is to ensure that outlet variables are also set to nil in  
dealloc:


- (void)dealloc {
// release outlets and set variables to nil
[anOutlet release], anOutlet = nil;
[super release];
}


The iPhone engineering team is aware of this issue (read: There is no  
need to file bugs on this).


mmalc

___

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 [EMAIL PROTECTED]

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

2008-11-21 Thread Ricky Sharp



On Nov 21, 2008, at 6:53 PM, mmalcolm crawford wrote:


This leaves us for now with two solutions:
(a) Greg's (override setView:) which is more future-proof but is in  
many respects academically unsatisfying.




- (void)setView:(UIView *)aView;
{
   if (!aView) {
   // set outlets to nil, e.g.
   self.anOutlet = nil;
   }
   // Invoke super's implementation last
   [super setView:aView];
}


Unfortunately, although in principle this is correct, in practice it  
may fall foul of another issue.


Because UIViewController currently implements its dealloc method  
using the setView: accessor method (rather than simply releasing the  
variable directly...), self.anOutlet = nil will be called in dealloc  
as well as in response to a memory warning... This will lead to a  
crash in dealloc.


But, that's only if dealloc releases objects directly and doesn't use  
accessors or use the workaround shown below.


I'm now really curious as to why UIViewController uses an accessor in  
dealloc since that's supposed to be bad practice.  Has a bug been  
filed against that too?


The remedy is to ensure that outlet variables are also set to nil in  
dealloc:


- (void)dealloc {
   // release outlets and set variables to nil
   [anOutlet release], anOutlet = nil;
   [super release];
}



That is indeed a workaround, but one of the reasons I moved towards  
using accessors instead (i.e. I didn't have to think about all the  
edge cases where clearing out the ivar was absolutely necessary; the  
accessor always does the right thing).


Now then, two things...

(1) In my personal code, I'm the only developer and do not integrate  
with any third party code (I only use Apple's SDKs directly).  Having  
said that, I do have full control over my own objects and thus don't  
have any pitfalls in using accessors in inits and/or deallocs.


(2) But, I can see where in the general case, this is becoming quite  
problematic for folks.  After all, it's always dangerous to base your  
code on implementation details such as these.


___
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm)   http://www.instantinteractive.com



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)



On Nov 21, 2008, at 5:21 PM, Ricky Sharp wrote:
But, that's only if dealloc releases objects directly and doesn't  
use accessors or use the workaround shown below.



Yes, although following best practice is assumed...  :-)

I'm now really curious as to why UIViewController uses an accessor  
in dealloc since that's supposed to be bad practice.  Has a bug been  
filed against that too?



Yes.

The remedy is to ensure that outlet variables are also set to nil  
in dealloc:


- (void)dealloc {
  // release outlets and set variables to nil
  [anOutlet release], anOutlet = nil;
  [super release];
}
That is indeed a workaround, but one of the reasons I moved towards  
using accessors instead (i.e. I didn't have to think about all the  
edge cases where clearing out the ivar was absolutely necessary; the  
accessor always does the right thing).


I would suggest that releasing then setting the variable to nil is a  
better strategy than using the accessor.



Now then, two things...
(1) In my personal code, I'm the only developer and do not integrate  
with any third party code (I only use Apple's SDKs directly).   
Having said that, I do have full control over my own objects and  
thus don't have any pitfalls in using accessors in inits and/or  
deallocs.




That's fine; if you're *sure* you'll never run into a problem such as  
this...


(2) But, I can see where in the general case, this is becoming quite  
problematic for folks.  After all, it's always dangerous to base  
your code on implementation details such as these.



... indeed, this is why best practice is given as such.

mmalc



___

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 [EMAIL PROTECTED]

Re: GetApplicationTextEncoding carbon free

2008-11-21 Thread Deborah Goldsmith

And if you really, really need to access legacy Mac OS 9 text files,  
the correct encoding to use is CFStringGetSystemEncoding(), which is  
in CoreFoundation.


GetApplicationTextEncoding(): legacy encoding (if any) corresponding  
to the language *the app is running in*. As Aki says, it's for  
resources inside the application itself (hence the name of the API).
CFStringGetSystemEncoding(): legacy encoding (if any) corresponding to  
the user's primary language, which may differ from the language the  
app is running in (e.g., English-only app on Japanese system). This is  
the correct encoding to use for legacy Mac OS 9 text files.


Deborah

On Nov 21, 2008, at 12:39 PM, Aki Inoue wrote:


Hi,

Mike's comment is right on.
The sole purpose of GetApplicationTextEncoding() is to provide  
functional compatibility with OS 9-era localization resources such  
as STR#.
There really shouldn't be any need to make your app rely on the  
single script approach even for a modern CFString-based Carbon apps.


For Cocoa apps, you shouldn't have to even bother with localization- 
specific string encodings.


If you have any need to store text data by yourself, UTF-16 is the  
recommended storage encoding on Mac OS X.
If the file format requires to be a superset of ASCII, you can use  
UTF-8 as Mike described.


Aki

On 2008/11/21, at 7:27, Michael Ash wrote:

On Fri, Nov 21, 2008 at 4:42 AM, spsaxena [EMAIL PROTECTED]  
wrote:

Hi all,
I am working on making my application carbon free. I could not  
find any
replacement for the API GetApplicationTextEncoding probably  
because this
API has not been marked as deprecated yet. Because of this API I  
need to
link with the carbon framework which I don't want. Can you please  
suggest

any non-carbon API as a replacement for this API.


May I suggest simply removing it and *not* replacing it?

Language-specific text encodings are evil. Sometimes you have to deal
with them, of course. But if you do, then you should already know  
what

encoding you're dealing with and shouldn't need an API to give you an
application encoding. For places where you are able to choose the
encoding, UTF-8 is the only reasonable ASCII-compatible encoding to
use.

Mike
___

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

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

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

This email sent to [EMAIL PROTECTED]


___

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/goldsmit%40apple.com

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]

simple question about variable retain/release (NSDate)

2008-11-21 Thread Bob Sabiston


Hi,

  I have a newbie question about retain/release stuff when using  
NSDate.  I am confused a little about what is necessary in this case.


I've got a local variable sTime (NSDate *).  I use it to measure the  
time and then compare it to the current time, so that I can space out an

animation over one second.

The docs say that [NSDate date] creates and returns an NSDate.  Does  
that mean the memory's been allocated until I release it?

Here's what I have.  It works until the very end, where it crashes.

NSDate *sTime = [NSDate date];  // get beginning time

NSTimeInterval elapsedTime;
float frameduration = 1.0/30.0;  // for 30 fps

for (int f = 0; f  30; f++) {
ratio = ((float)f/framerate);

// animation interpolation here based on ratio

// now wait for 1/30th of a second
do {
   elapsedTime = -[sTime timeIntervalSinceNow];
}
while (elapsedTime  frameduration);

[sTime release];
sTime = [NSDate date];

[self drawView];
}

[sTime release];
sTime = NULL;

So, you see that whenever one frame's worth of time has passed, I  
release the NSDate and set sTime again to [NSDate date].  Do I need to  
do that?
Why does it crash at the end?  sTime is just a pointer.  And if that  
final release is crashing it, why do all of the previous ones in the  
for-loop not crash it?


I could do the same thing just by measuring the time once and then  
just use the elapsed time incrementally for measurement, but I would  
like to understand what it is that is causing this crash the way it is  
now.  Is the [NSDate date] call something I don't need to worry about  
with regard to memory?  That is, can I set it and re-set it over and  
over, then finally leave the function without worrying about what  
happened to all of those calls?


Thanks for any info.
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 [EMAIL PROTECTED]

Re: simple question about variable retain/release (NSDate)

2008-11-21 Thread Andrew Farmer


On 21 Nov 08, at 18:17, Bob Sabiston wrote:

Hi,

 I have a newbie question about retain/release stuff when using  
NSDate.  I am confused a little about what is necessary in this case.


I've got a local variable sTime (NSDate *).  I use it to measure the  
time and then compare it to the current time, so that I can space  
out an

animation over one second.

The docs say that [NSDate date] creates and returns an NSDate.  Does  
that mean the memory's been allocated until I release it?


See the Cocoa memory management rules:

http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html

As the selector name date doesn't start with alloc or new, and  
doesn't contain copy, you don't own this object, making all the  
releases on sTime incorrect. The crashes are occurring when the  
enclosing NSAutoreleasePool gets purged (but that's an implementation  
detail - the part that matters is that you're releasing objects that  
you never owned).



Here's what I have.  It works until the very end, where it crashes.

...


// now wait for 1/30th of a second
do {
   elapsedTime = -[sTime timeIntervalSinceNow];
}
while (elapsedTime  frameduration);


This is incredibly inefficient. Use

	[NSThread sleepUntilDate:[NSDate  
dateWithTimeIntervalSinceNow:frameduration]]


instead. (But realize that this'll run slightly under 30 FPS, as the  
drawing takes some time.)

___

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 [EMAIL PROTECTED]

Re: CGPoint and CGRect