Re: Private ivars, not marked as IBOutlet, visible in IB
Am 04.03.2010 um 19:58 schrieb Joanna Carter: I have no problem with this concept of default behaviour, if it is for legacy purposes but, with the new visibility specifiers, these should take precedence of the older legacy rules. Never mind, as long as you prepend the private ivar with an underscore, it disappears :-) Which is something some people at Apple encourage not to do. The leading underscore is seen as Library implementors naming space (also and especially for method signatures) so your code might break when you use that coding pattern. OTOH, enforcing would break many peoples codebase, so it is unlikely that will ever happen. Regards, Tom_E ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Forcing text layout
In practice it probably won't because I believe the Cocoa typesetter always produces more glyphs than characters (eg: inserting null glyphs as padding). I'm not sure that's true - sometimes, multiple characters get replaced by a single glyph (i.c.o. ligatures). In other words: It can change both ways. Regards, Sander___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Key-Value Observing speed
As people often seem to do with such things, I was misinterpreting what it [Instruments] was telling me. A really really simple way of getting a handle on where a program is spending its time is to take a few samples in Activity Monitor while it is busy. You'd be amazed at how well this works. Breaking into the debugger is another good trick. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Better sorting using threads?
Yes, that's what I mean. But it worked fine on Leopard and Tiger... It's all academic now anyway, I rewrote it around my own, STL-based collection classes. I just thought I'd mention it in case it bit anybody else. I didn't keep a copy of the code, sorry. And I know about the difference between copy and mutableCopy Ken so it wasn't that, but it was a nice idea to suggest it. Paul Sanders. - Original Message - From: Greg Parker gpar...@apple.com To: Paul Sanders p.sand...@alpinesoft.co.uk Cc: Cocoa-Dev List cocoa-dev@lists.apple.com Sent: Saturday, March 13, 2010 12:01 AM Subject: Re: Better sorting using threads? mutating method sent to immutable object, you mean? That suggests your NSMutableDictionary object isn't as mutable as you thought. It might not be a thread-related bug. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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 Animation vs. Basic Cocoa Graphics
Am 12.03.2010 um 03:13 schrieb Mazen M. Abdel-Rahman: For the calendar grid I was creating an NSTrackingArea for each cell - in my case (the calendar is for 7 days with 15 minutes per cell) there was 672 NSTrackingAreas. I will have to look at alternative solutions to all these NSTrackingAreas to improve the performance. Erm, you are using tracking areas to subdivide into a rectangular grid instead of dayOfWeek = x / dayItemWidth; selectedTime = 0.25f * ((dayHeight - y) / timeSectionHeight ); ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Which iPhone Program?
This is not really a Cocoa question... - If you want your application in the store you need Company. - If you want to distribute in a big company (1000 employees) without using the store you want the enterprise. The account is for the whole company. But the one who pays owns the account. So you own the account and are able to add more phones/pods and people. Be aware that you can not change the owner easily. atze PS. I’d think all this info is on Apple’s site somewhere... Am 12.03.2010 um 12:02 schrieb Don Quixote de la Mancha: Greetings, Earthlings, I just subscribed. I'm just about to sign up for the paid iPhone developer program, but I'm not able to tell from Apple's website which program I should join. Presently I am the only developer, but we have two QA testers who will need to build my code on their own Macs, as well as install onto their devices themselves rather than have me do it for them. The reason is that the three of us are far apart geographically; I also want to ensure that someone else other than just myself can build my source. Both the iPhone Developer Program - Company and iPhone Developer Enterprise Program include the Ability to Create Developer Team. But nowhere can I find any information as to just what that means. I expect the we need licenses for three developer seats. I'll join the Enterprise Program if I really have to, but due to my limited budget, I'd rather join the Company Program if that would suffice. I'd like to suggest to my friends at Apple that they add some more details to the web pages that describe the iPhone developer programs, so that everything which is included with each type of program is made completely explicit. Thank you for any insight you can give me, Don Quixote -- Don Quixote de la Mancha quix...@dulcineatech.com http://www.dulcineatech.com Dulcinea Technologies Corporation: Software of Elegance and Beauty. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/atze%40freeport.de This email sent to a...@freeport.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Private ivars, not marked as IBOutlet, visible in IB
Am 13.03.2010 um 10:32 schrieb Joanna Carter: All that is needed is to detect whether the ivar is @private and to respect that visibility. If an ivar is private, it should not be visible in the IB designer, regardless of whether it is of type id or not. I’d say no to this. If my class is files owner the whole nib is owned by it - hence the name. Therefore I absolutely want IB to be able to set even the private ivars. The nib is just another way of setting up my class’ objects. atze ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Private ivars, not marked as IBOutlet, visible in IB
Try: #define PRIVATE_ID id ... PRIVATE_ID myPrivateiVar; Paul Sanders. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Private ivars, not marked as IBOutlet, visible in IB
I don't know if Joanna was suggesting you couldn't make anything available to IB by making it an IBOutlet, I took it that she was saying the old 'compatibility mode' of having any variable of type 'id', even if not an IBOutlet, be visible in IB would not be broken if you restricted it to those variables of type id which were not @private, because @private post-dates any code which should be depending on that old hack. I sort of agree, but I also sort of don't have this issue, never had a variable of type id in my class. If I did, I'd probably make it NSObject* and .. does that make it stop? On 13-Mar-2010, at 8:04 PM, Alexander Spohr wrote: Am 13.03.2010 um 10:32 schrieb Joanna Carter: All that is needed is to detect whether the ivar is @private and to respect that visibility. If an ivar is private, it should not be visible in the IB designer, regardless of whether it is of type id or not. I’d say no to this. If my class is files owner the whole nib is owned by it - hence the name. Therefore I absolutely want IB to be able to set even the private ivars. The nib is just another way of setting up my class’ objects. atze ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSResponder / acceptsFirstResponder
On Mar 12, 2010, at 1:17 PM, David Blanton wrote: How does one get a views acceptsFirstResponder method called without having to click on the view? You may be looking for -makeFirstResponder: in the NSWindow class. -acceptsFirstResponder should be called automatically... If not, you'll need to provide more details on what you are trying to accomplish. If a class subclasses NSResponder so it can get events how does one get an instance of this class in the responder chain? You can use -setNextResponder: in the NSResponder class to modify the responder chain and insert your own stuff. I would suggest reading the Cocoa Event-Handling Guide ( http://bit.ly/9hx11x ). There is a lot of good, important stuff in there, including stuff on the responder chain. I might also suggest picking up a copy of Cocoa Design Patterns (Paperback) ~ Erik M. Buck • ISBN-10: 0321535022 • ISBN-13: 978-0321535023 There is a chapter in this book on the responder chain and, basically, everything else in the book is stuff you're going to want to know. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Private ivars, not marked as IBOutlet, visible in IB
Hi Alexander
If my class is files owner the whole nib is owned by it - hence the name.
Therefore I absolutely want IB to be able to set even the private ivars. The
nib is just another way of setting up my class’ objects.
If I may say so, to say this is to misunderstand object oriented design.
The class that you designate as the File's Owner is a controller class that you
might create from within IB but that I would create in Xcode and assign to the
File's Owner in IB.
Regardless of how you create a controller class, it is entitled to have private
state that is not visible in the NIB file. This is true of all classes that
contain instances of other classes - the containing class's state is not
usually visible in the contained instance, unless the designer of the
containing class explicitly makes it so.
The concept of restricted visibility is relatively new to Objective-C and its
lack has been something that has put me off using the language sooner.
Yes, there will be ivars in the controller class that need to be visible in the
NIB file but the controller may also require other ivars which the designer of
the controller doesn't want to be visible in the NIB.
Although you can setup your controller class from within IB, you are only
really meant to setup outlets and actions that you require to see from the
controller class. You could just as easily setup actions and outlets in Xcode
and use IB to connect to them, which, coming from a more strictly regulated
language, is what I choose to do.
In fact, the latest docs recommend that IBOutlet is now applied to declared
properties, with a private backing ivar, instead of the old way of hooking up
directly to the ivar.
Pre-Objective-C 2.0
@interface MyClass : NSObject
{
id delegate;
IBOutlet NSWindow *window;
}
///
Objective-C 2.0
@interface MyClass : NSObject
{
@private
id delegate;
NSWindow *window;
}
@property (nonatomic, retain) IBOutlet NSWindow *window;
- (id) initWithDelegate:(id)delegate;
@end
@implementation MyClass
@synthesize window;
- (id) initWithDelegate:(id)del;
{
if (self = [super init])
{
delegate = del;
}
return self;
}
- (void) dealloc
{
[window release];
[super dealloc];
}
@end
///
Yes, it may be more code, but it allows developers, used to the enforcement of
visibility in classes, to create a controller that can be instantiated, in
code, with a constructor that takes a parameter of an object that we do not
want the NIB to see or use. In this example, the Objective-C 2.0 version should
allow me to hide the delegate because I don't want anyone accidentally
assigning over it in IB.
Joanna
--
Joanna Carter
Carter Consulting
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Private ivars, not marked as IBOutlet, visible in IB
Hi Paul Le 13 mars 2010 à 12:12, Paul Sanders a écrit : Try: #define PRIVATE_ID id ... PRIVATE_ID myPrivateiVar; Hmmm, messy. I much prefer the developer tools to respect the visibility specifier. :-) Joanna -- Joanna Carter Carter Consulting ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Private ivars, not marked as IBOutlet, visible in IB
Hi Roland Le 13 mars 2010 à 12:13, Roland King a écrit : I don't know if Joanna was suggesting you couldn't make anything available to IB by making it an IBOutlet, I took it that she was saying the old 'compatibility mode' of having any variable of type 'id', even if not an IBOutlet, be visible in IB would not be broken if you restricted it to those variables of type id which were not @private, because @private post-dates any code which should be depending on that old hack. Absolutely my point. There is no problem of backwards compatibility because the two technologies do not clash. I sort of agree, but I also sort of don't have this issue, never had a variable of type id in my class. If I did, I'd probably make it NSObject* and .. does that make it stop? My reason for using id is because I want to hold a delegate and call methods on it without compiler warnings. Or have I got the wrong idea there? Joanna -- Joanna Carter Carter Consulting ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
NSTimer never being deallocated
Hey Devs, I've always been having problems with Foundation's NSTimer Class when it comes to Memory-Management. After activating the static analyzer in Xcode (very useful!), it immediately reminds me of autoreleasing my instance of NSTimer and I thought like why is the NSTimer never being deallocated?? OKay so I created a demo NSTimer memory app and started testing with Instruments (Object Allocations Tool). In my opinion, there's a serious memory leak here since it's impossible to release an NSCFTimer. If I create it like that (should be actually autoreleased if repeat is set to NO and must be released manually or by calling - invalidate if repeat is set to YES): [NSTimer scheduledTimerWithTimeInterval:0.1 target:self selector:@selector(fire:) userInfo:nil repeats:YES]; I sent an -invalidate to my instance of NSTimer in -fire: but Instruments told me the object was still alive. This is really confusing, I think the instance should be released when sending an invalidate so mem-management is clean and fine as it is in every other Apple ObjC class. Since that didn't work I added a -release after invalidating the timer. This results in an EXC_BAD_ACESS (Invalid address) although its retain count was 1. I guess there's something else going wrong inside the NSTimer. Unfortunately, the Apple NSTimer docs don't say anything about mem managment (nothing in discussion or sth like that)… That's why I tried allocating the timer with alloc/init this way: [[[NSTimer alloc] initWithFireDate:[NSDate date] interval:0.1 target:self selector:@selector(fire:) userInfo:nil repeats:YES] autorelease]; After adding it to the current run-loop and invalidating it in -fire: it still remained in memory. Forcing an deallocation with an extra release (Note: this is just wrong since I never retained it without doing a release afterwards!) it crashed again with an invalid address. What am I doing wrong? There really should be a way to deallocate an instance of NSTimer, I guess. Thanks, guys! Best regards, Tobias Jordan.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Private ivars, not marked as IBOutlet, visible in IB
Am 13.03.2010 um 16:25 schrieb Joanna Carter: My reason for using id is because I want to hold a delegate and call methods on it without compiler warnings. Or have I got the wrong idea there? Yes your idea is wrong. You are free to specify NSObject YourProtocol *delegate; atze ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTimer never being deallocated
I sent an -invalidate to my instance of NSTimer in -fire: but Instruments told me the object was still alive. This is really confusing, I think the instance should be released when sending an invalidate so mem-management is clean and fine as it is in every other Apple ObjC class. This is just some optimization in the internal Cocoa implementation. I recently found out that Cocoa just reuses NSTimer instances: If you create an NSTimer object with scheduledTimerWithTimeInterval and then are done with it and your releases are just fine, the NSTimer instance may NOT get freed. But if you get another NSTimer instance with scheduledTimerWithTimeInterval, you'll find out that you often get the same NSTimer instance again. Cocoa is just caching NSTimer instances internally for re-use. But all this is just implementation detail that you don't have to worry about. Just make sure to follow the memory guidelines and all is fine. Sending an additional release is wrong and will crash, of course. Regards, Mani -- http://mani.de - friendly software iVolume - listen to music hands-free LittleSecrets - the encrypted notepad Sahara - sand in your pocket Watchdog - baffle the curious ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Private ivars, not marked as IBOutlet, visible in IB
Hi Alexander Yes your idea is wrong. You are free to specify NSObject YourProtocol *delegate; Great. I've learnt so much but there is still so much more to learn :-) Joanna -- Joanna Carter Carter Consulting ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Which iPhone Program?
On 13 Mar 2010, at 11:59, Alexander Spohr wrote: This is not really a Cocoa question... - If you want your application in the store you need Company. This is not true, I currently have two applications in the store, and do not have a company account. The important difference is that if you have a VAT number you must select company to reclaim tax. If you do not have a VAT number through not being a company, you must select personal. Bob ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Setting cursor for subview of NSTextView
Martin Wierschin mar...@nisus.com wrote: I have a custom NSTextAttachmentCell that does its work by adding subviews to the NSTextView (e.g. NSButtons). This works fine. What I can't get to work is cursor handling; I always get an arrow cursor when the mouse is over my views. I overwrite resetCursorRects, like this: ... This doesn't help. Getting desperate, I tried implementing mouseMoved:, but it's not even called Overriding mouseMoved is unfortunately required if you want to customize the mouse cursor in NSTextView (see this post by the helpful Mr Davidson). What I missed was that in order to receive mouseMoved events, you need to set a tracking area first; I had assumed that mouseMoved: is automatically called for the deepest view under the mouse that implements it. (Reading the docs can help at times...) After overriding updateTrackingAreas in my subview and installing a suitable NSTrackingArea, things work in most situations; I then still had to override mouseMoved: in the NSTextView though, and keep it from calling super if the subview had set the cursor, otherwise the cursor would still be reset to an arrow in certain cases. Thanks for the help (also to Douglas, who sent me private mail). -Stefan -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Which iPhone Program?
Am 13.03.2010 um 17:03 schrieb Thomas Davie: On 13 Mar 2010, at 11:59, Alexander Spohr wrote: This is not really a Cocoa question... - If you want your application in the store you need Company. This is not true, I currently have two applications in the store, and do not have a company account. The question here was if he needs company or enterprise. Private was out of the question. atze ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTimer never being deallocated
Hi Mani, Thanks a lot, sounds good although I am not really happy with the fact that Apple doesn't mention it somewhere. I know a lot of developers who don't care about Instruments and memory leaks'n'stuff that's why their software will be always buggy. I want to know what's going on inside my app and I've got enough experience in coding to know that just trusting the Apple docs (especially when it's about memory management) is not reliable. Best regards, Tobias Jordan. On Mar 13, 2010, at 4:56 PM, Manfred Schwind wrote: I sent an -invalidate to my instance of NSTimer in -fire: but Instruments told me the object was still alive. This is really confusing, I think the instance should be released when sending an invalidate so mem-management is clean and fine as it is in every other Apple ObjC class. This is just some optimization in the internal Cocoa implementation. I recently found out that Cocoa just reuses NSTimer instances: If you create an NSTimer object with scheduledTimerWithTimeInterval and then are done with it and your releases are just fine, the NSTimer instance may NOT get freed. But if you get another NSTimer instance with scheduledTimerWithTimeInterval, you'll find out that you often get the same NSTimer instance again. Cocoa is just caching NSTimer instances internally for re-use. But all this is just implementation detail that you don't have to worry about. Just make sure to follow the memory guidelines and all is fine. Sending an additional release is wrong and will crash, of course. Regards, Mani -- http://mani.de - friendly software iVolume - listen to music hands-free LittleSecrets - the encrypted notepad Sahara - sand in your pocket Watchdog - baffle the curious ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTimer never being deallocated
Am 13.03.2010 um 17:41 schrieb Tobias Jordan: I want to know what's going on inside my app and I've got enough experience in coding to know that just trusting the Apple docs (especially when it's about memory management) is not reliable. Please explain this. If you stick to the memory rules you’re fine. atze ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTimer never being deallocated
Please explain this. If you stick to the memory rules you’re fine. Recycled objects can appear as leaks, making it hard to distinguish between a bug and normal behavior. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTimer never being deallocated
On 13 mar 2010, at 08.57, Dave Keck wrote: Recycled objects can appear as leaks, making it hard to distinguish between a bug and normal behavior. I don't think that's true (it doesn't fit with the algorithm used for identifying leaks), but if it is, please file a bug report: http://developer.apple.com/bugreporter/ j o a r ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTimer never being deallocated
Yes, don't get me wrong, I trust the Apple docs, of course but I also know it's possible they are doing something wrong. I don't remember all cases but it always starts like this: I see something's not being freed, I try to free it, it doesn't work, I do a search on it and notice there are a lot of other developers saying this is an Apple bug and sending a bug report. One example is the IKImageBrowserNSImageRepresentationType used for the IKImageBrowserView. No one knows whether it's some kind of a very clever caching but for now it is not possible to completely remove the image of an NSImage-browserItem within an IKImageBrowserView. What that means is -- I load like 100 images into my browser view, remove them, add another 200, remove them and the memory says 500 MBs or more. And that's nothing you can say 'Oh, don't worry it's all ok' about since my app's crashed this way. ;-) I guess, the reasons all other IKImageBrowserViews used in public 3rd party apps are working are a) the few images are too small for being a problem or b) the IKImageBrowserPathRepresentationType has been used which does the releasing very well. But that's just one example, I mean no ones perfect that's why I make sure on my own that everything's fine. I've had a few classes in the past not behaving properly and being fixed in the next OS (Tiger to Leopard, Leopard to Snow Leopard…). Best regards, Tobias Jordan. On Mar 13, 2010, at 5:52 PM, Alexander Spohr wrote: Am 13.03.2010 um 17:41 schrieb Tobias Jordan: I want to know what's going on inside my app and I've got enough experience in coding to know that just trusting the Apple docs (especially when it's about memory management) is not reliable. Please explain this. If you stick to the memory rules you’re fine. atze ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Which iPhone Program?
On 13 Mar 2010, at 16:41, Alexander Spohr wrote: Am 13.03.2010 um 17:03 schrieb Thomas Davie: On 13 Mar 2010, at 11:59, Alexander Spohr wrote: This is not really a Cocoa question... - If you want your application in the store you need Company. This is not true, I currently have two applications in the store, and do not have a company account. The question here was if he needs company or enterprise. Private was out of the question. That doesn't make the statement any more true. Bob___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Private ivars, not marked as IBOutlet, visible in IB
On Sat, Mar 13, 2010 at 7:20 AM, Joanna Carter cocoa...@carterconsulting.org.uk wrote: If my class is files owner the whole nib is owned by it - hence the name. Therefore I absolutely want IB to be able to set even the private ivars. The nib is just another way of setting up my class’ objects. If I may say so, to say this is to misunderstand object oriented design. Actually this is how nibs were designed and intended to be used: to be fragments of the object graph loaded at runtime. It is a *very* recent trend to have them exist so independently of File's Owner, and to use the public API to hook up their connections. --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: NSTimer never being deallocated
On 13 mar 2010, at 07.36, Tobias Jordan wrote: I've always been having problems with Foundation's NSTimer Class when it comes to Memory-Management. After activating the static analyzer in Xcode (very useful!), it immediately reminds me of autoreleasing my instance of NSTimer and I thought like why is the NSTimer never being deallocated?? OKay so I created a demo NSTimer memory app and started testing with Instruments (Object Allocations Tool). In my opinion, there's a serious memory leak here since it's impossible to release an NSCFTimer. If I create it like that (should be actually autoreleased if repeat is set to NO and must be released manually or by calling -invalidate if repeat is set to YES): [NSTimer scheduledTimerWithTimeInterval:0.1 target:self selector:@selector(fire:) userInfo:nil repeats:YES]; I sent an -invalidate to my instance of NSTimer in -fire: but Instruments told me the object was still alive. This is really confusing, I think the instance should be released when sending an invalidate so mem-management is clean and fine as it is in every other Apple ObjC class. Memory management in a shared ownership system, like the reference counted system used in Cocoa, doesn't allow you to draw that kind of conclusion. The assumption that an object would get deallocated immediately as soon as you have balanced your memory management calls can be true in specific cases, but not in general - In particular when dealing with classes that you don't own, and when dealing with shared objects. I don't know of any memory leaks in the NSTimer class, or in Cocoa in general when it comes with the dealing with timers. If you can reproduce something that you suspect being a problem with Cocoa, please either post some sample code, or file a bug report: http://developer.apple.com/bugreporter/ Since that didn't work I added a -release after invalidating the timer. This results in an EXC_BAD_ACESS (Invalid address) although its retain count was 1. I guess there's something else going wrong inside the NSTimer. With all respect, if you thought that would be an OK solution, then I think that you should go back and review the memory management documentation. Unfortunately, the Apple NSTimer docs don't say anything about mem managment (nothing in discussion or sth like that)… The API reference documentation calls out exceptions, not things that just follow the general memory management rules. That said, there are two things about timers that you need to know and understand, but they are both called out in the documentation: Note in particular that run loops retain their timers The target object is retained by the timer and released when the timer is invalidated In addition, there's a separate programming topic on timers in the conceptual documentation: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Timers/Articles/usingTimers.html#//apple_ref/doc/uid/2807 ...and at the end of that page they also explicitly calls out memory management aspects to keep in mind. j o a r ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
death in dealloc
I have some code that is throwing EXC_BAD_ACCESS. It does so when an object is deallocating, in its -dealloc method on a call to [super dealloc]. The object's class's superclass is NSObject. Here's the (relevant part of the) stack trace: #0 0x7fff872e016d in _class_hasCxxStructorsNoSuper #1 0x7fff872e0741 in object_cxxDestructFromClass #2 0x7fff872e60f8 in objc_destructInstance #3 0x7fff872e06f5 in _internal_object_dispose #4 0x7fff83e0279a in -[NSObject(NSObject) dealloc] #5 0x10007b18e in -[ZPOauthParams dealloc] at ZPOauthParams.m:57 I know I must have blown something, but I have no idea what I could have done to cause this sort of problem. If anyone has seen something like this before, please let me in what direction I should look for the problem. TIA. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Private ivars, not marked as IBOutlet, visible in IB
Hi Kyle Actually this is how nibs were designed and intended to be used: to be fragments of the object graph loaded at runtime. It is a *very* recent trend to have them exist so independently of File's Owner, and to use the public API to hook up their connections. So I gather. Which was one of the main reasons I avoided Mac development because, until recently (Objective-C 2.0 ?), I was not at all comfortable with that way of working when compared with a much stricter interpretation of the MVC design pattern. I am now very comfortable with Xcode and IB and am really enjoying putting my OO design expertise to work writing code for a decent OS rather than for (sshh, you know who :-) ) Joanna -- Joanna Carter Carter Consulting ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: incorrect bitmap date from NSBitmapImageRep from NSDate
Hi Ken, the problem was solved by checking bitsPerPixel and changed the pixel format to GL_RGB, GL_UNSIGNED_BYTE but, if the best combination of format / type is GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV so does it means we need to convert RGB / RGBA to BGRA? sorry for posting in cocoa list 2010/3/13 Ken Ferry kenfe...@gmail.com Hi, Please go down to the phrase apps are rather fond of hardcoding bitmap formats in the AppKit release notes. http://developer.apple.com/mac/library/releasenotes/cocoa/appkit.html If the latter I suspect that your file is not in the needed format. Does your image have alpha? format is bmp The file format is bmp, but there's also a pixel format, which is the layout of the uncompressed bytes in memory. It is necessary to convert the data to the pixel format that you're telling GL the data is in. You said GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV. The version you have involving NSImage is not safe either, it just happens to work today. -ken On Fri, Mar 12, 2010 at 10:03 AM, Ariel Feinerman arielfap...@gmail.comwrote: 2010/3/12 Alexander Spohr a...@freeport.de Exactly what does not work? The loading? Or the opengl command? texture is corrupted with artifact on the screen and sometimes gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGBA, [image pixelsWide], [image pixelsHigh], GL_RGBA, GL_UNSIGNED_INT_8_8_8_8_REV, [image bitmapData]); take an exception If the latter I suspect that your file is not in the needed format. Does your image have alpha? format is bmp there is of the matter is that messages -initWithCIImage and -initWithFocusedViewRect read bitmap date from offscreen window so image is rendered twice, isn`t it? reference The image in the *ciImage* parameter must be fully rendered before the receiver can be initialized. If you specify an object whose rendering was deferred (and thus does not have any pixels available now), this method forces the image to be rendered immediately. Rendering the image could result in a performance penalty if the image has a complex rendering chain or accelerated rendering hardware is not available. Is the way to get NSBitmapImageRep for OpenGL without offscreen rendering image? atze Am 12.03.2010 um 13:09 schrieb Ariel Feinerman: // not work NSData *data = [NSData dataWithContentsOfFile: filename]; NSBitmapImageRep *image = [[NSBitmapImageRep alloc] initWithData: data]; as opposed to: // works fine NSImage *source = [[NSImage alloc] initWithContentsOfFile: filename]; NSSize size = [source size]; [source lockFocus]; NSBitmapImageRep *image = [[NSBitmapImageRep alloc] initWithFocusedViewRect: NSMakeRect(0.0, 0.0, size.width, size.height)]; [source unlockFocus]; // OpenGL commands gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGBA, [image pixelsWide], [image pixelsHigh], GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, [image bitmapData]); why? as opposed to ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/atze%40freeport.de This email sent to a...@freeport.de -- best regards Ariel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com This email sent to kenfe...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Private ivars, not marked as IBOutlet, visible in IB
Not necessarily true. While you are free to specify a delegate as NSObject YourProtocol, it is not standard convention. The convention for delegates is: idYourProtocol. Kevin On 13 Mar 2010, at 07:39, Alexander Spohr wrote: Am 13.03.2010 um 16:25 schrieb Joanna Carter: My reason for using id is because I want to hold a delegate and call methods on it without compiler warnings. Or have I got the wrong idea there? Yes your idea is wrong. You are free to specify NSObject YourProtocol *delegate; atze ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/cathey%40apple.com This email sent to cat...@apple.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: NSTimer never being deallocated
On 13 mar 2010, at 09.08, Tobias Jordan wrote: Yes, don't get me wrong, I trust the Apple docs, of course but I also know it's possible they are doing something wrong. I don't remember all cases but it always starts like this: I see something's not being freed, I try to free it, it doesn't work, I do a search on it and notice there are a lot of other developers saying this is an Apple bug and sending a bug report. While it's impossible to completely rule out problems in Cocoa, it is as a general rule not productive to start out by assuming that a discovered problem should be caused by a problem in Cocoa. The Cocoa frameworks receive so much testing, and have so many clients, that it is far more likely that any issues are to be found in your own software. That said, if you identify a bug in Cocoa, or its documentation, we very much welcome your bug reports: http://developer.apple.com/bugreporter/ It is great that you're looking at your software product in Instruments to make sure that it behaves correctly and as expected - More people should do that! Keep in mind though, and considering the attempts at fixing found problems that you mentioned at the beginning of this thread, that you can't propose solutions that doesn't comply with the general memory management guidelines (for example, you can't add extra calls to -release simply because you find an object that you expected to have been deallocated). One example is the IKImageBrowserNSImageRepresentationType used for the IKImageBrowserView. No one knows whether it's some kind of a very clever caching but for now it is not possible to completely remove the image of an NSImage-browserItem within an IKImageBrowserView. What that means is -- I load like 100 images into my browser view, remove them, add another 200, remove them and the memory says 500 MBs or more. And that's nothing you can say 'Oh, don't worry it's all ok' about since my app's crashed this way. ;-) I guess, the reasons all other IKImageBrowserViews used in public 3rd party apps are working are a) the few images are too small for being a problem or b) the IKImageBrowserPathRepresentationType has been used which does the releasing very well. Have you filed a bug report on this issue? j o a r ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Private ivars, not marked as IBOutlet, visible in IB
You are right, id YourProtocol is the standard. But the question was how to get a delegate that is not visible in IB and does not produce compiler warnings. atze Am 13.03.2010 um 18:55 schrieb Kevin Cathey: Not necessarily true. While you are free to specify a delegate as NSObject YourProtocol, it is not standard convention. The convention for delegates is: idYourProtocol. Kevin On 13 Mar 2010, at 07:39, Alexander Spohr wrote: Am 13.03.2010 um 16:25 schrieb Joanna Carter: My reason for using id is because I want to hold a delegate and call methods on it without compiler warnings. Or have I got the wrong idea there? Yes your idea is wrong. You are free to specify NSObject YourProtocol *delegate; atze ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/cathey%40apple.com This email sent to cat...@apple.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: NSTimer never being deallocated
Recycled objects can appear as leaks, making it hard to distinguish between a bug and normal behavior. I don't think that's true (it doesn't fit with the algorithm used for identifying leaks), but if it is, please file a bug report: I didn't mean to imply the Leaks instrument. Using the ObjectAlloc instrument to find rooted leaks, for example, and seeing a steady increase of NSNumber and NSString objects leads one to believe there's a leak, when in fact the objects are just being cached. Of course I don't think anyone would consider this a bug - just something that needs to be kept in mind. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Private ivars, not marked as IBOutlet, visible in IB
Am 13.03.2010 um 18:54 schrieb Joanna Carter: Actually this is how nibs were designed and intended to be used: to be fragments of the object graph loaded at runtime. It is a *very* recent trend to have them exist so independently of File's Owner, and to use the public API to hook up their connections. So I gather. Which was one of the main reasons I avoided Mac development because, until recently (Objective-C 2.0 ?), I was not at all comfortable with that way of working when compared with a much stricter interpretation of the MVC design pattern. To quote yourself: If I may say so, to say this is to misunderstand MVC design. MVC has nothing to do with private ivars. Cocoa is one of the cleanest MVC implementations - since 1989. atze ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTimer never being deallocated
For the benefit of the OP, according to the docs (and this fits in with my own experience), calling [NSTimer invalidate] will release the timer at some future point in the run loop and is in fact the only way to get rid of it. So there is really nothing to worrry about. Trust in Papa Cocoa, all will be well. Paul Sanders. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTimer never being deallocated
Hi Joar, Thanks a lot for taking the time to respond to this request! Let me explain what made me write to this cocoa list and think NSTimer's got a memory leak: When reading through all the class documentations from Apple I often see some notes in the discussion group that say something like: 'Returns an autoreleased object … ' or the opposite so I know whether I have to take care of releasing the object or not. I like and understand the reference counting system. I guess it means when sending a retain I tell the object: Hey, I need you, don't go away until I tell you to do. That's why one class can always send only one retain or one release. So it is quite clear that it's more than not okay to send a double retain or release. ;-) I did this while experimenting with the NSTimer class to find out how it's working. I sent a double-release to see if there's really one release somwhere else missing and I was actually really confused about the crash. After getting the solution -- that it's just some caching -- it has been eye opening for me, this explains NSTimers behavior. What made me think it is a bug was actually only the fact that instruments told me the object is always still alive and the 'missing' note in the documentations that tell me I don't need to release it because of some caching techniques. I guess you're right, I was just thinking too quickly, most users don't do these tests in Instruments, they rely on what's written in the docs :-), I don't see any bugs in NSTimer anymore. Have you filed a bug report on this issue? Not me but I am pretty sure a friend of mine did. The assumption that an object would get deallocated immediately as soon as you have balanced your memory management calls can be true in specific cases, but not in general - In particular when dealing with classes that you don't own, and when dealing with shared objects. No no, I don't assume that all objects are getting deallocated immediately provided that its caching or whatever system is really helpful and makes sense. In IKImageBrowserView's case it's just filling up my whole RAM and then crashed because of missing memory, that's what I simply don't want. :-( So I guess it is really the missing 'NSTimer is caching its instances' line that confused me so sorry about that and thanks for your help! Best regards, Tobias Jordan. On Mar 13, 2010, at 6:55 PM, Joar Wingfors wrote: On 13 mar 2010, at 09.08, Tobias Jordan wrote: Yes, don't get me wrong, I trust the Apple docs, of course but I also know it's possible they are doing something wrong. I don't remember all cases but it always starts like this: I see something's not being freed, I try to free it, it doesn't work, I do a search on it and notice there are a lot of other developers saying this is an Apple bug and sending a bug report. While it's impossible to completely rule out problems in Cocoa, it is as a general rule not productive to start out by assuming that a discovered problem should be caused by a problem in Cocoa. The Cocoa frameworks receive so much testing, and have so many clients, that it is far more likely that any issues are to be found in your own software. That said, if you identify a bug in Cocoa, or its documentation, we very much welcome your bug reports: http://developer.apple.com/bugreporter/ It is great that you're looking at your software product in Instruments to make sure that it behaves correctly and as expected - More people should do that! Keep in mind though, and considering the attempts at fixing found problems that you mentioned at the beginning of this thread, that you can't propose solutions that doesn't comply with the general memory management guidelines (for example, you can't add extra calls to -release simply because you find an object that you expected to have been deallocated). One example is the IKImageBrowserNSImageRepresentationType used for the IKImageBrowserView. No one knows whether it's some kind of a very clever caching but for now it is not possible to completely remove the image of an NSImage-browserItem within an IKImageBrowserView. What that means is -- I load like 100 images into my browser view, remove them, add another 200, remove them and the memory says 500 MBs or more. And that's nothing you can say 'Oh, don't worry it's all ok' about since my app's crashed this way. ;-) I guess, the reasons all other IKImageBrowserViews used in public 3rd party apps are working are a) the few images are too small for being a problem or b) the IKImageBrowserPathRepresentationType has been used which does the releasing very well. Have you filed a bug report on this issue? j o a r ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at
-[QCNSBitmapImageRep encodeWithCoder:]: Inconsistent state
I am running into a weird error and I don't know why it's happening. I
am adding an image that comes from a Quartz Composer composition to a
dictionary. The dictionary is archived, and when that happens I see
the following message in the console:
-[QCNSBitmapImageRep encodeWithCoder:]: Inconsistent state
The image description looks like this:
NSImage 0x255d0630 Size={604, 539} Reps=(
QCNSBitmapImageRep 0x246f4520
Size={604, 539}
ColorSpace=NSCalibratedRGBColorSpace
BPS=8
BPP=32
Pixels=604x539
Alpha=YES
Planar=NO
Format=1
)
As a workaround I'm making a copy of the image, which generates a
NSCachedImageRep, and the dictionary (and image) archives with no
problem. I'm just wondering what's going on and if I have to live with
making an image copy or if I'm otherwise doing something wrong. BTW,
this is on 10.5.8.
steve
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: NSTimer never being deallocated
I haven't followed this whole thread, but my experience is that an NSTimer (especially a repetitive one) is an easy thing to leak, even in a GC environment (which I use). To prevent it, you have to make sure you keep a reference to the timer so that you can actually invalidate it, taking it out of the run loop. Otherwise, it stays there forever. On 3/13/10 2:02 PM, cocoa-dev-requ...@lists.apple.com cocoa-dev-requ...@lists.apple.com wrote: For the benefit of the OP, according to the docs (and this fits in with my own experience), calling [NSTimer invalidate] will release the timer at some future point in the run loop and is in fact the only way to get rid of it. So there is really nothing to worrry about. Trust in Papa Cocoa, all will be well. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTimer never being deallocated
I don't understand all the confusion on this issue. The NSTimer documentation makes the life-cycle of this object very clear. Until it goes away, it is probably retained by the runloop. As Joar says, you often can't make any concrete predictions about when an object you don't manage yourself might be released for the last time, but if you put a breakpoint on [NSTimer dealloc] you will be able to see it when it happens. Paul Sanders. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: death in dealloc
This is almost always caused by releasing an object earlier than you expected to, and then trying to release it again later (similar to double free). Look around in your class's code for a place where you autorelease an ivar, but don't add it to a collection, or where you release an ivar but don't set it to nil afterwards. -Steven On Sat, Mar 13, 2010 at 12:53 PM, Stuart Malin stu...@zhameesha.com wrote: I have some code that is throwing EXC_BAD_ACCESS. It does so when an object is deallocating, in its -dealloc method on a call to [super dealloc]. The object's class's superclass is NSObject. Here's the (relevant part of the) stack trace: #0 0x7fff872e016d in _class_hasCxxStructorsNoSuper #1 0x7fff872e0741 in object_cxxDestructFromClass #2 0x7fff872e60f8 in objc_destructInstance #3 0x7fff872e06f5 in _internal_object_dispose #4 0x7fff83e0279a in -[NSObject(NSObject) dealloc] #5 0x10007b18e in -[ZPOauthParams dealloc] at ZPOauthParams.m:57 I know I must have blown something, but I have no idea what I could have done to cause this sort of problem. If anyone has seen something like this before, please let me in what direction I should look for the problem. TIA. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/steven.degutis%40gmail.com This email sent to steven.degu...@gmail.com -- Steven Degutis http://www.thoughtfultree.com/ http://www.degutis.org/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTimer never being deallocated
Hi Paul, You said 'an object you don't manage' -- If I alloc/init an instance of NSTimer I am responsible for this object, in my opinion. That's why I tried to do everything properly. You see I am actually really just trying to prevent memory leaks and I see lots of leaks in sample code I am downloading somewhere. That's the reason I am so careful. Let's just close the topic here, I thank everyone for the explanations, I appreciate all of them! Best regards, Tobias Jordan. On Mar 13, 2010, at 9:53 PM, Paul Sanders wrote: I don't understand all the confusion on this issue. The NSTimer documentation makes the life-cycle of this object very clear. Until it goes away, it is probably retained by the runloop. As Joar says, you often can't make any concrete predictions about when an object you don't manage yourself might be released for the last time, but if you put a breakpoint on [NSTimer dealloc] you will be able to see it when it happens. Paul Sanders. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
Best approach for a bunch of new UI controls
Hi guys, I've got a few *nix libs to flesh out with some Cocoa UI goodness and would welcome suggestions for a good way to do a bunch of controls: Control 1: A long colour bar with a sliding window over it (mouse controls the position of the window) - ++ |]|[||]|[||| ++ Control 2: A scrollable view of square boxes that can be picked and dragged out of the view either individually or as a group - +-- ---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | | +-+ +-+ +-+ +-+ ... +-+ +-+ +-+ +-+ | | | . : | | | +-+ +-+ +-+ +-+ ... +-+ +-+ +-+ +-+ | | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +-- ---+ Control 3: similar to control 2, but on a single line and can accept boxes dragged out of control 2 (or itself) highlighting the insertion point - \ / +-+ | +-+ +-+ +-+ | +-+ +-+ / \ Ideas/thoughts/suggestions are very welcome! Cheers, -- Igor ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
How to show a progress without multithreading?
Hi, All, I have a time-consuming procedure, and I'd like to show its progress. I can't use multi-threading for some technical reason. I'm looking for a way to update a progress indicator from this procedure, As far as I understand my task is to cause message loop processing. And my question is - how to do it? Thanks. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to show a progress without multithreading?
On Mar 13, 2010, at 8:33 PM, Alexander Bokovikov wrote: Hi, All, I have a time-consuming procedure, and I'd like to show its progress. I can't use multi-threading for some technical reason. I'm looking for a way to update a progress indicator from this procedure, As far as I understand my task is to cause message loop processing. And my question is - how to do it? Thanks. Are you getting periodic callbacks from the main runloop [say, by using an NSTimer], or just doing processing on the main thread without getting events [ie, so you get the spinning cursor of doom after a few seconds]? Eli ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
function cannot change buttons behavior
Hi all,
I have two functions increase and decrease which control the number of sides of
a polygon. I want to call a - (void)function that disables the buttons if the
current number of sides are equal to the maximum number of sides.
1) One problem is that button.enabled=YES/NO does not get called. If I put
this line into the decrease/increase function it works fine. But I don't want
to copy-paste the code, so I thought I can put this into my updateInterface
function.
2) Another problem is that somehow the function cannot change the ivars
values.. Again, if I put the code in the increase, decrease functions I have no
problems.
3) And lastly I'm not sure if I'm doing it correctly. As updateInterface is a
method declared in my controller class, polygon cannot call it. I use an
Controller object to invoke the updateInterface function. Due to the fact
that the function must change some ivars, I cannot use a class function... I
think it could be the reason why it doesn't work the way it should, but at this
point I don't see why...
I hope you can help me understand the issue here. I'm new to mac programming.
CODE:
- (void)awakeFromNib{
cont = [[Controller alloc] init];
polygon = [[PolygonShape alloc] initWithNumberOfSides:5
minimumNumberOfSides:3 maximumNumberOfSides:12];
numberOfSidesLabel.text=[NSString stringWithFormat:@%d %d
%d,polygon.numberOfSides, polygon.minimumNumberOfSides,
polygon.maximumNumberOfSides];
polygonAngle.text=[NSString stringWithFormat:@%f %f,
polygon.angleInDegrees, polygon.angleInRadians];
polygonName.text=[NSString stringWithFormat:@%@, polygon.name];
}
- (IBAction)decrease{
polygon.numberOfSides-=1;
[cont updateInterface:polygon];
}
- (IBAction)increase{
polygon.numberOfSides+=1;
[cont updateInterface:polygon];
}
- (void)updateInterface:(id)sender{
numberOfSidesLabel.text=[NSString stringWithFormat:@%d %d
%d,polygon.numberOfSides, polygon.minimumNumberOfSides,
polygon.maximumNumberOfSides];
polygonAngle.text=[NSString stringWithFormat:@%f %f,
polygon.angleInDegrees, polygon.angleInRadians];
polygonName.text=[NSString stringWithFormat:@%@, polygon.name];
if ([sender numberOfSides]==[sender maximumNumberOfSides]) {
[increaseButton setEnabled:NO];
increaseButton.enabled=NO;
}else if ([sender numberOfSides]==[sender minimumNumberOfSides]) {
decreaseButton.enabled=NO;
}else {
increaseButton.enabled=YES;
decreaseButton.enabled=YES;
}
}
THANKS A LOT!
-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
Re: How to show a progress without multithreading?
On Mar 13, 2010, at 19:33, Alexander Bokovikov wrote: I have a time-consuming procedure, and I'd like to show its progress. I can't use multi-threading for some technical reason. I'm looking for a way to update a progress indicator from this procedure, As far as I understand my task is to cause message loop processing. And my question is - how to do it? It's fairly straightforward -- repeatedly invoke a method that does the following: NSEvent *event; while ((event = [NSApp nextEventMatchingMask: NSAnyEventMask untilDate: nil inMode: NSEventTrackingRunLoopMode dequeue: YES])) [NSApp sendEvent: event]; Make sure this is called often enough for responsiveness (say, at least every 0.1 secs), but not too often to interfere with performance. You might want to choose a different run loop mode, if you have special requirements. NSEventTrackingRunLoopMode is sufficient to allow keystrokes and mouse clicks to be processed, so that you can have a UI (say, Esc key or button) to cancel the procedure if you want. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to show a progress without multithreading?
On Mar 13, 2010, at 10:23 PM, Quincey Morris wrote: On Mar 13, 2010, at 19:33, Alexander Bokovikov wrote: I have a time-consuming procedure, and I'd like to show its progress. I can't use multi-threading for some technical reason. I'm looking for a way to update a progress indicator from this procedure, As far as I understand my task is to cause message loop processing. And my question is - how to do it? It's fairly straightforward -- repeatedly invoke a method that does the following: NSEvent *event; while ((event = [NSApp nextEventMatchingMask: NSAnyEventMask untilDate: nil inMode: NSEventTrackingRunLoopMode dequeue: YES])) [NSApp sendEvent: event]; Make sure this is called often enough for responsiveness (say, at least every 0.1 secs), but not too often to interfere with performance. You might want to choose a different run loop mode, if you have special requirements. NSEventTrackingRunLoopMode is sufficient to allow keystrokes and mouse clicks to be processed, so that you can have a UI (say, Esc key or button) to cancel the procedure if you want. You should also see if -beginModalSessionForWindow:/-runModalSession:/-endModalSession: makes sense for your situation. It does require that you can do the time-consuming task in discrete chunks. 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
#include CommonStrings.txt - 'no such file' error
Folks; I have a dozen or so strings that I use over and over in various classes. So here's what I've done I have a CommonStrings.txt file added to the project. It looks like this: NSString *gLeftBracket =@; NSString *gRightBracket =@; If I #include this file somewhere in the project then I can use 'extern' in the classes/methods where I need one of these strings. benefits: one place for definition type-ahead works - more efficient code construction costs: global-ness violates object-oriented principles committed global overhead for entire project that doesn't benefit every class however there are only ~20 of these there is no inherent 'read-only' support (which is what I would prefer) On the whole I'm inclined to accept the costs for the benefits! Is there a better way to achieve the goal in ObjC2? But here's my real question: It appears that I cannot put the one and only #include CommonStrings.txt just anywhere in the project. Some locations work fine others result in a 'CommonStrings.tx.' - no such file error. I'm just cutting and pasting the #include statement - so I'm not munging the statement. I cannot see any rhyme or reason on where it works and where it doesn't… Can someone clarify this for me? Kochan ObjC2 p209 clearly states, …variable must be defined someplace among your source files… Thanks for your time, Steve___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
