• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Triggering a segue from code
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Triggering a segue from code


  • Subject: Re: Triggering a segue from code
  • From: "email@hidden" <email@hidden>
  • Date: Sun, 25 Sep 2016 20:11:44 -0400

Based on stuff I have been playing with, #2 seems like the “right” solution based on the design of the framework. A segue is currently not designed to support this behavior and it is always a mistake, I have learned, to try to fight the framework (which eliminates #1 & #4).


> On Sep 25, 2016, at 3:52 PM, Quincey Morris <email@hidden> wrote:
>
> On Sep 25, 2016, at 11:59 , email@hidden <mailto:email@hidden> wrote:
>>
>> 2. The reason why I do a performClose is because I want it to do the same thing as when the user presses the close button on the panel, which they are allowed to do. Unless I were to remove the close button from the inspector panel (which I do not want to do), my overall problem remains.
>
>
> There are a couple of different approaches you can take:
>
> 1. You know now that if you performClose or close the panel, a storyboard segue is going to create a new instance. You can deal with that by keeping enough panel state outside the panel view controller to re-configure a new panel if it’s created. That is, you don’t need the existence of the panel to be continuous. All you need is one panel at a time.
>
> 2. Don’t use segues for this. Move the panel to its own storyboard or XIB file. (Instantiate the storyboard in code, or load the NIB via the view controller initWithNibName initializer.)
>
> 3. Don’t do the performClose behavior. The point of the button-highlighting behavior is to indicate the window being affected when the user does something non-specific like choosing File -> Close or typing Command-W. Neither of those (presumably) will affect your inspector panel — otherwise it’d be too confusing for the user, whether a document window or the inspector was going to be closed.
>
> If the user has to click a button (e.g. toolbar or regular window button) to hide the inspector, the animated interaction *is* that button’s down/up transition, so there’s no need for it in the panel’s title bar.
>
> 4. You could, I suppose, subclass NSPanel and override the “close” method. The documentation says that “performClose” invokes “close”. You should be able to have the “close” override  do an “orderOut:” instead.
>

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden


References: 
 >Triggering a segue from code (From: "email@hidden" <email@hidden>)
 >Re: Triggering a segue from code (From: Quincey Morris <email@hidden>)
 >Re: Triggering a segue from code (From: "email@hidden" <email@hidden>)
 >Re: Triggering a segue from code (From: Quincey Morris <email@hidden>)
 >Re: Triggering a segue from code (From: "email@hidden" <email@hidden>)
 >Re: Triggering a segue from code (From: Quincey Morris <email@hidden>)

  • Prev by Date: Detecting user termination of an iOS auto-renewing subscription
  • Next by Date: SecStaticCodeCheckValidity fails when app is lauched from Terminal
  • Previous by thread: Re: Triggering a segue from code
  • Next by thread: Package installation on MacOS Sierra
  • Index(es):
    • Date
    • Thread