Re: Nav stack creating a bunch of UIImageViews on top of my view
Nevermind, it was a red herring. I thought those views were blocking user interaction, but it's autolayout sucking ass again, shrinking a parent view such that it was not encompassing a button in a subview. On Aug 20, 2013, at 19:12 , Rick Mann wrote: > iOS 6.1.3. > > I have a navigation stack in a UIPopover, using autolayout, and I'm > programmtically instantiating a couple of view controllers from scenes in the > storyboard and installing them in a view controller container view in the > view controller on the top of my navigation stack. I swap VCs as the user > taps a segmented control. > > Aside from no end of hell with autolayout and translatesautoresizingmasks, > I'm experiencing a new problem: I get a half-dozen UIImageViews ON TOP of my > views, making it impossible to interact with the UI. > > There's one UIImageView that covers the entire view controller, and four more > that seem to be for decorations on all four borders of the view. > > What the hell is this? It's not always there. > > -- > 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/rmann%40latencyzero.com > > This email sent to rm...@latencyzero.com -- 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
Nav stack creating a bunch of UIImageViews on top of my view
iOS 6.1.3. I have a navigation stack in a UIPopover, using autolayout, and I'm programmtically instantiating a couple of view controllers from scenes in the storyboard and installing them in a view controller container view in the view controller on the top of my navigation stack. I swap VCs as the user taps a segmented control. Aside from no end of hell with autolayout and translatesautoresizingmasks, I'm experiencing a new problem: I get a half-dozen UIImageViews ON TOP of my views, making it impossible to interact with the UI. There's one UIImageView that covers the entire view controller, and four more that seem to be for decorations on all four borders of the view. What the hell is this? It's not always there. -- 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: CoreText & NSMutableParagraphStyle maximumLineHeight
Just tested NSParagraphStyle lineHeightMultiple, the line space expands only. It is similar to NSParagraphStyle lineSpacing, no negative value possible. Below is the method what I intended to do, // lspace - 0.0 neutral , negative value the line height contracts and positive value line height expands - (NSMutableParagraphStyle *)adjustLineSpacing:(CGFloat)lspace { NSMutableParagraphStyle *paragraphStyle = [[NSMutableParagraphStyle alloc] init]; NSLayoutManager *lm; NSFont *fontObj; CGFloat defLineHeight; CGFloat calc; if (lspace > 0.0) paragraphStyle.lineSpacing = lspace; else if (lspace < 0.0) { fontObj = [NSFont fontWithName:_fontNameStr size:_fontSize]; lm = [[NSLayoutManager alloc] init]; defLineHeight = [lm defaultLineHeightForFont:fontObj]; [lm release]; calc = (lspace + 1.0) + defLineHeight; if (calc < 1.0) calc = 1.0; paragraphStyle.maximumLineHeight = calc; } return [paragraphStyle autorelease]; } -- Peter Chan ___ 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: handleGetURLEvent getting called after applicationDidFinishLaunching
On Aug 20, 2013, at 1:05 PM, Jens Alfke wrote: > > On Aug 20, 2013, at 11:38 AM, Bradley O'Hearne > wrote: > >> 1. Is there any guaranteed invocation order of these methods, or is it >> completely random? I cannot think of any scenario where you'd want to >> process the URL launching event *after* the callback which signifies app >> launch completion. That just seems wrong. > > Under the hood, the mechanism is that the Launch Services options for > launching an app can include an AppleEvent to send the app upon launch. Most > commonly this is an ‘odoc’ (open document) event, if the app was launched by > double-clicking a document. In the case of opening via a URL, as in your > case, that event would be a ‘GURL’ (goto URL). In the case where there’s no > AppleEvent given, the app receives an ‘oapp’ (open app) event just to tell it > that it isn’t going to get a different special event. > > The reason for ‘oapp’ is for the exact thing you’re describing: the app wants > to know when it’s done launching, i.e. when the special launch-time events > are over. > >> 2. Assuming that the answer to 1 is that there IS an expected invocation >> order, then what could possibly cause this problem? This smells an awful lot >> like something to do with unexpected results of thread scheduling in the OS >> (not in the app, I'm creating no threads at all). > > It might be an AppKit bug, or it might be in the Finder (e.g. maybe it’s > launching the app normally and then sending the GURL event, instead of > attaching the event to the launch options.) > > —Jens Jens, In my case, the URL is custom, configured with launch services and in my app's info.plist file. The app is launched by opening a URL with the specified protocol from a web browser. It is not being launched any other way (such as from the Finder). Brad ___ 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: handleGetURLEvent getting called after applicationDidFinishLaunching
On Aug 20, 2013, at 12:37 PM, Jerry Krinock wrote: > > On 2013 Aug 20, at 11:38, Bradley O'Hearne wrote: > >> So far, this problem seems isolated to Snow Leopard, I have not seen it on >> Lion or Mountain Lion. Also, the problem is intermittent [and much more] … > > Brad, you probably know more about this problem than anyone in the world > today. For issues with ancient versions of the OS, the smart strategy is: > Patch It and Move On. Even if there were an Apple engineer or two that > worked on this behavior three years ago, they are no doubt totally consumed > with iOS 8 or whatever comes after Mac OS X 10.9. Alas….not my choice. I've recommended the same to my client. They not only require support for, but have targeted, Snow Leopard. Unfortunately it is not within my power to change that. Thanks for the reply. Brad ___ 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: handleGetURLEvent getting called after applicationDidFinishLaunching
On Aug 20, 2013, at 12:37 PM, Ken Thomases wrote: > No, you're mistaken. This is not a callback specifically for an app being > launched to handle a URL. It's a callback to handle a request to open a URL, > whenever it happens. It is perfectly normal for it to be delivered after an > app is launched. Click a mailto: link on a website? Your mail program is > told to handle it. It may be launched to handle it, but it's quite likely to > have already been running. Click an http: link in an email? Your browser is > told to handle it. Again, it may be launched if it's not already running, > but it's quite likely to be already running. Ken, Thanks for that clarification. That helps immensely. Brad ___ 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: Converting to Arc → undeclared identifier
On 21/08/2013, at 12:59 AM, Gerriet M. Denkmann wrote: >> What version of Xcode? I just tried this with Xcode 4.6.3 and it worked >> perfectly. > > A difficult question: I am not allowed to talk about this (which might give > you an idea, which version I was using). Worked fine for me in an unmentionable version, FWIW. -- Shane Stanley 'AppleScriptObjC Explored' ___ 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: NSLog object = nil?
Thanks for this. I'd like to try using the Document object that owns the itemStore. The itemStore objects are created by the Document object in a loop as part of a dispatch_async GCD block. The itemStores' workers have a reference to the Document object. But since the itemStore objects are created within a loop and not as properties, the Document object has no direct reference to them. This means that calling self.document.itemStore = nil won't help either. Or is there a way to do this? I'd like to clear out itemStores for which the workers have completed their tasks, to manage CPU usage... Verstuurd vanaf mijn iPhone Op 20 aug. 2013 om 23:45 heeft Ken Thomases het volgende geschreven: > On Aug 20, 2013, at 4:32 PM, Diederik Meijer | Ten Horses wrote: > >> An itemStore object creates a worker object (property of itemStore object) >> that hold a weak reference back to the itemStore object; >> When the worker classes is done, it sets the itemStore object (of which the >> worker class itself is a property) to nil. > > It doesn't set the object to nil. It sets its reference to the itemStore > object to nil. > >> This project uses ARC. >> >> So within itemStore I do: >> self.worker = [[Worker alloc] init]; >> [self.worker setItemStore:self]; >> >> In Worker.h I do >> @property (nonatomic, weak) ItemStore *itemStore; >> >> In Worker.m, when all its tasks are done, I do >> self.itemStore = nil; >> >> I assume this completely destroys the itemStore object and all objects it >> exclusively owns. > > No. The itemStore property of Worker is weak. That means it does not > influence the lifetime of the itemStore object it references. Setting the > reference to nil simply makes it no longer reference that object. > > >> Is there any way to NSLog the destruction of the itemStore object? >> >> I tried putting a log in itemStore's dealloc method, but it doesn't show up >> in the console. > > Putting a call to NSLog() in the -dealloc would be the way to detect it. > Nothing is showing up because the itemStore object is not being deallocated. > > If you want to deallocate it, you have to make sure to clear all strong > references to it. Clearing weak references doesn't help. > > Regards, > Ken > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSLog object = nil?
Wouldn’t be possible to implement dealloc in that class and put an NSLog call there? Of course, in an ARC project, you wouldn’t call [super dealloc] but would that cause a problem? -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.com On Aug 20, 2013, at 17:45, Ken Thomases wrote: > On Aug 20, 2013, at 4:32 PM, Diederik Meijer | Ten Horses wrote: > >> An itemStore object creates a worker object (property of itemStore object) >> that hold a weak reference back to the itemStore object; >> When the worker classes is done, it sets the itemStore object (of which the >> worker class itself is a property) to nil. > > It doesn't set the object to nil. It sets its reference to the itemStore > object to nil. > >> This project uses ARC. >> >> So within itemStore I do: >> self.worker = [[Worker alloc] init]; >> [self.worker setItemStore:self]; >> >> In Worker.h I do >> @property (nonatomic, weak) ItemStore *itemStore; >> >> In Worker.m, when all its tasks are done, I do >> self.itemStore = nil; >> >> I assume this completely destroys the itemStore object and all objects it >> exclusively owns. > > No. The itemStore property of Worker is weak. That means it does not > influence the lifetime of the itemStore object it references. Setting the > reference to nil simply makes it no longer reference that object. > > >> Is there any way to NSLog the destruction of the itemStore object? >> >> I tried putting a log in itemStore's dealloc method, but it doesn't show up >> in the console. > > Putting a call to NSLog() in the -dealloc would be the way to detect it. > Nothing is showing up because the itemStore object is not being deallocated. > > If you want to deallocate it, you have to make sure to clear all strong > references to it. Clearing weak references doesn't help. > > Regards, > Ken > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/laurent%40nemesys-soft.com > > This email sent to laur...@nemesys-soft.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSLog object = nil?
On Aug 20, 2013, at 2:32 PM, Diederik Meijer | Ten Horses wrote: > Is there any way to NSLog the destruction of the itemStore object? Sure, but you'll save a lot more time if you use Instruments to track object lifetimes - it'll show you who does own the object and keeps you from hitting dealloc. ___ 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: NSLog object = nil?
Apologies, no need to respond, I have just fixed this.. Op Aug 20, 2013, om 11:32 PM heeft Diederik Meijer | Ten Horses het volgende geschreven: > Dear list, > > I have the following structure: > > An itemStore object creates a worker object (property of itemStore object) > that hold a weak reference back to the itemStore object; > When the worker classes is done, it sets the itemStore object (of which the > worker class itself is a property) to nil. > > This project uses ARC. > > So within itemStore I do: > self.worker = [[Worker alloc] init]; > [self.worker setItemStore:self]; > > In Worker.h I do > @property (nonatomic, weak) ItemStore *itemStore; > > In Worker.m, when all its tasks are done, I do > self.itemStore = nil; > > I assume this completely destroys the itemStore object and all objects it > exclusively owns. > > Is there any way to NSLog the destruction of the itemStore object? > > I tried putting a log in itemStore's dealloc method, but it doesn't show up > in the console. > > Many thanks, > > Diederik > ___ > > 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/diederik%40tenhorses.com > > This email sent to diede...@tenhorses.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: NSLog object = nil?
On Aug 20, 2013, at 4:32 PM, Diederik Meijer | Ten Horses wrote: > An itemStore object creates a worker object (property of itemStore object) > that hold a weak reference back to the itemStore object; > When the worker classes is done, it sets the itemStore object (of which the > worker class itself is a property) to nil. It doesn't set the object to nil. It sets its reference to the itemStore object to nil. > This project uses ARC. > > So within itemStore I do: > self.worker = [[Worker alloc] init]; > [self.worker setItemStore:self]; > > In Worker.h I do > @property (nonatomic, weak) ItemStore *itemStore; > > In Worker.m, when all its tasks are done, I do > self.itemStore = nil; > > I assume this completely destroys the itemStore object and all objects it > exclusively owns. No. The itemStore property of Worker is weak. That means it does not influence the lifetime of the itemStore object it references. Setting the reference to nil simply makes it no longer reference that object. > Is there any way to NSLog the destruction of the itemStore object? > > I tried putting a log in itemStore's dealloc method, but it doesn't show up > in the console. Putting a call to NSLog() in the -dealloc would be the way to detect it. Nothing is showing up because the itemStore object is not being deallocated. If you want to deallocate it, you have to make sure to clear all strong references to it. Clearing weak references doesn't help. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSLog object = nil?
On 20 Aug 2013, at 23:32, Diederik Meijer | Ten Horses wrote: > Dear list, > > I have the following structure: > > An itemStore object creates a worker object (property of itemStore object) > that hold a weak reference back to the itemStore object; > When the worker classes is done, it sets the itemStore object (of which the > worker class itself is a property) to nil. > > This project uses ARC. > > So within itemStore I do: > self.worker = [[Worker alloc] init]; > [self.worker setItemStore:self]; > > In Worker.h I do > @property (nonatomic, weak) ItemStore *itemStore; > > In Worker.m, when all its tasks are done, I do > self.itemStore = nil; > > I assume this completely destroys the itemStore object and all objects it > exclusively owns. > > Is there any way to NSLog the destruction of the itemStore object? > > I tried putting a log in itemStore's dealloc method, but it doesn't show up > in the console. No, this doesn’t destroy the item store at all. If the Worker holds a weak reference, then it setting its reference to nil will not do anything at all re memory management. Instead, whatever is holding strong references to the item store needs to release those references. Tom Davie ___ 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
NSLog object = nil?
Dear list, I have the following structure: An itemStore object creates a worker object (property of itemStore object) that hold a weak reference back to the itemStore object; When the worker classes is done, it sets the itemStore object (of which the worker class itself is a property) to nil. This project uses ARC. So within itemStore I do: self.worker = [[Worker alloc] init]; [self.worker setItemStore:self]; In Worker.h I do @property (nonatomic, weak) ItemStore *itemStore; In Worker.m, when all its tasks are done, I do self.itemStore = nil; I assume this completely destroys the itemStore object and all objects it exclusively owns. Is there any way to NSLog the destruction of the itemStore object? I tried putting a log in itemStore's dealloc method, but it doesn't show up in the console. Many thanks, Diederik ___ 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: NSSpellChecker -ignoreWord:… for NSTextCheckingTypeGrammar?
Thanks for the reply, Doug! Sorry, I somehow didn’t notice it had come in until just now. I’ll file an ER for suitable API (or for updating the docs, if the conclusion is not to provide one). Since I’m using NSSpellChecker with my own, WebView-based content view, I don’t get the benefit of AppKit’s automatic “Ignore” tracking for NSTextViews. So I probably will go the “maintain my own list” route for now, handling -ignoreSpelling: invocations differently when the active result is a grammar result — thanks for confirming that’s an appropriate approach. Regards, Troy On Aug 16, 2013, at 9:01 PM, Douglas Davidson wrote: > Troy, you can file an enhancement request specifically for an "ignore > grammar" API, but currently how it works is that if the last shown checking > result is a grammar checking result, then ignoring the word underlined by > that result will cause that grammar checking result to be ignored. > > It would be perfectly reasonable for you to maintain your own ignore list and > filter grammar-check results based on it. > > Douglas Davidson > > On Aug 8, 2013, at 7:41 AM, Troy Stephens wrote: > >> Is NSSpellChecker’s “ignored words” API meant for use with grammar-checking >> results too? >> >> Seems unlikely to me, and yet that’s what appears to be indicated by the >> documentation and apparent lack of corresponding “-ignoreGrammar…” API. >> >> The Spelling and Grammar panel sends -ignoreSpelling: when the user clicks >> “Ignore” for a grammar-check result, the same as it would do for a >> spell-check result. And the implementation example in the -ignoreSpelling: >> reference documentation unconditionally invokes >> -ignoreWord:inSpellDocumentWithTag: >> >> - (void)ignoreSpelling:(id)sender { >> [[NSSpellChecker sharedSpellChecker] ignoreWord:[[sender selectedCell] >> stringValue] inSpellDocumentWithTag: myDocumentTag]; >> } >> >> >> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSIgnoreMisspelledWords_Protocol/ >> >> It’s hard to tell whether the same technique is really meant to be >> applicable to ignored grammar results, and this bit of documentation wasn’t >> seen as needing updating when grammar-checking was added, or whether the >> documentation is in need of update. >> >> In the absence of clear info, seems like I should take care to invoke >> -ignoreWord:… for spell-check results only. If want to be able to ignore >> grammar results, maybe I need to maintain my own grammar “ignore” list and >> filter received grammar-check results based on it. >> >> Info appreciated if anyone else has run into this. My searching hasn’t >> turned up any answers. >> >> -- >> Troy Stephens >> Developer of TypeMetal: The Visual HTML Editor for OS X >> http://coherencelabs.com/typemetal/ >> >> >> >> >> ___ >> >> 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/ddavidso%40apple.com >> >> This email sent to ddavi...@apple.com > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa-dev Digest, Vol 10, Issue 522
If you have code that needs to happen first/once at start, maybe you can try putting it in awakeFromNib. Also, I think launching apps via NSWorkspace can be a little more robust than apple events, when possible. On Aug 20, 2013, at 3:00 PM, cocoa-dev-requ...@lists.apple.com wrote: > > Message: 6 > Date: Tue, 20 Aug 2013 11:38:52 -0700 > From: "Bradley O'Hearne" > To: List Developer Cocoa > Subject: handleGetURLEvent getting called after >applicationDidFinishLaunching > Message-ID: > Content-Type: text/plain;charset=windows-1252 > > Hello…. > > I have a Mac app that is launched via a URL handler that is installed. The > launch services / configuration setup of the URL handler is fine, app > launches just as expected. However, I am seeing an intermittent problem where > the URL handling method: > > - (void)handleGetURLEvent:(NSAppleEventDescriptor *)event > withReplyEvent:(NSAppleEventDescriptor *)replyEvent; > > is invoked after the app delegate method: > > - (void)applicationDidFinishLaunching:(NSNotification *)aNotification; > > Normally, handleGetURLEvent is invoked first, which is important, because the > implementation of that method is usually needing to capture the URL used to > launch it, for later processing. That is exactly my case, and when the > applicationDidFinishLaunching method is invoked first, the app fails, because > it doesn't have the launch URL which has information needed to run the app. > > So far, this problem seems isolated to Snow Leopard, I have not seen it on > Lion or Mountain Lion. Also, the problem is intermittent -- it works just > fine most of the time, even on the same machine where the problem > occasionally occurs. My questions: > > 1. Is there any guaranteed invocation order of these methods, or is it > completely random? I cannot think of any scenario where you'd want to process > the URL launching event *after* the callback which signifies app launch > completion. That just seems wrong. > > 2. Assuming that the answer to 1 is that there IS an expected invocation > order, then what could possibly cause this problem? This smells an awful lot > like something to do with unexpected results of thread scheduling in the OS > (not in the app, I'm creating no threads at all). > > If anyone has any thoughts or ideas, I'd greatly appreciate it. Even if any > of you have a similar use-case of an app with a URL handler that has to grab > that URL before doing anything in your app, sharing your experience might > help. > > Thanks, > > Brad > > > > > -- > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins (at) lists.apple.com > > https://lists.apple.com/mailman/listinfo/cocoa-dev > > > End of Cocoa-dev Digest, Vol 10, Issue 522 > ** ___ 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: handleGetURLEvent getting called after applicationDidFinishLaunching
On Aug 20, 2013, at 11:38 AM, Bradley O'Hearne wrote: > 1. Is there any guaranteed invocation order of these methods, or is it > completely random? I cannot think of any scenario where you'd want to process > the URL launching event *after* the callback which signifies app launch > completion. That just seems wrong. Under the hood, the mechanism is that the Launch Services options for launching an app can include an AppleEvent to send the app upon launch. Most commonly this is an ‘odoc’ (open document) event, if the app was launched by double-clicking a document. In the case of opening via a URL, as in your case, that event would be a ‘GURL’ (goto URL). In the case where there’s no AppleEvent given, the app receives an ‘oapp’ (open app) event just to tell it that it isn’t going to get a different special event. The reason for ‘oapp’ is for the exact thing you’re describing: the app wants to know when it’s done launching, i.e. when the special launch-time events are over. > 2. Assuming that the answer to 1 is that there IS an expected invocation > order, then what could possibly cause this problem? This smells an awful lot > like something to do with unexpected results of thread scheduling in the OS > (not in the app, I'm creating no threads at all). It might be an AppKit bug, or it might be in the Finder (e.g. maybe it’s launching the app normally and then sending the GURL event, instead of attaching the event to the launch options.) —Jens ___ 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: handleGetURLEvent getting called after applicationDidFinishLaunching
On 2013 Aug 20, at 11:38, Bradley O'Hearne wrote: > So far, this problem seems isolated to Snow Leopard, I have not seen it on > Lion or Mountain Lion. Also, the problem is intermittent [and much more] … Brad, you probably know more about this problem than anyone in the world today. For issues with ancient versions of the OS, the smart strategy is: Patch It and Move On. Even if there were an Apple engineer or two that worked on this behavior three years ago, they are no doubt totally consumed with iOS 8 or whatever comes after Mac OS X 10.9. > 1. Is there any guaranteed invocation order of these methods, or is it > completely random? Anything you can't find in the documentation is not guaranteed. Take the easy answer. Just assume that it is random. This way you're covered if it changes again in Mac OS X 10.9 or beyond. > I cannot think of any scenario where you'd want to process the URL launching > event *after* the callback which signifies app launch completion. That just > seems wrong. It could be, but exactly analogous behavior occurs when an app is launched by double-clicking a document in Finder: -[NSDocumentController openDocumentWithContentsOfURL:display:error: runs *before* -applicationDidFinishLaunching. But when an app is launched by an AppleScript 'open' command, -applicationDidFinishLaunching runs first. > when the applicationDidFinishLaunching method is invoked first, the app > fails, because it doesn't have the launch URL which has information needed to > run the app You need to change your design so it works either way. Move any code that requires the launch URL out of -applicationDidFinishLaunching. It probably belongs in some derivative of -handleGetURLEvent:withReplyEvent:. If there is code that needs to be done in -applicationDidFinishLaunching before you can handle the URL, write a -startUp method and put this code in -startUp, and invoke it within both methods. Use a BOOL isStartedUp to prevent it from running twice. You're done! ___ 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: handleGetURLEvent getting called after applicationDidFinishLaunching
On Aug 20, 2013, at 1:38 PM, Bradley O'Hearne wrote: > I have a Mac app that is launched via a URL handler that is installed. The > launch services / configuration setup of the URL handler is fine, app > launches just as expected. However, I am seeing an intermittent problem where > the URL handling method: > > - (void)handleGetURLEvent:(NSAppleEventDescriptor *)event > withReplyEvent:(NSAppleEventDescriptor *)replyEvent; > > is invoked after the app delegate method: > > - (void)applicationDidFinishLaunching:(NSNotification *)aNotification; > > Normally, handleGetURLEvent is invoked first, which is important, because the > implementation of that method is usually needing to capture the URL used to > launch it, for later processing. That is exactly my case, and when the > applicationDidFinishLaunching method is invoked first, the app fails, because > it doesn't have the launch URL which has information needed to run the app. > > So far, this problem seems isolated to Snow Leopard, I have not seen it on > Lion or Mountain Lion. Also, the problem is intermittent -- it works just > fine most of the time, even on the same machine where the problem > occasionally occurs. My questions: > > 1. Is there any guaranteed invocation order of these methods, or is it > completely random? I cannot think of any scenario where you'd want to process > the URL launching event *after* the callback which signifies app launch > completion. That just seems wrong. No, you're mistaken. This is not a callback specifically for an app being launched to handle a URL. It's a callback to handle a request to open a URL, whenever it happens. It is perfectly normal for it to be delivered after an app is launched. Click a mailto: link on a website? Your mail program is told to handle it. It may be launched to handle it, but it's quite likely to have already been running. Click an http: link in an email? Your browser is told to handle it. Again, it may be launched if it's not already running, but it's quite likely to be already running. Ideally, your code would just be able to handle the URL at the time the event is delivered to your handler, regardless of whether -applicationDidFinishLaunching: has already been invoked. -applicationDidFinishLaunching: is not all that special that you'd have to wait for it, at least from the framework's point of view. Nor should it be a problem to handle a URL after the app has launched. If you for some reason really need to wait until both things have happened, then you can make both methods store information and then do the work in the last of them to occur. (Although there's no such thing as the "last" time your GetURL handler will be called. It can be called at arbitrary times and/or an arbitrary number of times during your app's lifetime.) Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
handleGetURLEvent getting called after applicationDidFinishLaunching
Hello…. I have a Mac app that is launched via a URL handler that is installed. The launch services / configuration setup of the URL handler is fine, app launches just as expected. However, I am seeing an intermittent problem where the URL handling method: - (void)handleGetURLEvent:(NSAppleEventDescriptor *)event withReplyEvent:(NSAppleEventDescriptor *)replyEvent; is invoked after the app delegate method: - (void)applicationDidFinishLaunching:(NSNotification *)aNotification; Normally, handleGetURLEvent is invoked first, which is important, because the implementation of that method is usually needing to capture the URL used to launch it, for later processing. That is exactly my case, and when the applicationDidFinishLaunching method is invoked first, the app fails, because it doesn't have the launch URL which has information needed to run the app. So far, this problem seems isolated to Snow Leopard, I have not seen it on Lion or Mountain Lion. Also, the problem is intermittent -- it works just fine most of the time, even on the same machine where the problem occasionally occurs. My questions: 1. Is there any guaranteed invocation order of these methods, or is it completely random? I cannot think of any scenario where you'd want to process the URL launching event *after* the callback which signifies app launch completion. That just seems wrong. 2. Assuming that the answer to 1 is that there IS an expected invocation order, then what could possibly cause this problem? This smells an awful lot like something to do with unexpected results of thread scheduling in the OS (not in the app, I'm creating no threads at all). If anyone has any thoughts or ideas, I'd greatly appreciate it. Even if any of you have a similar use-case of an app with a URL handler that has to grab that URL before doing anything in your app, sharing your experience might help. Thanks, Brad ___ 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: How to detect a Retina Mac
On Aug 20, 2013, at 12:36 PM, Gerriet M. Denkmann wrote: > Well that much I know. And I also know that many NS/UI-things (which use > Objective-C) often have a CF-counterpart, which uses plain C and often these > are toll-free bridged. The latter kind is typically used when one needs more > options or finer control. (E.g. NSDictionary / CFDictionary). > > But what is the story behind NS/UIView relative to CIImage, CGImage? When to > use what? What are the relevant advantages? One more note (I presume you're aware of that, but since you're not 100% clear about that in your phrasing above): CGImage and NSImage are not toll-free bridged. CGImageRef is more of an equivalent to NSBitmapImageRep than NSImage. 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: How to detect a Retina Mac
On Aug 20, 2013, at 12:36 PM, Gerriet M. Denkmann wrote: > On 19 Aug 2013, at 19:18, Alex Zavatone wrote: >> Sent from my iPad >> >> On Aug 18, 2013, at 11:16 AM, "Gerriet M. Denkmann" >> wrote: >> >>> But I do not understand it. CIImage, CGImage, NSImage >> >> I know it's not much, but CI = Core Image, CG = Core Graphics and NS = Next >> Step (Mac). UI Image would be for iOS, if I'm not mistaken. > > Well that much I know. And I also know that many NS/UI-things (which use > Objective-C) often have a CF-counterpart, which uses plain C and often these > are toll-free bridged. The latter kind is typically used when one needs more > options or finer control. (E.g. NSDictionary / CFDictionary). > > But what is the story behind NS/UIView relative to CIImage, CGImage? When to > use what? What are the relevant advantages? > > I would really like to get some link to some documentation, which explains > these questions. NSImage/UIImage: Highest-level image abstraction, usually independent of pixels (e.g. may hold vector graphics, values are measured in Points, not pixels) CGImage: Highest-level pixel-based representation of an image, mostly measured in actual pixels, you have to do all Retina-work yourself. CIImage: Abstraction on top of textures on a graphics card for use as images. Useful if you want to quickly apply effects (CIFilter, transitions etc.) to an image, because the image is kept in GPU memory instead of RAM, so for applying several filters you save repeated up/downloads, and the filters run on many cores on the GPU, instead of blocking the few CPU cores your phone has. Note that the abstraction is transparent. E.g. for bitmap images, NSImage these days uses a CGImageRef under the hood. Also, CGImageRefs try to be smart about keeping image data on the GPU if they can (so conceptually "use CIImage", if not actually). 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: Converting to Arc → undeclared identifier
Actually, I think the question is "what version of Xcode are you upgrading the project from and what version of Xcode are you using to do the conversion?" That way, it's much easier to pin down the specific case that might be causing this. - Alex Zavatone On Aug 20, 2013, at 10:57 AM, glenn andreas wrote: On Aug 20, 2013, at 8:43 AM, Gerriet M. Denkmann wrote: On 20 Aug 2013, at 20:27, Fritz Anderson wrote: Sure, but the whole point the OP is trying to make is that the purported error is being raised by the refactoring process that is _supposed to remove that retain_. Refactoring would be a very easy process indeed if doing the conversion yourself is a prerequisite of having Xcode do it. The use of the _ivar should work ― did work as far as the production compiler knew. Is the code the OP posted the whole context? Has he tried to convert that minimal example, and gotten the same error? Has he examined the preprocessed code (and then searched for the no-underscore name of the @property) to see if anything suggests itself? Created a new project (not document based) removed arc in build settings, modified the AppDelegate thus: What version of Xcode? I just tried this with Xcode 4.6.3 and it worked perfectly. ___ 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/zav%40mac.com This email sent to z...@mac.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: Converting to Arc → undeclared identifier
On 20 Aug 2013, at 21:54, glenn andreas wrote: > > On Aug 20, 2013, at 8:43 AM, Gerriet M. Denkmann wrote: > >> >> On 20 Aug 2013, at 20:27, Fritz Anderson wrote: >> >>> Sure, but the whole point the OP is trying to make is that the purported >>> error is being raised by the refactoring process that is _supposed to >>> remove that retain_. Refactoring would be a very easy process indeed if >>> doing the conversion yourself is a prerequisite of having Xcode do it. >>> >>> The use of the _ivar should work ― did work as far as the production >>> compiler knew. >>> >>> Is the code the OP posted the whole context? Has he tried to convert that >>> minimal example, and gotten the same error? Has he examined the >>> preprocessed code (and then searched for the no-underscore name of the >>> @property) to see if anything suggests itself? >> >> Created a new project (not document based) removed arc in build settings, >> modified the AppDelegate thus: > > What version of Xcode? I just tried this with Xcode 4.6.3 and it worked > perfectly. A difficult question: I am not allowed to talk about this (which might give you an idea, which version I was using). Kind regards, Gerriet. ___ 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: Converting to Arc → undeclared identifier
On Aug 20, 2013, at 8:43 AM, Gerriet M. Denkmann wrote: > > On 20 Aug 2013, at 20:27, Fritz Anderson wrote: > >> Sure, but the whole point the OP is trying to make is that the purported >> error is being raised by the refactoring process that is _supposed to remove >> that retain_. Refactoring would be a very easy process indeed if doing the >> conversion yourself is a prerequisite of having Xcode do it. >> >> The use of the _ivar should work ― did work as far as the production >> compiler knew. >> >> Is the code the OP posted the whole context? Has he tried to convert that >> minimal example, and gotten the same error? Has he examined the preprocessed >> code (and then searched for the no-underscore name of the @property) to see >> if anything suggests itself? > > Created a new project (not document based) removed arc in build settings, > modified the AppDelegate thus: What version of Xcode? I just tried this with Xcode 4.6.3 and it worked perfectly. ___ 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: Converting to Arc → undeclared identifier
On 20 Aug 2013, at 21:41, Jens Alfke wrote: > This looks like a bug in Xcode’s refactoring tool — seems it doesn’t > understand the auto-synthesize feature. I would take your test case and > attach it to a new Radar bug report to Apple. Just done this. Bug 14784266. Gerriet. ___ 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: Converting to Arc → undeclared identifier
This looks like a bug in Xcode’s refactoring tool — seems it doesn’t understand the auto-synthesize feature. I would take your test case and attach it to a new Radar bug report to Apple. The workaround should be to add an explicit instance variable declaration and an “@synthesize” directive where needed. —Jens ___ 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: Converting to Arc → undeclared identifier
On 20 Aug 2013, at 20:27, Fritz Anderson wrote: > Sure, but the whole point the OP is trying to make is that the purported > error is being raised by the refactoring process that is _supposed to remove > that retain_. Refactoring would be a very easy process indeed if doing the > conversion yourself is a prerequisite of having Xcode do it. > > The use of the _ivar should work ― did work as far as the production compiler > knew. > > Is the code the OP posted the whole context? Has he tried to convert that > minimal example, and gotten the same error? Has he examined the preprocessed > code (and then searched for the no-underscore name of the @property) to see > if anything suggests itself? Created a new project (not document based) removed arc in build settings, modified the AppDelegate thus: #import "T1AppDelegate.h" @interface T1AppDelegate () @property (strong) NSDate *myDate; @end @implementation T1AppDelegate - initWithDate: (NSDate*)aDate { self = [super init]; if ( self == nil ) return nil; _myDate = [ aDate retain]; return self; } - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { // Insert code here to initialize your application } @end Nothing edited (except some comments at the very top). Builds without errors. As expected. Tried Edit → Refactor → Convert to Objective-C ARC Got: "Xcode found 1 issue that prevents conversion from proceeding. Fix all ARC readiness issues and try again." The offending line is: _myDate = [ aDate retain]; Adorned with the remark "Use of undeclared identifier '_myDate'" Gerriet. ___ 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: Converting to Arc → undeclared identifier
Sure, but the whole point the OP is trying to make is that the purported error is being raised by the refactoring process that is _supposed to remove that retain_. Refactoring would be a very easy process indeed if doing the conversion yourself is a prerequisite of having Xcode do it. The use of the _ivar should work ― did work as far as the production compiler knew. Is the code the OP posted the whole context? Has he tried to convert that minimal example, and gotten the same error? Has he examined the preprocessed code (and then searched for the no-underscore name of the @property) to see if anything suggests itself? ― F On Aug 20, 2013, at 8:12 AM, Shane Stanley wrote: > On 20/08/2013, at 9:07 PM, "Gerriet M. Denkmann" wrote: > >> How to placate Xcode? > > Are you sure it's not the use of retain that it's complaining about? Without > that, your code compiles fine here. ___ 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: Converting to Arc → undeclared identifier
On 20/08/2013, at 9:07 PM, "Gerriet M. Denkmann" wrote: > How to placate Xcode? Are you sure it's not the use of retain that it's complaining about? Without that, your code compiles fine here. -- Shane Stanley 'AppleScriptObjC Explored' ___ 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: Converting to Arc → undeclared identifier
On 20 Aug 2013, at 19:24, Uli Kusterer wrote: > You're missing an @synthesize privateData = _privateData; in your > @implementation, would be my guess. There is no @synthesize, this is true. But Xcode normally does not mind, and I think this is (since when?) no longer necessary (maybe only in 64 bit?). > > On Aug 20, 2013, at 1:07 PM, Gerriet M. Denkmann wrote: >> Trying to convert an older project to Arc, Xcode complains about "Use of >> undeclared identifier '_privateDate'". >> And threatens that nothing will be done unless I fix this first. >> >> Well - for one: without Arc there are no undeclared identifiers. (Builds >> without error or warnings). >> >> The class with problems looks like: >> >> @interface SomeClass( ) >> >> @property (strong) NSDate *privateDate; >> >> @end >> >> >> @implementation SomeClass >> >> - (id)initAt:(NSDate *)someDate ; >> { >> self = [ super init ]; >> if ( self == nil ) return nil; >> >> _privateDate = [ someDate retain ]; >> >> return self ; >> } >> >> ... some other stuff omitted ... >> >> @end >> >> I always thought that using accessors (like self.privateDate) in init >> methods was NOT a good idea, because at this point the thing might not be >> completely initialised and functional, so one had better use _privateDate >> directly. >> And the accessor methods like setPrivateDate: might rely on a completely >> functional object. >> >> Is this correct? >> >> How to placate Xcode? >> >> Gerriet. ___ 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: Converting to Arc → undeclared identifier
You're missing an @synthesize privateData = _privateData; in your @implementation, would be my guess. On Aug 20, 2013, at 1:07 PM, Gerriet M. Denkmann wrote: > Trying to convert an older project to Arc, Xcode complains about "Use of > undeclared identifier '_privateDate'". > And threatens that nothing will be done unless I fix this first. > > Well - for one: without Arc there are no undeclared identifiers. (Builds > without error or warnings). > > The class with problems looks like: > > @interface SomeClass( ) > > @property (strong) NSDate *privateDate; > > @end > > > @implementation SomeClass > > - (id)initAt:(NSDate *)someDate ; > { > self = [ super init ]; > if ( self == nil ) return nil; > > _privateDate = [ someDate retain ]; > > return self ; > } > > ... some other stuff omitted ... > > @end > > I always thought that using accessors (like self.privateDate) in init methods > was NOT a good idea, because at this point the thing might not be completely > initialised and functional, so one had better use _privateDate directly. > And the accessor methods like setPrivateDate: might rely on a completely > functional object. > > Is this correct? > > How to placate Xcode? > > Gerriet. > > > ___ > > 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/witness.of.teachtext%40gmx.net > > This email sent to witness.of.teacht...@gmx.net 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
Converting to Arc → undeclared identifier
Trying to convert an older project to Arc, Xcode complains about "Use of undeclared identifier '_privateDate'". And threatens that nothing will be done unless I fix this first. Well - for one: without Arc there are no undeclared identifiers. (Builds without error or warnings). The class with problems looks like: @interface SomeClass( ) @property (strong) NSDate *privateDate; @end @implementation SomeClass - (id)initAt:(NSDate *)someDate ; { self = [ super init ]; if ( self == nil ) return nil; _privateDate = [ someDate retain ]; return self ; } ... some other stuff omitted ... @end I always thought that using accessors (like self.privateDate) in init methods was NOT a good idea, because at this point the thing might not be completely initialised and functional, so one had better use _privateDate directly. And the accessor methods like setPrivateDate: might rely on a completely functional object. Is this correct? How to placate Xcode? Gerriet. ___ 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: How to detect a Retina Mac
On 19 Aug 2013, at 19:18, Alex Zavatone wrote: > Sent from my iPad > > On Aug 18, 2013, at 11:16 AM, "Gerriet M. Denkmann" > wrote: > >> But I do not understand it. CIImage, CGImage, NSImage > > I know it's not much, but CI = Core Image, CG = Core Graphics and NS = Next > Step (Mac). UI Image would be for iOS, if I'm not mistaken. Well that much I know. And I also know that many NS/UI-things (which use Objective-C) often have a CF-counterpart, which uses plain C and often these are toll-free bridged. The latter kind is typically used when one needs more options or finer control. (E.g. NSDictionary / CFDictionary). But what is the story behind NS/UIView relative to CIImage, CGImage? When to use what? What are the relevant advantages? I would really like to get some link to some documentation, which explains these questions. Kind regards, Gerriet. ___ 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: CoreText & NSMutableParagraphStyle maximumLineHeight
On 20 Aug, 2013, at 4:23 PM, Graham Cox wrote: > On 20/08/2013, at 8:38 AM, Peter C wrote: > >> Yes, it is possible to pass values with NSParagraphStyleAttributeName for >> NSString drawInRect:withAttributes. However by default line spacing or gap >> between lines is different compare to CoreText functions (CTFramesetter and >> etc). The gap is taller for NSString, perhaps the calculation is based on >> round up values rather than fraction values of the font height. > > I'm not sure but I think because the purpose of the NSString convenience > method is for UI labelling, there is an additional border added to the > bounding rect needed. However, this shouldn't affect the spacing of multiple > lines if the text wraps. If you are trying to draw each line yourself then > you are not going to see the same line spacing and you're doing unnecessary > work. I do not intend to draw line by line. The app would auto flow line of text in a text box. It is a simple variable text length, one to few lines text for label printing (printer and display). >> I believe the user would be probably happy with CoreText compare to NSString >> by default values. Print people, they are sensitive to typography >> measurements. According to the user, it's a common feature for apps like MS >> Word (line spacing) or Adobe Indesign (font leading). Putting some controls >> for line spacing and kern width will make them happy. > > You can do all of that with NSString + attributes, or alternatively > NSAttributedString. You can also use Core Text, but it's generally harder to > use than NSAttributedString and in this case doesn't give you anything you > don't already have. Core Text is harder. I would prefer NSString but line spacing by default is bad for NSString. Check this URL out, especially the picture. http://stackoverflow.com/questions/10587606/core-text-a-bit-smaller-than-nsstring-drawinrect?lq=1 When bigger font size is use, the line spacing is worse for NSString. >> The question is how to get maximum value of maximumLineHeight of a >> particular font ? > > I think that question is meaningless because there's no inherent "maximum" > for a line height for any font or font size. There is a minimum, which is > easily calculated from the NSFont - the simplest is probably to use > -boundingRectForFont.size.height. > > But you are taking about line SPACING, not line height. This is additional > space inserted between each line of wrapped text. It is a property of the > paragraph style and is implemented by the NSLayoutManager. For your purposes, > the [NSParagraphStyle lineHeightMultiple] is probably what you want - you can > just set it to 1, 1.5, 2 etc and it will perform all the calculations for > you. This is the property that the line spacing control in NSTextView affects. > > > --Graham OK, I will investigate NSParagraphStyle lineHeightMultiple. NSParagraphStyle lineSpacing would have work if negative value is allow. -- Peter Chan ___ 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: CoreText & NSMutableParagraphStyle maximumLineHeight
On 20 Aug, 2013, at 4:09 PM, Kyle Sluder wrote: > The default line height of Helvetica is 14.0. That information is > encoded in the font. You can discover this for yourself by asking your > NSLayoutManager for its defaultLineHeightForFont:. This line height will > be used for text layout if the typesetter returns YES from > -usesFontLeading. > > And of course, since 14 is less than 15, your maximumLineHeight is not > reached and thus you won't see any effect for values greater than 14. > > --Kyle Sluder That's it ! NSLayoutManager defaultLineHeightForFont works, thanks. But only for NSFont. CTFontRef will the return same font size. I can live with that, get value from NSFont & NSLayoutManager before doing anything else. I tested it, when the Helvetica font size is 12.0, the default line height is 14.0 . If when the Helvetica font size is 18.0, the default line height of is 22.0. Default line height is define by the font size. -- Peter Chan ___ 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: CoreText & NSMutableParagraphStyle maximumLineHeight
On 20/08/2013, at 8:38 AM, Peter C wrote: > Yes, it is possible to pass values with NSParagraphStyleAttributeName for > NSString drawInRect:withAttributes. However by default line spacing or gap > between lines is different compare to CoreText functions (CTFramesetter and > etc). The gap is taller for NSString, perhaps the calculation is based on > round up values rather than fraction values of the font height. I'm not sure but I think because the purpose of the NSString convenience method is for UI labelling, there is an additional border added to the bounding rect needed. However, this shouldn't affect the spacing of multiple lines if the text wraps. If you are trying to draw each line yourself then you are not going to see the same line spacing and you're doing unnecessary work. > I believe the user would be probably happy with CoreText compare to NSString > by default values. Print people, they are sensitive to typography > measurements. According to the user, it's a common feature for apps like MS > Word (line spacing) or Adobe Indesign (font leading). Putting some controls > for line spacing and kern width will make them happy. You can do all of that with NSString + attributes, or alternatively NSAttributedString. You can also use Core Text, but it's generally harder to use than NSAttributedString and in this case doesn't give you anything you don't already have. > The question is how to get maximum value of maximumLineHeight of a particular > font ? I think that question is meaningless because there's no inherent "maximum" for a line height for any font or font size. There is a minimum, which is easily calculated from the NSFont - the simplest is probably to use -boundingRectForFont.size.height. But you are taking about line SPACING, not line height. This is additional space inserted between each line of wrapped text. It is a property of the paragraph style and is implemented by the NSLayoutManager. For your purposes, the [NSParagraphStyle lineHeightMultiple] is probably what you want - you can just set it to 1, 1.5, 2 etc and it will perform all the calculations for you. This is the property that the line spacing control in NSTextView affects. --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: CoreText & NSMutableParagraphStyle maximumLineHeight
On Mon, Aug 19, 2013, at 09:08 PM, Peter C wrote: > maximumLineHeight when set to 1.0, the lines is maximum compacted to > unreadable text. Gradual increase of the value, will see the lines > expanding. However I discover it to be strange behaviour of > maximumLineHeight (probably something I don't understand yet). > maximumLineHeight does not correspond to font size for some font types. > For some other fonts, maximumLineHeight is equivalent to font size. I try > calculating from from font ascent, descent and leading value, it just > does not add up. > > For example, for Helvetica font size of 12.0, maximumLineHeight is 15.0 > to equal as maximumLineHeight = 0. The default line height of Helvetica is 14.0. That information is encoded in the font. You can discover this for yourself by asking your NSLayoutManager for its defaultLineHeightForFont:. This line height will be used for text layout if the typesetter returns YES from -usesFontLeading. And of course, since 14 is less than 15, your maximumLineHeight is not reached and thus you won't see any effect for values greater than 14. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: IB autolayout is impossible
Right, I agree, radarweb’s behaviour is pretty abominable, you can’t see anything at all going on. But that doesn’t change the fact, making radars is the only way these things get fixed. I’m glad to hear you’ve reported many already. Please make more if you can think of unique things that IB is doing very wrong here :D Tom Davie On 20 Aug 2013, at 09:55, Rick Mann wrote: > I have filed literally hundreds of bug reports. I get the spirit of what > you're saying, but I'm so stressed from this project (and IB's hand in it), > and so demoralized from having my bugs come back as either Duplicate, or > Behaves Correctly, or just stay Open forever, and finally, having to wait for > the next major release to see them fixed (rather than fixed in a dot > release), that it's getting nearly impossible to summon the will to write > more bugs. > > > On Aug 20, 2013, at 00:51 , Tom Davie wrote: > >> In general, please file a bug report at bugreport.apple.com. For what it’s >> worth, I agree, and I don’t think IB should be doing anything at all to try >> and guess what constraints we want, or even to keep them consistent. The >> spirit of the dev tools is to allow you to do whatever you want (even if >> it’s wrong), and to tell you when it’s wrong. The unsatisfiable constraints >> should simply come up as errors/warnings when the xib is compiled. This >> would lead to a whole lot less frustration when it comes to IB deciding to >> change everything you already set up simply because you added one extra view. >> >> Tom Davie >> >> On 20 Aug 2013, at 01:48, dangerwillrobinsondan...@gmail.com wrote: >> >>> In general in 4.x add your constraints that will make a satisfiable layout, >>> then remove the ones you don't want. >>> The next one does less trying without asking but this one is not that bad >>> if people follow the flow: add yours, remove theirs. >>> >>> Sent from my iPhone >>> >>> On 2013/08/20, at 7:40, Rick Mann wrote: >>> I want to create a view with size 74 x 74, containing three subviews, all centered on it. But IB is just a game of whack-a-mole. So angry. -- 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/tom.davie%40gmail.com >>> >>> This email sent to tom.da...@gmail.com >> > > > -- > 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: IB autolayout is impossible
I have filed literally hundreds of bug reports. I get the spirit of what you're saying, but I'm so stressed from this project (and IB's hand in it), and so demoralized from having my bugs come back as either Duplicate, or Behaves Correctly, or just stay Open forever, and finally, having to wait for the next major release to see them fixed (rather than fixed in a dot release), that it's getting nearly impossible to summon the will to write more bugs. On Aug 20, 2013, at 00:51 , Tom Davie wrote: > In general, please file a bug report at bugreport.apple.com. For what it’s > worth, I agree, and I don’t think IB should be doing anything at all to try > and guess what constraints we want, or even to keep them consistent. The > spirit of the dev tools is to allow you to do whatever you want (even if it’s > wrong), and to tell you when it’s wrong. The unsatisfiable constraints > should simply come up as errors/warnings when the xib is compiled. This > would lead to a whole lot less frustration when it comes to IB deciding to > change everything you already set up simply because you added one extra view. > > Tom Davie > > On 20 Aug 2013, at 01:48, dangerwillrobinsondan...@gmail.com wrote: > >> In general in 4.x add your constraints that will make a satisfiable layout, >> then remove the ones you don't want. >> The next one does less trying without asking but this one is not that bad if >> people follow the flow: add yours, remove theirs. >> >> Sent from my iPhone >> >> On 2013/08/20, at 7:40, Rick Mann wrote: >> >>> I want to create a view with size 74 x 74, containing three subviews, all >>> centered on it. But IB is just a game of whack-a-mole. So angry. >>> >>> -- >>> 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/tom.davie%40gmail.com >> >> This email sent to tom.da...@gmail.com > -- 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: IB autolayout is impossible
In general, please file a bug report at bugreport.apple.com. For what it’s worth, I agree, and I don’t think IB should be doing anything at all to try and guess what constraints we want, or even to keep them consistent. The spirit of the dev tools is to allow you to do whatever you want (even if it’s wrong), and to tell you when it’s wrong. The unsatisfiable constraints should simply come up as errors/warnings when the xib is compiled. This would lead to a whole lot less frustration when it comes to IB deciding to change everything you already set up simply because you added one extra view. Tom Davie On 20 Aug 2013, at 01:48, dangerwillrobinsondan...@gmail.com wrote: > In general in 4.x add your constraints that will make a satisfiable layout, > then remove the ones you don't want. > The next one does less trying without asking but this one is not that bad if > people follow the flow: add yours, remove theirs. > > Sent from my iPhone > > On 2013/08/20, at 7:40, Rick Mann wrote: > >> I want to create a view with size 74 x 74, containing three subviews, all >> centered on it. But IB is just a game of whack-a-mole. So angry. >> >> -- >> 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/tom.davie%40gmail.com > > This email sent to tom.da...@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