Re: Preferences for network login
On Apr 19, 2013, at 22:46 , Graham Cox wrote: > Exactly, which is why I figured it must either mean something else here, or > the user in question is confused... > > It's a network of iMacs we're talking about. https://developer.apple.com/library/mac/#documentation/Security/Conceptual/AuthenticationAndAuthorizationGuide/Authentication/Authentication.html AFAIK (which isn't very far, I admit) ActiveDirectory is LDAP, which OS X Server supports. ___ 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: Preferences for network login
Exactly, which is why I figured it must either mean something else here, or the user in question is confused... It's a network of iMacs we're talking about. I'm trying to get more info about what the user means. In the meantime, how to store prefs that work for remote logins? On 20/04/2013, at 3:38 PM, Quincey Morris wrote: > On Apr 19, 2013, at 22:18 , Graham Cox wrote: > >> what sort of network accounts are implied by 'AD' ? > > I assume AD == ActiveDirectory, which is a Microsoft thing. > > ___ 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: Preferences for network login
On Apr 19, 2013, at 22:18 , Graham Cox wrote: > what sort of network accounts are implied by 'AD' ? I assume AD == ActiveDirectory, which is a Microsoft thing. ___ 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
Preferences for network login
Hi all, Our app stores some "by host" preferences aside from its usual user defaults. We have a user that reports that these preferences are not working when logging in over the network. I'm not actually sure what they mean by that, quote: "other users (all of which are network accounts that authenticate with AD)" The prefs are stored and read using CFPreferences, with current user, current host as the domain settings. First, what sort of network accounts are implied by 'AD' ? Second, what preferences settings would allow the preferences to work with this kind of login, if any? I'm thinking that current user, any host would be appropriate, but it's hard to be sure as I don't know what sort of login they're even talking about, and it's also difficult to know how to test this. Any hints or help would be gratefully received. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ANN: new open-source window manager for OS X
Looks interesting. Any comment on how this relates to Slate (https://github.com/jigish/slate)? It seems to be roughly along the same lines (which would be fine, just asking). -Tom On Wed, Apr 17, 2013 at 12:44 PM, Steven Degutis wrote: > Called Windows.app. Source is on github: > https://github.com/sdegutis/windowsapp > > What's particularly neat about it is how you configure it. It looks for a > dotfile in your home dir, which can either be JavaScript or CoffeeScript. > In this config file you, bind your hot keys as you want, using a very > simple API that the app exposes in JS-land. > > I managed to get JavaScript scripting working via JSCocoa, and CoffeeScript > via coffeescript.js and Coffeescript.compile(). Technically I hide the ObjJ > syntax away, since most people are much more comfortable in pure JS than in > ObjJ. I was looking into adding ClojureScript support, but I'm not yet sure > how to avoid the start-up delay when running java. Waiting 5 seconds each > time you reload your config isn't ideal. > > My first choice for scripting was to use MacRuby, but it only works with GC > apps, and this one uses ARC. I hear they've got ARC in the works, so my > fingers are crossed for the future. Also, PyObjC is really hard to > integrate into an app. Ironically enough, when I was googling for how to do > it, I found an article I wrote about it 3 years ago when I was working at > BNR. > > Also, I created a technique for generating appcasts statically from the > command line, and hosting the appcast on github, that might be interesting > to other open source authors who don't want to have any other hosting but > github. The details are in this build.sh file: > https://github.com/sdegutis/windowsapp/blob/master/build.sh > > My apologies if new-app announcements are off-topic, but I think this one > is particularly suitable for cocoa-dev because of the technical details. > > -Steven > ___ > > 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/tomvons%40gmail.com > > This email sent to tomv...@gmail.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
Clang "File not found" - in cocoa app
Hi there, I used clang in my cocoa app but it doesn't find Clang/Index.h. The error is "File not found". I linked to clang but again it doesn't find it. Anybody knows what's the problem. Thanks. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Problems converting to ARC
Hi there,
I want to convert my code to ARC but this problems doesn't let me to do this. I
read the errors but I couldn't do nothing. All the problems are in these else
if statement and are colored Red.
else if (isupper(character)){
1) Pointer to non-const type 'NSString *' with no explicit ownership
NSString **classOrProtocolName = (isParsingProtocolName ?
&protocolName : &className);
2) Passing address of non-local object to __autoreleasing parameter for
write back
i += parseClassOrProtocolName(unparsedText, strlen(unparsedText),
classOrProtocolName);
isParsingProtocolName = NO;
}else if (i == 0){
3) Passing address of non-local object to __autoreleasing parameter
for write back
int advancement = parseTypePrefix(unparsedText, strlen(unparsedText),
&typePrefix);
if (advancement == 0)
return;
i += advancement;
}else{
2) Passing address of non-local object to __autoreleasing parameter for
write back
i += parseTypeSuffix(unparsedText, strlen(unparsedText), &typeSuffix);
}
Thanks.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
NSInvocation's getArgument & setReurnValue question
Hi there,
I used - getArgument:atIndex: method but it gives me error. I don't know what's
the problem. I used this as below:
if ([component isEqualToString: @"class"]) {
1) id arg;
2) [invocation getArgument: &arg atIndex: i + 2];
3) [self class:arg];
}
The error is this:
NSInvocation's getArgument is not safe to be used with an object with ownership
other than __unsafe_unretained.
The error is colored Red.
And also I used -setReturnValue: and it gives me two errors.
[invocation setReturnValue: &self];
The first is:
NSInvocation's setReturnValue is not safe to be used with an object with
ownership other than __unsafe_unretained.
The second is:
Sending 'DocHTMLElement *const __strong *' to parameter of type 'void *'
changes retain/release properties of
pointer.
The error is colored Red.
So Thank you.
___
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
mobile_house_arrest
Hi, does anybody have any idea what can such error mean: mobile_house_arrest [7872] : Max open files: 78 As I can see it - that's because app opened too many file handlers, but I can't find any docs or other info that can help. Cheers, Ilia ___ 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 19, 2013, at 5:51 PM, Jerry Krinock wrote: > > On 2013 Apr 19, at 13:58, Alex Zavatone wrote: > >> "many developer type people would assume that a save of a document's data is >> a write of a delta of the data to a disk, which would take an amount of time >> that is so small that it would be transparent to the user". > > I think this is the model that Apple engineers had in mind when they designed > Auto Save. And it is plausible when coupled with Asynchronous Saving (on > background threads). But then, Asynchronous Saving was found to be > incompatible with Core Data. > > * * * > > Maybe you Steve and Alex Zavatone may be on to something there. You're > suggesting that, rather than handling the autosave when it is requested > during a long-winded operation, you turn autosave off *before* the > long-winded operation begins, so that you won't get any such requests. > Bingo. > The problem with that is that the way you turn autosave off is by returning > NO from +autosavesInPlace, which is a class method. I ask then: Why did > Apple make +autosavesInPlace a class method, other than to make it difficult > to change on the fly? You could do it with a static or global variable, I > guess. Your results will definitely be interesting. Let us know what > happens. That's why I mentioned setting a BOOL and possibly subclassing part of autosave if at all possible. In the part where autosave says "hey, I'm going to check the conditions to start an autosave now". If there is a "next service interval to query for an autosave", that is accessible can you set that to the max integer value for the int type used and then restore it to what it was before when you are done with your transaction? > Finally, y'all should know that stashing the completion handler and invoking > it later was not my idea but rather an approach suggested by someones who is > way smarter than me. Certainly not me in that case. ___ 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 19, 2013, at 16:52:35, Quincey Morris wrote: > You may have covered this ground already and I missed it, but what happens if > you return NO from the autosave, along with a cancel error (that is, > domain=NSCocoaErrorDomain code=NSUserCancelledError). > > On iOS, the document has a special "save failed" state, and I believe it will > try again later. It's possible that something similar may occur on OS X. Or, > if it just stops autosave cold, perhaps you can forcibly dirty the document > again later. Yes, I've already tried that, and it put the autosave state out of whack. Simply marking it dirty again via updateChangeCount didn't do anything to make it autosave again. As suggested, I tried it from writeToURL:ofType:error. -- 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: Temporarily disabling autosave
On Apr 19, 2013, at 16:51:20, Jerry Krinock wrote: > Maybe you Steve and Alex Zavatone may be on to something there. You're > suggesting that, rather than handling the autosave when it is requested > during a long-winded operation, you turn autosave off *before* the > long-winded operation begins, so that you won't get any such requests. Exactly, and it seems like such a basic part of the entire autosave concept that it's amazing Apple didn't build it in from the start. > The problem with that is that the way you turn autosave off is by returning > NO from +autosavesInPlace, which is a class method. I ask then: Why did > Apple make +autosavesInPlace a class method, other than to make it difficult > to change on the fly? You could do it with a static or global variable, I > guess. Your results will definitely be interesting. Let us know what > happens. Actually, I believe you're mistaken. autosaveInPlace merely tells autosave that, if turned on, it should replace the actual file once the autosave has completed successfully. If it's off, autosaves are stored elsewhere in a folder of NSDocument's choosing. The way to turn autosave on or off is through NSDocumentController's setAutosavingDelay method, where 0 means off. But, doing so doesn't seem to affect open documents if they've already scheduled an autosave (seems like a bug to me - turning it off from here should turn it off everywhere). -- 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
UIActivityIndicatorView stops animating when table view cell moves
I have a UIActivityIndicatorView in a UITableViewCell that's set up in a dynamic-content cell prototype in a storyboard. It works fine, in that it's animating when displayed, unless the cell is removed and re-inserted. Then it stops animating (still shows). I never actually tell it to stop. Any ideas? -- Rick ___ 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 19, 2013, at 14:39 , Steve Mills wrote: > so autosave will happen again during playback You may have covered this ground already and I missed it, but what happens if you return NO from the autosave, along with a cancel error (that is, domain=NSCocoaErrorDomain code=NSUserCancelledError). On iOS, the document has a special "save failed" state, and I believe it will try again later. It's possible that something similar may occur on OS X. Or, if it just stops autosave cold, perhaps you can forcibly dirty the document again later. The point of returning a cancel error is that NSDocument tends not to report that particular error via a sheet. ___ 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 19, at 13:58, Alex Zavatone wrote: > "many developer type people would assume that a save of a document's data is > a write of a delta of the data to a disk, which would take an amount of time > that is so small that it would be transparent to the user". I think this is the model that Apple engineers had in mind when they designed Auto Save. And it is plausible when coupled with Asynchronous Saving (on background threads). But then, Asynchronous Saving was found to be incompatible with Core Data. * * * Maybe you Steve and Alex Zavatone may be on to something there. You're suggesting that, rather than handling the autosave when it is requested during a long-winded operation, you turn autosave off *before* the long-winded operation begins, so that you won't get any such requests. The problem with that is that the way you turn autosave off is by returning NO from +autosavesInPlace, which is a class method. I ask then: Why did Apple make +autosavesInPlace a class method, other than to make it difficult to change on the fly? You could do it with a static or global variable, I guess. Your results will definitely be interesting. Let us know what happens. Finally, y'all should know that stashing the completion handler and invoking it later was not my idea but rather an approach suggested by someones who is way smarter than me. ___ 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 19, 2013, at 15:22:28, Quincey Morris wrote: > a. When you get an autosave during playback, can you save the dirty state of > the document, return a YES result but not actually autosave, then when > playback stops, if you have this saved state, restore it (via > NSChangeReadOtherContents or whatever)? The downside is that if your app > crashes during playback, the pending changes are lost. > > b. At a higher level, force an autosave to occur just before playback starts, > then don't let the document get dirtied till playback ends. Interesting. I start with trying out (b) first. This indeed caused it to autosave, but because our playback is a very complicated and decades old process, some parts of playback actually dirty the doc, so autosave will happen again during playback. And because of this annoying behavior, I'm brought back to something I tried similar to (a), and that throws the Cocoa autosave status out of whack. Grrr. -- 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: Temporarily disabling autosave
On Apr 19, 2013, at 15:42:05, Jerry Krinock wrote: > That's a damned good question, Mike. You're probably thinking that, hey, we > lived without any autosaves from 1984 to 2011. What's the big deal? It > turns out that you need to be really careful when playing around with an > autosave that Cocoa has designated "not implicitly cancellable". Search the > internet for: > >deadlock in -[NSDocument performActivityWithSynchronousWaiting:usingBlock:] > > to see some of the fun that people have had. > > I have an app with a requirement similar to Steve's. The app can do > long-winded sequences of operations that take tens of seconds, and change the > document. So if I honored an autosave request during one these sequences, > I'd have to interrupt the operations (which is tricky), save, and then save > again at the end after the changes were done. > > The solution: Upon receiving a non-cancellable autosave message while other > operations are in progress, I stash the completion handler that Cocoa sends > in the message, create an operation to "really autosave" later, and add it to > my operation queue. > > I had to do other stuff to deal with corner cases such as Revert, being in > the Versions Browser, etc. Below, I've snipped out a few of the relevant > methods from my NSDocument (actually it's NSPersistentDocument, which adds > even more to the mess) implementation. Heh, I just happened to run across some part of your previous thread while searching for answers right before your message arrived. :) Holy carp. That's a lot of complicated stuff to do just to do something as simple as temporarily disable autosave. I appreciate the debugging work it took for you to understand the complexity of what happens when you cancel autosave. I really don't want to add so much complexity to this, when all I'm trying to do is replicate the autosave behavior our app had before moving to Cocoa. Turn it on, pause it during playback, resume it. Piece of pie. I'm going to try a different tactic for now and only come back to this if it doesn't work out. Thanks for the snippets, Jerry! -- 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: Temporarily disabling autosave
On 19 Apr 2013, at 21:42, Jerry Krinock wrote: > > On 2013 Apr 19, at 12:37, Mike Abdullah wrote: > >> Why, what's wrong with cancelling a [auto]save? > > That's a damned good question, Mike. You're probably thinking that, hey, we > lived without any autosaves from 1984 to 2011. What's the big deal? It > turns out that you need to be really careful when playing around with an > autosave that Cocoa has designated "not implicitly cancellable". Hey give me some credit here. I thought from the context it was clear I was referring only to autosaves that *are* deemed cancellable. ___ 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 think a good way of summing up your statement is "many developer type people
would assume that a save of a document's data is a write of a delta of the data
to a disk, which would take an amount of time that is so small that it would be
transparent to the user".
It's apparent that with your doc, the app/doc could easily be in a state where
letting auto save operate as it wishes could easily create cases where the user
is blocked from using the app, or a resource intensive action is set up.
I'd hate to run in to this when on a laptop under battery.
I think that a related part of this is explained in Apple's docs on "Sudden and
Unexpected Termination", in that there are times when an app just can't control
alt delete/abort its running process.
One of these times where this is forbidden is when there are disk operations in
queue.
Thinking from the 1000 foot view, if autosave is a "this thing is either on or
off when the app starts and there's nothing you can do to change that once your
app starts up", can you subclass part of autosave so as to check a BOOL that
you have set in a supervisory role that is your permission slip to allow
autosave to proceed or not?
On Apr 19, 2013, at 4:42 PM, Jerry Krinock wrote:
>
> On 2013 Apr 19, at 12:37, Mike Abdullah wrote:
>
>> Why, what's wrong with cancelling a [auto]save?
>
> That's a damned good question, Mike. You're probably thinking that, hey, we
> lived without any autosaves from 1984 to 2011. What's the big deal? It
> turns out that you need to be really careful when playing around with an
> autosave that Cocoa has designated "not implicitly cancellable". Search the
> internet for:
>
>deadlock in -[NSDocument performActivityWithSynchronousWaiting:usingBlock:]
>
> to see some of the fun that people have had.
>
> I have an app with a requirement similar to Steve's. The app can do
> long-winded sequences of operations that take tens of seconds, and change the
> document. So if I honored an autosave request during one these sequences,
> I'd have to interrupt the operations (which is tricky), save, and then save
> again at the end after the changes were done.
>
> The solution: Upon receiving a non-cancellable autosave message while other
> operations are in progress, I stash the completion handler that Cocoa sends
> in the message, create an operation to "really autosave" later, and add it to
> my operation queue.
>
> I had to do other stuff to deal with corner cases such as Revert, being in
> the Versions Browser, etc. Below, I've snipped out a few of the relevant
> methods from my NSDocument (actually it's NSPersistentDocument, which adds
> even more to the mess) implementation.
>
> Jerry
>
> -
> (void)autosaveWithImplicitCancellability:(BOOL)autosavingIsImplicitlyCancellable
> completionHandler:(void (^)(NSError
> *errorOrNil))completionHandler {
>if (autosavingIsImplicitlyCancellable) {
>// We can cancel this autosave if we want to.
>if (
>// If operations are currently in progress, cancel it. This is
>// because we will save when our operations are complete.
>([[[self operationQueue] operations] count] != 0)
>||
>// Prevent unnecessary saves, in case the document is in a watched
> folder
>// that triggers a syncing mechanism.
>(![self isDocumentEdited])
>) {
>// Cancel it.
>completionHandler([NSError errorWithDomain:NSCocoaErrorDomain
> code:NSUserCancelledError
> userInfo:nil]) ;
>return ;
>}
>}
>
>NSMutableDictionary* info = [NSMutableDictionary dictionary] ;
>[info setValue:Block_copy(completionHandler)
> forKey:constKeyCompletionHandler] ;
>[info setObject:self forKey:constKeyDocument] ;
>// The following adds a task to my home-made main operation
>// queue which I wrote back in the Leopard days …
>NSArray* selectorNames = [NSArray arrayWithObject:@"reallyAutosave"] ;
>[[self operationQueue] queueGroup:@"Non-cancellable Autosave"
>addon:NO
>selectorNames:selectorNames
> info:info
>block:NO
>owner:self
> doneThread:nil
> doneTarget:nil
> doneSelector:NULL
> keepWithNext:NO] ;
>[self setSavingState:1] ;
> }
>
>
> // This is the method that runs (in the main thread) to fulfill
> "reqllyAutosave"
>
> - (void)reallyAutosave_unsafe {
>NSDictionary* info = [self info] ;
>Bkmslf* bkmslf = [info objectForKey:constKeyDocument] ;
>
>void (^completionHandler)(NSError*) = [info
> objectForKey:constKeyCompletionHandler] ;
>
>[bk
Re: Temporarily disabling autosave
On 2013 Apr 19, at 12:37, Mike Abdullah wrote:
> Why, what's wrong with cancelling a [auto]save?
That's a damned good question, Mike. You're probably thinking that, hey, we
lived without any autosaves from 1984 to 2011. What's the big deal? It turns
out that you need to be really careful when playing around with an autosave
that Cocoa has designated "not implicitly cancellable". Search the internet
for:
deadlock in -[NSDocument performActivityWithSynchronousWaiting:usingBlock:]
to see some of the fun that people have had.
I have an app with a requirement similar to Steve's. The app can do
long-winded sequences of operations that take tens of seconds, and change the
document. So if I honored an autosave request during one these sequences, I'd
have to interrupt the operations (which is tricky), save, and then save again
at the end after the changes were done.
The solution: Upon receiving a non-cancellable autosave message while other
operations are in progress, I stash the completion handler that Cocoa sends in
the message, create an operation to "really autosave" later, and add it to my
operation queue.
I had to do other stuff to deal with corner cases such as Revert, being in the
Versions Browser, etc. Below, I've snipped out a few of the relevant methods
from my NSDocument (actually it's NSPersistentDocument, which adds even more to
the mess) implementation.
Jerry
-
(void)autosaveWithImplicitCancellability:(BOOL)autosavingIsImplicitlyCancellable
completionHandler:(void (^)(NSError
*errorOrNil))completionHandler {
if (autosavingIsImplicitlyCancellable) {
// We can cancel this autosave if we want to.
if (
// If operations are currently in progress, cancel it. This is
// because we will save when our operations are complete.
([[[self operationQueue] operations] count] != 0)
||
// Prevent unnecessary saves, in case the document is in a watched
folder
// that triggers a syncing mechanism.
(![self isDocumentEdited])
) {
// Cancel it.
completionHandler([NSError errorWithDomain:NSCocoaErrorDomain
code:NSUserCancelledError
userInfo:nil]) ;
return ;
}
}
NSMutableDictionary* info = [NSMutableDictionary dictionary] ;
[info setValue:Block_copy(completionHandler)
forKey:constKeyCompletionHandler] ;
[info setObject:self forKey:constKeyDocument] ;
// The following adds a task to my home-made main operation
// queue which I wrote back in the Leopard days …
NSArray* selectorNames = [NSArray arrayWithObject:@"reallyAutosave"] ;
[[self operationQueue] queueGroup:@"Non-cancellable Autosave"
addon:NO
selectorNames:selectorNames
info:info
block:NO
owner:self
doneThread:nil
doneTarget:nil
doneSelector:NULL
keepWithNext:NO] ;
[self setSavingState:1] ;
}
// This is the method that runs (in the main thread) to fulfill "reqllyAutosave"
- (void)reallyAutosave_unsafe {
NSDictionary* info = [self info] ;
Bkmslf* bkmslf = [info objectForKey:constKeyDocument] ;
void (^completionHandler)(NSError*) = [info
objectForKey:constKeyCompletionHandler] ;
[bkmslf reallyAutosaveWithCompletionHandler:completionHandler] ;
// Note: completionHandler will be released by the receiver of the above
message.
}
/*!
@briefOverride of new asynchronous saving method invoked by Cocoa
when running in Mac OS X 10.7 or later.
*/
- (void)saveToURL:(NSURL *)url
ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation
completionHandler:(void (^)(NSError *errorOrNil))completionHandler {
[self prepareForSaveOperation:saveOperation] ;
// Despite my best efforts to play nice with autosave, it still occasionally
// deadlocked on me, until I added this:
if ([self savingState] > 1) {
NSLog(@"Warning 089-0831 Cancelling save, now in state %ld, from %@ to
avoid deadlock", (long)[self savingState], SSYDebugCaller()) ;
completionHandler([NSError errorWithDomain:NSCocoaErrorDomain
code:NSUserCancelledError
userInfo:nil]) ;
return ;
}
[self setSavingState:2] ;
[super saveToURL:url
ofType:typeName
forSaveOperation:saveOperation
completionHandler:completionHandler] ;
}
- (void)doHousekeepingAfterSaveNotification:(NSNotification*)note {
[self setSavingState:0] ;
...
}
Re: Temporarily disabling autosave
On Apr 19, 2013, at 13:04 , Steve Mills wrote: > This leads me to believe that the autosave dirty state is getting out of > whack if the save doesn't happen as planned. Any ideas? a. When you get an autosave during playback, can you save the dirty state of the document, return a YES result but not actually autosave, then when playback stops, if you have this saved state, restore it (via NSChangeReadOtherContents or whatever)? The downside is that if your app crashes during playback, the pending changes are lost. b. At a higher level, force an autosave to occur just before playback starts, then don't let the document get dirtied till playback ends. c. If the autosave is asynchronous, you can just not return from it until playback finishes. Note, however, this does not prevent another autosave from arriving after some time interval, so you need to be careful that the second one doesn't step on the first one. (This autosave behavior is a bug, IMO, but it is the current behavior.) ___ 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 19, 2013, at 14:37:11, Mike Abdullah wrote: > Why, what's wrong with cancelling a save? It just seems icky. Who knows what behavior this will cause in the future? I just tried this approach, and it works the same as when I tried returning NO from hasUnautosavedChanges; it successfully prevents the autosave from happening, but then no other autosaves happen after that. I have to completely close the document and reopen before autosaves happen again. I even tried reverting with no luck. This leads me to believe that the autosave dirty state is getting out of whack if the save doesn't happen as planned. Any ideas? -- 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: Temporarily disabling autosave
On 19 Apr 2013, at 20:17, Steve Mills wrote: > On Apr 19, 2013, at 13:40:12, Mike Abdullah wrote: > >> Why is it causing an interruption? That sounds suspicious to me. > > Just because. This isn't simply ol' audio playback. This is a lot more > complex. Go with it. OK. > >> It sounds like you might want to have your -write… routine check >> -autosavingIsImplicitlyCancellable and bail if it returns YES during >> playback. > > But it's not that I want to cancel a save, I just want it to be skipped until > we stop playback. Why, what's wrong with cancelling a save? ___ 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 19, 2013, at 13:40:12, Mike Abdullah wrote: > Why is it causing an interruption? That sounds suspicious to me. Just because. This isn't simply ol' audio playback. This is a lot more complex. Go with it. > It sounds like you might want to have your -write… routine check > -autosavingIsImplicitlyCancellable and bail if it returns YES during playback. But it's not that I want to cancel a save, I just want it to be skipped until we stop playback. I tried returning NO from hasUnautosavedChanges if it's called during playback, but this seems to prevent autosave from firing again, even if I make changes to the doc, which causes updateChangeCount:NSChangeDone. -- 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: Temporarily disabling autosave
On 19 Apr 2013, at 19:25, Steve Mills wrote: > What's the best way to temporarily disable autosave (autosavesInPlace and > preservesVersions are both off), like if I don't want to interrupt our audio > playback? Simply override hasUnautosavedChanges and return NO if I want it > disabled, otherwise call super? Why is it causing an interruption? That sounds suspicious to me. It sounds like you might want to have your -write… routine check -autosavingIsImplicitlyCancellable and bail if it returns YES during playback. ___ 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: Preventing edits in Versions browser
On 19 Apr 2013, at 16:13, Jerry Krinock wrote: > > On 2013 Apr 17, at 09:23, Steve Mills wrote: > >> But TextEdit doesn't seem to prevent any actual edits from happening, but >> instantly undoes each edit. So you see the change for a split second. That's >> not a very good user experience. What does everyone else do? > > I agree it's weird, but I just let it go that way. I thought, "Apple knows > more about user experience than me" :)) > >> Disable menu items and disallow edits based solely or in part on the >> isInViewingMode result? > > Maybe the thinking is that the user is going to get an unexpected result, one > way or the other. Quickly changing it back tells the user that "Yes, we know > what you want to do, but you can't do that (change history)". > >> Does isInViewingMode ever return YES for reasons other than for docs being >> browsed in Versions? > > I found some opposite cases, in Mac OS X 10.7, wherein -[NSPersistentDocument > isInViewingMode] would return NO at times when it should have returned YES. > My code comments don't give any more detail. Anyhow, I overrode it. If > super returns NO, my override double-checks this answer by asking if [[self > fileURL] path] contains the component @".DocumentRevisions-V100". Not nice, > but it made things work. For neatness, I'd probably check [[self fileURL] pathComponents]. ___ 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
Temporarily disabling autosave
What's the best way to temporarily disable autosave (autosavesInPlace and preservesVersions are both off), like if I don't want to interrupt our audio playback? Simply override hasUnautosavedChanges and return NO if I want it disabled, otherwise call super? -- 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: Circular references caused by scheduled NSTimers?
> 2) make a __weak reference to self, and only use that inside the block, your > controller won't be retained. That's another alarming problem that I have become aware of in context of my question. It turns out that if you use blocks instead of delegates inaccurately, you can end up creating a strong reference (e.g. by mentioning self in the block) and a circular reference even without being aware of it. I am now seriously thinking that blocks can be evil for replacing delegates (which by convention are always assign properties, i.e. weak references). Am I right? On Fri, Apr 19, 2013 at 10:10 AM, Charles Srstka wrote: > On Apr 19, 2013, at 1:01 AM, Oleg Krupnov wrote: > >> I recently encountered an alarming problem that I have never been >> aware of, and I'd like to ask about the best practice to handle it. >> >> Is it true that any object (let's call it Controller) that owns an >> NSTimer, scheduled to fire a method (let's call it -timerDidFire) of >> the same Controller, creates a circular reference and causes the >> Controller to never be released and the timer never stop triggering? >> >> It looks like scheduling the timer causes the run loop to retain a >> reference to the object that implements -timerDidFire, in this case >> it's the Controller. Is this true? Then this is a circular reference, >> right? >> >> In this case, if [_timer invalidate]; is called only in Controller's >> dealloc, then the timer never stops firing? >> >> Which is the best way to prevent this problem? Currently I'm thinking >> about some kind of -[controller disconnect]; method that I need to >> call before [controller release]; in controller's parent object, but >> that seems a bit unwieldy solution. >> >> Any other ideas/considerations? Thanks! > > What I'd probably do would be to use a GCD timer instead of an NSTimer. That > way, you can pass the timer a block instead of a reference to the controller, > and as long as you either 1) don't reference self within the block or 2) make > a __weak reference to self, and only use that inside the block, your > controller won't be retained. > > Charles > ___ 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: Preventing edits in Versions browser
On 2013 Apr 17, at 09:23, Steve Mills wrote: > But TextEdit doesn't seem to prevent any actual edits from happening, but > instantly undoes each edit. So you see the change for a split second. That's > not a very good user experience. What does everyone else do? I agree it's weird, but I just let it go that way. I thought, "Apple knows more about user experience than me" :)) > Disable menu items and disallow edits based solely or in part on the > isInViewingMode result? Maybe the thinking is that the user is going to get an unexpected result, one way or the other. Quickly changing it back tells the user that "Yes, we know what you want to do, but you can't do that (change history)". > Does isInViewingMode ever return YES for reasons other than for docs being > browsed in Versions? I found some opposite cases, in Mac OS X 10.7, wherein -[NSPersistentDocument isInViewingMode] would return NO at times when it should have returned YES. My code comments don't give any more detail. Anyhow, I overrode it. If super returns NO, my override double-checks this answer by asking if [[self fileURL] path] contains the component @".DocumentRevisions-V100". Not nice, but it made things work. ___ 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: My App crash on 10.7.5, but works on 10.8
Found the problem, there's another place I declared the window controller as weak. Thanks. * * * * On Fri, Apr 19, 2013 at 9:19 AM, Uli Kusterer wrote: > According to the release notes for ARC: > > > http://developer.apple.com/library/ios/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html > > > Which classes don’t support weak references? > > > > You cannot currently create weak references to instances of the > following classes: > > > > NSATSTypesetter, NSColorSpace, NSFont, NSMenuView, NSParagraphStyle, > NSSimpleHorizontalTypesetter, and NSTextView. > > > > Note: In addition, in OS X v10.7, you cannot create weak references to > instances of NSFontManager, NSFontPanel, NSImage, > NSTableCellView,NSViewController, NSWindow, and NSWindowController. In > addition, in OS X v10.7 no classes in the AV Foundation framework support > weak references. > > So NSWindowController didn't support weak references until 10.8. That > chapter has instructions what to do instead. > > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > http://www.zathras.de > > ___ 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: My App crash on 10.7.5, but works on 10.8
According to the release notes for ARC: http://developer.apple.com/library/ios/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html > Which classes don’t support weak references? > > You cannot currently create weak references to instances of the following > classes: > > NSATSTypesetter, NSColorSpace, NSFont, NSMenuView, NSParagraphStyle, > NSSimpleHorizontalTypesetter, and NSTextView. > > Note: In addition, in OS X v10.7, you cannot create weak references to > instances of NSFontManager, NSFontPanel, NSImage, > NSTableCellView,NSViewController, NSWindow, and NSWindowController. In > addition, in OS X v10.7 no classes in the AV Foundation framework support > weak references. So NSWindowController didn't support weak references until 10.8. That chapter has instructions what to do instead. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de ___ 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: Showing a drawer on a sheet
On Apr 19, 2013, at 1:37 PM, Antonio Nunes wrote: > I have a panel that is shown as a sheet on the document window. I'm trying to > show a drawer (NSDrawer) when a certain tab is selected. The drawer shows, > but behind the main document window, rather than in front of it, thus being > either partly or completely obscured. The drawer window level is the same as > the panel's level (3), so I'm not sure why the drawer is drawn behind the > main window. As an experiment I tried adjusting the drawer's parentWindow > level but to no avail. Is there any way to make this work? (i.e. show the > drawer in front of the main window) I don't think that's a supported UI configuration. In general, sheets are reserved for short modal interactions, while drawers are intended to provide more in-depth options in non-modal windows. If you need an in-depth interaction in a sheet, that sounds like a very odd occurrence. May I ask why? What does the sheet contain, and what does the drawer add to that? If you just want to show an advanced checkbox as an additional option in the sheet, you should probably use a disclosure triangle. For example, we have this: http://twitpic.com/ckf5j2 that expands into this: http://twitpic.com/ckf5ob We originally didn't have this, but people kept checking the options when they didn't have to, so we decided to hide them. People who have problems go searching for more options and find them, but everyone else gets a fairly simple confirmation dialog. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de ___ 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
My App crash on 10.7.5, but works on 10.8
I have an app, which made it to the App Store just a few days ago. But I
received a few crash reports from some users.
*The information is as following:*
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0001, 0x
Application Specific Information:
objc[3449]: garbage collection is OFF
objc[3449]: cannot form weak reference to instance (0x10e761920) of class
LSMainWindowController
*In the LSMainWindowController, I have the following declaration:*
@property(unsafe_unretained, nonatomic) IBOutlet LSTextView *textView;
#if __has_feature(objc_arc_weak)
@property(weak, nonatomic) LSAppDelegate *appDelegate;
#else
@property(unsafe_unretained, nonatomic) LSAppDelegate *appDelegate;
#endif
*In the applicationDidFinishLaunching method in AppDelegate:*
if (!_mainWindowController) {
_mainWindowController = [[LSMainWindowController alloc]
initWithWindowNibName:@"LSMainWindow"];
}
[_mainWindowController showWindow:self];
Any thoughts? Really need to fix this as soon as possible.
-
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Showing a drawer on a sheet
Hi, I have a panel that is shown as a sheet on the document window. I'm trying to show a drawer (NSDrawer) when a certain tab is selected. The drawer shows, but behind the main document window, rather than in front of it, thus being either partly or completely obscured. The drawer window level is the same as the panel's level (3), so I'm not sure why the drawer is drawn behind the main window. As an experiment I tried adjusting the drawer's parentWindow level but to no avail. Is there any way to make this work? (i.e. show the drawer in front of the main window) -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: Circular references caused by scheduled NSTimers?
Thanks for your answers!
Now I'm thinking that I'd rather create a helper category on NSTimer
with a method that will schedule a timer but under the hood also
create the helper object. In this way, the current code of my project
will almost not change (only change the scheduling method). The helper
class will be private. The helper will not be retained by anyone
except the run loop and will be dealloced immediately after the timer
is invalidated
@interface TimerHelper
@property (nonatomic, assign) id target;
@property (nonatomic, assign) SEL action;
- (void)timerDidFire;
@end
@implementation TimerHelper
- (void)timerDidFire
{
[_target performSelector:_action withObject:nil];
}
@end
@implementation NSTimer (Helper)
+ (NSTimer*)scheduleTimerWithInterval:(NSTimeInterval)interval
target:(id)target action:(SEL)action
{
TimerHelper* helper = [[[TimerHelper alloc] init] autorelease];
helper.target = target;
helper.action = action;
NSTimer* timer = [NSTimer scheduledTimerWithTimeInterval:interval
target:helper selector:@selector(timerDidFire) userInfo:nil
repeats:YES];
return timer;
}
@end
@implementation Controller
{
NSTimer* _timer;
}
- (void)someMethod
{
_timer = [[NSTimer scheduleTimerWithInterval:interval target:self
action:@selector(someTimerDidFire)] retain];
}
- (void)dealloc
{
[_timer invalidate];
[_timer release];
[super dealloc];
}
@end
I think this is a more elegant solution than public helper. Any caveats?
On Fri, Apr 19, 2013 at 9:53 AM, Graham Cox wrote:
>
> On 19/04/2013, at 4:35 PM, Greg Parker wrote:
>
>> Another solution is to introduce a weak reference between the timer and your
>> controller. Create a helper class that holds a weak reference to your
>> Controller object.
>
>
> Since Greg and I have offered the same solution, here's an implementation of
> it you could use:
>
> Usage would be for your controller to alloc/init the helper/proxy (or use the
> convenience method and retain it) and then in its -dealloc method call
> -invalidate followed by -release.
>
> // .h file:
>
>
> #import
>
>
>
> @interface GCTimerTarget : NSObject
> {
> @private
> NSTimer*mTimerRef;
> id mTrueTargetRef;
> SEL mSelector;
> }
>
> @property (nonatomic, assign) NSTimer* timer;
> @property (nonatomic, assign) idtrueTarget;
> @property (nonatomic, assign) SEL selector;
>
> + (GCTimerTarget*) scheduledTimerWithInterval:(NSTimeInterval) t
> target:(id) target selector:(SEL) selector repeats:(BOOL) repeats;
>
> - (id) initForTarget:(id) trueTarget selector:(SEL) selector;
> - (void)invalidate;
>
> @end
>
>
> /// .m file:
>
> #import "GCTimerTarget.h"
>
>
>
> @interface GCTimerTarget ()
>
> - (void)timerCallback:(NSTimer*) timer;
>
> @end
>
>
> #pragma mark -
>
>
> @implementation GCTimerTarget
>
> @synthesize timer = mTimerRef;
> @synthesize trueTarget = mTrueTargetRef;
> @synthesize selector = mSelector;
>
>
>
> + (GCTimerTarget*) scheduledTimerWithInterval:(NSTimeInterval) t
> target:(id) target selector:(SEL) selector repeats:(BOOL) repeats
> {
> // convenience method makes the proxy and adds a scheduled timer to
> it. This can be used instead of the equivalent NSTimer class method
>
> GCTimerTarget* tt = [[[self alloc] initForTarget:target
> selector:selector] autorelease];
> tt.timer = [NSTimer scheduledTimerWithTimeInterval:t target:tt
> selector:@selector(timerCallback:) userInfo:nil repeats:repeats];
>
> return tt;
> }
>
>
>
> - (id) initForTarget:(id) trueTarget selector:(SEL) selector
> {
> self = [super init];
> if( self )
> {
> mTrueTargetRef = trueTarget;
> mSelector = selector;
> }
>
> return self;
> }
>
>
> - (void)invalidate
> {
> self.trueTarget = nil;
> [self.timer invalidate];
> self.timer = nil;
>
> // could call [self autorelease] here to make the proxy a one-line
> teardown, but it's probably safer to leave it as is
> // and rely on a deliberate -release as usual.
> }
>
>
> - (void)timerCallback:(NSTimer*) timer
> {
> if([self.trueTarget respondsToSelector:self.selector])
> [self.trueTarget performSelector:self.selector
> withObject:timer];
> }
>
>
> @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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSScrollView in NSTabView autolayout problem
Thank you Chuck for pointing me to the answer I will try that. I know that NSScrollView is not build with Autolayout in mind but I hoped using it would save several boring layout managment problems arising in my design. Also, I did send the message last week but as it was my first to this mailing list, I was not sure how long it take so I did not resend. Thanks again K On 18/04/2013 17:37, Chuck Soper wrote: This message may be relevant for your issue: http://prod.lists.apple.com/archives/cocoa-dev/2013/Feb/msg00426.html Personally, I don't use auto layout in NSScrollView. I think that NSScrollView doesn't support it, but it appears that many people have gotten it to work. Chuck P.S. It looks like your message was sent to the list on Saturday, but I didn't receive it until this morning. On 4/13/13 1:57 PM, "kwic...@wichry.net" wrote: Hi I have an NSTabView with multiple tabs, each containing an NSScrollView. In the scrollviews I dynamically place custom views which are sized using autolayout and constraints. Now if I add my custom views to a scrollview in tab1 and resize the window with this tab active everything works fine and autolayout does not complain. On the other hand, if I add my custom views to a scrollview in tab1, switch to another tab, resize the window, and switch back to tab1 autolayout breaks with the following exemplar message: Unable to simultaneously satisfy constraints: ( "", "", "", "", "" ) What I noticed in the message is this "H:[NSClipView:0x40120eb80(0)]". How come the NSClipView so in fact contentView of the scrollview has width = 0? My question is, why does the autolayout work fine for the active tab and does for inactive? Thanks k. ___ 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/chucks%40veladg.com This email sent to chu...@veladg.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: Circular references caused by scheduled NSTimers?
On Apr 19, 2013, at 1:01 AM, Oleg Krupnov wrote: > I recently encountered an alarming problem that I have never been > aware of, and I'd like to ask about the best practice to handle it. > > Is it true that any object (let's call it Controller) that owns an > NSTimer, scheduled to fire a method (let's call it -timerDidFire) of > the same Controller, creates a circular reference and causes the > Controller to never be released and the timer never stop triggering? > > It looks like scheduling the timer causes the run loop to retain a > reference to the object that implements -timerDidFire, in this case > it's the Controller. Is this true? Then this is a circular reference, > right? > > In this case, if [_timer invalidate]; is called only in Controller's > dealloc, then the timer never stops firing? > > Which is the best way to prevent this problem? Currently I'm thinking > about some kind of -[controller disconnect]; method that I need to > call before [controller release]; in controller's parent object, but > that seems a bit unwieldy solution. > > Any other ideas/considerations? Thanks! What I'd probably do would be to use a GCD timer instead of an NSTimer. That way, you can pass the timer a block instead of a reference to the controller, and as long as you either 1) don't reference self within the block or 2) make a __weak reference to self, and only use that inside the block, your controller won't be retained. Charles ___ 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
