NSCoder Chicag Reminder - Monday Night

[Bob Frank]

Reminder:

Monday August 31st is NSCoder Chicago at the 4th Floor Michigan Ave.  
Apple store 6:00 - 9:00 with drinking after.  Hope to see you there.




Dates of interest:

   August 31st 6:00 - 9:00: NSCoder Chicago Apple Store 4th floor
   September 8th 7:00 - 8:00: CocoaHeads / CAWUG Apple Store 2nd floor
   October 13th 7:00 - 8:00: CocoaHeads / CAWUG Apple Store 2nd floor


-Bob

___

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

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

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

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

Re: libcrypto on Snow Leopard

[Thomas Clement]

Another solution is to copy the libcrypto.0.9.7.dylib from the 10.5  
SDK into your project directory and link against that.

It works well.

Regards,
Thomas

On Aug 29, 2009, at 2:07 AM, Steven Degutis wrote:


The solution to this is pretty simple, don't link to libcrypto.
Instead, just #import  in your file and  
use the

CC_ prefixed functions in your app, such as CC_MD5.

--
Steven Degutis
http://www.thoughtfultree.com/
http://www.degutis.org/


On Fri, Aug 28, 2009 at 3:41 PM, David Riggle   
wrote:


I converted my project to the 10.6 SDK, but now my app won't launch  
on

Leopard:

myApp[595]: dyld: Library not loaded: /usr/lib/libcrypto.0.9.8.dylib
myApp[595]:  Referenced from: /Users/dave/Desktop/myApp.app/ 
Contents/myApp

myAppl[595]:   Reason: image not found

If I select the older libcrypto in Xcode, I get this compile error:

ld: cannot link directly with
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libcrypto.0.9.7.dylib

If I do this:

cd /Developer/SDKs/MacOSX10.6.sdk/usr/lib/
sudo mv libcrypto.0.9.7.dylib libcrypto.0.9.7.back
sudo cp /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libcrypto. 
0.9.7.dylib .


I can link against the old library, but I get the following link  
error:


Undefined symbols: _BIO_set_flags

Anybody know where that symbol was defined in 10.5? I really don't  
like

this Frankenstein's SDK that I'm having to cobble together...

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

This email sent to steven.degu...@gmail.com


___

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

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

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

This email sent to thoma...@free.fr



___

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

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

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

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

Re: libcrypto on Snow Leopard

[Jean-Daniel Dupas]

Make sure to also use the headers from 10.5 SDK if you choose this  
solution.



Le 29 août 2009 à 10:59, Thomas Clement a écrit :

Another solution is to copy the libcrypto.0.9.7.dylib from the 10.5  
SDK into your project directory and link against that.

It works well.

Regards,
Thomas

On Aug 29, 2009, at 2:07 AM, Steven Degutis wrote:


The solution to this is pretty simple, don't link to libcrypto.
Instead, just #import  in your file  
and use the

CC_ prefixed functions in your app, such as CC_MD5.

--
Steven Degutis
http://www.thoughtfultree.com/
http://www.degutis.org/


On Fri, Aug 28, 2009 at 3:41 PM, David Riggle   
wrote:


I converted my project to the 10.6 SDK, but now my app won't  
launch on

Leopard:

myApp[595]: dyld: Library not loaded: /usr/lib/libcrypto.0.9.8.dylib
myApp[595]:  Referenced from: /Users/dave/Desktop/myApp.app/ 
Contents/myApp

myAppl[595]:   Reason: image not found

If I select the older libcrypto in Xcode, I get this compile error:

ld: cannot link directly with
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libcrypto.0.9.7.dylib

If I do this:

cd /Developer/SDKs/MacOSX10.6.sdk/usr/lib/
sudo mv libcrypto.0.9.7.dylib libcrypto.0.9.7.back
sudo cp /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libcrypto. 
0.9.7.dylib .


I can link against the old library, but I get the following link  
error:


Undefined symbols: _BIO_set_flags

Anybody know where that symbol was defined in 10.5? I really don't  
like

this Frankenstein's SDK that I'm having to cobble together...

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

This email sent to steven.degu...@gmail.com


___

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

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

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

This email sent to thoma...@free.fr



___

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

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

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

This email sent to devli...@shadowlab.org



___

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

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

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

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

Re: libcrypto on Snow Leopard

[Carl Harris]

Nick Zitzmann wrote:

So if you need to use libcrypto 0.9.7, you must use the Leopard or
Tiger SDKs. You can't use the Snow Leopard SDK and libcrypto unless
you want to make your software require Snow Leopard.


Isn't it generally the case that an application built against the 10.6  
SDK is going to require 10.6 at runtime?  Taking libcrypto out of the  
equation, if I build my app using the 10.6 SDK, I can't really expect  
it to run under 10.5 or earlier versions of Mac OS X, can I?


--
Carl Harris
___

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

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

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

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

Re: libcrypto on Snow Leopard

[Thomas Clement]

On Aug 29, 2009, at 11:13 AM, Carl Harris wrote:


Nick Zitzmann wrote:

So if you need to use libcrypto 0.9.7, you must use the Leopard or
Tiger SDKs. You can't use the Snow Leopard SDK and libcrypto unless
you want to make your software require Snow Leopard.


Isn't it generally the case that an application built against the  
10.6 SDK is going to require 10.6 at runtime?  Taking libcrypto out  
of the equation, if I build my app using the 10.6 SDK, I can't  
really expect it to run under 10.5 or earlier versions of Mac OS X,  
can I?


Yes you can.
http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html

Thomas

___

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

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

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

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

Re: libcrypto on Snow Leopard

[Kyle Sluder]

No, very much no. It's common to build against the 10.x SDK but set  
the deployment target to 10.y (where y < x). This is how you take  
advantage of new behavior while remaining binary compatible with older  
versions.


--Kyle Sluder
___

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

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

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

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

Re: libcrypto on Snow Leopard

[Kyle Sluder]

On Aug 29, 2009, at 1:59 AM, Thomas Clement  wrote:

Another solution is to copy the libcrypto.0.9.7.dylib from the 10.5  
SDK into your project directory and link against that.


Aren't the SDK dylibs just stubs for linking purposes?

--Kyle Sluder
___

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

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

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

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

Re: libcrypto on Snow Leopard

[Jean-Daniel Dupas]

Le 29 août 2009 à 11:27, Kyle Sluder a écrit :


On Aug 29, 2009, at 1:59 AM, Thomas Clement  wrote:

Another solution is to copy the libcrypto.0.9.7.dylib from the 10.5  
SDK into your project directory and link against that.


Aren't the SDK dylibs just stubs for linking purposes?


They are. But it does not suggest to embed the dylib in the  
application, but just to copy it in the project to be able to link on  
it without having to modify the 10.6 SDK.
You may even rename it to avoid library resolution order issue with  
the linker.


___

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

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

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

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

NSTextView moves when being resized ???

[Anders Lassen]

Hi,

I am working on a custom view that consists of a column of several  
NSTextViews. In between, there are graphics and some other stuff that  
require special editing.


Therefore I cannot use a single NSTextView.

The NSTextView must adopt its height to the content. This works fine  
using the code as listed below.


But the problem is, that the NSTextView control moves downwards when  
the size is changed.


   textView = [[NSTextView alloc] initWithFrame:NSMakeRect(100, 100,  
300, 200)];


   [self addSubview:textView];

   [textView setVerticallyResizable:YES];

   [textView setAutoresizingMask NSViewHeightSizable];

   [textView setMinSize:NSMakeSize(0.0, 100.0)];
   [textView setMaxSize:NSMakeSize(FLT_MAX, FLT_MAX)];


I have read about others having the same problem, but I did not find a  
solution.


Note that the NSTextView is a subview to a custom view, that is the  
content view of a NSScrollView. But this does not matter - I think.


Hope someone can help on this.

Kind regards,

Anders Lassen


___

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

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

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

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

How to extract the "Artist" information of an song file?

[James]

Hi all,
How to extract the "Artist" information from an song file?
Is there any method about it ? Any clues is helpful for me.
Thank you in advance!
James

___

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

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

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

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

llvm-gcc-4.2 link-time error seen from command line but not in Xcode 3.2

[Jay Reynolds Freeman]

I have some C++ files used in a Snow Leopard / Xcode (3.2) project,  
that compiles and links in Xcode with no trouble, with the compiler  
set to llvm-gcc-4.2.  However, when I try to compile and link  
something that uses those same files  from the command line, directly  
invoking llvm-gcc-4.2 as /Developer/usr/bin/llvm-gcc-4.2, with no  
explicit libraries indicated to link to, I get an error message from  
the linker to the effect that it cannot find "new" and "delete".  The  
*same* source code compiles and links from the command line if I  
merely change the compiler to straight g++-4.2.


I suspect there is something simple that I need to link in, but I  
can't find documentation ...


Can anyone provide advice?

--  Jay Reynolds Freeman
-
jay_reynolds_free...@mac.com
http://web.mac.com/jay_reynolds_freeman (personal web site)

___

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

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

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

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

Re: How to extract the "Artist" information of an song file?

[Jonathan del Strother]

2009/8/29 James :
> Hi all,
> How to extract the "Artist" information from an song file?
> Is there any method about it ? Any clues is helpful for me.
> Thank you in advance!

If it's an AAC file, you can use the QTMetaData* functions.  If you're
looking to get it out of an mp3, you're unfortunately stuck with
either parsing it yourself (see the id3 specs) or using id3lib.
___

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

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

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

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

Re: Get error message about registered observers when Object receives dealloc message

[Andreas Grosam]

On Aug 28, 2009, at 5:32 PM, Roland King wrote:

Thank you Roland for your reply.


I think this is one of those unfortunate messages which comes out  
before the dealloc method even runs, just entering the dealloc  
method with registered observers logs it. It's possible it would be  
better if it was only logged at the point say NSObject dealloc was  
called, but it's not, it's called at the start of your own dealloc.


That either indicates it's a bug in the message because it doesn't  
allow for the case where a dealloc method unregisters the things  
observing it .. or perhaps you're not really supposed to be doing it  
there. Normally an object will register its interest in observing  
another object and the same object will then unregister later. It's  
a little unusual for an object to unhook the objects which are  
observing it. Actually how are you even doing that, do you have a  
list of all the objects and paths which are observing you?


Actually, the provided code is a over-simplification. My object  
hierarchy looks as follows:


Model   ( provides the properties where other objects can register for  
observing it)

dictionary of objects that are observers

The "child" objects contain a weak reference to its parent Model  
(Model is not retained, otherwise I would establish a circular  
reference).



During setup, child objects register itself as observers, observing  
one or more properties of its parent object Model:


- setup {
   ...
   [self.model addObserver: self
forKeyPath: key
   options: NSKeyValueObservingOptionInitial
   context: NSSelectorFromString([ports  
objectForKey:key])];


...
}

When Model gets deallocated, it releases the dictionary, which  
releases the observer objects, which in turn invokes their dealloc  
method:


- (void) dealloc {
[self.model removeObserver:self forKeyPath:key];
...
}





I can sort of see how this might happen in practice, you create an  
object who's lifetime is determined by external factors, but  
observers hook up to it without retaining it and .. do something  
with observations of the key properties. Eventually the object gets  
released because all the other things which cared about it release  
it and you want to remove the observations and dealloc is the  
natural place to do that.


Yes, that may describe it. Actually, as shown above, there is an  
object hierarchy, where child objects are owned by its respective  
parent object. The child object's life time is (shall be) controlled  
by the parent object. However, there may be times where other objets  
get references of the child objects and retain it. Due to this, the  
logic in the code shall ensure that all "external" retained references  
have been released when the parent object `Model' gets deallocated.  
So, at the time Model receives -dealloc -- all child object's retain  
count shall equal *one*. If not, horrible things will happen ;)




I'd try to get it the other way around myself if possible, have the  
observer retain the object observed and register the observation,  
then have it drop the observation at a later point and release the  
object, which then eventually deallocs. I sort of understand how  
that could be hard if your object lifecycle is complicated and you  
were trying to use the implicit reference count to manage object  
lifetime and have the observers not retain and have a sort of weak  
reference.
The object hierarchy and its interconnections are quite complex. There  
are also animations and timers involved that invoke messages from a  
different context. And timers also retain certain child objects - or  
some sub-objects of them. So, tearing down the Model - requires a  
number of steps to be performed in the right order and synchronously.




Is there something other than dealloc you can use to denote when  
everything except observers have finished with your object so you  
can set an observed property which basically says "I'm useless and  
want to die" and causes any observers to remove the observation and  
release the object, which will then dealloc?


I'm currently think about a method - something like "shutdown" which  
helps to orderly tear down an object hierarchy. However, in order to  
work, this requires a set of conventions that need to be followed, e.g.:


- There is a protocol, Shutdownable (ugly name). All objects within  
the hierarchy must implement it.


- The method shutdown needs to be invoked from a parent object for  
each of its child object from within its own shutdown method. (this  
will establish a recursive invocation scheme)


- The method shutdown must be invoked for an object before its  
parent's dealloc method gets invoked.


- If the base class implements a shutdown method, [super shutdown]  
must be called.


- The implementation of shutdown must ensure that its actual shutdown  
actions must be performed only once - even when the method gets  
i

[OT] Re: strncat on Leopard vs. Snow Leopard

[Alastair Houghton]

On 29 Aug 2009, at 06:43, David Riggle wrote:

When I compile my app on Snow Leopard and run it on Leopard, strncat  
erroneously aborts with "detected buffer overflow".


How is this a Cocoa question?  (Hint: it isn't, so you've sent your  
question to the wrong mailing list.)


I think there was a bug in the Leopard version of strncat that was  
fixed in the Snow Leopard version.


http://www.opensource.apple.com/source/Libc/Libc-498/secure/strncat_chk.c
http://www.opensource.apple.com/source/Libc/Libc-583/secure/strncat_chk.c

(note the removed dstlen++)



Since it's a relatively simple problem, however, a workaround might be  
to make your destination buffer one character larger?


Kind regards,

Alastair.

--
http://alastairs-place.net



___

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

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

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

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

[OT] Re: llvm-gcc-4.2 link-time error seen from command line but not in Xcode 3.2

[Alastair Houghton]

On 29 Aug 2009, at 12:21, Jay Reynolds Freeman wrote:


Can anyone provide advice?


Yes.  Ask your question on xcode-users, *not* cocoa-dev.  It has  
nothing to do with Cocoa and so it's off-topic for this list.


Kind regards,

Alastair.

--
http://alastairs-place.net



___

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

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

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

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

Re: Get error message about registered observers when Object receives dealloc message

[Andreas Grosam]

On Aug 29, 2009, at 2:29 AM, Graham Cox wrote:


Thank you Graham for your reply.


Hi Andreas,

There is a strong code smell here.

How does your observee know who its observers are?
Actually, it does not. My example  code is an oversimplification to  
show the actual issue. Often, things are much more complex, and  
explainig them may draw people away from the actual problem. ;)


The *Observer*  will do this:

- (void) dealloc {
   [self.observee removeObserver:self forKeyPath:key];
}


However, in my code the *Observee* will receive the dealloc method  
first, which in turn causes all its  "child" objects - the Observers -  
to receive its dealloc message - which is shown above. Here, the  
observee is the "parent" object that owns the child objects.



So, the call path is about this:

[observee release]
[observee dealloc]
[observer release]
[observer dealloc]
[observee removeObserver:observer 
forKeyPath:key]


Since KVO doesn't normally provide that knowledge to the observee,  
you must have arranged this yourself, possibly going considerably  
out of your way to do so. Whenever you find yourself having to add  
great gobs of code to "supplement" the built-in mechanism, something  
should start alarm bells ringing that you are doing it wrong. And I  
speak from experience here since when I first experimented with KVO,  
I made exactly this mistake too.


A basic principle of KVO is that an observee is, by design, happily  
unaware of who's watching it. In consequence, the only object(s)  
that are responsible for stopping observing are the observers  
themselves - the observee should not attempt to "chuck off" its  
observers.


This leads to the question of what to do when an observed object is  
deallocated. Your design should have ensured that all observers have  
stopped observing by then - if it makes it as far as dealloc and  
there are still observers registered (as the error message you're  
getting indicates) then it's too late.
As you can see in the call path, I didn't ensure this. dealloc is send  
to the observer, before KVO is unregistered. Although, it is  
**guaranteed** that all observers will be unregistered in this code.  
Just too late. But I'm wondering *why* this is too late.




This is not quite the chicken-and-egg situation it appears.  
Typically an observed object is owned by another object, and that  
owning object might be an observer. So whenever the owner adds or  
removes an object, it would also set up/tear down the KVO  
observations. It's hard to give more concrete advice without knowing  
more about your design, but the bottom line is - observees cannot  
and should not be managing their observers.


Well, the actual object hierarchy is more complex. At the root there  
is the "Model". The Model owns a number of other child objects.
The child objects are organized in dictionaries and arrays and in a  
tree structure. So, now imagine that any child object may be an  
observer to any other child object. From the view point of the model,  
the ownership seems to be clear: the model owns the children.
But in order to let a certain child observe a model's property (say a  
"model.dictionary.object" key path) (which is just another child) -  
the ownership should be circumvented. This requirement is a  
contradiction.



Please also read my reply to Roland King's answer. I think I have to  
introduce some "shutdown" method, that will be send to each object in  
the hierarchy, before the dealloc message is received. This shutdown  
message will orderly tear down the object hierarchy - without  
deallocating the objects.



Regards
Andreas




--Graham






On 28/08/2009, at 11:56 PM, Andreas Grosam wrote:

I'm using key-value-observing where an instance of class MyObservee  
has been registered for KVO with other objects which observe a  
value in a key path (e.g.: @"drives.model.port"):


The observee itself unregisters all observers in its dealloc method:

@implementation MyObservee
- (void) dealloc
{
  [self removeAllObservers];  // basicly:  [self  
removeObserver:observer forKeyPath:key];


  [super dealloc];
}


The observers are sill alive when the observee receives its dealloc  
message.


When the observed instance receives its dealloc message, I'm  
getting this error message in the console, before the first line of  
code in the dealloc method will be executed (note: BEFORE [super  
deallocate] has been invoked):



2009-08-28 14:57:49.753 MyApp[886:20b] An instance 0xd21b60 of  
class MyObservee is being deallocated while key value observers are  
still registered with it. Observation info is being leaked, and may  
even become mistakenly attached to some other object. Set a  
breakpoint on NSKVODeallocateBreak to stop here in the debugger.  
Here's the current observation info:

 (
drives.model.port, Options:  Context:  
0x16df0, Property: 0xd38990>

...


The class MyObservee 

Re: Get error message about registered observers when Object receives dealloc message

[Jean-Daniel Dupas]

Le 29 août 2009 à 14:08, Andreas Grosam a écrit :



On Aug 29, 2009, at 2:29 AM, Graham Cox wrote:


Thank you Graham for your reply.


Hi Andreas,

There is a strong code smell here.

How does your observee know who its observers are?
Actually, it does not. My example  code is an oversimplification to  
show the actual issue. Often, things are much more complex, and  
explainig them may draw people away from the actual problem. ;)


The *Observer*  will do this:

- (void) dealloc {
  [self.observee removeObserver:self forKeyPath:key];
}


However, in my code the *Observee* will receive the dealloc method  
first, which in turn causes all its  "child" objects - the Observers  
- to receive its dealloc message - which is shown above. Here, the  
observee is the "parent" object that owns the child objects.



So, the call path is about this:

[observee release]
[observee dealloc]
[observer release]
[observer dealloc]
[obse
rvee removeObserver:observer forKeyPath:key]



Did you try on Snow Leopard.

http://developer.apple.com/mac/library/releasenotes/Cocoa/Foundation.html
Bug Fixes in Debugging of Objects Being Deallocated With Observers  
Still Registered When Not Running Garbage-Collected (Updated since  
March 2009 Seed)

[…]
There was another bug in which this logging was done spuriously when  
an object observed by a second object was deallocated, its  
deallocation caused the release of the second object, and the second  
object correctly unregistered itself as an observer of the first  
object at that time due to its own deallocation. This bug has also has  
been fixed in Mac OS 10.6.




___

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

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

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

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

"Format not a string literal and no format arguments"

[Jonathan del Strother]

After upgrading to snow leopard & Xcode 3.2, I've starting getting
this warning on NSLogs -

NSLog(@"Hello");  //   'Format not a string literal and no format arguments'
NSLog(@"Hello %@", name);   // compiles fine


I must have some weird project setting somewhere since a new test
project didn't throw these warnings, but I can't see what it is.  Any
suggestions?
___

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

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

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

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

Re: Get error message about registered observers when Object receives dealloc message

[Roland King]

Well first off you're not really, really doing anything wrong, that  
message is in the wrong place (in my opinion), it should only come up  
when the NSObject dealloc is called if things haven't been unobserved.  
There's a comment in this thread about this having been fixed,  
hopefully it is.


Still there's a couple of comments I'd make. Again I can fully  
understand why you've done it this way and I can easily imagine doing  
just the same. However observation is a sort of loose-coupling  
protocol, as you can see even though you don't retain your observee,  
you've kind of made a coupling with it which is orthogonal to dealloc.  
Normally an observee has no idea who's observing it and normally the  
observer will retain the observee to stop it going away, and remove  
its own observation in its dealloc just before releasing the object it  
had been observing. If it goes that way around, you don't have a  
problem.


So is there a way you can turn your retain graph upside down so that  
children retain their parents (and observe them) and that's what keeps  
the parents alive? Then you have your observation and retention aligned.


If you can't then, given the way you describe your design, you're in a  
position where the parent actually knows what its children are .. in  
which case .. KVO isn't necessarily the right protocol for you, if you  
know who your children are you could easily have them all implement a  
protocol you yourself design and sends them the changes directly. Then  
you don't have this issue at all, there's no KVO which is going 'the  
wrong way' and needs to be torn down in dealloc and in fact you have a  
direct coupling to your 'observers'. You also save all the setup and  
tear down and any other overhead of KVO.


Something like that would of course not be as 'free' as KVO, you'd  
need to actually write the code to send out the changes, in which case  
you may have decided that KVO is better than writing your own direct  
protocol in which case .. you've already sort of done what I suggested  
in the last paragraph, you've just used KVO to do it for you. In that  
case personally I believe you haven't really done anything wrong and  
the message is just in the wrong place. If that's been fixed, you  
probably don't have a problem.


On Aug 29, 2009, at 7:30 PM, Andreas Grosam wrote:



On Aug 28, 2009, at 5:32 PM, Roland King wrote:

Thank you Roland for your reply.


I think this is one of those unfortunate messages which comes out  
before the dealloc method even runs, just entering the dealloc  
method with registered observers logs it. It's possible it would be  
better if it was only logged at the point say NSObject dealloc was  
called, but it's not, it's called at the start of your own dealloc.


That either indicates it's a bug in the message because it doesn't  
allow for the case where a dealloc method unregisters the things  
observing it .. or perhaps you're not really supposed to be doing  
it there. Normally an object will register its interest in  
observing another object and the same object will then unregister  
later. It's a little unusual for an object to unhook the objects  
which are observing it. Actually how are you even doing that, do  
you have a list of all the objects and paths which are observing you?


Actually, the provided code is a over-simplification. My object  
hierarchy looks as follows:


Model   ( provides the properties where other objects can register  
for observing it)

   dictionary of objects that are observers

The "child" objects contain a weak reference to its parent Model  
(Model is not retained, otherwise I would establish a circular  
reference).



During setup, child objects register itself as observers, observing  
one or more properties of its parent object Model:


- setup {
  ...
  [self.model addObserver: self
   forKeyPath: key
  options: NSKeyValueObservingOptionInitial
  context: NSSelectorFromString([ports  
objectForKey:key])];


   ...
}

When Model gets deallocated, it releases the dictionary, which  
releases the observer objects, which in turn invokes their dealloc  
method:


- (void) dealloc {
   [self.model removeObserver:self forKeyPath:key];
   ...
}





I can sort of see how this might happen in practice, you create an  
object who's lifetime is determined by external factors, but  
observers hook up to it without retaining it and .. do something  
with observations of the key properties. Eventually the object gets  
released because all the other things which cared about it release  
it and you want to remove the observations and dealloc is the  
natural place to do that.


Yes, that may describe it. Actually, as shown above, there is an  
object hierarchy, where child objects are owned by its respective  
parent object. The child object's life time is (shall be) controlled  
by the parent object. However, there may be times where other objets  
get refere

Re: NSTextView moves when being resized ???

[Reinhard Segeler]

The coordinate-system for a view starts with the lower left corner,  
not at the upper left. There is command, that sets the coordinate  
system to the upper left corner, but I can't find it right now. But I  
guess, that the first info is what you need to know.


Reinhard

Am 29.08.2009 um 12:38 schrieb Anders Lassen:


Hi,

I am working on a custom view that consists of a column of several  
NSTextViews. In between, there are graphics and some other stuff  
that require special editing.


Therefore I cannot use a single NSTextView.

The NSTextView must adopt its height to the content. This works fine  
using the code as listed below.


But the problem is, that the NSTextView control moves downwards when  
the size is changed.


  textView = [[NSTextView alloc] initWithFrame:NSMakeRect(100, 100,  
300, 200)];


  [self addSubview:textView];

  [textView setVerticallyResizable:YES];

  [textView setAutoresizingMask NSViewHeightSizable];

  [textView setMinSize:NSMakeSize(0.0, 100.0)];
  [textView setMaxSize:NSMakeSize(FLT_MAX, FLT_MAX)];


I have read about others having the same problem, but I did not find  
a solution.


Note that the NSTextView is a subview to a custom view, that is the  
content view of a NSScrollView. But this does not matter - I think.


Hope someone can help on this.

Kind regards,

Anders Lassen


___

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

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

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

This email sent to macmeid...@googlemail.com


___

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

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

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

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

multiple nsrunalert panels

[Rick C.]

hello,

i'm using nsrunalertpanel successfully except if i will make another app active 
and then make my own app active again it will display a duplicate panel even 
though i have never yet acknowledged the original one.  actually if i keep 
switching back and forth between active apps it will continue to create 
duplicate panels.  any help would be appreciated thank you,

rick


  
___

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

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

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

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

Re: multiple nsrunalert panels

[I. Savant]

On Aug 29, 2009, at 11:40 AM, Rick C. wrote:

i'm using nsrunalertpanel successfully except if i will make another  
app active and then make my own app active again it will display a  
duplicate panel even though i have never yet acknowledged the  
original one.  actually if i keep switching back and forth between  
active apps it will continue to create duplicate panels.  any help  
would be appreciated thank you,


  Our crystal ball is in the shop. Code, please. :-)

  Specifically, how are you creating and showing the panel? Where is  
this creating/showing code located (ie, what calls it)? This is the  
bare minimum of what we need to know to help you.


--
I.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 arch...@mail-archive.com

Re: Testing 32/64 bit and/or PPC

[Timothy Reaves]

On Aug 28, 2009, at 11:13 PM, Chris Idou wrote:





If you have a universal binary, 32/64 and/or PPC, is there a way to  
force it to run


one way or the other for testing purposes?





	There is, but you probably shouldn't.  A Universal binary needs to  
have the tests run for all platforms, as it's very easy to write code,  
and a test for that code, where the test passes, but the code will  
fail on a different platform.  It takes more time to run the tests,  
but forcing them to run on only one platform (for a Universal) defeats  
the purpose of testing.



___

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

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

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

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

Re: NSTextView moves when being resized ???

[Reinhard Segeler]

Hallo Anders,
did you receive my message below, because that solves the problem. I  
have checked, that in a testproject.


The explanation is: If you set a new max width/height its calculated  
and drawn from the origin, which is the lower left edge of your view.


You find more details in the NSView documentation


The coordinate-system for a view starts with the lower left corner,  
not at the upper left. There is command, that sets the coordinate  
system to the upper left corner, but I can't find it right now. But I  
guess, that the first info is what you need to know.


Reinhard

Am 29.08.2009 um 12:38 schrieb Anders Lassen:


Hi,

I am working on a custom view that consists of a column of several  
NSTextViews. In between, there are graphics and some other stuff  
that require special editing.


Therefore I cannot use a single NSTextView.

The NSTextView must adopt its height to the content. This works fine  
using the code as listed below.


But the problem is, that the NSTextView control moves downwards when  
the size is changed.


 textView = [[NSTextView alloc] initWithFrame:NSMakeRect(100, 100,  
300, 200)];


 [self addSubview:textView];

 [textView setVerticallyResizable:YES];

 [textView setAutoresizingMask NSViewHeightSizable];

 [textView setMinSize:NSMakeSize(0.0, 100.0)];
 [textView setMaxSize:NSMakeSize(FLT_MAX, FLT_MAX)];


I have read about others having the same problem, but I did not find  
a solution.


Note that the NSTextView is a subview to a custom view, that is the  
content view of a NSScrollView. But this does not matter - I think.


Hope someone can help on this.

Kind regards,

Anders Lassen


___

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

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

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

This email sent to macmeid...@googlemail.com


___

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

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

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

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

Re: Normalize an NSAttributedString

[Ross Carter]

On Aug 26, 2009, at 1:21 PM, Ken Thomases wrote:


On Aug 26, 2009, at 10:43 AM, Michael Ash wrote:

On Wed, Aug 26, 2009 at 5:42 AM, Ken Thomases  
wrote:

On Aug 25, 2009, at 7:21 PM, Ross Carter wrote:


I haven't tried it, but this should work:

  NSAttributedString* original = whatever;
  NSMutableAttributedString* normalized = [[original  
mutableCopy]

autorelease];
  CFMutableStringRef str = (CFMutableStringRef)[original
mutableString];
  CFStringNormalize(str, kCFStringNormalizationFormD);

This works because -[NSMutableAttributedString mutableString] is  
a proxy

that automatically fixes up the attribute runs held by its owner.


Hmm, this seems dangerous in the sense that the conversion may be  
lossy.  As
far as I can see, there's no guarantee that CFStringNormalize will  
perform
minimal replacements.  If it does not, then whole ranges of  
characters may

have their attributes reset to that of the first replaced character.

Even if testing reveals it to be non-lossy under one testing  
environment,
without a guarantee that might differ under any other testing  
environment.


http://en.wikipedia.org/wiki/Unicode_equivalence

[... quote snipped ...]


I'm well aware of what it means.  The question is, which exact  
operations on the mutable string proxy does CFStringNormalize  
perform.  If CFStringNormalize performs the minimal replace  
operations to get the result, then it will preserve the attributes  
closely.  It's conceivable, though, that CFStringNormalize uses a  
side buffer to compute the normalized form and then does one big  
replace of the whole mutable string's range.  Or, anywhere in  
between.  Like, it might replace a series of precomposed characters  
with their decompositions all with one replace operation.  In that  
case, the attributes of most of the characters will be lost  
(replaced with the attributes of the first character in the replace  
range).


So, it's clear that the _strings_ will always have a deterministic  
value as a result of normalization.  That's the point of  
normalization.  But the _attributed strings_ may not.



Also, it should be self-evident that normalizing to a precomposed  
form will
obliterate attribute differences between a base character and any  
combining

characters, as discussed elsewhere in this thread.


Good thing he went and normalized to a *de*composed form then,  
isn't it?


Martin's example used Form D, but Ross never quite said that's what  
he was normalizing to.  He might have been adapting Martin's example  
but using a different form.


Regards,
Ken



Just to make it clear what my situation is:

Suppose an NSAttributedString comprises the string o + umlaut in  
decomposed form, plus one attribute. Its length is 2, and the range of  
an attribute is {0, 2}. The string and its attribute are archived  
separately as xml data like this:

ö
NSFontAttributeName
Helvetica 12.0

If, during unarchiving, the string is represented by an NSString  
object in precomposed form, its length will be 1, and an attempt to  
apply the attribute range of {0, 2} will fail.


From the discussion here it seems to me that the only safe approach  
is to normalize the NSAttributedString to Form D before archiving  
(using Martin's approach), and when unarchiving to normalize the  
unarchived NSString to form D before combining it with the attribute  
to make an NSAttributedString.


Ross___

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

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

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

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

Re: Auto complete accepts on space, any way to change?

[Ross Carter]

On Aug 28, 2009, at 12:02 PM, Ben Lachman wrote:

My app, SousChef, uses the AppKit autocomplete functionality in a  
bunch of places.  Currently if a user types "So" they are presented  
with a list of completions and the first actual completion ("Soup")  
is used inline and selected so that this completed part is used if  
the user tabs to the next item but isn't if the user keeps typing  
(e.g. "up" is selected, "So" is not).  However in recently we've  
noticed that if you are typing through an autocomplete and hit  
space, the current completion is accepted and the space is appended  
to it.  This is unwanted behavior.  However in Safari's location  
bar, which has the functionality I want, if you hit space, the space  
is appended to the partial word instead of the full completion.   
Anyone have an idea of how to get this behavior of just accepting on  
enter/tab (cancel on escape already works)?  Currently I'm only  
implementing - 
textView:completionsForPartialWordRange:indexOfSelectedItem:.  I  
thought to override keyDown: but the problem is that the field  
editor is eating keystrokes.


I guess your field editor could override complete: and not call super  
if the user has just typed a space.

___

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

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

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

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

Re: libcrypto on Snow Leopard

[Charles Srstka]

On Aug 28, 2009, at 7:07 PM, Steven Degutis wrote:


The solution to this is pretty simple, don't link to libcrypto.
Instead, just #import  in your file and  
use the

CC_ prefixed functions in your app, such as CC_MD5.


Another solution is to use CDSA, which Apple provides in the Security  
framework, and which seems to work pretty well. Too bad it's so poorly  
documented, though.


Charles
___

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

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

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

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

Re: Normalize an NSAttributedString

[Ken Thomases]

On Aug 29, 2009, at 11:46 AM, Ross Carter wrote:

Suppose an NSAttributedString comprises the string o + umlaut in  
decomposed form, plus one attribute. Its length is 2, and the range  
of an attribute is {0, 2}. The string and its attribute are archived  
separately as xml data like this:

ö
NSFontAttributeName
Helvetica 12.0

If, during unarchiving, the string is represented by an NSString  
object in precomposed form, its length will be 1, and an attempt to  
apply the attribute range of {0, 2} will fail.


But why would it change between archiving and unarchiving?

Regards,
Ken

___

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

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

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

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

Re: Get error message about registered observers when Object receives dealloc message

[Quincey Morris]

On Aug 29, 2009, at 06:00, Roland King wrote:

Well first off you're not really, really doing anything wrong, that  
message is in the wrong place (in my opinion), it should only come  
up when the NSObject dealloc is called if things haven't been  
unobserved. There's a comment in this thread about this having been  
fixed, hopefully it is.


If I understand what's been said in this thread, Andreas *is* doing  
something wrong. He's in good company, though, because the retain/ 
release mechanism has traditionally allowed many Cocoa developers to  
do it wrong over the years. It's only now that the chickens are coming  
home to roost.


There are actually two things wrong here. One is that it's not  
*generally* safe to manage lifetimes of mutually dependent objects in  
their 'dealloc' methods. In this case, Andreas has said, observing  
objects are being released in the observed object's 'dealloc', and the  
released (and therefore deallocated) observing objects are messaging  
the partially torn down observed object from their own 'dealloc'. With  
very careful coding, Andreas *might* be able to make this kind of  
thing safe *for the part of the object behavior that he controls*, but  
he can't make it safe for the parts he doesn't control (e.g. behavior  
inherited from the frameworks).


The second is that one of the behaviors he doesn't control --  
unregistration of observers -- is not permitted during the 'dealloc'  
of the observed object, and must be done before that. That's what the  
log message is trying to say. The bug fixes described in the Snow  
Leopard release notes *don't* permit this requirement to be ignored.  
[In fact, the notes explicitly say that the consequences are memory  
leaks and observation info getting attached to the wrong object.]  
Instead, Snow Leopard corrects the detection of the problem in the  
retain/release case. That's why log messages have suddenly started  
appearing. Andreas' implementation was always wrong, but it's only  
being reported correctly now.


This is not news to anyone who's been using garbage collection, which  
has always had the same restriction, and enforced it. The solution (as  
stated earlier in this thread) is to unregister the observers of an  
observed object while it is still owned (RR: retained; GC: referenced)  
by something.


This sort of "release your resources" cleanup is sometimes much harder  
to do without relying on 'dealloc', because you lose the automatic  
"notification" of the end of an object's lifetime that 'dealloc'  
implies. Nevertheless, it's necessary because of KVO registrations,  
and it's necessary because of garbage collection.


I wish the frameworks did provide some kind of end-of-lifetime  
detection that would trigger a notification before object destruction  
begins. This would be something like a counterpart to 'awakeFromNib',  
which is a kind of beginning-of-lifetime notification after object  
initialization is complete. But there isn't anything like that in the  
frameworks (yet), so we have to do it the hard way.



___

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

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

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

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

Re: "Format not a string literal and no format arguments"

[Quincey Morris]

On Aug 29, 2009, at 05:36, Jonathan del Strother wrote:


After upgrading to snow leopard & Xcode 3.2, I've starting getting
this warning on NSLogs -

NSLog(@"Hello");  //   'Format not a string literal and no format  
arguments'

NSLog(@"Hello %@", name);   // compiles fine


I must have some weird project setting somewhere since a new test
project didn't throw these warnings, but I can't see what it is.  Any
suggestions?


This is addressed in the Snow Leopard Foundation release notes (under  
NSString). This should now produce a warning:


NSString* hello = @"Hello";
NSLog (hello);

but this should not:

NSLog (@"Hello");

Is that what you're seeing?




___

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

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

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

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

Re: NSTextView moves when being resized ???

[Anders Lassen]

Hi Reinhard,

Thanks for helping.

I have just tried to flip the coordinate system of the custom view by  
overriding the isFlipped method, and it did solve the problem.



Kind regards,

Anders Lassen


On Aug 29, 2009, at 6:13 PM, Reinhard Segeler wrote:


Hallo Anders,
did you receive my message below, because that solves the problem. I  
have checked, that in a testproject.


The explanation is: If you set a new max width/height its calculated  
and drawn from the origin, which is the lower left edge of your view.


You find more details in the NSView documentation


The coordinate-system for a view starts with the lower left corner,  
not at the upper left. There is command, that sets the coordinate  
system to the upper left corner, but I can't find it right now. But  
I guess, that the first info is what you need to know.


Reinhard

Am 29.08.2009 um 12:38 schrieb Anders Lassen:


Hi,

I am working on a custom view that consists of a column of several  
NSTextViews. In between, there are graphics and some other stuff  
that require special editing.


Therefore I cannot use a single NSTextView.

The NSTextView must adopt its height to the content. This works  
fine using the code as listed below.


But the problem is, that the NSTextView control moves downwards  
when the size is changed.


textView = [[NSTextView alloc] initWithFrame:NSMakeRect(100, 100,  
300, 200)];


[self addSubview:textView];

[textView setVerticallyResizable:YES];

[textView setAutoresizingMask NSViewHeightSizable];

[textView setMinSize:NSMakeSize(0.0, 100.0)];
[textView setMaxSize:NSMakeSize(FLT_MAX, FLT_MAX)];


I have read about others having the same problem, but I did not  
find a solution.


Note that the NSTextView is a subview to a custom view, that is the  
content view of a NSScrollView. But this does not matter - I think.


Hope someone can help on this.

Kind regards,

Anders Lassen


___

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

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

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

This email sent to macmeid...@googlemail.com




___

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

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

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

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

Re: bin2c GUI tool? [OT]

[Greg Guerin]

Erg Consultant wrote:


Does anyone make a GUI version of bin2c for OS X?



This isn't a Cocoa question, so is off-topic for this list.

Maybe you can merge bin2c's source into HexFiend as a new Export or  
Save As option. Or bundle bin2c's command-line executable into a  
Platypus app.


Find HexFiend source or Platypus.app source using google.

  -- GG

___

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

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

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

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

Applying color to template images

[Mitchell Livingston]

Hello,

I want to use NSImage's built-in template images, but want to replace  
the black color with different colors, such as gray or orange. I feel  
like I'm missing something obvious, but I can't seem to figure this  
out. Could someone point me in the right direction.


Thanks,
Mitch
___

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

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

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

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

Re: "Format not a string literal and no format arguments"

[Jonathan del Strother]

No - I really am seeing NSLog(@"Hello") producing a warning.  I did
find the culprit, though - OTHER_CFLAGS=-fno-constant-cfstrings.  The
project is for a loadable bundle - I guess I need to dig around to
figure out if I can safely get rid of it...

On Sat, Aug 29, 2009 at 6:36 PM, Quincey
Morris wrote:
> On Aug 29, 2009, at 05:36, Jonathan del Strother wrote:
>
>> After upgrading to snow leopard & Xcode 3.2, I've starting getting
>> this warning on NSLogs -
>>
>> NSLog(@"Hello");  //   'Format not a string literal and no format
>> arguments'
>> NSLog(@"Hello %@", name);   // compiles fine
>>
>>
>> I must have some weird project setting somewhere since a new test
>> project didn't throw these warnings, but I can't see what it is.  Any
>> suggestions?
>
> This is addressed in the Snow Leopard Foundation release notes (under
> NSString). This should now produce a warning:
>
>        NSString* hello = @"Hello";
>        NSLog (hello);
>
> but this should not:
>
>        NSLog (@"Hello");
>
> Is that what you're seeing?
>
>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/maillist%40steelskies.com
>
> This email sent to maill...@steelskies.com
>
___

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

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

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

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

Re: [OT] Re: llvm-gcc-4.2 link-time error seen from command line but not in Xcode 3.2

[Jay Reynolds Freeman]

On Aug 29, 2009, at 4:37 AM, Alastair Houghton wrote:

> Yes.  Ask your question on xcode-users, *not* cocoa-dev.  It has  
nothing to do with Cocoa and so it's off-topic for this list.


Sincere apologies to Alastair and possibly to others, but I posted to  
cocoa-dev because this issue has to do with one of the standard  
compilers used for Cocoa, and very likely with the standard libraries  
or frameworks that Cocoa projects link with; I thought that sounded  
like a Cocoa topic, and a search of the short descriptions of the  
Apple mailing lists turned up no better choice.  It may be that my  
problem falls through the cracks between the list topics.


I do not actually have an Xcode problem; the code I enquired about  
links successfully under Xcode; notwithstanding, I just did repost to  
the Xcode list, based on Alastair's advice.


--  Jay Reynolds Freeman
-
jay_reynolds_free...@mac.com
http://web.mac.com/jay_reynolds_freeman (personal web site)

___

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

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

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

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

Re: "Format not a string literal and no format arguments"

[Peter Duniho]

On Aug 29, 2009, at 10:36 AM, Quincey Morris wrote:


On Aug 29, 2009, at 05:36, Jonathan del Strother wrote:


After upgrading to snow leopard & Xcode 3.2, I've starting getting
this warning on NSLogs -

NSLog(@"Hello");  //   'Format not a string literal and no format  
arguments'

NSLog(@"Hello %@", name);   // compiles fine


I must have some weird project setting somewhere since a new test
project didn't throw these warnings, but I can't see what it is.  Any
suggestions?


This is addressed in the Snow Leopard Foundation release notes  
(under NSString). This should now produce a warning:


NSString* hello = @"Hello";
NSLog (hello);

but this should not:

NSLog (@"Hello");


Am I reading the right documentation?  On this page:
http://developer.apple.com/mac/library/releasenotes/Cocoa/Foundation.html

I see this text:

Foundation APIs which take string format arguments (APIs
such as initWithFormat:, NSLog(), etc) are now decorated
with attributes which allow the compiler to generate
warnings on potentially unsafe usages. This currently
includes usage such as:
NSString *str = ...;
NSString *formattedStr = [[NSString alloc] initWithFormat:str];
where the format is not a constant and there are no arguments.
In a case like above, the call to initWithFormat: is
unnecessary, so to avoid warnings, just drop the call. In
a case like NSLog(str), you can instead use NSLog(@"%@", str).

I read that to mean that one will get the warning for _any_ call to  
initWithFormat:, even those automatically generated by NSLog() (thus  
the suggestion in the text for a work-around so as to prevent the  
warning).


(Aside: The wording of the warning also seems weird to me, assuming  
Jonathan quoted it verbatim.  Why should a non-literal string format  
be any more or less likely to include formatting specifiers that would  
require format arguments?  Or is it implied that the compiler is doing  
compile-time verification of the format string when a literal is  
provided?)


Not having Snow Leopard, nor Xcode 3.2, I can't test this myself and I  
suppose I might be misunderstanding the question or the answer.  But  
it looks to me as though any usage of initWithFormat: that doesn't  
pass format arguments will generate the warning, even NSLog(@"Hello").


Is there some more specific documentation of the warning available  
somewhere?  I tried searching the docs for the warning text provided  
in the previous post, but didn't find anything.  Searching the web  
using Google suggests that this is a gcc feature, intended for use  
where actual string literals (e.g. "Hello", not @"Hello") would appear  
(e.g. printf()), but based on the comments I saw in that context, it's  
not clear to me why this warning would be all that useful in the  
context of Cocoa anyway (since most "literals" are really NSString  
objects, not checkable by the compiler).


Perhaps due to my inexperience, I am missing something here and  
NSLog() really shouldn't generate the warning. If so, please feel free  
to set me straight.  :)


Pete
___

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

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

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

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

Re: "Format not a string literal and no format arguments"

[Jay Reynolds Freeman]

As a possibly useful aid to understanding, I have seen what is very  
likely a related problem while compiling with llvm-gcc-4.2 from the  
command line; the problem there had to do with strict error checking  
of places where the current formal declaration of a function such as  
"fprintf" expects a format string, and where the source code in  
question provided not a literal string (C string) but a pointer to  
one, and also did not provide any extra arguments to be formatted.   
Thus for example, a command-line compile of the form


/Developer/usr/bin/llvm-gcc-4.2  -o bug bug.c++

in which the code contains the lines:

const char *formatString = "The answer is forty-two\n";
fprintf( stdout, formatString );
fputs( formatString, stdout );

generates the warning

bug.c++: In function ‘int main()’:
bug.c++:11: warning: format not a string literal and no format  
arguments


for the line using fprintf, but no warning for the line using fputs.

See the g++ documentation for Wno_format, which I found a little  
confusing ...  :-)


I also saw that same error message in Xcode compiles (Snow Leopard /  
Xcode 3.2, using llvm-gcc-4.2) of ".mm" files in which I had happened  
to use "fprintf" or "printf" in the offending manner.  In those cases,  
I was able to toggle the warning by checking and unchecking the box  
for "Typecheck Calls to printf/scanf", which is in the "LLVM GCC 4.2 -  
Warnings" section of the build tab in the Xcode information window for  
the target in question.


--  Jay Reynolds Freeman
-
jay_reynolds_free...@mac.com
http://web.mac.com/jay_reynolds_freeman (personal web site)


___

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

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

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

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

Re: "Format not a string literal and no format arguments"

[Quincey Morris]

On Aug 29, 2009, at 11:54, Peter Duniho wrote:

Or is it implied that the compiler is doing compile-time  
verification of the format string when a literal is provided?


Sort of, but not exactly. The first parameter to NSLog is *really* a  
format string, not just a string. If an arbitrary string passed as the  
first parameter happens to contain a stray '%' character, that's  
likely going to result in a crash.


So if you provide a string literal, there's no warning because it's  
assumed you're not going to hard-code stray '%' characters in it. If  
you provide arguments after the string (whether literal or not), it's  
assumed you've made sure the string really is a format string. If you  
provide a non-ilteral string and no arguments, there's a fair chance  
that you've forgotten that some potential string values will blow up,  
hence the warning.


The compiler's reasoning is heuristic, not impeccable. You can  
certainly do the wrong thing using a string literal too (or by giving  
the wrong number of arguments, for that matter), but the warning is  
generated in a commonly-overlooked case, not in all potentially buggy  
cases.


In Jonathan's case, the string *looked* like a literal in the source  
code, but wasn't, because of his compile options. Presumably his non- 
literal string is never going to get changed to something bad, but  
he'll have to code around it to keep the compiler from complaining.



___

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

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

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

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

Re: "Format not a string literal and no format arguments"

[Ken Thomases]

On Aug 29, 2009, at 1:54 PM, Peter Duniho wrote:


Am I reading the right documentation?  On this page:
http://developer.apple.com/mac/library/releasenotes/Cocoa/Foundation.html

I see this text:

   Foundation APIs which take string format arguments (APIs
   such as initWithFormat:, NSLog(), etc) are now decorated
   with attributes which allow the compiler to generate
   warnings on potentially unsafe usages. This currently
   includes usage such as:
   NSString *str = ...;
   NSString *formattedStr = [[NSString alloc] initWithFormat:str];
   where the format is not a constant and there are no arguments.
   In a case like above, the call to initWithFormat: is
   unnecessary, so to avoid warnings, just drop the call. In
   a case like NSLog(str), you can instead use NSLog(@"%@", str).

I read that to mean that one will get the warning for _any_ call to  
initWithFormat:, even those automatically generated by NSLog() (thus  
the suggestion in the text for a work-around so as to prevent the  
warning).


(Aside: The wording of the warning also seems weird to me, assuming  
Jonathan quoted it verbatim.  Why should a non-literal string format  
be any more or less likely to include formatting specifiers that  
would require format arguments?  Or is it implied that the compiler  
is doing compile-time verification of the format string when a  
literal is provided?)


Not having Snow Leopard, nor Xcode 3.2, I can't test this myself and  
I suppose I might be misunderstanding the question or the answer.   
But it looks to me as though any usage of initWithFormat: that  
doesn't pass format arguments will generate the warning, even  
NSLog(@"Hello").


Is there some more specific documentation of the warning available  
somewhere?  I tried searching the docs for the warning text provided  
in the previous post, but didn't find anything.  Searching the web  
using Google suggests that this is a gcc feature, intended for use  
where actual string literals (e.g. "Hello", not @"Hello") would  
appear (e.g. printf()), but based on the comments I saw in that  
context, it's not clear to me why this warning would be all that  
useful in the context of Cocoa anyway (since most "literals" are  
really NSString objects, not checkable by the compiler).


Objective-C @"..." strings are still literals and constants, despite  
also being objects.


You misunderstand when you "read that to mean that one will get the  
warning for _any_ call to initWithFormat:".  It happens when you pass  
a non-constant format string and no arguments.


The problem case they are trying to avoid is something like this:

NSString* str = [self getAnArbitraryStringFromTheUserOrAnUnknownSource];
NSLog(str);

What if str ends up containing percent signs?  Then the string- 
formatting machinery behind NSLog will attempt to treat them as  
formatting specifiers. It will likely try to access arguments to be  
formatted, arguments which aren't there, resulting in undefined  
behavior, possibly including crashing your app or corrupting your  
data.  This sort of thing is a pernicious bug which can also be taken  
advantage of by malicious hackers.


So, using -initWithFormat: (or any other properly decorated string- 
formatting method or function) with a constant format string allows  
the compiler to check the format string and verify the argument list  
to be sure it meets the requirements of the format strings.  (So, yes,  
it is "implied that the compiler is doing compile-time verification of  
the format string when a literal is provided".)


When you don't provide a constant format string but you do provide  
arguments, it is assumed that you at least haven't made the most  
common form of mistake.  Your code seems to recognize that the first  
argument is a format string which may require further arguments.  In  
this case, the compiler can't check consistency between the format  
string and the subsequent arguments, but generating a warning would  
flag too much correct code.


Lastly, yes, this is the same GCC feature as used in C.  It has been  
extended to understand Objective-C -- it recognizes Objective-C string  
literals and also the %@ format specifier.


Regards,
Ken

___

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

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

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

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

Re: Get error message about registered observers when Object receives dealloc message

[Andreas Grosam]

On Aug 29, 2009, at 7:28 PM, Quincey Morris wrote:


On Aug 29, 2009, at 06:00, Roland King wrote:

Well first off you're not really, really doing anything wrong, that  
message is in the wrong place (in my opinion), it should only come  
up when the NSObject dealloc is called if things haven't been  
unobserved. There's a comment in this thread about this having been  
fixed, hopefully it is.


If I understand what's been said in this thread, Andreas *is* doing  
something wrong. He's in good company, though, because the retain/ 
release mechanism has traditionally allowed many Cocoa developers to  
do it wrong over the years. It's only now that the chickens are  
coming home to roost.
Just to be clear, the code is running on the iPhone, hence there is no  
GC. Secondly, there is no issue with release or retain. If I invoke  
release from within a dealloc in order to release a certain object, I  
have to do it exactly the same way - even when the current KVO issue  
has been corrected somehow in my code. So, retain/release is unrelated  
to the current problem. The solution to my problem seems to be to  
unregister all KVO *before* the object hierarchy gets deallocated.




There are actually two things wrong here. One is that it's not  
*generally* safe to manage lifetimes of mutually dependent objects  
in their 'dealloc' methods.
If the dealloc method does not directly or indirectly invoke a method  
of any object that is currently deallocated, the design should be  
safe. But I wouldn't recommend it, because it may become a problem  
later when code changes.


In this case, Andreas has said, observing objects are being released  
in the observed object's 'dealloc', and the released (and therefore  
deallocated) observing objects are messaging the partially torn down  
observed object from their own 'dealloc'. With very careful coding,  
Andreas *might* be able to make this kind of thing safe *for the  
part of the object behavior that he controls*, but he can't make it  
safe for the parts he doesn't control (e.g. behavior inherited from  
the frameworks).


The second is that one of the behaviors he doesn't control --  
unregistration of observers -- is not permitted during the 'dealloc'  
of the observed object,
This is actually the piece of information that I am searching for. So,  
can I take this for a fact? I'm asking because then I don't understand  
the bug fixes mentioned in

http://developer.apple.com/mac/library/releasenotes/Cocoa/Foundation.html
 (please see Jean-Daniels reply)

Though, I don't see why this is a *second* problem - IMHO it's just a  
concrete reason of the one problem.



and must be done before that.
That's why I am proposing myself to introduce a new method -shutdown  
in my classes which is responsible to tear down the dependencies from  
any objects within the hierarchy -- before the root object starts to  
release any object, including itself.



That's what the log message is trying to say. The bug fixes  
described in the Snow Leopard release notes *don't* permit this  
requirement to be ignored. [In fact, the notes explicitly say that  
the consequences are memory leaks and observation info getting  
attached to the wrong object.] Instead, Snow Leopard corrects the  
detection of the problem in the retain/release case. That's why log  
messages have suddenly started appearing. Andreas' implementation  
was always wrong, but it's only being reported correctly now.
I don't know what Snow Leopard is reporting in my case - I'm running  
10.5.8 and this is an iPhone application. So, there are chances that  
the log that I'm getting now is still incorrect - although there  
actually might be real problems.




This is not news to anyone who's been using garbage collection,  
which has always had the same restriction, and enforced it. The  
solution (as stated earlier in this thread) is to unregister the  
observers of an observed object while it is still owned (RR:  
retained; GC: referenced) by something.

Understand.



This sort of "release your resources" cleanup is sometimes much  
harder to do without relying on 'dealloc', because you lose the  
automatic "notification" of the end of an object's lifetime that  
'dealloc' implies.
Absolutely. Even when I have a mechanism to tear down an object  
hierarchy via a shutdown message, after shutdown has been received,  
the object is effectively invalid. If there exists a third object that  
holds a reference to this torn down object, problems may occur since  
the object became invalid prematurely.


Nevertheless, it's necessary because of KVO registrations, and it's  
necessary because of garbage collection.


I wish the frameworks did provide some kind of end-of-lifetime  
detection that would trigger a notification before object  
destruction begins. This would be something like a counterpart to  
'awakeFromNib', which is a kind of beginning-of-lifetime  
notification after object initialization is complete. But ther

Testing localizations in 10.6

[Dylan McNamee]

Way back before Snow Leopard, I was able to test a localization by  
right-clicking on my application, and "un-checking" all of the  
languages except for the one I wanted to test.


Today, however, I see that portion of the "Get Info" window is  
missing.  What do folks suggest for testing localization?


Just to make sure I wasn't running with a non-standard setup, I did  
some Googling, and was comforted to see this post from a month ago,  
describing exactly what I remember seeing under Leopard and before:


http://www.macfixit.com/article.php?story=20090702161741495

thanks!
dylan


___

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

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

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

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

Re: "Format not a string literal and no format arguments"

[Ken Thomases]

On Aug 29, 2009, at 2:19 PM, Quincey Morris wrote:


On Aug 29, 2009, at 11:54, Peter Duniho wrote:

Or is it implied that the compiler is doing compile-time  
verification of the format string when a literal is provided?


Sort of, but not exactly.


Actually, yes exactly.

So if you provide a string literal, there's no warning because it's  
assumed you're not going to hard-code stray '%' characters in it.


No such thing is assumed.  If you provide a string literal, the  
compiler actual checks it and the arguments to make sure they're  
consistent with each other.


$ cat foo.c
#include 
int main(void)
{
printf("%d\n", "blah");
return 0;
}
$ cc -Wall -o foo foo.c
foo.c: In function ‘main’:
foo.c:4: warning: format ‘%d’ expects type ‘int’, but argument  
2 has type ‘char *’


Regards,
Ken

___

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

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

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

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

Re: Testing localizations in 10.6

[Ken Thomases]

On Aug 29, 2009, at 2:29 PM, Dylan McNamee wrote:

Way back before Snow Leopard, I was able to test a localization by  
right-clicking on my application, and "un-checking" all of the  
languages except for the one I wanted to test.


Today, however, I see that portion of the "Get Info" window is  
missing.  What do folks suggest for testing localization?


In the Language & Text (née International) pane of System Preferences,  
set the Formats/Region and Language preferences to the language and  
region you want to test.  Launch your app.  Set the system preferences  
back.


Regards,
Ken

___

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

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

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

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

Re: Testing localizations in 10.6

[Jean-Daniel Dupas]

Le 29 août 2009 à 21:29, Dylan McNamee a écrit :

Way back before Snow Leopard, I was able to test a localization by  
right-clicking on my application, and "un-checking" all of the  
languages except for the one I wanted to test.


Today, however, I see that portion of the "Get Info" window is  
missing.  What do folks suggest for testing localization?


Just to make sure I wasn't running with a non-standard setup, I did  
some Googling, and was comforted to see this post from a month ago,  
describing exactly what I remember seeing under Leopard and before:


http://www.macfixit.com/article.php?story=20090702161741495



I'm launching it from Xcode passing the following as argument (change  
'en' to the language you want to test):


-AppleLanguages ('en')

Note this it works for all Cocoa applications:

For example, try this in the terminal:

/Applications/TextEdit.app/Contents/MacOS/TextEdit -AppleLanguages  
"('fr')"



___

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

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

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

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

Re: Testing localizations in 10.6

[Gideon King]

This is also a problem if the users can't set it on an app by app  
basis easily - I know we have a number of users who have their  
operating system set to one language, but choose to have several  
specific applications running in English.


Gideon


On 30/08/2009, at 5:46 AM, Jean-Daniel Dupas wrote:



Le 29 août 2009 à 21:29, Dylan McNamee a écrit :

Way back before Snow Leopard, I was able to test a localization by  
right-clicking on my application, and "un-checking" all of the  
languages except for the one I wanted to test.


Today, however, I see that portion of the "Get Info" window is  
missing.  What do folks suggest for testing localization?


Just to make sure I wasn't running with a non-standard setup, I did  
some Googling, and was comforted to see this post from a month ago,  
describing exactly what I remember seeing under Leopard and before:


http://www.macfixit.com/article.php?story=20090702161741495



I'm launching it from Xcode passing the following as argument  
(change 'en' to the language you want to test):


-AppleLanguages ('en')

Note this it works for all Cocoa applications:

For example, try this in the terminal:

/Applications/TextEdit.app/Contents/MacOS/TextEdit -AppleLanguages  
"('fr')"


___

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

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

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

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

Correct way to have nil undo manager in Core Data document?

[Jerry Krinock]

From the Core Data Programming Guide:

"If you do not intend to use Core Data's undo functionality, you can  
reduce your application's resource requirements by setting the  
context’s undo manager to nil. This may be especially beneficial for  
background worker threads..."


Well, I've got a background worker process which opens an  
NSPersistenDocument.  Since it has no "undo" capability, I want to set  
it to nil as recommended.  (I have other reasons for not wanting an  
undo manager scurrying around.)  But the document doesn't like having  
nil undo manager.  When I ask for it later, it creates one for itself,  
and sets its managed object context to have the same one.


This is easily demonstrated by adding the following method to  
DepartmentAndEmployees project, in the implementation of MyDocument:


- (id)init {
self = [super init] ;
if (self) {
// Set both doc's and moc's undo manager to nil
[[self managedObjectContext] setUndoManager:nil] ;
[self setUndoManager:nil] ;

// Get and log them
NSLog(@"1: moc's undoManager = %@", [[self  
managedObjectContext] undoManager]) ;

NSLog(@"2: doc's undoManager = %@", [self undoManager]) ;
NSLog(@"3: moc's undoManager = %@", [[self  
managedObjectContext] undoManager]) ;

}

return self ;
}

Here is the debugger Log Output, with breakpoint set at - 
[NSManagedObjectContext setUndoManager:]


Running…
(gdb) continue
(gdb) continue
(gdb) continue
(gdb) continue
Test[61463:813] 1: moc's undoManager = (null)   ## This is good.
(gdb) p/a *(int *)($esp+8)
$1 = 0x161a80
(gdb) continue
Test[61463:813] 2: doc's undoManager =   ##  
Arghh!!
Test[61463:813] 3: moc's undoManager =   ##  
Arghh!!


Here is the call stack at the last break.  I typed the p/a command  
when viewing #1.


#0  0x92af7cf6 in -[NSManagedObjectContext setUndoManager:]
#1  0x91cc3f4d in -[NSPersistentDocument setUndoManager:]
#2  0x91969ea9 in -[NSDocument undoManager]
#3  0x2f0f in -[MyDocument init] at MyDocument.m:358

Apparently when -[NSDocument undoManager] sees that its undo manager  
is nil (because I set it to nil), it says to itself, "Golly, we need  
an undo manager here.  So it creates one, sets it in the subclass - 
[NSPersistentDocument setUndoManager:], which in turn says, "Gee, our  
moc needs this too", and then invokes -[NSManagedObjectContext  
setUndoManager:].


The obvious solution would be to add to the init method:

   [self setHasUndoManager:nil] ;

which would probably work for NSDocument but for NSPersistentDocument,  
the documentation says:


   "Overridden to be a no-op  ... You should not override this method.
The persistent document uses the managed object context’s undo  
manager."


Overriding -hasUndoManager didn't work either.  It's never invoked.

However, my third guess seems to be working.  In the MyDocument  
implementation I overrode...


- (NSUndoManager*)undoManager {
return nil ;
}

This seems to work.  I can add employees, delete employees, open and  
save documents, and there are no crashes or whineys printed to the  
console.  In the menu, Edit > Undo is always disabled, as expected.


In my actual application, my document subclass is in a framework, of  
which my non-gui background worker and the gui app are thin wrappers.   
So, I condition the code in the above methods with if(!NSApp).


Am I violating the "spirit of the docs" here, or is this solution OK?

Sincerely,

Jerry Krinock

___

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

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

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

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

Re: Get error message about registered observers when Object receives dealloc message

[Quincey Morris]

On Aug 29, 2009, at 12:26, Andreas Grosam wrote:

Just to be clear, the code is running on the iPhone, hence there is  
no GC. Secondly, there is no issue with release or retain. If I  
invoke release from within a dealloc in order to release a certain  
object, I have to do it exactly the same way - even when the current  
KVO issue has been corrected somehow in my code. So, retain/release  
is unrelated to the current problem. The solution to my problem  
seems to be to unregister all KVO *before* the object hierarchy gets  
deallocated.


No, there's no issue with calling the 'release' and 'retain' methods.  
It's an issue of object lifetimes -- what and when. Incidentally,  
although GC isn't an iPhone issue now, I can't imagine that GC won't  
become available on the iPhone in the next couple of years. (Perhaps  
when CPU horsepower and battery life limitations have eased enough.)


If the dealloc method does not directly or indirectly invoke a  
method of any object that is currently deallocated, the design  
should be safe. But I wouldn't recommend it, because it may become a  
problem later when code changes.


Yours may be safe. Mine wasn't, the last time I wrote a non-GC app  
(which is nearly 2 years now). I managed to so overload the semantics  
of dealloc that I couldn't get my data model to go away. :)


Though, I don't see why this is a *second* problem - IMHO it's just  
a concrete reason of the one problem.


It really is just one problem, but I was trying to forestall comments  
like, "Well, things would be just fine if Apple didn't place this  
arbitrary restriction on unregistering." It's one problem, but it's  
larger than just unregistering.


Absolutely. Even when I have a mechanism to tear down an object  
hierarchy via a shutdown message, after shutdown has been received,  
the object is effectively invalid. If there exists a third object  
that holds a reference to this torn down object, problems may occur  
since the object became invalid prematurely.


I think you have two ways to approach this. One is ensure that your  
design correctly decides when an object is no longer needed, so that  
the question of messaging an "invalid" object never arises. The other  
is to put the object into a shutdown state, where messaging it is  
either harmless or returns an error or throws an exception.


How could this be implemented? When an object gets deallocated it  
always previously received release with retain count one or - in  
case of GC - the last reference diminished. When this happens, it is  
already to late for a notification.


This will probably make you laugh, or worse, but I think in the  
hardest cases the best solution will turn out to be ... reference  
counting (implemented manually). That is, if the criterion for when a  
shared object should free its resources is really as vague as "when no  
one wants the object any more", the object could track how many other  
objects have registered interest in it, using a pseudo-retain/pseudo- 
release messaging protocol.


Think of it this way. An object really has 2 lifetimes -- visibility  
and existence. GC (and other factors) take existence mostly outside  
your control (aside from housekeeping), but visibility is what you  
really care about.



___

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

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

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

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

Re: "Format not a string literal and no format arguments"

[Quincey Morris]

On Aug 29, 2009, at 12:31, Ken Thomases wrote:

No such thing is assumed.  If you provide a string literal, the  
compiler actual checks it and the arguments to make sure they're  
consistent with each other.


I expressed myself badly. Because that check produces a different  
warning, I was thinking of it as a different check.


It's actually not clear (to me) whether the two warnings are  
controlled by the same compiler options. AFAIK -Wno-format (which used  
to be the default in the build setting) would turn off the type  
mismatch warning, but I don't know whether it would turn off the new  
warning too (which seems to depend on an __attribute decoration).



___

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

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

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

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

Re: learning the NSView structure of an app?

[Sean Kline]

Hi,
This may not be what you are looking for, but in Interface Builder, there
are a couple of ways to look at what views you have:

- Look at the various View Modes and drill into views, to see view
hierarchies
- Within a particular view, press "Shift" "Right-mouse" and you will see a
view hierarchy.

Regards

On Fri, Aug 28, 2009 at 12:08 PM, sag lists  wrote:

> Hi,
>
>  As a relatively new cocoa developer, one thing I struggle with is
> determining on visual inspection how an app is constructed in terms cocoa
> views.  Some things are obvious like splitter views, the toolbar, etc.  But
> some are not.  Does anyone know if there is a way to examine the view
> hierarchy of an app? Or alternatively, a good way to learn many of the
> common app layout patterns?
>
> 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/skline1967%40gmail.com
>
> This email sent to skline1...@gmail.com
>
___

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

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

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

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

Re: Correct way to have nil undo manager in Core Data document?

[Quincey Morris]

On Aug 29, 2009, at 13:01, Jerry Krinock wrote:

Apparently when -[NSDocument undoManager] sees that its undo manager  
is nil (because I set it to nil), it says to itself, "Golly, we need  
an undo manager here.  So it creates one, sets it in the subclass - 
[NSPersistentDocument setUndoManager:], which in turn says, "Gee,  
our moc needs this too", and then invokes -[NSManagedObjectContext  
setUndoManager:].


The obvious solution would be to add to the init method:

  [self setHasUndoManager:nil] ;

which would probably work for NSDocument but for  
NSPersistentDocument, the documentation says:


  "Overridden to be a no-op  ... You should not override this method.
   The persistent document uses the managed object context’s undo  
manager."


Overriding -hasUndoManager didn't work either.  It's never invoked.

However, my third guess seems to be working.  In the MyDocument  
implementation I overrode...


- (NSUndoManager*)undoManager {
   return nil ;
}


AFAIK, the problem is that NSPersistentDocument overrides *some* of  
NSDocument's undo-related methods, but not all, and calling the un- 
overridden ones really messes things up -- you can end up with 2 undo  
managers, one in a NSDocument private instance variable that's never  
used, plus the real one in the MOC.


IIRC, the correct strategy is to nil just the one in the MOC and take  
your grubby fingers completely off the NSDocument so that  
NSPersistentDocument can puts its own grubby fingers on it.


I think your third solution overrides NSPersistentDocument's override  
of NSDocument's undoManager, which is probably a Bad Idea, although it  
probably works fine in this case because you don't want any undo  
manager at all (so you're returning what the NSPersistentDocument  
override would have returned.)



___

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

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

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

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

Re: Normalize an NSAttributedString

[Ross Carter]

On Aug 29, 2009, at 1:22 PM, Ken Thomases wrote:


On Aug 29, 2009, at 11:46 AM, Ross Carter wrote:

Suppose an NSAttributedString comprises the string o + umlaut in  
decomposed form, plus one attribute. Its length is 2, and the range  
of an attribute is {0, 2}. The string and its attribute are  
archived separately as xml data like this:

ö
NSFontAttributeName
Helvetica 12.0

If, during unarchiving, the string is represented by an NSString  
object in precomposed form, its length will be 1, and an attempt to  
apply the attribute range of {0, 2} will fail.


But why would it change between archiving and unarchiving?


Because during unarchiving, the NSString is created by NSXMLParser and  
I assume that there is no guarantee regarding the normalization form  
of that string. NSXMLParser might decompose the string, for example.  
It seems to me that to rely on NSXMLParser always to returns strings  
in a particular form is to rely on an implementation detail.


Admittedly I have not observed any such funny business. I just assume  
it is possible.


Ross___

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

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

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

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

Core Data observer exception in 10.6

[David Sinclair]

Hi,

In a Core Data-based app that works fine in 10.5.x, I now get an  
exception as follows in 10.6 when opening a document.  It targets  
10.5, and the same exception occurs when rebuilding on 10.6 (still  
targeting 10.5, but also when targeting 10.6).


I don't register or unregister any observers myself, and the exception  
occurs without touching any of my code.  What's going on?



NSRangeException: Cannot remove an observer 0x15476c0> for the key path "richText" from   
because it is not registered as an observer.

 1  +[NSException raise:format:arguments:] (in CoreFoundation) + 136
 2  +[NSException raise:format:] (in CoreFoundation) + 58
 3	-[NSObject(NSKeyValueObserverRegistration)  
_removeObserver:forProperty:] (in Foundation) + 765
 4	-[NSObject(NSKeyValueObserverRegistration)  
removeObserver:forKeyPath:] (in Foundation) + 176
 5	-[NSKeyValueNestedProperty  
object:didRemoveObservance:recurse:] (in Foundation) + 544
 6	-[NSObject(NSKeyValueObserverRegistration)  
_removeObserver:forProperty:] (in Foundation) + 453
 7	-[NSObject(NSKeyValueObserverRegistration)  
removeObserver:forKeyPath:] (in Foundation) + 176
 8	-[_NSModelObservingTracker  
_registerOrUnregister:observerNotificationsForModelObject:] (in  
AppKit) + 228
 9	-[_NSModelObservingTracker clearAllModelObjectObserving] (in  
AppKit) + 341
10	-[_NSModelObservingTracker  
setIndexReferenceModelObjectArray:clearAllModelObjectObserving:] (in  
AppKit) + 51

11  -[NSArrayController _setObjects:] (in AppKit) + 196
12	-[NSArrayController  
_arrangeObjectsWithSelectedObjects:avoidsEmptySelection:operationsMask:useBasis 
:] (in AppKit) + 510

13  -[NSArrayController rearrangeObjects] (in AppKit) + 133
14	-[NSArrayController  
observeValueForKeyPath:ofObject:change:context:] (in AppKit) + 338

15  NSKeyValueDidChange (in Foundation) + 377
16	-[NSObject(NSKeyValueObservingPrivate)  
_didChangeValuesForKeys:] (in Foundation) + 565

17  _PFFaultHandlerFulfillFault (in CoreData) + 1921
18  _PFFaultHandlerLookupRow (in CoreData) + 1573
19  -[NSFaultHandler fulfillFault:withContext:] (in CoreData) + 39
20  _PF_FulfillDeferredFault (in CoreData) + 193
21  _sharedIMPL_pvfk_core (in CoreData) + 65
22	-[NSManagedObject(_PFDynamicAccessorsAndPropertySupport)  
_genericValueForKey:withIndex:flags:] (in CoreData) + 79

23  -[NSManagedObject valueForKey:] (in CoreData) + 244
24	-[NSKeyValueNestedProperty object:didAddObservance:recurse:]  
(in Foundation) + 240
25	-[NSObject(NSKeyValueObserverRegistration)  
_addObserver:forProperty:options:context:] (in Foundation) + 812
26	-[NSObject(NSKeyValueObserverRegistration)  
addObserver:forKeyPath:options:context:] (in Foundation) + 565
27	-[_NSModelObservingTracker  
_registerOrUnregister:observerNotificationsForKeyPath:ofModelObject:]  
(in AppKit) + 134
28	-[_NSModelObservingTracker  
_registerOrUnregister:observerNotificationsForModelObject:] (in  
AppKit) + 228
29	-[_NSModelObservingTracker _startObservingModelObject:] (in  
AppKit) + 418
30	-[_NSModelObservingTracker  
startObservingModelObjectsAtReferenceIndexes:] (in AppKit) + 333
31	-[NSArrayController  
_arrangeObjectsWithSelectedObjects:avoidsEmptySelection:operationsMask:useBasis 
:] (in AppKit) + 510

32  -[NSArrayController setContent:] (in AppKit) + 889
33	-[NSArrayController(NSManagedController)  
_performFetchWithRequest:merge:error:] (in AppKit) + 501
34	-[NSObjectController(NSManagedController)  
fetchWithRequest:merge:error:] (in AppKit) + 209
35	-[NSObjectController(NSManagedController)  
_executeFetch:didCommitSuccessfully:actionSender:] (in AppKit) + 106

36  _NSSendCommitEditingSelector (in AppKit) + 339
37	-[NSController _controllerEditor:didCommit:contextInfo:] (in  
AppKit) + 216

38  __invoking___ (in CoreFoundation) + 29
39  -[NSInvocation invoke] (in CoreFoundation) + 136
40  -[NSInvocation invokeWithTarget:] (in CoreFoundation) + 72
41  __NSFireDelayedPerform (in Foundation) + 537
42  __CFRunLoopRun (in CoreFoundation) + 6846


Immediately after that exception is a related one, which sounds more  
helpful, but still doesn't make sense to me:


NSInternalInconsistencyException: Cannot remove an observer  
 for the key path "text.richText" from  
, most likely because the value for the key  
"text" has changed without an appropriate KVO notification being sent.  
Check the KVO-compliance of the ChapterEntity class.

 1  +[NSException raise:format:arguments:] (in CoreFoundation) + 136
 2  +[NSException raise:format:] (in CoreFoundation) + 58
 3	-[NSKeyValueNestedProperty  
object:didRemoveObservance:recurse:] (in Foundation) + 457
 4	-[NSObject(NSKeyValueObserverRegistration)  
_removeObserver:forProperty:] (in Foundation) + 453
 5	-[NSObject(NSKeyValueObserverRegistration)  
removeObserver:forKeyPath:] (in Foundation) + 176
 6	-[_NSModelObserv

virtual ivars

[Todd Heberlein]

I've been playing with KVC and KVO with my own setters and getters  
(along with Controllers) to create virtual ivars. That is, there never  
is any storage created for the variable and its value is calculated on  
the fly when the getter is called. This seems to have some cool  
potential, but it raises the following question:


Could this break with future Xcode or OS X upgrades?

In other words, is this approach an officially supported way to code  
by Apple, or do they have the freedom to break this in the future?



Thanks,

Todd


Simple example where the ivar "myInt" never really exists:

@interface MyObj : NSObject  {
NSWindow *window;
}
@property (assign) IBOutlet NSWindow *window;

-(int)myInt;
-(void)setMyInt:(int)newVal;

@end




-(int)myInt
{
return 43;
}

-(void)setMyInt:(int)newVal
{
// do nothing right now
}


___

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

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

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

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

Copying records from to-many relationship in Core Data

[Sean Kline]

Folks,
I have a Core Data application with two entities (relevant to this question)
with a to-many relationship between them.  When I create a new record in
Entity 1, I would like to copy the to-many records from Entity 2 from that
last record created into the new record.  I tried to execute a fetch into an
array, but whenever I do this the table that is bound to Entity 1 displays
two records.  There may be something bizarre that I have done causing this
behavior, but does anyone have any general advice or examples to help me
achieve what I am trying to do?

Thanks,

- 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 arch...@mail-archive.com

Re: "Format not a string literal and no format arguments"

[Ken Thomases]

On Aug 29, 2009, at 3:24 PM, Quincey Morris wrote:

It's actually not clear (to me) whether the two warnings are  
controlled by the same compiler options. AFAIK -Wno-format (which  
used to be the default in the build setting) would turn off the type  
mismatch warning, but I don't know whether it would turn off the new  
warning too (which seems to depend on an __attribute decoration).


GCC knows about the standard formatting functions and applies the  
analysis to them automatically, by default.  However, it also allows  
the application of the __attribute__((format ...)) decoration to user- 
defined functions to have them checked in the same way.  This applies  
to all of the formatting-related warnings.


There's -Wformat and -Wformat-security (among a few others).  The  
former checks the types, the latter also warns about a lone non- 
literal argument. -Wformat-security is ignored if -Wformat is not  
enabled, so -Wno-format disables both.


Both warnings are available in GCC 4.0.1, but not enabled by default.   
They are apparently both enabled by default in GCC 4.2.1.  (Currently,  
-Wformat-security is a subset of -Wformat-nonliteral, which is  
apparently not enabled by default.  It warns when the format string is  
a non-literal even if it's followed by arguments.)


Regards,
Ken

___

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

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

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

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

Re: Drawing Text in an NSImage

[Seth Willits]

On Aug 27, 2009, at 9:37 PM, Henry McGilton (Boulevardier) wrote:


drawAtPoint/drawInRect in NSString/NSAttributedString says...

"You should only invoke this method when an NSView object has focus."
"Don’t invoke this method while no NSView is focused."

When an image is focused, and you draw text, it'll definitely do  
wonky things if the currently focused view is flipped. If we can't  
use these methods, are we really supposed to drop down to  
NSLayoutManager etc etc to draw a simple string? Is there really no  
secret API for image-friendly string drawing? Just want to double  
check before I have to go invent one...


Not quite sure what is the problem you're having here, Seth.

Create your NSImage.lockFocus on the image.Draw into the  
image.
i have two apps that draw into images using drawAtPoint, and I don't  
see

any problems relating to views . . .


String drawing always happens relative to the view's orientation, not  
the image's. If the view is flipped and you draw into an image, then  
draw that image, the string will be upside down. That's the reason I'm  
assuming they say not to do it.




On Aug 27, 2009, at 11:30 PM, Uli Kusterer wrote:

I think, for the discussion of this particular API, an NSView object  
having focus includes the case of an NSImage object having focus.  
You may want to file a documentation bug requesting clarification.


Except experimentation says otherwise. The only way to get it to work  
is to apply an NSAffineTransform manually to trick the string into  
drawing the correct way (when the view is flipped).


If you know you have to do that it's not so bad, but it's a pain in  
the butt trying to figure out that you need to do it.



--
Seth Willits



___

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

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

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

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

Re: Normalize an NSAttributedString

[Ken Thomases]

On Aug 29, 2009, at 3:48 PM, Ross Carter wrote:


On Aug 29, 2009, at 1:22 PM, Ken Thomases wrote:


On Aug 29, 2009, at 11:46 AM, Ross Carter wrote:

Suppose an NSAttributedString comprises the string o + umlaut in  
decomposed form, plus one attribute. Its length is 2, and the  
range of an attribute is {0, 2}. The string and its attribute are  
archived separately as xml data like this:

ö
NSFontAttributeName
Helvetica 12.0

If, during unarchiving, the string is represented by an NSString  
object in precomposed form, its length will be 1, and an attempt  
to apply the attribute range of {0, 2} will fail.


But why would it change between archiving and unarchiving?


Because during unarchiving, the NSString is created by NSXMLParser  
and I assume that there is no guarantee regarding the normalization  
form of that string. NSXMLParser might decompose the string, for  
example. It seems to me that to rely on NSXMLParser always to  
returns strings in a particular form is to rely on an implementation  
detail.


You can't rely on it to always return strings in a particular form.   
You should be able to rely on it to return strings in the form in  
which they were written.


Admittedly I have not observed any such funny business. I just  
assume it is possible.


I do not.  If an XML library/framework were to fail to maintain the  
round-trip integrity of my data, I would consider that a bug.


Apple's NSXML documents (which, admittedly, don't quite apply to  
NSXMLParser) reference , which  
defines an XML string data type, with this definition:


The string datatype represents character strings in XML. The ·value  
space· of string is the set of finite-length sequences of characters  
(as defined in [XML 1.0 (Second Edition)]) that ·match· the Char  
production from [XML 1.0 (Second Edition)]. A character is an atomic  
unit of communication; it is not further specified except to note  
that every character has a corresponding Universal Character Set  
code point, which is an integer.


To me, this definition prohibits an XML parser from considering a  
string as anything other than a sequence of characters.  That is, it  
can't apply knowledge about Unicode canonical equivalence or  
decomposition, etc.  You put in a sequence of characters, you get out  
that sequence of characters.  (The schema also defines a  
normalizedString data type, but that uses a completely different sense  
of normalization than we're discussing.)


Regards,
Ken

___

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

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

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

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

Re: Core Data observer exception in 10.6

[Kyle Sluder]

--Kyle Sluder

On Aug 29, 2009, at 1:48 PM, David Sinclair  wrote:

In a Core Data-based app that works fine in 10.5.x, I now get an  
exception as follows in 10.6 when opening a document.  It targets  
10.5, and the same exception occurs when rebuilding on 10.6 (still  
targeting 10.5, but also when targeting 10.6).


There is an active thread going about this exception *right now.* Did  
you check the list archives before posting? The answer is also in the  
10.6 release notes, did you read those?


I don't register or unregister any observers myself, and the  
exception occurs without touching any of my code.  What's going on?


Cocoa Bindings use KVO, and you have no idea if internally Core Data  
(or any other code for that matter) does as well.


--Kyle Sluder



___

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

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

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

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

Re: virtual ivars

[Kyle Sluder]

On Aug 29, 2009, at 1:49 PM, Todd Heberlein   
wrote:


I've been playing with KVC and KVO with my own setters and getters  
(along with Controllers) to create virtual ivars. That is, there  
never is any storage created for the variable and its value is  
calculated on the fly when the getter is called. This seems to have  
some cool potential, but it raises the following question:


   Could this break with future Xcode or OS X upgrades?

In other words, is this approach an officially supported way to code  
by Apple, or do they have the freedom to break this in the future?


If you can't set a value, don't provide a setter. If a setter might  
not set the value the user provides, disable disable KVO notification  
for that key and do it yourself.


--Kyle Sluder
___

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

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

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

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

Re: virtual ivars

[Ken Thomases]

On Aug 29, 2009, at 3:49 PM, Todd Heberlein wrote:

I've been playing with KVC and KVO with my own setters and getters  
(along with Controllers) to create virtual ivars. That is, there  
never is any storage created for the variable and its value is  
calculated on the fly when the getter is called.


You are confusing, or perhaps just sloppily conflating, ivars with  
properties.


There's nothing "virtual" about an ivar.  It either exists or doesn't.

A property is part of the interface of your class.  It's defined by  
the methods, not by the implementation behind those methods.   
Therefore, it's very possible to have a property which is not back by  
an instance variable or any other kind of storage.



This seems to have some cool potential, but it raises the following  
question:


Could this break with future Xcode or OS X upgrades?

In other words, is this approach an officially supported way to code  
by Apple, or do they have the freedom to break this in the future?


It's supported.  It won't break.  It's inherent in the definition of  
properties.  That is, properties are independent of any particular  
implementation.  So long as the interface meets the rules of KVC  
compliance, the property is compliant.  For KVO, there are some rules  
imposed on the implementation, but none of them require that you have  
an instance variable backing the property.


Among other things, consider what the methods -valueForUndefinedKey:  
and -setValue:forUndefinedKey: are for.


All that said, however, you seem to think that a property requires a  
setter, even if it's empty.  It does not.  A read-only property can be  
implemented with just a getter and no setter.  In most cases, if you  
setter isn't going to do anything, you should just leave it out --  
neither declare nor implement it.


Regards,
Ken

___

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

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

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

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

Re: Drawing Text in an NSImage

[Kyle Sluder]

On Aug 29, 2009, at 2:21 PM, Seth Willits  wrote:

String drawing always happens relative to the view's orientation,  
not the image's. If the view is flipped and you draw into an image,  
then draw that image, the string will be upside down. That's the  
reason I'm assuming they say not to do it.


Sounds like a misunderstanding about image flippedness. Check the 10.6  
AppKit release notes and you'll see they have removed the flipped  
property altogether.


Also, the release notes indicate that drawing will not always happen  
in a window or view. You will always have a graphics context, though,  
so start thinking in terms of the context's Current Transformation  
Matrix.


--Kyle Sluder
___

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

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

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

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

Re: virtual ivars

[Todd Heberlein]

If you can't set a value, don't provide a setter.


I see from another post I was conflating "ivars" with "properties".  
With regards to the setters, I have some C++ libraries, and I was  
thinking about having "property" wrappers in an Objective C object  
doing setting and getting into values in the C++ object. I just didn't  
want to make the demo code very long. My bad for a poor example.


Todd

___

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

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

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

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

Re: Core Data observer exception in 10.6

[David Sinclair]

On Aug 29, 2009, at 14:35:23, Kyle Sluder wrote:


On Aug 29, 2009, at 1:48 PM, David Sinclair  wrote:

In a Core Data-based app that works fine in 10.5.x, I now get an  
exception as follows in 10.6 when opening a document.  It targets  
10.5, and the same exception occurs when rebuilding on 10.6 (still  
targeting 10.5, but also when targeting 10.6).


There is an active thread going about this exception *right now.*  
Did you check the list archives before posting? The answer is also  
in the 10.6 release notes, did you read those?


Thanks for the reply.  Are you referring to the "Get error message  
about registered observers when Object receives dealloc message"  
thread?  I did see that, but it didn't seem to be the same issue, as  
far as I could tell.  Perhaps I'm mistaken, though, since I don't  
really know what the issue is.


I haven't had time to read the 10.6 release notes in detail yet, but  
did search for likely areas.  Can you point me to the specific  
document and section?


I don't register or unregister any observers myself, and the  
exception occurs without touching any of my code.  What's going on?


Cocoa Bindings use KVO, and you have no idea if internally Core Data  
(or any other code for that matter) does as well.



Yes, I understand that, I was just pointing out that I couldn't find a  
bug in my code, unless it's a bug of omission.


--

David Sinclair, Dejal Systems, LLC - d...@dejal.com
Dejal blog - http://www.dejal.com/blog/
Cocoa code - http://www.dejal.com/developer/
Twitter - http://twitter.com/dejal/






___

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

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

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

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

Re: virtual ivars

[Todd Heberlein]

I see from another post I was conflating "ivars" with "properties".  
With regards to the setters, I have some C++ libraries, and I was  
thinking about having "property" wrappers in an Objective C object  
doing setting and getting into values in the C++ object.


So here is a slightly more detailed scenario while still trying to  
keep it as simple as possible.


My "Model" is captured in C++ code (i.e., "CppObj" below). I want to  
use normal Cocoa "View" objects (e.g., an NSTextField) and  
"Controller" objects (e.g., NSObjectController). So I create an  
Objective C object ("MyWrapper ") to wrap the C++ object, and access  
to the C++ content is done through "properties". Both the setters and  
getters reach down into the C++ object to set or get its values.


Things seem to be working. I just wanted to make sure I wasn't doing  
something illegal or not supported. I guess I have always had  
properties associated with actual variables, so it never occurred to  
me before that they are really independent things.


Todd


//- C++ model 
class CppObj {
public:
int myInt;
};


//- Objective-C++ wrapper 
@interface MyWrapper : NSObject  {
CppObj* p_cppObj;
}
-(int)myInt;
-(void)setMyInt:(int)newVal;
@end



//- getter/setter wrappers of C++ model 
-(int)myInt
{
return p_cppObj->myInt;
}

- (void)setMyInt:(int)newVal
{
p_cppObj->myInt = newVal;
}


___

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

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

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

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

Getting managedObject Context

[Clayton Leitch]

I have spent the last month try to solve a simple problem.  I need to  
get the managedObjectContext in a NSDocument based application.  I  
know how to get this in a non-document based application

 -(NSManagedObjectContect *)managedObjectContext {
if (!managedObjectContext) {
managedObjectContext = [[NSApp delegate] managedObjectContext];
}
return managedObjectContext;
}

From the documentation it appears that I get the managedObject  
Context from the MyDocument instead of the application delegate.  I  
tried a similar structure to the above replacing NSApp delegate with  
MyDocument.  Does anyone have an example of getting the  
manageObjectContext from the MyDocument class?


Please no flames,
I have read the core data programming guide.  I may have missed the  
reference.

___

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

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

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

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

Re: Getting managedObject Context

[Quincey Morris]

On Aug 29, 2009, at 15:59, Clayton Leitch wrote:

I have spent the last month try to solve a simple problem.  I need  
to get the managedObjectContext in a NSDocument based application.   
I know how to get this in a non-document based application

-(NSManagedObjectContect *)managedObjectContext {
if (!managedObjectContext) {
managedObjectContext = [[NSApp delegate] managedObjectContext];
}
return managedObjectContext;
}

From the documentation it appears that I get the managedObject  
Context from the MyDocument instead of the application delegate.  I  
tried a similar structure to the above replacing NSApp delegate with  
MyDocument.  Does anyone have an example of getting the  
manageObjectContext from the MyDocument class?


You haven't given quite enough information here.

If you mean that your documents are themselves Core Data stores, then  
you need your document subclass (MyDocument) to be a subclass of  
NSPersistentDocument instead of NSDocument. If you started from the  
Core Data document-based application template in Xcode, that's what  
you were given to start with. Then getting the MOC is easy --  
NSPersistentDocument has a 'managedObjectContext' property which you  
simply access.


Since you mention "replacing NSApp delegate with MyDocument", it's  
possible you're trying to get the MOC from your MyDocument *class*  
object ("[MyDocument managedObjectContext]"). If so, that of course  
doesn't work. It's an instance property ("[myDocument  
managedObjectContext]").


If you mean that your documents are not Core Data stores, but refer to  
a shared Core Data store, then of course you continue to ask the  
application delegate for the MOC.



___

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

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

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

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

Re: Getting managedObject Context

[Gideon King]

If you use NSPersistentDocument instead of NSDocument, it has all that  
already built in for you.


Gideon


On 30/08/2009, at 8:59 AM, Clayton Leitch wrote:

I have spent the last month try to solve a simple problem.  I need  
to get the managedObjectContext in a NSDocument based application.   
I know how to get this in a non-document based application

-(NSManagedObjectContect *)managedObjectContext {
if (!managedObjectContext) {
managedObjectContext = [[NSApp delegate] managedObjectContext];
}
return managedObjectContext;
}

From the documentation it appears that I get the managedObject  
Context from the MyDocument instead of the application delegate.  I  
tried a similar structure to the above replacing NSApp delegate with  
MyDocument.  Does anyone have an example of getting the  
manageObjectContext from the MyDocument class?




___

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

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

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

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

Re: virtual ivars

[Clark Cox]

That's fine, as you've written it. There is nothing special about the
methods used to implement properties; they're just methods. Wherever
you choose to store the actual data that backs the property is
immaterial.

On Sat, Aug 29, 2009 at 3:39 PM, Todd Heberlein wrote:
>> I see from another post I was conflating "ivars" with "properties". With
>> regards to the setters, I have some C++ libraries, and I was thinking about
>> having "property" wrappers in an Objective C object doing setting and
>> getting into values in the C++ object.
>
> So here is a slightly more detailed scenario while still trying to keep it
> as simple as possible.
>
> My "Model" is captured in C++ code (i.e., "CppObj" below). I want to use
> normal Cocoa "View" objects (e.g., an NSTextField) and "Controller" objects
> (e.g., NSObjectController). So I create an Objective C object ("MyWrapper ")
> to wrap the C++ object, and access to the C++ content is done through
> "properties". Both the setters and getters reach down into the C++ object to
> set or get its values.
>
> Things seem to be working. I just wanted to make sure I wasn't doing
> something illegal or not supported. I guess I have always had properties
> associated with actual variables, so it never occurred to me before that
> they are really independent things.
>
> Todd
>
>
> //- C++ model 
> class CppObj {
> public:
>        int     myInt;
> };
>
>
> //- Objective-C++ wrapper 
> @interface MyWrapper : NSObject  {
>        CppObj* p_cppObj;
> }
> -(int)myInt;
> -(void)setMyInt:(int)newVal;
> @end
>
>
>
> //- getter/setter wrappers of C++ model 
> -(int)myInt
> {
>        return p_cppObj->myInt;
> }
>
> - (void)setMyInt:(int)newVal
> {
>        p_cppObj->myInt = newVal;
> }
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com
>
> This email sent to clarkc...@gmail.com
>



-- 
Clark S. Cox III
clarkc...@gmail.com
___

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

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

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

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

Standard Alert Note/Warning/Stop icon NSImage Names?

[Seth Willits]

Are the standard alert icons (note, warning, and stop) available  
through standard image names (like NSApplicationIcon)? They don't seem  
to be.



--
Seth Willits



___

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

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

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

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

re: Correct way to have nil undo manager in Core Data document?

[Ben Trumbull]

Well, I've got a background worker process which opens an
NSPersistenDocument.  Since it has no "undo" capability, I want to set
it to nil as recommended.  (I have other reasons for not wanting an
undo manager scurrying around.)  But the document doesn't like having
nil undo manager.  When I ask for it later, it creates one for itself,
and sets its managed object context to have the same one.



You need to use the NSDocument API:

/* The document's undo manager. The default implementation of - 
setUndoManager:, in addition to recording the undo manager, registers  
the document as an observer of various NSUndoManager notifications so  
that -updateChangeCount: is invoked as undoable changes are made to  
the document. The default implementation of -undoManager creates an  
undo manager if the document does not already have one and - 
hasUndoManager would return YES. */

- (void)setUndoManager:(NSUndoManager *)undoManager;
- (NSUndoManager *)undoManager;

/* Whether or not the document has an undo manager. The default  
implementation of -setHasUndoManager: releases the document's current  
undo manager if it has one before the invocation but is not to have  
one afterward. */

- (void)setHasUndoManager:(BOOL)hasUndoManager;
- (BOOL)hasUndoManager;


- Ben



___

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

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

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

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

re: Core Data Predicate Builder - comparing dates

[Ben Trumbull]

I have a Core Data entity that has a dateCreated and a dateModified -
both NSDates in the object files.
I'd like to construct a predicate that will retrieve all records where
a record's dateModified is greater than that record's dateCreated.

Its deceptively easy to setup something that looks like it should work
using 'Control-click' and 'Key' in the predicate builder in XCode.
But when I run queries it doesn't appear to yield the right results.
My thinking is that the comparison operators don't properly evaluate
dates (am I wrong?)


Comparison operators work just fine on dates, although == and != are  
fragile since NSDates are double time stamps, and floating point  
numbers have odd == behavior.


What does the predicate look like ?  How is it not working ?  What  
does SQL logging show ?



So dropping back to code - how would I write this predicate in code?


[NSPredicate predicateWithFormat:@"dateModified > dateCreated"]

- Ben



___

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

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

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

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

re: Curious about $SUBST_VARS within a SUBQUERY of a fetch request template

[Ben Trumbull]

I just created a fetch request template in my MOM that looked like:
SUBQUERY(platformInfos, $each, $each.platformName ==
$PLATFORM_NAME)@count == 0

I then looked up the template in the code and attempted to use it in  
the

usual manner with:
fetchRequestFromTemplateWithName:substitutionVariables:


should work


Core Data complained that it could not resolve the SQL for
$each.platformName == $PLATFORM_NAME, "because of the RHS".

I would have thought that this variable would be replaced as normal,  
even
though it is inside a SUBQUERY.  Does anybody know if this is  
officially

disallowed, or a bug, or just developer-error somehow?


What your code look like for the substitution variables dictionary ?

- Ben



___

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

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

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

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

Re: Standard Alert Note/Warning/Stop icon NSImage Names?

[Kyle Sluder]

On Aug 29, 2009, at 5:24 PM, Seth Willits  wrote:

Are the standard alert icons (note, warning, and stop) available  
through standard image names (like NSApplicationIcon)? They don't  
seem to be.


They are on 10.6. See the AppKit release notes and NSImage.h. Don't  
miss the addition of the standard folder icon as well.


--Kyle Sluder



___

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

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

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

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

re: core-data app design question

[Ben Trumbull]

I have a question, or rather, I'm looking for advice, on the design of
an application. Essentially I'm wanting to write a labbook-type
application. My plan was to use core-data for the model. In the model
will be an Entry entity. Each entry will have a one-to-one
relationship to a Content entity. The Content entity will just (at the
moment) contain a single attribute (data) which will be binary data.
Implementing this on the Mac I planned to use NSTextView to provide a
rich-text entry for the data attribute. Now comes the problem. I want
to make a Cocoa Touch version of the app, and make then synchronize
over Mobile me. The problem is I see no way to handle the
NSAttributedString that will be stored in the data attribute on the
iPhone.

Does anyone have any advice as to how I might go about this? I was
considering dropping back to plain text, but am loath to do this.


Well, since you can't draw NSAttributedStrings on the iPhone, there  
isn't much point in archiving your data that way.  You should use a  
platform neutral text run.  You can write your own, which isn't hard  
for basic attributes, or you can use HTML instead, which you can draw  
on both platforms easily.


Encoding your data this way is pushing the boundaries of violating MVC  
patterns by archiving UI information (NSTextView drawing information)  
into your model (database).  That obviously doesn't work if the  
platform doesn't support NSTextView.


- Ben

___

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

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

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

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

Re: learning the NSView structure of an app?

[Rob Keniger]

On 29/08/2009, at 2:08 AM, sag lists wrote:

As a relatively new cocoa developer, one thing I struggle with is  
determining on visual inspection how an app is constructed in terms  
cocoa views. Some things are obvious like splitter views, the  
toolbar, etc.  But some are not.  Does anyone know if there is a way  
to examine the view hierarchy of an app? Or alternatively, a good  
way to learn many of the common app layout patterns?



If you launch your app executable with the argument -NSShowAllViews  
YES, then you will be able to see all the views and their hierarchy  
using color-coded border highlights.


You can either add the argument to your executable in Xcode or run  
your app from the command line:


./YourApp.app/Contents/MacOS/YourApp -NSShowAllViews YES


--
Rob Keniger



___

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

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

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

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

re: Core Data observer exception in 10.6

[Ben Trumbull]

In a Core Data-based app that works fine in 10.5.x, I now get an
exception as follows in 10.6 when opening a document.  It targets
10.5, and the same exception occurs when rebuilding on 10.6 (still
targeting 10.5, but also when targeting 10.6).

I don't register or unregister any observers myself, and the exception
occurs without touching any of my code.  What's going on?


NSRangeException: Cannot remove an observer  for the key path "richText" from 
because it is not registered as an observer.
 1	+[NSException raise:format:arguments:] (in CoreFoundation) +  
136

 2  +[NSException raise:format:] (in CoreFoundation) + 58
 3  -[NSObject(NSKeyValueObserverRegistration)
_removeObserver:forProperty:] (in Foundation) + 765
 4  -[NSObject(NSKeyValueObserverRegistration)
removeObserver:forKeyPath:] (in Foundation) + 176
 5  -[NSKeyValueNestedProperty
object:didRemoveObservance:recurse:] (in Foundation) + 544
 6  -[NSObject(NSKeyValueObserverRegistration)
_removeObserver:forProperty:] (in Foundation) + 453
 7  -[NSObject(NSKeyValueObserverRegistration)
removeObserver:forKeyPath:] (in Foundation) + 176
 8  -[_NSModelObservingTracker
_registerOrUnregister:observerNotificationsForModelObject:] (in
AppKit) + 228
 9  -[_NSModelObservingTracker clearAllModelObjectObserving] (in
AppKit) + 341
10  -[_NSModelObservingTracker
setIndexReferenceModelObjectArray:clearAllModelObjectObserving:] (in
AppKit) + 51
11  -[NSArrayController _setObjects:] (in AppKit) + 196
12  -[NSArrayController
_arrangeObjectsWithSelectedObjects:avoidsEmptySelection:operationsMask:useBasis
:] (in AppKit) + 510
13  -[NSArrayController rearrangeObjects] (in AppKit) + 133
14  -[NSArrayController
observeValueForKeyPath:ofObject:change:context:] (in AppKit) + 338
15  NSKeyValueDidChange (in Foundation) + 377
16  -[NSObject(NSKeyValueObservingPrivate)
_didChangeValuesForKeys:] (in Foundation) + 565
17  _PFFaultHandlerFulfillFault (in CoreData) + 1921
18  _PFFaultHandlerLookupRow (in CoreData) + 1573
19  -[NSFaultHandler fulfillFault:withContext:] (in CoreData) + 39
20  _PF_FulfillDeferredFault (in CoreData) + 193
21  _sharedIMPL_pvfk_core (in CoreData) + 65
22  -[NSManagedObject(_PFDynamicAccessorsAndPropertySupport)
_genericValueForKey:withIndex:flags:] (in CoreData) + 79
23  -[NSManagedObject valueForKey:] (in CoreData) + 244
24  -[NSKeyValueNestedProperty object:didAddObservance:recurse:]
(in Foundation) + 240
25  -[NSObject(NSKeyValueObserverRegistration)
_addObserver:forProperty:options:context:] (in Foundation) + 812
26  -[NSObject(NSKeyValueObserverRegistration)
addObserver:forKeyPath:options:context:] (in Foundation) + 565
27  -[_NSModelObservingTracker
_registerOrUnregister:observerNotificationsForKeyPath:ofModelObject:]
(in AppKit) + 134
28  -[_NSModelObservingTracker
_registerOrUnregister:observerNotificationsForModelObject:] (in
AppKit) + 228
29  -[_NSModelObservingTracker _startObservingModelObject:] (in
AppKit) + 418
30  -[_NSModelObservingTracker
startObservingModelObjectsAtReferenceIndexes:] (in AppKit) + 333
31  -[NSArrayController
_arrangeObjectsWithSelectedObjects:avoidsEmptySelection:operationsMask:useBasis
:] (in AppKit) + 510
32  -[NSArrayController setContent:] (in AppKit) + 889
33  -[NSArrayController(NSManagedController)
_performFetchWithRequest:merge:error:] (in AppKit) + 501
34  -[NSObjectController(NSManagedController)
fetchWithRequest:merge:error:] (in AppKit) + 209
35  -[NSObjectController(NSManagedController)
_executeFetch:didCommitSuccessfully:actionSender:] (in AppKit) + 106
36  _NSSendCommitEditingSelector (in AppKit) + 339
37  -[NSController _controllerEditor:didCommit:contextInfo:] (in
AppKit) + 216
38  __invoking___ (in CoreFoundation) + 29
39  -[NSInvocation invoke] (in CoreFoundation) + 136
40  -[NSInvocation invokeWithTarget:] (in CoreFoundation) + 72
41  __NSFireDelayedPerform (in Foundation) + 537
42  __CFRunLoopRun (in CoreFoundation) + 6846


Hard to say without more details, but it does look like a Cocoa  
Bindings bug.  If you could create a new sample project with your NIB  
and your model and reproduce this, and then attach it to a bug report,  
that would be extremely helpful.


Thanks,

- Ben



___

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

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

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

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

re: CoreData: Using to-may relationships in fetch request predicates

[Ben Trumbull]

in  the typical CoreData example, if I want to fetch all departments
whose employees have a salary higher than a specified value, I will
perform a fetch on the Department entity using a predicate with the
following format:

"ANY employees.salary < %@"

This is working fine.
Now I want to fetch all departments whose employees fulfill the salary
condition AND are born after a certain date. I would expect something
like this to work:

"ANY (employees.salary < %@ AND employees.dateOfBirth > %@"

But it doesn't. Does anybody know if there is a way to use the ANY
statement with more than one condition?


You'll need to use a SUBQUERY predicate instead of an ANY/operator.   
Probably easiest to do SUBQUERY(..)@count > 0


Please file a bug.

- Ben

___

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

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

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

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

Drawing a graph & testing ranges

[Mark Bateman]

Hi,

I have a completed app that calculates graph points x and y  
coordinates.  I want to present these on a graph that has an  
acceptable "envelope"  of coordinates.


I'm guessing that i need to learn how to use quartz to draw lines  
pixel by pixel to represent this on a UIview.  is there any easier /  
better way to do this that I have overlooked  i did look at  
providing a uiview background preformattted with the graph but i  
haven't found a tool that will allow me to draw that accurately.


Also can is use the NSrange objects to check if a certain set of  
coordinates is inside a particular envelope.


That is,

if I have a value of   x= 10,000   y = 211.2 and an envelope  
of   9500, 200: 13000, 211:  14000,214: 9500,214 can i use NS  
range to check if the original coordinates are inside the bounds of  
that rectangle...


if not any ideas how i might do that...



___

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

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

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

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

Re: Standard Alert Note/Warning/Stop icon NSImage Names?

[Nick Zitzmann]

On Aug 29, 2009, at 6:24 PM, Seth Willits wrote:

Are the standard alert icons (note, warning, and stop) available  
through standard image names (like NSApplicationIcon)? They don't  
seem to be.


There are, and they're available through standard image names. But you  
have to use IconRef, not NSImage, to get those icons. See IconsCore.h  
for details.


Nick Zitzmann


___

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

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

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

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

TAB bar and nav bar together

[Mark Bateman]

Hi,

I have an app that uses a TAB bar controller to launch "n" view  
controllers through my main window.XIB.  I wanted each of them to have  
a nav bar with custom buttons and so I added a nav bar controller to  
the XIB for each one.  so the hierarchy in IB is


Tab bar controller
-> tab bar
 --->navigation controller
> nav bar
> view controller
> UIview
> navbar item
> tab bar item

I have this structure for each viewcontroller.  Problem is I can't  
help but think this adding a massive overhead to the application  
(launch is slower also).  is there a better way to do this. should i  
split them out into separate XIB's.


Also, one of my controllers uses a table view and from that I launch  
two XIB's dependant on the row selected.  one has a UIview with an  
embeded webview the other a UIview with a uitextview embedded.  The  
problem I have is that I use use the nav bar to start a 
UIActivityIndicatorView to show the views loading.  for the webview  
everything works ok.  for the view with the UItext view I have to wait  
for the user to add some text then it performs a load but the  
UIActivityIndicatorView on this doesn't show up on the nav bar.  did I  
miss something obvious.  I know from NSlog that the method is called  
the only difference I can see is in the CAlayer.


last but not least..

Is there a way I can stop my searchbar from disappearing when the user  
scrolls the table view (3.0 it is attached to the top of the table  
view not the nav bar)


thanks in advance.




___

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

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

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

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

Re: SOLVED -- llvm-gcc-4.2 link-time error seen from command line but not in Xcode 3.2

[Jay Reynolds Freeman]

For the record, I seem to have solved my original problem. It turns  
out that Xcode comes with an llvm-g++ as well as llvm-gcc.  Merely  
changing the compiler used from


   /Developer/usr/bin/llvm-gcc-4.2

to

   /Developer/usr/bin/llvm-g++-4.2

makes everything happy.  I did not find any documentation in the Apple  
Xcode documentation or in the man pages, that llvm-g++ was installed,  
and have filed a bug report requesting some.


--  Jay Reynolds Freeman
-
jay_reynolds_free...@mac.com
http://web.mac.com/jay_reynolds_freeman (personal web site)

___

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

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

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

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

enabling/ disabling a uitextfield

[Mark Bateman]

Hi,

anyone know how I can enable ./ disable a UItext field outside of IB.   
I can do this as part of the XIB but I want to disable interaction on  
a particular condition.


Also is there a keyboard property i can set to enable the caps lock  
key (not the auto capitalization)





 
___


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

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

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

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

Re: Get error message about registered observers when Object receives dealloc message

[Roland King]

On Aug 30, 2009, at 1:28 AM, Quincey Morris wrote:


On Aug 29, 2009, at 06:00, Roland King wrote:

If I understand what's been said in this thread, Andreas *is* doing  
something wrong. He's in good company, though, because the retain/ 
release mechanism has traditionally allowed many Cocoa developers to  
do it wrong over the years. It's only now that the chickens are  
coming home to roost.


There are actually two things wrong here. One is that it's not  
*generally* safe to manage lifetimes of mutually dependent objects  
in their 'dealloc' methods. In this case, Andreas has said,  
observing objects are being released in the observed object's  
'dealloc', and the released (and therefore deallocated) observing  
objects are messaging the partially torn down observed object from  
their own 'dealloc'. With very careful coding, Andreas *might* be  
able to make this kind of thing safe *for the part of the object  
behavior that he controls*, but he can't make it safe for the parts  
he doesn't control (e.g. behavior inherited from the frameworks).


Right I'd missed that because I'd originally commented on what his  
first post said his code was, which was an explicit unregister by the  
observed object on behalf of the observing object (which he'd  
retained) during the dealloc of the observed object. Now I see his  
clarification that he's been deallocating the dictionary of objects  
and using that dealloc to trigger the unregistration from the  
observing objects side - and yes I agree that's wrong. That's why I  
asked how he knew what to unregister, because you usually don't know  
who's listening to you.


I would agree that assuming the dealloc of the child object will occur  
as you release the dictionary of them at the start of your dealloc  
method and unregister all the observers for you is wrong, even in a  
retain/release sense, any object can have been retained by some piece  
of the framework to be deallocated much later.




The second is that one of the behaviors he doesn't control --  
unregistration of observers -- is not permitted during the 'dealloc'  
of the observed object, and must be done before that. That's what  
the log message is trying to say. The bug fixes described in the  
Snow Leopard release notes *don't* permit this requirement to be  
ignored. [In fact, the notes explicitly say that the consequences  
are memory leaks and observation info getting attached to the wrong  
object.] Instead, Snow Leopard corrects the detection of the problem  
in the retain/release case. That's why log messages have suddenly  
started appearing. Andreas' implementation was always wrong, but  
it's only being reported correctly now.


Now this I don't understand. If you enter your dealloc method with  
observers registered on yourself and do have a *safe* mechanism of  
ensuring they are completely removed before ending the dealloc routine  
(or calling [ super dealloc ] ) I don't see where the issue should  
lie. Can you point me to the note on that please too. I suppose if you  
did permit this you're sending a message to an object whilst it's  
being deallocated however the KVO registration methods are supplied by  
the NSObject superclass, who's dealloc method has not yet been called.


By *safe* there I mean that you know all the objects potentially  
observing you, they are all retained by you at this point (which in  
this posters case I believe they are) and you send them all a message  
on your own interface they all implement which says "I'm dying now -  
stop looking at me" and they unregister their observations of you  
before you release them.


Again however if you know who all your children are, and you say you  
do because you have them in a dictionary, why use KVO? You could as  
easily, each time a property they are likely to care about changes,  
iterate your dictionary of them and send them a custom message on a  
custom interface telling them so. They can choose to ignore it or not.  
When you are dealloc'ed your dictionary goes away and you stop sending  
things. It's kind of like a poor-man's KVO. 
___


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

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

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

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

Re: Correct way to have nil undo manager in Core Data document?

[Jerry Krinock]

On 2009 Aug 29, at 13:41, Quincey Morris wrote:

AFAIK, the problem is that NSPersistentDocument overrides *some* of  
NSDocument's undo-related methods, but not all, and calling the un- 
overridden ones really messes things up -- you can end up with 2  
undo managers, one in a NSDocument private instance variable that's  
never used, plus the real one in the MOC.


That's another reason why I want them ^both^ to be nil.

IIRC, the correct strategy is to nil just the one in the MOC and  
take your grubby fingers completely off the NSDocument so that  
NSPersistentDocument can puts its own grubby fingers on it.


Yes, I tried that, but as shown in my demo, when NSPersistentDocument  
sees that is MOC does not have an undo manager it sets its own, which  
is not nil.  This is indeed documented as noted by Ben below.


I think your third solution overrides NSPersistentDocument's  
override of NSDocument's undoManager, which is probably a Bad Idea,  
although it probably works fine in this case because you don't want  
any undo manager at all (so you're returning what the  
NSPersistentDocument override would have returned.)


Actually, the third solution is the only solution (that works).


On 2009 Aug 29, at 17:29, Ben Trumbull wrote:


You need to use the NSDocument API:

/* The document's undo manager. The default implementation of - 
setUndoManager:, in addition to recording the undo manager,  
registers the document as an observer of various NSUndoManager  
notifications so that -updateChangeCount: is invoked as undoable  
changes are made to the document. The default implementation of - 
undoManager creates an undo manager if the document does not already  
have one and -hasUndoManager would return YES. */


Yes, this is this header pretty much says the same thing as the  
documentation in different words.  I don't see in it any admonition  
against overriding -undoManager to return nil as I have done.  Since - 
hasUndoManager is a "should not override" in NSPersistentDocument, it  
looks like this is the "least unsupported" way to do it.



- (void)setHasUndoManager:(BOOL)hasUndoManager;


Yes, I've done that, set to nil.

So far it's working.  I'll hang on to this thread for a few weeks and  
let y'all know if anything bad happens.


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 arch...@mail-archive.com

Re: multiple nsrunalert panels

[Rick C.]

thanks I.S. sorry for my delay.  actually i figured it out and sorry for lack 
of info earlier.  i had it in a delegate method that could be called more than 
once.  maybe it was lack of sleep? :-)

thanks again,

rick






From: I. Savant 
To: Rick C. 
Cc: cocoa dev 
Sent: Saturday, August 29, 2009 11:44:32 PM
Subject: Re: multiple nsrunalert panels

On Aug 29, 2009, at 11:40 AM, Rick C. wrote:

> i'm using nsrunalertpanel successfully except if i will make another app 
> active and then make my own app active again it will display a duplicate 
> panel even though i have never yet acknowledged the original one.  actually 
> if i keep switching back and forth between active apps it will continue to 
> create duplicate panels.  any help would be appreciated thank you,

  Our crystal ball is in the shop. Code, please. :-)

  Specifically, how are you creating and showing the panel? Where is this 
creating/showing code located (ie, what calls it)? This is the bare minimum of 
what we need to know to help you.

--
I.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 arch...@mail-archive.com

Re: Get error message about registered observers when Object receives dealloc message

[Graham Cox]

On 30/08/2009, at 12:35 PM, Roland King wrote:

Now this I don't understand. If you enter your dealloc method with  
observers registered on yourself and do have a *safe* mechanism of  
ensuring they are completely removed before ending the dealloc  
routine (or calling [ super dealloc ] ) I don't see where the issue  
should lie. Can you point me to the note on that please too. I  
suppose if you did permit this you're sending a message to an object  
whilst it's being deallocated however the KVO registration methods  
are supplied by the NSObject superclass, who's dealloc method has  
not yet been called.



I believe the issue lies in the fact that an object that has KVO  
observers registered on it is not the object you think it is. It's in  
fact a sort of proxy for the "real" object that has been swizzled (you  
can see this in the debugger as the class will be  
KVONotifying_Whatever). When the last observer is removed it's  
swizzled back to the original class. The question would be just how  
possible/safe this would be to do in -dealloc.


Nevertheless, I think it's a moot point. Apple have decreed that  
removing observers in dealloc is too late; it flags a fairly stern  
warning about doing it - a warning that got much more strongly worded  
between 10.4 and 10.5. So whether or not there could be a way to do it  
in theory, in practice you have to find a way to do it some other way.  
Personally I found that once I grokked this (and it did take a while)  
it started to inform the design of other parts of my data model, in  
that knowing I planned to use KVO meant that I would build-in proper  
mechanisms for observing and de-observing at the right places in a  
legal fashion. As a result I went from finding KVO a pain in the butt  
to being one of the best things about Cocoa.


One way or another, I think Andreas has to re-jig his design.

--Graham


___

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

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

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

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

Re: core-data app design question

[Kyle Sluder]

On Aug 29, 2009, at 5:53 PM, Ben Trumbull  wrote:

Encoding your data this way is pushing the boundaries of violating  
MVC patterns by archiving UI information (NSTextView drawing  
information) into your model (database).  That obviously doesn't  
work if the platform doesn't support NSTextView.


Beg to differ a but here, or at least point out that NSTextStorage is  
not just a view-layer class. It just doesn't happen to exist on the  
iPhone, so it isn't a suitable model class for this application.


And that gets into hooking up field editors to your document's text  
storage vs. copying that text storage and changing it atomically.  
NSUndoManager support makes it very clear which you want to do.


--Kyle Sluder
___

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

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

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

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

Re: Applying color to template images

[Brandon Walkin]

I have a category on NSImage that should do what you need:

- (NSImage *)tintedImageWithColor:(NSColor *)tint
 {
NSSize size = [self size];
NSRect imageBounds = NSMakeRect(0, 0, size.width, size.height);

NSImage *copiedImage = [self copy];

[copiedImage lockFocus];

[tint set];
NSRectFillUsingOperation(imageBounds, NSCompositeSourceAtop);

[copiedImage unlockFocus];

return [copiedImage autorelease];
}

Brandon

On 2009-08-29, at 2:36 PM, Mitchell Livingston wrote:


Hello,

I want to use NSImage's built-in template images, but want to  
replace the black color with different colors, such as gray or  
orange. I feel like I'm missing something obvious, but I can't seem  
to figure this out. Could someone point me in the right direction.


Thanks,
Mitch
___

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

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

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

This email sent to bwal...@gmail.com


___

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

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

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

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

Re: Get error message about registered observers when Object receives dealloc message

[Roland King]

On Aug 30, 2009, at 1:28 AM, Quincey Morris wrote:

The second is that one of the behaviors he doesn't control --  
unregistration of observers -- is not permitted during the 'dealloc'  
of the observed object, and must be done before that. That's what  
the log message is trying to say. The bug fixes described in the  
Snow Leopard release notes *don't* permit this requirement to be  
ignored. [In fact, the notes explicitly say that the consequences  
are memory leaks and observation info getting attached to the wrong  
object.] Instead, Snow Leopard corrects the detection of the problem  
in the retain/release case. That's why log messages have suddenly  
started appearing. Andreas' implementation was always wrong, but  
it's only being reported correctly now.




Here are the release notes on this by the way. I note they only talk  
about running in non-GC mode. However in both cases mentioned an  
object has unregistered as an observer of an observed object during  
the dealloc of that observed object and these release notes say that  
is ok. In the first case the object is itself, in the second case it's  
an object retained by the observed object who's release by the  
observed object during dealloc() caused it also to be dealloc()ed and  
during that deallocation it unregistered itself as an observer of the  
observed object. That's actually exactly what the thread starter is  
doing and the release notes say 'correctly unregistered' which  
strongly indicates that it's perfectly allowable for unregistration of  
observers to happen during dealloc of the observed object and that the  
message he's been getting is a false positive.


I still agree that relying on nothing else having retained the child  
object such that its dealloc is guaranteed to be called when you  
yourself release it is bad and that an explicit request to observing  
objects is much safer, and that it wouldn't work in GC mode where your  
child object could be cleaned up .. I have no idea when. However  
unless there's another note I've not seen, from this particular note I  
take it that it is allowable for registrations on you to be removed  
during your dealloc().


One way to trigger that could be to have a 'canBeObserved' property  
which your children are all observing, flip that to NO at the start of  
dealloc() which would tell them to remove all their observations and  
then proceed from there. That assumes you're allowed to unregister  
observations during an observation callback.


... release note follows ...

Bug Fixes in Debugging of Objects Being Deallocated With Observers  
Still Registered When Not Running Garbage-Collected (Updated since  
March 2009 Seed)
In Mac OS 10.3 through 10.5 there was a bug in which a valuable  
debugging feature of KVO was not triggered when an object observing  
itself did not remove itself as an observer of itself during  
deallocation. This bug has been fixed in Mac OS 10.6. When this  
happens Foundation now logs something like "An instance 0x100771010 of  
class MySelfObservingClass was deallocated while key value observers  
were still registered with it. Observation info was leaked, and may  
even become mistakenly attached to some other object. Set a breakpoint  
on NSKVODeallocateBreak to stop here in the debugger. Here's the  
current observation info:…"


There was another bug in which this logging was done spuriously when  
an object observed by a second object was deallocated, its  
deallocation caused the release of the second object, and the second  
object correctly unregistered itself as an observer of the first  
object at that time due to its own deallocation. This bug has also has  
been fixed in Mac OS 10.6.


To summarize, KVO's test for objects being deallocated with observers  
still registered exhibited both false negatives and false positives,  
and both kinds of mistake have been fixed.




___

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

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

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

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

Re: Get error message about registered observers when Object receives dealloc message

[Roland King]

On 30-Aug-2009, at 11:24, Graham Cox  wrote:





I believe the issue lies in the fact that an object that has KVO  
observers registered on it is not the object you think it is. It's  
in fact a sort of proxy for the "real" object that has been swizzled  
(you can see this in the debugger as the class will be  
KVONotifying_Whatever). When the last observer is removed it's  
swizzled back to the original class. The question would be just how  
possible/safe this would be to do in -dealloc.




I didn't know the object was unswizzled again when the last observer  
is removed, but I can see how it might be.


Nevertheless, I think it's a moot point. Apple have decreed that  
removing observers in dealloc is too late; it flags a fairly stern  
warning about doing it - a warning that got much more strongly  
worded between 10.4 and 10.5.


Where? Where have they decreed this? That's what I'm missing. If  
you're using the fact of the message being logged then please can you  
explain the release note which I didn't find but did copy/paste into  
my last mail. As far as my reading of it says, it covers exactly the  
original poster's situation and says unregistation in that way is fine  
and the warning message being logged was a bug.



One way or another, I think Andreas has to re-jig his design.

--Graham



___

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

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

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

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

Re: Core Data Predicate Builder - comparing dates

[Steve Cronin]

Ben;

Thanks for taking the time to respond.
I believe that I was blinded by a build issue in my allegation that  
the Predicate Builder mechanism was not giving correct results.

This seems to be working fine now.

I'm glad you have expressed the fragility issue on equivalence - I'll  
remember that.


Thanks for the predicate in code.

It's amazing how often the Cocoa answers are simple and  
straightforward when you finally see them.
I might suggest the predicate you cited be considered for inclusion in  
the Apple documentation somewhere.

Most (all?) the examples use operators and some fixed value.
I know it may seem obvious (it does seem obvious now) but, when you  
don't know, a range of different examples can be a godsend...


Thank-you!
Steve

On Aug 29, 2009, at 7:35 PM, Ben Trumbull wrote:


I have a Core Data entity that has a dateCreated and a dateModified -
both NSDates in the object files.
I'd like to construct a predicate that will retrieve all records  
where

a record's dateModified is greater than that record's dateCreated.

Its deceptively easy to setup something that looks like it should  
work

using 'Control-click' and 'Key' in the predicate builder in XCode.
But when I run queries it doesn't appear to yield the right results.
My thinking is that the comparison operators don't properly evaluate
dates (am I wrong?)


Comparison operators work just fine on dates, although == and != are  
fragile since NSDates are double time stamps, and floating point  
numbers have odd == behavior.


What does the predicate look like ?  How is it not working ?  What  
does SQL logging show ?



So dropping back to code - how would I write this predicate in code?


[NSPredicate predicateWithFormat:@"dateModified > dateCreated"]

- Ben





___

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

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

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

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

Re: How to extract the "Artist" information of an song file?

[James]

>If it's an AAC file, you can use the QTMetaData* functions. If you're

>looking to get it out of an mp3, you're unfortunately stuck with
>either parsing it yourself (see the id3 specs) or using id3lib.
   Thank you for your help.
  In my application, there are three kinds of audio files--AAC, mp3 and
AIFF. So how should I to do for the AIFF? 
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 arch...@mail-archive.com

Re: Get error message about registered observers when Object receives dealloc message

[Quincey Morris]

On Aug 29, 2009, at 20:43, Roland King wrote:

Here are the release notes on this by the way. I note they only talk  
about running in non-GC mode. However in both cases mentioned an  
object has unregistered as an observer of an observed object during  
the dealloc of that observed object and these release notes say that  
is ok. In the first case the object is itself, in the second case  
it's an object retained by the observed object who's release by the  
observed object during dealloc() caused it also to be dealloc()ed  
and during that deallocation it unregistered itself as an observer  
of the observed object. That's actually exactly what the thread  
starter is doing and the release notes say 'correctly unregistered'  
which strongly indicates that it's perfectly allowable for  
unregistration of observers to happen during dealloc of the observed  
object and that the message he's been getting is a false positive.


Yes, that what it seems to say, and that's a pretty big mystery.  
Here's what we have:


a. When there *is* an error message, it says, "An instance of ... was  
deallocated while key value observers were still registered with it."  
That implies pretty strongly that there is something you're not  
supposed to do.


b. The release notes say that it was wrong for this message to appear  
"when an object observed by a second object was deallocated, its  
deallocation caused the release of the second object, and the second  
object correctly unregistered itself as an observer of the first  
object at that time due to its own deallocation". So this sort of  
thing should be OK.


c. The release notes also talk about "KVO's test for objects being  
deallocated with observers", which implies that it isn't OK for  
objects to be deallocated with observers. That seems to contradict b,  
which in turn seems to contradict a.


d. It's possible that "deallocation" means the end of the deallocation  
process (i.e. when the NSObject implementation does whatever it does),  
rather than the beginning of the deallocation process (i.e. when the  
most derived dealloc override is first invoked). If that were true,  
then a-c wouldn't really contradict each other.


e. It's possible that the rules for RR are laxer than the rules for  
GC, because (as you pointed out) the scenario in b does seem to remove  
the observations deterministically, whereas in the equivalent GC case  
that determinism doesn't exist.


f. I don't know when the isa-unswizzling occurs either, so I'm not  
sure how or if that plays into all of this.


g. Andreas has reported that the error message occurs at the  
*beginning* of the deallocation process. If that's a frameworks bug,  
that would mean that Snow Leopard, instead of fixing bugs in dealloc- 
time KVO-registration error reporting, *introduced* bugs in error  
reporting. That's possible, but (if true) ironic and puzzling.


h. It's possible that Andreas is getting the error message not because  
of the indirectly-deallocated observers he told us about, but because  
of some *other* observer that's not being removed at all. (That  
doesn't make any sense in terms of the timing of the error message,  
but oh well.)


Pretty much, that's 8 ways of saying "I dunno." Did I leave anything  
out? :)



___

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

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

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

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