Re: NSTableView with complex cells ?
On Jan 16, 2009, at 3:37 AM, Guillaume Laurent wrote: I'm currently toying with the idea of writing a very basic music sequencer. The main window would, like all sequencers, display a list of music tracks (e.g. Garage Band's main window). Apparently, an NSTableView with two columns (one for the track's various parameters and the other for the track itself) could be a good start, provided I can create NSCells which are very elaborate, for instance able to display several controls, or to have a large drawing area. Is this doable, or should I write my own NSView from scratch ? (which I hope not to) For creating custom complex cells, see: <http://developer.apple.com/samplecode/PhotoSearch/index.html> An alternative to using cells in a table view might be to use views in a NSCollectionView: <http://developer.apple.com/documentation/Cocoa/Reference/NSCollectionView_Class > 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: Nib memory management under Garbage Collection
On Jan 15, 2009, at 6:35 PM, Rob Keniger wrote: as far as I can tell the Nib objects should just get cleaned up automatically as their root (the File's Owner) is no longer hanging around. Note that the files owner isn't necessarily the owner / root of all objects instantiated by the nib file. It typically is, but not always. I was just a bit confused by this page in the Memory Management guide: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemMgmtNibObjects.html "The File’s Owner of a nib file is typically responsible for releasing the top-level objects in a nib file as well as any non- object resources created by the objects in the nib." Under GC you're not responsible for releasing anything. That comment doesn't apply to GC. You have the inverse responsibility though: Making sure that you have strong references to all objects that you're interested in keeping alive. 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: Remove Items From NSSet (safely)
On Jan 11, 2009, at 11:17 PM, Bridger Maxwell wrote:
I have an NSSet which I need to iterate through and remove any
objects if
they fail a certain test (this is a client/server setup, so I am
testing the
connection to connected clients). However, if I remove an object
from the
set while iterating through it, I get this message logged to the
console.
Collection was mutated while being
enumerated.*
Is there a better way to remove objects from a set? Perhaps there is
a safe
iteration that allows objects to be removed? I supposed I could keep a
separate list of objects that need to be removed, and then remove them
afterwards, but that seems like a clunky solution.
How about something like this?
for (id obj in [theSet allObjects])
{
if (something)
{
[theSet removeObject: obj
}
}
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: What is the best way to copy files
On Jan 10, 2009, at 1:23 PM, David wrote: This is sort of a conceptual question. The broader question is what is the purpose of Cocoa and how does it relate to Core Foundation and Unix. The specific question is, what is the best way to copy files. I think that one thing is clear: It's probably not smart to try to implement file copying by manually reading in and writing out files. Use the API:s provided at either the unix, Carbon or Cocoa layers. Which one to choose depends on your requirements. You forgot one important API in your list: copyfile (for more information, see the man page). This also addresses a broader question I have about how Cocoa relates to Core Foundation, to Unix APIs and even to standard C functions. I had thought Cocoa was a wrapper for Core Foundation, but NSFileManager is not a wrapper. There is no equivalent in Core Foundation, while the Carbon file manager has no equivalent in Cocoa. Cocoa sits on top of a bunch of C libraries, including standard unix and Carbon. Cocoa is not simply some sort of wrapper around CF, and actually pre-dates the introduction of CF. Cocoa and Carbon evolved on separate operating systems originally, so there is no simple mapping between the functionality that they provide. In some cases Carbon provides a better feature set, in some cases Cocoa. You'd have to pick the best API to use for your particular purpose, while making sure to stay away from any deprecated API:s. 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: What's the most cocoa-ey pattern for this?
On Jan 8, 2009, at 3:34 PM, Michael B Johnson wrote: @property (readonly) NSMutableSet *activeMarkers; You're right - it should be a set, not an array. But would it be mutable if it's readonly? What are the correct semantics for that, actually? The "readonly" attribute only refers to the property itself, not the mutability / immutability characteristics of that property, so it's perfectly OK to have a readonly mutable property. That said, you typically wouldn't expose a mutable collection through an interface like that of course - it's a bit too promiscuous. If performance allows, the easiest and most straight forward way to implement this would be to have an immutable collection, and to replace the entire collection whenever it changes. If you need better performance or granularity, you can use a mutable collection, but you need to ensure that you mutate the collection in such a way that you get the KVO behavior that you need. 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: What's the most cocoa-ey pattern for this?
On Jan 8, 2009, at 2:59 PM, Michael B Johnson wrote: This Sequence has a delegate, that would like to express interest in the following: (1) when the "current time" moves forward into the beginning of an Element or Marker. (2) when the "current time" moves backward into the end of an Element or Marker. (3) when the "current time" is the same as a Marker attached to a single point in time. With that information, we would know what Element is "active", and what Markers might be "active". So this is the goal: To be able to track the active element and marker, to be notified when elements and markers are activated? It seems to me that you're not really talking about delegation, but rather observation (?), so how about using KVO (pseudocode & incomplete): @interface Sequence @property (readonly) Element *activeElement; @property (readonly) Element *activeMarker; @property (readonly) Direction currentDirection; @end Your observers would add themselves as observers for the properties that they are interested in, and then get notified as they changes. I think that these three properties would be all that you need to satisfy your #1 - #3 above. 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: [NSOutlineView reloadData]
On Jan 8, 2009, at 11:07 AM, David Blanton wrote: My error ... I thought reloadData was asynchronous! It all depends on what you're after. Display updates are almost always delayed in Cocoa, meaning that the outline view will not show updated contents after your call to reloadData. All views will be redisplayed at the end of the current event loop. This leads to less "flickering", and less redundant redrawing. Like I said in my last reply to you: We can't really help you before you tell us what you're *really* trying to do. 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: [NSOutlineView reloadData]
On Jan 8, 2009, at 9:42 AM, David Blanton wrote: Is there a way to be notified when a reloadData operation is complete? What do you mean with complete? It's a regular synchronous method call, so it's completed when it returns. I bet there's something that you're trying to do that you're not asking. Could you perhaps explain what you're really trying to do? Cheers, 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: How to obtain icon displayed by Finder for a file
On Jan 7, 2009, at 1:42 PM, David wrote: Hello,Is there a way to obtain the icon that finder uses to display for a file system object? Such things as the folder icon for folders, PDF icon for pdfs etc. See: NSWorkspace 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: NSScrollView refuses to scroll
On Jan 7, 2009, at 1:26 PM, j o a r wrote: // A suggestion The correct thing to do is typically not to start with a scroll view. If you simply drag out a text view from the library it comes wrapped in a scroll view already - No need to add a scroll view manually. If you need to set it up manually (unlikely), make sure that you understand the arrangement of views inside the scroll view first. There is a very good "scroll view programming guide" in the documentation that can help you get up to speed. In addition: If you need to add a scroll view to some view that isn't already wrapped in a scroll view when you get it from the library, the preferred way to do that would be to select it and then use this menu item: Layout > Embed Objects In > Scroll View This would, for example, work if you wanted to wrap a NSTextField in a scroll view. 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: NSScrollView refuses to scroll
On Jan 7, 2009, at 1:13 PM, Jason Cox wrote: If you, in IB, create a new window, throw a NSScrollView in there, set its autosizing to keep 100% width / height when you resize the superview, then put an NSTextView at the bottom edge of the scrollview, compile and resize the window up to hide the NSTextView it wont put a scrollbar (even though you cant see the textview) Am i just completely missing the concept of what NSScrollView does? // The basics The scroll view will only show the scrollers when the frame of its document view is larger than the frame of its content view (the clip view). // A guess I would guess that when you added the text view, you didn't add it as the document view of the scroll view, but rather as a subview of the document view of the scroll view? The scroll view doesn't track or care about the subviews of its document view, it only cares about the size of the document view. // A suggestion The correct thing to do is typically not to start with a scroll view. If you simply drag out a text view from the library it comes wrapped in a scroll view already - No need to add a scroll view manually. If you need to set it up manually (unlikely), make sure that you understand the arrangement of views inside the scroll view first. There is a very good "scroll view programming guide" in the documentation that can help you get up to speed. 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: Pull Down Toolbar Item
On Dec 29, 2008, at 10:04 AM, Carmen Cerino Jr. wrote: You need to subclass in order to get validation working. That is the only reason I can think of why it needs to be a subclass Can you describe the type of validation that you're interested in performing? Simple validation should work automatically for at least the standard Cocoa controls, IIRC. The toolbar items are sized at 32x32 for both min and max. When I create the Popup button control, it is created with a frame of size 32x32 as well. Is there something I am forgetting to properly size? Not sure. Perhaps you can provide a screenshot of what the toolbar looks like when it's not aligned properly? If you could post a sample project that reproduces your problem, that would probably help too (preferably over http, and not inline to the list). 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: Pull Down Toolbar Item
On Dec 29, 2008, at 10:59 AM, Carmen Cerino Jr. wrote: The setArrowPosition and preferedEdge methods do not work for me. I followed the documentation to get the arrow to appear in the lower right corner pointing down and nothing happens. Please file a bug report. At the very least, the documentation and sample code that is provided should be able to provide better guidance for how these properties work (or don't). 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: How Does Autorelease Pool Work?
On Dec 29, 2008, at 9:00 AM, Oleg Krupnov wrote: I am a newbie to Cocoa Memory Management (have been using GC so far), and I'd like to make sure that my understanding is correct. - It follows that the actual releasing of objects registered in the auto-release pool is deferred until the entire call stack is unfolded back and the control passes to the next event. All of your assertions up until this point are correct. In this regard, auto-release pools remind me the garbage collector, where the time of deallocation is also somewhat indeterminate. This is not incorrect, but I think that this point can at least be argued. It's pretty clear that the time of deallocation would have to be considered at least *less* deterministic in GC. In addition, in GC you can't (this is of course both and advantage and a disadvantage) exert the same amount of manual control (using local autorelease pools, or even sidestepping the user of autorelease). 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: Pull Down Toolbar Item
On Dec 29, 2008, at 7:00 AM, Carmen Cerino Jr. wrote: In order to create the item, I started with a subclass of NSToolbarItem that has a NSPopupButton for its view. Any particular reason to use a subclass? You should be able to use a plain NSTollbarItem, and set the pop-up button using "-setView:". The issue I am running into is that the image is not being fully displayed (see screen capture below). Increasing the size of the toolbar item solves the issue, but causes the item to be out of alignment with the rest of the items. As you have noted, you need to set the max and min sizes of a toolbar item that contains a custom view. In order for your items to line up, you probably also need to make sure that they're of similar size. The standard size for image style toolbar items is 32x32px. I am just curious as to how they got it positioned more to the bottom right of the image vs. the center. My guess is that they possibly drew the triangle themselves. I think that you're supposed to be able to use the "arrowPosition" and "preferredEdge" properties of the pop-up button cell to control where the arrow shows up, but I think that Xcode is probably using custom artwork in this case. 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: Memory Management question
On Dec 26, 2008, at 9:28 AM, Michael Ash wrote:
But yes, generally,
you should retain any object that's being passed into a method to
ensure
that it stays around for the lifetime of that method and release
them when
you exit.
Absolutely false. Never do this. If you find yourself doing this then
it means you've either horribly misunderstood something or you've
encountered a severe bug. The correct course of action is to either
correct the misunderstanding or correct the bug, not to wrap all of
your methods in retain/release calls.
While I agree with your recommendation to not retain all local
parameters and variables, there is something to be said for doing so.
It's not difficult to argue that it is more correct from a conceptual
point of view, and the reason to omit this ownership swizzle is
primarily that it's for the most part redundant.
The reason why this can be useful is easy to see:
{
id foo = [self foo];// A local variable or
parameter
[self bar]; // Can lead to deallocation of
"foo" as a side effect
NSLog(@"Foo: %@", foo); // Trying to use "foo" here can
lead to crash
}
Whenever you call "out" from the local scope, you can't in the general
case know that your non-retained variables will survive. You might
think that you know, if you control all of the code that you call to,
but it's not difficult to introduce regressions later on.
This is also why the recommended Cocoa implementation of a getter
accessor method returns an object like this:
return [[obj retain] autorelease];
I'm not a fan of this recommendation, and it's sort of in competition
with the recommendation made in this thread. If I had to choose, I'd
rather see explicit retains and releases in the local scope, than this
type of "hack" in the getter methods (I think that the decision should
be made in the receiver). I typically choose to do neither though! :-)
Two final notes:
* This is really a very, very, small problem in practice. I think that
over my ~8 years of full time Cocoa programming, I've only had to
troubleshoot such a problem once or twice in real world code.
* This discussion only applies to RR (retain/release) code, in GC
(garbage collection) you get this "safer" behavior "for free", since
the pointers you have to local variables on the stack will prevent
deallocation.
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: Memory Management question
On Dec 25, 2008, at 11:30 AM, Scott Wilson wrote: NSLog(@"url %@", [desiredURL path]); // get EXC_BAD_ACCESS if link was an NSURL I'd suggest that you try to troubleshoot this using NSZombieEnabled. Is it possible that link is being autoreleased before my method has returned? That doesn't seem likely, unless you have a memory management problem elsewhere (hence the suggestion to use NSZombieEnabled above). Objects aren't just autoreleased at random, typically (unless you change the basic rules by adding your own autorelease pools) this only happens at the end of the current event. On Dec 25, 2008, at 9:45 PM, Robert Marini wrote: Indeed, you have no way of guaranteeing that link still exists as you are not explicitly claiming ownership to it. In the first case of your if, you receive an autoreleased NSURL instance (a new object created by using the contents of the link object). In the second, all your code is doing is deciding that desiredURL should point to the same object as link without claiming ownership of it. To ensure that you hold ownership of it, you need to explicitly retain it (code executing in the context of another thread might release it and cause it to receive -dealloc) or copy it (the former probably being the more appropriate in this case). Following that, it should be released when it is no longer of any relevance in this particular context. If you want to use a super-defensive programming style, you could follow this general guideline. Most Cocoa developers don't though. In any case I would suggest that before you do, you need to sit down and understand why you would want to do this. The threading problem that is mentioned above is, for example, NOT the reason to adhere to this type of defensive memory management scheme. Increasing retain count is NOT a way to become thread safe. On Dec 25, 2008, at 11:49 PM, Scott Wilson wrote: Am I missing something? I don't think so. 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: NSString stringByTrimmingCharactersInSet method doesnt work.
On Dec 23, 2008, at 10:00 AM, Alex.Wang wrote: We may expect to see "Trick here: Thereareblanks" output from the console. However, I got "Trick here: Thereareblanks" instead. I dont know why the stringByTrimmingCharactersInSet method doesn't work. Can anyone here give me an explanation or tell me how to solve it? From the documentation for this method: "A new string made by removing from both ends of the receiver characters contained in set." Note that it only removes characters "from both ends of the receiver". 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: Sublclassing NSThread
On Dec 16, 2008, at 9:29 AM, Brad O'Hearne wrote: Is this the recommended approach, or is there another way to go about this? Have you considered using NSOperation / NSOperationQueue? From what you're saying I think that would be the preferred building block for this type of thing starting with Mac OS X 10.5 Leopard. 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: Arggg...overrelease in table view cell, but where?
On Dec 11, 2008, at 2:17 PM, Markus Spoettl wrote: So it stops the debugger and shows you the call stack *at the exact time it's being called* and gives to an opportunity to walk back the call stack before continuing? How so? Please do tell me how to do that. Sure does! (obviously, aside from stopping the debugger..) Sure but the stopping-in-the-debugger-feature is what the essential part of the procedure I was describing is. Essential for me anyway. Not essential for troubleshooting this type of problem in general though, that's the only thing I was referring to. If you have special needs, it might well be that you have to use something else, but this should be your first approach (IMO). 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: Arggg...overrelease in table view cell, but where?
On Dec 11, 2008, at 4:06 PM, Benjamin Stiglitz wrote: NSCells use NSCopyObject to do their copies, which ends up setting the values of cellObject and gridController in your copies, but not retaining them. You need to nil them out before setting the values in your properties. This is a long-standing misbehavior of NSCell that probably won’t be changing anytime soon. This is indeed a problem. The documentation covers it, for the most part, but it could still be improved: <http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/ImplementCopy.html > <http://developer.apple.com/documentation/Cocoa/Conceptual/ControlCell/Tasks/SubclassingNSCell.html > 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: Arggg...overrelease in table view cell, but where?
On Dec 11, 2008, at 1:02 PM, Markus Spoettl wrote: Overwrite GFController's -release and -autorelease, simply calling [super release] and [super autorelease] (ensure you get the signatures exactly right). Set a breakpoint in both and debug the app. When the debugger hits the breakpoints you will see exactly who called it in the call stack. You can then go a figure out if that was on purpose. Don't do that - Use the ObjectAlloc Instrument, it provides this information out of the box. 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: Custom NSTableView cells
On Dec 9, 2008, at 6:21 PM, Randall Meadows wrote: I could use a little guidance, please, on customizing cells for display in an NSTableView. (My app is Leopard-only.) I looked around the Apple docs and cocoadev, but didn't really find anything useful. Other pointers would be appreciated. Take a look at this sample project: <http://developer.apple.com/samplecode/PhotoSearch/> 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 [EMAIL PROTECTED]
Re: NSTask and environment variables
On Dec 8, 2008, at 4:43 PM, Chris Idou wrote: Is there any Cocoa API which returns the environment as a NSDictionary, or do I need to drop down to the UNIX getenv() level? See: -[NSProcessInfo environment] 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 [EMAIL PROTECTED]
Re: Cocoa replacement for SetWindowModality
On Dec 2, 2008, at 7:28 AM, Russ wrote: In my UI there's a spot where it's very useful for the user to be able to change a window from modal to modeless for a little while. In Carbon, I used SetWindowModality to do so. How can I do the same in Cocoa? It doesn't look like I can reconfigure a run loop to do this. Thanks. Perhaps if you'd tell us why you'd want to do this, we might be in a better position to offer good advice. Thanks, 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 [EMAIL PROTECTED]
Re: analysing image to find blobs
On Nov 29, 2008, at 12:18 PM, Roland King wrote: If someone has something like 'read about these two classes, take a look at these 4 methods and you probably want this kind of transform', that would get me going in the right direction. You can probably assume that if I get to the point I have something I can search across and determine for each point if it's coloured or not, I can manage the 'finding the center of the circle' bit of the algorithm. I just want to get the data into the best format for it as fast as possible using as much framework as I can. Take a look at the CIColorTracking sample code: <http://developer.apple.com/samplecode/CIColorTracking/index.html> Very interesting stuff. Also highly efficient, since it's typically hardware accelerated. 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 [EMAIL PROTECTED]
Re: Problem with binding of @count
On Nov 28, 2008, at 11:41 PM, Mikael Wämundson wrote:
But I want the number of objects to be part of a text string ("The
number of students is: "). Thus I put this code into
myDocument.m:
-(NSString *) numberOfStudents
{
return [NSString stringWithFormat:@"The number of students is: %@",
[theStudentArrayController
valueForKeyPath:@"[EMAIL PROTECTED]"]];
}
No error during compilation or run-time, but value in the text label
is not updated when the array is changed.
For a simple thing like this you might also use a "Pattern Binding":
<http://developer.apple.com/documentation/Cocoa/Reference/CocoaBindingsRef/Concepts/BindingTypes.html
>
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 [EMAIL PROTECTED]
Re: Problem with binding of @count
On Nov 28, 2008, at 2:49 PM, j o a r wrote: I think that it would be more straight forward and efficient to write that: [NSString stringWithFormat:@"The number of students is: %lu", ((unsigned long)[theStudentArrayController count])]; Crap, typo: You'd get the count from the array, and not the controller, of course... 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 [EMAIL PROTECTED]
Re: Problem with binding of @count
On Nov 28, 2008, at 11:41 PM, Mikael Wämundson wrote:
-(NSString *) numberOfStudents
{
return [NSString stringWithFormat:@"The number of students is: %@",
[theStudentArrayController
valueForKeyPath:@"[EMAIL PROTECTED]"]];
}
I think that it would be more straight forward and efficient to write
that:
[NSString stringWithFormat:@"The number of students is: %lu",
((unsigned long)[theStudentArrayController count])];
No error during compilation or run-time, but value in the text label
is not updated when the array is changed.
That's because you haven't told the bindings machinery that the
"numberOfStudents" property depends on the count of objects in the
array. See:
<http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueObserving/Concepts/DependentKeys.html
>
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 [EMAIL PROTECTED]
Re: -[NSWindowController window] fails
On Nov 28, 2008, at 9:12 PM, Alexander Shmelev wrote: I cut off code after [self window], originally it looks like following: I suspected that you might have. In the future, please indicate this more clearly. I tried to call [NSWindowController window] outside init, but it fails. Where and when did you make that call, and what do you mean with "fails"? Returns "nil" instead of the window? Then I tried to replace NSWindowController and initWithWindowNibName with NSObject and [NSBundle loadNibNamed:owner:] but it fails too. I tried to use NIB 2.x instead XIB 3.x, but it still fails. Again, what does "fail" mean here? Have you made sure to connect the window outlet from the window controller to the window in the nib file? That's a *very* common source of problems. In my experience window controllers are very robust and predictable. I'm surprised to hear that you have problems. I suspect that we will figure out what's wrong, and that you will be able to fix it easily and then move on. 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 [EMAIL PROTECTED]
Re: -[NSWindowController window] fails
On Nov 28, 2008, at 2:06 AM, Alexander Shmelev wrote:
I have NSWindowController which loads nib with following code:
- (id) init
{
if (![super initWithWindowNibName:@"Dialog"])
return nil;
[self window];
}
I use [self window] to force nib load. This code perfectly works on
Leopard(Intel), but [self window] fails if I run it on Tiger(PPC) -
code after [self window] is not executed.
You don't have any code after [self window], so that's to be
expected... ;-)
Jokes aside, you need to "return self;" at the end of the method. You
should have a compiler warning / error about that.
I also agree with Kyle that calling [self window] in init is probably
not what you want to do. It might not even be "safe". In general you
should be very careful about calling methods on self from your
initializer. Consider this as something you need to be almost as
careful and respectful around as thread safety. Before you have
returned from your initializer your object is not to be considered
fully initialized, and therefore in the general case not "ready for
action".
It's better to call "-showWindow:" on the window controller after it's
been initialized.
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 [EMAIL PROTECTED]
Re: Which Mac models use the new 64-bit Objective-C ABI?
On Nov 20, 2008, at 6:50 AM, Påhl Melin wrote: If I were to require the use of the 64-bit ABI in my next project, which mac models would the application run on? All currently shipping Macs are 64-bit capable. The Mac mini was the last one to be updated, in August of 2007. And is it possible to detect at runtime if I'm running the old 32- bit ABI or the new 64-bit to enable a fallback on non-64-bit models? Your choice of ObjC runtime is made at compile time, not at runtime. It's easy to target both 32-bit and 64-bit though, using the standard multiple architecture support provided by Mac OS X and our developer tools. For more information, see the 64-bit transitioning guides. 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 [EMAIL PROTECTED]
Re: Outlets / IBOutlet declarations (was Re: InterfaceBuilder &Wiring Objects)
On Nov 19, 2008, at 4:55 PM, Jeff Laing wrote: Well, that's sort of my point, really. I don't *know* what happens inside the *synthesized* code, the only thing I can do is look to Apple who do and what they've said in the past is "don't do it". Not "its not safe". So I don't think I can make my own mind up - Apple has made it up for me, without explicitly telling me what the decision was, only hinting at it. I think that's being overly defensive. Synthesized accessors will be straight forward and minimal. They're not the problem. The problem is fancy extra special stuff that we often add to manual accessors. 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 [EMAIL PROTECTED]
Re: Autorelease Question
On Nov 19, 2008, at 4:24 PM, Kyle Sluder wrote: What prevents someone from manually running the runloop? Nothing, but that wouldn't still create the problem that you proposed. Autorelease pools are stacked. Popping the autorelease pool for the inner runloop wouldn't have any effect on the autorelease pools higher up in the stack. 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 [EMAIL PROTECTED]
Re: Outlets / IBOutlet declarations (was Re: Interface Builder &Wiring Objects)
On Nov 19, 2008, at 3:05 PM, Ricky Sharp wrote: Now, when you say "call through your properties in init/dealloc", is that explicitly for things set up with @property? Or, has what I've been doing all these years with calls to accessors in init/dealloc really "bad"? There's no difference between setting through a property, and setting through a plain old setter method. That said, it's up to you to decide if you want to go with the official recommendation or not. If you think that you have enough control over the implementation of your accessor methods, you might choose to still use them. 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 [EMAIL PROTECTED]
Re: Outlets / IBOutlet declarations (was Re: Interface Builder &Wiring Objects)
On Nov 19, 2008, at 2:22 PM, Brian Stern wrote: That is indeed correct. The official guideline is, AFAIK, to not call through your properties in init / dealloc. For whatever reason UIViewController sets its view property to nil from its dealloc method. Greg's override of setView is based on this behavior. Please file bug reports whenever you find that our sample code and documentation are in conflict! <http://developer.apple.com/bugreporter/> Thanks, 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 [EMAIL PROTECTED]
Re: Outlets / IBOutlet declarations (was Re: Interface Builder &Wiring Objects)
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote: My understanding (and I'm a noob in this) is that "best practices" recommend that you shouldn't start sending additional messages to an object from inside its dealloc. That is indeed correct. The official guideline is, AFAIK, to not call through your properties in init / dealloc. Anyone want to clarify if it is/isn't safe to do this? Certainly most of the samples I've seen go out of their way to release instance variables rather than nil properties, in their dealloc's What makes it unsafe is that you might not control the implementation of the property setter method - A subclass could for example override it and make it not safe for use from init / dealloc. That said, this might be something that the LLVM static analyzer could validate for us to the point where it would be OK. 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 [EMAIL PROTECTED]
Re: Question about interface builder
Dear Cocoa-Dev, // You should use IB whenever and wherever you can // It's often the case that developers new to the platform think that they have to write their UI in code. Perhaps because UI design tools on other platforms doesn't work as well as they should? Please note that Cocoa developers use IB wherever they can, and only fall back to constructing their UI in code where they have to. This holds true for all types of Cocoa apps, from the very small to the very large. Interface Builder is not used only by beginner programmers, or for small projects, it's used by everyone and everywhere. // IB doesn't do anything that you can't do in code // Anything that can be done using IB and nib loading can be done programmatically at runtime. Creating your UI programmatically is always possible, it just takes more time and effort to both write and maintain that code. Note that the opposite isn't true (of course). There are some things that you can't do in IB, that you have to do programmatically. // IB doesn't always work like other UI design tools // If the use of inspector panels and drag operations seems strange, it's probably because you're new to Mac OS X. If you're surprised that you can't double-click to edit the action of a button, it's probably because you're new to the design patterns used heavily in Cocoa, in particular MVC. It's very likely that the fact that IB isn't a code generator has *nothing* to do with why it works differently from other UI design tools. IB is awesome, but of course not perfect. Feedback from developers are always much appreciated: <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 [EMAIL PROTECTED]
Re: Question about interface builder
On Nov 17, 2008, at 4:02 PM, Kyle Sluder wrote: My point is that this isn't the case. Avoiding IB has been shown to introduce subtle bugs. Like what? I know of one thing that's currently difficult to do in code: Setting up the main menu. Difficult yes, but not impossible. Should this be fixed to be fully supported and robust? Of course. If you care about this, I'd suggest that you file bug reports. 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 [EMAIL PROTECTED]
Re: Question about interface builder
On Nov 17, 2008, at 3:23 PM, Kyle Sluder wrote: I'm wondering if Apple's doing a good enough job explaining how IB is different from UI code generators and why it is important that one use it. I don't agree that it's somehow more important for Cocoa developers to use an UI design tool, compared to developers using other development environments. Cocoa developers, much like developers on other platforms, can always choose not to use the designer, if they'd rather spend their time cranking out and maintaining UI configuration code than business critical code. Also note that Microsoft has moved away from code generation with their recent WPF designers that uses XML for storage. 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 [EMAIL PROTECTED]
Re: Blue default button style hangs.
On Nov 12, 2008, at 10:45 AM, Russ wrote: I'm trying to get the blue default button style to show up. It's NSMomentaryPushInButton with NSRoundedBezelStyle. I have it set as InitialFirstResponder. Works fine to start with. But if I setKeyEquivalent:@"\r" on it, or take its parent (modal) window and setDefaultButtonCell:[btn cell] on it, then the window hangs when it opens It waits on a semaphore in NSViewHierarchyLock from the view and windows's displayIfNeeded code, all from within the runModalForWindow. What thread is this being run on? Do you have a run loop? 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 [EMAIL PROTECTED]
MEETING: CocoaHeads Nov 13: Intro to iPhone SDK
As announced on Theocacao: <http://theocacao.com/document.page/597> = Michael Jurewitz, Apple's Developer and Performance Tools Evangelist, will presentIntroduction to iPhone Development at CocoaHeads Silicon Valley this Thursday, November 13 at 7:00pm. This meeting will be at Intuit (Quicken/QuickBooks) headquarters in Mountain View. Michael is graciously sharing some of his time with us between stops on Apple's iPhone Tech Talk World Tour, so we'd love to have everyone come out and show support for the group this Thursday night. Our typical meeting places have been undergoing a number of rearrangements, so we're very thankful to Intuit offering to host us this month. This likely will not be our typical location in the future, but I'm personally always up for a field trip. Inuit is located at 2535 Garcia Ave in Mountain View, and our location is the Darwin room in Building 1 (sorry for the lack of map here). We're not allowed to record video or audio for this event, so if you want to see it, you have to come down in person. See you there. = And, don't forget NSCoderNight in Campbell tonight! Cheers, 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 [EMAIL PROTECTED]
Re: Responder Chain & Multiple Windows
On Nov 10, 2008, at 9:00 AM, Todd Heberlein wrote: Oops. Yes, MyDocument is a subclass of NSDocument and BrowserViewController is a subclass of NSWindowController ...should probably be called "BrowserWindowController" in that case...:-) In MyDocument I have a method that has the following code: BrowserViewController* bvc; bvc = [[[BrowserViewController alloc] init] autorelease]; // init loads NIB [self addWindowController:bvc]; [bvc showWindow:self]; Both MyDocument and BrowserViewController implement the method (which is the action for the menu item): - (IBAction) extractAuditSession: (id) sender; But the menu item is only available when the window associated with MyDocument is key. When the window associated with BrowserViewController is key, the menu item is dimmed out. What if you make the window controller the delegate of the window? 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 [EMAIL PROTECTED]
Re: Crash in NSFileManager
On Nov 8, 2008, at 9:59 PM, David wrote: I am using NSFileManager on a secondary thread. I am using the defaultManager. But during this processing its hard to imagine how the primary thread could possibly be using the defaultManager. Isn't the potential issue with NSFileManager that having two threads use it at the same time can cause problems. If only one thread uses it, that shouldn't cause a problem should it, even if its the secondary thread? If you're using the defaultManager instance you can't necessarily know if / when someone else is using it. Cocoa itself my access the defaultManager. You have to alloc+init your own instance if you need to use NSFileManager from background threads. That's super easy, so why not? I can't see why it wouldn't be safe to pass a single, non-shared, instance of NSFileManager between threads if you can ensure that it's only ever used by one thread at a time. Not sure why you would need to do that though. Stepping back... what I'm trying to do is copy a mess of files which is time consuming, while allowing the user to cancel. Currently a put up a window showing a progress indicator and allowing them to cancel. If they cancel I set the cancel flag for the background thread. What is the best design approach in Cocoa for this type of scenario? What you're already doing sounds fine. Should I avoid using a background thread and do all the processing via the run loop? I assume I'd then chunk the processing so that I copy one file at a time in some method invoked off the run loop, while allowing the UI to continue to run and cancel, setting some flag I check. No, you should use a background thread. Trying to perform the work piecemeal on the main thread will result in a bad user experience. 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 [EMAIL PROTECTED]
Re: Xcode 3.1 (iphone SDK version) breaks my Core Data app
On Nov 7, 2008, at 9:28 PM, Steve Steinitz wrote: When the app starts up it gives the following (not sure if its a problem, I've just never seen it before): GuardMalloc: Allocations will be placed on 16 byte boundaries. GuardMalloc: - Some buffer overruns may not be noticed. GuardMalloc: - Applications using vector instructions (e.g., SSE or Altivec) should work. GuardMalloc: GuardMalloc version 18 You have enabled GuardMalloc in Xcode. If you don't know what it is, you probably want to disable it again. See: Xcode > Run > Enable Guard Malloc 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 [EMAIL PROTECTED]
Re: Skinny NSPanel titlebar for NSWindow?
On Nov 7, 2008, at 7:03 PM, Russ wrote: At the moment, I only have sendEvent reworked (to fix mouseMoved), so a separate iteration for NSPanel wouldn't be a big problem. It just seemed I should be able to turn on a style bit and call it a day though, since presumably that is what NSPanel is doing. Why would mouseMoved needs fixing at the window level? What problem were you trying to solve when you created your window subclass? I'm not asking to put you on the spot, but rather to figure out if there's some other, possibly even better, way to do this in Cocoa. Cheers, 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 [EMAIL PROTECTED]
Re: Skinny NSPanel titlebar for NSWindow?
On Nov 7, 2008, at 5:51 PM, Russ wrote: I'd like to be able to create NSWindows with the skinny titlebar of NSPanels, programmatically, without having to use NSPanel --- I've subclassed NSWindow, so if I need to create an NSPanel instead I'll have to have a duplicate subclass for the panel, which gets ugly. Why do you need a subclass of NSWindow in the first place? 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 [EMAIL PROTECTED]
Re: How to get a list of all known file types?
On Nov 6, 2008, at 4:21 PM, Chris Idou wrote: Sure, I read it. Can you see an API giving all known file types? Can you see a mention of human readable descriptions? I can't, but it wouldn't be the first time I have selective blindness. I don't know the answer to the former, but the human readable description would be returned by: UTTypeCopyDescription() What is the problem that you're really trying to solve here? It might be that there is a better way of going about what you're trying to do. 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 [EMAIL PROTECTED]
Re: How to get a list of all known file types?
On Nov 6, 2008, at 4:00 PM, Chris Idou wrote: How does one obtain a list of all the UTI file types known to the system? And then for a given UTI, how does one obtain a human readable representation of it? Have you checked here? <http://developer.apple.com/macosx/uniformtypeidentifiers.html> <http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/chapter_1_section_1.html > 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 [EMAIL PROTECTED]
Re: Lack of Initializers or Factory Methods
On Nov 3, 2008, at 8:37 AM, Michael Ash wrote: If the method is declared like this then you should assume that you get a subclass: + (id)foo; And if it is declared like this then you should not assume that: + (Foo *)foo; The difference being the return type. The 'id' return type implicitly means "this will return whatever is appropriate for the receiver". (This should probably be documented better.) The 'Foo *' return type tells you only to expect a Foo, and not rely on receiving any sort of subclass. The latter form is rare in Cocoa but shows up in e.g. NSParagraphStyle. My understanding is that that this is the general pattern to use: * Return (id) from initializers, and convenience factory methods. * Return (Foo*) for shared instances. There are some exceptions to these "rules" in Cocoa, but they are few and far in between. Note that "+[NSParagraphStyle defaultParagraphStyle]" fits this pattern, since it returns a shared instance. 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 [EMAIL PROTECTED]
Re: windowDidExpose: When called?
On Oct 31, 2008, at 8:23 AM, Claus Atzenbeck wrote: I need a delegate that gets called whenever the window appears on the screen. The opposite of windowWillClose:, so to say. However, - (void)windowDidExpose:(NSNotification *)notification does not get called via any of the following methods: [windowController showWindow:self]; [[windowController window] orderFront:self]; [[windowController window] orderBack:self]; The delegate works; for example, windowWillClose: gets called. I think that you will need to use NSWindow / NSPanel subclasses to accomplish this. That's at least how I've solved that problem in the past. If you'd like to see this capability added to NSWindow, I suggest that you file an enhancement request. It will be flagged as a duplicate, but it would still be useful - by showing interest, it's more likely that it will be prioritized. 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 [EMAIL PROTECTED]
Re: Silicon Valley CocoaHeads ... ?
On Oct 30, 2008, at 2:10 PM, Jay Reynolds Freeman wrote: Excuse me wasting bandwidth, but I have the impression that the Silicon Valley CocoaHeads group is dead or at least catatonic at the moment, and thought I would double-check by asking here ... Sorry for the delay. The lack of events recently is not for lack of trying, there has just been a number of unfortunate roadblocks. We're hoping to have a new event in the next couple of weeks. Stay tuned. And yes, the CocoaHeads mailing list is probably better for questions like this one. 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 [EMAIL PROTECTED]
Re: Mutable arrays
On Oct 19, 2008, at 10:11 PM, Graham Cox wrote: Since mutable arrays and dictionaries expand as required when new objects are added, when should one use -initWithCapacity: methods? I'd guess they're only worth using if you know you are about to populate one with a lot of items and the performance hit of letting them grow "naturally" is worth avoiding. There may also be private classes within the cluster that are optimised for certain numbers of objects, so this will act as a hint as to which one should be used. My suggestion would be to never use the "-initWithCapacity:" methods unless you know that you have a good reason for using them. I would expect that in at least 99% of the times that you use collections there is no measurable difference in performance between using "- initWithCapacity:" over regular "-init". Some general suggestions for best practices wrt. optimizations: 1) Measure first 2) Implement supposed optimization 3) Measure to see the impact of the code change 4) Based on the result of #3, either scrap your changes, or document the optimized code Skipping over step #1 and #3 is always a mistake - It's almost always the case that you'll end up surprised by what you find! We also often forget to do #4, something that typically leads to maintenance problems later on. 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 [EMAIL PROTECTED]
Re: Instruments leaks.
On Oct 11, 2008, at 9:31 PM, Sandro Noel wrote:
for instance, the leek tells me that i have a leek here in this
functions.
So this is actually not really true. What leaks will initially tell
you is where the leaked object was created. That's not the same thing
as where that object was leaked. Leaks can't tell you exactly where
the object was leaked, unfortunately. What it can tell you though, is
all the places where the object was retained & released (and
autoreleased). Using this information, you can typically figure out
where you retained some object when you shouldn't have, creating a leak.
Example:
- (NSString *) giveMeAString {
// String created here. No memory management error at this
point.
return [NSString stringWithString: @"A String"];
}
- (void) someMethod {
NSString *aString = [self giveMeAString];
[aString retain]; // String retained here, but never subsequently
released. This is a leak!
}
Notice how the string is created in one place, but how the actual
memory management error that leaks that object happens elsewhere.
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 [EMAIL PROTECTED]
Re: Instruments leaks.
On Oct 11, 2008, at 8:45 PM, Sandro Noel wrote: most of the leeks are created by NSString's from functions i gathered off the net. assignations like var1 = [var1 message]; This created a leek because the string being replaced is never released. or am I wrong. You need to provide a bit more information: Is "var1" an instance variable or local variable? How was the original value of var1 assigned? Is the object returned from "-message" autoreleased? Can you provide more code from the actual implementation? 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 [EMAIL PROTECTED]
Re: Instruments leaks.
On Oct 11, 2008, at 7:58 PM, Sandro Noel wrote: I'm in the optimizing phase of my little project and I'm trying to understand instruments to get most of the leeks out of my software. but instruments throws tons of leaked blocks for objects that should be auto-released, and objects that are still in use. how do I determine what is a leek and what is not ? Put a log statement in their dealloc methods to verify that they're actually being deallocated. NSLog(@"Dealloc: %@", self); False positives from Leaks should be rare, but I'm sure that it can happen. 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 [EMAIL PROTECTED]
Re: Strategy for naming support folder
On Oct 10, 2008, at 12:06 AM, Kyle Sluder wrote:
Preference files are opaque; the user's interaction with preference
files should be (ideally) through the app's UI or through the
`defaults` tool. There are legitimate use cases for accessing the
Application Support folder through the Finder, if the files therein
are meant to be treated as such (plugins come to mind). Ideally such
circumstances should be infrequent and well-defined; most interaction
with Application Support should probably be done with app-specific UI
instead.
Can you give a concrete example? I would argue that you're doing
something wrong if you ask your user to muck around in ~/Library.
There are better ways of solving the plugin problem - as demonstrated
by both System Preferences and Dashboard.
(As a side note, I'm not a fan of the naming scheme used for
preference files. The hierarchical naming scheme used for preference
files is merely conventional; they don't factor into the defaults
hierarchy at all. The system also provides no conveniences just
because there's a plist file whose name matches your app's bundle
identifier.)
I'm not sure that I get what you're saying here, but I think I have to
disagree: The functionality of NSUserDefaults is directly tied to your
bundle identifier.
The name is also not as stable as the bundle identifier. The name
of the app
could, for example, be localized in the Finder. The name of many
apps also
include a variable suffix, like a version number, " Lite", et.c.
So? There's no mandatory correlation between an app's name and where
it looks in Application Support. There's nothing preventing BBEdit
Lite.app, for example, to look in both ~/Library/Application
Support/BBEdit{, Lite}. Version numbers probably shouldn't be used in
the app's name anyway.
My comment was not on how the application itself would find it's
support folder. You suggested that using the name of the bundle would
make it easier for the user to find the support folder, and I argued
that this is not always the case - in particular for localized versions.
You're going to be hardcoding the name of the folder anyway, whether
that hardcoding happens to be in the form of a string in your source
code or the CFBundleIdentifier in your Info.plist. Why needlessly
inconvenience the user when you derive no benefit?
I don't agree. Using a predictable, rather than arbitrary, naming
scheme for auxiliary resources benefits everyone. I also get the added
benefit of having a unique name for my support folder, avoiding
potential collisions.
I don't think that we need to take this any further though. Let's just
agree to disagree.
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 [EMAIL PROTECTED]
Re: Strategy for naming support folder
On Oct 10, 2008, at 12:02 AM, Rob Keniger wrote: This might be true but I have a lot of apps installed (more than 250, not counting the Apple pre-installed apps) and the count of those that use a bundle identifier as the name of their folder in the ~/Library/Application Support folder is precisely zero. I never claimed that my opinion represents what is in use, quite the opposite: See my original reply in this thread. I'm arguing for what I consider to be *better*. 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 [EMAIL PROTECTED]
Re: Strategy for naming support folder
On Oct 9, 2008, at 11:16 PM, Kyle Sluder wrote: The user might have very legitimate reason to play with things in ~/Library/Application Support. As such, I'd hesitate to confuse the user with weird names. In the worst case, the user might delete the folder in confusion. Your app's bundle isn't named with a reverse domain name, so I wouldn't do it for the Application Support folder either. The same thing could be said about preference files too though, and they're stored using the bundle identifier per default. The name is also not as stable as the bundle identifier. The name of the app could, for example, be localized in the Finder. The name of many apps also include a variable suffix, like a version number, " Lite", et.c. Finally, ~/Library is for all intent and purposes off limits for "normal" users, ie. the type of users who would be confused about a bundle identifier. 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 [EMAIL PROTECTED]
Re: Strategy for naming support folder
On Oct 9, 2008, at 5:21 PM, Graham Cox wrote: I'm thinking of using my main bundle's identifier or the application name to name the top-level folder, then maybe have a few subfolders within there for specific types of files (such as document templates). Is that a good idea? What do others do? Most apps use just the name, but I've never liked that and I support your idea of using the bundle identifier. Makes a lot of sense. 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 [EMAIL PROTECTED]
Re: Finder Crashes on File Open
Hello Brian, I hope that you've filed a formal bug report? If not, that should be your first priority in a case like this: <http://developer.apple.com/bugreporter/> Thanks, j o a r On Oct 9, 2008, at 10:47 AM, Brian Miller wrote: I have a Cocoa Core Data Document based application. When files created with this application are opened via the Finder (or double clicked), the Finder crashes and restarts every time. Opening files from within the application work fine, using Open With works fine. The Finder crashes before the application is launched. This happens even on a clean Leopard install. This only happens on Leopard, works fine in Tiger. I have changed store types to SQL, etc. problem persists. I have changed extension, etc. and problem persists. I am including Finder Crash report, I can provide other info as needed. Since my app doesn't launch, I can't figure out what is going on. Any help would be greatly appreciated. ___ 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 toolbar use validation and not enable/disable?
On Oct 8, 2008, at 7:56 AM, Nick Zitzmann wrote: Why does toolbar use validation and not enable/disable like most every other Cocoa control does? It doesn't seem "consistent". Really? Menu items also use validation. Indeed. Note that automatic validation can also be turned off, just like for menu items. 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 [EMAIL PROTECTED]
Re: defaultCenter's addObserver
On Oct 7, 2008, at 12:03 PM, John Love wrote: 2008-10-07 14:36:14.149 Calculate Medical[265:10b] *** -[NSCFSet calcStatusChanged:]: unrecognized selector sent to instance 0xe41f250 John, This type of error message indicates that your notification observer has been deallocated. This would probably be because you forgot that you have to remove notification observers before they are deallocated. In many cases you would put your unsubscribe statement in your dealloc method. It could also indicate any other type of memory management error. NSZobieEnabled is the general facility for troubleshooting that type of problem, but in this case you could probably do with simple code inspection. 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 [EMAIL PROTECTED]
Re: defaultCenter's addObserver
On Oct 7, 2008, at 8:26 AM, John Love wrote: So just for whatever, I pass object:nil to addObserver:selector:name:object:. Then, within my selector I test for the type of passed encapsulated object and something(?) doesn't work. My selector gets called for my first new MyDocument. But when I open up a second new MyDocument, the Debugger complains about an invalid aSelector. I don't understand what's going on, so I'm looking for help. Please provide the exact error from the debugger. My guess would be that you have some sort of memory management error, or that you didn't provide the correct selector (Note that a ":" at the end of a method name is significant, and needs to be included in the selector). 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 [EMAIL PROTECTED]
Re: Memory Leak in XIB file?
On Oct 4, 2008, at 12:29 PM, Jens Beuckenhauer wrote: I have created a project in that I found a memory leak. The leak seems to be located in a XIB file?!? In the XIB file 'MainView' is an ImageView that shows an image file (TIFF file) that is set via the IB inspector panel. In no way is the ImageView connected via an outlet or action with any of my classes. If I delete this ImageView the only memory leak in my project is gone. You mention that you've found a memory leak, but not what type of memory / object that you're leaking. Could you clarify? It would also be interesting to know how you find memory leaks. 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 [EMAIL PROTECTED]
Re: Cocoa Programming iPing exercise
On Oct 2, 2008, at 8:12 AM, Jack Carbaugh wrote: could it be that [hostField stringValue] is not an object ? isn't "stringValue" just a value ? That doesn't seem likely. In all likelihood the "hostField" variable points to a NSTextField, in which case "stringValue" returns an instance of NSString. 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 [EMAIL PROTECTED]
Re: NSString's "mutableCopy" creating a leak?
On Oct 1, 2008, at 1:16 PM, Christopher J Kemsley wrote: I was not aware that I shouldn't explicitly call a dealloc... Why not? Replacing it with a "release" in the object made that leak go away, but I still don't understand why I can't dealloc it. I would suggest that you read the memory management documentation. Any answers you get here can't serve as a substitute for reading and understanding the official documentation. Explicitly calling dealloc is in direct conflict with the reference counting scheme used by Cocoa. Dealloc should only be called implicitly, ie. not by you, as the retain count of an object reaches zero. 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 [EMAIL PROTECTED]
Re: NSString's "mutableCopy" creating a leak?
On Oct 1, 2008, at 12:57 PM, Christopher J Kemsley wrote: I neglected to mention in my original post that, when this object is deallocated, it explicitly deallocated the editedRowName before calling a [super dealloc], so the thing should be deallocated. By that I hope you don't mean that you're explicitly calling "- dealloc"? You shouldn't. On Oct 1, 2008, at 12:34 PM, Christopher J Kemsley wrote: However, when I do a "Run with performance tool: Leaks", it tells me that, ever time this part of the code runs, it leaks a "GeneralBlock-32" with the following information: Category: CFString (store) Event Type: Malloc Responsible Library: Foundation Responsible Caller: -[NSCFString mutableCopyWithZone:] Does anybody know where this leak is coming from? Note that this is the allocation site for the leaked object. That is not necessarily the same thing as the place where you introduced the memory management error that is the reason for the leak. If you use Instruments to inspect the individual memory management events for this object you'll likely see a number of retains, release, and autorelease operations. You'll have to figure out where a unbalanced call is introduced. 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 [EMAIL PROTECTED]
Re: [NSCFNumber intValue]: unrecognized selector
On Sep 26, 2008, at 4:36 PM, Steve Rossi wrote: Yes, that is correct. A separate thread is spawned which updates the model - consequently driving UI updates based on KVO notifications. It is the only thread that is updating the model - the main thread does very little except respond to fairly minimal UI events. It works very reliably it seems ... except on these occassions when the OpenPanel is opened from the main thread. That might appear to be the case on your machine, on this version of your application, and on this version of Mac OS X - But as soon as you change any of these variables, it might well start to fall apart. I can think through whether I really need that separate thread. But is there a way to make the model updates from the 2nd thread safe? If you're doing blocking work, having it on a separate thread is probably a good thing - But you need to forward your UI updates to the main thread. That's typically easy to do using "performSelectorOnMainThread:" 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 [EMAIL PROTECTED]
Re: sending email with attachement from cocoa
On Sep 26, 2008, at 10:03 AM, Alexander Cohen wrote: Is there a way to use a url request to open mail with all its fields completed but most importantly, contain an image attachement? Not using the frameworks provided by Apple. Your problem, in particular, is that you can't assume that all users are running the same email client. There are some third party attempts at solving this problem -> Google. 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 [EMAIL PROTECTED]
Re: [NSCFNumber intValue]: unrecognized selector
On Sep 25, 2008, at 6:22 AM, Steve Rossi wrote: I've deduced that he crash seems to be something timing related which occurs only at application startup, and only under certain conditions (i.e. reproduce occassionlly by opening an NSOpenPanel modal dialog before the application is fully up and running). When I say the application is fully up and running, I mean a secondary thread has retrieved data from a network source and populated a model class. This secondary thread cyclically updates the data about 8x per second by means of a timer in the secondary thread's run loop. I use Cocoa bindings to display the data in the UI. I'm sure the problem is happening in the bindings, but I'm having trouble finding where. In the general case, and with few exceptions, you can't call your UI on non-main threads. This means that you can't drive UI updates based on KVO notifications from non-main threads. Could this be your problem? 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 [EMAIL PROTECTED]
Re: unrecognized selector sent to instance
On Sep 25, 2008, at 4:01 AM, pan xuan wrote: Hi, I am having a strange problem of my class declaration. I used to declare some methods of a class in a category, "Private". After I have done some refactoring work (basically moving some classes into another framework), it seems those methods declared in the category, "Private" do not belong to the object anymore. If I load the code in my debugger and try to invoke a method declared as "Private", the program receives a doesNotRecognizeSelector error and crashes after receiving the signal SIGTRAP. And if I move those methods into the main implementation of the class, it all works out. Any idea why is that? Thanks for your help. BR, Pan Perhaps a memory management error somewhere? Try to run your app with NSZombieEnabled (Google for the details) and see what that turns up. 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 [EMAIL PROTECTED]
Re: How to create a new window initially zoomed to the maximal size?
On Sep 20, 2008, at 11:11 AM, Benjamin Stiglitz wrote: Alternatively, you can set its frame to [[window screen] defaultFrame], which is the same frame that -zoom: will use, subtracting space for any visible drawers. I think that should be: "-[NSScreen visibleFrame]" 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 [EMAIL PROTECTED]
Re: How to create a new window initially zoomed to the maximal size?
On Sep 20, 2008, at 11:02 AM, Oleg Krupnov wrote: What I want to achieve is that when a new window is created, it has the maximal size allowed by the screen, menu and the dock, exactly like if someone clicked the green zoom button in the window's title bar. I don't want any resizing animation or flickering though. You would have to resize the window manually. To find out how to size and position it, ask NSScreen for the appropriate frame. To avoid flickering, do this in "awakeFromNib" or similar, before the window is put on screen. 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 [EMAIL PROTECTED]
Re: NSUInteger in for-loop?
On Sep 14, 2008, at 9:15 PM, Alex Reynolds wrote:
I'm wondering if I'm using unsigned integers (specifically
NSUInteger) properly or not.
I was under the impression that unsigned integers run from 0 to
MAX_INT, but when I use them in a "for" loop within these bounds,
the loop does not seem to always obey these constraints.
For example:
for (NSUInteger counter = 5; counter >= 0; --counter)
{
NSLog(@"NSUInteger: %d", counter);
}
keeps running well after the "counter" variable turns negative:
NSUInteger runs from 0 -> NSUIntegerMax.
This is how you print a NSUInteger:
NSLog(@"NSUInteger: %lu", ((unsigned long)counter));
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 [EMAIL PROTECTED]
Re: when should my NSWindowController be released?
On Sep 13, 2008, at 1:43 PM, Markus Spoettl wrote: Not true, I can think of many scenarios where you have no other choice. Like what? Seth is right in general, app termination is very much a special case. 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 [EMAIL PROTECTED]
Re: NSDate autorelease problem
On Sep 3, 2008, at 10:02 AM, [EMAIL PROTECTED] wrote:
I'm trying to calculate the elapsed time by calling this twice and
getting the difference.
double Seconds()
{
return [[NSDate date] timeIntervalSince1970];
}
How about replacing that with:
return [NSDate timeIntervalSinceReferenceDate];
That said, I would bet that there are simple C APIs that would be more
efficient to use for this purpose.
This is being called from an audio play back proc which is being
called about 100 times a second. I'm getting this error message in
the log window a whole bunch of times.
2008-09-03 09:39:30.766 App[321] *** _NSAutoreleaseNoPool(): Object
0x36acd0 of class NSCFDate autoreleased with no pool in place - just
leaking
The reason is that you're executing the code above on a non-main
thread. See the documentation for NSAutoReleasePool for details (or
just use Google), but in general:
"Cocoa expects there to be an autorelease pool always available. If a
pool is not available, autoreleased objects do not get released and
you leak memory. NSAutoreleasePool objects are automatically created
and destroyed in the main thread of applications based on the
Application Kit, so your code normally does not have to deal with them."
On threads that you set up, you have to manage the top level
autorelease pool manually.
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 [EMAIL PROTECTED]
Re: Creating movie on background thread
On Sep 2, 2008, at 1:14 AM, Roger Herikstad wrote: But I do need the Carbon headers to use the functions AttachMovieToCurrentThread, DetachMovieFromCurrentThread, etc, no? It doesn't seem like that's the case: "With Mac OS X 10.5 and QuickTime 7.3 or later installed, QTKit provides the framework level support that is required to use QTKit objects on background threads. This includes the ability to tell QTKit when you want to use a QTMovie instance on a background thread, when you're attaching or detaching a QTMovie instance from the current thread and also allows control of the QTMovie idle state." <http://developer.apple.com/technotes/tn/tn2125.html> I'm not an expert on this - you might want to consult a QT specific mailing list for a definitive answer. 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 [EMAIL PROTECTED]
Re: Creating movie on background thread
On Sep 2, 2008, at 12:55 AM, Roger Herikstad wrote: Since the Carbon stuff is not 64 bit Not correct: Some of it is, some of it isn't. Read the API reference documentation and release notes to figure out which is what. Besides, QTKit is a Cocoa framework. 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 [EMAIL PROTECTED]
Re: What to use observeValueForKeyPath: context
On Aug 29, 2008, at 9:56 AM, Michael Ash wrote: It really just needs to be unique in your class hierarchy, right? True, but not particularly useful. Your class hierarchy includes NSObject, which is free to observe whatever it feels like in your objects. No this is not generally true, so just forget about that and instead ensure that the context pointers are globally unique. If you use a constant string, you should make sure that the string *contents* are unique, in order to ensure uniqueness of the pointer to it. So don't call it @"context", use @"MyFunkyClass KVO observer context". After all there's no penalty for being verbose in this case. Of course using a pointer to a global solves this too. The penalty for using constant strings is that they will end up wasting space in your binary... Rons suggestion is probably optimal. 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 [EMAIL PROTECTED]
Re: Undocumented Leopard support for overlapping sibling views
On Aug 28, 2008, at 1:28 PM, Nathan Vander Wilt wrote: According to two list postings (http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01760.html,http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01764.html ) both by Apple employees, overlapping sibling subviews are fully supported in Leopard (and presumably beyond). However, the official documentation (http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/WorkingWithAViewHierarchy/chapter_5_section_5.html ) still says: "Cocoa does not enforce clipping among sibling views or guarantee correct invalidation and drawing behavior when sibling views overlap. If you want a view to be drawn in front of another view, you should make the front view a subview (or descendant) of the rear view." And Interface Builder 3.1 on the one hand has options like "Layout > Send to Front" that change the ordering of subviews, yet on the other still warns about "Illegal geometry" when a view overlaps one of its siblings even when the deployment target is set to 10.5. I can't find anything in the documentation (or even release notes) that describes that/how overlapping views are supported. Why isn't this documented? Can we rely on overlapping sibling views working now and in the future? Are there any caveats we should be aware of? Hello, Please file a couple of bug reports on this: <http://developer.apple.com/bugreporter/> Thanks! 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 [EMAIL PROTECTED]
Re: NSWindowController, owner, "primary window"...
On Aug 21, 2008, at 10:12 AM, Negm-Awad Amin wrote:
Probably because the GoF prefers combination over (?) subclassing.
Subclassing always discloses parts of the implementation of a class.
("white-boxing") So generally it is a good idea, to look for
alternatives for subclassing, esp. delegates.
You are right in that Cocoa programmers often look to other design
patterns before choosing to subclass one of the framework provided
classes. That said, NSWindowController is one of the classes in Cocoa
designed and intended to be subclassed, so that's not a consideration
in this particular case.
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 [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 4:56 PM, John C. Randolph wrote: Personally, I prefer "if (!foo)" over "if (foo == nil)", because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at "if (foo = nil)" before you spot the mistake. There is a GCC warning to help you with that, but in addition, you can learn to type: if (nil == foo) Problem solved! :-) I personally much prefer to have if-statements that clearly evaluate to a boolean value. More intention revealing, and to me that's more important than being terse. 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 [EMAIL PROTECTED]
Re: passing an object between views
On Aug 19, 2008, at 5:31 PM, John Greene wrote: Hopefully this is a generic enough question that it applies to general Cocoa development: How do I pass an object between views? That is: I have an array of objects that I've built using NSXMLParser, and that populates a table, and clicking on a cell changes my view to another table with a separate controller. I had originally thought that I could just write a method, setTableData in the secondary controller, that takes an object as an argument, and then use that object to build the secondary table. This is apparently forbidden by the language, so what's the proper approach? I could make the array available somehow to the new controller, since I can pass the integer index, but I'm not sure how! It sounds like you might be trying to implement a Master-Detail Interface. Possibly. If so, you might have a look at this: <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Tasks/masterdetail.html > 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 [EMAIL PROTECTED]
Re: Question about respondsToSelector
On Aug 18, 2008, at 11:17 AM, Carmen Cerino Jr. wrote: Does the id type have enough information for the respondsToSelector method to work. I have a class with an ivar of type id, and when I invoke the respondsToSelector method it fails when it should succeed. I am assuming it should work fine, because if I skip checking with the respondsToSelector method and just make the call, it executes the method. Can someone please tell me what I am doing wrong? Perhaps you've misspelled the name of the selector - just like you've done above with "respondsToSelector:" (note the trailing ":"). 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 [EMAIL PROTECTED]
Re: Clearing a Memory Buffer?
On Aug 18, 2008, at 6:19 AM, Dave wrote: I'm fairly new to Cocoa and was wondering if there are OS functions to Copy and Clear/Fill Memory available? In addition to the lower level C API:s that have been mentioned so far, there is also the object oriented Cocoa NSData + NSMutableData API:s that might provide some / all of what you're looking for. 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 [EMAIL PROTECTED]
Re: @try @catch
On Aug 14, 2008, at 5:34 PM, Andrew Farmer wrote: Python has been optimized to handle exceptions quickly, so it's often faster to catch exceptions than to check for exceptional situations in Python code. Objective-C has not been similarly optimized*, so checking for errors before attempting operations will be much faster than catching exceptions unless the exceptions are exceedingly rare. *: Or, more accurately, the overhead of setting up exceptions is much higher compared to the overhead of checking for situations that would trigger them. The cost, and where you pay it, depends on many factors: The type of exceptions handler you use, and the version of Mac OS X and the version of the Objective C runtime you happen to execute on. That said, and has been pointed out earlier in this thread, the decision to use exceptions for control flow or not is not simply one, perhaps not even primarily one, of performance considerations. 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 [EMAIL PROTECTED]
Re: how to implement the auto-complement function like Xcode 3.x?
On Aug 12, 2008, at 8:24 PM, Leopard x86 wrote: Then here comes the question: how can we implement this function for our editor-like application? Because I am working on an editor project which concerns about the user experience, I think the auto-complement function is an indispensable one. Moreover, the Xcode-style of auto-implement is exactly what I want. This feature can improve the efficiency and productivity of users greatly. Have a look at the NSTextView "- textView:completions:forPartialWordRange:indexOfSelectedItem:" delegate method. 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 [EMAIL PROTECTED]
Re: Get specified window from nib
On Aug 11, 2008, at 8:08 PM, Fosse wrote: In fact, in my another application, there are more than one hundred windows.. split them into one hundred nib? and create one hundred Outlet? Seems a little too crazy! Over a hundred different windows seems a little crazy too ;-) If you describe your application, and your use of nib files, it might be that we could provide some suggestions for cutting down on that number. 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 [EMAIL PROTECTED]
Re: IKSlideshow Question
On Aug 5, 2008, at 5:37 PM, Robert McCullough wrote: The IKSlideshowDataSource protocol for IKSlideshow includes several optional methods, one of which is "nameOfSlideshowItemAtIndex". However, this method NEVER seems to be called. Anyone know why? I think that it's simply a bug - most likely a very well known bug. You might still want to file a bug report to indicate interest in getting this API fixed for some future release. 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 [EMAIL PROTECTED]
Re: observers removed?
On Jul 27, 2008, at 7:36 PM, James Maxwell wrote: Stupid question, probably, but if an object is deleted, is it automatically removed as an observer of notifications? Or should I write a removeObserver into my dealloc? If you're talking about NSNotification/Center, then the answer is: "It depends". If you're using GC, you wouldn't have to remove the observer. If you're not using GC, you would. 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 [EMAIL PROTECTED]
Re: NSMutableDictionary autorelease chrashes application
On Jul 18, 2008, at 11:51 AM, Andy Lee wrote: I don't see the difference from the caller's point of view. There isn't any, and that was not MMalcs point. His point was that you were using the term "autoreleased" incorrectly. 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 [EMAIL PROTECTED]
Re: just don't get it...
On Jul 17, 2008, at 2:24 PM, Nick Zitzmann wrote:
How on earth to I communicate with an object that has been
instantiated by Interface Builder???
Declare an IBOutlet pointer connecting an instantiated class to the
instantiated object. Then read the instantiated class's header file
into IB, which is normally done automatically, but you may have to
do it manually if you're working on a framework.
...but note that this is not how James would solve the concrete
problem mentioned in the original message.
In a document based application you don't have "the document", you
have any number of documents. The AppDelegate doesn't just want a
reference to any document, it's looking for some specific document.
Typically that would be the document associated with the "main
window" (check the documentation for more on what "main" and "key"
window is in Cocoa). You could find that document like this:
NSApp > Main Window > Window Controller > Document
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 [EMAIL PROTECTED]
Re: Attributed string to an Image without window
On Jul 16, 2008, at 9:59 AM, Nethan Aryan wrote: I have to write a command line utility which will create an image from another source image by adding some attributed text onto the source image. Before thinking about how you would implement this, you should read about the concept of "daemon-safe frameworks": <http://developer.apple.com/technotes/tn2005/tn2083.html#SECLAYEREDFRAMEWORKS > 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 [EMAIL PROTECTED]
Re: Blue lines
On Jul 15, 2008, at 5:31 PM, Andrew Thompson wrote: How do Interface Builder and Quartz Composer draw the blue line connections from object to object? I have been looking through the APIs, but I can't find anything that looks right. I thought of just drawing my own line on a custom view (shouldn't be that hard), but interface builder manages to do it between objects that aren't connected by ANY view, and I am not sure how to do that. IB probably uses one or more separate transparent windows to hold the connection lines. 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 [EMAIL PROTECTED]
Re: Problem on reload data source of a table view
On Jul 15, 2008, at 10:36 AM, JArod Wen wrote: The dataSource of TableView is connected to tableSource. There is a TableController containing two IBOutlets to both tableSource and dataTable. Then dataTable.dataSource is connected to tableSource in IB. Anything I lost here? You might want to verify, at runtime, that this connection is set. You can do this either in the debugger, or just using a standard debug log statement. Btw.: Have you set up any bindings for this table view? 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 [EMAIL PROTECTED]
Re: Problem on reload data source of a table view
On Jul 15, 2008, at 10:17 AM, JArod Wen wrote: Thanks for fast reply! Just as Jens said, I have checked the table and I am sure that it is not nil: Printing description of dataTable: (gdb) continue You should probably also verify that the NSTableView knows where to get data from - Using the "dataSource" property of the table view. At this point it sounds like a good thing to double-check that this connection is set up properly in IB. 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 [EMAIL PROTECTED]
Re: Importing Xcode 2.x projects into Xcode 3
On Jul 8, 2008, at 6:03 PM, John Joyce wrote: Are there any caveats when importing an XCode 2.x project into XCode 3? I seem to have NIBs that are no longer connected properly... It could be something I did (or did not do properly), but just curious if anybody else has had any issues. I think that would be considered a bug in IB 3, and not an expected side effect. If you can verify that this is the case, and in particular if you can reproduce the problem, you should file a bug report here: <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 [EMAIL PROTECTED]
Re: Newbie question: Timers
On Jun 30, 2008, at 2:36 PM, Matthew Youney wrote: In the VS environment, there is a “timer” control that can be dropped onto a form, and will generate timer events every X milliseconds. How would I impliment similar functionality in Cocoa, or what would you gurus suggest that I look into? What is best? There is no way to do that in IB, you would have to set up the timer in code, but that's easy enough - Check the documentation for the NSTimer class. What are you going to use the timer for? There might be something else that would be better for you to use in Cocoa. 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 [EMAIL PROTECTED]
Re: Responder Chain and NSViewController in non-doc applications
On Jun 30, 2008, at 9:52 AM, Jerry Isdale wrote: Again, the NSViewController doesnt appear in the responder chain, unless it was designated by the initial Event Responder. If it was designated, but doesnt respond, what happens? An Error or does it go back to the responder chain? I'm not clear on what you mean by "designated by the initial Event Responder". The NSViewController is a Responder, but the associated view does not patch it into the responder chain for either event or action responding. Correct? Correct. Unless you manually insert it into the responder chain, in that case typically right after its view. But if my design explicitly specifies the target (connecting IBActions in InterfaceBuilder), I dont have to worry about the Responder chain for actions. Correct? Correct. 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 [EMAIL PROTECTED]
