Re: Trouble with design pattern
., I need to declare an instance of MyDocument inside my view's classes. The compiler won't let me do this unless I import MyDocument to the class definitions. The problem is that the classes are already included in MyDocument and the chicken/egg thing makes XCode spit a zillion compile errors (naturally). I tried declaring the variables inside the custom views as type 'id' and tested the approach calling a MyDocument method which shows some data in various textfields. The code compiled and ran, but MyDocument never got the messages. // inside custom view's class definition id document; // inside awakeFromNib document = [ [ [ self window ] windowController ] document ]; // inside mouseUp [document refreshParameters]; If I just query the window controler for the document on demand like this: [ [ [ [ self window ] windowController ] document refreshParameters ]; the code works, but I still can't get rid of those message-not-found warnings: warning: no '-refreshParamters' method found (Messages without a matching method signature will be assumed to return 'id' and accept '...' as arguments.) So my questions are: 1) Is there a better way to approach this? 2) Is it OK to just call the document like this and ignore the compiler warning? I'd really appreciate if someone could comment on this - i'd hate to find out later that i'd been building on a bad design... Thanks already for a y help. Carlos. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com This email sent to ag...@mac.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: mouseDown in NSSegmentedControl
Did you override mouseDown or mouseDown:? --Andy On Jan 14, 2011, at 03:08 PM, koko k...@highrolls.net wrote: I have sub-classed NSSegmentedControl and set this class to the NSSegmentedControl in IB. I have implemented mouseDown in the sub-class thinking I would get these events. I do not. How does one get mouseDown in an NSSegmentedControl? -koko ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
QuickLook returning small image
I'm requesting a QuickLook preview for an OmniGraffle file. The size I'm asking for is 500x300. The image I get back is much smaller, at 122x77, which looks terrible when I display it in my application. When I use QuickLook to preview the same file in the Finder, it looks great. Why would I get such a small image back? Here's the code I'm using (courtesy of Matt Gemmell's handy extension on NSImage): NSDictionary *dict = [NSDictionary dictionaryWithObject:[NSNumbernumberWithBool:icon] forKey:(NSString*)kQLThumbnailOptionIconModeKey]; CGImageRef ref = QLThumbnailImageCreate(kCFAllocatorDefault, (CFURLRef)fileURL, CGSizeMake(size.width, size.height), (CFDictionaryRef)dict); NSLog(@ref [%d, %d], CGImageGetWidth(ref), CGImageGetHeight(ref)); The size passed to QLThumbnailImageCreate is documented as an upper bound. I assume that means there's no promise the returned image will actually be that size. But again, the Finder is able to get previews at any size I want. --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: QuickLook returning small image
On Jan 13, 2011, at 01:06 PM, Kyle Sluder kyle.slu...@gmail.com wrote: Taking a while stab here: icon==YES? I get the same result (size-wise) whether icon is YES or NO. Joar pointed out off-list that Finder might be asking for a *preview* rather than a *thumbnail*. I totally missed that distinction and I bet it's the explanation. Thanks, --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: QuickLook returning small image
On Jan 13, 2011, at 01:07 PM, Kyle Sluder kyle.slu...@gmail.com wrote: On Thu, Jan 13, 2011 at 10:06 AM, Kyle Sluder kyle.slu...@gmail.com wrote: Taking a while stab here: icon==YES? *Wild* stab. Coffee is good. I was going to say, in this case it's more of an if stab than a while stab. --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: how do I put a subview in a superview with color
On Dec 30, 2010, at 06:13 PM, colo colo0l...@gmail.com wrote:
I can get it to compile just fine now but I can't get the button to
show up at all.
Perhaps I am sending the addSubview to the incorrect place? NSView
*superview = [window contentView];
I thought contentView was the top.
@implementation WVShapesView
-(BOOL) isFlipped { return YES;}
- (id)initWithFrame:(NSRect)frame {
self = [super initWithFrame:frame];
if (self) {
// Initialization code here.
NSView *superview = [window contentView];
NSRect frame = NSMakeRect(10, 10, 200, 100);
NSButton *button = [[NSButton alloc] initWithFrame:frame];
[button setTitle:@aggg];
[superview addSubview:button];
[button release];
}
return self;
}
The immediate answer to your question is that your init method is the wrong
place to do this. The view is in the process of being created, so it doesn't
belong to any window yet. Try doing this in awakeFromNib. See the
documentation for awakeFromNib for more info.
Related points that will make your life easier:
(1) Use the debugger and/or NSLog statements. This is the kind of thing where
you should use the debugger to confirm the code is going through the steps you
think it is. In this case I would have stepped through initWithFrame: to
confirm the button is being created and does become a subview of the window's
content view. I'm pretty sure if you do this you will find the window is nil.
You could also have discovered this by adding NSLog statements. Messages sent
to nil don't do anything, so the button you created never gets added as a
subview of anything.
(2) Use nibs. Setting up view hierarchies is exactly the kind of thing nib
files (also known as xib files) are for. You can create your WVShapesView and
your button within your window, and you can easily do some of the things you
left out in your code. For example, it just takes a couple of clicks to
specify how your button should reposition itself when the window resizes. Also
in the code above you never set an action for the button to perform when it is
clicked; you would typically do this with a simple drag in Interface Builder.
The overwhelming majority of Cocoa UIs are constructed with Interface Builder,
especially where it's just a couple of subviews within a window.
(3) Separation of concerns. The design of WVShapesView is flawed if it's
adding a button to its own window; it's not even adding the button to itself.
Suppose you create a window containing two WVShapesViews? They will both put a
button in the window. The existence of the button is no concern of the
WVShapeView, and the view shouldn't muck with the view hierarchy outside of
itself. Better to create your layout in a nib file and create a view
controller and/or window controller that loads the nib. See NSViewController
and NSWindowController.
Hope this helps,
--Andy
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: access multiple NSTextFields as an array?
On Dec 20, 2010, at 11:11 AM, Siegfried triebschen.siegfried.id...@gmail.com wrote: Check documentation for NSArray and NSMutableArray for more info, it's your friend! :-) And an easy way to do this is by Option-Command-double-clicking on NSArray and NSMutableArray in your code. Note that NSMutableArray inherits from NSArray. --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa view gets sluggish over time
On Dec 20, 2010, at 09:13 AM, Artemiy Pavlov artemiy.pav...@ukrpost.ua wrote: NSTextField *PatternStepLabel = [[NSTextField alloc] initWithFrame:NSMakeRect(x, y, 20, 20)]; NSString *PatternStepLabelString = [NSString stringWithFormat:@%d, i]; [PatternStepLabel setEditable:NO]; [PatternStepLabel setDrawsBackground:NO]; [PatternStepLabel setSelectable:NO]; [PatternStepLabel setBezeled:NO]; [PatternStepLabel setAlignment:2]; [PatternStepLabel setTextColor:StepColor]; [PatternStepLabel setStringValue:PatternStepLabelString]; [PatternStepLabel setFont:[NSFont fontWithName:@Courier size:8.0]]; [self addSubview:PatternStepLabel]; [PatternStepLabelString release]; [PatternStepLabel release]; You seem to have solved your main problem, so I'll just comment on a couple of other things. (1) You are over-releasing PatternStepLabelString. stringWithFormat: returns an object you do not own, which means you are not responsible for releasing it. In fact, you must not release it, because releasing an object too many times will cause your program to crash. Note that it is correct to release PatternStepLabel, because alloc returns an object that you do own. You must release it (either right away or later via autorelease), or it will be a memory leak. See http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html, in particular Memory Management Rules. (2) Unless you need PatternStepLabelString for something else, you can eliminate it altogether by using setIntValue: instead of setStringValue: as follows. [PatternStepLabel setIntValue:i]; (3) The convention in Cocoa is to begin variables with lowercase letters, like this: NSTextField *patternStepLabel; NSString *patternStepLabelString; If you work with other Cocoa developers, or even if you paste code into emails like this one, you can make the code easier for others to read by sticking to convention. --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: access multiple NSTextFields as an array?
On Dec 20, 2010, at 11:42 AM, Artemiy Pavlov artemiy.pav...@ukrpost.ua wrote: Yes, sorry, I have setTextColor actually. Still, it doesn't work.. I suggest pasting your exact code into email. Don't abbreviate and don't type it by hand. --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: access multiple NSTextFields as an array?
On Dec 20, 2010, at 11:30 AM, Scott Ribe scott_r...@elevated-dev.com wrote: Anyway, there's no need for an NSMutableArray. You can just have a plain C array as an attribute of your class, and set up its entries in awakeFromNib: patterRateLabels[0] = numberLabel1; patterRateLabels[1] = numberLabel2; I don't recommend this approach. It's safer to get the memory management benefits of NSMutableArray, and not worry about off-by-one or array overflow errors. --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[MEET] CocoaHeads-NYC, tonight
In one hour! Sorry for the late notice again. --Andy -- Paul Kim will be our last speaker of 2010. His talk will be on Memory management with blocks an introduction to heapshot analysis -- two topics for the price of one! Admission is free and everyone's welcome. Just tell the person at the front you're there for CocoaHeads. Thursday, Dec 9 6:00 PM - 8:00 PM Downstairs at Tekserve, on 23rd between 6th and 7th http://tekserve.com/about/hours.php for directions and map As usual: (1) Please feel free to bring questions, code, and works in progress. We have a projector and we like to see code and try to help. (2) We'll have burgers and beer afterwards. (3) If there's a topic you'd like presented, let us know. (4) If *you'd* like to give a talk, let me know. Hope to see you there! --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Drawers on windows...
Hi, A.M. :) Here are some thoughts on why I went that way with AppKiDo. Maybe they'll be relevant to others considering a drawer. * One reason I went with the drawer is that by sliding it in and out you can change its width without affecting the layout of the parent window. That matters less to me than it used to, and offhand I can't give a solid reason other than personal preference why it matters at all, but it does matter some. I think it's appropriate that OmniWeb uses a drawer rather than a source list for listing tabs. * The HIG says A drawer should contain frequently accessed controls that don’t need to be visible at all times. I'm torn about whether I comply with this. Almost all my navigation in AppKiDo starts with the search field, which makes it *so* frequently accessed that it almost does need to be visible at all times. I actually didn't foresee how often I'd use the search field, but I don't think it would have affected my decision to put it in the drawer. * This could be splitting hairs, but I don't think the search drawer provides hierarchical navigation the way a typical source list does. The class browser on top, if it was an outline view, would be the more the equivalent of a source list. (I considered but rejected the idea of using an outline view because I think an NSBrowser is a better way to navigate the class hierarchy. Those aren't the only options, though.) * One thing I've considered is using a source list plus some sort of unobtrusive control on the left edge of the window that would allow resizing the window from that edge. I would like if the main Xcode window had such a feature, so I could widen or shrink the Groups Files pane without affecting the width of my source code pane. This would have the disadvantage of pretty nonstandard. Anyway my source code pane is so wide I don't notice the change anyway, so I don't mind so much using the splitter to resize the Groups Files pane. --Andy On Nov 30, 2010, at 05:45 PM, A.M. age...@themactionfaction.com wrote: On Nov 30, 2010, at 5:27 PM, Jean-Daniel Dupas wrote: And for completeness of the answer, here is when Apple recommends to use drawer: http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGWindows/XHIGWindows.html%23//apple_ref/doc/uid/2961-BACEFIJH You should not use a drawer to provide users with a way to navigate hierarchically arranged content in your window. If you need to do this in your application, you should use a source list instead. R.I.P. AppKiDo search drawer. Cheers, M ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
[ANN] CocoaHeads-NYC tonight, Wed 10/13
Our meeting date this month will be Wednesday Oct 13 (tonight) rather than the usual Thursday. I'll be doing a quick show-and-tell of how to get a WebView to talk to Cocoa, via JavaScript. Daniel Jalkut will show his Web Inspector. Bob Clair is generously contributing three copies of his book to raffle off. Check it out: http://www.amazon.com/Learning-Objective-C-2-0-Hands-Developers/dp/0321711386/ Learning Objective-C 2.0: A Hands-On Guide to Objective-C for Mac and iOS Developers WEDNESDAY, Oct 13 6:00 - 8:00 Downstairs at Tekserve, on 23rd between 6th and 7th http://tekserve.com/about/hours.php for directions and map Everyone's welcome. Just tell the person at the front you're there for CocoaHeads. As usual: (1) Please feel free to bring questions, code, bugs, and works in progress. We have a projector and we like to see code and try to help. (2) We'll have food and beer afterwards. It was Shake Shack last month, so in theory it should be pizza this month, but nothing's written in stone. (3) If there's a topic you'd like presented, let us know. (4) If *you'd* like to give a talk (and you know you would!), let me know. It can be brief and casual or as painstakingly prepared as a Steve Jobs keynote. Up to you. Hope to see you there! --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Style question
On 30 Aug, 2010,at 11:33 AM, Dave DeLong davedel...@me.com wrote: My personal preference is the latter example. My general rule of thumb is that once I -release or -autorelease an object, I shouldn't interact with it anymore, since I have relinquished ownership of said object. Definitely true once you release, but the whole purpose of autorelease is to allow you to interact with the object despite relinquishing ownership. For example, in Vincent's code he is returning the new autoreleased object precisely so the caller can use it. For all the reasons already given, I actually think this is a case where there is a right answer and not so much a matter of personal preference. If you're going to autorelease, do so right away. I think this falls in the same category as do the alloc and the init in the same statement. --Andy The only time I don't follow that guideline is when I'm working inside a method that has several different return routes, and cleaning up the appropriate objects at each point would just add to the complexity of the method (which could be argued is already too complex, but that's for another thread). In this case, I'll autorelease the appropriate objects immediately after initialization, thereby sparing me from having to clean stuff up in every single one of the return conditions. Dave On Aug 30, 2010, at 9:29 AM, Vincent Habchi wrote: Hi everybody, just an enquiry regarding coding style. What is considered best: baz = [[[Foo alloc] init] autorelease]; … return baz; or baz = [[Foo alloc] init]; … return [baz autorelease]; ? Thanks! Vincent ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com This email sent to ag...@mac.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: Tracking multiple NSURLConnections
(Coming late to this thread...) I recently used both approaches. Subclassing NSURLConnection worked nicely and was quick to code when I had just one kind of delegate behavior. When I had to add other kinds of delegate behavior I switched to the multiple-delegate-classes approach and used plain NSURLConnection. My classes are lightweight wrappers that hide the NSURLConnection machinery and define their own delegates (this is the weak pointer Dave described). My classes' delegates are notified when either (1) the connection fails, (2) the connection finishes getting the data and the data is invalid, or (3) the connection finishes getting the data and the data is okay. This was my first time using NSURLConnection, so I'm glad each of the two approaches I used makes sense to at least one other person. :) --Andy On 29 Jun, 2010,at 03:31 PM, Stevo Brock st...@monkey-tools.com wrote: You could also subclass NSURLConnection and add any additional data to your subclass that you can easily access in the callbacks. On Jun 29, 2010, at 12:11 PM, Dave DeLong wrote: If you're spawning dozens of connections, you may want to consider giving each one a separate delegate object and encapsulating that connection's specific logic in that delegate. The url connection delegate might then have a weak pointer back to the original controller to notify when the connection is finished, at which point the controller could extract any data it needs from the connection delegate. Dave On Jun 29, 2010, at 1:08 PM, lorenzo7...@gmail.com wrote: Now, a devil's advocate question: If I have lots of connections, say two dozen, or say I'm spawning connections continuously, would this be the most efficient way of doing this? I'd likely store them in an NSArray and iterate/compare until I find the right one. There could be lots of comparisons. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/stevo%40monkey-tools.com This email sent to st...@monkey-tools.com -Stevo ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/aglee%40maccom This email sent to ag...@mac.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: Deallocation while key value observers still registered
On May 25, 2010, at 10:54 AM, Kyle Sluder kyle.slu...@gmail.com wrote: This sounds off you're deregistering obeservers in your observee's -dealloc? In general this would sound off to me too, on the principle that observees normally don't know who their observers are. �It�only makes sense to me if the observee added the observers to itself in the first place, on the principle that whoever adds an observer should take it away. On May 25, 2010, at 09:49 AM, Roland King r...@rols.org wrote: That's not it then, in Snow Leopard there was a change so that message was only emitted at the end of the dealloc() method instead of at the start which allowed you to deregister your observers in dealloc() and not get this error. In Leopard and in (I think still in) iPhone OS you get the message at the start of dealloc whether you are just about to deregister your observers or not. Thanks for this -- I vaguely remember something about the change in Snow Leopard but it hadn't clearly registered in my mind. I had an idea for a perverse hack to deal with the problem in Leopard, which was to to override release and do the deregistering there if the retainCount is 1, thus sneaking in the deregistering just before dealloc but no sooner. --Andy On 25-May-2010, at 9:33 PM, Gideon King wrote: 10.6.3 On 25/05/2010, at 11:17 PM, Roland King wrote: what version of what operating system are you using? On 25-May-2010, at 9:14 PM, Gideon King wrote: Hi, I'm getting the message: An instance 0x11d0ce4b0 of class NMGeneralPrintAccessoryController was deallocated while key value observers were still registered with it. Observation info was leaked, and may even become mistakenly attached to some other object. Set a breakpoint on NSKVODeallocateBreak to stop here in the debugger. Here's the current observation info: all my observers But I have put a breakpoint on my dealloc method, and in there, I do deregister for those notifications. Dealloc is called, and I did check that it was the same object, and all the calls to deregister are there. So I don't know how it could *not* be removing the observers. Any clues where to look? Thanks Gideon ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com This email sent to ag...@mac.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
