>> I see that NSTabViewItem has a strong viewController property. Are you >> using that, or does your NSTabViewItem >> subclass add its own separate reference to the view controller? >> --Andy
Ah, we are using our own reference. That may be the problem. We set the view in the NSTabViewItem but not the view controller property. Unfortunately when I add [self setViewController : ourController]; it just exits there. Looking inside the NSTabViewItem struct, _viewController is inside a _NSTabViewItemAuxiliary (!). The whole thing smells like it was cobbed together ad hoc, maybe to fix this very problem. The official way to set the property is on init via tabViewItemWithViewController. Unfortunately, we allocate the view controller from inside the NSTabViewItem so that will require a serious rewrite. I think we will try NSTabViewController first. Thanks, Casey McDermott Turtle Creek Software -------------------------------------------- On Thu, 4/4/19, <cocoa-dev-requ...@lists.apple.com> wrote: Subject: Cocoa-dev Digest, Vol 16, Issue 27 To: cocoa-dev@lists.apple.com Date: Thursday, April 4, 2019, 3:00 PM Send Cocoa-dev mailing list submissions to cocoa-dev@lists.apple.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.apple.com/mailman/listinfo/cocoa-dev or, via email, send a message with subject or body 'help' to cocoa-dev-requ...@lists.apple.com You can reach the person managing the list at cocoa-dev-ow...@lists.apple.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Cocoa-dev digest..." Today's Topics: 1. Re: Category errata in Objective-C (David Hoerl) 2. NSTabViewItem and NSViewController (Casey McDermott) 3. Re: NSTabViewItem and NSViewController (Keary Suska) 4. Re: NSTabViewItem and NSViewController (Andy Lee) 5. Re: NSTabViewItem and NSViewController (Casey McDermott) 6. Re: NSTabViewItem and NSViewController (Keary Suska) ---------------------------------------------------------------------- Message: 1 Date: Wed, 03 Apr 2019 15:33:13 -0700 From: David Hoerl <dho...@mac.com> To: cocoa-dev@lists.apple.com Subject: Re: Category errata in Objective-C Message-ID: <73da1779-4b31-d1ee-b46d-e3338f902...@mac.com> Content-Type: text/plain; CHARSET=US-ASCII; format=flowed I've had to do some funky things with categories in the past, in at least one case because some framework had added one but for complex reasons could not import. So, similar to what Jens said: The interface description of the category is for the sole purpose of helping the compiler generate a selector. This has the following implications: - you can put the interface description anywhere. You can put it at the top of one or more using implementation files, as well as the file that actually has the implementation for the category. Note: you do NOT need a implementation anywhere. If you ever had a project that failed to include the category implementation file, you know it will build and run, then crash when some code tries to use that category. [Ask me how I know this :-) ] - suppose you find a category in some framework used by your app, and want to use it. Or, you may want to know about it so you don't declare a similar method in your App, then have either the framework or your code crash because only one of those categories actually is installed. BIG REQUEST: if you write frameworks or libraries, don't use categories on anything but your own classes!!! Or, if you must, then namespace them with some whacky prefix so an app that defines a similar code doesn't crash! (Ask me how I know this :-) ) ------------------------------ Message: 2 Date: Thu, 04 Apr 2019 13:43:30 +0000 (UTC) From: Casey McDermott <supp...@turtlesoft.com> To: cocoa-dev@lists.apple.com Subject: NSTabViewItem and NSViewController Message-ID: <1618554483.16793428.1554385410...@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 We have a tab view with tabs added from code. Each tab uses a NSTabViewItem subclass, which contains a reference to a NSViewController subclass within it to manage tab contents. Users click to add and remove tabs. It works fine without ARC, with the NSTabView controlling the viewer lifetime. With ARC, it works fine with one tab. However the view controller is released and deallocated when a second tab is added, so switching tabs causes a crash from the invalid reference. Is there some way to see what is releasing the view controller? It's nothing in our code. NSTabView seems the likeliest culprit? NSTabViewItem is not a NSView subclass. Does that prevent it from managing lifetime for a view and view controller? Thanks, Casey McDermott Turtle Creek Software ------------------------------ Message: 3 Date: Thu, 04 Apr 2019 08:01:52 -0600 From: Keary Suska <cocoa-...@esoteritech.com> To: Casey McDermott <supp...@turtlesoft.com> Cc: "Cocoa-Dev (Apple)" <cocoa-dev@lists.apple.com> Subject: Re: NSTabViewItem and NSViewController Message-ID: <2b944d28-3587-46f4-9900-0adc82a2f...@esoteritech.com> Content-Type: text/plain; charset=utf-8 Who owns the view controller? Apparently, no-one, sine ARC is deallocating it once the last reference to it (the tab view item) is deallocated. If there is supposed to be an owner, make sure the owner’s reference is strong. If you can target 10.10+, using NSTabViewController is probably a better choice. Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" > On Apr 4, 2019, at 7:43 AM, Casey McDermott <supp...@turtlesoft.com> wrote: > > We have a tab view with tabs added from code. Each tab uses a NSTabViewItem subclass, > which contains a reference to a NSViewController subclass within it to manage tab contents. > Users click to add and remove tabs. > > It works fine without ARC, with the NSTabView controlling the viewer lifetime. > With ARC, it works fine with one tab. However the view controller is released and deallocated > when a second tab is added, so switching tabs causes a crash from the invalid reference. > > Is there some way to see what is releasing the view controller? It's nothing in our code. > NSTabView seems the likeliest culprit? > > NSTabViewItem is not a NSView subclass. Does that prevent it from managing lifetime for a view and view controller? > > Thanks, > > Casey McDermott > Turtle Creek Software > _______________________________________________ > > 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/cocoa-dev%40esoteritech.com > > This email sent to cocoa-...@esoteritech.com ------------------------------ Message: 4 Date: Thu, 04 Apr 2019 10:09:39 -0400 From: Andy Lee <ag...@mac.com> To: "cocoa-dev@lists.apple.com List" <cocoa-dev@lists.apple.com> Subject: Re: NSTabViewItem and NSViewController Message-ID: <24c1ffd4-8bd5-4a73-9c97-6cd7d3686...@mac.com> Content-Type: text/plain; CHARSET=US-ASCII On Apr 4, 2019, at 9:43 AM, Casey McDermott <supp...@turtlesoft.com> wrote: > > We have a tab view with tabs added from code. Each tab uses a NSTabViewItem subclass, > which contains a reference to a NSViewController subclass within it to manage tab contents. > Users click to add and remove tabs. I see that NSTabViewItem has a strong viewController property. Are you using that, or does your NSTabViewItem subclass add its own separate reference to the view controller? --Andy ------------------------------ Message: 5 Date: Thu, 04 Apr 2019 15:29:02 +0000 (UTC) From: Casey McDermott <supp...@turtlesoft.com> To: Keary Suska <cocoa-...@esoteritech.com> Cc: "Cocoa-Dev (Apple)" <cocoa-dev@lists.apple.com> Subject: Re: NSTabViewItem and NSViewController Message-ID: <940887224.1050279.1554391742...@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 The tab view item has a strong reference to the view controller, but the controller is released even though the tab view item still exists. So, selecting the tab hits the controller ref and it crashes with EXC_BAD_ACCESS. My guess is it's released when the NSTabView switches views, but a breakpoint at dealloc doesn't help much. However, we were not using a NSTabViewController. We'll try that now. Thanks, Casey McDermott Turtle Creek Software -------------------------------------------- On Thu, 4/4/19, Keary Suska <cocoa-...@esoteritech.com> wrote: Subject: Re: NSTabViewItem and NSViewController To: "Casey McDermott" <supp...@turtlesoft.com> Cc: "Cocoa-Dev (Apple)" <cocoa-dev@lists.apple.com> Date: Thursday, April 4, 2019, 10:01 AM Who owns the view controller? Apparently, no-one, sine ARC is deallocating it once the last reference to it (the tab view item) is deallocated. If there is supposed to be an owner, make sure the owner’s reference is strong. If you can target 10.10+, using NSTabViewController is probably a better choice. Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" > On Apr 4, 2019, at 7:43 AM, Casey McDermott <supp...@turtlesoft.com> wrote: > > We have a tab view with tabs added from code. Each tab uses a NSTabViewItem subclass, > which contains a reference to a NSViewController subclass within it to manage tab contents. > Users click to add and remove tabs. > > It works fine without ARC, with the NSTabView controlling the viewer lifetime. > With ARC, it works fine with one tab. However the view controller is released and deallocated > when a second tab is added, so switching tabs causes a crash from the invalid reference. > > Is there some way to see what is releasing the view controller? It's nothing in our code. > NSTabView seems the likeliest culprit? > > NSTabViewItem is not a NSView subclass. Does that prevent it from managing lifetime for a view and view controller? > > Thanks, > > Casey McDermott > Turtle Creek Software > _______________________________________________ > > 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/cocoa-dev%40esoteritech.com > > This email sent to cocoa-...@esoteritech.com ------------------------------ Message: 6 Date: Thu, 04 Apr 2019 09:42:06 -0600 From: Keary Suska <cocoa-...@esoteritech.com> To: Casey McDermott <supp...@turtlesoft.com> Cc: "Cocoa-Dev (Apple)" <cocoa-dev@lists.apple.com> Subject: Re: NSTabViewItem and NSViewController Message-ID: <828b41bc-f8e3-4582-8776-831dc0c4b...@esoteritech.com> Content-Type: text/plain; charset=utf-8 Re-reading my response, I hope it didn’t come across as snarky. If so, I apologize, as that wasn’t my intention. Anyway, I believe that it is expected behavior that a tab view item is released when it is removed, and in non-ARC environments that tends to mean a lot of autoreleasing, and xib-loading semantics also muddy the water, so some memory issues can be hidden and only crop up in certain circumstances. One of the reasons for going ARC, I imagine. This could explain the difference, as well as possibly some sort of timing issue with how ARC disposes of objects, since the tab view item should be gone as well. Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" > On Apr 4, 2019, at 9:29 AM, Casey McDermott <supp...@turtlesoft.com> wrote: > > The tab view item has a strong reference to the view controller, but the controller is released > even though the tab view item still exists. So, selecting the tab hits the controller ref and it > crashes with EXC_BAD_ACCESS. My guess is it's released when the NSTabView > switches views, but a breakpoint at dealloc doesn't help much. > > However, we were not using a NSTabViewController. We'll try that now. > > Thanks, > > Casey McDermott > Turtle Creek Software > > -------------------------------------------- > On Thu, 4/4/19, Keary Suska <cocoa-...@esoteritech.com> wrote: > > Subject: Re: NSTabViewItem and NSViewController > To: "Casey McDermott" <supp...@turtlesoft.com> > Cc: "Cocoa-Dev (Apple)" <cocoa-dev@lists.apple.com> > Date: Thursday, April 4, 2019, 10:01 AM > > Who owns the view controller? > Apparently, no-one, sine ARC is deallocating it once the > last reference to it (the tab view item) is deallocated. If > there is supposed to be an owner, make sure the owner’s > reference is strong. If you can target 10.10+, using > NSTabViewController is probably a better choice. > > Keary Suska > Esoteritech, Inc. > "Demystifying technology for your home or > business" > >> On Apr 4, 2019, at > 7:43 AM, Casey McDermott <supp...@turtlesoft.com> > wrote: >> >> We have a > tab view with tabs added from code. Each tab uses a > NSTabViewItem subclass, >> which contains > a reference to a NSViewController subclass within it to > manage tab contents. >> Users click to > add and remove tabs. >> >> It works fine without ARC, with the > NSTabView controlling the viewer lifetime. >> With ARC, it works fine with one tab. > However the view controller is released and deallocated >> when a second tab is added, so switching > tabs causes a crash from the invalid reference. >> >> Is there some way to > see what is releasing the view controller? It's > nothing in our code. >> NSTabView seems > the likeliest culprit? >> >> NSTabViewItem is not a NSView subclass. > Does that prevent it from managing lifetime for a view and > view controller? >> >> > Thanks, >> >> Casey > McDermott >> Turtle Creek Software > >> > _______________________________________________ >> >> 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/cocoa-dev%40esoteritech.com >> >> This email sent to > cocoa-...@esoteritech.com > ------------------------------ Subject: Digest Footer _______________________________________________ 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 16, Issue 27 ***************************************** _______________________________________________ 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
