Re: Temporarily disabling autosave
On 24 Apr 2013, at 04:16, Steve Mills wrote: > On Apr 23, 2013, at 17:39:17, Mike Abdullah > wrote: > >> -hasUnautosavedChanges continues to be applicable to all (auto)saving models. >> >> I caution against overriding it since: >> >> A) Your override is likely a lie to the system when you get down to it. This >> might upset the state for other bits of the system >> B) A perfectly good system for backing out of non-essential autosaves >> already exists, and should be used instead > > Then why would hasUnautosavedChanges be exposed publicly with no > documentation that says overriding it is a bad idea? To be fair, there's plenty of methods in the frameworks that are public and a bad idea to override, but not explicitly documented as such. The team may not have considered that anyone might actually want to override it. Or they simply forget. Or maybe I'm wrong and it's perfectly reasonable to override. > >> If you read the docs for >> -autosaveWithImplicitCancellability:completionHandler: *its* implementation >> calls -hasUnautosavedChanges. It will back out without doing any work should >> the document claim not to have any unautosaved changes. > > Yes, but if hasUnautosavedChanges returns NO, then > autosaveWithImplicitCancellability won't autosave. I don't see what > difference it makes which one I override, except hasUnautosavedChanges is a > much simpler method to understand and override. I'm just pointing out that your override comes down to lying about the document's state (claiming a doc is autosaved when it isn't really), and that that would make me uncomfortable in my code. > >> I suspect that if you do override -hasUnautosavedChanges, a call to >> -scheduleAutosaving would be needed — at least under some circumstances — to >> restart autosave when you’re ready. > > > Not from my tests. If I cause an autosave to happen before I pause it > locally, then later when it's resumed, any dirtying of the document is all > that is needed to cause an autosave to fire again when the autosave time > interval has elapsed. OK, that's good. Not that it's guaranteed to be the case for future OS's mind… ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
IKCameraDeviceView ignores 'memory' mode.
I'd like my IKCameraDeviceView to report downloaded images in memory-mode, but despite the fact that I have told it to use IKCameraDeviceViewTransferModeMemoryBased and it agrees that it heard me: (gdb)p (int) [cameraDeviceView mode] $1 = 1 ... it still passes the image as a URL to its delegate's cameraDeviceView:didDownloadFile:location:fileData:error: method, after downloading it to ~/Pictures. That's bad, because the user may have that folder open, and I don't want her to see a tmp file flash in and out of existence. Because I'm asking for memory mode, I deliberately don't display the file UI (aka 'Displays download location' in Interface Builder). I tried to workaround it by doing the following, but it ignores that too. cameraView.downloadsDirectory = [NSURL fileURLWithPath:NSTemporaryDirectory()]; Anyone have pearl she'd like to cast? ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Third time I ask - please help. How to trace visible change in a UIView (UIWebView)
> I seem to have a loose end though -- when I examine the UIWebView's > scrollView property, it initially has a non-nil delegate. I don't know if I > should "interpose" as delegate and after taking my snapshot, call the > original delegate, or only set myself as a delegate instead of the original. > > I'm afraid that "posing" as the delegate but still maintaining the original > delegate, may imply that I need to implement the WHOLE delegate protocol, > just to pass on all delegate calls to the original delegate. > > Any ideas? Nothing other than trying it out and see what happens… even if you have to interpose yourself between the scrollview and its original delegate, UIScrollViewDelegate only needs a dozen or so methods anyway. —Mt. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Temporarily disabling autosave
I agree with all of Mike's warnings, and continue to be amazed that Steve is able to sidestep the whole minefield of -autosaveWithImplicitCancellability:completionHandler: hangs in which so many of us have lost limbs. In my Lion-autosaved app, I override -autosaveWithImplicitCancellability:completionHandler:, and do NOT invoke -hasUnautosavedChanges. (I consider -isDocumentEdited instead.) So, out of curiosity, I overrode -hasUnautosavedChanges to see if it ever gets called by Cocoa. It does, quite often, and super returns either YES or NO, as expected. So it could be that the God of Autosave in Cocoa invokes -hasUnautosavedChanges not only during but *before* invoking -autosaveWithImplicitCancellability:completionHandler:. And if you tell it NO on the *before*, indeed it may forego invoking -autosaveWithImplicitCancellability:completionHandler:. I'm rooting for you, Steve. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Temporarily disabling autosave
Could it be because we're not using Cocoa's undo manager or because I have preservesVersions and autosavesInPlace turned off? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 On Apr 24, 2013, at 09:25:25, Jerry Krinock wrote: > I agree with all of Mike's warnings, and continue to be amazed that Steve is > able to sidestep the whole minefield of > -autosaveWithImplicitCancellability:completionHandler: hangs in which so many > of us have lost limbs. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Temporarily disabling autosave
On 24 Apr 2013, at 15:58, Steve Mills wrote: > Could it be because we're not using Cocoa's undo manager or because I have > preservesVersions and autosavesInPlace turned off? You do?! That takes us back to an earlier point then, surely – you're using a custom autosave system? ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Temporarily disabling autosave
On Apr 24, 2013, at 10:00:13, Mike Abdullah wrote: > On 24 Apr 2013, at 15:58, Steve Mills wrote: > >> Could it be because we're not using Cocoa's undo manager or because I have >> preservesVersions and autosavesInPlace turned off? > > You do?! That takes us back to an earlier point then, surely – you're using a > custom autosave system? No. This works. Why does this surprise you? (Sent from home account because the list is not delivering some message from you to my work account.) -- Steve Mills Drummer, Mac geek ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Attempts to restore unrestorable windows
On Apr 18, 2013, at 12:42 PM, Seth Willits wrote: > I have an application with a single window and that window's -restorable > property is NO (in the xib). If I force quit that application or otherwise > cause it to crash, when it is launched again the app asks me if I want to > restore its windows. > > Is there any way to turn off that notice? In this app the window should never > ever be restored so the alert is confusing and wrong. Repost in case someone has an answer and missed this. I still can't find the answer. -- Seth Willits ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Temporarily disabling autosave
On 24 Apr 2013, at 16:12, Steve Mills wrote: > On Apr 24, 2013, at 10:00:13, Mike Abdullah wrote: > >> On 24 Apr 2013, at 15:58, Steve Mills wrote: >> >>> Could it be because we're not using Cocoa's undo manager or because I have >>> preservesVersions and autosavesInPlace turned off? >> >> You do?! That takes us back to an earlier point then, surely – you're using >> a custom autosave system? > > > No. This works. Why does this surprise you? It doesn't surprise me, so much as it confuses me! I thought you'd turned on +autosavesInPlace and were trying to get it not to autosave at certain times. But now you're saying you're not using it. Are you using the old 10.4-based autosave system then? Or your own custom one? If so, that makes no sense why you would be wrestling the NSDocument system so much! ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Temporarily disabling autosave
On Apr 24, 2013, at 12:34:41, Mike Abdullah wrote: > It doesn't surprise me, so much as it confuses me! I thought you'd turned on > +autosavesInPlace and were trying to get it not to autosave at certain times. > But now you're saying you're not using it. > > Are you using the old 10.4-based autosave system then? > > Or your own custom one? If so, that makes no sense why you would be wrestling > the NSDocument system so much! In a previous thread I was using autosavesInPlace and preservesVersions, but the way Cocoa doesn't prevent things from happening in version browser documents added a huge amount to our workload, so we had to step back to the easier 10.4 type autosave, again, NOT our own autosave (this is replacing an old cross-platform autosave scheme). -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core data commit changes made programmatically
On 2013 Apr 23, at 14:41, Peng Gu wrote: Peng, I don't quite understand all of what you're doing there, but from this remark, > The code above works, but core data won't save the attributes changes > unless I type some words in the Textview. Calling moc to commit editting > doesn't save the changes too. this makes me think that maybe your problem is not with Core Data but with the text view, or Cocoa bindings. See if the appropriate setter in your data model is being invoked when you change attributes. The chain of events is… Text View ends editing or for some other reason changes it value Cocoa Bindings grabs it. Cocoa Bindings invokes the setter in your data model Core Data commits (later) Core Data saves (later) Start at the beginning, probe and determine which link is broken. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Temporarily disabling autosave
On 24 Apr 2013, at 19:00, Steve Mills wrote: > On Apr 24, 2013, at 12:34:41, Mike Abdullah > wrote: > >> It doesn't surprise me, so much as it confuses me! I thought you'd turned on >> +autosavesInPlace and were trying to get it not to autosave at certain >> times. But now you're saying you're not using it. >> >> Are you using the old 10.4-based autosave system then? >> >> Or your own custom one? If so, that makes no sense why you would be >> wrestling the NSDocument system so much! > > In a previous thread I was using autosavesInPlace and preservesVersions, but > the way Cocoa doesn't prevent things from happening in version browser > documents added a huge amount to our workload, so we had to step back to the > easier 10.4 type autosave, again, NOT our own autosave (this is replacing an > old cross-platform autosave scheme). So why not use the modern autosave system, and leave out Versions support? Both Apple and many of your customers would appreciate using the modern model. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core data commit changes made programmatically
Mutating an attributed string doesn't count as "key-value coding", even if the string itself is exposed as a KVC-compliant property. Since the only KVC-compliant change for the textStorage property would be to change it to a completely new object instance, and that would be very wasteful, you will need to add another property that you mutate in a KVC-compliant manner to trick Core Data into noticing your attributed string has changed. --Kyle Sluder On Apr 23, 2013, at 11:41 PM, Peng Gu wrote: > I have a textview that is binding to Core data, I want to be able to > highlight the selected text in the textview. > > *[self.textStorage addAttribute:NSBackgroundColorAttributeName value:[ > NSColor yellowColor] range:self.selectedRange];* > > The code above works, but core data won't save the attributes changes > unless I type some words in the Textview. Calling moc to commit editting > doesn't save the changes too. > > *[aManagedObjectContext commitEditing];* > > *[aManagedObjectContext save:&error];* > > I also tried to set the value of the object in Core data after adding the > attributes, but *[aManagedObject setValue:text forKey:@"text"] *will make > the textview lose focus. > > > Is there any way to force the core data to save the changes immediately? Or > any better way to highlight selected text in NSTextview, like addFontTrait: > used by Bold, Italic Menu Items? > > > Thanks, > > - Peng > > * > * > ___ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/kyle%40ksluder.com > > This email sent to k...@ksluder.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Temporarily disabling autosave
On 2013 Apr 24, at 07:58, Steve Mills wrote: > Could it be because we're not using Cocoa's undo manager or because I have > preservesVersions and autosavesInPlace turned off? Yes. Plus everything that Mike said on this thread today. As I said yesterday, there are three different autosave mechanisms available: Lion, Tiger, and in your case, probably a Legacy Home Brew. If you return YES in +autosavesInPlace, you are using Lion Autosave. If you return NO in +autosavesInPlace or do not implement +autosavesInPlace, you are *not* using Lion Autosave. The advice you've gotten from Mike and I assume that you are using Lion Autosave. Stepping back from that, you should make sure that both you and your marketing team understand the three Autosave mechanisms, and agree on which one you're adopting in your product. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Temporarily disabling autosave
On 2013 Apr 24, at 11:00, Steve Mills wrote:
> but the way Cocoa doesn't prevent things from happening in version browser
> documents added a huge amount to our workload
That's maybe not the hardest thing you'll do this week. Add this to your code
snippets…
if ([self isInViewingMode]) {
NSBeep() ;
return ;
}
and start pasting! My Lion-autosaved app uses that in 34 places. When in
doubt, paste. It usually does no harm.
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Temporarily disabling autosave
On Apr 24, 2013, at 13:29:13, Jerry Krinock
wrote:
> That's maybe not the hardest thing you'll do this week. Add this to your
> code snippets…
>
>if ([self isInViewingMode]) {
>NSBeep() ;
>return ;
>}
>
> and start pasting! My Lion-autosaved app uses that in 34 places. When in
> doubt, paste. It usually does no harm.
Sure, I've already played with something similar, and it *sounds* easy, but
there are far too many places to take care of this and think about all the
implications, and there's a schedule to meet. I also think it's kind of a lame
way to prevent edits. Like the way TextEdit does it; you see the change take
place, but then it instantly blinks back to the way it was before. It's *very*
un-Mac-like and feels extremely half-baked. It's a lot of work just get version
browsing, which is a brand new feature that most customers are not using.
Everyone forgets that tons of users don't and/or can't upgrade their OS just
because Apple released a new one.
--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Find functions disabled while NSSearchField is first responder.
Hi, I have an NSSearchField, and a menu bar submenu with the standard Find items. When the search field receives some input, it performs its action and an array controller is filled with search results. Now, while the search field is the first responder, none of the Find items are enabled, so it is impossible to issue, say a Find Next command. The Find functions perform fine when just about any other item in the document window is first responder. I find that surprising, but, more importantly, I cannot find a way to get the Find functions to work, while the search command has focus. What am I missing? -António ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core data commit changes made programmatically
I found the solution. Just do [theTextView didChangeText] in the end of the changes. Thanks - Peng On Wed, Apr 24, 2013 at 2:08 PM, Kyle Sluder wrote: > Mutating an attributed string doesn't count as "key-value coding", even if > the string itself is exposed as a KVC-compliant property. > > Since the only KVC-compliant change for the textStorage property would be > to change it to a completely new object instance, and that would be very > wasteful, you will need to add another property that you mutate in a > KVC-compliant manner to trick Core Data into noticing your attributed > string has changed. > > --Kyle Sluder > > On Apr 23, 2013, at 11:41 PM, Peng Gu wrote: > > > I have a textview that is binding to Core data, I want to be able to > > highlight the selected text in the textview. > > > > *[self.textStorage addAttribute:NSBackgroundColorAttributeName value:[ > > NSColor yellowColor] range:self.selectedRange];* > > > > The code above works, but core data won't save the attributes changes > > unless I type some words in the Textview. Calling moc to commit editting > > doesn't save the changes too. > > > > *[aManagedObjectContext commitEditing];* > > > > *[aManagedObjectContext save:&error];* > > > > I also tried to set the value of the object in Core data after adding the > > attributes, but *[aManagedObject setValue:text forKey:@"text"] *will > make > > the textview lose focus. > > > > > > Is there any way to force the core data to save the changes immediately? > Or > > any better way to highlight selected text in NSTextview, like > addFontTrait: > > used by Bold, Italic Menu Items? > > > > > > Thanks, > > > > - Peng > > > > * > > * > > ___ > > > > 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: > > https://lists.apple.com/mailman/options/cocoa-dev/kyle%40ksluder.com > > > > This email sent to k...@ksluder.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
