Questions about Nib Object Retention
Nib Object Retentionhttp://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/1051i-CH4-SW6 Mac OS X - managed memory model Objects in the nib file are initially created with a retain count of 1. As it rebuilds the object hierarchy, however, AppKit autoreleases any objects that have a parent or owning object, such as views nested inside view hierarchies. By the time the nib-loading code is done, only the top-level objects in the nib file have a positive retain count and no owning object. Your code is responsible for releasing these top-level objects. Here are my questions: Who owns the unarchived top-level objects' initial positive retain count? Are they retained for outlet connections? Or are they just not autoreleased only because they are top-level, regardless of whether there are any outlet connected to them? -- Hell boy is cool, but let me be healthy boy first. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Questions about Nib Object Retention
So, to be a good memory-wise citizen:1. If there is only one outlet to a top-level object from the nib owner, the outlet should have assign attribute, and the nib owner is now in fact the initial 1 retention(which seems reserved right for this predictable ownership)'s owner so is responsible for the releasing. Otherwise if the outlet uses retain logic, there will be a redundant retention to the top-level object so a memory leak. 2. If there are other outlets to a top-level object from other objects, they should use the retain logic to claim their share of ownership. 3. Outlets to non-top-level objects should always use the retain logic if they want to claim their ownership, since there are no reserved initial retain count for them. Am I getting it all right? On Wed, Oct 21, 2009 at 11:55 AM, Graham Cox graham@bigpond.com wrote: On 21/10/2009, at 2:40 PM, an0 wrote: Who owns the unarchived top-level objects' initial positive retain count? Nobody. That's what no owning object means. Are they retained for outlet connections? No, because if there is an outlet to them then they are owned. Or are they just not autoreleased only because they are top-level, regardless of whether there are any outlet connected to them? They are not autoreleased because that would presumably cause problems for the users of these objects, who don't own them either. If there's an outlet to them, they are owned by whoever declares the outlet. As it says, Your code is responsible for releasing these top-level objects. This is not the big issue it seems. Most nibs don't contain top level objects with no owners. For the very few that do, the objects most likely leak but typically that's no big deal unless you're loading the same nib repeatedly many times. --Graham -- Hell boy is cool, but let me be healthy boy first. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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 make NSURLConnection send delegate messages during runModalForWindow
Actually, I tried NSModalPanelRunLoopMode first, but it didn't work; and I was not sure whether NSModalPanelRunLoopMode is exactly the mode of model panel's run loop. Then I thought since the modal panel's delegate method windowDidBecomeKey is called during runModalForWindow, the currentRunLoop must be modal panel's run loop, and currentMode of it must be the mode in which I wanted my connection's delegate methods called. But it turned out that I still missed something here. On Tue, Dec 16, 2008 at 11:49 PM, Michael Babin mba...@orderndev.comwrote: On Dec 16, 2008, at 8:30 AM, an0...@gmail.com wrote: I want to handle the connection events during runModalForWindow, so I use [connection scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:[[NSRunLoop currentRunLoop] currentMode]]; in the modal window's windowDidBecomeKey delegate method. But still my connection's delegate methods are not called until stopModal. Is there anything I misunderstood about NSURLConnection's scheduleInRunLoop:forMode: method? Is there some reason not to pass in NSModalPanelRunLoopMode as the forMode argument? What happens if you do? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Why do all these methods of measuring string metrics with font attribute fail?
On Thu, Sep 4, 2008 at 11:33 AM, Peter Ammon [EMAIL PROTECTED] wrote: On Sep 3, 2008, at 6:01 AM, an0 wrote: I should declare up front that I know there are some arcane ways to measure string metrics using things like NSTextStorage, NSLayoutManager and the kin. Given the string and the font used to render it, it is reasonable there should be some straightforward way to tell the metrics of the string when laid out in one line. Actually, I thought I'd found several after reading through the docs; however, all of them turned out to be very miserable. Here goes what I've tried, with the effects in comments: Then what about boundingRectForFont? Why is it so large? NSFont *font = [NSFont labelFontOfSize:12]; // I put the string in a label NSRect fontRect = [font boundingRectForFont]; // too large This is measuring how much space it would take to render any single glyph. This isn't what you want for measuring text. NSRect glyphRect = [font boundingRectForGlyph:'W']; // too too small Glyphs are not the same thing as characters, and you cannot pass one in place of the other. The ASCII value of a character is not related to its glyph value. For example, the glyph corresponding to W would be 58 in the font you were using. Using 58 for 'W' seems to make no difference here, the resulting glyph height is still unreasonably small. (In fact, you should not think about glyph value of a character at all. Some characters have no glyphs, like space; sometimes multiple characters produce a single glyph, like an fi ligature.) In order to generate glyphs from characters, you should use the methods in NSLayoutManager. However, as you know, this is overkill for simple text measurements. IMO, the size of a string with font attribute is an intrinsic property determined only by the string and the font(and the layout of the string on the view, but here let's fix the layout to one single line); and the view used to render the attributed string should have a reasonalby bigger size to hold the whole string. In other words, one could have a good guess of the view size from the attributed string size. So, if my understanding of these two metrics is right, how can they differ so much? Was I using the wrong APIs? If my understanding is wrong, can you tell me what's the exact relationship between these two metrics? You were using the wrong APIs. To find the size of a string, use -[string sizeWithAttributes:]. To find the natural size of a control whose content is some string, use -[[textField cell] cellSize]. As you surmised, the control's natural size is often reasonably bigger than the content - but it may not be, if the control is fixed size (such as a circular button). So, it seems -[string sizeWithAttributes:] is the only API that gives a reasonable size of string. But I'm wondering what all the other APIs listed above are for. If they give no useful information for application programmers, why does Apple expose them to confuse us? If you just want a control to be big enough for its content, set the content on the control and then call -[control sizeToFit]. Hope this helps, -Peter ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Why do all these methods of measuring string metrics with font attribute fail?
I know the difference between string and font, and that between grapheme and glyph. However, I might miss the point that the size of the rendered string is not simply the sum the sizes of individual glyphs. There should be some extra space taken by spacing among and around glyphs. And some other more subtle typesetting details, also. Thanks for your hint, anyhow. On Thu, Sep 4, 2008 at 10:05 PM, Graham Cox [EMAIL PROTECTED] wrote: On 4 Sep 2008, at 11:27 pm, an0 wrote: If they give no useful information for application programmers, Yes they do, but perhaps just not for your application. If you want to use glyphs as a graphic element for example, it's sometimes useful to query these sizes without having to try laying them out as text. Remember, there is a big difference, conceptually, between a string (a collection of characters) and a font (a collection of glyphs). Glyphs are graphical entities, and most of the stuff in NSFont and NSFontManager is there to support these concepts at that level. Your problem (and confusion) appears to stem from the fact that you seem to think that a font is something like a string, and so can be treated as a collection of characters. The layout of glyphs to form an image of a string of text on the screen is a complex process, and applications that do this need to know all sorts of metrics beyond how much space does this string occupy. In fact to calculate that they need to add up the space occupied by each glyph, and some of the methods you mentioned are there to support that sort of processing. cheers, Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Why do all these methods of measuring string metrics with font attribute fail?
I should declare up front that I know there are some arcane ways to measure string metrics using things like NSTextStorage, NSLayoutManager and the kin. Given the string and the font used to render it, it is reasonable there should be some straightforward way to tell the metrics of the string when laid out in one line. Actually, I thought I'd found several after reading through the docs; however, all of them turned out to be very miserable. Here goes what I've tried, with the effects in comments: NSFont *font = [NSFont labelFontOfSize:12]; // I put the string in a label NSRect fontRect = [font boundingRectForFont]; // too large NSRect glyphRect = [font boundingRectForGlyph:'W']; // too too small NSLog(@fontRect: %f, %f, %f, %f\nglyphRect: %f, %f, %f, %f, fontRect.origin.x, fontRect.origin.y, fontRect.size.width, fontRect.size.height, glyphRect.origin.x, glyphRect.origin.y, glyphRect.size.width, glyphRect.size.height); NSTextField *label1 = [[[NSTextField alloc] init] autorelease]; [label1 setStringValue:@ABC]; [label1 setFrame:NSMakeRect(0, 0, fontRect.size.width * 3, fontRect.size.height)]; [[box contentView] addSubview:label1]; // box is an NSBox NSTextField *label2 = [[[NSTextField alloc] init] autorelease]; [label2 setStringValue:@ABC]; NSSize size = [@ABC sizeWithAttributes:[NSDictionary dictionaryWithObject:font forKey:NSFontAttributeName]]; // too small NSLog(@string size: %f, %f, size.width, size.height); [label2 setFrame:NSMakeRect(fontRect.size.width * 3, 0, size.width, size.height)]; [[box contentView] addSubview:label2]; So, can anyone tell me why all these fell through so badly, and what is the true straightforward way to do this if any? Thanks in advance. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
How to enable/disable buttons immediately after focus transfer
I know how to do this for NSValidatedUserInterfaceItem by implementing `- (BOOL)validateUserInterfaceItem:(id NSValidatedUserInterfaceItem )anItem'; however, NSSegmentedControl and NSButton do not conform to NSValidatedUserInterfaceItem protocol, then how can I switch the enable status of these controls as an IMMEDIATE response to the focus transfer? Thanks in advance. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Why can't I name a property `tag'?
It is just simple as you said. And it is cool just after I know what's on earthing happening there. Thanks a lot. On Fri, Jul 11, 2008 at 2:03 AM, Bill Bumgarner [EMAIL PROTECTED] wrote: On Jul 10, 2008, at 8:55 AM, an0 wrote: Sure. I'm grateful that you tell me the internal truth instead of confusing me even more by just saying it is my responsibility to tell compiler more. But if different return types cause different native code, how could my program still work with the mistaken type(an NSString * returned from the inner message is treated as an NSInteger at the first place, then is passed as an NSString * to the outer message) guessed by compiler? Whichever method the compiler sees first wins. While Objective-C is polymorphic, it does not support type based dispatch or type based method differentiation (like, say, Java). In Objective-C, the following doesn't make sense: - (NSInteger) tag; - (NSString *) tag; It won't compile if in the same class file and, as you have discovered, it'll cause no end of problems when the same method name -- the same selector -- has different argumentation across different classes in the class hierarchy. To put it more precisely: Objective-C has a single, global, namespace for all methods. Every method's name, every selector, is in a shared namespace. The method's selector does not include any typing information and, thus, the type of the arguments and return value of the method are not used by the compiler to disambiguate invocations. As a result, the standard pattern is to *never* declare the same method name twice, but with different types of arguments or return values. For someone coming from C++ or Java, this may seem like a pretty nasty restriction. It really isn't. It is just different. And it has some very distinct advantages. Two, in fact: - there is no name mangling - you don't have to figure out the types of the arguments to figure out which of N possible methods on your class, all named identically save for argumentation differences, were invoked I.e. it is dead simple. b.bum ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Why can't I name a property `tag'?
I have a NSString * property named `tag' in my class Foo, and use Foo
instances to populate an NSOutlineView. In one delegate method of
NSOutlineView, I pass the `tag' property of an item to a method as an
NSString * argument as follows:
- (void)outlineViewSelectionDidChange:(NSNotification *)aNotification
{
NSInteger row = [tagView selectedRow];
if (row == -1) {
return;
}
[filteredPosts release];
filteredPosts = [[self filterPosts:postNodes WithTag:[[tagView
itemAtRow:row] tag]] retain];
[postView reloadData];
}
but a warning of passing argument 2 of 'filterPosts:WithTag:' makes
pointer from integer without a cast always pops up when compiling.
I guess it is caused by the fact that NSCell and NSView have a
NSInteger property named `tag'. However, since
* the root class NSObject does not have such a property,
* NSOutlineView's item is typed with id,
* and my class Foo is a direct subclass of NSObject,
what makes XCode think the `tag' property of the item is an NSInteger?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Why can't I name a property `tag'?
Thanks. But isn't it annoying for XCode to pretend to know something for sure while in fact it is just a wrong guess? At least the warning is very misleading. On Thu, Jul 10, 2008 at 9:31 PM, Graham Cox [EMAIL PROTECTED] wrote: I ran into this a while back. Basically if the method names only differ by return type and there is nothing else to go on (like a concrete object pointer type) the compiler, without complaining, plumps for the first one it can find, which invariably is Cocoa's built-in methods and not yours. The return type is not part of the method signature. You have two choices: a) rename your property something else b) type the object explicitly where used, and don't use id. hth, Graham On 10 Jul 2008, at 11:25 pm, an0 wrote: what makes XCode think the `tag' property of the item is an NSInteger? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Any good advice for naming parameters of init methods?
I've been always stumbling on the embarrassment of warning: local declaration of 'xxx' hides instance variable for my init methods, because I really can't figure out a nice naming pattern for parameters used to assign to instance properties, and I am always apt to write code like this: - (id)initWithURL:(NSString *)url title:(NSString *)title tags:(NSString *)tags note:(NSString *)note time:(NSString *)time count:(NSUInteger)count since it is most natural(to me). Then I just see XCode spew out lots of annoying warnings like these: Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Even though I then follow the general naming rules to prepend an indefinite article to each singular noun, I still have those plural nouns sitting there, which now looks this: - (id)initWithURL:(NSString *)aUrl title:(NSString *)aTitle tags:(NSString *)tags note:(NSString *)aNote time:(NSString *)aTime count:(NSUInteger)aCount Set aside the oddness of aTime and aCount, my XCode still complain: Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Am I supposed to use something like aGroupOfTags instead of just tags? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Why can't I name a property `tag'?
We are Cocoa family. I am a RedCocoa, and my elder brother is a BlackCocoa. We both have a `pet', but our Dad doesn't. My pet is a Cat, while my elder brother's pet is a Dog. And of course he got his pet long before me, for he is 10 but I am only 2. So as a Cocoa, am I supposed to have a pet Dog just because my elder brother has one? And should I be accused of lying every time I say I have a pet Cat? On Thu, Jul 10, 2008 at 10:10 PM, I. Savant [EMAIL PROTECTED] wrote: On Thu, Jul 10, 2008 at 9:49 AM, an0 [EMAIL PROTECTED] wrote: Thanks. But isn't it annoying for XCode to pretend to know something for sure while in fact it is just a wrong guess? At least the warning is very misleading. How is this XCode's fault, exactly? You appear to be blaming the IDE for the idiosyncrasies of a dynamically-typed language combined with your own lack of specificity. We'll leave alone the fact that XCode != gcc ... As far as the warning goes, it isn't misleading at all - it's telling you exactly what's happening. That it's alright in this case can't be known by anybody but the developer with the information the compiler has (unspecific type). -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Any good advice for naming parameters of init methods?
I like the idea of adding prefix to my ivars, and in fact, all my C++ code use _ivars. However, I like the declared properties feature of Objective-C 2.0, and the good feeling will be impaired if I have to explicitly bind ivars to these declared properties like this: @synthesize url = iUrl, title = iTitle, tags = iTags, note = iNote, time = iTime, count = iCount. It is not so bad really. But I still prefer a better naming convention for parameters if there is one. On Thu, Jul 10, 2008 at 10:38 PM, Graham Cox [EMAIL PROTECTED] wrote: Bear in mind that the names you choose for these parameter variables are unimportant really, they don't affect the public interface of your class and don't even have to match the header. What I would suggest though is that you adopt a naming convention for your instance variables (ivars) that consistently flag them as such. Some people use a leading underscore, but Apple say not to do that. I personally use 'm' (for 'member') which is a carry-over from my C++ days, but anything consistent is good. This not only fixes your shadowing problem, but makes code far more readable by indicating at a glance where a given variable lives. Graham On 11 Jul 2008, at 12:25 am, an0 wrote: I've been always stumbling on the embarrassment of warning: local declaration of 'xxx' hides instance variable for my init methods, because I really can't figure out a nice naming pattern for parameters used to assign to instance properties, and I am always apt to write code like this: - (id)initWithURL:(NSString *)url title:(NSString *)title tags:(NSString *)tags note:(NSString *)note time:(NSString *)time count:(NSUInteger)count since it is most natural(to me). Then I just see XCode spew out lots of annoying warnings like these: Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Even though I then follow the general naming rules to prepend an indefinite article to each singular noun, I still have those plural nouns sitting there, which now looks this: - (id)initWithURL:(NSString *)aUrl title:(NSString *)aTitle tags:(NSString *)tags note:(NSString *)aNote time:(NSString *)aTime count:(NSUInteger)aCount Set aside the oddness of aTime and aCount, my XCode still complain: Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Am I supposed to use something like aGroupOfTags instead of just tags? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/graham.cox%40bigpond.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Why can't I name a property `tag'?
I am with you. We should coldly face the somewhat cold reality. On Thu, Jul 10, 2008 at 11:26 PM, Graham Cox [EMAIL PROTECTED] wrote: At some point you have to realise that it's a compiler, a very dumb finite state machine. It can't intelligently recognise every possible nuance of your code. I agree it's not good behaviour - in my case it caused a bug that corrupted memory that crashed the program in a completely unrelated place, and took me 11 hours to find the real cause. One thing you could do is to unravel that big compound statement somewhat and explicitly type some intermediate variables. This not only makes the code more readable, but any warnings that the compiler can offer will be more obvious. There's no real performance advantage to huge compound statements, and they definitely make code harder to read at times. Graham On 11 Jul 2008, at 1:19 am, an0 wrote: However, if you don't know what exact type of Cocoa I am, how could you call me BlackCocoa so surely? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Why can't I name a property `tag'?
Sure. I'm grateful that you tell me the internal truth instead of confusing me even more by just saying it is my responsibility to tell compiler more. But if different return types cause different native code, how could my program still work with the mistaken type(an NSString * returned from the inner message is treated as an NSInteger at the first place, then is passed as an NSString * to the outer message) guessed by compiler? On Thu, Jul 10, 2008 at 11:40 PM, Jens Alfke [EMAIL PROTECTED] wrote: On 10 Jul '08, at 8:19 AM, an0 wrote: However, if you don't know what exact type of Cocoa I am, how could you call me BlackCocoa so surely? Can we stop using confusing metaphors and just talk about OOP? :-p When the compiler parses a message-send expression ([]) it tries to figure out which declared method is being invoked. The most important reason for this is that it needs to know the return type of the method, because that can affect the machine code that's generated for the call. If the receiver of the expression is typed as id, i.e. with no class, the compiler has no clues about what class to look for matching methods in. So it looks in any @interface blocks that it's already seen (i.e. ones in all #imported headers). If it finds one matching method, it uses it. If it finds more than one method, and the return types differ, then the situation is ambiguous … so it emits a warning. The short answer to your question, then, is that the compiler has to decide what method is being used, because that determines what machine code to generate. This is an ugly side effect of the fact that Objective-C compiles into native code and not some abstract bytecode like Java or Python. It's part of the price you pay as a developer for creating apps that run fast. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Is it possible for several NSURLConnection instances to share one delegate?
Thank you all. I am going to try what I've learnt from this thread:) On Thu, Jun 26, 2008 at 12:01 AM, I. Savant [EMAIL PROTECTED] wrote: Just to mention, the natural approach would be a dictionary whose keys are connection objects with a value being a request, or maybe another dictionary with several pieces of info about a connection. The problem is that you can't use NSURLConnection objects as keys because they aren't copyable. For that, I recommend using [NSValue valueWithNonretainedObject:aConnection] as the key. I like Jens' approach better than the on-the -spot solution I concocted. ;-) -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Is it possible for several NSURLConnection instances to share one delegate?
So it forces me to keep all the fired NSURLConnections, right? Otherwise, I can't tell which is which in my delegate methods. On Wed, Jun 25, 2008 at 10:57 PM, I. Savant [EMAIL PROTECTED] wrote: On Wed, Jun 25, 2008 at 10:17 AM, Ling Wang [EMAIL PROTECTED] wrote: I can't find a way to identify different NSURLConnection instances in the delegate methods, for NSURLConnection does not offer access to the NSURLRequest used to initialize it. Really? The delegate methods I see for NSURLConnection all start with - (void)connection:(NSURLConnection *)connection . Seems like the connection passes a reference to itself as the very first argument. As to getting the NSURLRequest, why do you need to get it from the connection? This seems like an overall design problem. See Creating a Connection in this document: http://developer.apple.com/documentation/Cocoa/Conceptual/URLLoadingSystem/Tasks/UsingNSURLConnection.html# -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Is it possible for several NSURLConnection instances to share one delegate?
Sure, I see that. But since it is what both of us could think up, it makes me more confident. On Wed, Jun 25, 2008 at 11:22 PM, I. Savant [EMAIL PROTECTED] wrote: I believe so, yes. It's important to note that I've never had reason to build anything that handles multiple requests. I've only built a simple system to download a single XML file and have my way with it. My advice and understanding is based on the documentation and how I would attempt to go about building such a thing. Take that into consideration (I don't like to steer people in the wrong direction). -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Why does this https post request always return 404 Not Found
- (void) login
{
NSString *userName = [[userNameField stringValue]
stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSString *password = [[passwordField stringValue]
stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSURL *url = [NSURL URLWithString:@https://secure.del.icio.us/login;];
NSMutableURLRequest *urlRequest = [NSMutableURLRequest
requestWithURL:url
cachePolicy:NSURLRequestReturnCacheDataElseLoad
timeoutInterval:30];
[urlRequest setHTTPMethod:@POST];
NSString *body = [NSString stringWithFormat:
@user_name=%@
@password=%@,
userName, password];
[urlRequest setHTTPBody:[body dataUsingEncoding:NSUTF8StringEncoding]];
NSLog(@request: [EMAIL PROTECTED]@\n%@,
[urlRequest URL],
[urlRequest HTTPMethod],
[[[NSString alloc] initWithData:[urlRequest HTTPBody]
encoding:NSUTF8StringEncoding] autorelease]);
NSData *urlData;
NSURLResponse *response;
NSError *error;
urlData = [NSURLConnection sendSynchronousRequest:urlRequest
returningResponse:response
error:error];
if (!urlData) {
NSAlert *alert = [NSAlert alertWithError:error];
[alert runModal];
return;
}
// Parse the login result
NSString *loginResult = [[[NSString alloc] initWithData:urlData
encoding:NSUTF8StringEncoding]
autorelease];
NSLog(@login result: %@, loginResult);
}
Is there anything special about https requests in Cocoa that I must
learn? Since I've verified that sending http requests in this manner
is perfectly OK, and accessing https://secure.del.icio.us/login in web
browsers goes well.
If anyone could tell me anything that I've missed here, I'll very much
appreciate that.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Why does this https post request always return 404 Not Found
Cool, it works. Thanks a lot. But as to APIs, I really can't find the login API, or I would of course use that instead of posting forms. Can you tell me where the login API is? On Sun, Jun 22, 2008 at 6:32 AM, Jens Alfke [EMAIL PROTECTED] wrote: This is pretty weird. After some experimenting, I narrowed it down to the value of the User-Agent header. I think the del.icio.us server is checking that header and returning a 404 if it doesn't like it. And it doesn't seem to like CFNetwork's default user-agent header, though it likes Safari and curl. You can programmatically set the User-Agent header value to Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_3; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.1 Safari/525.20 and the result should work. On the other hand, why are you trying to log into del.icio.us using forms and cookies as though you were a web browser? That site already has a pretty comprehensive API for applications to access it; you should use that instead. (That may in fact be what they're trying to tell you by blocking your request.) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
How to sort smoothly when NSTableColumn's Sort Key is empty
I know how to sort items in NSTableView when each NSTableColumn corresponds to a property of the item object. But what if there is only one NSTableColumn and it is just mapped to the item object itself instead of a property of it? I set the Selector to compare: and leave the Sort Key to empty for the NSTableColumn in Interface Builder. It seems items can be sorted once in such a case but the order can not be reverted by clicking the column header again. And the NSTableView's sortDescriptors are found cumulated instead of changed by NSLog in dataSource's tableView:sortDescriptorsDidChange: method. What is the right configuration for such a case then? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: A cursor bug in DragItemAround example
On Sun, Apr 27, 2008 at 3:34 PM, Quincey Morris
[EMAIL PROTECTED] wrote:
On Apr 26, 2008, at 23:14, an0 wrote:
Setting a cursor always works, but is useless if something else changes
it immediately afterwards. I think that might be what's happening here.
(Also, if view comes from a NIB, initWithCoder may be called instead of
initWithFrame.)
What's happening here is exactly what I want to know. I think
awakeFromNib should set the scene no matter initWithCoder or
initWithFrame is called, so I do my initialization in awakeFromNib.
I think you have 2 separate cursor management problems to solve:
1. When not dragging. Tracking areas may be useful, even if the items are
not subviews. You should have a cursorUpdate method, otherwise some default
implementation of it may keep changing the cursor on you. The cursorUpdate
event will tell you which NSTrackingArea is involved, so you can use that to
work out how to choose the cursor.
2. When dragging. Tracking areas don't matter, because (presumably) you
just want to force a single cursor wherever the mouse goes. Your
cursorUpdate method needs to take the dragging state into account. As I said
before, you may not be able to control the cursor completely, when it is
*outside* your view during a drag.
What you said is exactly what I've done.
If you change the NSTrackingArea at mouseUp, you should probably specify
the NSTrackingAssumeInside option too, since (presumably) you are placing
the tracking area so that the mouse is actually inside. (The documentation
for this option is almost completely wrong. See the Leopard developer
release notes if you want the correct description.)
I've appended NSTrackingAssumeInside option as you advise, but the
misbehavior remains.
At this point, I think it is more convenient if I make my code
available, so that you can know better what I am trying to achieve and
find what I've done inappropriately and revise it accordingly. Thank
you for your time in advance. The code is simple and short.
DraggableItemView.h:
#import Cocoa/Cocoa.h
@interface DraggableItemView : NSView {
NSPoint location;
NSTrackingArea *trackingRect;
// private variables that track state
BOOL dragging;
BOOL inTrackingRect;
NSPoint lastDragLocation;
}
@property(retain) NSTrackingArea *trackingRect;
// ---
// Modify the Rectange location
// ---
- (void)offsetLocationByX:(float)x andY:(float)y;
-(IBAction)setItemPropertiesToDefault:(id)sender;
// ---
// Various Accessor Methods
// ---
- (void)setLocation:(NSPoint)point;
- (NSPoint)location;
- (NSRect)calculatedItemBounds;
- (BOOL)isPointInItem:(NSPoint)testPoint;
@end
DraggableItemView.m:
#import DraggableItemView.h
@implementation DraggableItemView
@synthesize trackingRect;
- (void)awakeFromNib
{
[self setItemPropertiesToDefault:self];
}
- (void)dealloc
{
[trackingRect release];
[super dealloc];
}
// ---
// Draw the View Content
// ---
- (void)drawRect:(NSRect)rect
{
// erase the background by drawing white
[[NSColor whiteColor] setFill];
[NSBezierPath fillRect:rect];
// set the current color for the draggable item
[[NSColor redColor] setFill];
// draw the draggable item
[NSBezierPath fillRect:[self calculatedItemBounds]];
}
- (BOOL)isOpaque
{
return YES;
}
// ---
// Modify the item location
// ---
- (void)offsetLocationByX:(float)x andY:(float)y
{
// tell the display to redraw the old rect
[self setNeedsDisplayInRect:[self calculatedItemBounds]];
// since the offset can be generated by both mouse moves
// and moveUp:, moveDown:, etc.. actions, we'll invert
// the deltaY amount based on if the view is flipped or
// not.
int invertDeltaY = [self isFlipped] ? -1: 1;
location.x=location.x+x;
location.y=location.y+y*invertDeltaY;
// invalidate the new rect location so that it'll
// be redrawn
[self setNeedsDisplayInRect:[self calculatedItemBounds]];
}
// ---
// Hit test the item
// ---
- (BOOL)isPointInItem:(NSPoint)testPoint
{
BOOL itemHit=NO;
// test first if we're in the rough bounds
itemHit = NSPointInRect(testPoint,[self calculatedItemBounds]);
// yes, lets further refine the testing
if (itemHit) {
}
return itemHit;
}
// ---
// Handle Mouse Events
// ---
-(void)mouseDown:(NSEvent *)event
{
NSPoint clickLocation;
BOOL itemHit=NO;
// convert the click location into the view coords
clickLocation = [self convertPoint:[event locationInWindow]
fromView:nil];
// did the click occur
Re: A cursor bug in DragItemAround example
Does this sample application still use cursorRects/NSTrackingRects?
Leopard introduced a new mechanism -- NSTrackingArea and cursorUpdate
events -- which doesn't have some of the problems that the old
mechanism supposedly had.
With NSTrackingArea and cursorUpdate you should be able to get
complete, consistent control of the cursor inside the visible portion
of your view (even when returning from the outside), and it's fairly
easy to use. [NSScrollView setDocumentCursor:] will still be necessary
to control the part of the scroll view outside the visible portion of
your view, and control entirely outside the scroll view (or window)
will be harder to enforce, because other views (and other windows) may
have their own ideas.
Thanks. I've tried NSTrackingArea, and it seems a clearer concept and
easier to use. However, there are still two problems I can't fix:
1. Setting cursor in initWithFrame: and awakeFromNib does not have
effect. So I can't set the initial cursor.
2. Setting cursor together with tracking areas renders the cursor
setting ineffective. I found this from my mouseUp action. With the
code handling tracking areas, [[NSCursor openHandCursor] set] did not
give me an openHandCursor, but an arrowCursor.
-(void)mouseUp:(NSEvent *)event
{
dragging=NO;
[self removeTrackingArea:trackingRect];
self.trackingRect = [[[NSTrackingArea alloc] initWithRect:[self
calculatedItemBounds]
options:NSTrackingCursorUpdate | NSTrackingActiveInActiveApp
owner:self
userInfo:nil] autorelease];
[self addTrackingArea:trackingRect];
[[NSCursor openHandCursor] set];
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
Thanks. But it seems you haven't read to the end. As I said in my first mail: Besides, I found the value returned by [NSKeyedUnarchiver unarchiveObjectWithData:data] was nil, but I didn't understand why, since it was normal when I saved the file using [NSKeyedArchiver archivedDataWithRootObject:view.drawing]. On Fri, Apr 25, 2008 at 3:20 AM, Jens Alfke [EMAIL PROTECTED] wrote: I suspect what happened is that NSKeyedArchiver returned nil for some reason, and the caller of that method then looked at *outError to find the reason for the error; but you didn't store anything in there, so it got whatever happened to be in that variable, which in this case may have been a pointer to the NSDocumentController. So try adding a test for nil to your save method. It looks like that's where the problem is. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
Sorry for my careless, I though Jens was talking about the `read' part. However, as I said, the error occurred when reading not when writing. So it was not because NSKeyedArchiver returned nil but because `[NSKeyedUnarchiver unarchiveObjectWithData:data]' returned nil, and my `readFromData:(NSData *)data ofType:(NSString *)typeName error:(NSError **)outError' returned NO without setting `outError' (thanks Jens let me learn this point). OK. Now I'm just wondering why `[NSKeyedUnarchiver unarchiveObjectWithData:data]' returnes nil, since I've saved the data without any error as I can see. Thanks a lot if you or others can give me some more hint. On Fri, Apr 25, 2008 at 4:29 PM, Kyle Sluder [EMAIL PROTECTED] wrote: On Fri, Apr 25, 2008 at 4:11 AM, an0 [EMAIL PROTECTED] wrote: Thanks. But it seems you haven't read to the end. As I said in my first mail: Besides, I found the value returned by [NSKeyedUnarchiver unarchiveObjectWithData:data] was nil, but I didn't understand why, since it was normal when I saved the file using [NSKeyedArchiver archivedDataWithRootObject:view.drawing]. But you apparently haven't comprehended Jens' message. You're not setting *outError to anything, so whoever is calling your method is seeing that you've returned NO and is expecting whatever it passed in as outError to point to an NSError object. Unfortunately this is not the case and whatever was in that memory location is receiving bogus messages -- particularly, -localizedFailureReason, which is an NSError method. In short, you're breaking the contract for messages which take an NSError**. Set *outError to an NSError object (or nil if you're lazy) if you're going to return a value that signifies an error. --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 [EMAIL PROTECTED]
Re: A cursor bug in DragItemAround example
Chances are, calling '[[self enclosingScrollView] setDocumentCursor:[NSCursor closedHandCursor]]' in 'mouseDown:' will fix the problem you're seeing. NSScrollView/NSClipView's way of changing the cursor conflicts with autoscrolling or drag-scrolling, but AFAIK there's no way of preventing that interference directly. This partially works. However, if you move the item off the visible part of scroll view and then move back, you'll find a arrowCursor instead of openHandCursor when cursor hovers on the item. It seems cursor problems pervade Cocoa applications and Apple just ignores them:( ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Failure on unarchiving a NSBezierPath
I was building a very simple drawing application, but met problems
when reading the file saved by my application.
The two functions as to archiving/unarchiving are as follows:
- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
return [NSKeyedArchiver archivedDataWithRootObject:view.drawing];
}
- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName
error:(NSError **)outError
{
NSBezierPath *drawing = [NSKeyedUnarchiver
unarchiveObjectWithData:data]; //*** returns nil
if (drawing == nil) {
return NO;
} else {
view.drawing = drawing;
return YES;
}
}
Nothing appeared when I opened a saved file, and log said:
2008-04-23 23:33:44.127 EasyDraw[631:10b] *** -[NSDocumentController
localizedFailureReason]: unrecognized selector sent to instance
0x11b210
2008-04-23 23:33:44.128 EasyDraw[631:10b] *** -[NSDocumentController
localizedFailureReason]: unrecognized selector sent to instance
0x11b210
I don't know what the log means.
Besides, I found the value returned by [NSKeyedUnarchiver
unarchiveObjectWithData:data] was nil, but I didn't understand why,
since it was normal when I saved the file using [NSKeyedArchiver
archivedDataWithRootObject:view.drawing].
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
