Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 5, 2008, at 10:07 PM, Chris Hanson wrote: Can you give an example of a framework method that's documented to return an autoreleased CF object? NSBitmapImageRep: - (CGImageRef)CGImage Returns an autoreleased CGImage object (an opaque type) from the receiver’s current bitmap data. http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSBitmapImageRep_Class/Reference/Reference.html#//apple_ref/occ/instm/NSBitmapImageRep/CGImage mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 5, 2008, at 11:04 PM, mmalc crawford wrote: On Jul 5, 2008, at 10:07 PM, Chris Hanson wrote: Can you give an example of a framework method that's documented to return an autoreleased CF object? NSBitmapImageRep: - (CGImageRef)CGImage Returns an autoreleased CGImage object (an opaque type) from the receiver’s current bitmap data. Interesting, thanks for the tip! -- Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 5, 2008, at 22:07, Chris Hanson wrote: On Jul 5, 2008, at 3:52 PM, Quincey Morris wrote: The other thing worth noting is that, when GC is enabled, any CF object that is documented to be *returned* already autoreleased from a frameworks function is actually returned with a reference count of 1, so you still need to call CFMakeCollectable yourself in that case, even though you wouldn't follow it with a call to autorelease like you would in Chris's examples. I don't believe this is the case. Can you give an example of a framework method that's documented to return an autoreleased CF object? I would assume that the result of such a method has already had CFMakeCollectable called on it, making doing so unnecessary. The example I was thinking of was -[QTMovie frameImageAtTime:withAttributes:error:], which is clearly documented to return autoreleased objects. I know from getting all tangled up in it that with GC on it returns 'CGImageRef's and 'CVPixelBufferRef's with a reference count of 1. The CVPixelBufferRef was a particular trial because CFMakeCollectable isn't allowed on it, and there's no CVMakeCollectable AFAIK. But it may well be true that there are no non-Cocoa functions that return autoreleased objects, only a few Cocoa methods that return autoreleased non-Cocoa objects. It also occurs to me that the OP is going to have to be careful to document the behavior of methods in *his* framework that return new CF objects (if there are any). He'll have to decide whether to use CF rules (retain count == 1), Cocoa rules (retain count == 1 or autoreleased object, depending on whether the caller or the framework is regarded as the owner of the new object), or to return an object on which CFMakeCollectable has already been called. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: garbage collection and NSConnection
El 06/07/2008, a las 2:05, mmalc crawford escribió: On Jul 5, 2008, at 3:00 PM, Joan Lluch (casa) wrote: However, let me copy an excerpt of the Cocoa documentation on the GC algorithm that Cocoa uses. You haven't updated your documentation since the beginning of November last year. Oops, thanks. Looks as it is time for me to update things... I will give the Cocoa GC another try before adding another comment, (my apologies, I might be testing an earlier version) By the way, how do I know for sure that a set of documentation corresponds to a particular version of the SKD. I am using XCode 3.0 for mac development since I believe it is the latest non pre-release version of the dev-tools and the documentation files that came with it. Is 3.1 already intended for use for mac development?. Since this post will go out of topic I am also posting this on the Xcode lists, where I think I should receive a more appropriate answer. Joan Lluch___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Stopping actions mid stream
Hi Guys I've set up matrix with 2 radio buttons (1 and 2) with a delegate method that gets run when the matrix gets clicked. Lets say radio button 1 is highlighted and someone clicks on radio button 2. The delegate method has some code that checks whether the radio buttons are allowed to be changed from 1 to 2 and if not, sends an alert to the user. My problem is how can I stop the radio buttons themselves changing from 1 to 2. When programming in Visual Basic there was a method that stopped the action from completing. Is there something similar I can do here or some other way. Thanks in advance. Jeff Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/mail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
NSInvalidArgumentException', reason: '*** -[NSCFArray insertObject:atIndex:]: attempt to insert nil
Hello fellow developers, Is there any of you can give me an idea on the cause of this uncaught exception: 'NSInvalidArgumentException', reason: '*** -[NSCFArray insertObject:atIndex:]: attempt to insert nil' I can't seem to find where I should look to trace for this problem, even though I thought this could be happening because I'd done something wrong related to CFRunLoop. I have searched everywhere for this, but none of it points me to guide on how to trace the errors related to this message. -- Jesse Armand barablu (http://www.barablu.com) iPhone Developer (http://jessearm.blogspot.com) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSInvalidArgumentException', reason: '*** -[NSCFArray insertObject:atIndex:]: attempt to insert nil
On Jul 6, 2008, at 1:25 AM, Jesse Armand wrote: Is there any of you can give me an idea on the cause of this uncaught exception: 'NSInvalidArgumentException', reason: '*** -[NSCFArray insertObject:atIndex:]: attempt to insert nil' It means something tried to insert nil into an NSMutableArray, which is not allowed. I can't seem to find where I should look to trace for this problem, even though I thought this could be happening because I'd done something wrong related to CFRunLoop. Break on objc_exception_throw, as well as -[NSException raise] if you're using Tiger or earlier. Nick Zitzmann http://www.chronosnet.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Capture Window/View created through NSTask
Each application has its own address space and can access only windows in its space. So an application cannot draw content into anoter one and so, it's not possible to grab a window from an other application. Le 6 juil. 08 à 01:28, Michael Moore a écrit : No, I mean actually capture the fully functional NSView displayed - so I can interact with it, etc. For example, imagine taking an OpenGL game and embedding the game in a custom nib within a custom application. On Jul 5, 2008, at 7:11 PM, Jean-Daniel Dupas wrote: Le 6 juil. 08 à 00:43, Michael Moore a écrit : I'm hoping someone might be able to assist me with this question. I have a Cocoa application, with an embedded command-line tool in the Resources folder. This tool is from an outside source, and I have no source code available for it. When launched, it creates its own window, and displays a variety of content. I launch this tool via NSTask (utilizing NSPipe to communicate with the tool via STDIN, STDOUT, and STDERR). What I am hoping to do is find a way to capture the NSWindow/NSView created by the tool and embed it in a Custom View in my nib. Is there a way to do this? Many thanks, Michael If you mean create an image from the window contents, you may have a look at the SonOfGrab sample (http://developer.apple.com/samplecode/SonOfGrab/ ) that contains some sample to grab the content of a any window (even in other processes). Note that it requires 10.5. smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Method Sees Populated Array As Empty
Try NSLog(@%@, self) and make sure your are working with the same document instance and not with two distincs documents objects (one with a full array and one with an empty array). Le 6 juil. 08 à 12:26, Mark Wales a écrit : Do you actually have an accessor method for arrayOfReferences? Yes, there is one. I didn't copy the full code in, but there is a synthesised setter for arrayOfReferences. I tried doing it manually too and added an NSLog in there. Again the array only came up as empty when called from that one method. It's very strange indeed: it is as if the array goes blank just for that method – but i don't know what could cause that to happen – it's just a mutable array that I'm adding objects too. I'm I missing something basic? I don't see how it could work in every other method but not that one. I'm flummoxed. Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org This email sent to [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Method Sees Populated Array As Empty
Do you actually have an accessor method for arrayOfReferences? Yes, there is one. I didn't copy the full code in, but there is a synthesised setter for arrayOfReferences. I tried doing it manually too and added an NSLog in there. Again the array only came up as empty when called from that one method. It's very strange indeed: it is as if the array goes blank just for that method – but i don't know what could cause that to happen – it's just a mutable array that I'm adding objects too. I'm I missing something basic? I don't see how it could work in every other method but not that one. I'm flummoxed. Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Method Sees Populated Array As Empty
Try NSLog(@%@, self) and make sure your are working with the same document instance and not with two distincs documents objects (one with a full array and one with an empty array). Ok, that seems to have done something. When I use the NSLog(@%@, self) in all the other methods I get: MyDocument: 0x17f620 When I try it in the dataOfType method I get: MyDocument: 0x1559d0 So the document instance changes I guess. Why would that happen and how can I stop it? Thanks, Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Method Sees Populated Array As Empty
On Sun, Jul 6, 2008 at 4:26 AM, Mark Wales [EMAIL PROTECTED] wrote: So the document instance changes I guess. Why would that happen and how can I stop it? Only your code could tell us why. -Shawn ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Method Sees Populated Array As Empty
So the document instance changes I guess. Why would that happen and how can I stop it? Only your code could tell us why. The MyDocument.m file is pretty long so I don't want to post it on here, and it links to other files too. So here's the full source code instead: http://www.think-yak.com/files/XCite_source.zip – if anyone wants to check it out for me then that would be hugely appreciated, but please don't spend too much time on it. I'm afraid there isn't as much commenting as there should be and some of the code is appalling at the moment – i only started Cocoa two weeks ago, so I'm still learning some of the basics (I know, for example, that the copy and paste procedure does everything twice, which is horribly inefficient – working on it today). It's a drag-and-drop bibliography program in case anyone is wondering, for BibTex/EndNote etc. Thanks again, Mark___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Stopping actions mid stream
On Jul 6, 2008, at 3:04 AM, Jeff Brown wrote: The delegate method has some code that checks whether the radio buttons are allowed to be changed from 1 to 2 and if not, sends an alert to the user. My problem is how can I stop the radio buttons themselves changing from 1 to 2. When programming in Visual Basic there was a method that stopped the action from completing. Is there something similar I can do here or some other way. Hi, I don't have an answer to your question, but an observation: Giving a user the option to click something, then telling them they cannot, seems kind of weird. Radio buttons are generally for options a user has. If the functionality denoted by an item is unavailable, generally it is hidden or at the very least inactive. In other words, using logic to determine availability of an interface item before it is clicked. Such a thing can be done with bindings. anyway, good luck finding the answer to your question. Jaime Jaime Magiera Sensory Research http://www.sensoryresearch.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Method Sees Populated Array As Empty
Le 6 juil. 08 à 13:47, Mark Wales a écrit : So the document instance changes I guess. Why would that happen and how can I stop it? Only your code could tell us why. The MyDocument.m file is pretty long so I don't want to post it on here, and it links to other files too. So here's the full source code instead: http://www.think-yak.com/files/XCite_source.zip – if anyone wants to check it out for me then that would be hugely appreciated, but please don't spend too much time on it. I'm afraid there isn't as much commenting as there should be and some of the code is appalling at the moment – i only started Cocoa two weeks ago, so I'm still learning some of the basics (I know, for example, that the copy and paste procedure does everything twice, which is horribly inefficient – working on it today). It's a drag-and-drop bibliography program in case anyone is wondering, for BibTex/EndNote etc. Thanks again, You should not create a new instance of MyDocument in your xib file. In a nib document - File owner represents an existing object that is determine when you load your nib file (passed as argument when usign a window controller for example). - The First responder represents... the first responder (see Cocoa Event Handling Guide to now how what it mean) and it change every time. - Application represents the shared instance of NSApplication. Except this 3 special items, all other objects in your xib document represent new instance that will be created when you load your nib. In the case of a document based application, by default, the File Owner represents the document instance that load the nib. So, the solution is pretty simple. Delete the MyDocument object in your xib file, and bind all action, target and other that was targetting it to the 'File Owner'. smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Method Sees Populated Array As Empty
You should not create a new instance of MyDocument in your xib file. So, the solution is pretty simple. Delete the MyDocument object in your xib file, and bind all action, target and other that was targetting it to the 'File Owner'. That works perfectly! Thanks very much – that'll teach me to skim read chapters. Mark___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Stopping actions mid stream
The preferred way to do this is to prevent the user clicking the button if it's not appropriate by greying it out. This is far more user-friendly than rebuking a user for having the audacity to click your button when they shouldn't have, even though they had no visual cue that they shouldn't. The permit then rebuke form of input validation is the hallmark of bad UI design. Sadly, it's all too common. G. On 6 Jul 2008, at 5:04 pm, Jeff Brown wrote: I've set up matrix with 2 radio buttons (1 and 2) with a delegate method that gets run when the matrix gets clicked. Lets say radio button 1 is highlighted and someone clicks on radio button 2. The delegate method has some code that checks whether the radio buttons are allowed to be changed from 1 to 2 and if not, sends an alert to the user. My problem is how can I stop the radio buttons themselves changing from 1 to 2. When programming in Visual Basic there was a method that stopped the action from completing. Is there something similar I can do here or some other 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 2:04 AM, mmalc crawford at [EMAIL PROTECTED] wrote: On Jul 5, 2008, at 10:07 PM, Chris Hanson wrote: Can you give an example of a framework method that's documented to return an autoreleased CF object? NSBitmapImageRep: NSEvent, too: - (const void *)eventRef -- returns a carbon EventRef opaque type corresponding to the receiver - (CGEventRef)CGEvent -- returns a Core Graphics CGEventRef opaque type corresponding to the receiver The Leopard AppKit release notes say of the first of these The EventRef is retained by the NSEvent, so will be valid as long as the NSEvent is valid, and will be released when the NSEvent is freed. You can use RetainEvent to extend the lifetime of the EventRef, with a corresponding ReleaseEvent when you are done with it. The release notes say of the second: -CGEvent ... Returns an autoreleased CGEventRef corresonding to the NSEvent. If you want to control the lifetime of the CGEventRef, you should retain it. I was puzzled at first by the differing return type conventions, and by the different phrasing of the memory management discussions. I guess, however, from looking briefly at the Carbon Event Manager Reference, that the carbon EventRef isn't a CFType and has a variety of memory management methods of its own -- I've never had occasion to use it. But they seem to present the same issues with respect to their use in a garbage collected Cocoa application or framework. -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 2:45 AM, Quincey Morris at [EMAIL PROTECTED] wrote:
It also occurs to me that the OP is going to have to be careful to
document the behavior of methods in *his* framework that return new CF
objects (if there are any). He'll have to decide whether to use CF
rules (retain count == 1), Cocoa rules (retain count == 1 or
autoreleased object, depending on whether the caller or the framework
is regarded as the owner of the new object), or to return an object on
which CFMakeCollectable has already been called.
Actually, I (the OP) am receiving inconsistent advice privately regarding
the original question (the OQ?), namely, whether to use the __strong keyword
when declaring an instance variable with a CFType-derived type. Privately, I
have been told by a knowledgeable developer that I do NOT need to use
__strong, if I have been careful in my framework to balance my calls to
CFRetain and CFRelease. He even goes so far as to suggest that it would be
dangerous or at least inefficient to use __strong in a mixed environment
such as a shared framework that supports both garbage collection and
retain/release, due in part to the additional overhead.
In fact, my framework does balance CFRetain and CFRelease, because my
framework is also usable in a retain/release client application. My
documentation for the accessor method in my PFUIElement class, for example,
reads like this:
- (AXUIElementRef)elementRef {
// Returns the accessibility API AXUIElementRef object that was
associated with the receiver when the receiver was created. It is CFRetained
and will automatically be CFReleased when the UI element it represents is
destroyed. If you CFRetain it yourself to keep it around, you must CFRelease
it when you're done with it.
return elementRef;
}
I wrote this back in Tiger days, before the similar NSEvent methods were
public. If I'm reading between the lines correctly, I lucked into exactly
the same memory management behavior that NSEvent now implements. But I
confess that the NSEvent documentation isn't altogether clear to me.
So, back to the OQ. I am now inclined to think that, at least in my
circumstances (a shared framework properly balancing CFRetain and
CFRelease), I do NOT need to use the __strong keyword for the CFType-derived
instance variables, in order to support garbage collection. Any
disagreement?
--
Bill Cheeseman - [EMAIL PROTECTED]
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 1:07 AM, Chris Hanson at [EMAIL PROTECTED] wrote: On Jul 5, 2008, at 3:52 PM, Quincey Morris wrote: The other thing worth noting is that, when GC is enabled, any CF object that is documented to be *returned* already autoreleased from a frameworks function is actually returned with a reference count of 1, so you still need to call CFMakeCollectable yourself in that case, even though you wouldn't follow it with a call to autorelease like you would in Chris's examples. I don't believe this is the case. Can you give an example of a framework method that's documented to return an autoreleased CF object? I would assume that the result of such a method has already had CFMakeCollectable called on it, making doing so unnecessary. I don't question Quincey's experience with -[QTMovie frameImageAtTime:withAttributes:error:], which I haven't looked at. But I agree with Chris as to the NSEvent methods I describe in another post, and the similar methods in my own frameworks. In these cases, when the Cocoa object goes away, its CFType-derived counterpart also goes away. -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-05 6:14 PM, William J. Cheeseman at [EMAIL PROTECTED] wrote:
it would be very helpful to have some good examples of ways to
move cleanup code out of dealloc/finalize and into what you call
deterministic methods.
It occurs to me that this is a question that will eventually be answered by
an evolving Cocoa design pattern, as so many other Cocoa design patterns
have evolved over time.
Apple's garbage collection documentation very strongly advises us not to
implement a -finalize method if at all possible, but instead to do cleanup
in a method whose invocation the developer can control -- in order to avoid
the problems that can be created by the built-in uncertainty as to when
-finalize will be called, not to mention the overhead that would be created
at collection time.
So here's a possible approach that was suggested to me privately, for use in
a framework that supports garbage collection. Comments?
@interface MyFrameworkClass : NSObject {
BOOL wrappedup;
}
- (void)wrapup;
- (void)someMethod;
@end
@implementation MyFrameworkClass
- (void)finalize {
if (!wrappedup) {
// protect against inadvertent early termination
[self wrapup];
}
}
- (void)wrapup {
// cleanup code goes here
wrappedup = YES;
}
- (void)someMethod {
[self wrapup];
}
@end
--
Bill Cheeseman - [EMAIL PROTECTED]
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Stopping actions mid stream
I agree with you but here is JoelOnSoftware saying virtually the complete opposite. http://www.joelonsoftware.com/items/ 2008/07/01.html. Fortunately most of his commenters disagree. On 06/07/2008, at 10:21 PM, Graham Cox wrote: The preferred way to do this is to prevent the user clicking the button if it's not appropriate by greying it out. This is far more user-friendly than rebuking a user for having the audacity to click your button when they shouldn't have, even though they had no visual cue that they shouldn't. The permit then rebuke form of input validation is the hallmark of bad UI design. Sadly, it's all too common. G. On 6 Jul 2008, at 5:04 pm, Jeff Brown wrote: I've set up matrix with 2 radio buttons (1 and 2) with a delegate method that gets run when the matrix gets clicked. Lets say radio button 1 is highlighted and someone clicks on radio button 2. The delegate method has some code that checks whether the radio buttons are allowed to be changed from 1 to 2 and if not, sends an alert to the user. My problem is how can I stop the radio buttons themselves changing from 1 to 2. When programming in Visual Basic there was a method that stopped the action from completing. Is there something similar I can do here or some other 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/peter%40fracturedsoftware.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
Le 6 juil. 08 à 14:45, Bill Cheeseman a écrit : on 2008-07-06 2:45 AM, Quincey Morris at [EMAIL PROTECTED] wrote: It also occurs to me that the OP is going to have to be careful to document the behavior of methods in *his* framework that return new CF objects (if there are any). He'll have to decide whether to use CF rules (retain count == 1), Cocoa rules (retain count == 1 or autoreleased object, depending on whether the caller or the framework is regarded as the owner of the new object), or to return an object on which CFMakeCollectable has already been called. Actually, I (the OP) am receiving inconsistent advice privately regarding the original question (the OQ?), namely, whether to use the __strong keyword when declaring an instance variable with a CFType-derived type. Privately, I have been told by a knowledgeable developer that I do NOT need to use __strong, if I have been careful in my framework to balance my calls to CFRetain and CFRelease. He even goes so far as to suggest that it would be dangerous or at least inefficient to use __strong in a mixed environment such as a shared framework that supports both garbage collection and retain/release, due in part to the additional overhead. If __strong is so dangerous, why is it used in Cocoa (see NSDrawer, NSDateFormatter, NSNumberFormatter, NSKeyedArchiver, NSURL, …) ? smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Stopping actions mid stream
Not only his commenters disagree. http://daringfireball.net/linked/2008/07/01/spolsky-menu-items http://www.red-sweater.com/blog/515/disabled-menus-are-usable And I disagree too. Le 6 juil. 08 à 15:41, Peter Zegelin a écrit : I agree with you but here is JoelOnSoftware saying virtually the complete opposite. http://www.joelonsoftware.com/items/ 2008/07/01.html. Fortunately most of his commenters disagree. On 06/07/2008, at 10:21 PM, Graham Cox wrote: The preferred way to do this is to prevent the user clicking the button if it's not appropriate by greying it out. This is far more user-friendly than rebuking a user for having the audacity to click your button when they shouldn't have, even though they had no visual cue that they shouldn't. The permit then rebuke form of input validation is the hallmark of bad UI design. Sadly, it's all too common. G. On 6 Jul 2008, at 5:04 pm, Jeff Brown wrote: I've set up matrix with 2 radio buttons (1 and 2) with a delegate method that gets run when the matrix gets clicked. Lets say radio button 1 is highlighted and someone clicks on radio button 2. The delegate method has some code that checks whether the radio buttons are allowed to be changed from 1 to 2 and if not, sends an alert to the user. My problem is how can I stop the radio buttons themselves changing from 1 to 2. When programming in Visual Basic there was a method that stopped the action from completing. Is there something similar I can do here or some other 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/peter%40fracturedsoftware.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org This email sent to [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Stopping actions mid stream
Wow, I'm really surprised that Joel Spolsky of all people would say this - and so recently too. I used to like System 7's Balloon Help approach - grey out the menu but the help balloon would explain why it wasn't available (at least in an app that took the trouble to implement this). Sadly, as with many things since hen, in some ways we've gone backwards. G. On 6 Jul 2008, at 11:41 pm, Peter Zegelin wrote: I agree with you but here is JoelOnSoftware saying virtually the complete opposite. http://www.joelonsoftware.com/items/ 2008/07/01.html. Fortunately most of his commenters disagree. On 06/07/2008, at 10:21 PM, Graham Cox wrote: The preferred way to do this is to prevent the user clicking the button if it's not appropriate by greying it out. This is far more user-friendly than rebuking a user for having the audacity to click your button when they shouldn't have, even though they had no visual cue that they shouldn't. The permit then rebuke form of input validation is the hallmark of bad UI design. Sadly, it's all too common. G. On 6 Jul 2008, at 5:04 pm, Jeff Brown wrote: I've set up matrix with 2 radio buttons (1 and 2) with a delegate method that gets run when the matrix gets clicked. Lets say radio button 1 is highlighted and someone clicks on radio button 2. The delegate method has some code that checks whether the radio buttons are allowed to be changed from 1 to 2 and if not, sends an alert to the user. My problem is how can I stop the radio buttons themselves changing from 1 to 2. When programming in Visual Basic there was a method that stopped the action from completing. Is there something similar I can do here or some other 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/peter%40fracturedsoftware.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/graham.cox%40bigpond.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Stopping actions mid stream
Some of the commenters suggest a tool tip over the disabled menu explaining why it is disabled, which sounds reasonable. As a newby here would this be easy to implement in Cocoa? On 07/07/2008, at 12:02 AM, Graham Cox wrote: Wow, I'm really surprised that Joel Spolsky of all people would say this - and so recently too. I used to like System 7's Balloon Help approach - grey out the menu but the help balloon would explain why it wasn't available (at least in an app that took the trouble to implement this). Sadly, as with many things since hen, in some ways we've gone backwards. G. On 6 Jul 2008, at 11:41 pm, Peter Zegelin wrote: I agree with you but here is JoelOnSoftware saying virtually the complete opposite. http://www.joelonsoftware.com/items/2008/07/01.html . Fortunately most of his commenters disagree. On 06/07/2008, at 10:21 PM, Graham Cox wrote: The preferred way to do this is to prevent the user clicking the button if it's not appropriate by greying it out. This is far more user-friendly than rebuking a user for having the audacity to click your button when they shouldn't have, even though they had no visual cue that they shouldn't. The permit then rebuke form of input validation is the hallmark of bad UI design. Sadly, it's all too common. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Efficiently receiving data from an NSTask
Hi, I am in the situation where I want to launch a helper tool,
retrieve the data that it dumps to stdout, and monitor the output of
stderr for error messages and progress control. I did figure out that
the standard way of doing this is along the lines of the Moriarity
sample code. The problem is that this is way too slow if lots of data
gets returned (typically in the region of 100MB).
Right now, I am doing the following instead. In the thread that
launched the NSTask (call that the master thread), I poll data from
stdout until the task has died:
while ([myTask isRunning]) {
NSData* data = [output availableData];
if ([datalength])
Do something with the data
}
Simultaneously, I have a separate thread in which I poll stderr until
no more. I am trying to be careful in the following way:
- The separate thread does not call [myTask isRunning], but instead
checks on a flag set by the master thread.
- After the task has died, the master thread makes sure that the
secondary thread has finished before starting cleaning up.
- The NSFileHandle for the NSPipe attahced to stderr is only ever
accessed from the secondary thread and not by the master thread.
This works like a treat and is faster by a factor 3 or so than using
the Moriarity implementation. However, it leaves me a bit concerned
about various warnings all over the place concerning the thread
(un)safety of NSTask and NSFileHandle. So my question is: is the kind
of approach that I am taking doable / reasonable? If not, is there an
alternative way of doing this which is more efficient than the
Moriarty code? Thanks a lot in advance for any help / hint,
Martin
--
HairerSoft
http://www.hairersoft.com/
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Sun, Jul 6, 2008 at 5:45 AM, Bill Cheeseman [EMAIL PROTECTED] wrote:
on 2008-07-06 2:45 AM, Quincey Morris at [EMAIL PROTECTED] wrote:
It also occurs to me that the OP is going to have to be careful to
document the behavior of methods in *his* framework that return new CF
objects (if there are any). He'll have to decide whether to use CF
rules (retain count == 1), Cocoa rules (retain count == 1 or
autoreleased object, depending on whether the caller or the framework
is regarded as the owner of the new object), or to return an object on
which CFMakeCollectable has already been called.
Actually, I (the OP) am receiving inconsistent advice privately regarding
the original question (the OQ?), namely, whether to use the __strong keyword
when declaring an instance variable with a CFType-derived type. Privately, I
have been told by a knowledgeable developer that I do NOT need to use
__strong, if I have been careful in my framework to balance my calls to
CFRetain and CFRelease.
If CFRetain/CFRelease are indeed balanced, then you don't need the
__strong keyword *but* this requires that you implement -finalize to
CFRelease your ivars. You should, instead, use __strong, and
CFMakeCollectable, and eliminate the need to implement -finalize.
For example. In option 1 below, the object pointed to by ivar won't
likely be collected until the cycle *after* the MyObject instance is
collected, while in option 2, it is collected as part of the same
cycle. By using option 1, you are causing extra work for the collector
and potentially raising your memory high-water mark.
//Option1:
@interface MyObject : NSObject {
CFTypeRef ivar;
}
-(void)createIvar;
@end
@implementation MyObject
-(void)dealloc {
if(ivar) CFRelease(ivar);
[super dealloc];
}
-(void)finalize {
if(ivar) CFRelease(ivar);
[super finalize];
}
-(void)createIvar {
ivar = CFFooCreateFoo(...);
}
@end
//Option2:
@interface MyObject : NSObject {
__strong CFTypeRef ivar;
}
-(void)createIvar;
@end
@implementation MyObject
-(void)dealloc {
if(ivar) CFRelease(ivar);
[super dealloc];
}
-(void)createIvar {
ivar = CFMakeCollectable(CFFooCreateFoo(...));
}
@end
He even goes so far as to suggest that it would be
dangerous or at least inefficient to use __strong in a mixed environment
such as a shared framework that supports both garbage collection and
retain/release, due in part to the additional overhead.
What additional overhead does he imagine will be incurred?
--
Clark S. Cox III
[EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 9:49 AM, Jean-Daniel Dupas at [EMAIL PROTECTED] wrote: If __strong is so dangerous, why is it used in Cocoa (see NSDrawer, NSDateFormatter, NSNumberFormatter, NSKeyedArchiver, NSURL, ) ? Those are interesting examples, especially NSDrawer. In NSDrawer, only the CFRunLoopTimerRef and CFRunLoopObserverRef iVars are given the __strong keyword, while the CFRunLoopRef iVar is not. This suggests to me that some very refined thinking is going on as to when to use or not to use the __strong keyword. I wish I knew what all the relevant considerations were. In NSURL, the void *_reserved iVar is given the __strong keyword, which doesn't tell us much since _reserved may not be used at all. Ditto NSKeyedArchiver. In NSDateFormatter, a CFDateFormatterRef iVar is given the __strong keyword. This seems consistent with your point, but I am still haunted by the fact that NSDrawer's CFRunLoopRef iVar is not given the __strong keyword. Ditto NSNumberFormatter. -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSTableView and rows of different type
On Sat, Jul 5, 2008 at 12:45 PM, Erik Elmgren [EMAIL PROTECTED] wrote: I think I understand how to solve the display part by using tableView:dataCellForTableColumn:row: and supplying a full-width cell (custom subclass), and then painting the fields inside by drawing other cells. But how do I solve that some of these cells need to be editable by the user? The same way you handle drawing. Implement all of the NSCell event methods, use the event's position to figure out which cell was hit, and then pass the message to it. For example, if you have several NSTextFieldCells, you'll keep track of their locations internally (or calculate it each time you need it), see which one intersects the point in question, then tell it that it was clicked. The NSTextFieldCell will then take care of all the editing stuff for you. Alternatively, is there any way to reposition the cells horizontally (and change their width) for a specific row? There is not, each NSTableColums is in a fixed location for the entire extent of the table. You might consider using an NSCollectionView for this instead. It would allow you to have a custom NSView (rather than a custom NSCell) for each row which could then have subviews positioned as you wished. The downside is that, because it creates one view for every object in the collection view, it has a lot of overhead if you have a large number of objects to display. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Sun, Jul 6, 2008 at 11:25 AM, Bill Cheeseman [EMAIL PROTECTED] wrote: on 2008-07-06 9:49 AM, Jean-Daniel Dupas at [EMAIL PROTECTED] wrote: If __strong is so dangerous, why is it used in Cocoa (see NSDrawer, NSDateFormatter, NSNumberFormatter, NSKeyedArchiver, NSURL, Š) ? Those are interesting examples, especially NSDrawer. In NSDrawer, only the CFRunLoopTimerRef and CFRunLoopObserverRef iVars are given the __strong keyword, while the CFRunLoopRef iVar is not. This suggests to me that some very refined thinking is going on as to when to use or not to use the __strong keyword. I wish I knew what all the relevant considerations were. CFRunLoopRefs live for the entire lifetime of their thread, so there's no need for __strong. But I would suggest that, as is the case for many other things, you don't need to duplicate Apple's refined thinking as to whether to use __strong or not. Do you want to keep a reference to a CF object? If yes, use __strong. End of story. You might use __weak if you want a zeroing weak reference. But this is extremely uncommon in a dual-mode framework such as what you're writing, because there's no equivalent to __weak in the non-GC world. Aside from wanting a zeroing weak reference, there's no real reason not to use __strong. The only reason would be for performance, and as we all know, premature optimization is the root of all evil. You *can* leave off the __strong keyword, provided you do your CFRetains and CFReleases properly and implement a -finalize method to clean things up. But this is less efficient, requires more brainpower, and is unnecessary. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Stopping actions mid stream
I haven't test but -[NSMenuItem setToolTip:] look fine to do this. Now, just chek if this methods works even when the item is disabled. Le 6 juil. 08 à 16:31, Peter Zegelin a écrit : Some of the commenters suggest a tool tip over the disabled menu explaining why it is disabled, which sounds reasonable. As a newby here would this be easy to implement in Cocoa? On 07/07/2008, at 12:02 AM, Graham Cox wrote: Wow, I'm really surprised that Joel Spolsky of all people would say this - and so recently too. I used to like System 7's Balloon Help approach - grey out the menu but the help balloon would explain why it wasn't available (at least in an app that took the trouble to implement this). Sadly, as with many things since hen, in some ways we've gone backwards. G. On 6 Jul 2008, at 11:41 pm, Peter Zegelin wrote: I agree with you but here is JoelOnSoftware saying virtually the complete opposite. http://www.joelonsoftware.com/items/2008/07/01.html . Fortunately most of his commenters disagree. On 06/07/2008, at 10:21 PM, Graham Cox wrote: The preferred way to do this is to prevent the user clicking the button if it's not appropriate by greying it out. This is far more user-friendly than rebuking a user for having the audacity to click your button when they shouldn't have, even though they had no visual cue that they shouldn't. The permit then rebuke form of input validation is the hallmark of bad UI design. Sadly, it's all too common. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org This email sent to [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
Le 6 juil. 08 à 17:35, Michael Ash a écrit : On Sun, Jul 6, 2008 at 11:25 AM, Bill Cheeseman [EMAIL PROTECTED] wrote: on 2008-07-06 9:49 AM, Jean-Daniel Dupas at [EMAIL PROTECTED] wrote: If __strong is so dangerous, why is it used in Cocoa (see NSDrawer, NSDateFormatter, NSNumberFormatter, NSKeyedArchiver, NSURL, Š) ? Those are interesting examples, especially NSDrawer. In NSDrawer, only the CFRunLoopTimerRef and CFRunLoopObserverRef iVars are given the __strong keyword, while the CFRunLoopRef iVar is not. This suggests to me that some very refined thinking is going on as to when to use or not to use the __strong keyword. I wish I knew what all the relevant considerations were. CFRunLoopRefs live for the entire lifetime of their thread, so there's no need for __strong. But I would suggest that, as is the case for many other things, you don't need to duplicate Apple's refined thinking as to whether to use __strong or not. Do you want to keep a reference to a CF object? If yes, use __strong. End of story. You might use __weak if you want a zeroing weak reference. But this is extremely uncommon in a dual-mode framework such as what you're writing, because there's no equivalent to __weak in the non-GC world. Aside from wanting a zeroing weak reference, there's no real reason not to use __strong. The only reason would be for performance, and as we all know, premature optimization is the root of all evil. You *can* leave off the __strong keyword, provided you do your CFRetains and CFReleases properly and implement a -finalize method to clean things up. But this is less efficient, requires more brainpower, and is unnecessary. Mike I think the rule may be: use __strong for retained/copied ivars, and nothing for assigned ivars. There is no equivalent of zeroing ref, but weak ref are really common in Cocoa. For example, delegate are not retain. the Notification center does not retain observers, and the drawer probably does not retain the runloop. smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Sun, Jul 6, 2008 at 9:05 AM, Jean-Daniel Dupas [EMAIL PROTECTED] wrote: I think the rule may be: use __strong for retained/copied ivars, and nothing for assigned ivars. There is no equivalent of zeroing ref, but weak ref are really common in Cocoa. For example, delegate are not retain. the Notification center does not retain observers, and the drawer probably does not retain the runloop. The reason delegates and observers aren't retained it to avoid retain cycles. In a GC world cycles aren't a problem (cycle with no roots will be collected). As a result ivars to delegates and observers, etc. can (and some do IIRC) use strong references. -Shawn ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 6, 2008, at 05:45, Bill Cheeseman wrote: So, back to the OQ. I am now inclined to think that, at least in my circumstances (a shared framework properly balancing CFRetain and CFRelease), I do NOT need to use the __strong keyword for the CFType- derived instance variables, in order to support garbage collection. Any disagreement? No disagreement ... just footnotes: -- #1 Provided you manage memory just like a non-GC app (so don't call CFMakeCollectable). -- #2 Provided you don't depend on any autorelease-related behavior for CF objects (so be careful with those few things that return autoreleased CF objects, and don't cast bridgeable objects over to their NS versions to call 'autorelease') -- #3 Provided you add duplicates of any CFRelease calls inside 'dealloc' methods to the corresponding 'finalize' methods, to avoid leaking those objects. Most likely you've already got #1 covered, possibly #2 won't affect the CF objects you're using, and #3 is easy if you haven't done it already. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Stopping actions mid stream
Yes: http://ignorethecode.net/blog/2008/07/01/disabling-inactive-menu- items/ (by way of DaringFireball) --Andy On Jul 6, 2008, at 11:57 AM, Jean-Daniel Dupas wrote: I haven't test but -[NSMenuItem setToolTip:] look fine to do this. Now, just chek if this methods works even when the item is disabled. Le 6 juil. 08 à 16:31, Peter Zegelin a écrit : Some of the commenters suggest a tool tip over the disabled menu explaining why it is disabled, which sounds reasonable. As a newby here would this be easy to implement in Cocoa? On 07/07/2008, at 12:02 AM, Graham Cox wrote: Wow, I'm really surprised that Joel Spolsky of all people would say this - and so recently too. I used to like System 7's Balloon Help approach - grey out the menu but the help balloon would explain why it wasn't available (at least in an app that took the trouble to implement this). Sadly, as with many things since hen, in some ways we've gone backwards. G. On 6 Jul 2008, at 11:41 pm, Peter Zegelin wrote: I agree with you but here is JoelOnSoftware saying virtually the complete opposite. http://www.joelonsoftware.com/items/2008/07/01.html . Fortunately most of his commenters disagree. On 06/07/2008, at 10:21 PM, Graham Cox wrote: The preferred way to do this is to prevent the user clicking the button if it's not appropriate by greying it out. This is far more user-friendly than rebuking a user for having the audacity to click your button when they shouldn't have, even though they had no visual cue that they shouldn't. The permit then rebuke form of input validation is the hallmark of bad UI design. Sadly, it's all too common. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 6, 2008, at 05:48, Bill Cheeseman wrote:
So here's a possible approach that was suggested to me privately,
for use in
a framework that supports garbage collection. Comments?
@interface MyFrameworkClass : NSObject {
BOOL wrappedup;
}
- (void)wrapup;
- (void)someMethod;
@end
@implementation MyFrameworkClass
- (void)finalize {
if (!wrappedup) {
// protect against inadvertent early termination
[self wrapup];
}
}
- (void)wrapup {
// cleanup code goes here
wrappedup = YES;
}
- (void)someMethod {
[self wrapup];
}
@end
IMO it's either not safe or not necessary.
The purpose of keeping stuff out of finalize is first and foremost
about safety, and only secondarily about timing or collection-time
overhead. Collectable memory that is referred to by an object being
finalized may itself already have been finalized, causing the finalize
to crash.
If it's safe to call 'wrapup' from finalize, you may as well just move
the code into finalize and eliminate the 'wrapup' method as
bureaucratic waste.
If it's not safe to call 'wrapup' from finalize, implementing 'wrapup'
hasn't solved the problem for which it was created.
My experience has been that almost every time I've convinced myself
that it was safe to use a particular collectable object in another's
finalize, I was just plain wrong.
A safer pattern might be to replace the above finalize with:
- (void)finalize {
NSAssert (wrappedup, @I'm sorry, Dave, I can't do that ...);
[super finalize];
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 10:50 AM, Clark Cox at [EMAIL PROTECTED] wrote: He even goes so far as to suggest that it would be dangerous or at least inefficient to use __strong in a mixed environment such as a shared framework that supports both garbage collection and retain/release, due in part to the additional overhead. What additional overhead does he imagine will be incurred? CFMakeCollectable as a no-op in a retain/release environment? Which I'm not sure makes sense. But I am becoming persuaded that your Option #2 is in fact the way to go. (Even though I can avoid the collection time overhead of -finalize by implementing some sort of wrapup system such as I outlined in another message.) -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 11:35 AM, Michael Ash at [EMAIL PROTECTED] wrote: You might use __weak if you want a zeroing weak reference. But this is extremely uncommon in a dual-mode framework such as what you're writing, because there's no equivalent to __weak in the non-GC world. There is a weak retain technique, and I use it in one of my frameworks. It was outlined by Ken Case of OmniGroup many years ago. See www.cocoadev.com/index.pl?WeakReferences. I anticipate that I may use __weak to replace this when my framework is used in a garbage collection environment. -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
How to create to-many accessor methods at runtime
I have an object that I would like to respond to a potentially large number of KVC compliant to-many accessors of the form: -countOfkey -objectInkey:atIndex: so that they can be used with valueForKey: to return a proxy array, or just called directly. Rather than implement these as methods (and because key specifies the array behavior), I want to be able to create them dynamically and have all accesses to -countOfkey -objectInkey:atIndex: be handled by two central methods: -countOfForKey: -objectInForKey:atIndex: that respond according to key. I had thought that implementing forwardInvocation would do this, but - forwardInvocation is only called if -respondsToSelector says NO. And if -respondsToSelector says NO, then the tests for -countOfkey and - objectInkey:atIndex: will always fail and I will lose KVC compliance. Another approach would be to override -valueForUndefinedKey:, but that gives me the responsibility of creating and returning the proxy NSArray that implements accesses to -countOfForKey: and - objectInForKey:atIndex: Is there a better way to be KVC compliant and yet create the methods dynamically? Steve Weller [EMAIL PROTECTED] Technical Writing, Editing, Developer Guides, and a little Cocoa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 1:40 PM, Quincey Morris at [EMAIL PROTECTED] wrote: The purpose of keeping stuff out of finalize is first and foremost about safety, and only secondarily about timing or collection-time overhead. Collectable memory that is referred to by an object being finalized may itself already have been finalized, causing the finalize to crash. OK. I just noticed (in an Apple tutorial on Objective-C 2.0) that NSNotificationCenter observers don't need to be set to nil in GC, so that eliminates one reason to need a -finalize method even apart from all this. -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: How to create to-many accessor methods at runtime
On Jul 6, 2008, at 12:56 PM, Steve Weller wrote: I had thought that implementing forwardInvocation would do this, but -forwardInvocation is only called if -respondsToSelector says NO. And if -respondsToSelector says NO, then the tests for -countOfkey and -objectInkey:atIndex: will always fail and I will lose KVC compliance. Looks like you almost hit on your answer, but just didn't see it. If you don't want -respondsToSelector: to return NO for certain selectors, override it to return YES. :) Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: plist parsing in c
How can you read a plist file from C? Unless you're looking for a pure C solution which isn't dependent on any Mac OS libraries, you could always use CFXMLParser and it's SAX based callbacks. Keith Duncan [EMAIL PROTECTED], 33software.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: multiple UndoManagers
I have a rather complicated undo setting I encountered a similar situation where I had multiple plugins each with their own NSManagedObjectContext and thus their own undo manager. I solved it by implementing an NSProxy subclass which held references to all the undo managers and was returned by - windowWillReturnUndoManager, it then forwarded messages to the appropriate undo manager object. Keith Duncan [EMAIL PROTECTED], 33software.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: plist parsing in c
On Jul 6, 2008, at 1:44 PM, Keith Duncan wrote: How can you read a plist file from C? Unless you're looking for a pure C solution which isn't dependent on any Mac OS libraries, you could always use CFXMLParser and it's SAX based callbacks. I think I missed the original post, so forgive me if this is off- base... If you're willing to use a framework API such as CFXMLParser to parse a plist, which not go whole-hog and use CFPropertyList? Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: plist parsing in c
Le 6 juil. 08 à 20:44, Keith Duncan a écrit : How can you read a plist file from C? Unless you're looking for a pure C solution which isn't dependent on any Mac OS libraries, you could always use CFXMLParser and it's SAX based callbacks. If you can use CFXMLParser, you can use CFPropertyList functions, it will be even easier. Note that plist have 3 formats, text, xml, and binary. smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Key equivalents for an action without a visible object item
Thanks Michael, I had deleted that MainMenu NSMenu from the MainMenu.nib thinking I didn't need it as I had another NSMenu statusItem for my app. But putting it back from an empty project's nib file solved the issue. Now the textFields accept cut,copy and paste key equivalents and since i have set LSUIElement to 1, the Application-Menu doesn't appear. -Original Message- Message: 5 Date: Sat, 5 Jul 2008 21:27:55 -0400 From: Michael Ash [EMAIL PROTECTED] Subject: Re: Key equivalents for an action without a visible object item To: Cocoa Developers cocoa-dev@lists.apple.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=UTF-8 On Sat, Jul 5, 2008 at 8:14 PM, Kanny [EMAIL PROTECTED] wrote: Is it possible to define a key-equivalent for an action like in NSMenuItem but without any visible object ? The situation is like this: I have a NSTextField in nib file of my Application-Menu-less menubar app. I want it to receive Command-v for 'paste', but since I don't have/want a menuItem to connect to FirstResponder's paste method, it doesn't react in any way to Command-v. However the textfield is able to receive paste method by Control-clicking and selecting from the system-wide contextual menu. I don't know what a menubar app is, but if it's anything like an LSUIElement app then you can just create the menu item like you normally would. The menu bar doesn't appear, but any time the app is frontmost the key equivalents still function. Mike -- ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: plist parsing in c
Note that plist have 3 formats, text, xml, and binary. That's true, but there's actually a bigger problem at hand here which I previously overlooked. located inside the file /Library/Preferences/ com.apple.xgrid.agent.plist I failed to pick this one up earlier, you shouldn't be assuming what format the preferences are written out in; in the future they might not even be in PLIST format. This is an implementation detail and much like how installer receipts have been migrated into a database; preferences might also be stored in a radically different format sometime soon. The only reliable* way to access system preferences is through the CFPreferences API which NSUserDefaults is built on. Keith Duncan [EMAIL PROTECTED], 33software.com *remember that each preference domain is liable to change, they aren't public unless declared so ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Sun, Jul 6, 2008 at 12:05 PM, Jean-Daniel Dupas [EMAIL PROTECTED] wrote: Le 6 juil. 08 à 17:35, Michael Ash a écrit : Do you want to keep a reference to a CF object? If yes, use __strong. End of story. You might use __weak if you want a zeroing weak reference. But this is extremely uncommon in a dual-mode framework such as what you're writing, because there's no equivalent to __weak in the non-GC world. Aside from wanting a zeroing weak reference, there's no real reason not to use __strong. The only reason would be for performance, and as we all know, premature optimization is the root of all evil. You *can* leave off the __strong keyword, provided you do your CFRetains and CFReleases properly and implement a -finalize method to clean things up. But this is less efficient, requires more brainpower, and is unnecessary. I think the rule may be: use __strong for retained/copied ivars, and nothing for assigned ivars. If the ivar is an ObjC object, then it's already strong automatically, unless you explicitly specify __weak. If it's a CF reference, then you really ought to use either __strong or __weak. If you use nothing, then you're just setting yourself up to explode if the object is collected. Sure, you can get your retains and releases set up to avoid that, but why bother when you have the collector there? The only reason to not put __strong on a CF ref that you would otherwise be leaving blank would be for speed, and that consideration should always come much later. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Using key-value observing on NSUserDefaults
I have a preferences controller (PreferencesController) that controls a preferences window. It would be quite nice if I could observe changes to all of the preferences via key-value observing. In IB I also have an NSUserDefaultsController that's hooked up to all the controls, I've tried observing its 'values' but that doesn't seem to work. Thanks, - Greg ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: plist parsing in c
On Jul 6, 2008, at 3:12 PM, Keith Duncan wrote: The only reliable* way to access system preferences is through the CFPreferences API which NSUserDefaults is built on. CFURLCreateDataAndPropertiesFromResource() and CFPropertyListCreateXMLData() for read. CFPropertyListCreateXMLData() and CFURLWriteDataAndPropertiesToResource() to write. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
[NSTextStorage/NSAttributedString] How can we know the height of a rendered string?
Problem:
I would like/need to know the height that would be required to render
a string inside a fixed width box.
Solution that does not work:
So far, I've been using a solution found from a google search and
which looks like this:
- (float) heightOfString:(NSString *) inString forFont:(NSFont *)
inFont andMaxWidth:(float) inMaxWidth
{
float tHeight=0;
if (inString!=nil)
{
NSTextStorage * tTextStorage;
tTextStorage=[[NSTextStorage alloc] initWithString:inString];
if (tTextStorage!=nil)
{
NSTextContainer * tTextContainer;
tTextContainer = [[NSTextContainer alloc] initWithContainerSize:
NSMakeSize(inMaxWidth, FLT_MAX)];
if (tTextContainer!=nil)
{
NSLayoutManager * tLayoutManager =
[[NSLayoutManager alloc] init];
tLayoutManager = [[NSLayoutManager alloc] init];
if (tLayoutManager!=nil)
{
[tLayoutManager
addTextContainer:tTextContainer];
[tTextStorage
addLayoutManager:tLayoutManager];
[tTextStorage addAttribute:NSFontAttributeName value:inFont
range:NSMakeRange(0, [tTextStorage length])];
[tTextContainer
setLineFragmentPadding:0.0];
[tLayoutManager
glyphRangeForTextContainer:tTextContainer];
tHeight=NSHeight([tLayoutManager
usedRectForTextContainer:tTextContainer]);
[tLayoutManager release];
}
[tTextContainer release];
}
[tTextStorage release];
}
}
return tHeight;
}
The issue with this solution is that it does not return a correct
result. 1 or 2 lines are OK (or can be corrected). Over 3 lines, the
results are incorrect (or can not be corrected reliably).
Question:
-
Which solution would work?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: [NSTextStorage/NSAttributedString] How can we know the height of a rendered string?
Le 6 juil. 08 à 21:25, Stéphane Sudre a écrit :
Problem:
I would like/need to know the height that would be required to
render a string inside a fixed width box.
Solution that does not work:
So far, I've been using a solution found from a google search and
which looks like this:
- (float) heightOfString:(NSString *) inString forFont:(NSFont *)
inFont andMaxWidth:(float) inMaxWidth
{
float tHeight=0;
if (inString!=nil)
{
NSTextStorage * tTextStorage;
tTextStorage=[[NSTextStorage alloc] initWithString:inString];
if (tTextStorage!=nil)
{
NSTextContainer * tTextContainer;
tTextContainer = [[NSTextContainer alloc] initWithContainerSize:
NSMakeSize(inMaxWidth, FLT_MAX)];
if (tTextContainer!=nil)
{
NSLayoutManager * tLayoutManager =
[[NSLayoutManager alloc] init];
tLayoutManager = [[NSLayoutManager alloc] init];
if (tLayoutManager!=nil)
{
[tLayoutManager
addTextContainer:tTextContainer];
[tTextStorage
addLayoutManager:tLayoutManager];
[tTextStorage addAttribute:NSFontAttributeName value:inFont
range:NSMakeRange(0, [tTextStorage length])];
[tTextContainer
setLineFragmentPadding:0.0];
[tLayoutManager
glyphRangeForTextContainer:tTextContainer];
tHeight=NSHeight([tLayoutManager
usedRectForTextContainer:tTextContainer]);
[tLayoutManager release];
}
[tTextContainer release];
}
[tTextStorage release];
}
}
return tHeight;
}
usedRectForTextContainer: causes neither glyph generation nor layout,
and so the result is may be inaccurate (the layout manager may be
computing the layout in background and does not have finish).
You have to make sure it is ready before using this function.
[tLayoutManager ensureLayoutForTextContainer:tTextContainer];
smime.p7s
Description: S/MIME cryptographic signature
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: [Solved] Using key-value observing on NSUserDefaults
Silly me, I needed to observe the controller itself, not the values... duh! :-p [[NSUserDefaultsController sharedUserDefaultsController] addObserver:self forKeyPath:[@values. stringByAppendingString:preferenceKey] options:NSKeyValueObservingOptionNew context:NULL]; - Greg On Jul 6, 2008, at 4:18 PM, Greg wrote: I have a preferences controller (PreferencesController) that controls a preferences window. It would be quite nice if I could observe changes to all of the preferences via key-value observing. In IB I also have an NSUserDefaultsController that's hooked up to all the controls, I've tried observing its 'values' but that doesn't seem to work. Thanks, - Greg ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/greg %40kinostudios.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: garbage collection and NSConnection
On 7/4/08, Chris Hanson [EMAIL PROTECTED] wrote: Under non-GC, an object's memory may not be reclaimed until the current autorelease pool is drained. However, under GC, an object's memory can be reclaimed as soon as the collector can tell there are no more references to it -- no matter when that is. I think Joan's point is not that there are circumstances in which the GC will never reclaim, but that it is not possible to ensure reclamation deterministically. From the docs: collectExhaustively Tells the receiver to collect iteratively. - (void)collectExhaustively Discussion You use this method to indicate to the collector that it should perform an exhaustive collection. Collection is subject to interruption on user input. Availability Available in Mac OS X v10.5 and later. Declared In NSGarbageCollector.h Collection is subject to interruption on user input -- with no mention of when it might be re-started. Hamish ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
My experience has been that almost every time I've convinced myself that it was safe to use a particular collectable object in another's finalize, I was just plain wrong. This has been my experience as well. Because the ordering of finalization is undefined, it will often work anyway, making for difficult to reproduce bugs. I've wasted so much time debugging this that I've just abandoned this idiom as impractical. The people I've talked to supporting this as a tenable idiom make unmaintainable assumptions about encapsulation violations, and inheritance implementation details, e.g. that the receiver, or its superclass, won't change in the future in ways that invalidate their assumptions. The dependencies are incredibly fragile and messaging other objects in finalize is just not worth my time. I never message another object in finalize unless my object being finalized owns a CFRetain on the receiver. 'nuke the entire site from orbit. It's the only way to be sure - 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 [EMAIL PROTECTED]
Package data store for app with agents
Hi, I'm designing an application that will consist of a main UI app plus about three agents that will perform various aspects of the product. I want to support multiple documents for the app, displayed in a single-window UI in the main app (i.e. using a source list rather than separate document windows). My thought is to store the documents on disk as file packages, with files within each owned by each of the component apps. For example, a configuration file that is only saved by the main UI app, but can be read by the agents as needed, and similar for state information for each of the agents. I would like to use Core Data for at least the main app, but realize that it doesn't support file packages. As far as I can see from the documentation, I might be able to use a custom atomic store to implement this: rather than writing out to a single file, it could write the entities out to separate files within the file packages. Or it could at least write out a file reference (e.g. path) to the single atomic store file, and use that to load/save the data in the packages. Would that work? Or is there a better way to do this? My other idea is to use single independent Core Data SQLite stores for the main app and agents as a kind of cache, and write a custom copy of the data in the file packages, and keep them in synch. But that seems less elegant (and more hazardous) to me. -- David Sinclair, Dejal Systems, LLC - [EMAIL PROTECTED] Dejal blog - http://www.dejal.com/blog/ Cocoa code - http://www.dejal.com/developer/ Twitter - http://twitter.com/dejal/ smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
re: How to create to-many accessor methods at runtime
Steve, First, have you considered the low tech approach of using a gcc variadic macro (#define) ? http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html You can generate a lot of template code this way. With one line of code per key you can generate all the accessors you need. A second option would be to override -mutableArrayValueForKey: to return a proxy object that knows both the source object and the key and fulfills the mutable KVC contract. Basically, this is creating a subclass of NSMutableArray that knows how to properly handle your source object, it's key. On 10.5, you have an additional hook that is invoked before forwarding: + (BOOL)resolveInstanceMethod:(SEL)sel; This is much more efficient than forwarding, and the result is cached, so method resolution is only invoked once per selector. It does require some nasty parsing of the selector, and use of the raw objective-c runtime functions to register the new method on the class. -forwardInvocation: is the least efficient choice, although it can be handy under some circumstances where flexibility is the most important design issue. - 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 [EMAIL PROTECTED]
Re: plist parsing in c
The only reliable* way to access system preferences is through the CFPreferences API which NSUserDefaults is built on. CFURLCreateDataAndPropertiesFromResource() and CFPropertyListCreateXMLData() for read. CFPropertyListCreateXMLData() and CFURLWriteDataAndPropertiesToResource() to write. I'm afraid you're missing the point; think of the PLIST files simply as a convenient representation of the defaults database. There is no guarantee that preference domains outside your control will remain; named consistently, where you expect them, nor in any particular format. The format of the defaults database is maintained by the CFPreferences API and should only be accessed through it. From the docs: Preferences files are stored in the system’s or user’s preferences directories. On Mac OS X versions 10.0 to 10.4 these are in /Library/ Preferences and in /Library/Preferences in the user’s home directory respectively. When debugging an application, it may sometimes be useful to inspect these files to determine that preferences have been saved correctly, however you should never hardcode these paths into an application. If you do need to access the directory programmatically you should use the NSSearchPathForDirectoriesInDomains API, although there should typically be no reason to do so. It's all very well that you can read and write to them directly; but it really isn't advisable. I'm certain the docs state NOT to assume the preference format either though I can't find it now, you simply need to take package receipts as an example though. Keith Duncan [EMAIL PROTECTED], 33software.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Reading/Writing application dictionary files.
I need to read and write a .dict file to keep state for my application. i'm new to cocoa so i don't know how a cocoa app should handle state files. i do have .dict files as resources in xcode; i've heard, but don't know how to, that you can save .dict file inbetween an application; and that your application automatically does this for certain standard features. i need to do this with a file saving information for the application/user in the right place. this file can grow large. thanks+ You don't get no juice unless you squeeze Lemon Obrien, the Third. http://www.tamago.us ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Stopping actions mid stream
Thanks Andy and Jean-Daniel. Peter On 07/07/2008, at 3:34 AM, Andy Lee wrote: Yes: http://ignorethecode.net/blog/2008/07/01/disabling-inactive-menu-items/ (by way of DaringFireball) --Andy On Jul 6, 2008, at 11:57 AM, Jean-Daniel Dupas wrote: I haven't test but -[NSMenuItem setToolTip:] look fine to do this. Now, just chek if this methods works even when the item is disabled. Le 6 juil. 08 à 16:31, Peter Zegelin a écrit : Some of the commenters suggest a tool tip over the disabled menu explaining why it is disabled, which sounds reasonable. As a newby here would this be easy to implement in Cocoa? snip ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Reading/Writing application dictionary files.
Store your state information in an NSDictionary, and write it out using the writeToFile:atomically: method. When you want to read it in, use the NSDictionary class method +dictionaryWithContentsOfFile:. Works great. On Jul 6, 2008, at 7:51 PM, Lemon Obrien wrote: I need to read and write a .dict file to keep state for my application. i'm new to cocoa so i don't know how a cocoa app should handle state files. i do have .dict files as resources in xcode; i've heard, but don't know how to, that you can save .dict file inbetween an application; and that your application automatically does this for certain standard features. i need to do this with a file saving information for the application/ user in the right place. this file can grow large. thanks+ You don't get no juice unless you squeeze Lemon Obrien, the Third. http://www.tamago.us ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/casseres%40mac.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: plist parsing in c
On 6 Jul 2008, at 6:02 PM, Keith Duncan wrote: It's all very well that you can read and write to them directly; but it really isn't advisable. I'm certain the docs state NOT to assume the preference format either though I can't find it now, you simply need to take package receipts as an example though. If the docs don't say this, they should[1]; if you're manipulating preferences domains, the only supported way to do it is use the CFPreferences or NSUserDefaults APIs. .chris [1] I'm pretty sure they do, probably pretty close to the paragraph that talks about not hard-coding the paths. -- Chris Parker Cocoa Frameworks Apple Inc. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Mysterious NULL Coming From NSUserDefaults
I've been enjoying NSUserDefaults when going through the Hillegeass book.
I've decided to do a small app that has two colors it stores. I get these
colors from a colorwell via Preference Pane.
I have bounded the values of the wells to backGroundWell and lineWell in IB.
I have the appropriately named methods. I know my bindings are ok becuase if
I just return [NSColor whiteColor] instead of the data
from NSUserDefaults, they're yellow when I open the pane. so that's ok.
I am pretty sure I'm getting a null from the defaults because the wells are
black. I have no blackColor in my project. Already searched for that. ;)
What am I doing wrong? I thought that NSUserDefaults was pretty simple...
Below are my getters and setters.
-(NSColor*)backGroundWell
{
NSLog(@called BGwell);
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSData* data = [defaults objectForKey:@BGCOLOR];
NSColor* newColor = [NSKeyedUnarchiver unarchiveObjectWithData:data];
NSLog(@retrieved Color for BG is %@, newColor);
//NSLog(@%@,[NSKeyedUnarchiver unarchiveObjectWithData:data]);
return [NSKeyedUnarchiver unarchiveObjectWithData:data];
}
-(NSColor*)lineWell
{
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSData* data = [defaults objectForKey:@LINECOLOR];
return [NSKeyedUnarchiver unarchiveObjectWithData:data];
}
-(void)setBackGroundWell: (NSColor*)newColor
{
NSLog(@New Color is %@, newColor);
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSColor* color = [backGroundWell color];
NSData* colorData = [NSKeyedArchiver archivedDataWithRootObject:color];
[defaults setObject:colorData forKey:@BGCOLOR];
NSLog(@changing background color);
}
-(void)setLineWell: (NSColor*)newColor
{
NSLog(@New Color is %@, newColor);
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSData* colorData = [NSKeyedArchiver
archivedDataWithRootObject:[lineWell color] ];
[defaults setObject:colorData forKey:@LINECOLOR];
NSLog(@changing line color);
}
---
Below is my +(void) initialize method
+(void) initialize
{
NSMutableDictionary* defaultValues = [NSMutableDictionary dictionary];
NSData* backgroundColorData = [NSKeyedArchiver
archivedDataWithRootObject:[NSColor greenColor] ];
NSData* lineColorData = [NSKeyedArchiver
archivedDataWithRootObject:[NSColor whiteColor] ];
[defaultValues setObject:backgroundColorData forKey:@BGCOLOR];
[defaultValues setObject:lineColorData forKey:@LINECOLOR];
[[NSUserDefaults standardUserDefaults] registerDefaults:defaultValues];
NSLog(@registered defaults %@, defaultValues);
}
--
If you can't be kind, at least have the decency to be vague.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: How to create to-many accessor methods at runtime
On Jul 6, 2008, at 5:02 PM, Ben Trumbull wrote: First, have you considered the low tech approach of using a gcc variadic macro (#define) ? http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html You can generate a lot of template code this way. With one line of code per key you can generate all the accessors you need. I had not considered this. However I do want to set up the methods at run time since the action of the methods depends on how a number of other objects are set up and attached. A second option would be to override -mutableArrayValueForKey: to return a proxy object that knows both the source object and the key and fulfills the mutable KVC contract. Basically, this is creating a subclass of NSMutableArray that knows how to properly handle your source object, it's key. My class only presents a set of immutable to-many accessors. But now I am wondering -- if I do that my values may get optimized away by another object that thinks the values never change. I should probably add the mutable accessors too, even if they do nothing. On 10.5, you have an additional hook that is invoked before forwarding: + (BOOL)resolveInstanceMethod:(SEL)sel; This is much more efficient than forwarding, and the result is cached, so method resolution is only invoked once per selector. It does require some nasty parsing of the selector, and use of the raw objective-c runtime functions to register the new method on the class. That's an interesting option. My selectors are fixed, so that would not be too bad. -forwardInvocation: is the least efficient choice, although it can be handy under some circumstances where flexibility is the most important design issue. I'm sticking with that for now. Another responder set me straight about -respondToSelector being only for he convenience of other methods. I can say YES as long as I actually implement the dynamic methods somehow. NSInvocation is a good container for all the information I need, so I also use it to call the method. I set up one NSInvocation per method and select the correct one based on the selector I am passed after dropping the arguments in as needed, then transfer the return result back. - Ben Steve Weller [EMAIL PROTECTED] Technical Writing, Editing, Developer Guides, and a little Cocoa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Reading/Writing application dictionary files.
On Jul 6, 2008, at 10:51 PM, Lemon Obrien wrote: I need to read and write a .dict file to keep state for my application. i'm new to cocoa so i don't know how a cocoa app should handle state files. i do have .dict files as resources in xcode; i've heard, but don't know how to, that you can save .dict file inbetween an application; and that your application automatically does this for certain standard features. i need to do this with a file saving information for the application/ user in the right place. In the right place... thats the key. Check out the Apple Human Interface Guidelines.. specifically the Resource Management section of The Mac OS X Environment. This covers exactly where this should go. http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGMOSXEnvironment/chapter_8_section_9.html#/ /apple_ref/doc/uid/TP40002721-TPXREF142 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Mysterious NULL Coming From NSUserDefaults
Indeed. Both the setters and getters are being called. I looked in the plist
file for my app and I see BgColor and LineColor
as values with a bunch of digits/hex for its value.
On Sun, Jul 6, 2008 at 10:13 PM, Thomas Mueller
[EMAIL PROTECTED] wrote:
Hi,
Are the setters actually being called? Maybe the values are never
being stored in the defaults? Maybe have a look at the preferences
file for your app (in ~Library/Preferences) to see if anything is
stored in there. I guess you won't be able to see *which* color is
stored, though.
Just an idea; I'm just a few chapters ahead of you, so I'm probably
wrong... :-)
Regards,
Thomas
2008/7/7 Alex Wait [EMAIL PROTECTED]:
I've been enjoying NSUserDefaults when going through the Hillegeass book.
I've decided to do a small app that has two colors it stores. I get these
colors from a colorwell via Preference Pane.
I have bounded the values of the wells to backGroundWell and lineWell in
IB.
I have the appropriately named methods. I know my bindings are ok becuase
if
I just return [NSColor whiteColor] instead of the data
from NSUserDefaults, they're yellow when I open the pane. so that's ok.
I am pretty sure I'm getting a null from the defaults because the wells
are
black. I have no blackColor in my project. Already searched for that.
;)
What am I doing wrong? I thought that NSUserDefaults was pretty simple...
Below are my getters and setters.
-(NSColor*)backGroundWell
{
NSLog(@called BGwell);
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSData* data = [defaults objectForKey:@BGCOLOR];
NSColor* newColor = [NSKeyedUnarchiver unarchiveObjectWithData:data];
NSLog(@retrieved Color for BG is %@, newColor);
//NSLog(@%@,[NSKeyedUnarchiver unarchiveObjectWithData:data]);
return [NSKeyedUnarchiver unarchiveObjectWithData:data];
}
-(NSColor*)lineWell
{
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSData* data = [defaults objectForKey:@LINECOLOR];
return [NSKeyedUnarchiver unarchiveObjectWithData:data];
}
-(void)setBackGroundWell: (NSColor*)newColor
{
NSLog(@New Color is %@, newColor);
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSColor* color = [backGroundWell color];
NSData* colorData = [NSKeyedArchiver
archivedDataWithRootObject:color];
[defaults setObject:colorData forKey:@BGCOLOR];
NSLog(@changing background color);
}
-(void)setLineWell: (NSColor*)newColor
{
NSLog(@New Color is %@, newColor);
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSData* colorData = [NSKeyedArchiver
archivedDataWithRootObject:[lineWell color] ];
[defaults setObject:colorData forKey:@LINECOLOR];
NSLog(@changing line color);
}
---
Below is my +(void) initialize method
+(void) initialize
{
NSMutableDictionary* defaultValues = [NSMutableDictionary dictionary];
NSData* backgroundColorData = [NSKeyedArchiver
archivedDataWithRootObject:[NSColor greenColor] ];
NSData* lineColorData = [NSKeyedArchiver
archivedDataWithRootObject:[NSColor whiteColor] ];
[defaultValues setObject:backgroundColorData forKey:@BGCOLOR];
[defaultValues setObject:lineColorData forKey:@LINECOLOR];
[[NSUserDefaults standardUserDefaults]
registerDefaults:defaultValues];
NSLog(@registered defaults %@, defaultValues);
}
--
If you can't be kind, at least have the decency to be vague.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/thomasmueller76%40googlemail.com
This email sent to [EMAIL PROTECTED]
--
If you can't be kind, at least have the decency to be vague.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Mysterious NULL Coming From NSUserDefaults
Sorry. forgot something.
I should add this: I tried reading NSColorPanel from the file (it's a
NSString) and I WAS able to read that just fine.
I think it has something to do with NSKeyedArchive/NSKeyedUnarchiver
On Sun, Jul 6, 2008 at 10:40 PM, Alex Wait [EMAIL PROTECTED] wrote:
Indeed. Both the setters and getters are being called. I looked in the
plist file for my app and I see BgColor and LineColor
as values with a bunch of digits/hex for its value.
On Sun, Jul 6, 2008 at 10:13 PM, Thomas Mueller
[EMAIL PROTECTED] wrote:
Hi,
Are the setters actually being called? Maybe the values are never
being stored in the defaults? Maybe have a look at the preferences
file for your app (in ~Library/Preferences) to see if anything is
stored in there. I guess you won't be able to see *which* color is
stored, though.
Just an idea; I'm just a few chapters ahead of you, so I'm probably
wrong... :-)
Regards,
Thomas
2008/7/7 Alex Wait [EMAIL PROTECTED]:
I've been enjoying NSUserDefaults when going through the Hillegeass
book.
I've decided to do a small app that has two colors it stores. I get
these
colors from a colorwell via Preference Pane.
I have bounded the values of the wells to backGroundWell and lineWell in
IB.
I have the appropriately named methods. I know my bindings are ok
becuase if
I just return [NSColor whiteColor] instead of the data
from NSUserDefaults, they're yellow when I open the pane. so that's ok.
I am pretty sure I'm getting a null from the defaults because the wells
are
black. I have no blackColor in my project. Already searched for that.
;)
What am I doing wrong? I thought that NSUserDefaults was pretty
simple...
Below are my getters and setters.
-(NSColor*)backGroundWell
{
NSLog(@called BGwell);
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSData* data = [defaults objectForKey:@BGCOLOR];
NSColor* newColor = [NSKeyedUnarchiver unarchiveObjectWithData:data];
NSLog(@retrieved Color for BG is %@, newColor);
//NSLog(@%@,[NSKeyedUnarchiver unarchiveObjectWithData:data]);
return [NSKeyedUnarchiver unarchiveObjectWithData:data];
}
-(NSColor*)lineWell
{
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSData* data = [defaults objectForKey:@LINECOLOR];
return [NSKeyedUnarchiver unarchiveObjectWithData:data];
}
-(void)setBackGroundWell: (NSColor*)newColor
{
NSLog(@New Color is %@, newColor);
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSColor* color = [backGroundWell color];
NSData* colorData = [NSKeyedArchiver
archivedDataWithRootObject:color];
[defaults setObject:colorData forKey:@BGCOLOR];
NSLog(@changing background color);
}
-(void)setLineWell: (NSColor*)newColor
{
NSLog(@New Color is %@, newColor);
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
NSData* colorData = [NSKeyedArchiver
archivedDataWithRootObject:[lineWell color] ];
[defaults setObject:colorData forKey:@LINECOLOR];
NSLog(@changing line color);
}
---
Below is my +(void) initialize method
+(void) initialize
{
NSMutableDictionary* defaultValues = [NSMutableDictionary
dictionary];
NSData* backgroundColorData = [NSKeyedArchiver
archivedDataWithRootObject:[NSColor greenColor] ];
NSData* lineColorData = [NSKeyedArchiver
archivedDataWithRootObject:[NSColor whiteColor] ];
[defaultValues setObject:backgroundColorData forKey:@BGCOLOR];
[defaultValues setObject:lineColorData forKey:@LINECOLOR];
[[NSUserDefaults standardUserDefaults]
registerDefaults:defaultValues];
NSLog(@registered defaults %@, defaultValues);
}
--
If you can't be kind, at least have the decency to be vague.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/thomasmueller76%40googlemail.com
This email sent to [EMAIL PROTECTED]
--
If you can't be kind, at least have the decency to be vague.
--
If you can't be kind, at least have the decency to be vague.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: NSURLConnection timeoutInterval only works in multiples of 30 seconds
On 2008 Jul, 05, at 15:55, [EMAIL PROTECTED] wrote: But when i run the app, the After statement with timed out message is logged after 30 seconds from the Before statement. When I set the timeoutInterval between 30.1 to 59.9, it is printed after 60 seconds and so on. I don't know how to get it to work in desired time intervals. Any help would be appreciated. Kanny, I noticed about two years ago that I could never get the 10- second timeouts that I wanted using NSURLConnection and setting the timeout in the NSURLRequest as you are doing which, as far as I know, is the only way to do it. (Well, actually you can make the request mutable and then set it, but the result is the same.) Then I read that others had reported the same thing in the list archives, and since this was intolerable for my app, I ended writing my own whole stupid class that set up a thread with a timer to work around the problem. I am developing a Leopard-only app now and planned to re-test NSURLConnection within the next few days, hoping that it has been fixed. I therefore find your report very disappointing. You are using Leopard I presume? Has anyone else tested the URL Loading System with sub-30-second timeouts lately? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Mysterious NULL Coming From NSUserDefaults
Well, I see a couple problems here 1) Even though you're getting directly passed a color in your setters, you're ignoring that and trying to find out the color from the wells. That's bad form for many reasons, and if those backGroundWell and lineWell variables weren't hooked up correctly, that would explain your symptoms. Especially since your lineWell and backGroundWell aren't getting hooked up correctly. 2) Since I can't see your whole project, I can't be 100% sure, but I'm 99% sure your lineWell and backGroundWell probably aren't getting hooked up correctly. This is because you named your color setters and getters *the exact same thing* as the instance variables for your color wells. This is a big mistake, for reasons that are way too complicated to explain in an email. The short version is that when nibs are loaded, outlets are set using key-value coding. If you have a method named -setLineWell: and an ivar named lineWell, the KVC routines assume that the -setLineWell: method is the way to set the lineWell ivar and call that method instead of setting lineWell directly. You can avoid this problem in the future by making your getter and setter names describe what you're actually getting and setting, i.e -lineWell and -setLineWell: should get/set an NSColorWell, while -lineColor and -setLineColor: should get/set an NSColor. 3) Pulling back a bit, you're working way too hard. You don't have to write any code at all to hook a color well up to a preference key. You just bind to the 'Shared User Defaults Controller', set the controller key to 'values', the Model Key to whatever you want your preference key to be, and the Value Transformer to NSUnarchiveFromData (it'll be in the popup menu). It will handle all that archiving and unarchiving you're currently doing manually. 4) The G in Background should not be capitalized. ;) Best wishes, Bo ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
