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 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 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.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: How to change focus ring color?
Hi Alexander, If your object is always the First Responder, that would account for its focus ring always being redrawn. There's a lot of good information available, but you have to look around a bit to find it. Googling for - cocoa draw focus ring - shows some good results. The 2005 thread, "How to draw keyboard focus ring around a custom control?" on Cocoa-dev was my guide when I implemented custom focus rings. (A very belated "thank you" to Sean McBride, Ricky Sharp, Alastair Houghton and Scott Anguish!) Sincerely, Joel http://www.cocoabuilder.com/archive/message/cocoa/2005/5/12/135670 http://developer.apple.com/SampleCode/Clock_Control/index.html http://developer.apple.com/documentation/Cocoa/Conceptual/ControlCell/Articles/ManipulateCellControl.html ___ 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: IPhone Textview question
I left out a crucial bit of information not realizing it was crucial. I was using the NSURLConnection synchronous request every 4 seconds on the main thread. I noticed that in some circumstances I had a fairly regular lag spike. Almost timed to exactly 4 seconds, the time span of my ticker. I moved all timed requests to separate threads and the lag is gone. Now I get a pile up when you have a not so good internet connection but it sorts itself out. On Jul 31, 2009, at 10:06 PM, Luke Hiesterman wrote: I'd make sure your tester is using at least os 3.0. I seem to recall slow typing issues in 2.x Luke Sent from my iPhone. On Jul 31, 2009, at 9:20 PM, Development wrote: I'm working on an app and it is fairly large. well... maybe not it's about 1.1 megs. I save as much memory as I can but I think its not enough. When typing in text fields and text views I get this strange lag in the keys. Do any of you happen to know what might cause this? I've turned off auto correction thinking that might be part of the problem but it does not seem to help too much. What can I be doing wrong that coul cause this kind of lag? On one of my testers phones he says he cant use the app it slows down so much but on my ipod I cannot reproduce. April. ___ 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/luketheh%40apple.com This email sent to luket...@apple.com ___ 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 12:09 PM -0600 8/1/09, Scott Ribe wrote: > 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. well... i'm not sure i'd use the word confused, as i do understand memory management, both in general and in cocoa. but i do have a bug somewhere that causes crashes sometimes when i quit by app and attempt to release IOKit/USB "resources". unfortunately, the bug hasn't shown up when i've run with guard malloc on, and the times that i've hit the malloc_error_break breakpoint, the stack trace hasn't helped, and i always run my development versions with zombies, etc. enabled. for now, i'm just waiting until the crashes start again so that i can again try to find it. ken -- 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 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
Re: How to change focus ring color?
On 02/08/2009, at 7:05 AM, Alexander Bokovikov wrote: NSSetFocusRingStyle(NSFocusRingOnly); I may be wrong, but my understanding was that this sets up some sort of special mode in the graphics context that draws the focus ring as a special case. If you notice, the ring is not a simple solid colour but some kind of gradient. I also think that it doesn't matter what colour you set, it will be ignored and the focus ring drawn by the graphics system using the colour internally set (by the current theme effectively, but that can't be changed). The short answer is - you cannot do what you are trying to do. If you must have a custom focus ring colour (why?) then you will have to draw it entirely yourself and avoid setting this special mode. --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
