Re: How to change focus ring color?
On 01.08.2009, at 4:42, Joel Norvell wrote: You didn't say what objects you are drawing, so I should add this caveat: I'm not sure what variations, if any, would be induced by generalizing my approach to NSCell objects. OK, maybe I provided not so clear problem description. I have _standard_ NSPathControl. It's style is set to PopUp. And I see a light blue rounded rectangle around the control. I'm not sure exactly, if it's a focus ring, because this border does not disappear, if I'm selecting (by mouse) other controls on the same panel. At least this border disappears if choose none in IB properties inspector for the Focus Ring. My question was exactly can I subclass NSPathControl to override this border drawing procedure to change the color of the border? If yes, then what method should I override? I'm not so skilled yet in controls inner structure yet, so I don't know if there is a special procedure, drawing the border, or it's drawn within the same method, which draws the control itself. It looks like your code really draws focus ring, related to keyboard focus. But I'm not sure, if it's what I need for my case. Please advise if you can. Another related problem is that checkbox has the same light-blue background in the checked state. And I don't see what property could change it. I'd like to change it to some grayscale value. Thanks. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data App With Auxiliary Panel
Because you have a managedObjectContext ivar, you never change its value so it defaults to nil, and +[NSObject(NSKeyValueCoding) accessInstanceVariablesDirectly] returns YES, -[AuxPanelController objectForKey:@managedObjectContext] will always return nil. Ditch the ivar. Need to correct myself here. Instance variable access is a last resort, performed only when there is no KVC-compliant accessor for the requested key. Sorry for th misinformation. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How do I delete NSCollectionView item on right click?
On 01/08/2009, at 1:11 PM, Austin Grigg wrote: I've got an NSCollectionView with the prototype view subclassed and I'm overriding menuForEvent. I'm creating a menu that has Edit/ Delete and when the user clicks Delete I want to remove that collection view item. Where would you put the selector for the Delete menu item, and how would you know when it gets called what collection view item to delete? By selector I assume you mean e.g. a -delete: IBAction method. That would go in the controller that is handling the view. To ensure it gets called, you simply ctrl-drag a connection from the menu item to the controller and choose this method. Verify it gets called using NSLog or the debugger. To actually implement the delete, you'd use the view's - selectionIndexes to find out what items to delete, remove them from your data model and call the view's -setContent: with the modified array from your model, and also remove the selection using - setSelectionIndexes: with an empty set. You might need to call - setNeedsdisplay:YES on the view to make it show the change. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How do I delete NSCollectionView item on right click?
On 01/08/2009, at 4:12 PM, Graham Cox wrote: I've got an NSCollectionView with the prototype view subclassed and I'm overriding menuForEvent. I'm creating a menu that has Edit/ Delete and when the user clicks Delete I want to remove that collection view item. Where would you put the selector for the Delete menu item, and how would you know when it gets called what collection view item to delete? By selector I assume you mean e.g. a -delete: IBAction method. That would go in the controller that is handling the view. To ensure it gets called, you simply ctrl-drag a connection from the menu item to the controller and choose this method. Verify it gets called using NSLog or the debugger. Forgot to mention - if you are setting up the menu programmatically, you need to set the target of the menu item to the controller and the action method selector to the -delete: IBAction (it doesn't strictly need to be an IBAction in this case, but personally I find that declaring it as such is useful for managing the code and converting it to an IB-based solution later). If your menu is simple and not dynamic - i.e. it never changes according to the state of the item it's attached to - you might find it easier to set it up in IB rather than overriding -menuForEvent: - just create a menu object and connect it to the 'menu' outlet of the view. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data App With Auxiliary Panel
On Jul 31, 2009, at 20:03, Richard Somers wrote:
I am having problems binding an auxiliary panel with the document's
managed object context. The panel is in nib separate from the
document nib. My code looks like this.
@interface AuxPanelController : NSWindowController
{
@private
NSManagedObjectContext *managedObjectContext;
}
@implementation AuxPanelController
- (id)init
{
if (![super initWithWindowNibName:@AuxPanel])
return nil;
return self;
}
- (NSManagedObjectContext *)managedObjectContext
{
return [[self document] managedObjectContext];
}
In the AuxPanel.xib the array controller's managed object context is
bound to the File's Owner managedObjectContext model key path. The
File's Owner object is the AuxPanelController.
In the running application the auxiliary panel displays properly but
an error message is produced: Cannot perform operation without a
managed object context.
You haven't said what you mean by an auxiliary panel.
If you mean it's a sheet on the document window, then its window
controller's document property will be nil. You should pass the
document as a parameter to the AuxPanelController's initializer instead.
If you mean it's a freestanding window (whether NSWindow or NSPanel),
the answer is the same: pass the document because there's no other way.
If you mean it's a secondary document window, then you need to add it
to the document's list of window controllers. That would need to be
done by whatever creates is -- typically the window controller of the
main document window. After that's done, AuxPanelController can refer
to [self document] and get the document.
Or, in all 3 cases, just pass the managed object context to the
AuxPanelController initializer, and stash it in your otherwise unused
instance variable.
___
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
Surprise: -[NSInvocation retainArguments] also Autoreleases them
The document for -[NSInvocation retainArguments] tells me:
If the receiver hasn’t already done so, retains the target and all
object arguments of the receiver and copies all of its C-string
arguments. ... Newly created NSInvocations don’t retain or copy their
arguments, nor do they retain their targets or copy C strings. You
should instruct an NSInvocation to retain its arguments if you intend
to cache it, since the arguments may otherwise be released before the
NSInvocation is invoked.
So I decided to -retainArguments, and presumed that this meant I was
supposed to release the target and arguments when I was done with
them. But I thought it was odd that the documentation did not say so
explicitly, so I did a little experiment, and learned that -
retainArguments also adds them to the autorelease pool! Presumably (I
hope) this happens when and in the thread where the invocation is
invoked.
The code and results are below. Whether -retainArguments is commented
out or not, the target (Target) and the argument (StringWrapper) both
get deallocced just the same. If -retainArguments is commented out,
the final NSLog() does cause a crash, but that is expected since in
this case the target and argument have not been placed in the
autorelease pool by the action of -retainArguments.
If anyone sees anything wrong with my explanation, please reply. I'm
using NSInvocation alot.
-- CONSOLE OUTPUT --
2009-07-31 23:08:56.848 Test[48825:10b] retainCounts: target=1
stringWrapper=1
2009-07-31 23:08:56.854 Test[48825:10b] retainCounts: target=2
stringWrapper=2
2009-07-31 23:08:56.860 Test[48825:10b] Hello
2009-07-31 23:08:56.861 Test[48825:10b] retainCounts: target=2
stringWrapper=2
2009-07-31 23:08:56.862 Test[48825:10b] retainCounts: target=1
stringWrapper=1
2009-07-31 23:08:56.864 Test[48825:10b] dealloccing Target
2009-07-31 23:08:56.871 Test[48825:10b] dealloccing MyString
-- CODE --
#import Cocoa/Cocoa.h
@interface StringWrapper :NSObject{
NSString* string ;
}
@property (retain) NSString* string ;
- (id) initWithString:(NSString*)string ;
@end
@implementation StringWrapper
@synthesize string ;
- (id) initWithString:(NSString*)string_ {
self = [super init];
if (self != nil) {
[self setString:string_] ;
}
return self;
}
- (void)dealloc {
NSLog(@dealloccing MyString) ;
[string release] ;
[super dealloc] ;
}
@end
@interface Target : NSObject {
}
- (void)logThis:(StringWrapper*)what ;
@end
@implementation Target
- (void)logThis:(StringWrapper*)what {
NSLog([what string]) ;
}
- (void)dealloc {
NSLog(@dealloccing Target) ;
[super dealloc] ;
}
@end
int main (int argc, const char * argv[]) {
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init] ;
Target* target = [[Target alloc] init] ;
SEL selector = @selector(logThis:) ;
NSMethodSignature* methSig = [target
methodSignatureForSelector:selector] ;
NSInvocation* invoc = [NSInvocation
invocationWithMethodSignature:methSig] ;
[invoc setTarget:target] ;
[invoc setSelector:selector] ;
StringWrapper* stringWrapper = [[StringWrapper alloc]
initWithString:@Hello] ;
[invoc setArgument:stringWrapper
atIndex:2] ;
NSLog(@retainCounts: target=%d stringWrapper=%d,
[target retainCount],
[stringWrapper retainCount]) ;
// Here's the retainArguments which may be commented out:
[invoc retainArguments] ;
NSLog(@retainCounts: target=%d stringWrapper=%d,
[target retainCount],
[stringWrapper retainCount]) ;
[invoc invoke] ;
NSLog(@retainCounts: target=%d stringWrapper=%d,
[target retainCount],
[stringWrapper retainCount]) ;
[target release] ;
[stringWrapper release] ;
NSLog(@retainCounts: target=%d stringWrapper=%d,
[target retainCount],
[stringWrapper retainCount]) ;
[pool release] ;
}
___
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: Surprise: -[NSInvocation retainArguments] also Autoreleases them
On Aug 1, 2009, at 1:42 AM, Jerry Krinock wrote: So I decided to -retainArguments, and presumed that this meant I was supposed to release the target and arguments when I was done with them. As you've discovered, no, you're not supposed to do that. You have not retained the target and arguments. You have told the NSInvocation to do so, and it then has responsibility for releasing them. But I thought it was odd that the documentation did not say so explicitly, so I did a little experiment, and learned that - retainArguments also adds them to the autorelease pool! Whether they are released or autoreleased is an implementation detail on which you shouldn't rely. And, to be clear, -retainArguments doesn't [add] them to the autorelease pool. That would imply they are autoreleased by the time -retainArguments returns, which would defeat the whole purpose. But asking the NSInvocation to take ownership of its arguments does cause it to later release them, yes. Presumably (I hope) this happens when and in the thread where the invocation is invoked. Not when nor where the invocation is invoked. When and where the invocation is ultimately deallocated, just like with typical objects which own other objects. Among other reasons, invocations can be invoked multiple times, so it definitely can't be when it's invoked. The code and results are below. Whether -retainArguments is commented out or not, the target (Target) and the argument (StringWrapper) both get deallocced just the same. If - retainArguments is commented out, the final NSLog() does cause a crash, but that is expected since in this case the target and argument have not been placed in the autorelease pool by the action of -retainArguments. My interpretation of your results is that neither the target nor argument are being autoreleased. Rather, the NSInvocation is autoreleased as is fairly common for objects obtained through convenience constructors. It, in turn, just directly owns the target and argument (because you told it to with -retainArguments) and releases them as it is being deallocated. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data App With Auxiliary Panel
The below is incorrect. Key-Value Coding (and therefore Key-Value Observing and bindings) will always use a method if one is present. -- Chris On Jul 31, 2009, at 8:33 PM, Kyle Sluder kyle.slu...@gmail.com wrote: Because you have a managedObjectContext ivar, you never change its value so it defaults to nil, and +[NSObject(NSKeyValueCoding) accessInstanceVariablesDirectly] returns YES, -[AuxPanelController objectForKey:@managedObjectContext] will always return nil. Ditch the ivar. ___ 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
Disabling Undo in Core Data
I want to disable undo in Core Data. So far I can think of two ways to do that. 1) In awakeFromNib, call either [[self managedObjectContext] setUndoManager:nil]; or [[[self managedObjectContext] undoManager] disableUndoRegistration]; This certainly works, but the problem with this is that the NSManagedObjectContextObjectsDidChangeNotification will stop being sent when the context changes! This is not an option for me, as I rely on this notification a lot throughout my app. How come this notification is so dependent on having undo turned on? Seems weird to me that turning undo off would stop change notifications being sent out. 2) Which brings me to the second option. Keep the undo stuff there so that the NSManagedObjectContextObjectsDidChangeNotification will properly be sent out, as I want. However, instead just get rid of the Undo and Redo menu items. How good is this solution? Therefore, method 1) isn't an option for me as I stop receiving notifications of changes. 2) might be an option, but might be a bad one in case I would one day like to add undoing for some selected feature in my app. What do you all think? --. _ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/___ 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: Surprise: -[NSInvocation retainArguments] also Autoreleases them
Thank you, Ken. Yes, your explanation -- that the NSInvocation retains them as instance variables -- makes more sense than mine. I submitted Document Feedback that Apple make clear what they mean by retain in this method. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data App With Auxiliary Panel
On Aug 1, 2009, at 12:28 AM, Quincey Morris wrote:
You haven't said what you mean by an auxiliary panel.
It is an inspector panel. One panel for many documents. The panel is
made visible with a menu selection which by the way currently works.
Or, in all 3 cases, just pass the managed object context to the
AuxPanelController initializer, and stash it in your otherwise
unused instance variable.
The managed object context is returned by the following method in my
window controller for the panel.
- (NSManagedObjectContext *)managedObjectContext
{
return [[self document] managedObjectContext];
}
The managed object context ivar was probably misleading everyone.
Setting this ivar in the window controller initializer will not work
because I have one panel for many documents. As suggested previously I
have dumped the ivar. The -managedObjectContext method should return
on demand the correct context. It is this method that I am trying to
bind the array controller to.
If I create the inspector panel in the document nib and bind the array
controller to the File's Owner everything works great. It is when I
try to create an inspector panel in a separate nib that something goes
wrong. The error message Cannot perform operation without a managed
object context indicates the binding is not working. I think this is
my problem. How do you debug a binding?
Richard
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Core Data App With Auxiliary Panel
On Aug 1, 2009, at 8:03 AM, Richard Somers wrote: How do you debug a binding? Troubleshooting Cocoa Bindings http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/Troubleshooting.html Richard ___ 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 set the name of open-with application for a specific file?
On 31.07.2009, at 21:41, MATSUMOTO Satoshi sato...@mac.com wrote: I want to do this programmatically. The direct answer to this question is very easy - it's impossible. Why? Take a look here: http://developer.apple.com/technotes/tn/tn2017.html#Section3 Nevertheless, if I understand it correctly, you need to create a situation, when your app will be shown within the Open With menu for appropriate file type, after user has installed your app on his/her computer. If this is the case, then all what you need to do is the next: - provide appropriate info.plist with your app bundle; - place your app into Applications folder (with app installer's help). I did it manually (the second part) and it works without any problems. Going ahead, a question raises, how to make our great app to be the default application for this file type? First of all read the topic, next to the above mentioned. Then... really I never did it yet. As I believe, a specific API function is required here. I never tried it yet, though I will need to resolve the same problem soon. Therefore I'd like to ask you to let me know, if you'll have any success here. Thanks. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: incorrect checksum for freed object
At 6:31 PM -0700 7/31/09, Shawn Erickson wrote: On Fri, Jul 31, 2009 at 3:39 PM, kvic...@pobox.comkvic...@pobox.com wrote: where interface and device are declared as follows: @property ( assign, nonatomic) IOUSBDeviceInterface300** device; @property ( assign, nonatomic) IOUSBInterfaceInterface300** interface; Why are you use a pointer to a pointer (**) in above? I ask because doing so seems a little strange and hence leads me to think you may have a misunderstanding of pointers, etc. in some of the API you are calling. -Shawn i'm using pointer to pointer (sometimes called handles) because that is what is required when using the usb aspects of the IOKit as demonstated in apple's sample code. ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data App With Auxiliary Panel
On Aug 1, 2009, at 8:03 AM, Richard Somers wrote: The error message Cannot perform operation without a managed object context indicates the binding is not working. Upon further investigation I have discovered that my window controller -document method returns nil. So as far as the binding is concerned I have no document and no managed object context. I thought the - document method would automatically return a pointer to my persistent document but that is not the case. I thought about using -setDocument but the documentation states that you should never directly call this method. So how do I get my NSWindowController subclass -document method to return a pointer to my persistent document? Richard P.S. I am getting better at debugging bindings. It is possible:) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data App With Auxiliary Panel
On Aug 1, 2009, at 07:03, Richard Somers wrote: It is an inspector panel. One panel for many documents. This is a crucial piece of information which changes the nature of the problem to be solved. You gotta tell us the relevant information up front. :) If I create the inspector panel in the document nib and bind the array controller to the File's Owner everything works great. It is when I try to create an inspector panel in a separate nib that something goes wrong. The error message Cannot perform operation without a managed object context indicates the binding is not working. I think this is my problem. Er, no. You want one inspector for all documents, so loading a new panel for each document is simply not the answer. On Aug 1, 2009, at 09:32, Richard Somers wrote: Upon further investigation I have discovered that my window controller -document method returns nil. So as far as the binding is concerned I have no document and no managed object context. I thought the -document method would automatically return a pointer to my persistent document but that is not the case. Yes, that's what I said earlier. Excuse me for being facetious, but when you say automatically you mean magically, and there's no magic here. The document property of a window controller gets set to a non-nil value *because and only because* the window controller is added to the list of the document's window controllers. (See [NSDocument addWindowController:].) Otherwise, the window controller is freestanding, and if it wants some document's object pointer (or the document's managed object context pointer) it has to use a different strategy. So how do I get my NSWindowController subclass -document method to return a pointer to my persistent document? In your scenario, you don't. Your panel needs to switch from document to document over time, so forget about [self document] in its window controller. What you want is for the inspector to reflect the state of the *frontmost* document window -- that is, the current main window. So, one strategy is to override 'windowDidBecomeMain:' and/or 'windowDidResignMain:' in your document window controller, and have the document window controller message the panel's window controller directly (which is a singleton and therefore can be referenced via a static variable, or via an instance variable of the app delegate). Another strategy is for the panel window controller to register itself as an observer of *all* NSWindowDidBecomeMain and NSWindowDidResignMain notifications, and to switch itself based on the notifying window. (You can get the window out of the NSNotification object, and use '[[[window windowController] document] isKindOfClass: [MyDocument class]]' to find out whether the window is one of your document windows.) HTH ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: incorrect checksum for freed object
i'm using pointer to pointer (sometimes called handles) because that is what is required when using the usb aspects of the IOKit as demonstated in apple's sample code. FYI, Ken's right. The IOUSB stuff is odd-looking. You have instance vars of type IOxxx**, and then pass the addresses of those into routines that take IOxxx*** and fill in your IOxxx** and then you do (*iovar)-Function throughout the code. Still though, Shawn's basic point is right: Ken is confused about memory management *somewhere* in his code. -- Scott Ribe scott_r...@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice ___ 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: Disabling Undo in Core Data
On 2009 Aug 01, at 05:11, Squ Aire wrote: 1) disableUndoRegistration ... NSManagedObjectContextObjectsDidChangeNotification will stop being sent when the context changes! I'd call that a bug, at least in the documentation. It is implied in a roundabout way... The notification is posted during processPendingChanges, and then if you look up -processPendingChanges, causes changes to registered managed objects to be recorded with the undo manager. But if it's true that NSManagedObjectContextObjectsDidChangeNotification falls silent if undo is disabled, at least the documentation should so state. When I first started reading Core Data I thought that NSManagedObjectContextObjectsDidChangeNotification would be quite a useful and simpler one stop alternative to KVO, but then learned that it is quite limited. You've just discovered another limitation. 2) Which brings me to the second option. Keep the undo stuff there so that the NSManagedObjectContextObjectsDidChangeNotification will properly be sent out, as I want. However, instead just get rid of the Undo and Redo menu items. I'd say it's quite reliable! might be an option, but might be a bad one in case I would one day like to add undoing for some selected feature in my app. It is rarely a good decision in this business to not use an easy solution because of what you might want to do one day. The world moves too fast. ___ 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: Disabling Undo in Core Data
In fact, the NSManagedObjectContextObjectsDidChangeNotification is working nicely for my purposes, given that it is indeed being sent! So, solution 2) you seem to like. When I said one day I actually meant to say that I plan on supporting undo for some selected features in my app, especially if my users request them. So it's not something far in the future thing. So how about this: a) Leave the Core Data undo manager running (so that the NSManagedObjectContextObjectsDidChangeNotification will be sent properly). b) Get rid of the Undo and Redo menu items. c) When I need undo/redo for a particular feature, just add the Undo and Redo menu items again but connect them not to the default stuff but my own thing--my own custom undo manager stuff. Sounds good enough? From: je...@ieee.org To: cocoa-dev@lists.apple.com Date: Sat, 1 Aug 2009 12:38:00 -0700 Subject: Re: Disabling Undo in Core Data On 2009 Aug 01, at 05:11, Squ Aire wrote: 1) disableUndoRegistration ... NSManagedObjectContextObjectsDidChangeNotification will stop being sent when the context changes! I'd call that a bug, at least in the documentation. It is implied in a roundabout way... The notification is posted during processPendingChanges, and then if you look up -processPendingChanges, causes changes to registered managed objects to be recorded with the undo manager. But if it's true that NSManagedObjectContextObjectsDidChangeNotification falls silent if undo is disabled, at least the documentation should so state. When I first started reading Core Data I thought that NSManagedObjectContextObjectsDidChangeNotification would be quite a useful and simpler one stop alternative to KVO, but then learned that it is quite limited. You've just discovered another limitation. 2) Which brings me to the second option. Keep the undo stuff there so that the NSManagedObjectContextObjectsDidChangeNotification will properly be sent out, as I want. However, instead just get rid of the Undo and Redo menu items. I'd say it's quite reliable! might be an option, but might be a bad one in case I would one day like to add undoing for some selected feature in my app. It is rarely a good decision in this business to not use an easy solution because of what you might want to do one day. The world moves too fast. ___ 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/squ4r3%40live.com This email sent to squ...@live.com _ Share your memories online with anyone you want. http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1___ 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: Disabling Undo in Core Data
On Aug 1, 2009, at 12:38, Jerry Krinock wrote: On 2009 Aug 01, at 05:11, Squ Aire wrote: 2) Which brings me to the second option. Keep the undo stuff there so that the NSManagedObjectContextObjectsDidChangeNotification will properly be sent out, as I want. However, instead just get rid of the Undo and Redo menu items. I'd say it's quite reliable! If that's going to be the solution, I'd suggest also doing 'document.undoManager.levelsOfUndo = 1'. (In OldSpeak: '[[document undoManager] setLevelsOfUndo: 1]'.) WRT the larger issue, we know that there's nothing accidental in the Core Data APIs. It's *possible* that this is a defect in the Core Data design (needing undo enabled in order to get change notifications), but it's also *possible* that there's a carefully thought-out reason why the two things are linked. (For example, that the information needed to produce the notifications is precisely the same as the information needed for undo. So, beyond removing the menu items and limiting the number of undo actions as above, the perceived need to turn off Core Data undo may be imaginary.) Did you post here in general about the limitations you found in using the notifications? It's likely you posted specifics, but was there a higher level discussion that I don't recall? ___ 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: Disabling Undo in Core Data
On Aug 1, 2009, at 5:11 AM, Squ Aire wrote: 1) In awakeFromNib, call either [[self managedObjectContext] setUndoManager:nil]; or [[[self managedObjectContext] undoManager] disableUndoRegistration]; This certainly works, but the problem with this is that the NSManagedObjectContextObjectsDidChangeNotification will stop being sent when the context changes! It's not clear why you make this assertion? A simple test shows this is not the case... Did you register for NSManagedObjectContextObjectsDidChangeNotification or @NSManagedObjectContextObjectsDidChangeNotification? mmalc ___ 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 change focus ring color?
On 02.08.2009, at 0:14, Joel Norvell framewor...@yahoo.com wrote:
If your object is always the First Responder, that would account for
its focus ring always being redrawn.
As I've tested it with the code samples from your links, it's NOT the
first resonder. I don't see any drawings if I surround the drawing
code by if ([self showsFirstResponder]) operator.
There's a lot of good information available, but you have to look
around a bit to find it.
I've checked the links. Thanks. At least I see the way now.
Nevertheless my main problem is still unresolved - I can't change the
color of the focus ring. I used this code:
- (void)drawWithFrame:(NSRect)cellFrame inView:(NSView *)controlView {
[super drawWithFrame:cellFrame inView:controlView];
//if ([self showsFirstResponder]) {
// showsFirstResponder is set for us by the NSControl that is
drawing us.
NSRect focusRingFrame = cellFrame;
focusRingFrame.size.height -= 2.0;
[NSGraphicsContext saveGraphicsState];
NSSetFocusRingStyle(NSFocusRingOnly);
[[NSColor brownColor] setStroke];
[[NSBezierPath bezierPathWithRect: NSInsetRect(focusRingFrame,
4,4)] stroke];
^
^
^
^
^
^
^^
//[[self focusRingPath] stroke];
[NSGraphicsContext restoreGraphicsState];
//}
// other stuff might happen here
}
I don't see any ring if I comment the line above, marked with ^.
And I see just the same blue ring, if I uncomment it. I tried NSColor
set, NSColor setFill, NSBezierPath fill - all with the same result. I
can't set another color. What is wrong in my code?
Thanks.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
RE: Disabling Undo in Core Data
Ah, it is interesting that you say this, because now suddenly I realize that
the problem might be related to bindings (although I'm not sure).
Please follow these simple steps to make a very simple test app that
demonstrates my issue:
1) Create a new Core Data Application project in Xcode.
2) Add an Employee entity with the 'name' (String) attribute.
3) Open the XIB file, and onto the window add a table view with one column and
two buttons called Add and Remove.
4) Add an NSArrayController into the XIB. Bind it to the app delegate's
managedObjectContext and set the Employee entity and Prepares content as
usual.
5) Bind the table column to the array controller's arrangedObjects.name as
usual.
6) Connect the Add and Remove buttons to the NSArrayController's add: and
remove: methods respectively.
7) Back in the code, paste the following into the app delegate's source file:
- (void)awakeFromNib
{
NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
[nc addObserver:self
selector:@selector(contextChanged:)
name:NSManagedObjectContextObjectsDidChangeNotification
object:[self managedObjectContext]];
}
- (void)contextChanged:(NSNotification *)note
{
NSSet *inserted = [[note userInfo] objectForKey:NSInsertedObjectsKey];
NSSet *updated = [[note userInfo] objectForKey:NSUpdatedObjectsKey];
NSSet *deleted = [[note userInfo] objectForKey:NSDeletedObjectsKey];
NSLog(@contextChanged. inserted %d. updated %d. deleted %d.,
[inserted count],[updated count],[deleted count]);
}
8) Play with this app. You will see that the notifications are properly getting
sent.
9) Now add [[[self managedObjectContext] undoManager]
disableUndoRegistration]; to the top of awakeFromNib.
10) As you now play with the app, you will notice that the notification is NOT
getting sent except when the app quits (and the context saves).
Can you guys help me analyze why, when using bindings like this,
NSManagedObjectContextObjectsDidChangeNotification is not getting sent anymore
when undo is disabled?
From: mmalc_li...@me.com
Date: Sat, 1 Aug 2009 13:58:07 -0700
To: cocoa-dev@lists.apple.com
Subject: Re: Disabling Undo in Core Data
On Aug 1, 2009, at 5:11 AM, Squ Aire wrote:
1) In awakeFromNib, call either [[self managedObjectContext]
setUndoManager:nil]; or [[[self managedObjectContext]
undoManager] disableUndoRegistration]; This certainly works, but
the problem with this is that the
NSManagedObjectContextObjectsDidChangeNotification will stop being
sent when the context changes!
It's not clear why you make this assertion? A simple test shows this
is not the case...
Did you register for
NSManagedObjectContextObjectsDidChangeNotification or
@NSManagedObjectContextObjectsDidChangeNotification?
mmalc
_
Drag n’ drop—Get easy photo sharing with Windows Live™ Photos.
http://www.microsoft.com/windows/windowslive/products/photos.aspx___
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
NSCollectionView and initWithCoder
Hi, I programmatically create a NSCollectionView and set my own prototype view containing my own objects. These objects are subclasses of NSView containing other subviews, for example I have a XXView object containing an NSTextView defined by the variable mTextView. Now when I get the several items in the NSCollectionView with newItemForRepresentedObject, I quite see XXView containing the NSTextView but the variable mTextView is NULL, so I cannot longer work with it. My question is: Since the prototype view and its subviews are created by initWithCoder, how can I save/restore the variable mTextView? I should not create again the NSTextView subview because it already exists within XXView. I just need to relink the variable mTextView to the NSTextView view. How to do that? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSURLConnection performance on iPhone
Hi All: I'm working on a small iPhone project this weekend that among other things downloads some medium sized video files. To do this I set up a NSURLConnection and use an NSOutputStream to write the data to my apps' documents folder as it arrives. The only problem is that I'm seeing lousy download speed, particularly over wifi (~200K/sec over 3G, 100K/sec over wifi). Any ideas as to why this might be or if there is anything I can do to improve things? Currently in connection:didReceiveData: I append the incoming data to a temporary buffer (mutable data obj) and then every ~1MB I write it out to disk using my output stream. I do this because writing the stream to disk every time I received data was even slower. Thanks for any thoughts, -Ben -- Ben Lachman Acacia Tree Software http://acaciatreesoftware.com email: blach...@mac.com twitter: @benlachman mobile: 740.590.0009 ___ 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
