Re: iPad: CGPDF... methods and leak/cache
On 07.07.2010, at 19:35, Kyle Sluder wrote: > On Wed, Jul 7, 2010 at 10:21 AM, sebi wrote: >> When I get a memory warning I unload most of the images and I also release >> the current CGPDFDocumentRef which should release the memory. >> Unfortunately it doesn't. ObjectAlloc shows me that I have thousands of >> small memory blocks hanging around between 8 bytes and 32 kilobytes that >> somehow were created in the CGPDF... methods. > > I believe this is a known bug, as described in this thread: > http://lists.apple.com/archives/quartz-dev/2010/Apr/msg00024.html > > quartz-dev is a more appropriate list for this thread. > > --Kyle Sluder > Thanks a lot! Regards, Sebastian Mecklenburg___ 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: Sanity Check
On 7 Jul 2010, at 21:07, k...@highrolls.net wrote:
> Does this code make sense? Where
>
> [[ SewAndColorController alloc] initWithWindowNibName:@"nibName"]
>
> is called from another view action?
>
>
> @interface SewAndColorController : NSWindowController {
>
> NSPanel *m_panel;
> }
>
> @end
>
> #import "SewAndColorController.h"
>
> @implementation SewAndColorController
>
> - (id) initWithWindowNibName:(NSString*)windowNibName
> {
> self = [super initWithWindowNibName:windowNibName];
> if (self != nil)
> {
> [self retain];
> m_panel = [self window];
> [m_panel setDelegate:self];
> [m_panel makeKeyAndOrderFront:self];
This seems weird. Why assign the panel/window to your own ivar when this is
exactly -[NSWindowController window] is designed to do for you?
> }
> return self;
> }
> @end
___
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 catch [NSEvent dealloc]?
>> In that case I'd guess you might want to use method swizzling on >> -[NSEvent dealloc]: >> >> http://www.cocoadev.com/index.pl?MethodSwizzling >> >> Beware that swizzling is a powerful and dangerous technique, and you >> want to code your override with the utmost caution, but it's a great >> way to intercept methods like this. >> Mike > Since the event is application-defined, any handler will, of course, also be > application-defined. > Can't you handle this in the handler? Or, alternatively, in an override of > -[NSApplication sendEvent:]? > Regards, > Ken That's what I'm currently doing - releasing the referenced object in an override of sendEvent. The problem is that events don't always go through there (in a modal tracking loop, specifically) so I need handle that case too. Why? Well, it's too complicated to go into here but I actually play all kinds of games with event handling in order to emulate the Windows API, which has a rather different view of the world. It's not my most favourite piece of code. Strangely, if you post a mouse or keyboard event to the input queue, the event that is eventually delivered is a copy of the original, rather than the event you actually posted. Why this should be I don't know but it makes life much harder for me. So I shall ponder my options. What I have works, but I have had one crash report from the field (just one) where my referenced object pointer was obviously stale so there must be a little loophole in there somewhere. Thanks for the input guys, much appreciated. Regards, Paul Sanders. ___ 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: Sanity Check
his seems weird. Why assign the panel/window to your own ivar when
this is exactly -[NSWindowController window] is designed to do for
you?
I was thinking I might need to reference it and rather than call for
it just have it hanging around. Yes, no?
-koko
On Jul 8, 2010, at 4:44 AM, Mike Abdullah wrote:
On 7 Jul 2010, at 21:07, k...@highrolls.net wrote:
Does this code make sense? Where
[[ SewAndColorController alloc] initWithWindowNibName:@"nibName"]
is called from another view action?
@interface SewAndColorController : NSWindowController {
NSPanel *m_panel;
}
@end
#import "SewAndColorController.h"
@implementation SewAndColorController
- (id) initWithWindowNibName:(NSString*)windowNibName
{
self = [super initWithWindowNibName:windowNibName];
if (self != nil)
{
[self retain];
m_panel = [self window];
[m_panel setDelegate:self];
[m_panel makeKeyAndOrderFront:self];
This seems weird. Why assign the panel/window to your own ivar when
this is exactly -[NSWindowController window] is designed to do for
you?
}
return self;
}
@end
___
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: Sanity Check
Thanks Ken. I'll do 2. -koko On Jul 7, 2010, at 6:15 PM, Ken Thomases wrote: On Jul 7, 2010, at 6:09 PM, k...@highrolls.net wrote: Even though it would be better style would my approach cause any problem? I don't see any. Yes. You alloc+init and you also retain. Then, you (presumably) only release once when the panel closes. Thus, you are leaking the window controller. If you're going to go with a self-owning window controller, then either: 1) You should not retain self and the release on close balances the alloc. OR 2) The code which does the alloc should also release (balanced), and the window controller should both retain and release itself (balanced). If you insist on going this route, I guess I recommend 2 since it makes it clearer that both pieces of code balance their own responsibilities. With 1, the responsibilities are split between two unrelated parts of the code. 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: Sanity Check
\On Thu, Jul 8, 2010 at 7:19 AM, wrote: >> his seems weird. Why assign the panel/window to your own ivar when this is >> exactly -[NSWindowController window] is designed to do for you? > > I was thinking I might need to reference it and rather than call for it just > have it hanging around. Yes, no? You can already get at it by calling -window. There's no need to duplicate that functionality by putting it in an ivar. --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: Sanity Check
On Thu, Jul 8, 2010 at 10:19 AM, wrote: >> his seems weird. Why assign the panel/window to your own ivar when this is >> exactly -[NSWindowController window] is designed to do for you? > > I was thinking I might need to reference it and rather than call for it just > have it hanging around. Yes, no? Did you profile (with Shark or Instruments) your code, and did the profiler tell you that calls to -window are taking up a significant amount of your app's time? If not, what you're doing is called "premature optimization," and it's generally considered a bad idea. sherm-- -- Cocoa programming in Perl: http://www.camelbones.org ___ 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: Programmatically closing a submenu (NSMenu)
On Jul 7, 2010, at 4:20 PM, augusto callejas wrote: > hi- > > i have an NSMenu that has another NSMenu as a submenu (via an NSMenuItem). > in a certain situation, when the submenu is visible, i want to close that > submenu, but without closing the main NSMenu. > the documentation for [NSMenu cancelTracking] says it dismisses the menu, but > when i call that on the submenu, > it dismisses the submenu but also the main NSMenu. > > how can i only close a submenu without affecting the main menu? There is no way to do that using Carbon or Cocoa API. You might be able to trick the menu system into closing the submenu by posting a left arrow keydown/keyup pair to the event queue - I haven't tried that, and it would be fragile. -eric ___ 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: Sanity Check
I have taken all advice and the code now looks like below which cleans
up the pointed out controller leak and does not store [self window]:
- (IBAction)sewing:(id)sender {
[[[SewingController alloc] initWithWindowNibName:@"Sewing and Color"
andBFileName:&mBFilename] release];
}
- (id) initWithWindowNibName:(NSString*)windowNibName andBFileName:
(BFilename*)bfilename
{
self = [super initWithWindowNibName:windowNibName];
if (self != nil)
{
[self retain];
m_design = [[self window] contentView];
[[self window] setDelegate:self];
}
return self;
}
- (void)windowWillClose:(NSNotification *)notification {
if(m_design->m_dirtyDesign)
NSLog(@"dirty message");
else
NSLog(@"clean, no message");
[self release];
}
On Jul 8, 2010, at 9:03 AM, Sherm Pendley wrote:
On Thu, Jul 8, 2010 at 10:19 AM, wrote:
his seems weird. Why assign the panel/window to your own ivar when
this is
exactly -[NSWindowController window] is designed to do for you?
I was thinking I might need to reference it and rather than call
for it just
have it hanging around. Yes, no?
Did you profile (with Shark or Instruments) your code, and did the
profiler tell you that calls to -window are taking up a significant
amount of your app's time? If not, what you're doing is called
"premature optimization," and it's generally considered a bad idea.
sherm--
--
Cocoa programming in Perl:
http://www.camelbones.org
___
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: Sanity Check
> I have taken all advice and the code now looks like below which cleans up the
> pointed out controller leak and does not store [self window]:
There still seems to be some problems with your code...
> - (IBAction)sewing:(id)sender {
>
> [[[SewingController alloc] initWithWindowNibName:@"Sewing and Color"
> andBFileName:&mBFilename] release];
> }
You allocate and immediately release the controller here... not quite sure what
you're trying to do here, but that basically means you don't have a controller
object, and your window will not stay onscreen. Have you actually tested this
code?
> - (id) initWithWindowNibName:(NSString*)windowNibName
> andBFileName:(BFilename*)bfilename
> {
> self = [super initWithWindowNibName:windowNibName];
> if (self != nil)
> {
> [self retain];
> m_design = [[self window] contentView];
>
>
> [[self window] setDelegate:self];
> }
> return self;
> }
Once again, no point in hanging on to the content view and storing it in an
ivar, because just like the window, it's easily accessible from -window
-contentView. Unless it's a custom view, but I do not see a cast here... Also,
do you have a reason for retaining self?
>
> - (void)windowWillClose:(NSNotification *)notification {
>
> if(m_design->m_dirtyDesign)
> NSLog(@"dirty message");
> else
> NSLog(@"clean, no message");
> [self release];
> }
This -release is interesting as
well.___
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: Programmatically highlighting an NSMenuItem
i'm trying to replicate the functionality of spotlight using an embedded NSSearchField inside an NSMenu. when a search is performed, i add NSMenuItems to the NSMenu. when you perform a search in spotlight, the first search result is highlighted and you can immediately use the up/down arrows to traverse the results. i'd like to do the same by highlighting the first result in my NSMenu (which is an NSMenuItem). since spotlight has the same behavior, then it seems like an experience a user is familiar with. augusto. On Jul 7, 2010, at 6:29 PM, Graham Cox wrote: > > On 08/07/2010, at 11:00 AM, Kyle Sluder wrote: > >> Does NSMenuItemCell match the appearance of menus on 10.5? > > > No. I noticed this in the docs just after posting: "Note: NSMenuItemCell is > no longer used to draw menus. Using it will not affect the appearance of your > menus." > > Maybe the OP ought to tell us why he needs this, sounds like one of those > 'don't do it that way' cases. > > --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: Programmatically highlighting an NSMenuItem
On 09/07/2010, at 2:30 AM, Augusto Callejas wrote: > i'm trying to replicate the functionality of spotlight using an embedded > NSSearchField inside an NSMenu. > when a search is performed, i add NSMenuItems to the NSMenu. when you > perform a search in spotlight, > the first search result is highlighted and you can immediately use the > up/down arrows to traverse the > results. i'd like to do the same by highlighting the first result in my > NSMenu (which is an NSMenuItem). > since spotlight has the same behavior, then it seems like an experience a > user is familiar with. It looks to me as if Spotlight isn't a menu at all, it's just putting up a window that looks a bit like one (not that there's much of a distinction anyway, NSMenus are windows internally). Maybe just do the whole thing in a custom 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: Sanity Check
On Thu, Jul 8, 2010 at 8:57 AM, wrote:
> - (IBAction)sewing:(id)sender {
>
> [[[SewingController alloc] initWithWindowNibName:@"Sewing and Color"
> andBFileName:&mBFilename] release];
This is entirely wrong. Why would you create an object just to
immediately release it? Please review the Cocoa Memory Management
Guide:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html
> }
>
>
>
> - (id) initWithWindowNibName:(NSString*)windowNibName
> andBFileName:(BFilename*)bfilename
> {
> self = [super initWithWindowNibName:windowNibName];
> if (self != nil)
> {
> [self retain];
This is insanity. Again, please reread the memory management guide.
> m_design = [[self window] contentView];
>
>
> [[self window] setDelegate:self];
Why don't you just make these outlets and wire them up in Interface
Builder? And even if you wanted to do this in code for some reason,
the appropriate place to do it would be in -windowDidLoad. Right now
you're loading the window from within the initializer, which is wrong.
> }
> return self;
> }
>
> - (void)windowWillClose:(NSNotification *)notification {
>
> if(m_design->m_dirtyDesign)
> NSLog(@"dirty message");
> else
> NSLog(@"clean, no message");
If you're writing a document-based application, NSDocument does dirty
tracking for you already.
> [self release];
Again, read the memory management guide. Perhaps consider investing in
Aaron Hillegass's Cocoa Programming for Mac OS X.
> }
--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: Programmatically highlighting an NSMenuItem
yes i know its not a real menu, but given it mostly behaves like one, i was trying to use existing functionality without having to rewrite the menu-ing system. thanks, augusto. On Jul 8, 2010, at 9:38 AM, Graham Cox wrote: > > On 09/07/2010, at 2:30 AM, Augusto Callejas wrote: > >> i'm trying to replicate the functionality of spotlight using an embedded >> NSSearchField inside an NSMenu. >> when a search is performed, i add NSMenuItems to the NSMenu. when you >> perform a search in spotlight, >> the first search result is highlighted and you can immediately use the >> up/down arrows to traverse the >> results. i'd like to do the same by highlighting the first result in my >> NSMenu (which is an NSMenuItem). >> since spotlight has the same behavior, then it seems like an experience a >> user is familiar with. > > > It looks to me as if Spotlight isn't a menu at all, it's just putting up a > window that looks a bit like one (not that there's much of a distinction > anyway, NSMenus are windows internally). > > Maybe just do the whole thing in a custom 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: Programmatically highlighting an NSMenuItem
On Thu, Jul 8, 2010 at 9:57 AM, augusto callejas wrote: > yes i know its not a real menu, but given it mostly behaves like one, > i was trying to use existing functionality without having to rewrite the > menu-ing system. Given that you're going to want to do a significant amount of custom work, it's probably better for your own sanity that you can't work from within NSMenu to do this. I don't imagine dispatching Cocoa events from within a view-based menu item to be a fun time. If it helps, +[NSMenu selectedMenuItemColor] is a magic color that gives you the 10.5 and later gradient appearance. So at least you don't have to reimplement that yourself. --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: Programmatically highlighting an NSMenuItem
On Jul 8, 2010, at 9:34 AM, augusto callejas wrote: > i'm trying to replicate the functionality of spotlight using an embedded > NSSearchField inside an NSMenu. > when a search is performed, i add NSMenuItems to the NSMenu. when you > perform a search in spotlight, > the first search result is highlighted and you can immediately use the > up/down arrows to traverse the > results. i'd like to do the same by highlighting the first result in my > NSMenu (which is an NSMenuItem). > since spotlight has the same behavior, then it seems like an experience a > user is familiar with. I think you will find it sufficiently difficult to fully implement the behaviors you want using a regular menu, that it would really be better to use a custom view for the entire thing. I know it seems like a menu could get you almost all the way there, but that last 20% is going to be really painful. -eric ___ 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: Sanity Check
On Jul 8, 2010, at 10:30 AM, John Johnson wrote:
I have taken all advice and the code now looks like below which
cleans up the pointed out controller leak and does not store [self
window]:
There still seems to be some problems with your code...
- (IBAction)sewing:(id)sender {
[[[SewingController alloc] initWithWindowNibName:@"Sewing and
Color" andBFileName:&mBFilename] release];
}
The controller is retained in the init method and released when the
window closes so this release is to balance the alloc ... in the
object where the controller is instanced I do not need a reference to
it, I just need to get a window displayed.
You allocate and immediately release the controller here... not
quite sure what you're trying to do here, but that basically means
you don't have a controller object, and your window will not stay
onscreen. Have you actually tested this code?
- (id) initWithWindowNibName:(NSString*)windowNibName andBFileName:
(BFilename*)bfilename
{
self = [super initWithWindowNibName:windowNibName];
if (self != nil)
{
[self retain];
m_design = [[self window] contentView];
[[self window] setDelegate:self];
}
return self;
}
Once again, no point in hanging on to the content view and storing
it in an ivar, because just like the window, it's easily accessible
from -window -contentView. Unless it's a custom view, but I do not
see a cast here... Also, do you have a reason for retaining self?
just for easier coding as there is code I haven't shown (proprietary
issue) that uses ivars in the content view.
self is retained because it is released where the allc/init call was
made
- (void)windowWillClose:(NSNotification *)notification {
if(m_design->m_dirtyDesign)
NSLog(@"dirty message");
else
NSLog(@"clean, no message");
[self release];
}
This -release is interesting as well.
so now release it , I am done 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 arch...@mail-archive.com
Re: Sanity Check
On Jul 8, 2010, at 10:41 AM, Kyle Sluder wrote:
On Thu, Jul 8, 2010 at 8:57 AM, wrote:
- (IBAction)sewing:(id)sender {
[[[SewingController alloc] initWithWindowNibName:@"Sewing
and Color"
andBFileName:&mBFilename] release];
This is entirely wrong. Why would you create an object just to
immediately release it? Please review the Cocoa Memory Management
Guide:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html
Because I retain it in the init method , I don't need a reference to
it where the alloc is called
}
- (id) initWithWindowNibName:(NSString*)windowNibName
andBFileName:(BFilename*)bfilename
{
self = [super initWithWindowNibName:windowNibName];
if (self != nil)
{
[self retain];
This is insanity. Again, please reread the memory management guide.
m_design = [[self window] contentView];
[[self window] setDelegate:self];
Why don't you just make these outlets and wire them up in Interface
Builder? And even if you wanted to do this in code for some reason,
the appropriate place to do it would be in -windowDidLoad. Right now
you're loading the window from within the initializer, which is wrong.
Ok, I understand -windowDidLoad is the place for these
}
return self;
}
- (void)windowWillClose:(NSNotification *)notification {
if(m_design->m_dirtyDesign)
NSLog(@"dirty message");
else
NSLog(@"clean, no message");
If you're writing a document-based application, NSDocument does dirty
tracking for you already.
Not document based
[self release];
Again, read the memory management guide. Perhaps consider investing in
Aaron Hillegass's Cocoa Programming for Mac OS X.
this release balances the retain in the init method seems correct to me
}
--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: Sanity Check
On Thu, Jul 8, 2010 at 10:19 AM, wrote:
>
> On Jul 8, 2010, at 10:41 AM, Kyle Sluder wrote:
>
>> On Thu, Jul 8, 2010 at 8:57 AM, wrote:
>>>
>>> - (IBAction)sewing:(id)sender {
>>>
>>> [[[SewingController alloc] initWithWindowNibName:@"Sewing and
>>> Color"
>>> andBFileName:&mBFilename] release];
>>
>> This is entirely wrong. Why would you create an object just to
>> immediately release it? Please review the Cocoa Memory Management
>> Guide:
>> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html
>
> Because I retain it in the init method , I don't need a reference to it
> where the alloc is called
Retaining self in -init is wrong. It doesn't matter if it works.
>
>>
>>> }
>>>
>>>
>>>
>>> - (id) initWithWindowNibName:(NSString*)windowNibName
>>> andBFileName:(BFilename*)bfilename
>>> {
>>> self = [super initWithWindowNibName:windowNibName];
>>> if (self != nil)
>>> {
>>> [self retain];
>>
>> This is insanity. Again, please reread the memory management guide.
>>
>>> m_design = [[self window] contentView];
>>>
>>>
>>> [[self window] setDelegate:self];
>>
>> Why don't you just make these outlets and wire them up in Interface
>> Builder? And even if you wanted to do this in code for some reason,
>> the appropriate place to do it would be in -windowDidLoad. Right now
>> you're loading the window from within the initializer, which is wrong.
>
> Ok, I understand -windowDidLoad is the place for these
>>
>>> }
>>> return self;
>>> }
>>>
>>> - (void)windowWillClose:(NSNotification *)notification {
>>>
>>> if(m_design->m_dirtyDesign)
>>> NSLog(@"dirty message");
>>> else
>>> NSLog(@"clean, no message");
>>
>> If you're writing a document-based application, NSDocument does dirty
>> tracking for you already.
>
> Not document based
>>
>>> [self release];
>>
>> Again, read the memory management guide. Perhaps consider investing in
>> Aaron Hillegass's Cocoa Programming for Mac OS X.
>
> this release balances the retain in the init method seems correct to me
It is not.
>>
>>> }
>>
>> --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: Sanity Check
Le 8 juil. 2010 à 19:34, Kyle Sluder a écrit : >> Because I retain it in the init method , I don't need a reference to it >> where the alloc is called > > Retaining self in -init is wrong. It doesn't matter if it works. You can retain your controller in -windowDidLoad and (auto)release it in -windowWillClose. That's what I usually do for non-modal windows. For modal window, the problem is even more simple. Vincent___ 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: Programmatically highlighting an NSMenuItem
Le 8 juil. 2010 à 18:57, augusto callejas a écrit : > yes i know its not a real menu, but given it mostly behaves like one, > i was trying to use existing functionality without having to rewrite the > menu-ing system. As far as I know, you cannot use menu to do what you seek to achieve. You would lose focus on the NSTextField you use to type and that would be strange. Don't forget to set the backgroundColor of your custom NSView to clearColor and setOpaque to no. Vincent___ 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: setting focus on NSSearchField in status bar menu item
Can somebody answer this please? On Jul 8, 2010, at 8:41 AM, Nava Carmon wrote: > Hi, > > I added a custom view with a NSSearchField as a first menu item to a status > bar menu. When I run the application from debugger I can click and write in > the NSSearchField. After I go to another application, make it front and click > again on my status menu, the NSSearchField shows, but it's disabled and can't > get focus. The question is how to cause the NSSearchField to get focus each > time, the user clicks to show the menu? > > Thanks, > > Nava > > > Nava Carmon > ncar...@mac.com > > "Think good and it will be good!" > > ___ > > 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/ncarmon%40mac.com > > This email sent to ncar...@mac.com Nava Carmon ncar...@mac.com "Think good and it will be good!" ___ 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: setting focus on NSSearchField in status bar menu item
Le 8 juil. 2010 à 21:26, Nava Carmon a écrit : > Can somebody answer this please? > >> I added a custom view with a NSSearchField as a first menu item to a status >> bar menu. When I run the application from debugger I can click and write in >> the NSSearchField. After I go to another application, make it front and >> click again on my status menu, the NSSearchField shows, but it's disabled >> and can't get focus. The question is how to cause the NSSearchField to get >> focus each time, the user clicks to show the menu? I cannot precisely figure out what you've tried to do, but, as I said in another thread, popping up a menu will make lose focus to any other view, so I am unsure you can add a text editing view to it. Vincent ___ 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: setting focus on NSSearchField in status bar menu item
when you click again on your status menu, try making your app the active app: [NSApp activateIgnoringOtherApps:YES]; augusto. On Jul 8, 2010, at 12:26 PM, Nava Carmon wrote: > Can somebody answer this please? > > On Jul 8, 2010, at 8:41 AM, Nava Carmon wrote: > >> Hi, >> >> I added a custom view with a NSSearchField as a first menu item to a status >> bar menu. When I run the application from debugger I can click and write in >> the NSSearchField. After I go to another application, make it front and >> click again on my status menu, the NSSearchField shows, but it's disabled >> and can't get focus. The question is how to cause the NSSearchField to get >> focus each time, the user clicks to show the menu? >> >> Thanks, >> >> Nava >> >> >> Nava Carmon >> ncar...@mac.com >> >> "Think good and it will be good!" >> >> ___ >> >> 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/ncarmon%40mac.com >> >> This email sent to ncar...@mac.com > > > Nava Carmon > ncar...@mac.com > > "Think good and it will be good!" > > ___ > > 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/acallejas%40appliedminds.com > > This email sent to acalle...@appliedminds.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: setting focus on NSSearchField in status bar menu item
Hi, thank you for answering.
I do the following:
- (void) menuWillOpen:(NSMenu *)menu
{
> [statusItem popUpStatusItemMenu: menu];
> [NSApp activateIgnoringOtherApps:YES];
}
It brings the process to the front, but on first click the menu doesn't stay
open, so i have to click it again to show up.
What is the best practice to implement it anyway?
Thanks,
Nava
On Jul 8, 2010, at 11:25 PM, augusto callejas wrote:
> when you click again on your status menu, try making your app the active app:
>
> [NSApp activateIgnoringOtherApps:YES];
>
> augusto.
>
> On Jul 8, 2010, at 12:26 PM, Nava Carmon wrote:
>
>> Can somebody answer this please?
>>
>> On Jul 8, 2010, at 8:41 AM, Nava Carmon wrote:
>>
>>> Hi,
>>>
>>> I added a custom view with a NSSearchField as a first menu item to a status
>>> bar menu. When I run the application from debugger I can click and write in
>>> the NSSearchField. After I go to another application, make it front and
>>> click again on my status menu, the NSSearchField shows, but it's disabled
>>> and can't get focus. The question is how to cause the NSSearchField to get
>>> focus each time, the user clicks to show the menu?
>>>
>>> Thanks,
>>>
>>> Nava
>>>
>>>
>>> Nava Carmon
>>> ncar...@mac.com
>>>
>>> "Think good and it will be good!"
>>>
>>> ___
>>>
>>> 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/ncarmon%40mac.com
>>>
>>> This email sent to ncar...@mac.com
>>
>>
>> Nava Carmon
>> ncar...@mac.com
>>
>> "Think good and it will be good!"
>>
>> ___
>>
>> 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/acallejas%40appliedminds.com
>>
>> This email sent to acalle...@appliedminds.com
>
Nava Carmon
ncar...@mac.com
"Think good and it will be good!"
___
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: setting focus on NSSearchField in status bar menu item
try delaying displaying the menu through a notification:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(showPopupMenu:)
name:NSApplicationDidBecomeActiveNotification object:nil]
On Jul 8, 2010, at 1:53 PM, Nava Carmon wrote:
> Hi, thank you for answering.
>
> I do the following:
>
> - (void) menuWillOpen:(NSMenu *)menu
> {
>> [statusItem popUpStatusItemMenu: menu];
>> [NSApp activateIgnoringOtherApps:YES];
>
> }
>
> It brings the process to the front, but on first click the menu doesn't stay
> open, so i have to click it again to show up.
>
> What is the best practice to implement it anyway?
>
> Thanks,
>
> Nava
>
> On Jul 8, 2010, at 11:25 PM, augusto callejas wrote:
>
>> when you click again on your status menu, try making your app the active app:
>>
>> [NSApp activateIgnoringOtherApps:YES];
>>
>> augusto.
>>
>> On Jul 8, 2010, at 12:26 PM, Nava Carmon wrote:
>>
>>> Can somebody answer this please?
>>>
>>> On Jul 8, 2010, at 8:41 AM, Nava Carmon wrote:
>>>
Hi,
I added a custom view with a NSSearchField as a first menu item to a
status bar menu. When I run the application from debugger I can click and
write in the NSSearchField. After I go to another application, make it
front and click again on my status menu, the NSSearchField shows, but it's
disabled and can't get focus. The question is how to cause the
NSSearchField to get focus each time, the user clicks to show the menu?
Thanks,
Nava
Nava Carmon
ncar...@mac.com
"Think good and it will be good!"
___
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/ncarmon%40mac.com
This email sent to ncar...@mac.com
>>>
>>>
>>> Nava Carmon
>>> ncar...@mac.com
>>>
>>> "Think good and it will be good!"
>>>
>>> ___
>>>
>>> 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/acallejas%40appliedminds.com
>>>
>>> This email sent to acalle...@appliedminds.com
>>
>
>
> Nava Carmon
> ncar...@mac.com
>
> "Think good and it will be good!"
>
> ___
>
> 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/acallejas%40appliedminds.com
>
> This email sent to acalle...@appliedminds.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: setting focus on NSSearchField in status bar menu item
Tried it,
In awakwFromNib I added:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(showPopupMenu:)
name:NSApplicationDidBecomeActiveNotification object:nil];
added a function:
- (void)showPopupMenu:(NSNotification *)notification
{
[statusItem popUpStatusItemMenu:statusMenu];
}
and in menuWillOpen:
- (void)menuWillOpen:(NSMenu*)menu
{
if (![NSApp isActive]) {
[NSApp activateIgnoringOtherApps:YES];
}
}
It's better now and the menu stays after a slight flickering... It highlights
the title for a sec and unhighlights it. How to get rid of flickering at all?
Thank you very much!
On Jul 8, 2010, at 11:59 PM, augusto callejas wrote:
> [[NSNotificationCenter defaultCenter] addObserver:self
> selector:@selector(showPopupMenu:)
> name:NSApplicationDidBecomeActiveNotification object:nil]
Nava Carmon
ncar...@mac.com
"Think good and it will be good!"
___
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: setting focus on NSSearchField in status bar menu item
not sure how to prevent flickering, this entire approach is hack-ish anyhow :)
On Jul 8, 2010, at 2:09 PM, Nava Carmon wrote:
> Tried it,
>
> In awakwFromNib I added:
>
> [[NSNotificationCenter defaultCenter] addObserver:self
> selector:@selector(showPopupMenu:)
> name:NSApplicationDidBecomeActiveNotification object:nil];
>
> added a function:
>
> - (void)showPopupMenu:(NSNotification *)notification
> {
> [statusItem popUpStatusItemMenu:statusMenu];
> }
>
> and in menuWillOpen:
>
> - (void)menuWillOpen:(NSMenu*)menu
> {
> if (![NSApp isActive]) {
> [NSApp activateIgnoringOtherApps:YES];
> }
> }
>
> It's better now and the menu stays after a slight flickering... It highlights
> the title for a sec and unhighlights it. How to get rid of flickering at all?
>
> Thank you very much!
>
> On Jul 8, 2010, at 11:59 PM, augusto callejas wrote:
>
>> [[NSNotificationCenter defaultCenter] addObserver:self
>> selector:@selector(showPopupMenu:)
>> name:NSApplicationDidBecomeActiveNotification object:nil]
>
>
> Nava Carmon
> ncar...@mac.com
>
> "Think good and it will be good!"
>
> ___
>
> 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/acallejas%40appliedminds.com
>
> This email sent to acalle...@appliedminds.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
ABPeoplePickerView setSources
In various Mac OS X 10.6 Apple apps (e.g., Address Book, iChat, etc.) there are ABPeoplePickerView objects that show sources in the Group column that go beyond the default "On My Mac" group (e.g., LDAP directories, Exchange servers, etc.). When I include an ABPeoplePickerView in my app (from IB), it just defaults to the "On My Mac" group when shown. However, when the ABPeoplePickerView is displayed, it does seem to be picking up my Exchange server settings (as specified in Address Book.app) as it makes a request to both access the Exchange server via HTTP(S) and access my Keychain item for my Exchange account. While the request is made, this Exchange account is not shown in the source list after web call. Is there a way to specify the sources shown in the ABPeoplePickerView source list? If this is private and not possible for third-party apps, why is the view making the request to my Exchange account and is there a way to suppress this request? (It looks suspicious to my users.) Thanks, Jon Nathan ___ 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: setting focus on NSSearchField in status bar menu item
So what is the best and by-the-book approach? Spotlight does it so smooth...
On Jul 9, 2010, at 12:12 AM, augusto callejas wrote:
> not sure how to prevent flickering, this entire approach is hack-ish anyhow :)
>
> On Jul 8, 2010, at 2:09 PM, Nava Carmon wrote:
>
>> Tried it,
>>
>> In awakwFromNib I added:
>>
>> [[NSNotificationCenter defaultCenter] addObserver:self
>> selector:@selector(showPopupMenu:)
>> name:NSApplicationDidBecomeActiveNotification object:nil];
>>
>> added a function:
>>
>> - (void)showPopupMenu:(NSNotification *)notification
>> {
>> [statusItem popUpStatusItemMenu:statusMenu];
>> }
>>
>> and in menuWillOpen:
>>
>> - (void)menuWillOpen:(NSMenu*)menu
>> {
>> if (![NSApp isActive]) {
>> [NSApp activateIgnoringOtherApps:YES];
>> }
>> }
>>
>> It's better now and the menu stays after a slight flickering... It
>> highlights the title for a sec and unhighlights it. How to get rid of
>> flickering at all?
>>
>> Thank you very much!
>>
>> On Jul 8, 2010, at 11:59 PM, augusto callejas wrote:
>>
>>> [[NSNotificationCenter defaultCenter] addObserver:self
>>> selector:@selector(showPopupMenu:)
>>> name:NSApplicationDidBecomeActiveNotification object:nil]
>>
>>
>> Nava Carmon
>> ncar...@mac.com
>>
>> "Think good and it will be good!"
>>
>> ___
>>
>> 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/acallejas%40appliedminds.com
>>
>> This email sent to acalle...@appliedminds.com
>
Nava Carmon
ncar...@mac.com
"Think good and it will be good!"
___
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: setting focus on NSSearchField in status bar menu item
On Thu, Jul 8, 2010 at 2:29 PM, Nava Carmon wrote: > So what is the best and by-the-book approach? Spotlight does it so smooth... As was discussed in the other thread on this topic, don't use an NSMenu for this. --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: setting focus on NSSearchField in status bar menu item
On Jul 8, 2010, at 2:29 PM, Nava Carmon wrote: > So what is the best and by-the-book approach? Spotlight does it so smooth... Spotlight presents its own window and does not use a menu at all. -eric ___ 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: setting focus on NSSearchField in status bar menu item
Can you point me on this thread please? Thanks a lot! On Jul 9, 2010, at 12:36 AM, Kyle Sluder wrote: > On Thu, Jul 8, 2010 at 2:29 PM, Nava Carmon wrote: >> So what is the best and by-the-book approach? Spotlight does it so smooth... > > As was discussed in the other thread on this topic, don't use an > NSMenu for this. > > --Kyle Sluder Nava Carmon ncar...@mac.com "Think good and it will be good!" ___ 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
-processPendingChanges removing changed objects from -updatedObjects list
Hi all,
I'm really stumped by something. The short version is that calling -
[NSManagedObjectContext processPendingChanges] is actually removing
changed managed objects from the list returned by -
[NSManagedObjectContext updatedObjects]. Anyone know why this would
happen?
The long version is as follows:
Background: I have 3 entities, A, B, BRef. BRef acts as a join table
with an index for A and B, because the relationship between As and Bs
needs to remain ordered:
A(name, ...)<--owner--childReferences-->>BRef(index)<<--items--
references-->B(name, url,...)
In A, I have implemented (or rather, been given an implementation of)
a custom setter method setBs: which creates the BRef instances for
each B in the passed array:
- (void)setBs:(NSArray *)children
{
[mCachedChildren release];
mCachedChilren = nil;
mCachedChildren = [children copy];
NSManagedObjectContext *context = [[Library sharedLibrary]
contextForCurrentThread];
NSMutableSet *references = [NSMutableSet set];
for (NSUInteger index = 0; index < children.count; index++) {
B *item = [children objectAtIndex:index];
BRef *reference = [Bref insertInManagedObjectContext:context];
//^^ This is from MOGenerator
reference.item = item;
reference.index = [NSNumber numberWithInteger:index];
[references addObject:reference];
}
NSSet *oldReferences = self.childReferences;
for (BRef *reference in oldReferences) {
[context deleteObject:reference];
}
self.childReferences = references;
}
What I'm doing several stack frames up is to generate a whole bunch of
As from an external data source, the Bs for which already exist. In
the loop to generate them, I take each B, and replace it with a
doppelgänger which comes from a less transient source. I do a fetch
request to get the original B's replacement, populate a replacements
array, and then call the code which calls setBs: above.
So far, everything was working fine.
Then I decided I didn't like the performance of this, and on
investigation, discovered that I was calling [context save:&error]
way, way too much. So I decided I'd go ahead and do all the changes to
the object graph, then write it out in one big save. Sounded like a
great idea, so I did it.
Turned out that there was one little problem: all but the first of my
new As were empty! Well, not empty, but a tableview owned by another
class, AController, was; it conditionally reloads data on the
NSManagedObjectContextObjectsDidChangeNotification; each AController
checks to see if its A is in [[notification userInfo]
objectForKey:NSUpdatedObjectsKey], and refreshes itself if so. (Yes,
there is an AControllerManager, and I realize that it should be the
one registered for that notification, but that's not related to the
problem.)
Clearly the A's are changing: their BRefs are being set. Tracing the
problem and logging the output of [context updatedObjects], I found
that on every first fetch request, the A would be removed from -
updatedObjects list. A little documentation reading and testing
revealed that the -processPendingChanges in the fetch request would
remove the changed B from the list!
So I'm well and truly stumped. Functionally, the only difference
between the code paths were doing before and what they're doing now is
only the frequency of save: operations (incorrectly frequently to none
until the final save). What's really odd is that if I quit and
restart, the As are properly populated with their B doppelgängers, so
the whole object graph IS getting saved properly.
Any help or insight would be greatly appreciated!
Thanks,
Daniel
Daniel DeCovnick
danhd123 at mac dot 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: NSView Docs. Was: Binding -- or not -- a button created in code
Well, I'm still using -[NSView viewWillMoveToWindow:] to remove my observers
and unbind my bindings, with no problems. But I'm still scared that someday it
might not be invoked when a window is closed. So I filed a bug on the
documentation.
Problem ID: 8172493
Title: -[NSView viewWillMoveToWindow:] always invoked when closed?
Summary:
Documentation of -[NSView viewWillMoveToWindow:] does not clearly state that it
is always invoked when a window is closed.
Steps to Reproduce:
In writing a Cocoa app, one needs a method which is reliably called upon in
which to do various cleanups, such as removing the receiver as an observer or
unbinding.
Expected Results:
The desired method should be well-known and documented.
Actual Results:
One needs to hunt around. The -dealloc or -finalize method comes to mind, but
in the Garbage Collection Programming Guide, "... it is best not to attempt any
work in a finalizer. ... Your design goal should therefore be to not have a
finalizer at all. If you must use a finalizer, you should keep it as short as
possible, and reference as few other objects as possible in its
implementation."
So, other methods should be found. For NSView subclasses, developers have been
using -viewWillMoveToWindow:, like this:
- (void)viewWillMoveToWindow:(NSWindow*)window {
if (window && !m_isObserving) {
[self beginObservingStuff] ;
}
else if (!window && m_isObserving) {
[self endObservingStuff] ;
}
[super viewWillMoveToWindow:window] ;
}
However the documentation for -viewWillMoveToWindow: states only that it
"informs the receiver that it’s being added to the view hierarchy of the
specified window object (which may be nil)."
This implies but does not guarantee that -viewWillMoveToWindow: will be
received when a window will be *closed*. I've never seen it not do this, but
such a statement would be a wonderful addition to the Cocoa documentation.
___
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: CoreData and undo/redo : how to add a managed object with attributes already set in the undo/redo stack ?
On Jun 29, 2010, at 22:47 , Sean McBride wrote: > I don't believe that's the right pattern. In awakeFromInsert/Fetch, one > should be using primitive setters. The docs say "If you want to set > attribute values in an implementation of this method, you should > typically use primitive accessor methods (either > setPrimitiveValue:forKey: or--better--the appropriate custom primitive > accessors). This ensures that the new values are treated as baseline > values rather than being recorded as undoable changes for the properties > in question." Oooh, that's what I was looking for :-). Although I did find an alternative solution thanks to a friend, which is to split the creation of the object and its insertion in the MOC : NSManagedObject* newSegment = [[NSManagedObject alloc] initWithEntity:segmentEntity insertIntoManagedObjectContext:nil]; //do some init stuff on newSegment [managedObjectContext insertObject:newSegment]; It's a tad easier than your solution in that I don't need to create a custom class for the CoreData object. Thanks for your replies everyone :-), -- Guillaume http://telegraph-road.org ___ 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: CoreData and undo/redo : how to add a managed object with attributes already set in the undo/redo stack ?
On Jun 28, 2010, at 12:33 , Mike Abdullah wrote: > > On 27 Jun 2010, at 00:01, Guillaume Laurent wrote: > >> Hi all, >> >> I'm having difficulties with the undo/redo mechanism and my Core Data >> objects. The problem is that I create a CoreData object (say a rectangle), >> then set some of its attributes according to some controls values (the >> position and size of a CALayer the user has just created in a view). This >> set of actions is a single one from the user's point of view. I know I can >> make it appear so with NSUndoManager:beginUndoGrouping/endUndoGrouping. But >> when I undo this in the app, each of the steps of the object's creation are >> undone seperately, including the setting of each of the attributes. > > Alarm bells going off here. Even if Core Data wasn't coalescing these changes > into one undo operation, NSUndoManager should do it for you with the > groups-by-event behaviour. Have you turned this off by any chance? No, I didn't. As I said, the problem is that grouping only means that one 'undo' request will result in several undo actions internally. So undoing the creation of a new CoreData Rectangle object (that is, pressing Cmd-Z) results in several actions : one per each initial parameter setting, and then one for the object creation itself. -- Guillaume http://telegraph-road.org ___ 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: CoreData and undo/redo : how to add a managed object with attributes already set in the undo/redo stack ?
On Jun 27, 2010, at 4:08 , Jerry Krinock wrote:
>
> On 2010 Jun 26, at 16:01, Guillaume Laurent wrote:
>
>> I'm having difficulties with the undo/redo mechanism and my Core Data
>> objects.
>
> Uh-huh.
>
>> The problem is that I create a CoreData object (say a rectangle), then set
>> some of its attributes according to some controls values (the position and
>> size of a CALayer the user has just created in a view). This set of actions
>> is a single one from the user's point of view. I know I can make it appear
>> so with NSUndoManager:beginUndoGrouping/endUndoGrouping. But when I undo
>> this in the app, each of the steps of the object's creation are undone
>> seperately, including the setting of each of the attributes.
>
>> Bottom line : is there a way to make it so that the CoreData object's
>> instantiation and its setup are registered as a single action in the
>> undo/redo stack ?
>
> I presume that you are setting these attributes in -awakeFromInsert. One
> solution I've seen used for this particular problem is to disable undo
> registration when the attributes are set. Something like this:
>
> - (void)awakeFromInsert {
>[super awakeFromInsert] ;
>
>// Close the curtain so the wizard can do some magic
>[[self managedObjectContext] processPendingChanges] ;
>[[[self managedObjectContext] undoManager] disableUndoRegistration] ;
>
>// Do some magic
>[self setFoo:whatever] ;
>[self setBar:whateverElse] ;
>
>// Re-open the curtain
>[[self managedObjectContext] processPendingChanges] ;
>[[[self managedObjectContext] undoManager] enableUndoRegistration] ;
> }
>
> So the setting of foo and bar aren't even on the undo stack. But when you
> Undo, it removes the object, so no one cares.
Yes, that's what I did, but a friend gave me a better one, which was to
dissociate element creation and insertion :
NSEntityDescription* segmentEntity = [NSEntityDescription
entityForName:@"Segment" inManagedObjectContext:managedObjectContext];
NSManagedObject* newSegment = [[NSManagedObject alloc]
initWithEntity:segmentEntity insertIntoManagedObjectContext:nil];
//do some init stuff on newSegment
[managedObjectContext insertObject:newSegment];
That does exactly what I need.
--
Guillaume
http://telegraph-road.org
___
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
Pipelining HTTP Requests?
Hi everyone, Is there a way to pipeline HTTP requests on the Mac (and pre-iOS4)? I've found vague references in the CFNetwork source from 10.4 to "_CFNetConnectionSetShouldPipeline()", but that's not a reliable option. I've also seen mentioned that CFHTTPStream supposedly supports pipelining, but have found no supporting documentation. Is there a built-in option (or 3rd party library I've overlooked, perhaps?), or will I need to implement my own pipelining? (And yes, I know that the servers I need to talk to support pipelining. In fact, they really really really want me to use pipelining) Thanks, Dave smime.p7s Description: S/MIME cryptographic signature ___ 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
Display problem when drag session interrupted
I'm allowing drag into my NSOutlineView and I've been using the example "DragNDropOutlineView" as a guide. Everything works fine except when I interrupt a drag session by pressing escape. The drag session is canceled and my outline view is left with some artifact from the drag, an insertion line between rows or an inverted container (folder or expandable item). I checked if there was some outline view delegation method that would be called when the drag session is canceled but didn't find any. I did review the example's code and I can't find what I'm missing. Anybody knows? -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.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
Another basic CoreData question
Using the standard Employee/Department example, Whats the best way to set a default department for an Employee? So that every employee is created with a relationship to the "mailRoom" department. ___ 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
NSXMLParser parses line feeds in attribute strings as spaces
Consider this XML: wherein there is a linefeed (0x0a) followed by two spaces between the command and "California". The accented é is represented by two bytes, 0xa3 0xc9. It's all nice UTF-8, as indicated in the header. When I parse this using NSXMLParser, the value for the key "location" in the attributes dictionary comes out as: San José, California wherein there are three spaces (0x20) between the comma and "California". The accented é gets parsed correctly, as UTF8, but the linefeed 0x0a gets changed to a space. Is this a bug? ___ 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: NSXMLParser parses line feeds in attribute strings as spaces
On Jul 8, 2010, at 10:04 PM, Jerry Krinock wrote: > Consider this XML: > > > > > > > wherein there is a linefeed (0x0a) followed by two spaces between the command > and "California". The accented é is represented by two bytes, 0xa3 0xc9. > It's all nice UTF-8, as indicated in the header. > > When I parse this using NSXMLParser, the value for the key "location" in the > attributes dictionary comes out as: > > San José, California > > wherein there are three spaces (0x20) between the comma and "California". > > The accented é gets parsed correctly, as UTF8, but the linefeed 0x0a gets > changed to a space. Is this a bug? Do you know for a fact that it's the LF that gets changed? I would experiment with removing the linefeed, then removing the accented é, then removing the space, to see exactly what triggers the bad behavior. Steve Bird Culverson Software - Elegant software that is a pleasure to use. www.Culverson.com (toll free) 1-877-676-8175 ___ 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: NSXMLParser parses line feeds in attribute strings as spaces
No, I don't believe that this is a bug. See section 3.3.3 Attribute-Value Normalization: http://www.xml.com/axml/testaxml.htm -Jeff On Jul 8, 2010, at 9:04 PM, Jerry Krinock wrote: > Consider this XML: > > > > > > > wherein there is a linefeed (0x0a) followed by two spaces between the command > and "California". The accented é is represented by two bytes, 0xa3 0xc9. > It's all nice UTF-8, as indicated in the header. > > When I parse this using NSXMLParser, the value for the key "location" in the > attributes dictionary comes out as: > > San José, California > > wherein there are three spaces (0x20) between the comma and "California". > > The accented é gets parsed correctly, as UTF8, but the linefeed 0x0a gets > changed to a space. Is this a bug? ___ 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: Another basic CoreData question
On Jul 8, 2010, at 7:33 PM, gumbo...@mac.com wrote: > Using the standard Employee/Department example, Whats the best way to set a > default department for an Employee? > So that every employee is created with a relationship to the "mailRoom" > department. Probably to add some custom code to AwakeFromInsert in your employee NSManagedObjectSubclass to set its own department. -Noah___ 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: NSXMLParser parses line feeds in attribute strings as spaces
You may need to escape it first if it is CDATA. You might benefit from growing the schema to have Then you can insert new line characters as you wish for presentation of the data elsewhere. New lines would often be considered presentational stuff. On Jul 8, 2010, at 9:18 PM, Jeff Johnson wrote: > No, I don't believe that this is a bug. See section 3.3.3 Attribute-Value > Normalization: > > http://www.xml.com/axml/testaxml.htm > > -Jeff > > > On Jul 8, 2010, at 9:04 PM, Jerry Krinock wrote: > >> Consider this XML: >> >> >> >> >> >> >> wherein there is a linefeed (0x0a) followed by two spaces between the >> command and "California". The accented é is represented by two bytes, 0xa3 >> 0xc9. It's all nice UTF-8, as indicated in the header. >> >> When I parse this using NSXMLParser, the value for the key "location" in the >> attributes dictionary comes out as: >> >> San José, California >> >> wherein there are three spaces (0x20) between the comma and "California". >> >> The accented é gets parsed correctly, as UTF8, but the linefeed 0x0a gets >> changed to a space. Is this a bug? > > ___ > > 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/jjoyce%40apple.com > > This email sent to jjo...@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
