Pour l'instant, tout est ouvert et l'interpreteur passe par 2 endroits pour appeler des fonctions C ou Cocoa : At the very least I would leave a normal pool in place beneath your 'remote-control' pool. But the bending of the autorelease pool conventions makes me cringe. I realize that's a real edge case, and that it may not really affect JSCocoa programs. Try putting an NSLog( as the first line of your main function). If, by chance, the program pops its pool and does something, the 'active' autorelease pool will have died already. I was going to suggest a safer variant which deallocated and reallocated the autorelease pool at the same time, but then I realized that both versions have a serious problem: when -awakeFromNib is called, AppKit has its own autorelease pool on the top of the autorelease stack.

Classes in particular are supposed to stick around for the lifetime of the program. If you mean you need the objects to hang around until after the nib is loaded, well, I'm not sure you should be using autorelease then anyway it breaks the semantics of 'I'm done with this, if the caller wants it they better retain it'. (I'm not familiar with JSCocoa, true, so maybe this isn't quite what you want.) Well.I would create an autorelease pool around the JSCocoaController initialization and call to evalJSFile. I really like having an app delegate written in Javascript, but I might use a 'proxy' ObjC one and replace it with a JS one in awakeFromNib. nib, and starting JSCocoa in the application delegate's awakeFromNib. I'm well aware this is kludgy, but it works :) A cleaner solution would be to not use any JSCocoa objects in MainMenu. Which, thinking about it, might be BAD :) It should be released too after NSApplicationMain. That's why your NSLog doesn't crash as that pool is still in place. What I'm doing is popping that stack leaving it empty, then right after adding a new pool to it. I don't think autorelease pools have any concept of 'beneath', just a stack getting pushed and popped by every pool alloc/dealloc.

> I realize that's a real edge case, and that it may not really affect JSCocoa programs. Even a basic NSLog() fails to display anything - nothing shows up in the console or in console. You mean right in main.m ? Doesn't crash nor even log. > Try putting an NSLog([NSString after your call to NSApplicationMain() in a JSCocoa app. js might be using functions like performSelector:withObject:afterDelay that would maybe leak if they happen before the runtime creates a new pool. This would work fine if I'm the only one autoreleasing, but the runtime might autorelease too, or the. Creating an autorelease pool just before calling, calling, then releasing the pool would remove the autorelease objects - that's what I want. > I would create an autorelease pool around the JSCocoaController initialization and call to evalJSFile:ĮvalJSFile will create ObjC classes that will be called back during NIB loading. (I autorelease objects for convenience, eg in getProperty(), allocating a string to copy the property name from JS back to ObjC then autoreleasing it as I don't want to release it at each return of the function or use goto.) So coming back to the first point, since using rect is inappropriate, you should use - for finding the actual size of the view (in its drawing space).Īpply has a guide on efficient view drawing if you want more information. You'll see that Apple are usually pretty efficient with the amount they redraw. If you launch the 'Quartz Debug' utility that shipped with your developer tools, you can enable options to flash, or highlight, the areas that are being updated on screen. Only a portion of the view is changing and needing to be redrawn. Picture where the user is working on some sort of elements in a view, such as selecting a range of text in a text view, or rolling their mouse over a list of buttons and having them highlight. (Or if further rectangles are specified later, then a union of all those rectangles.)īy only invalidating what has changed, and then by drawing only what has been invalidated, your drawing becomes more efficient. The invalidRect argument is then the rectangle used in the -drawRect: method. However, a part of the view can also be chosen to redraw, through use of methods such as: - (void)setNeedsDisplayInRect:(NSRect)invalidRect When you resize the window and the view, the whole view needs updating. The rect is the dirty rectangle that needs redrawing.

Netnewswire 3