Re: How to enable Undo only for subgroup of managed objects?
Re: How to enable Undo only for subgroup of managed objects?
- Subject: Re: How to enable Undo only for subgroup of managed objects?
- From: Chad Seldomridge <email@hidden>
- Date: Thu, 21 Sep 2006 14:34:07 -0600
I get to repy to myself today :) I was browsing CocoaDevCentral and found this page http://cocoadevcentral.com/articles/000083.php Scroll down to page 6 and take a look at the graphic on the right. It diagrams the internal order of KVC operations:
[object setName:newValue];
1. Register for Undo
2. Do Retain/Release
3. Set New Value
4. KVO auto-sends "Did Change"
5. Bound Objects get New Value
>Date: Thu, 21 Sep 2006 10:52:27 -0600
>From: Chad Seldomridge <email@hidden>
>Subject: Re: How to enable Undo only for subgroup of managed objects?
>To: email@hidden
>Cc: email@hidden
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=ISO-8859-1
>
>I would read the KVC documentation and make sure your setter methods KVC compliant and are being called. Either that or log a debug string inside the setter. It could be that your undo code isn?t being called because the KVC system is setting your variable via some method other than your setter.
>
>
>>Date: Thu, 21 Sep 2006 16:16:19 +0200
>>From: "Arthur C." <email@hidden>
>>Subject: RE: How to enable Undo only for subgroup of managed objects?
>>To: email@hidden
>>Cc: email@hidden
>>Message-ID: <email@hidden>
>>Content-Type: text/plain; format=flowed
>>
>>According to the Core Data programming guide, page 57, a solution would be
>>as follows:
>>
>>NSManagedObjectContext *moc = [[NSApp delegate] managedObjectContext];
>>[moc processPendingChanges]; // flush operations for which you want undos
>>[[moc undoManager] disableUndoRegistration];
>>
>>// do things for which you don't want undo
>>
>>[moc processPendingChanges]; // flush operations for which you do not want
>>undos
>>[[moc undoManager] enableUndoRegistration];
>>
>>I would then put this code in the setter methods of some objects, for
>>example:
>>
>>- (void)setName:(NSString *)value
>>{
>>NSManagedObjectContext *moc = [[NSApp delegate] managedObjectContext];
>>[moc processPendingChanges];
>>[[moc undoManager] disableUndoRegistration];
>>
>>[self willChangeValueForKey: @"name"];
>> [self setPrimitiveValue: value forKey: @"name"];
>> [self didChangeValueForKey: @"name"];
>>
>>[moc processPendingChanges];
>>[[moc undoManager] enableUndoRegistration];
>>}
>>
>>But this does not appear to work (changes can still be undone). However when
>>I put the undo disable / enable code outside of the setter method, undo is
>>disabled as expected:
>>
>><disable undo>
>>[myObject setName: somevalue];
>><enable undo>
>>
>>Is this expected behaviour? I would rather like to have the undo
>>disabling/enabling inside the setter method, as that would simply lead to
>>less code.
>>
>>
>>Best regards,
>>
>>Arthur C.
>>
>>>I have a Core Data application in which I would like some objects to have
>>>an undo capability, and others not.
>>>For example, there are some objects which the user can change (which we
>>>want to be undo enabled), and objects that get changed as the program runs,
>>>for example by incoming I/O, network traffic etc. (no undo wanted).
>>>When the user tries to 'undo' some change, the latest change is undone,
>>>regardless what type of object was changed. So this will normally be an
>>>automatically updated object.
>>>
>>>Question: can I disable 'undo' for a specific set of objects in a managed
>>>object context?
>>>
>>>A solution would be either to throw the automatically changed objects out
>>>of the managed object context, or to create a second managed object
>>>context.
>>>I would like to know if there is a simpler solution, or that one of the
>>>above is really preferred.
>>>
>>>
>>>Best regards,
>>>
>>>Arthur C.
>>>
>
>
>------------------------------
>
>Message: 6
>Date: Thu, 21 Sep 2006 10:28:37 -0700
>From: "Jordan Krushen" <email@hidden>
>Subject: Re: [CD] programmatically inserting MO in MOC gets slower
> with number of items II
>To: "Volker Runkel" <email@hidden>
>Cc: email@hidden
>Message-ID:
> <email@hidden>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>On 9/21/06, Volker Runkel <email@hidden> wrote:
>
>> I discovered the reason for the slow down: For each newly inserted
>> MO I set the value for a relationship (a "parent" MO that has one-to-
>> many relation to my inserted MOs). Without the call setValue:forKey
>> to connect my newly inserted MO with its "parent" the insertion is
>> rather fast.
>
>> Still this does not solve my problem though, since I need to
>> establish that relationship. Is there a faster possibility to create
>> a relationship or can I make it faster ? Or do I have to live with
>> the fact that the nth object is inserted in the object tree x times
>> slower then the first ?
>
>Do you have a tight loop with an accumulation of autoreleased objects
>causing memory exhaustion? Does the Performance section in the
>CoreData Programming Guide help you at all?
>
>What do the profiling tools like Shark and ObjectAlloc tell you?
>
>Showing your code often helps, as well.
>
>As djb says, "Profile. Don't speculate."
>
>J.
>
>
>------------------------------
>
>Message: 7
>Date: Thu, 21 Sep 2006 12:31:16 -0500
>From: Howard Shere <email@hidden>
>Subject: graphicsContextWithGraphicsPort
>To: email@hidden, email@hidden
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
>I have a carbon app which uses graphicsContextWithGraphicsPort and it
>works great:
>
> nsContext = [NSGraphicsContext graphicsContextWithGraphicsPort:
>fCurrentContext flipped: true];
>
>The problem is that I need to make this app work in 10.3 now and I
>can't figure out a way to do what graphicsContextWithGraphicsPort
>does since it is a 10.4 only call.
>
>I have tried this:
>
> cocoaWindow = [[NSWindow alloc] initWithWindowRef: (void*)
>carbonWindow];
> nsContext = [NSGraphicsContext graphicsContextWithWindow:
>cocoaWindow];
>
>But as soon as I call initWithWindowRef, the drawing of the carbon
>window stops working. If I then release the cocoaWindow, the
>WindowRef seems to be disposed of.
>
>Any ideas?
>
>Howard Shere
>http://www.livejournal.com/users/realgreendragon/
>Altair 8800a to Mac OS X so far...
>
>
>
>
>------------------------------
>
>Message: 8
>Date: Thu, 21 Sep 2006 13:31:19 -0400 (EDT)
>From: "Matt Mashyna" <email@hidden>
>Subject: Re: Save dialog question
>To: email@hidden
>Message-ID: <email@hidden>
>Content-Type: text/plain;charset=iso-8859-1
>
>Because I want the user to have a seamless experience where saving (really
>save as) gives them the option to save the document as a "normal" local file
>based document or a "remote" document when they choose to save it initially
>rather than another menu option to "Save As Remote".
>
>Maybe another menu option to "Save As Remote" is the right thing to do. I'm
>sure I'll get some good opinions about it.
>
>Maybe a user will want to initially save it locally to work on and then
>remotely to share it. I don't know. I'm still thinking about how the concept
>should work.
>
>
>>
>> Why use an NSSavePanel at all, then? If all you need is a name,
>> why not just make a custom panel?
>>
>> --
>> I.S.
>>
>>
>> On Sep 21, 2006, at 10:47 AM, Matt Mashyna wrote:
>>
>>> I have an app that works on documents. Now, we have hit upon the
>>> idea that it
>>> would be a really great feature to "Save" or "Save As" these
>>> documents not to
>>> a file system but to a URL or some kind of net service.
>>>
>>> I think the user would choose a document type from the popup at the
>>> bottom. If
>>> the user chose to make it a "Remote" document we would only want
>>> the user to
>>> be able to put in a name and make the file system pane disappear or
>>> at least
>>> disable it.
>>>
>>> Is there a way to disable views on the NSSavePanel ?
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Cocoa-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>> 40gmail.com
>>>
>>> This email sent to email@hidden
>>
>>
>>
>
>
>
>
>------------------------------
>
>Message: 9
>Date: Thu, 21 Sep 2006 13:37:24 -0400
>From: "I. Savant" <email@hidden>
>Subject: Re: Save dialog question
>To: email@hidden
>Cc: email@hidden
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> Oh. :-)
>
> Stephane's suggestion seems sound in theory, though I can't say
>I'd be comfortable using it in production myself. There is, however,
>no reason why you couldn't just recreate the basic controls of the
>save panel with IB. If you want to turn off just the file system
>browser, just don't include it.
>
> The save dialogue is, by default, 'collapsed', meaning the file
>browser portion is invisible anyway. Just don't include that UI (or
>the disclosure button to the right of the file name).
>
>--
>I.S.
>
>
>On Sep 21, 2006, at 1:31 PM, Matt Mashyna wrote:
>
>> Because I want the user to have a seamless experience where saving
>> (really
>> save as) gives them the option to save the document as a "normal"
>> local file
>> based document or a "remote" document when they choose to save it
>> initially
>> rather than another menu option to "Save As Remote".
>>
>> Maybe another menu option to "Save As Remote" is the right thing to
>> do. I'm
>> sure I'll get some good opinions about it.
>>
>> Maybe a user will want to initially save it locally to work on and
>> then
>> remotely to share it. I don't know. I'm still thinking about how
>> the concept
>> should work.
>>
>>
>>>
>>> Why use an NSSavePanel at all, then? If all you need is a name,
>>> why not just make a custom panel?
>>>
>>> --
>>> I.S.
>>>
>>>
>>> On Sep 21, 2006, at 10:47 AM, Matt Mashyna wrote:
>>>
>>>> I have an app that works on documents. Now, we have hit upon the
>>>> idea that it
>>>> would be a really great feature to "Save" or "Save As" these
>>>> documents not to
>>>> a file system but to a URL or some kind of net service.
>>>>
>>>> I think the user would choose a document type from the popup at the
>>>> bottom. If
>>>> the user chose to make it a "Remote" document we would only want
>>>> the user to
>>>> be able to put in a name and make the file system pane disappear or
>>>> at least
>>>> disable it.
>>>>
>>>> Is there a way to disable views on the NSSavePanel ?
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Cocoa-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>> 40gmail.com
>>>>
>>>> This email sent to email@hidden
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Cocoa-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>> 40gmail.com
>>
>> This email sent to email@hidden
>
>
>
>------------------------------
>
>Message: 10
>Date: Thu, 21 Sep 2006 10:44:02 -0700
>From: John Stiles <email@hidden>
>Subject: Re: Save dialog question
>To: "I. Savant" <email@hidden>
>Cc: email@hidden
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes;
> format=flowed
>
>You could easily include a custom part in the NSSavePanel which
>contains a button "Save To URL
" (Save As Remote is a confusing name,
>I'd suggest rethinking it). When the user clicks the button, it could
>just cause the NSSavePanel to cancel itself, and bring up a normal
>dialog in its place.
>
>The new dialog could then have a "Save Locally
" button which brings
>the NSSavePanel back.
>
>So it's really the same experience, just the transitions will be a
>little less pretty.
>
>
>On Sep 21, 2006, at 10:37 AM, I. Savant wrote:
>
>>
>> Oh. :-)
>>
>> Stephane's suggestion seems sound in theory, though I can't say
>> I'd be comfortable using it in production myself. There is,
>> however, no reason why you couldn't just recreate the basic
>> controls of the save panel with IB. If you want to turn off just
>> the file system browser, just don't include it.
>>
>> The save dialogue is, by default, 'collapsed', meaning the file
>> browser portion is invisible anyway. Just don't include that UI (or
>> the disclosure button to the right of the file name).
>>
>> --
>> I.S.
>>
>>
>> On Sep 21, 2006, at 1:31 PM, Matt Mashyna wrote:
>>
>>> Because I want the user to have a seamless experience where saving
>>> (really
>>> save as) gives them the option to save the document as a "normal"
>>> local file
>>> based document or a "remote" document when they choose to save it
>>> initially
>>> rather than another menu option to "Save As Remote".
>>>
>>> Maybe another menu option to "Save As Remote" is the right thing
>>> to do. I'm
>>> sure I'll get some good opinions about it.
>>>
>>> Maybe a user will want to initially save it locally to work on and
>>> then
>>> remotely to share it. I don't know. I'm still thinking about how
>>> the concept
>>> should work.
>>>
>>>
>>>>
>>>> Why use an NSSavePanel at all, then? If all you need is a name,
>>>> why not just make a custom panel?
>>>>
>>>> --
>>>> I.S.
>>>>
>>>>
>>>> On Sep 21, 2006, at 10:47 AM, Matt Mashyna wrote:
>>>>
>>>>> I have an app that works on documents. Now, we have hit upon the
>>>>> idea that it
>>>>> would be a really great feature to "Save" or "Save As" these
>>>>> documents not to
>>>>> a file system but to a URL or some kind of net service.
>>>>>
>>>>> I think the user would choose a document type from the popup at the
>>>>> bottom. If
>>>>> the user chose to make it a "Remote" document we would only want
>>>>> the user to
>>>>> be able to put in a name and make the file system pane disappear or
>>>>> at least
>>>>> disable it.
>>>>>
>>>>> Is there a way to disable views on the NSSavePanel ?
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Cocoa-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> 40gmail.com
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Cocoa-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>> 40gmail.com
>>>
>>> This email sent to email@hidden
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Cocoa-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>> 40blizzard.com
>>
>> This email sent to email@hidden
>
>
>
>------------------------------
>
>Message: 11
>Date: Thu, 21 Sep 2006 10:50:35 -0700
>From: Rosyna <email@hidden>
>Subject: Re: pid vs. Process Serial Number
>To: Brad Peterson <email@hidden>, cocoa dev
> <email@hidden>
>Message-ID: <p06230900c13880fad362@[192.168.1.5]>
>Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
>1. Don't trust executable names.
>2. Only processes that connect to the window server have process
>serial numbers. Background daemons that don't connect do not have one.
>3. You might try looking at
>http://developer.apple.com/samplecode/PIDFromBSDProcessName/index.html
>which is some happy fun sample code.
>
>Ack, at 9/21/06, Brad Peterson said:
>
>>So, I figured I'd use getppid(), convert the result to
>>a psn, use that to get the process' name, and then
>>check for "cron".
>>
>>But, I always get a -600 when calling
>>GetProcessForPID().
>
>--
>
>
>Sincerely,
>Rosyna Keller
>Technical Support/Holy Knight/Always needs a hug
>
>Unsanity: Unsane Tools for Insanely Great People
>
>It's either this, or imagining Phil Schiller in a thong.
>
>
>------------------------------
>
>Message: 12
>Date: Thu, 21 Sep 2006 14:09:20 -0400
>From: Cameron Hayne <email@hidden>
>Subject: Re: Save dialog question
>To: CocoaDev list <email@hidden>
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>On 21-Sep-06, at 1:44 PM, John Stiles wrote:
>
>> Save As Remote is a confusing name, I'd suggest rethinking it
>
>I note that TextWrangler (and I presume BBEdit) has a menu item "Save
>to FTP/SFTP Server..."
>
>--
>Cameron Hayne
>email@hidden
>
>
>
>
>------------------------------
>
>Message: 13
>Date: Thu, 21 Sep 2006 14:55:21 -0400
>From: William Turner <email@hidden>
>Subject: Child windows, ordering, shadows
>To: Cocoa List Dev <email@hidden>
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>I'm working with a group of borderless window subclasses that have
>custom titlebars and "snap" together magnetically, the top of one
>window to the bottom of another. All is well accept for the shadows
>drawn around the higher window occasionally shows over the one
>attached at its bottom. I'm using orderWindow:relativeTo: and
>explicitly ordering the lower window above the one it is attached to,
>and yet this still occurs in some cases.
>
>As I understand it, if two windows have the same
>"level" (NSFloatingWindowLevel in this case), the window with the
>higher ordering should draw its shadow over the window below it (if
>they have contiguous borders). Is there a piece of the puzzle I'm
>missing?
>
>I can describe this in more depth if needed, or even link screenshots
>on the web if I'm not being clear.
>
>Thanks for any help.
>
>Wil
>
>------------------------------
>
>Message: 14
>Date: Thu, 21 Sep 2006 18:58:09 +0000
>From: Trygve Inda <email@hidden>
>Subject: Bind checkbox in menu?
>To: Cocoa-Dev Apple <email@hidden>
>Message-ID: <C1389141.41202%email@hidden>
>Content-Type: text/plain; charset="US-ASCII"
>
>I have a menu (attached as a submenu to an item in a menubar menu). I would
>like to check one item in this menu based on a binding.
>
>So...
>
>Somevar = 3, the third item in the menu (and only the third item) is checked
>and the others are not.
>
>Is this possible with bindings?
>
>I know you can set a popup menu to a value based on a binding, but don't
>know how to keep a normal menu bound so the binding sets the checked item.
>
>Thanks for any ideas,
>
>Trygve
>
>
>
>
>------------------------------
>
>_______________________________________________
>Cocoa-dev mailing list
>email@hidden
>http://lists.apple.com/mailman/listinfo/cocoa-dev
>
>End of Cocoa-dev Digest, Vol 3, Issue 1169
>******************************************
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden