IB displays a non-outlet (Bug or feature?)

[Negm-Awad Amin]

Hi

before I report this, I want to check, whether I misunderstood  
something.


I've a window controller subclass with three outlets. Additional the  
class owns to ivars, one of them typed id. These ivars are not marked  
as outlet.


@interface GroupsWC : NSWindowController {
   IBOutlet NSArrayController* personsController;
   IBOutlet NSArrayController* groupsController;
   IBOutlet NSOutlineView* sidebarView;

   NSIndexSet* selectionIndexes;
   id selectedGroup;
}

In the IB3 I see the ivar typed id and can connect it. Is this the  
intended behaviour? (I accidentally connected this "outlet" to a view.)

http://www.cocoading.de/webspace/id_outlet.tiff

Cheers,

Amin Negm-Awad
[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: !foo vs foo == nil

[Jules Colding]

On 21/08/2008, at 01.56, John C. Randolph wrote:



On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote:


There was a common perception that NULL is not really the same as  
nil. But seems like in the end it really is (void*)0.



They differ in type, not in value.

"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.

Personally, I prefer "if (!foo)" over "if (foo == nil)", because the  
latter has the hazard of a typo that compiles.  You can lose a fair  
bit of time staring at "if (foo = nil)" before you spot the mistake.


Which is why you should always write "if (nil == foo)".

--
  jules


___

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

Please do not post 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: !foo vs foo == nil

[Thomas Davie]

On 21 Aug 2008, at 09:06, Jules Colding wrote:



On 21/08/2008, at 01.56, John C. Randolph wrote:



On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote:


There was a common perception that NULL is not really the same as  
nil. But seems like in the end it really is (void*)0.



They differ in type, not in value.

"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.

Personally, I prefer "if (!foo)" over "if (foo == nil)", because  
the latter has the hazard of a typo that compiles.  You can lose a  
fair bit of time staring at "if (foo = nil)" before you spot the  
mistake.


Which is why you should always write "if (nil == foo)".


Just to add my 2 cents to this discussion, I think there's something  
which hasn't been brought up (and I guess isn't often brought up by C  
programmers).


One of the two options doesn't make sense here.
Because of C's weak type system ! works on almost anything you throw  
at it.  However, it is a *boolean* operator.  Boolean negating a  
pointer is a hack that by happy coincidence works.  On the other hand,  
nil == foo is type safe, and makes semantic sense.


For that simple reason, I'd go for nil == foo every time.

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: Accessing properties of a generic class

[Chris Hanson]

On Aug 20, 2008, at 7:54 PM, John Murphy wrote:

I have a Person class with name and image properties stored in an  
array. When I access its properties from within the controller class  
like this:


Person *person = [objectArray objectAtIndex:0]; 
[nameField setStringValue:person.name]; 
[imageArea setImage:person.image];

everything works fine. But when I try to do it generically:

id object = [objectArray objectAtIndex:0];
[nameField setStringValue:object.name]; 
[imageArea setImage:object.image];

I get errors about the name and image properties not being in a  
structure or union.


The compiler errors you get are expected.  The Objective-C 2.0 dot  
syntax is mapped to message sends just like bracket syntax is.   
However, the mapping is more flexible:  In the @property declaration  
you can specify that a property has getter and setter methods with  
specific names, or that it should be read-only and thus only have a  
getter.


Because of this flexibility, the compiler needs additional compile- 
time type information to know how to generate the actual message sends  
that correspond to the property access.


For example, say I have a class representing a task:

@interface Task : NSObject {
@private
NSString *_title;
BOOL _completed;
}

@property(readwrite, copy) NSString *title;
@property(readwrite, assign, getter=isCompleted) BOOL completed;

@end

Now I want to log all completed tasks:

for (Task *task in self.allTasks)
if (task.completed) NSLog(@"Completed: %@", task.title);

The property name used is "completed" just as it is in the @property  
declaration.  However, it will be compiled identically to the  
expression "[task isCompleted]" because that's what the property  
actually means, since its declaration says "getter=isCompleted".


  -- Chris

___

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

Please do not post 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: !foo vs foo == nil

[Jean-Daniel Dupas]

haha gros malin why free (func) does this test?
arf sorry your trusting scale is going to zero


Not sure what you're trying to say. According to the C standard, given
a variable (foo) the following are identical:

if(foo == 0)
if(foo == nil)
if(foo == NULL)
if(!foo)
if(foo == '0')

and any other way you can compare to a literal zero.


I hope this is a typo but '0' != 0, so the last line is not a valid  
way to test for nullity (but foo == '\0' is).



___

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

Please do not post 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: !foo vs foo == nil

[Jules Colding]

On 21/08/2008, at 09.21, Thomas Davie wrote:



On 21 Aug 2008, at 09:06, Jules Colding wrote:



On 21/08/2008, at 01.56, John C. Randolph wrote:



On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote:


There was a common perception that NULL is not really the same as  
nil. But seems like in the end it really is (void*)0.



They differ in type, not in value.

"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.

Personally, I prefer "if (!foo)" over "if (foo == nil)", because  
the latter has the hazard of a typo that compiles.  You can lose a  
fair bit of time staring at "if (foo = nil)" before you spot the  
mistake.


Which is why you should always write "if (nil == foo)".


Just to add my 2 cents to this discussion, I think there's something  
which hasn't been brought up (and I guess isn't often brought up by  
C programmers).


One of the two options doesn't make sense here.
Because of C's weak type system ! works on almost anything you throw  
at it.  However, it is a *boolean* operator.  Boolean negating a  
pointer is a hack that by happy coincidence works.  On the other  
hand, nil == foo is type safe, and makes semantic sense.


For that simple reason, I'd go for nil == foo every time.


Yes, and in general you should always do "if (CONSTANT == foo)" to  
catch the potential "if (CONSTANT = foo)" error.


Best regards,
  jules

___

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

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

Cheap quality improvements (was Re: !foo vs foo == nil)

[Neil Brewitt]

On 21 Aug 2008, at 04:03, Michael Ash wrote:


This hazard goes away if you turn on the appropriate warnings. I
compile all of my code with "-W -Wall -Wno-unused-parameter", and it
has caught much more than just this error over the years.


[getting slightly off topic]

Speaking as a battle-hardened QA manager, the one simple step of  
turning on all warnings and removing them is one of the cheapest ways  
possible to improve the quality of the output of a dev team[1]. I'm  
astounded that pretty much every commercial dev team I've worked with  
have been content to check in code with warnings until I harangue them  
about it. Also amazing is that they all KNEW what -Wall and -Werror do  
but were content not to bother with them.


Neil.

[1] Of course firing the chaff is cheaper in the short term, but is  
not always seen as a pragmatic option when projects are underway.

___

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

Please do not post 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: Best Way to Handle Properties?

[Dave]

On 20 Aug 2008, at 19:37, Ken Thomases wrote:


On Aug 20, 2008, at 12:42 PM, Dave wrote:


On Aug 20, 2008, at 6:05 AM, Dave wrote:




-(void) setFirstName:(NSString*)theNewValue
{
if (FirstName != theNewValue)
FirstName = [theNewValue copy];
}


The reason I did it like this in that case is that I copied and  
pasted one template for all 56 odd properties, I didn't want to  
have to edit them all again later on.


If you really have 56-odd setters all implemented in the same way,  
you have a big problem.  That implementation is simply not viable.   
It doesn't do proper memory management.  Think of what happens if  
you call it twice over the lifetime of the PersonDetails object.   
The first time perhaps you are "lucky" and FirstName is nil.  In  
that case, there isn't an old string that needs to be released  
before you change the FirstName ivar to point to the new copy.


However, on the second time through, FirstName holds a pointer to a  
string object which this PersonDetails object owns.  Before it  
loses that pointer (by replacing it with a new pointer) it needs to  
release that old string.  So, the expected form of the setter would  
be:


- (void) setFirstName:(NSString*)theNewValue
{
if (firstName != theNewValue)
{
[firstName release]; // This is the important thing you're 
missing
firstName = [theNewValue copy];
}
}

However, if you have accessors (like these examples) which don't do  
any custom processing (like modifying the new value), then your  
best bet is to let the compiler synthesize them.  You're allowed to  
synthesize some properties' accessors while manually implementing  
others (those that require custom behavior).




No, not all 56 like that, only so many are strings, and I've not  
finished yet, I'll have to edit them all again anyway I know, but I  
didn't know that when I originally wrote it!


The copy operation here, copies that data from one string to a  
newly allocated string, right?


Conceptually, yes.  The copy message gives you back a new string  
which is a copy of the string to which you sent the message.


There is a wrinkle.  As an optimization, when you copy immutable  
value objects you may actually just receive the same object back,  
with its retain count incremented.  That is, for those kinds of  
objects, -copy may be a synonym for -retain.  This is OK because  
two copies of the same immutable value behave exactly the same, so  
there might as well be only one.  You don't have to worry about  
this optimization; it's an implementation detail.  I just wanted to  
make you aware of it because you specifically asked if you get a  
newly allocated string, and sometimes you don't, but in those cases  
it doesn't matter. :)


Because both -copy and -retain leave you with the same ownership  
responsibility, there is no memory management implication from this  
optimization, either.




A, ok, now I'm beginning to understand. I hadn't seen the Memory  
Guidelines Manual before, I've read it one and am just about to do so  
again.


Are all 56 properties required for the object to be valid?  I  
wasn't suggesting that you not use setters after the object is  
initialized.  I was suggesting that initializing an object should  
result in a valid object.


Yes, all 56 properties are required for the object to be valid


Yikes.

so in the initializer I set the NSString pointers to nil, zeroize  
the integers and set the dataValid flag to FALSE.


Just so you know, the Objective-C runtime guarantees that +alloc  
(or +allocWithZone:) gives you an object with all of its ivars  
zeroed out.  So, there's no need for you to manually do that.


All the Best
Dave


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: !foo vs foo == nil

[Clark Cox]

On Thu, Aug 21, 2008 at 12:21 AM, Thomas Davie <[EMAIL PROTECTED]> wrote:
>
> On 21 Aug 2008, at 09:06, Jules Colding wrote:
>
>>
>> On 21/08/2008, at 01.56, John C. Randolph wrote:
>>
>>>
>>> On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote:

 There was a common perception that NULL is not really the same as nil.
 But seems like in the end it really is (void*)0.
>>>
>>>
>>> They differ in type, not in value.
>>>
>>> "NULL" is (void *) 0.
>>> "nil" is (id) 0.
>>> "Nil" is (Class) 0.
>>>
>>> Personally, I prefer "if (!foo)" over "if (foo == nil)", because the
>>> latter has the hazard of a typo that compiles.  You can lose a fair bit of
>>> time staring at "if (foo = nil)" before you spot the mistake.
>>
>> Which is why you should always write "if (nil == foo)".
>
> Just to add my 2 cents to this discussion, I think there's something which
> hasn't been brought up (and I guess isn't often brought up by C
> programmers).
>
> One of the two options doesn't make sense here.

It may not make sense to those who aren't used to C (or, more
accurately, are *more* used to another language), but it makes perfect
sense to C programmers (just as [foo method: bar] doesn't make sense
to C programmers, but makes perfect sense to Obj-C programmers).
Different languages have different idioms. C programmers likely tend
not to bring it up, because it is second nature to them.

> Because of C's weak type system ! works on almost anything you throw at it.
>  However, it is a *boolean* operator.  Boolean negating a pointer is a hack
> that by happy coincidence works.

This is not a "hack" or a "coincidence", this is by design. A non-NULL
pointer *is* a boolean expression that evaluates to true, just as a
non-zero integer is. Again, it doesn't work by coincidence, it is a
guarantee of the language standard.

Note, that the same is true in C++, which has a much stronger type
system than C.

> On the other hand, nil == foo is type
> safe, and makes semantic sense.
>
> For that simple reason, I'd go for nil == foo every time.

-- 
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: !foo vs foo == nil

[Clark Cox]

On Thu, Aug 21, 2008 at 12:39 AM, Jean-Daniel Dupas
<[EMAIL PROTECTED]> wrote:

>>>
>>> haha gros malin why free (func) does this test?
>>> arf sorry your trusting scale is going to zero
>>
>> Not sure what you're trying to say. According to the C standard, given
>> a variable (foo) the following are identical:
>>
>> if(foo == 0)
>> if(foo == nil)
>> if(foo == NULL)
>> if(!foo)
>> if(foo == '0')
>>
>> and any other way you can compare to a literal zero.
>
> I hope this is a typo but '0' != 0, so the last line is not a valid way to
> test for nullity (but foo == '\0' is).

Indeed, I lost a backslash there :)

-- 
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: Parse form values from HTTP POST

[Thomas Engelmeier]

Am 20.08.2008 um 22:54 schrieb Jesse Grosjean:

Does anyone know what the best way to parse form values from and  
HTTP Post is?


I have a mini HTTP server in my app, and it needs to accept posts.  
I'm using CFHTTP to implement the server, so I have a  
CFHTTPMessageRef. I'm trying to figure out how to turn that into a  
dictionary of keys and values. Is there an API that can do this, or  
any example code around?


No solution (debugging POST packets sucks IMO...) but all the Web API  
hype is now with AJAX + REST, which uses HTTP GET + "everything is in  
the URI" - are you sure you need POST?


Regards,
Tom_E
___

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

Please do not post 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: !foo vs foo == nil

[Jean-Daniel Dupas]

Le 21 août 08 à 10:06, Clark Cox a écrit :

On Thu, Aug 21, 2008 at 12:21 AM, Thomas Davie <[EMAIL PROTECTED]>  
wrote:


On 21 Aug 2008, at 09:06, Jules Colding wrote:



On 21/08/2008, at 01.56, John C. Randolph wrote:



On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote:


There was a common perception that NULL is not really the same  
as nil.

But seems like in the end it really is (void*)0.



They differ in type, not in value.

"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.

Personally, I prefer "if (!foo)" over "if (foo == nil)", because  
the
latter has the hazard of a typo that compiles.  You can lose a  
fair bit of

time staring at "if (foo = nil)" before you spot the mistake.


Which is why you should always write "if (nil == foo)".


Just to add my 2 cents to this discussion, I think there's  
something which

hasn't been brought up (and I guess isn't often brought up by C
programmers).

One of the two options doesn't make sense here.


It may not make sense to those who aren't used to C (or, more
accurately, are *more* used to another language), but it makes perfect
sense to C programmers (just as [foo method: bar] doesn't make sense
to C programmers, but makes perfect sense to Obj-C programmers).
Different languages have different idioms. C programmers likely tend
not to bring it up, because it is second nature to them.

Because of C's weak type system ! works on almost anything you  
throw at it.
However, it is a *boolean* operator.  Boolean negating a pointer is  
a hack

that by happy coincidence works.


This is not a "hack" or a "coincidence", this is by design. A non-NULL
pointer *is* a boolean expression that evaluates to true, just as a
non-zero integer is. Again, it doesn't work by coincidence, it is a
guarantee of the language standard.

Note, that the same is true in C++, which has a much stronger type
system than C.


Agree with that. And remember that the bool type is a recent addition  
and was not defined in the first C language version.
So it's perfectly valid to use the '!' operator on something that is  
not a boolean.




___

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

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

Sending a message to super's super (tab keyDown in NSTextView)

[Jerry Krinock]

When the 'tab' or 'backTab' key is pressed, NSTextView accepts it as a  
character to be typewritten.  But sometimes I want NSTextView to  
behave like an NSTextField, with 'tab' or 'backTab' selecting the next  
or previous key view.  So, in my NSTextView subclass, I over-ride - 
keyDown: and re-implement the next/previous view selection.


It works, but, besides being redundant code, this re-implementation  
seems like an evil assumption of some other class' behavior by my  
subclass.  What I really want to say is: "Behave like your  
'grandfather' class, NSView".  But there is no supersuper keyword.


Is there any way to improve this?.

- (void)keyDown:(NSEvent*)event {
NSString *s = [event charactersIgnoringModifiers] ;
unichar keyChar = 0 ;
if ([s length] == 1) {
keyChar = [s characterAtIndex:0] ;

// Our superclass NSTextView accepts tabs and backtabs as text.
// If we want _tabToNextKeyView, we re-implement the NSView  
behavior

// of selecting the next or previous key view
if ((keyChar == NSTabCharacter)&& _tabToNextKeyView) {
[[self window] selectNextKeyView:self] ;
}
else if ((keyChar == NSBackTabCharacter) &&  
_tabToNextKeyView) {

[[self window] selectPreviousKeyView:self] ;
}
else {
// Handle using super's (i.e. NSTextView) - 
interpretKeyEvents:,

// which will typewrite the key-downed character
NSArray* events = [NSArray arrayWithObject:event] ;
[self interpretKeyEvents:events] ;
}
}
}


___

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

Please do not post 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: Parse form values from HTTP POST

[Thomas Engelmeier]

Am 21.08.2008 um 04:07 schrieb Jesse Grosjean:

So now at least I have a more specific question. Is there any OS X  
framework for decoding x-www-form-urlencoded, or sample code  
floating around. I've found what I need in Java:


http://kickjava.com/src/java/net/URLDecoder.java.htm

And while it's not that much code, it seems like the kind of thing  
that must have been done before. Anyway I'll start on my own  
implementation, but if someone can point me to an existing solution  
for decoding x-www-form-urlencoded that would make my day :)


isn't that java code is just
[urlString  
stringByReplacingPercentEscapesUsingEncoding:encodingFromHTTPHeader]; ? 
___


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

Please do not post 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: Design Question: Pro & Cons of KVC/KVO

[Negm-Awad Amin]

Am Do,21.08.2008 um 08:58 schrieb Oleg Krupnov:


I need to make the design decision regarding how the model and the
views will be kept in sync with each other. Namely:

- I can use key-value coding and observing (KVC and KVO)
- I can use bindings (not sure if it's really different from the KVC/ 
KVO)
At least it isn't, since a binding registers KVO and uses KVC for data  
retrievel.




- I can write the "glue code" myself

The concept of KVC/KVO is new to me. I have been looking at the Sketch
sample (a kind of application I am building myself too), which is
based on KVC/KVO, and I have found that the use of KVC/KVO makes the
program very unreadable and clumsy (like C++ COM code in Windows, you
know), because of the generic messages and hidden dependencies.
There is no "magic". IMHO, it makes the code more readable, beause the  
dependencies are not central, but encapsulated.



I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,

This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:change:context:

I think, you want to say, that if one changes a property, he sends a  
message to a central MVC server, which distributes update messages.  
Correct? Why?


if you want to have one method per synchronized property, use a  
NSString instance as context and simply do that:


// Typed in mail.app, simple example
- observeValueForKeyPath:(NSString*)keyPath ofObject: 
(id)observedObject change:(NSDictionary*)change context:(void*)context

{
  NSString* updateMethode = [NSString stringWithFormat.@"update%@",  
context]; // I didn't care about upper case to keep it simple for  
demonstration

  SEL selector = NSSelectorFromString( updateMethod );
  if( [self respondsToSelector:selector] ) {
 [self performSelector:selector];
  }
}

This will call a method with the name updateSize, if you set @"size"  
as the context at registration.


But: Why?

Cheers,

Amin



than try to fit into the over-generalized
model of KVC/KVO for the sake of skipping a few lines of code. And I
still have to subscribe objects to objects with KVC/KVO, don't I?

Does anyone actually use KVC/KVO? What is your experience? Any
pros/cons, opinions and best practices would be appreciated.

Thanks
___

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

Please do not post 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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[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: !foo vs foo == nil

[Negm-Awad Amin]

Am Do,21.08.2008 um 09:54 schrieb Jules Colding:



On 21/08/2008, at 09.21, Thomas Davie wrote:



On 21 Aug 2008, at 09:06, Jules Colding wrote:



On 21/08/2008, at 01.56, John C. Randolph wrote:



On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote:


There was a common perception that NULL is not really the same  
as nil. But seems like in the end it really is (void*)0.



They differ in type, not in value.

"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.

Personally, I prefer "if (!foo)" over "if (foo == nil)", because  
the latter has the hazard of a typo that compiles.  You can lose  
a fair bit of time staring at "if (foo = nil)" before you spot  
the mistake.


Which is why you should always write "if (nil == foo)".


Just to add my 2 cents to this discussion, I think there's  
something which hasn't been brought up (and I guess isn't often  
brought up by C programmers).


One of the two options doesn't make sense here.
Because of C's weak type system ! works on almost anything you  
throw at it.  However, it is a *boolean* operator.  Boolean  
negating a pointer is a hack that by happy coincidence works.  On  
the other hand, nil == foo is type safe, and makes semantic sense.


For that simple reason, I'd go for nil == foo every time.


Yes, and in general you should always do "if (CONSTANT == foo)" to  
catch the potential "if (CONSTANT = foo)" error.

You should always compile with -Wall to catch potential
if( value1 = value2 )
even if value1 is no constant.

Cheers,
Amin




Best regards,
 jules

___

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

Please do not post 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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[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: !foo vs foo == nil

[Thomas Engelmeier]

Am 21.08.2008 um 05:03 schrieb Michael Ash:

There was a common perception that NULL is not really the same as  
nil. But

seems like in the end it really is (void*)0.


They differ in type, not in value.

"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.


This is true conceptually but not as far as their actual definition.
NULL can be either 0 or (void *)0.


Let's be a little bit more precise, I'll try to paraphrase correctly  
from my memory:


a.)
(int) NULL  is NOT required or guaranteed  0x0 by the standard. This  
is why one should never use

   if( anPtr == (void *) 0 );
instead of
   if( anPtr == NULL );
On modern machines, it usually is.

b.) At least the C++ standard mandates for type conversion of an  
pointer to an boolean, that e.g. ( !anPtr )  is equivalent  to ( ! 
(anPtr == NULL )). I didn't read the C99 spec but I'm sure there is  
something similar specified.


This implementation detail does probably not matter on most platforms  
today as even microcontrollers have AFAIK linear address spaces.
When I was writing my first C app on a DOS machine, there were  
segmented addresses. That meant  it could happen that


((somePtr + offset) - offset) == somePtr

evaluated to false - (somePtr + offset) changed the segment,  
anotherPtr - offset did not. Big debug surprise for poor little 68020  
fanboy ;-)


Regards,
Tom_E
___

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

Please do not post 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: IB displays a non-outlet (Bug or feature?)

[Jon Hess]

Hey Amin -

It's a compatibility feature that, I believe, dates from before the  
existence of IBOutlet. All id typed ivars without a leading underscore  
are available as outlets. There are similar rules for actions. I
For example, IB will treat any method with a single id typed argument  
named 'sender' as an action.


From my phone -
Jon Hess

On Aug 21, 2008, at 12:01 AM, Negm-Awad Amin <[EMAIL PROTECTED]>  
wrote:



Hi

before I report this, I want to check, whether I misunderstood  
something.


I've a window controller subclass with three outlets. Additional the  
class owns to ivars, one of them typed id. These ivars are not  
marked as outlet.


@interface GroupsWC : NSWindowController {
  IBOutlet NSArrayController* personsController;
  IBOutlet NSArrayController* groupsController;
  IBOutlet NSOutlineView* sidebarView;

  NSIndexSet* selectionIndexes;
  id selectedGroup;
}

In the IB3 I see the ivar typed id and can connect it. Is this the  
intended behaviour? (I accidentally connected this "outlet" to a  
view.)

http://www.cocoading.de/webspace/id_outlet.tiff

Cheers,

Amin Negm-Awad
[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/jhess%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: !foo vs foo == nil

[Thomas Engelmeier]

Am 21.08.2008 um 05:25 schrieb Clark Cox:

Not sure what you're trying to say. According to the C standard, given

a variable (foo) the following are identical:



if(!foo)
if(foo == '0')



YIKES!

(NULL == (char_type_t) 0x30  ) != ( NULL == '0' ) ?

C99 or C99 + C++98?

Regards,
Tom_E


___

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

Please do not post 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: IB displays a non-outlet (Bug or feature?)

[Negm-Awad Amin]

Am Do,21.08.2008 um 10:51 schrieb Jon Hess:


Hey Amin -

It's a compatibility feature that, I believe, dates from before the  
existence of IBOutlet. All id typed ivars without a leading  
underscore are available as outlets. There are similar rules for  
actions. I
For example, IB will treat any method with a single id typed  
argument named 'sender' as an action.


From my phone -
Jon Hess
Incredible! I'm developing with IB for more than five years and have  
never realized that. Probably the reason is, that I hate id-typed  
ivars and use them very rarely.


Thanks!
Amin




On Aug 21, 2008, at 12:01 AM, Negm-Awad Amin [EMAIL PROTECTED]> wrote:



Hi

before I report this, I want to check, whether I misunderstood  
something.


I've a window controller subclass with three outlets. Additional  
the class owns to ivars, one of them typed id. These ivars are not  
marked as outlet.


@interface GroupsWC : NSWindowController {
 IBOutlet NSArrayController* personsController;
 IBOutlet NSArrayController* groupsController;
 IBOutlet NSOutlineView* sidebarView;

 NSIndexSet* selectionIndexes;
 id selectedGroup;
}

In the IB3 I see the ivar typed id and can connect it. Is this the  
intended behaviour? (I accidentally connected this "outlet" to a  
view.)

http://www.cocoading.de/webspace/id_outlet.tiff

Cheers,

Amin Negm-Awad
[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/jhess%40apple.com

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[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: !foo vs foo == nil

[Negm-Awad Amin]

Am Do,21.08.2008 um 10:47 schrieb Thomas Engelmeier:



Am 21.08.2008 um 05:03 schrieb Michael Ash:

There was a common perception that NULL is not really the same as  
nil. But

seems like in the end it really is (void*)0.


They differ in type, not in value.

"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.


This is true conceptually but not as far as their actual definition.
NULL can be either 0 or (void *)0.


Let's be a little bit more precise, I'll try to paraphrase correctly  
from my memory:


a.)
(int) NULL  is NOT required or guaranteed  0x0 by the standard. This  
is why one should never use

  if( anPtr == (void *) 0 );
instead of
  if( anPtr == NULL );
On modern machines, it usually is.

b.) At least the C++ standard mandates for type conversion of an  
pointer to an boolean, that e.g. ( !anPtr )  is equivalent  to ( ! 
(anPtr == NULL )). I didn't read the C99 spec but I'm sure there is  
something similar specified.


This implementation detail does probably not matter on most  
platforms today as even microcontrollers have AFAIK linear address  
spaces.
When I was writing my first C app on a DOS machine, there were  
segmented addresses. That meant  it could happen that


((somePtr + offset) - offset) == somePtr

evaluated to false - (somePtr + offset) changed the segment,  
anotherPtr - offset did not. Big debug surprise for poor little  
68020 fanboy ;-)



First: Thanks a lot! I wanted to write somthing like this, but …

I always say, that theoretically it is dangerous to relay on NO = 0  
and nil = 0 (The assumption YES = 1 is simply wrong on some machines).  
In practice of course this always works.


But in the documentation of  Objective-C 2 from Apple, the definitions  
of NO and nil are diclosed. So I think, now it is for (and only for)  
Objective-C 2 "official" that NO and nil equals to 0.


Sometimes you see in source code something like this:
if( booleanVarOrExpression == YES )
(I think, Rentzsch does it that way, IIRC) and Ithink, that this is  
simply correct.


Cheers,
Amin


Regards,
Tom_E
___

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

Please do not post 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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[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: Sending a message to super's super (tab keyDown in NSTextView)

[Jon Hess]

Hey Jerry -

A couple of comments.

If you want to call super's super method, one way to do that is to put  
a category on you super class with a method name that is unique that  
invokes the selector you want on super. If that sounds evil, that's  
because it is :). Calling super super is usually a hint that some  
refactoring would be a better choice. In this case you don't have a  
choice though since NSTextView isn't your class. NSTextView has you  
covered though.


You may not know this, but when you edit an NSTextField, you're  
actually typing into an NSTextView. So NSTextView already has all of  
the logic to "act like a text field". I believe the property that  
controlls this is 'isFieldEditor'. I don't have access to the  
reference docs right now to double check though.


Yet another possibility would be to ovveride insertTab: and  
insertBackTab: instead of keyDown:, however, I think toggling  
isFieldEditor is your best bet.


From my phone -
Jon Hess

On Aug 21, 2008, at 1:22 AM, Jerry Krinock <[EMAIL PROTECTED]> wrote:

When the 'tab' or 'backTab' key is pressed, NSTextView accepts it as  
a character to be typewritten.  But sometimes I want NSTextView to  
behave like an NSTextField, with 'tab' or 'backTab' selecting the  
next or previous key view.  So, in my NSTextView subclass, I over- 
ride -keyDown: and re-implement the next/previous view selection.


It works, but, besides being redundant code, this re-implementation  
seems like an evil assumption of some other class' behavior by my  
subclass.  What I really want to say is: "Behave like your  
'grandfather' class, NSView".  But there is no supersuper keyword.


Is there any way to improve this?.

- (void)keyDown:(NSEvent*)event {
   NSString *s = [event charactersIgnoringModifiers] ;
   unichar keyChar = 0 ;
   if ([s length] == 1) {
   keyChar = [s characterAtIndex:0] ;

   // Our superclass NSTextView accepts tabs and backtabs as text.
   // If we want _tabToNextKeyView, we re-implement the NSView  
behavior

   // of selecting the next or previous key view
   if ((keyChar == NSTabCharacter)&& _tabToNextKeyView) {
   [[self window] selectNextKeyView:self] ;
   }
   else if ((keyChar == NSBackTabCharacter) &&  
_tabToNextKeyView) {

   [[self window] selectPreviousKeyView:self] ;
   }
   else {
   // Handle using super's (i.e. NSTextView) - 
interpretKeyEvents:,

   // which will typewrite the key-downed character
   NSArray* events = [NSArray arrayWithObject:event] ;
   [self interpretKeyEvents:events] ;
   }
   }
}


___

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

Please do not post 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/jhess%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: Parse form values from HTTP POST

[Jonathan del Strother]

On Thu, Aug 21, 2008 at 9:17 AM, Thomas Engelmeier
<[EMAIL PROTECTED]> wrote:
>
> Am 20.08.2008 um 22:54 schrieb Jesse Grosjean:
>
>> Does anyone know what the best way to parse form values from and HTTP Post
>> is?
>>
>> I have a mini HTTP server in my app, and it needs to accept posts. I'm
>> using CFHTTP to implement the server, so I have a CFHTTPMessageRef. I'm
>> trying to figure out how to turn that into a dictionary of keys and values.
>> Is there an API that can do this, or any example code around?
>
> No solution (debugging POST packets sucks IMO...) but all the Web API hype
> is now with AJAX + REST, which uses HTTP GET + "everything is in the URI" -
> are you sure you need POST?
>

Eh?  REST uses both GET and POST (and tries really really hard to do
PUT & DELETE despite the crippled support for it).  POST is generally
used for carrying data to modify a resource - sticking all that in the
URI is a gross misuse of GET.
___

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

Please do not post 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: !foo vs foo == nil

[Thomas Engelmeier]

Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin:


Sometimes you see in source code something like this:
if( booleanVarOrExpression == YES )
(I think, Rentzsch does it that way, IIRC) and Ithink, that this is  
simply correct.


Oh, that is another discussion.
Bool != Boolean != bool, and sometimes that can introduce subtle  
errors if it's not only used to evaluate logical statements but by  
comparing values, especially to "YES", true and "TRUE".


In an large C++ Cross-Platform project I spotted some subtle problems,  
IIRC from assignment of an bool to an Boolean for an API that  
evaluated the values by comparison to "TRUE" or some code assigned it  
to ints, giving different values for true (1 vs. 0xFF vs. 0x).  
I don't know any more, fixed it, was glad my own coding practices  
don't leave room for that problems, moved on ;-)...


Regards,
Tom_E
___

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

Please do not post 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: !foo vs foo == nil

[James Montgomerie]

On 21 Aug 2008, at 09:06, Clark Cox wrote:

This is not a "hack" or a "coincidence", this is by design. A non-NULL
pointer *is* a boolean expression that evaluates to true, just as a
non-zero integer is. Again, it doesn't work by coincidence, it is a
guarantee of the language standard.


To go off on a bit of a tangent, if you read this without thinking of  
all the implications of other parts of the language you /can/ still  
run into problems.  For example:


BOOL b = (BOOL)v;

could leave you with b == NO even if v != 0.

If BOOL is a shorter type than value's type (e.g. if BOOL is char and  
v is long), and if the lower bits of v are all 0 but the higher bits  
are not, the higher bits will just get truncated off in the conversion.


i.e. this:

---

#include 

int main() {
int myFlags = 0x01000200;
int myBitMask = 0x0100;

BOOL isFlagSet = (BOOL)(myFlags & myBitMask);
if(isFlagSet == NO) {  // Could (of course) use "if(!isMasked)"  
here, I just used this for clarity

printf("Oh No!\n");
}
return 1;
}

---

gives:

---

Thing:tmp jamie$ gcc test.m -framework Foundation
Thing:tmp jamie$ ./a.out
Oh No!

---

This has puzzled me for a while in the past when I was wondering why  
my bit masks were not evaluating correctly.


Jamie.

___

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

Please do not post 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: !foo vs foo == nil

[Negm-Awad Amin]

Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier:



Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin:


Sometimes you see in source code something like this:
if( booleanVarOrExpression == YES )
(I think, Rentzsch does it that way, IIRC) and Ithink, that this is  
simply correct.


Oh, that is another discussion.

Yeah, but connected

It is antoher discussion in that way, that we have other types. (BOOL  
vs. type of logical expression in C)
It is the same discussion in that way, that most programmers make some  
assumptions about the value (and the casting).


(I bet, that 10 % believe, that the expression inside the if is typed  
BOOL)


Doing this is absolutly correct.
BOOL var = …; // Something evaluating to YES or NO
if( var == YES )

a simple

BOOL var = …; // Something evaluating to YES or NO
if( var )

is a very good hidden implicit cast from BOOL to logical expression.

However I use the simple condition (without == YES), too – for  
convenience.


BTW: This is an implicit cast, too:

BOOL var = a && b;

because the result of the right expression types to logical  
expression, not to BOOL.




Bool != Boolean != bool, and sometimes that can introduce subtle  
errors if it's not only used to evaluate logical statements but by  
comparing values, especially to "YES", true and "TRUE".

Yes, and some people do calculations with it

andExpression = a * b, // of course in a more subtle context
orExpression  = a + b; // argh …

In an large C++ Cross-Platform project I spotted some subtle  
problems, IIRC from assignment of an bool to an Boolean for an API  
that evaluated the values by comparison to "TRUE" or some code  
assigned it to ints, giving different values for true (1 vs. 0xFF  
vs. 0x). I don't know any more, fixed it, was glad my own  
coding practices don't leave room for that problems, moved on ;-)...

:-)




Regards,
Tom_E


LG

Amin Negm-Awad
[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: !foo vs foo == nil

[Thomas Engelmeier]

Am 21.08.2008 um 13:25 schrieb Chris Holloway:


If you look at section 7.17 of ISO/IEC 9899:1999, then it states that
NULL is a macro which "expands to an implementation-defined null
pointer constant". So, what is a null pointer constant? Section
6.3.2.3 states that "An integer constant expression with the value 0,
or such an expression cast to type void *, is called a null pointer
constant". So, in order for NULL to satisfy the requirement of being a
null pointer constant, it must be either 0 or (void *)0 (as Michael
stated), and hence (int)NULL is guaranteed to be 0.


What I meant was, as you noted correctly, that the memory pattern of  
an NULL pointer is not necessary sizeof( void * ) bytes containing  
0x00. Obviously I overlooked that the standard guarantees the  
conversion NULL => int results in 0 and vice versa.


Regards,
Tom_E

___

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

Please do not post 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: !foo vs foo == nil

[Sam Mo]

On Aug 21, 2008, at 4:47 AM, Thomas Engelmeier wrote:


Am 21.08.2008 um 05:03 schrieb Michael Ash:

There was a common perception that NULL is not really the same  
as nil. But

seems like in the end it really is (void*)0.


They differ in type, not in value.

"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.


This is true conceptually but not as far as their actual definition.
NULL can be either 0 or (void *)0.


Let's be a little bit more precise, I'll try to paraphrase  
correctly from my memory:


a.)
(int) NULL  is NOT required or guaranteed  0x0 by the standard.  
This is why one should never use

   if( anPtr == (void *) 0 );
instead of
   if( anPtr == NULL );
On modern machines, it usually is.


But Stroustrup says NULL is defined as 0 (zero) in C++.



With my C++ background, I normally write:

if (thePtr) {
  // do things
}
else {
  // error handling
}

Btw, I recall reading something in the PPC days that the expected  
case should put first so the compiler can optimize better (branch  
prediction?).


b.) At least the C++ standard mandates for type conversion of an  
pointer to an boolean, that e.g. ( !anPtr )  is equivalent  to ( ! 
(anPtr == NULL )). I didn't read the C99 spec but I'm sure there is  
something similar specified.


This implementation detail does probably not matter on most  
platforms today as even microcontrollers have AFAIK linear address  
spaces.
When I was writing my first C app on a DOS machine, there were  
segmented addresses. That meant  it could happen that


((somePtr + offset) - offset) == somePtr

evaluated to false - (somePtr + offset) changed the segment,  
anotherPtr - offset did not. Big debug surprise for poor little  
68020 fanboy ;-)


Regards,
Tom_E

___

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

Please do not post 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: !foo vs foo == nil

[Uli Kusterer]

On 21.08.2008, at 02:43, Torsten Curdt wrote:



On Aug 21, 2008, at 01:50, Ken Thomases wrote:


On Aug 20, 2008, at 6:15 PM, Torsten Curdt wrote:

I guess my questions wasn't phrased correctly. The point was more:  
is 'nil' really the equivalent of 0 or NULL.


Let's put it this way: freshly allocated objects have their memory  
zeroed out,


Why should that affect the pointer to an object?



 I think what he meant to say is that, since Apple guarantees stuff  
will be zeroed out, and much code already relies on ivars that have  
pointer types being nil, it's unlikely that NULL will not be binary- 
equivalent to one or more zeroes, because that would break pretty much  
all code.


Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de





___

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

Please do not post 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: !foo vs foo == nil

[Sam Mo]

On Aug 21, 2008, at 7:57 AM, Sam Mo wrote:


On Aug 21, 2008, at 4:47 AM, Thomas Engelmeier wrote:


Am 21.08.2008 um 05:03 schrieb Michael Ash:

There was a common perception that NULL is not really the same  
as nil. But

seems like in the end it really is (void*)0.


They differ in type, not in value.

"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.


This is true conceptually but not as far as their actual definition.
NULL can be either 0 or (void *)0.


Let's be a little bit more precise, I'll try to paraphrase  
correctly from my memory:


a.)
(int) NULL  is NOT required or guaranteed  0x0 by the standard.  
This is why one should never use

   if( anPtr == (void *) 0 );
instead of
   if( anPtr == NULL );
On modern machines, it usually is.


But Stroustrup says NULL is defined as 0 (zero) in C++.



With my C++ background, I normally write:

if (thePtr) {
  // do things
}
else {
  // error handling
}

Btw, I recall reading something in the PPC days that the expected  
case should put first so the compiler can optimize better (branch  
prediction?).


apparently this is also discussed in C-FAQ:




___

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

Please do not post 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: !foo vs foo == nil

[Uli Kusterer]

On 21.08.2008, at 06:10, mm w wrote:

great alignement



 Great mail client on your end, more likely. For me, the source code  
came across correctly indented.


 But honestly, isn't it a bit childish to complain about the  
alignment in a thread about something else?


Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de





___

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

Please do not post 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: Parse form values from HTTP POST

[Jesse Grosjean]

So now at least I have a more specific question. Is there any OS X  
framework for decoding x-www-form-urlencoded, or sample code  
floating around. I've found what I need in Java:


http://kickjava.com/src/java/net/URLDecoder.java.htm

And while it's not that much code, it seems like the kind of thing  
that must have been done before. Anyway I'll start on my own  
implementation, but if someone can point me to an existing solution  
for decoding x-www-form-urlencoded that would make my day :)


isn't that java code is just
[urlString  
stringByReplacingPercentEscapesUsingEncoding:encodingFromHTTPHeader 
]; ?


You are right... Thanks! I'd tried  
stringByReplacingPercentEscapesUsingEncoding first, but I think I  
might have been messing up the encoding somewhere else the process.  
And that lead me to believe that  
stringByReplacingPercentEscapesUsingEncoding wasn't going to work for  
what I needed. But after your message I went back to it, and got  
things to work. For future reference here's what I'm doing that seems  
to work:


- (NSData *)requestBody {
return [(id) CFHTTPMessageCopyBody(request) autorelease];
}

- (NSString *)requestBodyString {
	return [[[NSString alloc] initWithData:self.requestBody  
encoding:NSUTF8StringEncoding] autorelease];

}

- (NSDictionary *)requestBodyWWWFormURLDecoded {
NSMutableDictionary *results = [NSMutableDictionary dictionary];
	for (NSString *eachPair in [[self.requestBodyString  
stringByReplacingOccurrencesOfString:@"+" withString:@" "]  
componentsSeparatedByString:@"&"]) {

NSArray *eachPairArray = [eachPair 
componentsSeparatedByString:@"="];

if ([eachPairArray count] == 2) {
			[results setObject:[[eachPairArray objectAtIndex:1]  
stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding]  
forKey:[eachPairArray objectAtIndex:0]];

} else {
NSLog(@"Pair array without pair: %@", eachPairArray);
}
}   
return results;
}

And for more future reference this code isn't really complete, it's  
assuming UTF8, and doesn't handle multipart posts, but it works for my  
needs.


Thanks again.

Jesse

___

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

Please do not post 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: Design Question: Pro & Cons of KVC/KVO

[Oleg Krupnov]

>> I suspect that it could be way easier, when a property's value
>> changes, to just explicitly send a concise and clearly named message
>> to the subscribed objects,
>
> This is, what is done. The name of the message is
> -observeValueForKeyPath:ofObject:change:context:

Then how is it better than manual "glue code"?

> I think, you want to say, that if one changes a property, he sends a message
> to a central MVC server, which distributes update messages. Correct? Why?
>

No. Actually, the alternative approach that I kept in mind was that
each model object maintains an array of observers (like delegates or
just objects with a declared protocol) to all of which the
corresponding message is sent each time a property of the model object
changes.

For example,

id observer;
MyModelObject* myModelObject;
// subscribe observer
[myModelObject addObserver: observer];
// set some prop
[myModelObject setSomeProp:someValue];

@interface MyModelObject
{
  NSMutableArray* m_observers;
  id m_someProp;
}
@end

@implementation MyModelObject
- (void)addObserver:(id) observer
{
[m_observers addObject:observer];
}

- (void)setSomeProp:(id)newValue
{
// save new value
m_someProp = newValue;
// notify observers
id observer = nil;
for (observer in m_observers)
{
[observer somePropChanged];
}
}
@end

Is there something terribly wrong with this approach? The dependencies
are encapsulated. In addition, it seems that this approach gives me
more flexibility, say, if newValue is invalid, it can be rejected. Or,
for instance, when the entire MyModelObject gets removed from its
parent model object - in this case there is no property actually
modified, instead, a mutator message is received by the model, but the
observers still need to be notified. Can KVC/KVO monitor the contents
of an array of model objects? And so on. Even though KVC/KVO may
handle these cases too, my intuition tells me there can be cases when
the flexibility of KVC/KVO may run short compared to the manual code.

Anyway, even if I assume that KVC/KVO is at least not worse than
manual code, I don't see any real benefit so far. Except that it
allows me to get the scripting support "for free" (but I'd rather like
the scripting to be separate thing and not get in the way of the model
objects).

Could someone please try to explain me the rationale behind KVC/KVO
once again? :) Thanks
___

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

Please do not post 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: Sending a message to super's super (tab keyDown in NSTextView)

[Jerry Krinock]

On 2008 Aug, 21, at 2:07, Jon Hess wrote:

You may not know this, but when you edit an NSTextField, you're  
actually typing into an NSTextView. So NSTextView already has all of  
the logic to "act like a text field".


Of course I ^knew^ that, Jon.  I'd heard the teacher say it.  I just  
didn't ^know^ it because I hadn't done the homework :))


Indeed

NSText setFieldEditor:
Controls whether the receiver interprets Tab, Shift-Tab, and Return  
(Enter) as cues to end editing and possibly to change the first  
responder.


Yet another possibility would be to ovveride insertTab: and  
insertBackTab: instead of keyDown:, however, I think toggling  
isFieldEditor is your best bet.


Yes that would have been better too.


From my phone -


at 2:07.

Thank you, Jon.  Twenty-four lines of code, GONE!

___

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

Please do not post 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: Design Question: Pro & Cons of KVC/KVO

[Negm-Awad Amin]

Am Do,21.08.2008 um 15:22 schrieb Oleg Krupnov:


I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,


This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:change:context:


Then how is it better than manual "glue code"?

1. You do not have to manage a list of observes. this is done by cocoa.
2. cocoas implementation is faster than everything you would program.
3. Less Coding for you
4. Compliance with cocoa concepts

Enough?

I think, you want to say, that if one changes a property, he sends  
a message
to a central MVC server, which distributes update messages.  
Correct? Why?



No. Actually, the alternative approach that I kept in mind was that
each model object maintains an array of observers (like delegates or
just objects with a declared protocol) to all of which the
corresponding message is sent each time a property of the model object
changes.

Sounds like KVO.



For example,

id observer;
MyModelObject* myModelObject;
// subscribe observer
[myModelObject addObserver: observer];
// set some prop
[myModelObject setSomeProp:someValue];

@interface MyModelObject
{
 NSMutableArray* m_observers;
 id m_someProp;
}
@end

@implementation MyModelObject
- (void)addObserver:(id) observer
{
   [m_observers addObject:observer];
}

- (void)setSomeProp:(id)newValue
{
   // save new value
   m_someProp = newValue;
   // notify observers
   id observer = nil;
   for (observer in m_observers)
   {
   [observer somePropChanged];
   }
}
@end

Looks like a bad implementation oif KVO.

What is the advantage of reprogramming KVO?

Beside this: Do you want to use core data? What about core data  
properties?



Is there something terribly wrong with this approach?
There is nothing wrong in programming a new string class. But why  
don't you use NSString?



The dependencies
are encapsulated. In addition, it seems that this approach gives me
more flexibility, say, if newValue is invalid, it can be rejected.

Key value valdidation


Or,
for instance, when the entire MyModelObject gets removed from its
parent model object - in this case there is no property actually
modified, instead, a mutator message is received by the model, but the
observers still need to be notified. Can KVC/KVO monitor the contents
of an array of model objects?

Of course. Look at the array controller.


And so on. Even though KVC/KVO may
handle these cases too, my intuition tells me there can be cases when
the flexibility of KVC/KVO may run short compared to the manual code.
My intuition is, that you don't want to get deeper with KVO und KVC  
and are searching for reasons to reject it.



Anyway, even if I assume that KVC/KVO is at least not worse than
manual code, I don't see any real benefit so far. Except that it
allows me to get the scripting support "for free" (but I'd rather like
the scripting to be separate thing and not get in the way of the model
objects).

Could someone please try to explain me the rationale behind KVC/KVO
once again? :) Thanks

In five minutes?

You want to hold an oberserver list for every property and every  
object. This is done by KVO. And ist is done for KVC with Core Data.  
And it works with bindings. And it is implemented very good through  
isa-swizzling. And And And …


There is nothing wrong in writing a Cocoa II.

But: Why?


Cheers,

Amin Negm-Awad
[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: !foo vs foo == nil

[Michael Ash]

On Thu, Aug 21, 2008 at 6:47 AM, Negm-Awad Amin <[EMAIL PROTECTED]> wrote:
>
> Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier:
>
>>
>> Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin:
>>
>>> Sometimes you see in source code something like this:
>>> if( booleanVarOrExpression == YES )
>>> (I think, Rentzsch does it that way, IIRC) and Ithink, that this is
>>> simply correct.
>>
>> Oh, that is another discussion.
>
> Yeah, but connected
>
> It is antoher discussion in that way, that we have other types. (BOOL vs.
> type of logical expression in C)
> It is the same discussion in that way, that most programmers make some
> assumptions about the value (and the casting).
>
> (I bet, that 10 % believe, that the expression inside the if is typed BOOL)

I'd be very surprised at this, given that BOOL is found only in
Objective-C, and if statements are found in C.

> Doing this is absolutly correct.
> BOOL var = …; // Something evaluating to YES or NO
> if( var == YES )

It's "correct" in that it is a legal language construct and it has
well-defined results. But it is incorrect as far as doing what most
people would want it to do. Consider this:

BOOL var = 2;
if(var == YES)

That if statement will evaluate to false, even though the value of
"var" is conceptually true. ("True" in C meaning anything that is not
zero.) For this reason, I recommend never comparing with YES. If you
are mentally unable to simply write "if(var)", then I recommend using
"if(var != NO)". I consider any code that compares against YES as you
wrote to have a bug.

> a simple
>
> BOOL var = …; // Something evaluating to YES or NO
> if( var )
>
> is a very good hidden implicit cast from BOOL to logical expression.

There is no "hidden implicit cast". The if statement simply checks its
contents for truth or falseness, which is to say that it checks it for
zero or non-zero.

> However I use the simple condition (without == YES), too – for convenience.

Your code then has a bug, in my opinion, and this is likely to
manifest in ways extremely annoying and difficult to diagnose.

> BTW: This is an implicit cast, too:
>
> BOOL var = a && b;
>
> because the result of the right expression types to logical expression, not
> to BOOL.

No, the right side of the expression is typed *int*. There is no such
C type as "logical expression".

I recommend you learn more about the C language before you continue
any further, because you have a lot of misconceptions and many of them
are going to cause you to write bad code.

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: Sending a message to super's super (tab keyDown in NSTextView)

[Michael Ash]

On Thu, Aug 21, 2008 at 4:22 AM, Jerry Krinock <[EMAIL PROTECTED]> wrote:
> When the 'tab' or 'backTab' key is pressed, NSTextView accepts it as a
> character to be typewritten.  But sometimes I want NSTextView to behave like
> an NSTextField, with 'tab' or 'backTab' selecting the next or previous key
> view.  So, in my NSTextView subclass, I over-ride -keyDown: and re-implement
> the next/previous view selection.
>
> It works, but, besides being redundant code, this re-implementation seems
> like an evil assumption of some other class' behavior by my subclass.  What
> I really want to say is: "Behave like your 'grandfather' class, NSView".
>  But there is no supersuper keyword.

First, the grandfather class is not NSView, it is NSText.

Second, what makes you think that NSView's keyDown: implementation
performs this sort of tab selection that you think it does?

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]

Source List groups shifted down in NSOutlineView

[Jeff Wilcox]

I generally am pretty good at web mining or hacking solutions to weird  
cocoa things, but this one has me a bit puzzled.


I want to use groups in an NSOutlineView that is set up with Source  
List highlighting.  However, I am also using horizontal grid lines,  
and for some reason the drawing of the cell gets shifted down by a few  
points for groups which looks really bad relative to the horizontal  
grid lines.


Notes:
1. It doesn't happen for groups without Source List highlighting.
2. While the cell frame gets shifted, its not just the cell.  The  
background drawn with the highlighting gets the same shift down.

3. Its an absolute shift - independent of the row height.

Any ideas of how to get rid of this? 
___


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

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

Lenient NSNumberFormatters

[Frank Illenberger]

Hi there,

has anybody successfully used NSNumberFormatter's new setLenient:  
feature that was introduced with 10.5 together with one of the common  
number styles like currency or percent? As usual, I want the formatter  
to show a currency or percent symbol when turning numbers into strings  
but to be forgiving of omitted symbols when converting a user's string  
input into numbers.


The following code

NSNumberFormatter *percentFormatter = [[NSNumberFormatter alloc] init];
percentFormatter.formatterBehavior = NSNumberFormatterBehavior10_4;
percentFormatter.numberStyle = NSNumberFormatterPercentStyle;
[percentFormatter setLenient:YES];
NSLog(@"%@", [percentFormatter numberFromString:@"10"]);

outputs "(null)".  The same happens with the currency style.

Is there any way to get a lenient behavior from NSNumberFormatter  
without having to subclass it?


Cheers

 Frank


___

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

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

warning: initialization makes integer from pointer without a cast

[Stuart Green]

Hi,

I'm either overlooking something extremely simple here or I'm losing  
my mind.


I have two NSString objects in a NSDictionary object that I am passing  
to a class method in the form:


	(int)validateUsersFor:(NSString *)username withEmailAddress:(NSString  
*)email


Within the function, I need to convert the NSStrings back to C Strings  
(for a C API) so I'm using:


const char cUserName = [username UTF8String];
const char cEmail = [email UTF8String];

However, come the build, I get

warning: initialization makes integer from pointer without a cast

I thought I was doing everything right.  Any ideas?

Cheers,

Stu
___

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

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

Obtaining rotation from CTM

[Tilman Bender]

Hi there,

Is it possible to obtain the angle of rotation from a tranformation- 
matrix created with CGAffineTransfrom?


Background:
I am building a simple kitchen-timer app, that should work like the  
ones in your mom's kitchen:
You set the time by touching a control and rotating it. Now I would  
like to obtain  the current

angle of my clock.

I know how to use and create CGAffineTransform stuff, but I am not  
really familiar with the extraction of specific information from

such a matrix.

kind regards
Tilman Bender
___

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

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

CALayer retain count

[Shaun Larkin]

Why is it that when you set a CALayer property it's retain count increases  +1 ?

eg.

CALayer * testLayer = [[CALayer alloc] init];
NSLog(@"test layer retain count:: %i", [testLayer retainCount]);
testLayer.frame = CGRectMake(0, 0, 30, 30);
NSLog(@"test layer retain count:: %i", [testLayer retainCount]);

First log prints  test layer retain count:: 1
Second log prints test layer retain count:: 2


  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now at
http://ca.toolbar.yahoo.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: warning: initialization makes integer from pointer without a cast

[Dave DeLong]

Try putting an * after both uses of "char".

CStrings (char arrays) are char pointers.

Dave

On Thu, Aug 21, 2008 at 6:42 AM, Stuart Green <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm either overlooking something extremely simple here or I'm losing my
> mind.
>
> I have two NSString objects in a NSDictionary object that I am passing to a
> class method in the form:
>
>(int)validateUsersFor:(NSString *)username withEmailAddress:(NSString
> *)email
>
> Within the function, I need to convert the NSStrings back to C Strings (for
> a C API) so I'm using:
>
>const char cUserName = [username UTF8String];
>const char cEmail = [email UTF8String];
>
> However, come the build, I get
>
>warning: initialization makes integer from pointer without a cast
>
> I thought I was doing everything right.  Any ideas?
>
> Cheers,
>
> Stu
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post 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/davedelong%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: !foo vs foo == nil

[Negm-Awad Amin]

Am Do,21.08.2008 um 16:15 schrieb Michael Ash:

On Thu, Aug 21, 2008 at 6:47 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
> wrote:


Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier:



Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin:


Sometimes you see in source code something like this:
if( booleanVarOrExpression == YES )
(I think, Rentzsch does it that way, IIRC) and Ithink, that this is
simply correct.


Oh, that is another discussion.


Yeah, but connected

It is antoher discussion in that way, that we have other types.  
(BOOL vs.

type of logical expression in C)
It is the same discussion in that way, that most programmers make  
some

assumptions about the value (and the casting).

(I bet, that 10 % believe, that the expression inside the if is  
typed BOOL)


I'd be very surprised at this, given that BOOL is found only in
Objective-C, and if statements are found in C.

IIRC this depends on the concrete standard?


Doing this is absolutly correct.
BOOL var = …; // Something evaluating to YES or NO
if( var == YES )


It's "correct" in that it is a legal language construct and it has
well-defined results. But it is incorrect as far as doing what most
people would want it to do. Consider this:

BOOL var = 2;
If somebody wants to do this, he does something wrong. 2 is no valid  
assignment for a BOOL.




if(var == YES)

That if statement will evaluate to false, even though the value of
"var" is conceptually true.
There is no "conpetionally true". BOOL has the valid values YES and  
NO, not 2, not CONCEPTIONALLYYES.



("True" in C meaning anything that is not
zero.)
This is not a BOOL. *You* said, that there is no bool in C. An if  
takes no BOOL, but the type of an logical expression.



For this reason, I recommend never comparing with YES.
You should recommend, to assign never something else then YES or NO to  
a BOOL. *This* is wrong.



If you
are mentally unable to simply write "if(var)",

I'm not mentally unable to write that and I said, that I do that.
"However I use the simple condition (without == YES), too – for  
convenience."



then I recommend using
"if(var != NO)". I consider any code that compares against YES as you
wrote to have a bug.

No,
BOOL var = 2;
has a bug.


a simple

BOOL var = …; // Something evaluating to YES or NO
if( var )

is a very good hidden implicit cast from BOOL to logical expression.


There is no "hidden implicit cast". The if statement simply checks its
contents for truth or falseness,

No, it checks for == 0 or != 0.
BOOLs contain YES and NO.


which is to say that it checks it for
zero or non-zero.

Yup, and *not* for YES or NO

However I use the simple condition (without == YES), too – for  
convenience.

Your code then has a bug, in my opinion, and this is likely to
manifest in ways extremely annoying and difficult to diagnose.

No, your code has a bug:
BOOL var = 2;


BTW: This is an implicit cast, too:

BOOL var = a && b;

because the result of the right expression types to logical  
expression, not

to BOOL.

No, the right side of the expression is typed *int*.
There is no such
C type as "logical expression".
You cannot use it explicitly, but it is a construction of the  
language. The check of if is on == 0 or != 0. This is less then an int  
(or whatever you use) and something else than a BOOL.



I recommend you learn more about the C language before you continue
any further, because you have a lot of misconceptions and many of them
are going to cause you to write bad code.
I do not think so. But *I* would never assing 2 to a BOOL. And I'm  
sure doing so is a misconception.


Cheers,
Amin




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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[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: Design Question: Pro & Cons of KVC/KVO

[Oleg Krupnov]

Thanks Amin for responding.

You are correct that there's no need to reinvent the wheel, and that's
exactly what I'd like to avoid, that's why I am now re-reading about
KVC/KVO and reconsidering it.

So, does everybody really always use KVC/KVO for implementing MVC, in
all projects? Is this the recommended best practice?

BTW does anyone use Core Data? I've watched the video tutorial and it
looks like too much magic. I would never guess how to make Core Data
work for a drawing application like the Sketch. Is Core Data rather
for database+forms apps?

Thanks.
___

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

Please do not post 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: warning: initialization makes integer from pointer without a cast

[Simone Tellini]

Il giorno 21/ago/08, alle ore 15:42, Stuart Green ha scritto:


const char cUserName = [username UTF8String];
const char cEmail = [email UTF8String];

However, come the build, I get

warning: initialization makes integer from pointer without a cast

I thought I was doing everything right.  Any ideas?



const char *cUserName = [username UTF8String];

UTF8String returns a pointer to a string (char *), not a single byte  
(char)


--
Simone Tellini
http://tellini.info



___

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

Please do not post 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: !foo vs foo == nil

[Clark Cox]

On Thu, Aug 21, 2008 at 1:47 AM, Thomas Engelmeier
<[EMAIL PROTECTED]> wrote:
>
> Am 21.08.2008 um 05:03 schrieb Michael Ash:
>
 There was a common perception that NULL is not really the same as nil.
 But
 seems like in the end it really is (void*)0.
>>>
>>> They differ in type, not in value.
>>>
>>> "NULL" is (void *) 0.
>>> "nil" is (id) 0.
>>> "Nil" is (Class) 0.
>>
>> This is true conceptually but not as far as their actual definition.
>> NULL can be either 0 or (void *)0.
>
> Let's be a little bit more precise, I'll try to paraphrase correctly from my
> memory:
>
> a.)
> (int) NULL  is NOT required or guaranteed  0x0 by the standard. This is why
> one should never use
>   if( anPtr == (void *) 0 );
> instead of
>   if( anPtr == NULL );
> On modern machines, it usually is.

This is not true. Those two expressions are identical as far as C is
concerned, on any machine with a conforming C implementation (i.e.
(void*)0 and NULL are both valid null pointer constants.)

I think you are trying to say that the *representation* of a null
pointer needn't necessarily be all-bits-zero (i.e. you won't always
get a null pointer if you bzero/or memset it to zero). In that, you
are correct, but that is orthogonal to the discussion here (and there
is currently no C implementation with such null pointers that I know
of).

> b.) At least the C++ standard mandates for type conversion of an pointer to
> an boolean, that e.g. ( !anPtr )  is equivalent  to ( !(anPtr == NULL )).

I believe you mean that (!anPtr) is equivalent to (anPtr == NULL), in
which case, you are correct for C and C++.

> I didn't read the C99 spec but I'm sure there is something similar specified.
>
> This implementation detail

This is not an implementation detail, it is a guarantee of the
standards, and is essential to the C and C++ languages.

> does probably not matter on most platforms today
> as even microcontrollers have AFAIK linear address spaces.

The above is true on *any* C implementation, even those without a
linear address space.

> When I was writing my first C app on a DOS machine, there were segmented
> addresses. That meant  it could happen that
>
> ((somePtr + offset) - offset) == somePtr
>
> evaluated to false - (somePtr + offset) changed the segment, anotherPtr -
> offset did not. Big debug surprise for poor little 68020 fanboy ;-)

Indeed, but this is also a separate issue, even on DOS, (!anPtr) is
equivalent to (anPtr == NULL). Unless somePtr is a pointer to an array
or object that is at least (offset - 1) bytes in size, then ((somePtr
+ offset) - offset) causes undefined behavior on any platform (it just
dosen't usually manifest on platforms with a linear address space)

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

[moderator] Re: !foo vs foo == nil

[Scott Anguish]

mm w

The list isn't a quiz show.  If you have an answer, please provide it  
in full, perhaps with a bit of an explanation.


Otherwise you're risking moderation for offering little support (and  
lots of confusion)


scott
[moderator]


On 20-Aug-08, at 9:15 PM, mm w wrote:


anyway I m going to add a hint

as a previous oppenant said yeh dude it's normal it's undefined/  
nothin nada :)


int main(void) {g
 char *p1;
 char *p2 = NULL;

 if(!p1)
puts("hello p1");

 if(!p2)
puts("hello p2");

 return 0;
}

output "hello p2"

On Wed, Aug 20, 2008 at 6:00 PM, mm w <[EMAIL PROTECTED]> wrote:

ok Im like a puppy I like to play, I will stop to play the evil
advogate for 98% of cases

here my late Initialization:
we can say (!toto) is the same of toto == NULL

but the Douglas pointed something really interesting... let see ahead




On Wed, Aug 20, 2008 at 5:39 PM, Andrew Merenbach
<[EMAIL PROTECTED]> wrote:
With all due respect, this seems a little more confusing than  
enlightening.
Alignment has little to do with the question, as far as I can  
see.  Would
you be so kind as to explain what bearing your answer has on the  
original

poster's question?

-- Andrew

On Aug 20, 2008, at 3:29 PM, mm w wrote:


#include 
#include 

int main(void) {
char *p1;
char *p2 = NULL;

free(p1);

free(p2);

return 0;
}

if (toto)... just align your answer

On Wed, Aug 20, 2008 at 3:23 PM, Torsten Curdt <[EMAIL PROTECTED]>  
wrote:


This question has come up during the last CocoaHeads and no one  
was

really
able to give a definite answer.
Do both expressions really mean the same thing (as nil is not  
null)?


if (!foo) {
...
}

if (foo == nil) {
...
}

cheers
--
Torsten
___

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

Please do not post admin requests or moderator comments to the  
list.

Contact the moderators at cocoa-dev-admins(at)lists.apple.com

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

This email sent to [EMAIL PROTECTED]





--
-mmw
___

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

Please do not post 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/andrew.merenbach%40ucla.edu

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

This email sent to [EMAIL PROTECTED]





--
-mmw





--
-mmw
___

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

Please do not post 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/scott%40cocoadoc.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: How to enumerate directory contents?

[Paul Archibald]

I did something like this:

NSString *file;
// Get all of the files in the source directory, loop thru them.
	NSEnumerator *files = [[myFileMgr  
directoryContentsAtPath:srcDirectory] objectEnumerator];

while(file = [files nextObject] ) { 
if( [[file pathExtension] isEqualToString:interestingExtension] 
) {
// do something with file
}

}



Paul Archibald

"An ocean without its unnamed monsters
would be like a completely dreamless sleep."
— John Steinbeck





On Aug 19, 2008, at 10:06 PM, [EMAIL PROTECTED] wrote:


Re: How to enumerate directory contents?


___

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

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

[moderator] Re: !foo vs foo == nil

[Scott Anguish]

it appears that mm w has left the list in the middle of this thread.

I think it's quite safe to assume there was more than a little  
trolling on his part.


scott
[moderator]
___

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

Please do not post 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: Design Question: Pro & Cons of KVC/KVO

[Negm-Awad Amin]

Am Do,21.08.2008 um 16:41 schrieb Oleg Krupnov:


Thanks Amin for responding.

You are correct that there's no need to reinvent the wheel, and that's
exactly what I'd like to avoid, that's why I am now re-reading about
KVC/KVO and reconsidering it.

So, does everybody really always use KVC/KVO for implementing MVC, in
all projects?
There are some situation, where glue code is neccessary. Imagine a  
outline view that has a items lib and some groups, where you can place  
items from the lib and see them in the outline view by opening the  
isclosure. Or you have items from different entities there.


But even in this case it helps to use KVO on the parts to get  
synchronized.




Is this the recommended best practice?

BTW does anyone use Core Data?

You're joking?


I've watched the video tutorial and it
looks like too much magic. I would never guess how to make Core Data
work for a drawing application like the Sketch. Is Core Data rather
for database+forms apps?

1. Core data is not a database.
2. I think, that you are new to cocoa and a little bit afraid of the  
"magic" things. Hey, dive into it, read documentation, try a little  
bit coding and so on. There is no magic. It's just new land for you.






Thanks.


Cheers,
Amin Negm-Awad
[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: Design Question: Pro & Cons of KVC/KVO

[Oleg Krupnov]

Amin,

It is true that I am new to Cocoa, and although I find the
documentation really great and engaging, I have sort of difficulty
figuring out what technology is newer/more powerful/built on top of/
other technology.

In particular, would you explain me, in just two words, what are the
relations between and intended/typical applications of

(in the context of implementing the MVC pattern)

1) KVC/KVO
2) Bindings
3) Core Data
4) Anything else I may have overlooked?

If Core Data is really that cool, why don't one always use it instead
of KVC/KVO or maybe Bindings?

BTW I didn't say I thought Core Data was a database, I said it may be
intended rather for database apps.

Thanks again :)


On Thu, Aug 21, 2008 at 5:50 PM, Negm-Awad Amin <[EMAIL PROTECTED]> wrote:
>
> Am Do,21.08.2008 um 16:41 schrieb Oleg Krupnov:
>
>> Thanks Amin for responding.
>>
>> You are correct that there's no need to reinvent the wheel, and that's
>> exactly what I'd like to avoid, that's why I am now re-reading about
>> KVC/KVO and reconsidering it.
>>
>> So, does everybody really always use KVC/KVO for implementing MVC, in
>> all projects?
>
> There are some situation, where glue code is neccessary. Imagine a outline
> view that has a items lib and some groups, where you can place items from
> the lib and see them in the outline view by opening the isclosure. Or you
> have items from different entities there.
>
> But even in this case it helps to use KVO on the parts to get synchronized.
>
>
>> Is this the recommended best practice?
>>
>> BTW does anyone use Core Data?
>
> You're joking?
>
>> I've watched the video tutorial and it
>> looks like too much magic. I would never guess how to make Core Data
>> work for a drawing application like the Sketch. Is Core Data rather
>> for database+forms apps?
>
> 1. Core data is not a database.
> 2. I think, that you are new to cocoa and a little bit afraid of the "magic"
> things. Hey, dive into it, read documentation, try a little bit coding and
> so on. There is no magic. It's just new land for you.
>
>
>>
>>
>> Thanks.
>
> Cheers,
> Amin Negm-Awad
> [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: Design Question: Pro & Cons of KVC/KVO

[Kai]

Oleg,

by all means, go ahead with what you started and spend more time  
learning about KVC/KVO.


Yes, this is used in many many projects and I personally would really  
miss it if it wouldn’t be there. Actually, as you described yourself,  
if it wouldn’t be there, you’d had to brew something similar yourself.  
Which I did, coincidental, like 15 years ago under Mac OS 7 or so.  
Only that Apple can spend a lot more resources than you (I guess) or  
me (I’m sure) in making this "right". And they did.


Yes, it has a learning curve. And yes, it is sometimes unfortunate  
that the inner workings are a black box and can not be looked at with  
the debugger. Nevertheless, these are minor disadvantages in  
comparison to the whole thing.


Amin already mentioned all the advantages of KVC/KVO as provided by  
Apple, including the integration with other Cocoa technologies, which  
a home-brewn solution could never provide.


Concerning Core Data: it is equally great - inside its specs. Just  
take the build-in multi-level undo and redo support. Another great  
reason to use KVC/KVO, by the way: when Core Data undoes something,  
KVO is the way to get notified about these changes. Done consistently,  
this works simply beautiful.


And I wouldn’t restrict Core Data to database+forms apps. You can  
certainly use it for a drawing application. Whether it is the best  
solution for this kind of application depends - as always - on many  
details.


Hope this helps a little
Kai


On 21.8.2008, at 16:41, Oleg Krupnov wrote:


Thanks Amin for responding.

You are correct that there's no need to reinvent the wheel, and that's
exactly what I'd like to avoid, that's why I am now re-reading about
KVC/KVO and reconsidering it.

So, does everybody really always use KVC/KVO for implementing MVC, in
all projects? Is this the recommended best practice?

BTW does anyone use Core Data? I've watched the video tutorial and it
looks like too much magic. I would never guess how to make Core Data
work for a drawing application like the Sketch. Is Core Data rather
for database+forms apps?

Thanks.
___

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

Please do not post 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/kai%40granus.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: CALayer retain count

[Sherm Pendley]

On Thu, Aug 21, 2008 at 10:06 AM, Shaun Larkin <[EMAIL PROTECTED]> wrote:

> Why is it that when you set a CALayer property it's retain count increases  
> +1 ?

The obvious reason is that something else (i.e., not your code) is
retaining it. Standard memory management requires that "something
else" to match its retain with a release when its done with it, so
it's not something you need to worry about in your own code.

This is why it's a bad idea to examine retain counts - they're not a
good indicator of what *you* need to write and/or debug.

sherm--

-- 
Cocoa programming in Perl: http://camelbones.sourceforge.net
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Design Question: Pro & Cons of KVC/KVO

[Negm-Awad Amin]

Am Do,21.08.2008 um 17:03 schrieb Oleg Krupnov:


Amin,

It is true that I am new to Cocoa, and although I find the
documentation really great and engaging, I have sort of difficulty
figuring out what technology is newer/more powerful/built on top of/
other technology.

In particular, would you explain me, in just two words, what are the
relations between and intended/typical applications of

(in the context of implementing the MVC pattern)

1) KVC/KVO
KVC is a very old (10.0?) technique to set properties of an entity. In  
comparison with setters you can choose (change) the property at run- 
time without changing your code:


Entity* instance = …; // imagine this is set
[instance setProperty:value]; // you know that

You cannot change the name of the property without recompiling. This  
can be done with KVC:


NSString* key;
Entity* instance = …; // imagine this is set
key= @"property";
[instance setValue:value forKey:key];
key= @"another";
[instance setValue:value forKey:key];

Since key is a NSString constructed at run-time, you can change the  
property at run-time.


KVO is newer, I think 10.3 IIRC and something totally different: The  
core: You get a mesage, if you registered for a property of an  
instance, that changes. It's quite close to your code. There are  
differences between automatic and manual KVO, but this is the essence.




2) Bindings
Bindings use KVO to get synchronized and KVC for reading/writing data.  
You can imagine a binding a command to an object, to observe the given  
key of the given instance. So, hmmm, usually an object starts a KVO,  
when it becomes bound. Conceptionally:


- bind:(NSString*)boundPropertyKey toObject:(id)observed forKeyPath: 
(NSString*)observedProperty

   // start KVO
   [observed addObserver:self forKeyPath:observedProperty];

There are more features through binding options I omitted to clarify.

KVO, KVC, and Bindings are placed "between" the MVC-layers. They  
typically synchronize a controller to the model and a view to the  
controller. (Inside a layer you typically do not need KVO, KVC,  
because the objects inside the same layer know each other. But of  
course you can use KVO, KVC)



3) Core Data
Core data is not neccessarily related to KV*. It is simply a  
technology for your model to ease the boring work of defining entites,  
writing accessors, supporting serialization….


But core data is KVC- and KVO-compliant, that means, that you can set/ 
read properties to/from an core data entity and you're able to observe  
the properties. Short: You *can* use KV technologies with core data.


Using core data or not and using KV* or not is orthogonal.



4) Anything else I may have overlooked?

If Core Data is really that cool, why don't one always use it instead
of KVC/KVO or maybe Bindings?

See above. You do not use core data or KV*, but core data and KV*


BTW I didn't say I thought Core Data was a database, I said it may be
intended rather for database apps.

Okay :-)

The usage is quite simple (if I'm allowed to simplify that)

Without core data
In your model you have classes for entities, let's say Person,  
Department, Company, Account … These classes are typically subclsses  
of NSObject. So you have to define the ivars, write accessors (okay,  
Objctive-C 2 …), maybe support undoing, support serialization with  
NSCoding …


With core data
In many cases you do not need any subclass, but simply use  
NSManagedObject. The definition of the model can be done in the  
modeller very easy. Undoing, Coding and so on will work.


Cheers

Amin Negm-Awad
[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: CALayer retain count

[Shawn Erickson]

On Thu, Aug 21, 2008 at 7:06 AM, Shaun Larkin <[EMAIL PROTECTED]> wrote:
> Why is it that when you set a CALayer property it's retain count increases  
> +1 ?
>
> eg.
>
> CALayer * testLayer = [[CALayer alloc] init];
> NSLog(@"test layer retain count:: %i", [testLayer retainCount]);
> testLayer.frame = CGRectMake(0, 0, 30, 30);
> NSLog(@"test layer retain count:: %i", [testLayer retainCount]);
>
> First log prints  test layer retain count:: 1
> Second log prints test layer retain count:: 2

Why are you looking at retain counts? They will often mislead you
because of temporary retains that will be balanced at some point in
the future by a release messages (autorelease).

Note that testLayer.frame = ... is the same as [testLayer
setFrame:...] so the setFrame method is causing something to do a
retain/autorelease of testLayer. It is an implementation detail.

-Shawn
___

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

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

10.4+ NSNumberFormatter in IB3 question

[Sam Krishna]

Hi,

I'm trying to get the 10.4+ NSNumberFormatter to properly format a  
basic decimal input in a table view. For whatever reason, I keep  
getting either (1) an invalid format (which causes the formatter to  
refuse the input) or (2) a formatted input, but without the 3-digit  
grouping separators inserted (in this case, a comma: ",").


Is there some trick that I'm missing here?

(FYI: I'm using Aaron Hillegas' CarLot app as an example to make this  
work).


Live Playfully,

Sam
___

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

Please do not post 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: CALayer retain count

[Shaun Larkin]

thanks for the answer!

--- On Thu, 8/21/08, Shawn Erickson <[EMAIL PROTECTED]> wrote:

> From: Shawn Erickson <[EMAIL PROTECTED]>
> Subject: Re: CALayer retain count
> To: [EMAIL PROTECTED]
> Cc: Cocoa-dev@lists.apple.com
> Received: Thursday, August 21, 2008, 11:27 AM
> On Thu, Aug 21, 2008 at 7:06 AM, Shaun Larkin
> <[EMAIL PROTECTED]> wrote:
> > Why is it that when you set a CALayer property
> it's retain count increases  +1 ?
> >
> > eg.
> >
> > CALayer * testLayer = [[CALayer alloc] init];
> > NSLog(@"test layer retain count:: %i",
> [testLayer retainCount]);
> > testLayer.frame = CGRectMake(0, 0, 30, 30);
> > NSLog(@"test layer retain count:: %i",
> [testLayer retainCount]);
> >
> > First log prints  test layer retain count:: 1
> > Second log prints test layer retain count:: 2
> 
> Why are you looking at retain counts? They will often
> mislead you
> because of temporary retains that will be balanced at some
> point in
> the future by a release messages (autorelease).
> 
> Note that testLayer.frame = ... is the same as [testLayer
> setFrame:...] so the setFrame method is causing something
> to do a
> retain/autorelease of testLayer. It is an implementation
> detail.
> 
> -Shawn


  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now at
http://ca.toolbar.yahoo.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: !foo vs foo == nil

[Sean McBride]

On 8/21/08 10:15 AM, Michael Ash said:

>BOOL var = 2;
>if(var == YES)
>
>That if statement will evaluate to false, even though the value of
>"var" is conceptually true.

If only BOOL was bool we would not have this problem. :)

To the best of my knowledge, there is no compiler flag to catch
comparing a BOOL to YES.  Anyone know of a way?

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Source List groups shifted down in NSOutlineView

[Corbin Dunn]

On Aug 20, 2008, at 9:16 PM, Jeff Wilcox wrote:

I generally am pretty good at web mining or hacking solutions to  
weird cocoa things, but this one has me a bit puzzled.


I want to use groups in an NSOutlineView that is set up with Source  
List highlighting.  However, I am also using horizontal grid lines,  
and for some reason the drawing of the cell gets shifted down by a  
few points for groups which looks really bad relative to the  
horizontal grid lines.


Notes:
1. It doesn't happen for groups without Source List highlighting.
2. While the cell frame gets shifted, its not just the cell.  The  
background drawn with the highlighting gets the same shift down.

3. Its an absolute shift - independent of the row height.



The shift is to match the HI specification for how it should look.  
Using grid lines is not part of the source list look, so it was never  
designed to work well with it. You'll have to draw your own, in  
drawBackgroundInClipRect:


corbin




Any ideas of how to get rid of this? 
___


___

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

Please do not post 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: Obtaining rotation from CTM

[David Duncan]

On Aug 21, 2008, at 6:56 AM, Tilman Bender wrote:

Is it possible to obtain the angle of rotation from a tranformation- 
matrix created with CGAffineTransfrom?


If the CTM consists of only rotation and transform (or if it is scaled  
and you know the scale values) then it should be possible to reverse  
one. However...



Background:
I am building a simple kitchen-timer app, that should work like the  
ones in your mom's kitchen:
You set the time by touching a control and rotating it. Now I would  
like to obtain  the current

angle of my clock.

I know how to use and create CGAffineTransform stuff, but I am not  
really familiar with the extraction of specific information from

such a matrix.



I would highly recommend that you retain the rotation as part of your  
data model instead of trying to extract it from the CTM. Not only  
that, but if your concatenating lots of rotations to your transform  
matrix in order to do the rotation, then your losing precision that  
can eventually cause your transform to do very weird things, causing  
odd graphical glitches.

--
David Duncan
Apple DTS Animation and Printing

___

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

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

How to pause and resume an animation that uses a transform (CATransform3DMakeScale)?

[John Fox]

Hello:

I'm trying to pause, and then resume an animation that uses a  
CATransform3D to set animate the zoom level of a layer. I want to be  
able to pause the animation, but I can't figure out how to determine  
the current scale factor of the layer at the time when the animation  
is paused (using removeAllAnimations on the layer).


Here's how I'm creating the animation in question:

	CATransform3D myTransform = CATransform3DMakeScale(aScaleFactor,  
aScaleFactor, 1.0f);

CABasicAnimation *myTransformAnimation;

	myTransformAnimation = [CABasicAnimation  
animationWithKeyPath:@"transform"];
	myTransformAnimation.toValue = [NSValue  
valueWithCATransform3D:myTransform];


CABasicAnimation *myAnchorPointAnimation;

	myAnchorPointAnimation = [CABasicAnimation  
animationWithKeyPath:@"anchorPoint"];
	myAnchorPointAnimation.toValue = [NSValue valueWithPoint:NSMakePoint(. 
5, .5)];


CAAnimationGroup *group = [CAAnimationGroup animation];

	group.animations = [NSArray arrayWithObjects:myAnchorPointAnimation,  
myTransformAnimation, nil];


group.duration = aDuration;
group.repeatCount = 0;
	group.timingFunction = [CAMediaTimingFunction  
functionWithName:kCAMediaTimingFunctionEaseInEaseOut];

group.fillMode = kCAFillModeForwards;
group.removedOnCompletion = NO;

What I've tried so far is to look at at the layer's transform  
property, then getting the appropriate value from the CATransform3D  
struct. However, from what I can see by logging one of the struct's  
value (specifically m11), what you get are the values that make up the  
toValue in my animation, not the current value at the point in time in  
the animation when the pause happens.


The only other discussion on pausing an animation came from this thread:

http://www.cocoabuilder.com/archive/message/cocoa/2007/12/4/194458

...and it didn't quite apply. If someone has any guidance, I'd really  
appreciate it.


Best,

John
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Obtaining rotation from CTM

[Nathan Vander Wilt]

On Aug 21, 2008, at 6:56 AM, Tilman Bender wrote:


Hi there,

Is it possible to obtain the angle of rotation from a tranformation- 
matrix created with CGAffineTransfrom?



If you haven't applied any other transforms to your CGAffineTransform,  
you could determine the rotation (in radians) via:


double rotationInRadians = acos(theTransform.a);	// if the transform  
ONLY rotates around the origin


My linear algebra is fairly rusty, so I may be forgetting some things,  
but I don't think it's practical to determine in the general case   
when you've also scaled and translated back and forth besides just  
rotating. A few cases will not affect the result above, but in most  
cases used in drawing, the above will probably not work. But I'm not  
sure why you'd need to do this in the first place, see below...




Background:
I am building a simple kitchen-timer app, that should work like the  
ones in your mom's kitchen:
You set the time by touching a control and rotating it. Now I would  
like to obtain  the current

angle of my clock.

I know how to use and create CGAffineTransform stuff, but I am not  
really familiar with the extraction of specific information from

such a matrix.



My question is: why do you need to get the rotation out of an affine  
transform?


Somewhere in your code you've determined an angle from a move event, I  
would assume. It would make a lot more sense to keep track of the  
current angle, and only convert that to a CGAffineTransform in your  
drawing code, than to for some reason store a CGAffineTransform and  
try to extract the angle from that.


hope this helps,
-natevw
___

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

Please do not post 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: Sending a message to super's super (tab keyDown in NSTextView)

[Douglas Davidson]

On Aug 21, 2008, at 1:22 AM, Jerry Krinock wrote:

When the 'tab' or 'backTab' key is pressed, NSTextView accepts it as  
a character to be typewritten.  But sometimes I want NSTextView to  
behave like an NSTextField, with 'tab' or 'backTab' selecting the  
next or previous key view.  So, in my NSTextView subclass, I over- 
ride -keyDown: and re-implement the next/previous view selection.


You really don't want to do this.  You've just broken any input method  
that uses tab or backtab.  I've posted about this many times before-- 
take a look at the list archives.


If you want NSTextView to behave like a text field with regard to tabs  
and returns, call setFieldEditor:YES on it.  If you need some  
different behavior for individual keys, use the delegate method  
textView:doCommandBySelector: or subclass and override  
doCommandBySelector:.


Douglas Davidson

___

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

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

[Q] SFPreferenceView and authorize as admin?

[JongAm Park]

I don't think it is not possible.. but.. does anyone know how to?

Thank you.

 Original Message 
Subject:[Q] SFPreferenceView and authorize as admin?
Date:   Wed, 20 Aug 2008 14:53:34 -0700
From:   JongAm Park <[EMAIL PROTECTED]>
To: cocoa-dev 



Hello, all.

Does any of you know how to authorize a user as an admin user using the 
SFPreferenceView?


I'm writing a preference pane for the System Preference.
What this custom preference pane does are :

- Display system wide setting, but until a user clicks the "lock" icon, 
a user is not allowed to change it.
 When the user clicks the "lock" icon, it asks ID and password. ( This 
is done by the SFPreferenceView. )


- Display user-specific setting and allows changing them

- When the user choose other preference pane, it saves the system-wide 
setting and the user-specific setting.



To save the system-wide setting, I used :

   CFPreferenceSetValue( CFSTR("System Name", [systemNameField
   stringValue], kAppID, kCFPreferencesAnyUser, kCFPreferencesAnyHost );

   isSuccessful = CFPreferencesSynchronize( kAppID,
   kCFPreferencesAnyUser, kCFPreferencesAnyHost );


Currently the SFPreferenceView is initialized like :

   [authView setDelegate:self];
   [authView setString:appID_UTF8_CString];
   [authView updateStatus:self];
   [authView setEnabled:YES];


For being sure, I also obtain the authorization from the authView and 
tried setting kAuthorizationRuleAuthenticateAsAdmin.


   SFAuthorization *authorization = [authView authorization];
   AuthorizationRef authRef = [authorization authorizationRef];
   AuthorizationRights *authRights = [authView authorizationRights];

   CFStringRef keys[2] = { CFSTR(kAuthorizationRightRuel),
   CFSTR(kAuthorizationComment)};
   CFStringRef values[2] = {
   CFSTR(kAuthorizationRuleAuthenticateAsAdmin), CFSTR("Authorize as
   Admin") };

   CFDictionaryRef dictRef = CFDictionaryCreate( NULL, (void *)keys,
   (void *)values, 2, &kCFCopyStringDictionaryKeyCallBacks,
   &kCFTypeDictionaryValueCallBacks);

   // To modify the authorization of the authView, the authRef is used.
   result = AuthorizationRightSet( authRef, authRights->items[0].name,
   dictRef, CFSTR("Authorize as an admin"), NULL, NULL );


Although it returns 1 for the isSuccessful, it doesn't create a plist 
file in /Library/Preferences directory for the system-wide setting.


Can anyone help me?

Thank 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: How to enumerate directory contents?

[Sean McBride]

On 8/21/08 7:46 AM, Paul Archibald said:

>   NSString *file;
>   // Get all of the files in the source directory, loop thru them.
>   NSEnumerator *files = [[myFileMgr
>directoryContentsAtPath:srcDirectory] objectEnumerator];
>   while(file = [files nextObject] ) { 
>   if( [[file pathExtension] isEqualToString:interestingExtension] 
> ) {
>   // do something with file
>   }

You might want to read the docs for "isEqualToString".  Using it to
compare file extensions will not behave as the user expects (case
sensitivity, Unicode decomposition, etc.)

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: NSWindowController, owner, "primary window"...

[Gerd Knops]

On Aug 20, 2008, at 11:10 PM, Graham Cox wrote:



On 21 Aug 2008, at 5:13 am, Gerd Knops wrote:

That'd work, but I'd have to subclass NSWindowController for that  
so I can add that property. Seemed to me that the above would not  
be an uncommon pattern and there ought to be a more elegant way  
that I might have missed.



Yep, that's the usual approach. What's the problem with subclassing?  
An unsubclassed NSWindowController isn't really all that useful. Why  
is subclassing so often referred to as "inelegant"? That's what OOP  
is for.


No problem with subclassing. It was just the presence of the '- 
initWithWindowNibName:owner:' method that tripped me off a little, as  
it seems near useless unless there is some undocumented magic behind it.


Gerd

___

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

Please do not post 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: How to enumerate directory contents?

[Paul Archibald]

You make a valid point. I think I will make that change.

This is not really what we actually do. I cut out most of the real  
code to keep the example simple. The actual files we are looking for  
are machine generated, and the user is not really involved in the  
process at this point.


Paul


On Aug 21, 2008, at 9:49 AM, Sean McBride wrote:


On 8/21/08 7:46 AM, Paul Archibald said:


NSString *file;
// Get all of the files in the source directory, loop thru them.
NSEnumerator *files = [[myFileMgr
directoryContentsAtPath:srcDirectory] objectEnumerator];
while(file = [files nextObject] ) { 
if( [[file pathExtension] isEqualToString:interestingExtension] 
) {
// do something with file
}


You might want to read the docs for "isEqualToString".  Using it to
compare file extensions will not behave as the user expects (case
sensitivity, Unicode decomposition, etc.)

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada





___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: !foo vs foo == nil

[Scott Ribe]

Wow, don't check the list for a few days and look what happens!

> After all, that's why nil (and Nil) exist at all,
> rather than just reusing NULL.

Actually nil exists at all because Objective-C was created *before* NULL was
in such standard use! (It may have always been part of stdio.h, don't recall
for sure, but there definitely was no stddef.h.) Way back when, everybody
defined their own macro, and some libraries even called it NIL or nil or
null instead of NULL. (Others simply used 0.)

> I finally discovered
> that one of the headers in this old cross-platform code had defined
> NULL to be 0, just a plain integer 0, rather than (void *)0.

Yes, that is allowed. In fact, Stroustrup suggests that it is preferred for
C++, because stricter type checking makes ((void*)0) much less useful... GCC
(actually g++) gets around this by providing __null, which is a magic token
that gets special treatment from the compiler. If you look at stddef.h
and/or _types.h, you'll see a special case for __GNUG__ (GNU C++) that
defines NULL to be __null.

> It is a little known fact that when passing NULL (and by extension nil
> or Nil) as a parameter to a vararg function, you *must* cast it to the
> appropriate pointer type to guarantee correct behavior.

2 reasons: 1) integer & pointer sizes may not be the same, this is the
common case, and is cured by defining NULL as ((void*)0) and nil as ((id)0)
instead of just 0, and is why Apple gets away with this usage, and I suspect
the g++ magic __null takes care of this as well; 2) The standard actually
allows different types of pointers to have different sizes, which I think is
very rare, and certainly not the case on any architectures on which Cocoa
does (or ever did) run--or any that I've ever worked with.

> Boolean negating a
> pointer is a hack that by happy coincidence works.

No it is not; it is an explicitly designed and required feature of the
language.

> a.)
> (int) NULL  is NOT required or guaranteed  0x0 by the standard.

Yes, it is.

> Obviously I overlooked that the standard guarantees the
> conversion NULL => int results in 0 and vice versa.

OK, close but not quite. The standard says that NULL is 0, and that all
pointer <-> int conversions take care of mapping the machine's null address
to the integer 0, if necessary.

 
-- 
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: NSWindowController, owner, "primary window"...

[Negm-Awad Amin]

Am Do,21.08.2008 um 06:10 schrieb Graham Cox:



On 21 Aug 2008, at 5:13 am, Gerd Knops wrote:

That'd work, but I'd have to subclass NSWindowController for that  
so I can add that property. Seemed to me that the above would not  
be an uncommon pattern and there ought to be a more elegant way  
that I might have missed.



Yep, that's the usual approach. What's the problem with subclassing?  
An unsubclassed NSWindowController isn't really all that useful. Why  
is subclassing so often referred to as "inelegant"?
Probably because the GoF prefers combination over (?) subclassing.  
Subclassing always discloses parts of the implementation of a class.  
("white-boxing") So generally it is a good idea, to look for  
alternatives for subclassing, esp. delegates.


But, of course, sometimes a subclass is simply the right thing.


That's what OOP is for.
Not all OOP languages use classes. I. e. look at SELF, a prototype- 
based language.


But Objective-C is a class-based language, yup.


Cheers,
Amin






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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[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: NSWindowController, owner, "primary window"...

[j o a r]

On Aug 21, 2008, at 10:12 AM, Negm-Awad Amin wrote:

Probably because the GoF prefers combination over (?) subclassing.  
Subclassing always discloses parts of the implementation of a class.  
("white-boxing") So generally it is a good idea, to look for  
alternatives for subclassing, esp. delegates.



You are right in that Cocoa programmers often look to other design  
patterns before choosing to subclass one of the framework provided  
classes. That said, NSWindowController is one of the classes in Cocoa  
designed and intended to be subclassed, so that's not a consideration  
in this particular case.


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]

Re: NSWindowController, owner, "primary window"...

[Negm-Awad Amin]

Am Do,21.08.2008 um 19:24 schrieb j o a r:



On Aug 21, 2008, at 10:12 AM, Negm-Awad Amin wrote:

Probably because the GoF prefers combination over (?) subclassing.  
Subclassing always discloses parts of the implementation of a  
class. ("white-boxing") So generally it is a good idea, to look for  
alternatives for subclassing, esp. delegates.



You are right in that Cocoa programmers often look to other design  
patterns before choosing to subclass one of the framework provided  
classes. That said, NSWindowController is one of the classes in  
Cocoa designed and intended to be subclassed, so that's not a  
consideration in this particular case.


j o a r



Yup, this was the reason for me to write:
"But, of course, sometimes a subclass is simply the right thing."

Cheers,

Amin Negm-Awad
[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: [Q] SFPreferenceView and authorize as admin?

[Jean-Daniel Dupas]

Most of the authorizations question on this list have the same answer.
It's not and will never be possible to increase the rights of a  
running process (for obvious security reasons). System Preferences  
(your host process) run as the current user, so it cannot access  
protected locations.


Have a look at “Performing Privileged Operations With Authorization  
Services" to find a way to do what you want.


http://developer.apple.com/documentation/Security/Conceptual/authorization_concepts/01introduction/chapter_1_section_1.html



Le 21 août 08 à 18:35, JongAm Park a écrit :


I don't think it is not possible.. but.. does anyone know how to?

Thank you.

 Original Message 
Subject:[Q] SFPreferenceView and authorize as admin?
Date:   Wed, 20 Aug 2008 14:53:34 -0700
From:   JongAm Park <[EMAIL PROTECTED]>
To: cocoa-dev 



Hello, all.

Does any of you know how to authorize a user as an admin user using  
the SFPreferenceView?


I'm writing a preference pane for the System Preference.
What this custom preference pane does are :

- Display system wide setting, but until a user clicks the "lock"  
icon, a user is not allowed to change it.
When the user clicks the "lock" icon, it asks ID and password.  
( This is done by the SFPreferenceView. )


- Display user-specific setting and allows changing them

- When the user choose other preference pane, it saves the system- 
wide setting and the user-specific setting.



To save the system-wide setting, I used :

  CFPreferenceSetValue( CFSTR("System Name", [systemNameField
  stringValue], kAppID, kCFPreferencesAnyUser,  
kCFPreferencesAnyHost );


  isSuccessful = CFPreferencesSynchronize( kAppID,
  kCFPreferencesAnyUser, kCFPreferencesAnyHost );


Currently the SFPreferenceView is initialized like :

  [authView setDelegate:self];
  [authView setString:appID_UTF8_CString];
  [authView updateStatus:self];
  [authView setEnabled:YES];


For being sure, I also obtain the authorization from the authView  
and tried setting kAuthorizationRuleAuthenticateAsAdmin.


  SFAuthorization *authorization = [authView authorization];
  AuthorizationRef authRef = [authorization authorizationRef];
  AuthorizationRights *authRights = [authView authorizationRights];

  CFStringRef keys[2] = { CFSTR(kAuthorizationRightRuel),
  CFSTR(kAuthorizationComment)};
  CFStringRef values[2] = {
  CFSTR(kAuthorizationRuleAuthenticateAsAdmin), CFSTR("Authorize as
  Admin") };

  CFDictionaryRef dictRef = CFDictionaryCreate( NULL, (void *)keys,
  (void *)values, 2, &kCFCopyStringDictionaryKeyCallBacks,
  &kCFTypeDictionaryValueCallBacks);

  // To modify the authorization of the authView, the authRef is used.
  result = AuthorizationRightSet( authRef, authRights->items[0].name,
  dictRef, CFSTR("Authorize as an admin"), NULL, NULL );


Although it returns 1 for the isSuccessful, it doesn't create a  
plist file in /Library/Preferences directory for the system-wide  
setting.


Can anyone help me?

Thank 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/devlists%40shadowlab.org

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: !foo vs foo == nil

[Michael Ash]

On Thu, Aug 21, 2008 at 10:40 AM, Negm-Awad Amin <[EMAIL PROTECTED]> wrote:
>
> Am Do,21.08.2008 um 16:15 schrieb Michael Ash:
>
>> On Thu, Aug 21, 2008 at 6:47 AM, Negm-Awad Amin <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier:
>>>

 Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin:

> Sometimes you see in source code something like this:
> if( booleanVarOrExpression == YES )
> (I think, Rentzsch does it that way, IIRC) and Ithink, that this is
> simply correct.

 Oh, that is another discussion.
>>>
>>> Yeah, but connected
>>>
>>> It is antoher discussion in that way, that we have other types. (BOOL vs.
>>> type of logical expression in C)
>>> It is the same discussion in that way, that most programmers make some
>>> assumptions about the value (and the casting).
>>>
>>> (I bet, that 10 % believe, that the expression inside the if is typed
>>> BOOL)
>>
>> I'd be very surprised at this, given that BOOL is found only in
>> Objective-C, and if statements are found in C.
>
> IIRC this depends on the concrete standard?

No, it does not. Objective-C does not have a standard, and no C
standard includes BOOL.

>>> Doing this is absolutly correct.
>>> BOOL var = …; // Something evaluating to YES or NO
>>> if( var == YES )
>>
>> It's "correct" in that it is a legal language construct and it has
>> well-defined results. But it is incorrect as far as doing what most
>> people would want it to do. Consider this:
>>
>> BOOL var = 2;
>
> If somebody wants to do this, he does something wrong. 2 is no valid
> assignment for a BOOL.

Of course it's valid:

typedef signed char BOOL;

The C standard guarantees that a signed char can hold at least values
in the range of -127 to 127. Depending on the implementation, it may
be abel to hold more. Thus any number in that range is a valid value
for a variable of type BOOL.

>> if(var == YES)
>>
>> That if statement will evaluate to false, even though the value of
>> "var" is conceptually true.
>
> There is no "conpetionally true". BOOL has the valid values YES and NO, not
> 2, not CONCEPTIONALLYYES.

No, BOOL has the valid values -127 through 127, and possibly more. In
the C language, all non-zero values are "true".

>> ("True" in C meaning anything that is not
>> zero.)
>
> This is not a BOOL. *You* said, that there is no bool in C.

No, I said that there is no BOOL in C. Of course it is also true that
there is no bool in C. And it's true. But C does have the concept of
logical truth and falsehood, it's just not expressed by means of a
boolean type, or boolean values.

> An if takes no
> BOOL, but the type of an logical expression.

There is no such thing in the C language as "type of an logical
expression". So I really can't tell what you're trying to say here,
except that it must be wrong, because no such type exists.

The if statement in C takes any scalar type as its conditional expression.

>> For this reason, I recommend never comparing with YES.
>
> You should recommend, to assign never something else then YES or NO to a
> BOOL. *This* is wrong.

Yes, I *also* recommend this. The two recommendations are not mutually
exclusive. You should *never* assign anything besides YES or NO to
your BOOL variables, and you should *never* compare any BOOL variable
with YES.

If you think that only one of these suggestions is sufficient,
consider that Cocoa could easily return 2 from the -isEqual: method,
for example.

>>> a simple
>>>
>>> BOOL var = …; // Something evaluating to YES or NO
>>> if( var )
>>>
>>> is a very good hidden implicit cast from BOOL to logical expression.
>>
>> There is no "hidden implicit cast". The if statement simply checks its
>> contents for truth or falseness,
>
> No, it checks for == 0 or != 0.

That's what I said. "Truth" in C is defined as != 0. "Falseness" is
defined as == 0.

> BOOLs contain YES and NO.

And any other value in the range of -127 to 127.

>>> BTW: This is an implicit cast, too:
>>>
>>> BOOL var = a && b;
>>>
>>> because the result of the right expression types to logical expression,
>>> not
>>> to BOOL.
>>
>> No, the right side of the expression is typed *int*.
>> There is no such
>> C type as "logical expression".
>
> You cannot use it explicitly, but it is a construction of the language. The
> check of if is on == 0 or != 0. This is less then an int (or whatever you
> use) and something else than a BOOL.

No, there is no such construction of the language. The C if statement
simply checks for equality to zero, period, full stop. There is no
such concept as "logical expression".

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 PROTECTE

Re: Design Question: Pro & Cons of KVC/KVO

[Erik Buck]

I love answering questions that require an essay.  So – here is my essay.
  I think my forthcoming “Cocoa Design Patterns” book does a good job of 
explaining the patterns used to implement Cocoa and reused to implement Cocoa 
applications.  In particular, the book explains how techniques like Key Value 
Coding, Key Value Observing, and Core Data are used within the overarching 
Model View Controller design.  However, Key Value Coding and Key Value 
Observing and Core Data are “high level” and “advanced” in part because they 
are all built upon lower level design patterns.  Some people struggle with the 
basic concepts employed by high level patterns because the lower level patterns 
are unfamiliar.  Other people struggle with the lower level patterns because 
they don’t see the utility of the patterns until they see the high level uses.
   
  KVC
  Key Value Coding (KVC) is an implementation of the “Associative Storage 
Pattern”.  All that means is that you are able to look-up values based on keys 
(like the way you use NSDictionary).  KVC formalizes the idea that every object 
can be used like a dictionary.  NSDictionary provides the objectForKey: and 
setObject:forKey: methods.  KVC extends the NSObject base class to include the 
valueForKey: and setValue:forKey: methods.  
  If you follow recommended naming conventions for instance variables and/or 
“Accessor” methods, the built-in KVC NSObject versions of valueForKey: and 
setValue:forKey: access you “properties” in the form of instance variables or 
accessor methods automatically.  I use the term “property” because the trick to 
KVC is that objects represent/store properties in many different ways.  Some 
properties are stored in correctly named instance variables.  Other properties 
are stored in NSDictionary instances.  Some properties may be calculated on 
demand and not stored anywhere.  And some properties might be dynamically 
loaded as needed from an underlying persistent storage like a database or flat 
file or URL, etc.)
  So, in summary, the whole point of KVC is to standardize the way an object’s 
properties are accessed regardless of how they are stored.  KVC also provides 
support (hooks) for change management so that any change to a property can have 
application defined side effects like registering an undo event or validating 
the change.  KVC provides a way to gracefully handle the situation when a 
requested property is not available.  KVC supports properties that are actually 
collections like arrays or sets or any other data structure you want within 
reason.
   
  KVO
  Key Value Observing takes advantage of the change management hooks provided 
by Key Value Coding in order to notify other interested objects whenever an 
observed property changes.  Interested objects register the fact that they are 
interested.  KVO is just another implementation of the “Notification” pattern 
also known as the “Observer” pattern in other frameworks.  KVO exists so that 
you don’t have to manually send notifications every time a “property” changes.  
This is particularly important because the notification approach only works 
well when it is ubiquitous.  When manually sending notifications, it’s too easy 
to forget to send them in a few places and thus greatly degrade the benefits. 
  KVO is also the basis of “Bindings”.  I would go so far as to say “Bindings” 
are just a way to specify which objects observe which properties in which other 
objects using Interface Builder instead of writing code to register all those 
notification observers.
  Although KVO is “built upon KVC”, KVO really only needs change notifications. 
 So, if you provide the change notifications, KVO will work even if you don’t 
really use KVC.  But why not use KVC ?
   
  Core Data
  Core Data is a technology for efficiently storing and accessing a graph data 
structure of interrelated objects.  Efficiency includes memory efficiency as 
well as persistent storage efficiency.  You provide Core Data with information 
about the objects you plan to store.  You tell Core Data what properties your 
objects have and what constraints and/or initial values the properties have.  
You tell Core Data about the inter-relationships between your objects.  As a 
result, Core Data can validate the correctness of changes to properties and to 
relationships between objects.
  Core Data uses Key Value Coding.  This allows you to access the properties of 
Core Data objects just like any other objects.  This allows Core Data to delay 
actually loading the values of properties until you ask for the values.  This 
allows Core Data to register undo events each time you change an object’s 
properties or relationships.
  If you know XML, you might want to think of Core Data as the combination of a 
Data Type Definition and the stored data.  Core Data uses the Data Type 
Definition to validate changes made to the data.
  Why use Core Data ?  Use Core data If you want a flexible high performance 
self va

Re: Modifying TextEdit.app

[R.L. Grigg]

On Aug 20, 2008, at 10:22 AM, Sherm Pendley wrote:


On Wed, Aug 20, 2008 at 12:13 PM, R.L. Grigg
<[EMAIL PROTECTED]> wrote:


Now I want to modify TextEdit so I can display the filenames full  
path in

the title bar of the document window instead of just the filename.ext
(because sometimes I have more than 1 version of a file up and its  
easy to

forget which one is which).


Coding issues aside... You *do* know about cmd-clicking the document
name in the title bar, right? :-)


Yes, that's a cool feature. But if I have three versions of  
AppController.m up at once, it would be great to be reminded -- at a  
glance -- which one is which, especially since I get so many  
interruptions. So if the path was on the title bar, that'd be cool.  
But I guess it's not so easy to change TextEdit to do this.


Russ

___

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

Please do not post 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: How to pause and resume an animation that uses a transform (CATransform3DMakeScale)?

[Bill Dudney]

Hi John,

Try the layer's presentationLayer property. The presentationLayer is  
the thing that is actually moving around and you should be able to get  
'current' values from it (give or take a bit).


HTH,

-bd-
http://bill.dudney.net/roller/objc
http://www.pragprog.com/titles/bdcora


On Aug 21, 2008, at 9:54 AM, John Fox wrote:


Hello:

I'm trying to pause, and then resume an animation that uses a  
CATransform3D to set animate the zoom level of a layer. I want to be  
able to pause the animation, but I can't figure out how to determine  
the current scale factor of the layer at the time when the animation  
is paused (using removeAllAnimations on the layer).


Here's how I'm creating the animation in question:

	CATransform3D myTransform = CATransform3DMakeScale(aScaleFactor,  
aScaleFactor, 1.0f);

CABasicAnimation *myTransformAnimation;

	myTransformAnimation = [CABasicAnimation  
animationWithKeyPath:@"transform"];
	myTransformAnimation.toValue = [NSValue  
valueWithCATransform3D:myTransform];


CABasicAnimation *myAnchorPointAnimation;

	myAnchorPointAnimation = [CABasicAnimation  
animationWithKeyPath:@"anchorPoint"];
	myAnchorPointAnimation.toValue = [NSValue  
valueWithPoint:NSMakePoint(.5, .5)];


CAAnimationGroup *group = [CAAnimationGroup animation];

	group.animations = [NSArray  
arrayWithObjects:myAnchorPointAnimation, myTransformAnimation, nil];


group.duration = aDuration;
group.repeatCount = 0;
	group.timingFunction = [CAMediaTimingFunction  
functionWithName:kCAMediaTimingFunctionEaseInEaseOut];

group.fillMode = kCAFillModeForwards;
group.removedOnCompletion = NO;

What I've tried so far is to look at at the layer's transform  
property, then getting the appropriate value from the CATransform3D  
struct. However, from what I can see by logging one of the struct's  
value (specifically m11), what you get are the values that make up  
the toValue in my animation, not the current value at the point in  
time in the animation when the pause happens.


The only other discussion on pausing an animation came from this  
thread:


http://www.cocoabuilder.com/archive/message/cocoa/2007/12/4/194458

...and it didn't quite apply. If someone has any guidance, I'd  
really appreciate it.


Best,

John
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/bdudney%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: !foo vs foo == nil

[Sean McBride]

On 8/20/08 11:06 PM, Michael Ash said:

>It is a little known fact that when passing NULL (and by extension nil
>or Nil) as a parameter to a vararg function, you *must* cast it to the
>appropriate pointer type to guarantee correct behavior.
>
>Interestingly, Apple's vararg methods which use nil as a terminator
>(such as dictionaryWithObjectsAndKeys:) make no mention of this in
>their documentation, and have a great deal of officially sanctioned
>sample code which doesn't use such a cast. (And none of my code uses
>it either.) I suppose Apple must be implicitly making a stronger
>guarantee about the pointer-ness of nil than the C language makes
>about NULL.

gcc provides:

"-Wstrict-null-sentinel (C++ only)
Warn also about the use of an uncasted "NULL" as sentinel. When
compiling only with GCC this is a valid sentinel, as "NULL" is defined
to "__null". Although it is a null pointer constant not a null pointer,
it is guaranteed to of the same size as a pointer. But this use is not
portable across different compilers."

and indeed:

--
#import 

int main(int argc, char *argv[])
{
  NSArray* foo = [NSArray arrayWithObjects:@"foo", @"bar", nil];

  return 0;
}
--

$ g++-4.2 -Wformat=2 -Wstrict-null-sentinel /Users/sean/Desktop/test.mm
/Users/sean/Desktop/test.mm:5: warning: missing sentinel in function call

using "(id)nil" in place of "nil" fixes the warning.

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: !foo vs foo == nil

[Jean-Daniel Dupas]

Le 21 août 08 à 19:06, Scott Ribe a écrit :


Wow, don't check the list for a few days and look what happens!


After all, that's why nil (and Nil) exist at all,
rather than just reusing NULL.


Actually nil exists at all because Objective-C was created *before*  
NULL was
in such standard use! (It may have always been part of stdio.h,  
don't recall
for sure, but there definitely was no stddef.h.) Way back when,  
everybody
defined their own macro, and some libraries even called it NIL or  
nil or

null instead of NULL. (Others simply used 0.)


I finally discovered
that one of the headers in this old cross-platform code had defined
NULL to be 0, just a plain integer 0, rather than (void *)0.


Yes, that is allowed. In fact, Stroustrup suggests that it is  
preferred for
C++, because stricter type checking makes ((void*)0) much less  
useful... GCC
(actually g++) gets around this by providing __null, which is a  
magic token

that gets special treatment from the compiler. If you look at stddef.h
and/or _types.h, you'll see a special case for __GNUG__ (GNU C++) that
defines NULL to be __null.

It is a little known fact that when passing NULL (and by extension  
nil
or Nil) as a parameter to a vararg function, you *must* cast it to  
the

appropriate pointer type to guarantee correct behavior.


2 reasons: 1) integer & pointer sizes may not be the same, this is the
common case, and is cured by defining NULL as ((void*)0) and nil as  
((id)0)
instead of just 0, and is why Apple gets away with this usage, and I  
suspect
the g++ magic __null takes care of this as well; 2) The standard  
actually
allows different types of pointers to have different sizes, which I  
think is
very rare, and certainly not the case on any architectures on which  
Cocoa

does (or ever did) run--or any that I've ever worked with.


Boolean negating a
pointer is a hack that by happy coincidence works.


No it is not; it is an explicitly designed and required feature of the
language.


a.)
(int) NULL  is NOT required or guaranteed  0x0 by the standard.


Yes, it is.


Obviously I overlooked that the standard guarantees the
conversion NULL => int results in 0 and vice versa.


OK, close but not quite. The standard says that NULL is 0, and that  
all
pointer <-> int conversions take care of mapping the machine's null  
address

to the integer 0, if necessary.



Could you tell me which part of the standard states that NULL is 0. I  
don't managed to find it. The only relevant part I found about NULL is  
the section 7.17.


Common definitions  :

NULL
which expands to an implementation-defined null pointer constant;



___

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

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

Converting NSString to valid HTML string

[JanakiRam]

Hi All,

I'm developing an Cocoa client application.As part of application logic , i
make the Webservice Call with XML data - which returns the XML file as
response which contains the HTML code for the special characters. While
sending the data i need to convert the special characters such as &,'
etc with their HTML Codes/equivalents and also need to extract the
string by replacing the HTML codes while retrieving the data. Can any one
suggest me the preferred way to convert/extract HTML Codes.

Please help me to solve this problem.

Thanks in Advance.

JanakiRam
___

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

Please do not post 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: Modifying TextEdit.app

[Andy Lee]

On Aug 21, 2008, at 1:55 PM, R.L. Grigg wrote:
Yes, that's a cool feature. But if I have three versions of  
AppController.m up at once, it would be great to be reminded -- at a  
glance -- which one is which, especially since I get so many  
interruptions. So if the path was on the title bar, that'd be cool.  
But I guess it's not so easy to change TextEdit to do this.


Did you not see my earlier reply?


On Aug 20, 2008, at 12:26 PM, Andy Lee wrote:
Sounds like TextEdit is an NSDocument-based app.  I'm not familiar  
with those, but I see NSDocument has a -displayName method whose  
documentation says:


"If the document has been saved, the display name is the last  
component of the directory location of the saved file (for example,  
“MyDocument” if the path is “/tmp/MyDocument.rtf”). If the document  
is new, NSDocument makes the display name “Untitled n,” where n is a  
number in a sequence of new and unsaved documents. The displayable  
name also takes into account whether the document’s filename  
extension should be hidden. Subclasses ofNSWindowController can  
override windowTitleForDocumentDisplayName:to modify the display  
name as it appears in window titles."


This would explain why you didn't see an explicit call to -setTitle:  
in the code -- that's taken care of by the framework.  You can  
override to customize the framework's default behavior.



I just added the following to DocumentWindowController and it had the  
desired effect:



- (NSString *)windowTitleForDocumentDisplayName:(NSString *)displayName
{
NSURL *fileURL = [[self document] fileURL];

if (fileURL)
return [fileURL path];
else
return [super windowTitleForDocumentDisplayName:displayName];
}


I would have guessed there would be a simpler way, maybe a boolean you  
could set.  But this works.


--Andy

___

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

Please do not post 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: Converting NSString to valid HTML string

[Randall Meadows]

On Aug 21, 2008, at 12:16 PM, JanakiRam wrote:

I'm developing an Cocoa client application.As part of application  
logic , i

make the Webservice Call with XML data - which returns the XML file as
response which contains the HTML code for the special characters.  
While

sending the data i need to convert the special characters such as &,'
etc with their HTML Codes/equivalents and also need to extract the
string by replacing the HTML codes while retrieving the data. Can  
any one

suggest me the preferred way to convert/extract HTML Codes.


Take a look at the NSString documentation, the "Working with URLs"  
section:


– stringByAddingPercentEscapesUsingEncoding:
– stringByReplacingPercentEscapesUsingEncoding:

___

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

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

Parsing any date/time format with NSDateFomatter

[Joseph Kelly]

Hello,

I am creating NSDateFormatter programmatically, and I wish to parse  
any type of date string within the user's locale -- for instance  
"03/13/08" or "1:30PM March 13, 2008" would both be acceptable.


Unfortunately, NSDateFormatter seems to parse only one specific format  
at a time. I wrote a category method on NSDateFormatter which does the  
following, and seems to work okay:


// Note: I've set the locale, calendar, and  timezone to "current" in  
the calling code...


-(NSDate*)iterativeDateFromString:(NSString*)string
{	// Iterate through increasingly specific date and time styles,  
finding one that parses.

NSDate* theBestDate = nil;
int timeStyle, dateStyle;
	for (timeStyle = NSDateFormatterNoStyle; timeStyle <=  
NSDateFormatterFullStyle; timeStyle++)

{
		for (dateStyle = NSDateFormatterNoStyle; dateStyle <=  
NSDateFormatterFullStyle; dateStyle++)

{
NSDate* aDate = nil;
[self setTimeStyle:(NSDateFormatterStyle)timeStyle];
[self setDateStyle:(NSDateFormatterStyle)dateStyle];
NSRange r = NSMakeRange(0, [string length]);
NSError* err = nil;
			if ([self getObjectValue:&aDate forString:string range:&r  
error:&err])

theBestDate = aDate;
}
}
return theBestDate;
}

But it seems there's got to be a better way to do this. Any ideas?

Joe K.
___

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

Please do not post 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: !foo vs foo == nil

[Clark Cox]

On Thu, Aug 21, 2008 at 10:46 AM, Jean-Daniel Dupas
<[EMAIL PROTECTED]> wrote:
>
> Le 21 août 08 à 19:06, Scott Ribe a écrit :
>
>> Wow, don't check the list for a few days and look what happens!
>>
>>> After all, that's why nil (and Nil) exist at all,
>>> rather than just reusing NULL.
>>
>> Actually nil exists at all because Objective-C was created *before* NULL
>> was
>> in such standard use! (It may have always been part of stdio.h, don't
>> recall
>> for sure, but there definitely was no stddef.h.) Way back when, everybody
>> defined their own macro, and some libraries even called it NIL or nil or
>> null instead of NULL. (Others simply used 0.)
>>
>>> I finally discovered
>>> that one of the headers in this old cross-platform code had defined
>>> NULL to be 0, just a plain integer 0, rather than (void *)0.
>>
>> Yes, that is allowed. In fact, Stroustrup suggests that it is preferred
>> for
>> C++, because stricter type checking makes ((void*)0) much less useful...
>> GCC
>> (actually g++) gets around this by providing __null, which is a magic
>> token
>> that gets special treatment from the compiler. If you look at stddef.h
>> and/or _types.h, you'll see a special case for __GNUG__ (GNU C++) that
>> defines NULL to be __null.
>>
>>> It is a little known fact that when passing NULL (and by extension nil
>>> or Nil) as a parameter to a vararg function, you *must* cast it to the
>>> appropriate pointer type to guarantee correct behavior.
>>
>> 2 reasons: 1) integer & pointer sizes may not be the same, this is the
>> common case, and is cured by defining NULL as ((void*)0) and nil as
>> ((id)0)
>> instead of just 0, and is why Apple gets away with this usage, and I
>> suspect
>> the g++ magic __null takes care of this as well; 2) The standard actually
>> allows different types of pointers to have different sizes, which I think
>> is
>> very rare, and certainly not the case on any architectures on which Cocoa
>> does (or ever did) run--or any that I've ever worked with.
>>
>>> Boolean negating a
>>> pointer is a hack that by happy coincidence works.
>>
>> No it is not; it is an explicitly designed and required feature of the
>> language.
>>
>>> a.)
>>> (int) NULL  is NOT required or guaranteed  0x0 by the standard.
>>
>> Yes, it is.
>>
>>> Obviously I overlooked that the standard guarantees the
>>> conversion NULL => int results in 0 and vice versa.
>>
>> OK, close but not quite. The standard says that NULL is 0, and that all
>> pointer <-> int conversions take care of mapping the machine's null
>> address
>> to the integer 0, if necessary.
>
>
> Could you tell me which part of the standard states that NULL is 0.

NULL *can* be 0, it isn't *necessarily* 0

> I don't
> managed to find it. The only relevant part I found about NULL is the section
> 7.17.
>
> Common definitions  :
>
> NULL
> which expands to an implementation-defined null pointer constant;

... and 0 is a valid null pointer constant. From 6.3.2.3:

3 An integer constant expression with the value 0, or such an
expression cast to type
void *, is called a null pointer constant. If a null pointer constant
is converted to a
pointer type, the resulting pointer, called a null pointer, is
guaranteed to compare unequal
to a pointer to any object or function.


-- 
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: Converting NSString to valid HTML string

[Nate Weaver]

Those are for URL encoding; I think he wants HTML entities. I can't  
remember if there are Cocoa methods to do this, but you can use  
CFXMLCreateStringByEscapingEntities() (since NSString * and  
CFStringRef are toll-free bridged):


NSString *input = @"2 < 4";
NSString *output = (NSString  
*)CFXMLCreateStringByEscapingEntities(NULL, (CFStringRef)input, NULL);


Should result in output being @"2 < 4".

Just remember that the output string will need to be released.

On Aug 21, 2008, at 1:32 PM, Randall Meadows wrote:


On Aug 21, 2008, at 12:16 PM, JanakiRam wrote:

I'm developing an Cocoa client application.As part of application  
logic , i
make the Webservice Call with XML data - which returns the XML file  
as
response which contains the HTML code for the special characters.  
While

sending the data i need to convert the special characters such as &,'
etc with their HTML Codes/equivalents and also need to extract  
the
string by replacing the HTML codes while retrieving the data. Can  
any one

suggest me the preferred way to convert/extract HTML Codes.


Take a look at the NSString documentation, the "Working with URLs"  
section:


– stringByAddingPercentEscapesUsingEncoding:
– stringByReplacingPercentEscapesUsingEncoding:

___

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

Please do not post 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/nateweaver%40xtechllc.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: !foo vs foo == nil

[Scott Ribe]

>> Could you tell me which part of the standard states that NULL is 0.


> NULL *can* be 0, it isn't *necessarily* 0


It follows from the rules re conversions that it must be either 0, or 0 cast
to a pointer type. No value other than 0 is guaranteed to cast to the
machine's actual null address (whatever bit pattern that might actually be).

6.3.2.3 which you quoted, does not provide for any value other than 0.

-- 
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: !foo vs foo == nil

[Clark Cox]

On Thu, Aug 21, 2008 at 11:56 AM, Scott Ribe <[EMAIL PROTECTED]> wrote:
>>> Could you tell me which part of the standard states that NULL is 0.
>
>
>> NULL *can* be 0, it isn't *necessarily* 0
>
>
> It follows from the rules re conversions that it must be either 0, or 0 cast
> to a pointer type.

Or an "implementation defined null pointer constant". That is, this is
perfectly legal:

#define NULL __builtin_special_null_keyword_that_is_specific_to_my_compiler

as long as, when
__builtin_special_null_keyword_that_is_specific_to_my_compiler is
converted to a pointer type, it becomes a null pointer.

GCC uses such an implementation defined constant to allow additional
warnings when NULL is used in a non-pointer context (i.e. int i = 0;).

> No value other than 0 is guaranteed to cast to the
> machine's actual null address (whatever bit pattern that might actually be).
>
> 6.3.2.3 which you quoted, does not provide for any value other than 0.

-- 
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: !foo vs foo == nil

[Clark Cox]

On Thu, Aug 21, 2008 at 12:16 PM, Clark Cox <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 21, 2008 at 11:56 AM, Scott Ribe <[EMAIL PROTECTED]> wrote:
 Could you tell me which part of the standard states that NULL is 0.
>>
>>
>>> NULL *can* be 0, it isn't *necessarily* 0
>>
>>
>> It follows from the rules re conversions that it must be either 0, or 0 cast
>> to a pointer type.
>
> Or an "implementation defined null pointer constant". That is, this is
> perfectly legal:
>
> #define NULL __builtin_special_null_keyword_that_is_specific_to_my_compiler
>
> as long as, when
> __builtin_special_null_keyword_that_is_specific_to_my_compiler is
> converted to a pointer type, it becomes a null pointer.
>
> GCC uses such an implementation defined constant to allow additional
> warnings when NULL is used in a non-pointer context (i.e. int i = 0;).

Arg, that example of a non-pointer context that GCC can warn about
should have been (int i = NULL;)

-- 
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: !foo vs foo == nil

[Scott Ribe]

> as long as, when
> __builtin_special_null_keyword_that_is_specific_to_my_compiler is
> converted to a pointer type, it becomes a null pointer.

And, if converted to integer type, it becomes 0. Right; I was certainly
talking about standard integer/pointer types, without compiler magic, which
must be 0, not any other value. Thing is, even the special compiler keyword
is *indistinguishable* from 0, except for type checking rules.

> GCC uses such an implementation defined constant to allow additional
> warnings when NULL is used in a non-pointer context (i.e. int i = 0;).

And also, I believe, to finesse away type conflicts in C++.


-- 
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: !foo vs foo == nil

[Jim Correia]

On Aug 21, 2008, at 3:54 AM, Jules Colding wrote:


For that simple reason, I'd go for nil == foo every time.


Yes, and in general you should always do "if (CONSTANT == foo)" to  
catch the potential "if (CONSTANT = foo)" error.


If your name is Yoda, then perhaps if (3 != x) reads naturally to  
you. :-)


As in most things, I think it is critical to strike a balance between  
code readability/skim-ability and other considerations.


The previously mentioned warning will catch an unintentional  
assignment as long as you don't overzealously use extra sets of  
parenthesis.


And to use Uli's example, the compiler will happily accept

x =+ 5;

even when that isn't what you intended. At the end of the day, you are  
responsible for what you typed, typos included.


Jim
___

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

Please do not post 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: !foo vs foo == nil

[Jim Correia]

On Aug 20, 2008, at 9:31 PM, Marcel Weiher wrote:

I was swayed by the "nil == foo" arguments for a while, but my gut  
kept tugging at me and now I have switched back to just if ( !foo),  
or better (I prefer positive ifs), if (foo).  Of course, if all the  
if (foo) is protecting is a message-send, you can just leave it out  
altogether and let nil do its thing to messages...


For the sake of completeness (I know Marcel knows the rule), if you  
are using the return value of a message send, the value will be  
undefined depending on return type when sending a message to nil. See  
the runtime documentation for details.


Jim
___

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

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

Scaling an NSImage makes the edges disappear.

[David Springer]

Folks,

For some reason, I am not able to figure this out.  I want to draw a
scaled NSImage, but the edges of the image are not drawn, it seems
like the resizing actually clips the image.

I have an NSBitmapImageRep created from some data.  I then create the
NSImage like this:

NSImage *image = [[NSImage alloc] initWithSize:NSMakeSize([myBitmap
pixelsWide], [myBitmap pixelsHigh]);
[image addRepresentation:myBitmap];
[image setScalesWhenResized:YES];

// Figure out the new image size so that it is proportionally scaled
by |scaleFactor|.
NSSize scaledSize = ProportionallyScale([image size], scaleFactor);
[image drawInRect:NSMakeRect((kTileImageSize - scaledSize.width) * 0.5,
   (kTileImageSize - scaledSize.height) * 0.5,
   scaledSize.width,
   scaledSize.height)
   fromRect:NSZeroRect
  operation:NSCompositeSourceOver
   fraction:1.0];

This sometimes works (that is, the entire original image is visible).
But more often than not, the edges of the original image are not
drawn.  See the screen shots for a picture of what I get.

What am I doing wrong here?  I have scoured the archives, I have tried
things like making sure scaledSize has integer values, I have even
done crazy things like add one to the height just to see what would
happen.  Note that if I write out the TIFFRepresentation of |image|
(both before and after) the entire image gets into the file (that is,
the edges are not clipped).

In the attached picture, the top tile is correct (you see all the
black edges), the bottom two tiles are incorrect (not all the black
edges are visible).

Help?
Thanks!
- Dave.S
<>___

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

Please do not post 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: !foo vs foo == nil

[Clark Cox]

On Thu, Aug 21, 2008 at 12:38 PM, Scott Ribe <[EMAIL PROTECTED]> wrote:
>> as long as, when
>> __builtin_special_null_keyword_that_is_specific_to_my_compiler is
>> converted to a pointer type, it becomes a null pointer.
>
> And, if converted to integer type, it becomes 0.

No, converting a pointer type (any pointer type, null or otherwise)
results in implementation defined behavior or undefined behavior. From
6.3.2.3 6:
"Any pointer type may be converted to an integer type. Except as
previously specified, the result is implementation-defined. If the
result cannot be represented in the integer type, the behavior is
undefined. The result need not be in the range of values of any integer
type."

That is, this always yields a null pointer to foo:
foo *ptr = 0;

This, on the other hand, is not guaranteed to yield zero (despite the
fact that it does yield zero on most platforms)
int i = (int)ptr;

There is nothing preventing a compiler from compiling:

int i = (int)NULL;

to:

int i = 42;

> Right; I was certainly
> talking about standard integer/pointer types, without compiler magic, which
> must be 0, not any other value. Thing is, even the special compiler keyword
> is *indistinguishable* from 0, except for type checking rules.

It is distinguishable from 0, in that it is not guaranteed that you
can convert it to an int.

-- 
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: !foo vs foo == nil

[Shawn Erickson]

On Thu, Aug 21, 2008 at 12:45 PM, Jim Correia <[EMAIL PROTECTED]> wrote:

> For the sake of completeness (I know Marcel knows the rule), if you are
> using the return value of a message send, the value will be undefined
> depending on return type when sending a message to nil. See the runtime
> documentation for details.

As of the 10.5 runtime the zero value guarantee is more well defined
(aka review the latest and prior documentation)...

--- 10.5 ---

- If the method returns an object, any pointer type, any integer
scalar of size less than or equal to sizeof(void*), a float, a double,
a long double, or a long long, then a message sent to nil returns 0.

- If the method returns a struct, as defined by the Mac OS X ABI
Function Call Guide to be returned in registers, then a message sent
to nil returns 0.0 for every field in the data structure. Other struct
data types will not be filled with zeros.

- If the method returns anything other than the aforementioned value
types the return value of a message sent to nil is undefined.

--- older ---

A message to nil also is valid, as long as the message returns an
object, any pointer type, void, or any integer scalar of size less
than or equal to sizeof(void*); if it does, a message sent to nil
returns nil. If the message sent to nil returns anything other than
the aforementioned value types (for example, if it returns any struct
type, any floating-point type, or any vector type) the return value is
undefined. You should therefore not rely on the return value of
messages sent to nil unless the method's return type is an object, any
pointer type, or any integer scalar of size less than or equal to
sizeof(void*):


-Shawn
___

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

Please do not post 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: !foo vs foo == nil

[Scott Ribe]

You're forgetting that null pointers *must* convert to 0, this is why
if(!foo) works. I think  that would be the "Except as previously
specified.." part of what you quoted ;-)


-- 
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Scaling an NSImage makes the edges disappear.

[Ken Ferry]

Hi David,

Could you post a complete test app? There's nothing in what you've
posted that looks problematic[1].  Also, what OS are you working on?

-Ken

[1]: well, except maybe that you're likely to see antialiasing on the edges.
 Your problem looks more severe than antialiasing, though.

On Thu, Aug 21, 2008 at 12:47 PM, David Springer <[EMAIL PROTECTED]> wrote:
> Folks,
>
> For some reason, I am not able to figure this out.  I want to draw a
> scaled NSImage, but the edges of the image are not drawn, it seems
> like the resizing actually clips the image.
>
> I have an NSBitmapImageRep created from some data.  I then create the
> NSImage like this:
>
> NSImage *image = [[NSImage alloc] initWithSize:NSMakeSize([myBitmap
> pixelsWide], [myBitmap pixelsHigh]);
> [image addRepresentation:myBitmap];
> [image setScalesWhenResized:YES];
>
> // Figure out the new image size so that it is proportionally scaled
> by |scaleFactor|.
> NSSize scaledSize = ProportionallyScale([image size], scaleFactor);
>[image drawInRect:NSMakeRect((kTileImageSize - scaledSize.width) * 0.5,
>   (kTileImageSize - scaledSize.height) * 0.5,
>   scaledSize.width,
>   scaledSize.height)
>   fromRect:NSZeroRect
>  operation:NSCompositeSourceOver
>   fraction:1.0];
>
> This sometimes works (that is, the entire original image is visible).
> But more often than not, the edges of the original image are not
> drawn.  See the screen shots for a picture of what I get.
>
> What am I doing wrong here?  I have scoured the archives, I have tried
> things like making sure scaledSize has integer values, I have even
> done crazy things like add one to the height just to see what would
> happen.  Note that if I write out the TIFFRepresentation of |image|
> (both before and after) the entire image gets into the file (that is,
> the edges are not clipped).
>
> In the attached picture, the top tile is correct (you see all the
> black edges), the bottom two tiles are incorrect (not all the black
> edges are visible).
>
> Help?
> Thanks!
> - Dave.S
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post 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/kenferry%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: !foo vs foo == nil

[Clark Cox]

On Thu, Aug 21, 2008 at 1:23 PM, Scott Ribe <[EMAIL PROTECTED]> wrote:
> You're forgetting that null pointers *must* convert to 0,

Please show me where that is guaranteed.

> this is why if(!foo) works.

if(!foo) works because of:

From 6.5.3.3:
"The expression !E is equivalent to (0==E)."

if(foo) works because of:

From 6.8.4.1:
"In both forms, the first substatement is executed if the expression
compares unequal to 0."

Neither of these involves converting the pointer to an integer.

>I think  that would be the "Except as previously
> specified.." part of what you quoted ;-)

-- 
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: Scaling an NSImage makes the edges disappear.

[David Springer]

Hi Ken,

I can build a test app - give me a couple hours to put it together.

As for antialiasing, I thought that might be the problem, but I set
the image interpolation on the graphics context to
NSImageInterpolationNone and get the same results.

I am on Leopard 10.5.4 (this all has to work on Tiger, as well though).

Thanks
- Dave.S


On Thu, Aug 21, 2008 at 2:26 PM, Ken Ferry <[EMAIL PROTECTED]> wrote:
> Hi David,
>
> Could you post a complete test app? There's nothing in what you've
> posted that looks problematic[1].  Also, what OS are you working on?
>
> -Ken
>
> [1]: well, except maybe that you're likely to see antialiasing on the edges.
>  Your problem looks more severe than antialiasing, though.
>
> On Thu, Aug 21, 2008 at 12:47 PM, David Springer <[EMAIL PROTECTED]> wrote:
>> Folks,
>>
>> For some reason, I am not able to figure this out.  I want to draw a
>> scaled NSImage, but the edges of the image are not drawn, it seems
>> like the resizing actually clips the image.
>>
>> I have an NSBitmapImageRep created from some data.  I then create the
>> NSImage like this:
>>
>> NSImage *image = [[NSImage alloc] initWithSize:NSMakeSize([myBitmap
>> pixelsWide], [myBitmap pixelsHigh]);
>> [image addRepresentation:myBitmap];
>> [image setScalesWhenResized:YES];
>>
>> // Figure out the new image size so that it is proportionally scaled
>> by |scaleFactor|.
>> NSSize scaledSize = ProportionallyScale([image size], scaleFactor);
>>[image drawInRect:NSMakeRect((kTileImageSize - scaledSize.width) * 0.5,
>>   (kTileImageSize - scaledSize.height) * 0.5,
>>   scaledSize.width,
>>   scaledSize.height)
>>   fromRect:NSZeroRect
>>  operation:NSCompositeSourceOver
>>   fraction:1.0];
>>
>> This sometimes works (that is, the entire original image is visible).
>> But more often than not, the edges of the original image are not
>> drawn.  See the screen shots for a picture of what I get.
>>
>> What am I doing wrong here?  I have scoured the archives, I have tried
>> things like making sure scaledSize has integer values, I have even
>> done crazy things like add one to the height just to see what would
>> happen.  Note that if I write out the TIFFRepresentation of |image|
>> (both before and after) the entire image gets into the file (that is,
>> the edges are not clipped).
>>
>> In the attached picture, the top tile is correct (you see all the
>> black edges), the bottom two tiles are incorrect (not all the black
>> edges are visible).
>>
>> Help?
>> Thanks!
>> - Dave.S
>>
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post 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/kenferry%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: Modifying TextEdit.app

[R.L. Grigg]

On Aug 21, 2008, at 11:18 AM, Andy Lee wrote:


On Aug 21, 2008, at 1:55 PM, R.L. Grigg wrote:
Yes, that's a cool feature. But if I have three versions of  
AppController.m up at once, it would be great to be reminded -- at  
a glance -- which one is which, especially since I get so many  
interruptions. So if the path was on the title bar, that'd be cool.  
But I guess it's not so easy to change TextEdit to do this.


Did you not see my earlier reply?


Funny, it didnt come in until your second post.


On Aug 20, 2008, at 12:26 PM, Andy Lee wrote:
Sounds like TextEdit is an NSDocument-based app.  I'm not familiar  
with those, but I see NSDocument has a -displayName method whose  
documentation says:


"If the document has been saved, the display name is the last  
component of the directory location of the saved file (for example,  
“MyDocument” if the path is “/tmp/MyDocument.rtf”). If the document  
is new, NSDocument makes the display name “Untitled n,” where n is  
a number in a sequence of new and unsaved documents. The  
displayable name also takes into account whether the document’s  
filename extension should be hidden. Subclasses  
ofNSWindowController can override  
windowTitleForDocumentDisplayName:to modify the display name as it  
appears in window titles."


This would explain why you didn't see an explicit call to - 
setTitle: in the code -- that's taken care of by the framework.   
You can override to customize the framework's default behavior.



I just added the following to DocumentWindowController and it had  
the desired effect:



- (NSString *)windowTitleForDocumentDisplayName:(NSString  
*)displayName

{
   NSURL *fileURL = [[self document] fileURL];

   if (fileURL)
   return [fileURL path];
   else
   return [super windowTitleForDocumentDisplayName:displayName];
}


Overriding -windowTitleForDocumentDisplayName: works perfectly!
Thanks, Andy!

Russ

___

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

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

Vancouver - We Need A Mac Guru @ macProVideo

[Martin Sitter]

Vancouver - Senior Mac Developer With Multimedia Experience @  
macProVideo.com


Company: macProVideo.com
Location: Vancouver, BC, CANADA

Description:

macProVideo.com, a leading global publisher of software tutorial- 
videos, requires a Senior Mac Developer with experience creating  
Multimedia applications.
Our company is expanding and we have several educational software  
products in development. Each of these applications is designed to  
enhance our video-tutorials, so a strong knowledge of multimedia  
programming is required. If coding Audio & Video applications for the  
Mac is your dream job, we need you!


We're looking for a coder/guru to become the keeper of our code! As  
our resident Mac guru, you will:


• Build the Mac side of our software development division.
• Work with the Publisher to conceptualize and code revolutionary  
educational software.


This is a senior position, and the successful candidate will have a  
demonstrable history of coding Mac software. The following skills are  
also required:


• Superior understanding of XCode and Cocoa
• Strong & demonstrable experience coding with the QuickTime  
architecture

• Solid understanding of Core Graphics and Core Animation
• Some knowledge of Core Audio and/or audio driver construction

The successful candidate will undertake a 3-month trial contract. If  
all milestones are met during the contract period, the position will  
resolve to full time with benefits, with relocation to our Vancouver  
office. Pay is according to experience, but above industry standard.


To apply, email resume directly - please do not reply to this mail on  
the cocoa-dev list!!


_

Martin Sitter
Publisher
macProVideo.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]