Quicklook thumbnails vs previews, API for previews?
Hi, The QuickLook API documentation defines and contrasts thumbnails and previews, but all I see on the client side is the only function QLThumbnailImageCreate. I assume this is for creating thumbnails, isn't it? In that case, how do I create previews on the client side? Alternatively, if this function is meant for creating both thumbnails and previews, is there a way to force create thumbnail or preview? Thanks. Oleg. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Wed, Jun 29, 2011 at 10:38 PM, James Merkel jmerk...@mac.com wrote: Ok, thanks. For what I'm doing file descriptors are not a scarce resource. File descriptors are almost always a scarce resource. By default, each process only gets 256 of them. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUndoManager - unstable state
On Wed, Jun 29, 2011 at 10:40 PM, livinginlosange...@mac.com wrote: Is there a way to check if the NSUndomanager is in an unstable state and reset it? No, NSUndoManager is very fragile, and if it gets into a bad state it is not recoverable. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 29, 2011, at 11:07 PM, Kyle Sluder wrote: On Wed, Jun 29, 2011 at 10:38 PM, James Merkel jmerk...@mac.com wrote: Ok, thanks. For what I'm doing file descriptors are not a scarce resource. File descriptors are almost always a scarce resource. By default, each process only gets 256 of them. --Kyle Sluder Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
Le 30 juin 2011 à 08:19, James Merkel a écrit : On Jun 29, 2011, at 11:07 PM, Kyle Sluder wrote: On Wed, Jun 29, 2011 at 10:38 PM, James Merkel jmerk...@mac.com wrote: Ok, thanks. For what I'm doing file descriptors are not a scarce resource. File descriptors are almost always a scarce resource. By default, each process only gets 256 of them. --Kyle Sluder Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? No, Just like process ID, file descriptor number can be reused by the system. And there is absolutely no guarantee the system use simple incremental value for fd AFAIK. -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 3:02 AM, Jean-Daniel Dupas wrote: Le 30 juin 2011 à 08:19, James Merkel a écrit : Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? No, Just like process ID, file descriptor number can be reused by the system. That analogy is a bit flawed. Process IDs are global across the system. File descriptors are per-process. And there is absolutely no guarantee the system use simple incremental value for fd AFAIK. Actually, when a new file descriptor is created for your process, it does use the lowest unused descriptor number (except for dup2()). Still, the File Activity instrument's event list isn't showing a count of file descriptors, it's showing the specific individual file descriptor involved in the specific event. But there's a pretty good chance that the highest file descriptor you see across a significant range of events roughly indicates the count of open descriptors. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Scaling CALayer produces blurry/distorted text
Hello, I have an application in which the user can continuously zoom and pan a canvas (kind of like Google Maps). On the canvas, a user can have multiple text items. Each text item is a Core Animation layer, and the text is drawn using NSLayoutManager's drawGlyphsForGlyphRange method. When the canvas is zoomed in or out, the text item is scaled using CGContextScaleCTM. The text however, is blurry at certain zoom levels. If I set the magnification filter of the CALayer to kCAFilterNearest, it almost works, but at a few (seemingly random) zoom levels, there appear to be some artifacts. Here are four links, each one showing different scenarios: 1) Using kCAFilterNearest magnification filter, at a zoom level where no artifacts are produced. http://mothercreative.com/ajay/text/perfect.png 2) Using kCAFilterNearest magnification filter, at a zoom level where some artifacts are produced (areas in red). http://mothercreative.com/ajay/text/artifacts1.jpg http://mothercreative.com/ajay/text/artifacts2.png 3) Using the default magnification filter, notice blurriness. http://mothercreative.com/ajay/text/blurry.png I've ensured already that the frame rect is integral (so that the layer isn't sitting on half pixels), font smoothing is off, and antialiasing is on. Any suggestions as to why these artifacts are showing up, or how to produce more clear results without using the kCAFilterNearest magnification filter, would be much appreciated. Thanks, Ajay ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUndoManager - unstable state
On 2011 Jun 29, at 23:08, Kyle Sluder wrote: On Wed, Jun 29, 2011 at 10:40 PM, livinginlosange...@mac.com wrote: Is there a way to check if the NSUndomanager is in an unstable state and reset it? No, NSUndoManager is very fragile, and if it gets into a bad state it is not recoverable. and it's a black box you can't see inside. Here we go again. For any real app of significant complexity, particularly if it uses Core Data, I highly recommend using Graham Cox' GCUndoManager instead of NSUndoManager: http://apptree.net/gcundomanager.htm You'll be happy immediately, and at any future date when you need to debug an undo issue. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 2:01 AM, Ken Thomases wrote: On Jun 30, 2011, at 3:02 AM, Jean-Daniel Dupas wrote: Le 30 juin 2011 à 08:19, James Merkel a écrit : Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? No, Just like process ID, file descriptor number can be reused by the system. That analogy is a bit flawed. Process IDs are global across the system. File descriptors are per-process. And there is absolutely no guarantee the system use simple incremental value for fd AFAIK. Actually, when a new file descriptor is created for your process, it does use the lowest unused descriptor number (except for dup2()). Still, the File Activity instrument's event list isn't showing a count of file descriptors, it's showing the specific individual file descriptor involved in the specific event. But there's a pretty good chance that the highest file descriptor you see across a significant range of events roughly indicates the count of open descriptors. Regards, Ken That's kind of what I concluded -- that the FD is roughly the current number of file descriptors. I noticed that sometimes the FD shows -1, but that's only in a transient condition. I attribute that to Instruments not being able to keep up. It never settles down to -1. After a fair amount of application warm-up the FD shows 25 to 26. So, I assume I'm ok. The FD has a pattern similar to memory in use. It grows for a while when you start and use an application, then settles out to some value. If it grows continually I guess you have a problem. In order not to get a fire-hose amount of data, you can type in a file-name (or some other identifier) into the spotlight-like magnifier box in the lower right corner of the Instruments window. Then you are looking at only files of interest. Again this sort of works, but Instruments still may not show everything. Jim Merkel___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Properties, Attributes and Retain+Autorelease
On 2011-06-29, at 21:50 , Quincey Morris wrote: You're looking for provable correctness. That's laudable, and will probably mean that you keep all of your fingers. But you'll still end up in the emergency room -- in your case it will be for a stress-induced ulcer. :) My university professor once said: If you write code that other people will or have to use and they are supposed to use it without having to read your source code first, implement every method/function in such a way as if everybody out there has only one goal: Breaking it! Either by feeding completely absurd input parameters to it or by calling your methods/functions any completely absurd order or combination you can ever think of. Excuse me for saying this, but I think this particular discussion has gone on too long. The discussion was going on for hardly 9 hours when you wrote that. You're not going to get any new answers to your questions, because there are no answers to give beyond what's already been said. Actually I think I didn't get answers to those questions, because nobody knew the answers and instead of arguing why the answers don't matter, people could have just admitted that they don't know the answers either. Anyway, I think I figured out those answers all by myself in the meantime. Kind regards, Markus ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Properties, Attributes and Retain+Autorelease (SOLVED)
Since nobody was able to provide real answers to my questions, I wrote some
dummy code to find out as much about that issue as possible. Here are the
results:
Remember, I listed the following cases:
a) retain
b) retain, nonatomic
c) copy
d) copy, nonatomic
e) assign
f) assign, nonatomic
And I gave sample code for a) and b) already:
a) retain
- (id)value
{
id res;
[_magic_lock lock];
res = [value retain];
[_magic_lock unlock];
return [res autorelease];
}
- (void)setValue:(id)aNewValue
{
[_magic_lock lock];
if (aNewValue != value) {
[value release];
value = [aNewValue retain];
}
[_magic_lock unlock];
}
b) retain, nonatomic
- (id)value
{
return value;
}
- (void)setValue:(id)aNewValue
{
if (aNewValue != value) {
[value release];
value = [aNewValue retain];
}
}
As far as my testing goes, the sample code seems to be pretty close to what's
really going on, though Apple is probably doing all this stuff on a much lower
level, possibly highly optimized and thus much faster than the code above ever
could. Here's how the code for the other cases would look like:
c) copy
The getter equals case a)
- (void)setValue:(id)aNewValue
{
[_magic_lock lock];
if (aNewValue != value) {
[value release];
value = [aNewValue copy];
}
[_magic_lock unlock];
}
d) copy, nonatomic
The getter equals case b)
- (void)setValue:(id)aNewValue
{
if (aNewValue != value) {
[value release];
value = [aNewValue copy];
}
}
e) assign
- (id)value
{
id res;
[_magic_lock lock];
res = value;
[_magic_lock unlock];
return res;
}
- (void)setValue:(id)aNewValue
{
[_magic_lock lock];
value = aNewValue;
[_magic_lock unlock];
}
f) assign, nonatomic
- (id)value
{
return value;
}
- (void)setValue:(id)aNewValue
{
value = aNewValue;
}
Apple may optimize case e) to become case f) in case reading/writing value is
an atomic operation anyway, e.g. setting a 32 bit value on a 32 bit CPU is
guaranteed to be atomic already through the compiler. However, setting a 64 bit
value on a 32 bit CPU (or a 64 bit CPU running in 32 bit mode) is not atomic
for example, just like setting a 8/16 bit value on a 32/64 bit CPU may not be
atomic (this depends on CPU, e.g. some operations are atomic on Intel CPUs that
used to be not atomic on PPC CPUs).
Kind regards,
Markus___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 9:20 AM, James Merkel wrote: On Jun 30, 2011, at 2:01 AM, Ken Thomases wrote: On Jun 30, 2011, at 3:02 AM, Jean-Daniel Dupas wrote: Le 30 juin 2011 à 08:19, James Merkel a écrit : Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? No, Just like process ID, file descriptor number can be reused by the system. That analogy is a bit flawed. Process IDs are global across the system. File descriptors are per-process. And there is absolutely no guarantee the system use simple incremental value for fd AFAIK. Actually, when a new file descriptor is created for your process, it does use the lowest unused descriptor number (except for dup2()). Still, the File Activity instrument's event list isn't showing a count of file descriptors, it's showing the specific individual file descriptor involved in the specific event. But there's a pretty good chance that the highest file descriptor you see across a significant range of events roughly indicates the count of open descriptors. Regards, Ken That's kind of what I concluded -- that the FD is roughly the current number of file descriptors. I noticed that sometimes the FD shows -1, but that's only in a transient condition. I attribute that to Instruments not being able to keep up. It never settles down to -1. After a fair amount of application warm-up the FD shows 25 to 26. So, I assume I'm ok. The FD has a pattern similar to memory in use. It grows for a while when you start and use an application, then settles out to some value. If it grows continually I guess you have a problem. In order not to get a fire-hose amount of data, you can type in a file-name (or some other identifier) into the spotlight-like magnifier box in the lower right corner of the Instruments window. Then you are looking at only files of interest. Again this sort of works, but Instruments still may not show everything. Jim Merkel After looking some more at Instruments File Activity, I see that the FD can end up in a static state with an FD of -1. I'm not sure what that means. However I think Ken Thomases' statement is correct: Still, the File Activity instrument's event list isn't showing a count of file descriptors, it's showing the specific individual file descriptor involved in the specific event. But there's a pretty good chance that the highest file descriptor you see across a significant range of events roughly indicates the count of open descriptors. You can sort on the FD column and find the largest FD, so that's pretty easy to find. I notice that the Instruments documentation (User Guide) doesn't explain these things, at least as far as I could tell. Maybe you're just supposed to know this (from birth I guess). Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[Q] Will the be any problem in implementing an NSArray method using fast enumeration?
Hello,
I wrote a method for NSArray.
- (NSArray *)objectsForKey:(id)key
{
NSMutableArray *objectsArray = [NSMutableArray arrayWithCapacity:10];
for( id item in self )
{
[objectsArray addObject:[item objectForKey:key]];
}
return [[objectsArray copy] autorelease];
}
What I'm curious is if it is OK to use fast enumeration to implement an NSArray
method itself.
Because the mechanism for fast enumeration is already there, I basically think
it will be OK.
However, wouldn't it better to rely on the most fundamental mechanism like
objectAtIndex:?
I found someone's implementation here at
http://svn.opengroupware.org/SOGo/inverse/trunk/SoObjects/SOGo/NSArray+Utilities.m
Approaching such a way looks reasonable to me, because it should work whatever
underlying mechanism is supported by Objective-C.
Will there be any good/bad aspect in using fast enumeration in this case?
Thank you.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: [Q] Will the be any problem in implementing an NSArray method using fast enumeration?
Yeah, that should be fine, but it's unnecessary.
You can just do:
NSArray *objectsArray = [theArray valueForKey:key];
And it'll do pretty much the same thing (except that it'll call -valueForKey:
on each item in the array, and not objectForKey:. However, if the objects are
NSDictionaries, that's pretty much the same thing).
Dave
On Jun 30, 2011, at 11:59 AM, JongAm Park wrote:
Hello,
I wrote a method for NSArray.
- (NSArray *)objectsForKey:(id)key
{
NSMutableArray *objectsArray = [NSMutableArray arrayWithCapacity:10];
for( id item in self )
{
[objectsArray addObject:[item objectForKey:key]];
}
return [[objectsArray copy] autorelease];
}
What I'm curious is if it is OK to use fast enumeration to implement an
NSArray method itself.
Because the mechanism for fast enumeration is already there, I basically
think it will be OK.
However, wouldn't it better to rely on the most fundamental mechanism like
objectAtIndex:?
I found someone's implementation here at
http://svn.opengroupware.org/SOGo/inverse/trunk/SoObjects/SOGo/NSArray+Utilities.m
Approaching such a way looks reasonable to me, because it should work
whatever underlying mechanism is supported by Objective-C.
Will there be any good/bad aspect in using fast enumeration in this case?
Thank you.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/davedelong%40me.com
This email sent to davedel...@me.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Thu, Jun 30, 2011 at 9:20 AM, James Merkel jmerk...@mac.com wrote: After a fair amount of application warm-up the FD shows 25 to 26. So, I assume I'm ok. And what happens when (not if) you introduce a leak, and these objects live longer than you expect them to? Or worse, someone else starts holding on to these objects? You're already using an -invalidate method. You just happened to call it -dealloc. Why not follow good defensive programming practice and make it explicit to save yourself future headaches? --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 12:04 PM, Kyle Sluder wrote: On Thu, Jun 30, 2011 at 9:20 AM, James Merkel jmerk...@mac.com wrote: After a fair amount of application warm-up the FD shows 25 to 26. So, I assume I'm ok. And what happens when (not if) you introduce a leak, and these objects live longer than you expect them to? Or worse, someone else starts holding on to these objects? You're already using an -invalidate method. You just happened to call it -dealloc. Why not follow good defensive programming practice and make it explicit to save yourself future headaches? --Kyle Sluder Ok, I don't know what an -invalidate method is, but I'll look it up. Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Thu, Jun 30, 2011 at 12:12 PM, James Merkel jmerk...@mac.com wrote: Ok, I don't know what an -invalidate method is, but I'll look it up. It's the thing Wim talked about. An explicit way to release the scarce resource you're holding on to. Depending on what that resource is, an appropriate name might be -close, or -invalidate, or -terminate. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [Q] Will the be any problem in implementing an NSArray method using fast enumeration?
You might also try HBCollections, a series of collections categories I wrote that makes it easy to do stuff like this. https://github.com/hborders/HBCollections -Heath On Jun 30, 2011 2:10 PM, Dave DeLong davedel...@me.com wrote: ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 12:21 PM, Kyle Sluder wrote: On Thu, Jun 30, 2011 at 12:12 PM, James Merkel jmerk...@mac.com wrote: Ok, I don't know what an -invalidate method is, but I'll look it up. It's the thing Wim talked about. An explicit way to release the scarce resource you're holding on to. Depending on what that resource is, an appropriate name might be -close, or -invalidate, or -terminate. --Kyle Sluder I saw that in Wlm's post. However, I'm not sure where I would do that. I'll have to think about it some more. By the way my original post referred to the Memory Management Programming Guide and the statement: You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. I was pretty sure that file descriptors referred to something at a lower level, but wasn't sure. Maybe I'm being pedantic, but Apple could have helped things along by saying: You should typically not manage scarce resources such as Unix file descriptors, ... Everyone doesn't approach this stuff with the same background. We find from Kernighan and Ritchie (KR) second edition, section 8.1 that a file descriptor is a small non-negative integer that refers to a file and is maintained by the system. So, my guess is that when Instruments shows an FD of -1 it refers to an FD that isn't mine. But that's just a guess. Instruments doesn't document this as far as I know. Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Activate app but bring only *one* window to the front
On 2011 Jun 29, at 10:11, Kyle Sluder wrote: -[NSRunningApplication activateWithOptions:] Thank you, Kyle, that works. Indeed, in Mac OS 10.6+, the code [[NSRunningApplication currentApplication] activateWithOptions:NSApplicationActivateIgnoringOtherApps] ; activates the app, but only brings forward the key/main window(s), as desired. (My actual code is longer since this app uses the 10.5 SDK. 10.5 users will get all windows activated.) However, Cocoa still wins. My purpose was to show an alert-type of window (my own custom version of NSAlert) without bringing forward a document window. Initially, it works, but when the user clicks a button which sends -[NSWindow close] to the alert window, the document window is brought forward, even if I try and tell it no by deactivating the app… NSLog(@Will close alert window in 5 seconds) ; sleep(5) ; [NSApp deactivate] ; [[self window] close] ; [NSApp deactivate] ; NSLog(@Did close alert window. Will continue in 5 seconds) ; sleep(5) ; That test shows that it's definitely -[NSWindow close] which brings the next window forward, not -[NSApp stopModal] or -[NSApp endModalSession]. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [Q] Will the be any problem in implementing an NSArray method using fast enumeration?
Um... Thanks for your reply. The last time I used that was about 5 or 6 years ago, and I wondered yesterday where it went away. :) Thanks for pointing out that method. BTW, my actual question was if it is meant to use fast enumeration in a collection class implementation. Although I tried to add objectsForKey: to existing NSArray, it should be OK, because it is to rely on existing, fully functional one. However, let's say we write a class like NSArray that supports fast enumeration, block based enumeration, numerator based enumeration and finally index based iteration. The rationale behind enumerator pattern is to unify the way to access collection classes no matter what they actually look like. So, enumerator pattern is actually written in index based iteration wrapped with enumerator pattern. Similarly, I guessed fast enumeration was based on either index iteration or enumerator pattern. Also, fast enumeration is a language feature. So, if Objective-C without fast enumerator is used, methods written with fast enumerator would not work. So, my question was originally for that. :) Anyway, it's not big deal now. Thank you :) JongAm Park On Jun 30, 2011, at 12:02 PM, Dave DeLong wrote: Yeah, that should be fine, but it's unnecessary. You can just do: NSArray *objectsArray = [theArray valueForKey:key]; And it'll do pretty much the same thing (except that it'll call -valueForKey: on each item in the array, and not objectForKey:. However, if the objects are NSDictionaries, that's pretty much the same thing). Dave ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On 2011 Jun 30, at 13:33, James Merkel wrote: I'm not sure where I would do that [-invalidate, releaseResources, removeObservers, whatever] That's a common dilemma. There is no general solution. Each situation will have its own least-worst solution. Apple could have helped things along by saying… Please scroll down to the bottom, Did this document help you?, and click Not helpful… ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 1:33 PM, James Merkel wrote: We find from Kernighan and Ritchie (KR) second edition, section 8.1 that a file descriptor is a small non-negative integer that refers to a file and is maintained by the system. Actually file descriptors are used for any sort of I/O channel, including the default stdin/stdout/stderr streams, network sockets, IPC connections, and more. Running out of them is less uncommon than you’d think, so it’s a good idea to close unneeded ones ASAP. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Activate app but bring only *one* window to the front
On Jun 30, 2011, at 2:39 PM, Jerry Krinock wrote: However, Cocoa still wins. My purpose was to show an alert-type of window (my own custom version of NSAlert) without bringing forward a document window. Initially, it works, but when the user clicks a button which sends -[NSWindow close] to the alert window, the document window is brought forward, even if I try and tell it no by deactivating the app… That's the way windowing behavior is defined in OS X. When the frontmost regular window is closed, the next window of that app is made frontmost. Sounds like you need a floating/utility window of some flavor. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [Q] Will the be any problem in implementing an NSArray method using fast enumeration?
On Jun 30, 2011, at 13:51, JongAm Park wrote: The rationale behind enumerator pattern is to unify the way to access collection classes no matter what they actually look like. So, enumerator pattern is actually written in index based iteration wrapped with enumerator pattern. Similarly, I guessed fast enumeration was based on either index iteration or enumerator pattern. No, not necessarily, if by index iteration you mean 'objectAtIndex:'. NSArray has 2 primitive methods (count and objectAtIndex:) that a concrete subclass must implement. It also conforms to NSFastEnumeration, so a concrete subclass must also implement 'countByEnumeratingWithState:objects:count:'. That's three primitive methods you know for sure are implemented in any concrete subclass. There's no way of knowing (in general) whether these primitive implementations make use of each other. I'm virtually certain, for example, that in NSCFArray (the standard but private concrete subclass of NSArray), countByEnumeratingWithState:objects:count: doesn't use objectAtIndex:, because part of the point of fast enumeration is to eliminate per-object method calls if possible. I'm also virtually certain that NSCFArray's enumerator uses the fast enumeration method countByEnumeratingWithState:objects:count: directly, rather than using objectAtIndex:. The method you wrote is non-primitive. However, you know that all of the primitive methods and protocols are implemented, so it's safe to use those directly (as others already replied). It's also safe to use all of the standard non-primitive methods, because the abstract NSArray class provides default implementations of all of them, regardless of whether a subclass overrides them for performance reasons. Also, fast enumeration is a language feature. So, if Objective-C without fast enumerator is used, methods written with fast enumerator would not work. If an older Objective-C runtime is used, you'll get an invalid selector exception for 'countByEnumeratingWithState:objects:count:', so yes it would not work in that sense. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [Q] Will the be any problem in implementing an NSArray method using fast enumeration?
Wow.. great information! Thank you very much for sharing your idea! It definitely helped me! JongAm Park On Jun 30, 2011, at 2:41 PM, Quincey Morris wrote: On Jun 30, 2011, at 13:51, JongAm Park wrote: The rationale behind enumerator pattern is to unify the way to access collection classes no matter what they actually look like. So, enumerator pattern is actually written in index based iteration wrapped with enumerator pattern. Similarly, I guessed fast enumeration was based on either index iteration or enumerator pattern. No, not necessarily, if by index iteration you mean 'objectAtIndex:'. NSArray has 2 primitive methods (count and objectAtIndex:) that a concrete subclass must implement. It also conforms to NSFastEnumeration, so a concrete subclass must also implement 'countByEnumeratingWithState:objects:count:'. That's three primitive methods you know for sure are implemented in any concrete subclass. There's no way of knowing (in general) whether these primitive implementations make use of each other. I'm virtually certain, for example, that in NSCFArray (the standard but private concrete subclass of NSArray), countByEnumeratingWithState:objects:count: doesn't use objectAtIndex:, because part of the point of fast enumeration is to eliminate per-object method calls if possible. I'm also virtually certain that NSCFArray's enumerator uses the fast enumeration method countByEnumeratingWithState:objects:count: directly, rather than using objectAtIndex:. The method you wrote is non-primitive. However, you know that all of the primitive methods and protocols are implemented, so it's safe to use those directly (as others already replied). It's also safe to use all of the standard non-primitive methods, because the abstract NSArray class provides default implementations of all of them, regardless of whether a subclass overrides them for performance reasons. Also, fast enumeration is a language feature. So, if Objective-C without fast enumerator is used, methods written with fast enumerator would not work. If an older Objective-C runtime is used, you'll get an invalid selector exception for 'countByEnumeratingWithState:objects:count:', so yes it would not work in that sense. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Core Data: stop object from firing fault?
Is there anyway to stop an NSManagedObject from firing a fault, say because it's actually been deleted? For instance if an object is created on the main thread and is then punted to a background thread and deleted (in a separate context of course) then the changes are merged back to the main thread, the reference on the main thread shows it's now a fault, but not that it's deleted. If the object fires its fault then of course an exception is raised. Does anyone know a way to change this behavior so that you can test if an object is invalid? -- Michael___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Instance Variables of NSManagedObject Subclasses
Dear cocoa-dev list,
I want my NSManagedObjects to retain a variable valid for the lifetime the
application instance but not between instances of the application. So I
have subclassed NSManagedObject and added an instance variable to the
NSManagedObject subclass and defined a property as follows:
from the NSManagedObject sublcass header file:
@interface KCBMergingManagedObject : NSManagedObject
{
NSNumber *mergeID;
}
@property(readwrite, retain) NSNumber *mergeID;
and the corresponding .m file contains
@synthesize mergeID;
Accessing that property has worked but now I have a case where it fails as
follows:
NSString *foo;
NSString *matchValueTemp;
foo= entityBTemp.mergeID;
matchValueTemp= [entityBTemp valueForKey: @userTypeName];
foo= entityBTemp.mergeID;
Here, userTypeName is a field of the entity defined in the core data model
and retain by the context. At line three of that that snippet the data of
entityBTemp is faulted. The fault is uniqued by accessing userTypeName in
the fourth line. In the fifth line, accessing entityBTemp.mergeID causes
the application to crash with EXC_BAD_ACCESS. The values returned in
variables foo and
matchValueTemp in lines 3 and 4 are correct.
Am I not supposed to add instance variables to NSManagedObject sublcasses?
It does seem like a poor idea from the standpoint that it would interfere
with faulting because the data held in the variable and perhaps then
also relationships could not be faulted. I can not find anything in Cocoa
documentation discussing instance variables in NSManagedObject subclasses.
Is it necessary to define transient attribute in the model to get a volatile
property in a managed object? Or I could define a new field in the model,
retained between app instances, and clear it at application launch. I
would like to understand what is going on here though.
Allen W. Ingling
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Instance Variables of NSManagedObject Subclasses
Dear cocoa-dev list,
I want my NSManagedObjects to retain a variable valid for the lifetime the
application instance but not between instances of the application. So I
have subclassed NSManagedObject and added an instance variable to the
NSManagedObject subclass and defined a property as follows:
from the NSManagedObject sublcass header file:
@interface KCBMergingManagedObject : NSManagedObject
{
NSNumber *mergeID;
}
@property(readwrite, retain) NSNumber *mergeID;
and the corresponding .m file contains
@synthesize mergeID;
Accessing that property has worked but now I have a case where it fails as
follows:
NSString *foo;
NSString *matchValueTemp;
foo= entityBTemp.mergeID;
matchValueTemp= [entityBTemp valueForKey: @userTypeName];
foo= entityBTemp.mergeID;
Here, userTypeName is a field of the entity defined in the core data model
and retain by the context. At line three of that that snippet the data of
entityBTemp is faulted. The fault is uniqued by accessing userTypeName in
the fourth line. In the fifth line, accessing entityBTemp.mergeID causes
the application to crash with EXC_BAD_ACCESS. The values returned in
variables foo and
matchValueTemp in lines 3 and 4 are correct.
Am I not supposed to add instance variables to NSManagedObject sublcasses?
It does seem like a poor idea from the standpoint that it would interfere
with faulting because the data held in the variable and perhaps then
also relationships could not be faulted. I can not find anything in Cocoa
documentation discussing instance variables in NSManagedObject subclasses.
Is it necessary to define transient attribute in the model to get a volatile
property in a managed object? Or I could define a new field in the model,
retained between app instances, and clear it at application launch. I
would like to understand what is going on here though.
Allen W. Ingling
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Instance Variables of NSManagedObject Subclasses
Dear cocoa-dev list,
I want my NSManagedObjects to retain a variable valid for the lifetime the
application instance but not between instances of the application. So I
have subclassed NSManagedObject and added an instance variable to the
NSManagedObject subclass and defined a property as follows:
from the NSManagedObject sublcass header file:
@interface KCBMergingManagedObject : NSManagedObject
{
NSNumber *mergeID;
}
@property(readwrite, retain) NSNumber *mergeID;
and the corresponding .m file contains
@synthesize mergeID;
Accessing that property has worked but now I have a case where it fails as
follows:
NSString *foo;
NSString *matchValueTemp;
foo= entityBTemp.mergeID;
matchValueTemp= [entityBTemp valueForKey: @userTypeName];
foo= entityBTemp.mergeID;
Here, userTypeName is a field of the entity defined in the core data model
and retain by the context. At line three of that that snippet the data of
entityBTemp is faulted. The fault is uniqued by accessing userTypeName in
the fourth line. In the fifth line, accessing entityBTemp.mergeID causes
the application to crash with EXC_BAD_ACCESS. The values returned in
variables foo and
matchValueTemp in lines 3 and 4 are correct.
Am I not supposed to add instance variables to NSManagedObject sublcasses?
It does seem like a poor idea from the standpoint that it would interfere
with faulting because the data held in the variable and perhaps then
also relationships could not be faulted. I can not find anything in Cocoa
documentation discussing instance variables in NSManagedObject subclasses.
Is it necessary to define transient attribute in the model to get a volatile
property in a managed object? Or I could define a new field in the model,
retained between app instances, and clear it at application launch. I
would like to understand what is going on here though.
Allen W. Ingling
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
James Merkel wrote: Everyone doesn't approach this stuff with the same background. We find from Kernighan and Ritchie (KR) second edition, section 8.1 that a file descriptor is a small non-negative integer that refers to a file and is maintained by the system. Wikipedia is also a useful reference. When I select the words file descriptors on a web page, contextual- click it (right click, secondary click, control click), then choose Search with Google from the contextual menu, Wikipedia's page is the top hit. -- GG ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Thu, Jun 30, 2011 at 7:06 PM, Greg Guerin glgue...@amug.org wrote: James Merkel wrote: Everyone doesn't approach this stuff with the same background. We find from Kernighan and Ritchie (KR) second edition, section 8.1 that a file descriptor is a small non-negative integer that refers to a file and is maintained by the system. Wikipedia is also a useful reference. When I select the words file descriptors on a web page, contextual-click it (right click, secondary click, control click), then choose Search with Google from the contextual menu, Wikipedia's page is the top hit. Wikipedia is hardly the definitive reference. SEO comes to mind. The following was one of the best I've seen, where Dr. Adler is asked to explain why his reference implementation differs from Wikipedia: This is going out the Mr. Adler, his friends at zlib, the related newsgroups comp.compression and sci.crypt, and the newsgroups sci.math and sci.math.num-analysis... This post relates to suspect calculations... The algorithm is described in the last parts of RFC 1950 and at its Wikipedia page (http://en.wikipedia.org/wiki/Adler-32). [1] Jeff [1] Need peer review: May have found mistake in Adler-32!, http://groups.google.com/group/comp.compression/browse_thread/thread/5a37a9fcd32786fd/9859a0c61a3fb333 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data: stop object from firing fault?
On 30 Jun 2011, at 23:01, Michael Link wrote: Is there anyway to stop an NSManagedObject from firing a fault, say because it's actually been deleted? For instance if an object is created on the main thread and is then punted to a background thread and deleted (in a separate context of course) then the changes are merged back to the main thread, the reference on the main thread shows it's now a fault, but not that it's deleted. If the object fires its fault then of course an exception is raised. Does anyone know a way to change this behavior so that you can test if an object is invalid? In this scenario your object should match the combo of -isFault and (managedObjectContext == nil) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
Jeffrey Walton wrote: Wikipedia is hardly the definitive reference. SEO comes to mind. Luckily, I didn't say Wikipedia was a definitive reference. I said useful reference. And anyone at all familiar with it knows full well that its accuracy (and usefulness) can vary widely. I, for one, would never use it as a definitive reference for any algorithm, though I may well use its links at the end of an article to begin my search for definitive references. My main point was more that there is a very easy way to search for unknown terms that one encounters when reading documentation on the web. This is on the same level as pointing out that nearly every reference page on developer.apple.com has Feedback buttons at the bottom of the page, where complaints about unknown terms can easily be filed. -- GG ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Modify metadata of existing file using AVFoundation
Hi all, I'm playing around a bit with AVFoundation and it seems to have all the audio related functionality I could possibly want (playback, metadata, mixing, etc.) but there's one thing I'm having trouble figuring out. I know how to read metadata from a file via AVAsset's -commonMetadata method, but there doesn't seen to be a convenient way to *change* the metadata of an existing file. The AVMutableMetadataItem class exists, but the only place I can really find where using it would be applicable is AVAssetWriter's metadata property. The overview of AVAssetWriter mentions that it is used for write media data to a new file, which isn't exactly what I'm looking for. Any suggestions are appreciated. Thanks, Indragie___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Activate app but bring only *one* window to the front
On Jun 30, 2011, at 3:39 PM, Jerry Krinock wrote: On 2011 Jun 29, at 10:11, Kyle Sluder wrote: -[NSRunningApplication activateWithOptions:] Thank you, Kyle, that works. Indeed, in Mac OS 10.6+, the code [[NSRunningApplication currentApplication] activateWithOptions:NSApplicationActivateIgnoringOtherApps] ; activates the app, but only brings forward the key/main window(s), as desired. (My actual code is longer since this app uses the 10.5 SDK. 10.5 users will get all windows activated.) For what it's worth, that new method is simply the Cocoa equivalent of SetFrontProcessWithOptions with kSetFrontProcessFrontWindowOnly. So, you can use the latter for 10.5 compatibility. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 3:33 PM, James Merkel wrote: So, my guess is that when Instruments shows an FD of -1 it refers to an FD that isn't mine. What the File Activity instrument is showing in its event list is a certain subset of system calls which operate on file descriptors. It is showing each call. When one of those events shows a file descriptor of -1, it typically means that call failed, because system calls which return file descriptors typically return -1 (or other negative number) to indicate failure. By the way, since File Activity is only monitoring a subset of file-descriptor-related system calls, you can't necessarily use it to track leaks of file descriptors. I have opened a bug report with Apple about the need for an instrument which tracks all file descriptor activity, but it hasn't had any response. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Thu, Jun 30, 2011 at 6:34 PM, James Merkel jmerk...@mac.com wrote: Then wherever I was sending the -release, I need to also send a separate -close. it could be before or after the release, it doesn't really matter. No, it really needs to be before the -release. When you call -release, you relinquish your ownership of that object. It may cease to exist at that point. It may continue to live for an indeterminate amount of time. But either way, yes, it's one method call, done before the call to -release. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dealloc and scarce resources
On Jun 30, 2011, at 6:39 PM, Kyle Sluder wrote: On Thu, Jun 30, 2011 at 6:34 PM, James Merkel jmerk...@mac.com wrote: Then wherever I was sending the -release, I need to also send a separate -close. it could be before or after the release, it doesn't really matter. No, it really needs to be before the -release. When you call -release, you relinquish your ownership of that object. It may cease to exist at that point. It may continue to live for an indeterminate amount of time. But either way, yes, it's one method call, done before the call to -release. --Kyle Sluder Ok, doing the -close first makes more sense. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
