Re: Outline View not retaining objects it uses. Why?
On 20 Jul 2008, at 09:02, Ken Thomases wrote: On Jul 19, 2008, at 7:52 PM, Paul Sargent wrote: While you're right I would return different objects if I was called twice, I'm not. As I understand it the Outline View will only ask for objects when it knows the data has changed (e.g. after a reloadData or reloadItem call) at which point it needs to expect a different object. This is incorrect. An outline view is not expected to keep or manage the objects your data source returns to it. Your data source _is_ the cache of objects which the outlive view uses for that purpose. If the outline view were to implement its own cache, that would just be redundant. Ok thanks, I see what I need to do and how to design things in the future. I wasn't really expecting the view to keep a cache at all. I was expecting it to request the item each time it wanted information about it (in which case an returning an autoreleased object seemed reasonable). The fact that the object had a longer life caught me out. The documentation does say outlineView:child:ofItem: is called very frequently. Granted that does suggest I don't want to be creating an object every time. I didn't hit either of the notes about it just because of the way a tend to traverse the documentation. The way the documentation is worded it does seem like it's an exception to the normal Cocoa memory management. Paul ___ 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]
Outline View not retaining objects it uses. Why?
Hi all,
I've obviously not got the right mental model for something and I'm
wondering why. It should be fairly obvious that this is quite early on
in my Cocoa Career.
I've got an outline view that has a data source. The data source has
routines that look like this:
-(id) outlineView:(NSOutlineView *) aView child:(NSInteger) anIndex
ofItem:(id) anItem {
id aDataItem = [someArray objectAtIndex:anIndex];
return [NSDictionary dictionaryWithObjectsAndKeys:aDataItem,
@DataItem, extraInfo, @ExtraInfo];
}
-(id) outlineView:(NSOutlineView *) aView objectValueForTableColumn:
(NSTableColumn *) aColumn byItem:(id) anItem {
id dataItem = [anItem objectForKey:@DataItem];
id extraInfo = [anItem objectForKey:@ExtraInfo];
.
}
This works fine the first time the view is populated, but when it's
refreshed it just calls the second method with the pointers to the
dictionaries I return first time round. Trouble is they've been
autoreleased by now.
I know how to fix this, but I'm looking to understand.
Why, if the outline view is holding pointers to the objects I return
from outlineView:child:ofItem:, doesn't it retain them?
Why was I wrong to assume that an autoreleased object was sufficient?
Would the pointers it holds be strong or weak in a GC program?
Thanks
Paul
___
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: Outline View not retaining objects it uses. Why?
On 19 Jul 2008, at 23:18, Quincey Morris wrote: On Jul 19, 2008, at 14:35, Paul Sargent wrote: This works fine the first time the view is populated, but when it's refreshed it just calls the second method with the pointers to the dictionaries I return first time round. Trouble is they've been autoreleased by now. I think you mean deallocated, not autoreleased. The question is, what's your evidence that they're deallocated? Is something crashing? Just to be clear, I mean the object was de-allocated due to it being an object created by a convenience method, and the auto release pool it was in was released when control went back to the event loop. Yes, when the OutlineView redraws for some reason (e.g. a mouse click), it re-accesses the objects I returned last time (nothing wrong with that). Trouble is, they are no longer valid, resulting in a crash or a zombie log message if I have zombies enabled. I was just surprised by the fact the OutlineView held pointers to objects it didn't retain. The main thing that's wrong here is that you're returning a *different* object from outlineView:child:ofItem: each time. You should return the same object if you are given the same parameters. If finding extraInfo is not incredibly expensive, you could just return aDataItem in the first method, and find extraInfo in the second. While you're right I would return different objects if I was called twice, I'm not. As I understand it the Outline View will only ask for objects when it knows the data has changed (e.g. after a reloadData or reloadItem call) at which point it needs to expect a different object. It's exactly the cost that took me down the road of bundling the info up into a dictionary, so any other call backs didn't need to re- evaluate things. Obviously I wasn't expecting anybody to guess that from the code I posted. ___ 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: Outline View not retaining objects it uses. Why?
On 19 Jul 2008, at 22:49, Andy Lee wrote: On Jul 19, 2008, at 5:35 PM, Paul Sargent wrote: This works fine the first time the view is populated, but when it's refreshed it just calls the second method with the pointers to the dictionaries I return first time round. Trouble is they've been autoreleased by now. Maybe this is relevant: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html#//apple_ref/doc/uid/2043 In Cocoa, references to table data sources, outline view items, notification observers, and delegates are all considered weak (for example, an NSTableView object does not retain its data source and the NSApplication object does not retain its delegate). Thank for the pointer Andy. I can see why all the other items are on that list, but why outline view items? ... and by extension should table view items be on that list too? ___ 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: Bit maps from raw camera files
Remember that some raw files contain multiple resoltions (i.e. a
thumbnail and the main image), so you may not always want the first one.
On 6 Jul 2008, at 04:29, James Merkel wrote:
Will look into CGImageRef using ImageIO. However, I found that if I
use: imageRepsWithContentsOfFile: rather than
imageRepWithContentsOfFile: I can get a bit map from all raw files
that are supported by OS X. (At least for the raw files I have
checked so far). The method imageRepsWithContentsOfFile returns an
array of file reps, so the following works:
NSBitmapImageRep * imageBitMap = nil;
NSArray * repsArray;
repsArray = [NSBitmapImageRep imageRepsWithContentsOfFile:theFile];
if([repsArray lastObject] != nil) {
imageBitMap = [repsArray objectAtIndex:0];
}
Jim Merkel
On Sat, 05 Jul 2008 14:16:46 -0700 Chris Hanson wrote:
On Jul 5, 2008, at 2:00 PM, James Merkel wrote:
So the question is how to go about reliably getting a bit map
reliably form these camera raw files?
Try getting a CGImageRef using ImageIO.
On Jul 5, 2008, at 2:00 PM, James Merkel wrote:
I notice there are now about 120 Digital camera raw formats supported
by Mac OS X as of system 10.5.4.
I am trying to get a bit map from these camera files so I am using:
NSBitmapImageRep * imageBitMap = [NSBitmapImageRep
imageRepWithContentsOfFile:theFile]
For some raw files (Nikon NEF and Canon CR2) I get a bit map. But for
other files (Sony DSLR-A100 ARW file) I get a nil bit map.
On the other hand, I notice that the system does support the Sony raw
file in some way, since for example:
[[NSImage alloc] initWithContentsOfFile:theFile] does produce an
image.
So the question is how to go about reliably getting a bit map
reliably
form these camera raw files?
___
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/psarge%40gmail.com
This email sent to [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: [MODERATOR] Re: sphere in openGL ES ++IRC
On Wed, Jun 25, 2008 at 11:20 PM, Scott Anguish [EMAIL PROTECTED] wrote: On Jun 25, 2008, at 4:47 PM, Simon Fleming wrote: Dear All, Can anyone help me create a sphere in openGL ES for the iphone? NO they can't. The iPhone SDK is covered by a non-disclosure agreement. You can't talk about it here, or anywhere else. Also, it's an OpenGL question that has nothing to do with Cocoa. Ask questions on a list that relevant to your problem. I'd suggest writing some OpenGL apps targeted at a normal computer before worrying about it on the phone. ___ 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: Garbage collector vs variable lifetime
On 8 Jun 2008, at 01:23, Bill Bumgarner wrote: One of the tenets of GCC is that *it controls the layout of the stack always* and this is done quite explicitly because of performance. I think this is the crucial point when considering how any GC will work with gcc. If gcc controls the stack, it's impossible for the programmer to dictate what is in the root set. They can make some suggestions, and possibly influence it with hacks (such as [data self]), but absolute control is ceded to the compiler. It's a fundamental truth for any GC on top of gcc, and one that makes the job of writing the GC one I wouldn't ever want. I don't think it's possible to make a 100% fool proof GC without more compiler support, or internal pointer support (which is non-trivial). ___ 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: Main window disappears. Sometimes.
El 02/06/2008, a las 10:45, Michael Vannorsdel escribió: This will happen if the window is deallocated. It's probably getting cleaned up by garbage collection. On 2 Jun 2008, at 10:05, Francis Perea wrote: I've also supposed it was happening that, and I've tried to correct it by using retain in each one of init methods of both classes, but no results. What I mean is, in every init method, when I call the [super init] I've tried [[super init] retain]. But no way. As Michael says, retain and release become null-operations when garbage collection is switched on (so code can be written to run as both GC and non-GC). If nothing is holding onto a pointer to your window then it'll be collected by the garbage collector. Something has to hold on to a pointer to it. I believe it's worth writing an application or two without using garbage collection if you're starting out. GC is one area in Cocoa that's a bit like magic if you don't understand how it works. Learning everything else with 'magic stuff' happening can be difficult. Retain and Release are pretty simple, and as long as you stay within Objective C (i.e. don't start using the CoreFoundation C API) managing it all is pretty straight forward. Once you're comfortable with that, switch GC back on and get used to how it works.___ 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: Leopard (10.5+): Any Upper-Level (Cocoa) access to Mail?
On 2 Jun 2008, at 16:45, [EMAIL PROTECTED] wrote: I would like to talk to Mail.app / ditto for (NDA - aware) iPhone platform. Ric. You're probably looking at using the scripting bridge/AppleScript to talk to Mail.app. I know nothing about it, but it's where I'd start looking. Obviously you're aware that nobody can tell you how to do it on the iPhone. ___ 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: Main window disappears. Sometimes.
On 2 Jun 2008, at 18:50, Bill Bumgarner wrote: While learning the retain/release paradigm is certainly useful, it is considerably more complex than GC. It is also unnecessary while learning Cocoa. Specifically, GC is intended to be a production quality solution that you can use in your Cocoa applications, without exception. In Leopard, there have been a handful of bugs and they have been addressed through software updates -- not surprising given the rather sweeping and intrusive set of changes needed to support GC. And GC will get better / faster in future releases. I agree with nearly everything you've said, except the (second half of the) first statement. I wouldn't say retain/release is more complex than GC. I'd say using retain/release in a medium-large size project is more complex than using GC, but the base concept is a simpler one. Whilst learning, getting retain/release wrong tends to be less confusing than getting GC wrong. GC will make things disappear at random times, whereas retain/release will tend to be deterministic in behaviour. ... and it's good grounding. Learning some of the old styles of writing Cocoa apps (e.g. accessor methods before properties, custom controllers before bindings) makes learning the newer styles that much easier. You don't need to write big projects without the nice new technologies. Just do a few test apps with them and understand why you want them. That's how all the senior programmers on this list learnt (although they didn't have a choice). Why do we think that people following can jump a few steps? That's my opinion anyway. (Feel free to disagree, but we probably don't need another big thread about it) ___ 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: Main window disappears. Sometimes.
On 2 Jun 2008, at 12:16, Francis Perea wrote: Hi Paul. I've disabled GC as Michael and you propose and the application it's working right now. I've had to retain both properties of the model class (generator) and the instance of that class in the controller class (generatorcontroller). There's a few simple rules that specify when you have to retain something, and when you don't. The document Graham gave you goes through them. I don't want to repeat them here because I'd probably get it slightly wrong and people love to argue over the fine detail. We found that out in another thread recently. I've also had to implement both dealloc method of both classes so that all retained objects get released. Is that right? Yes, that's exactly the reason for dealloc. And a final question, I would like to know if my application frees up all memory it uses after stopping and it has no memory leaks; I think Instruments is the utility Apple provides for that matter, isn't it? An application will automatically free everything when it quits. If you want a way of seeing if you've released everything you allocated, then it's worth looking back in the archive a couple of weeks, as there was a thread talking about how to do it. I think the conclusion was put a sleep statement before the app quits. That way you have some time to see the final state. In that case I should read Instruments help so that I know how to get that information, cos I've tried to use it but it doesn't seem very friendly to me :-( Instruments is one tool that can do it. Also there's the 'leaks' command line tool, and ObjectAlloc (which appears to be an Instruments template now). Don't worry too much about getting rid of all memory leaks while you're learning. There's lot's of stuff to learn, and as you get more experience you'll start to see the patterns. If you get problems with over releasing something (which will often cause you to crash), search for NSZombiesEnabled in the docs. Have fun. ___ 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: Dealing with NSError outside of the Responder chain
On 27 May 2008, at 21:24, Adam R. Maxwell wrote: In general, I think you're supposed to add NSError** parameters to pass it back up to some class that knows how to present an error, but I find that's not always practical, and it tends to be messy. In such cases I typically take the easy way out and call [NSApp presentError:]. Makes sense. Hadn't noticed NSApp had a presentError method. Thanks ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: File's Owner
On 24 May 2008, at 05:39, Andreas Mayer wrote: I thought, maybe a picture would help: http://www.harmless.de/images/other/files_owner.png Exactly the picture I was about to draw. Johnny Lundy wrote: Saying it connects the nib to an object outside the nib sounds good, but what object is that? The object that loaded the NIB. What object is that? Whichever is passed when the NIB is loaded with [NSBundle loadNibNamed:owner:] e.g. NSApplication probably has code that looks like [NSBundle loadNibNamed:@MainMenu owner:self] You might have a piece of code that reads [NSBundle loadNibNamed:@InspectorWindows owner:inspectorController] ___ 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]
Breakpoint for unknown selector
In the same way that there are that there are breakpoints that will catch all the Objective C exceptions that are thrown... Is there a good place to set a breakpoint to catch selectors that aren't recognised by the receiving object? I want to get in and have a good look around when it occurs. ___ 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: Gaussian blur with core image, using CPU or GPU?
Just FYI, Core Image is normally dealt with n the Quartz list rather than here, but not to worry. On 22 May 2008, at 22:36, Jordan Woehr wrote: Does this mean that it is not possible to write a bilateral filter which does the computations on the GPU? Filters of variable kernel size are tricky (to say the least). Apple's blur filter seems to generate different GPU programs depending on the radius parameter, but it does run on the GPU. It might also be multi-pass. You can see that varying the radius of the blur is quite low performance compared to changing the image it's blurring. If your filter has a fixed kernel size (that isn't too big), then it can normally be coded. The key problem is the the kernel language has no conditional branching, so loops of variable length aren't allowed. Fixed length You may have more luck coding for OpenGL rather than CoreImage, and using GLSL. Unfortunately Apple decided to remove the parts of GLSL that the hardware of the time didn't support when they created the CIKernel language. Now that hardware is more capable CI is stuck with those limitations. That said, getting a OpenGL solution running will probably need you to be familiar with Pixel Buffer Objects (PBOs), Frame Buffer Objects (FBOs) and devising some way of putting your 4D data into textures (which you'd have to do for CoreImage anyway). Another advantage of going the OpenGL route is that you've be able to use 3D textures, rather than just 2D images that you'll be working with in CoreImage. At least that's only one dimension off. Is there source code available for this filter and if so where is it? I have had no luck finding it so far. You won't find it, it's in a framework that isn't open-source. ___ 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: Delegates
On 19 May 2008, at 17:22, john darnell wrote: As far as I can tell, it is kind of like a virtual function (virtual because I, the programmer, am expected to flesh it out) that resembles an event attached to a given class. You're in the right ball park. The bit you're missing is that with virtual functions the overloading is done in a subclass at compile time, and with delegates it's done with any class at runtime. Say we had two classes (ClassA ClassB). ClassB DOES NOT have to be any relation to ClassA (Super, Sub-Class, or anything else). An instance of class B can tell an instance of class A's that it wants to be it's delegate. After that, when ClassA is doing something it can check to see if it has a delegate, and if so call it. ~~ Somewhere in ClassA ~~ ableToKickIt = NO; if ([self delgate]) ableToKickIt = [delegate canWeKickIt]; ~ (It's not quite written like that, but it gets the point across) Points to note: * We're talking about instances, not classes, so you have a delgate object for A window, or A document, not all windows, or all documents. * Behaviour might change as the as the application runs, so a different instance of ClassB might be set as the delegate later on. Alternatively it could be a completely different class, ClassC. * Sometime you see code where an object set's itself to as it's own delegate. This is normally done because for other reasons the author has decided to write a subclass, and rather than have the delegate methods elsewhere it makes sense to have them in the same place. It doesn't have to be done this way though. It has specific times when it is called and at that time it may perform just about any duty that the programmer can dream of, or she can stick to something that relates to the object calling it. Yes, although it's normally best to keep with the second option. In almost every description of a delegate that I perused, I found the words when or before, which is why I related a delegate to an event. should returns a yes/no to say should the action occur. e.g. applicationShouldTerminate will is notification of an event before it happens e.g. applicationWillTerminate did is notification of an event after it happens e.g. applicationDidFinishLaunching ___ 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: Delegates
On 19 May 2008, at 18:01, I. Savant wrote: On Mon, May 19, 2008 at 12:52 PM, Michael Vannorsdel [EMAIL PROTECTED] wrote: Delegates act like observers. Well, no, not really. I think that was 'observers', not 'Observers'. (i.e. not in the Cocoa/KVO sense) Sometimes wonder if we're going to run out of words to describe things because everything is overloaded with some technical meaning. ___ 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: Bypassing Interface Builder
On 15 May 2008, at 17:40, Johnny Lundy wrote:
but I am puzzled as to how my new class got instantiated. Here's
what I did:
1. Create the class, the .h and .m files.
2. Code the ivars, their @property directives, and their @synthesize
directives.
3. Write 2 instance methods plus the -init method. There are no
class methods, and no IBOutlets.
4. Write an -init method that doesn't instantiate anything.
5. There is no +initialize method, as I don't understand it. When I
have tried to use it, it complains I can't refer to ivars.
6. Compile.
7. In IB, make an NSTextField and read in my class header file.
8. In IB, drag out an NSObject and give it the class name of my new
class. I did NOT control-drag anything to anything, and there are no
IBOutlets in my code.
Somehow, doing the above steps must have created an instance of my
class, as one instance method can call another. I know that
dragging out the NSObject made an instance, but my class does not
know about it. So how come the instance methods in my class work?
How can the property that I bound to an NSTextField work if there is
no instance of my class to hold the property?
I think you're confusing yourself (or others are), and you're tying
yourself up in knots.
You placed the NSObject in the NIB, you gave it a class name of your
class. What you're saying when you do that is When this NIB is
loaded, create an instance of my class. It's an NSObject you drag
because NSObject is the super class of all other classes. i.e. your
class is-a NSObject.
But [MyClass somemessage] tries to message the class, and I get a
Class MyClass may not respond to somemessage, which makes sense
since there is no class method somemessage.
You're right. [MyClass somemessage] sends a message to the class
object, not an instance of the class. For that to work you'd need to
have +(void) somemessage; defined in MyClass. (Notice the '+' meaning
class method, as opposed to '-' meaning instance method).
Class methods cannot access instance variables (ivars) because there
is no instance associated with the call to contains the variables.
(There might be hundreds of instances of a class in the system, which
one contains the ivar I want to access) This is why you get the issues
with +initalize() not being allowed to access ivars. It's a class
method.
It won't let me set the class for the second Object. I can type it
in, but on hitting Tab or Return or clicking out of the field, the
text I entered disappears and it gets replaced with a dimmed
NSObject. I thought it was a glitch in IB, but I discovered that
it only does that if you try and set more than one IB object to the
same class.
This shouldn't be the case, and suggests you're not doing things quite
right.
Make sure you are setting the class by editing the Class Identity
field in the Identity inspector, rather than just changing the name.
I just tried to do this in a new project and succeeded. Here's what I
did:
1. Started a Cocoa Application Project
2. With 'New File' I added a Objective-C Class called MyClass. I left
it empty, except I gave it an init method.
- (id) init
{
self = [super init];
if (self != nil) {
NSLog(@Initialized MyClass);
}
return self;
}
3. Opened the NIB and dragged an NSObject into play. I then set the
class of the Object to MyClass.
4. Added a second MyClass instance in exactly the same way.
5. Saved, build, run, and look at the console.
You'll see that two messages are present, as two instances were
created. and init is always the first message sent to a new instance.
Right. I can understand that, that the owner is the shared
application instance. But why do people bind nib objects to File's
Owner?
You're right, in this case the Files Owner is the shared NSApplication
instance. That's not always true, because NIBs can be loaded by any
class, but NSApplication is always the owner of the first NIB loaded.
People connect to file's owner to allow the owner to access the
objects in the NIB. (I use connect rather than bind to avoid
confusion. Bindings are something different in cocoa-speak)
A common practice is to connect an object to the delegate outlet of
the NSApplication instance. This allows the NSApplication to send
messages to your code a predetermined key times. For example, when the
user selects quit from the menu, the object linked to the delegate
outlet of the NSApplication will be sent a message to confirm if the
application should terminate, by sending it the aptly named
applicationShouldTerminate message. These messages are detailed in the
NSApplication docs under delegate methods.
If that link wasn't made the NSApplication wouldn't know where to send
the message. There are no magic connections made between objects
instantiated by the NIB, and those that are instantiated some other
way. File's Owner tends to be the gateway between
Re: NSApplicationMain Main NIB File
On 9 May 2008, at 10:10, Simon Wolf wrote: I'm going to apologise here in my first contribution to this list for the potential stupidity of my questions. I'm a VB developer who has been a Mac user for several years but I'm only now starting to dip my toe into XCode and I think that I'm going to have loads of questions, some practical and some more theoretical like the one below. No problem. Everybody has to learn. Be respectful ask good (i.e. well formed) questions and I'm sure everybody will be happy to help. Welcome. I know for the documentation that NSApplicationMain 'loads the main nib file from the application’s main bundle, and runs the application' but I was wondering what defines a NIB (or XIB) as being the main one if you have a project containing several NIBs. Is it just the fact that it includes an NSMenu called MainMenu? As an alternative answer to Stephan's (which isn't incorrect, but only half the story): You'll notice that there's a file called Info.plist in your project. This file defines various things about your app bundle. The one you're looking for is the NSMainNibFile property. This is changed when you edit the setting Stephan described. Others that are worth being aware of (from a start-up behaviour point of view) are NSPrincipalClass*, and CFBundleExecutable. I doubt you'll ever need to change them though. * I believe this is used more for bundle based plug-ins than apps.___ 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: Threading - How its done?
Sorry, long non-cocoa post, but maybe there some useful info for someone. On 7 May 2008, at 18:33, Army Research Lab wrote: Pay particular attention to the section titled HDL and programming languages. Chip designers have had to contend with these problems for years, and developed languages for expressing parallelism with implicit threading already (everything in an HDL is parallel unless you carefully force it to be sequential). We should be using ideas from those languages. As somebody who's day job is writing HDL I'd like to just repeat this for emphasis, but it's not the languages that solves the race conditions, it's the architectures employed by the engineers. I think a lot of the problems software engineers have with with threading come from bad architectures when viewed from a parallel execution point of view. Locks and Semaphores are the workaround for this, and (good) hardware engineers (almost) never use them. For example: Pipe-lining. If faced with a set of tasks that need to be performed sequentially on some data blocks a software engineer might decompose the problem like this (MIGHT, I said MIGHT): (PA means process A, D1 means data block 1) Thread 1: PA - D1 | PB - D1 | PC - D1 | PD - D1 Thread 2: PA - D2 | PB - D2 | PC - D2 | PD - D2 Thread 3: PA - D3 | PB - D3 | PC - D3 | PD - D3 Thread 4: PA - D4 | PB - D4 | PC - D4 | PD - D4 The thing to note is how each thread is running the same code (which must therefore be re-entrant) on different data. A Hardware engineer would probably do this: Thread 1: PA - D1 | PA - D2 | PA - D3 | PA - D4 Thread 2: PB - D1 | PB - D2 | PB - D3 | PB - D4 Thread 3: PC - D1 | PC - D2 | PC - D3 | PC - D4 Thread 4: PD - D1 | PD - D2 | PD - D3 | PD - D4 Note how the data is passed from thread to thread so only one thread owns the data at any time (no locks necessary), and how no process is being run in more than one thread at a time so code doesn't have to worry about being re-entrant. Granted there's a start-up / shut-down cost where full parallelism isn't achieved (which is overwhelming in this example, but give it more data blocks and it becomes negligible), and this doesn't work for all problems, but it's a useful pattern for data-processing. The other thing is to make sure that you're stages are of similar complexity, as the slowest stage will define the performance of the system. Passing the ownership of data from thread to thread would be done with FIFOs which can also be written without locks, with some care. (e.g. http://msmvps.com/blogs/vandooren/archive/2007/01/05/creating-a-thread-safe-producer-consumer-queue-in-c-without-using-locks.aspx , but read the comments esp. w.r.t out of order execution). Yes there can be issues with something like this in software (passing data between NUMA processors and non-shared caches), but believe me... It's makes code far, far, far easier to read, write and DEBUG (unit tests for each stage). ___ 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 adopt a superclass's protocol?
On 29 Apr 2008, at 04:22, K. Darcy Otto wrote: First, I still get the warning that the superclass may not respond to the method (and to be sure, it is only implemented in the subclass, but the superclass calls it after a conformsToProtocol: check). Sounds like the way things a decomposed into classes could use some rethinking, but you could [instanceB performSelector:] to call the method, and it wouldn't be checked by the compiler. Messy if it's a lot of code though. Only really suitably if it's a single call. ___ 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]
Obj-C idioms for list based tasks
Coming from other object based languages I'm aware that each language can have it's own idioms for common tasks. In particular coming from doing a lot of python, I'm finding myself wanting to do a few things with NSArrays that I would do quite easily with python lists. Can anybody suggest a good way to: 1) Given an ordered set of objects, create a new non-mutable ordered set, with all the duplicates removed? 2) Given an ordered set of objects, create a new non-mutable ordered set, with each entry being the output of a method applied to each entry of the original array (e.g. Python map())? I can easily write 'for each' loops that do these and create mutable arrays, and then return non-mutable copies, but I half expect that these are common patterns, and there might be a nice, concise, way of writing them. Are there any ObjC shortcuts when doing things like this? Am I best writing a category on top of NSArray the encompass these (and other) patterns? I'd like to retain ordering, so using NSSet for (1) seems counter productive. Thanks P.S. Alternatively, Is there a site like http://aspn.activestate.com/ASPN/Cookbook/Python/ for Objective C? ___ 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: Python/Ruby for Cocoa (was: Simple question)
On 17 Mar 2008, at 17:46, Hamish Allan wrote: If you're cutting your programming teeth on Cocoa, you might find that Python or Ruby is gentler. I'm not sure I agree. Two problems for me. * Cocoa isn't a seamless fit with either python or ruby, so there are little corner cases around that don't feel quite right. Method naming, for example, reads correctly in Objective C, but not in Python. In fact it can get quite confusing. * The documentation for Cocoa on Python and Ruby is far less bountiful than for Objective C, so you end up reading Objective C documents and translating them to Python or Ruby. I really like Python (in particular) as a teaching language, but I wouldn't teach cocoa with it. ___ 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]
