• 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: best time to alter GUIs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: best time to alter GUIs


  • Subject: Re: best time to alter GUIs
  • From: Daniel Child <email@hidden>
  • Date: Mon, 03 Mar 2008 12:12:29 -0500


On Mar 1, 2008, at 6:15 AM, Ken Thomases wrote:

Does your init method do anything else other than calling [super initWithWindowNibName:]? In particular, if it calls [self window], that forces the loading (and awakening) of the NIB in order to reconstitute the window.
My bad. I should have checked that, and assumed it simply passed the address. If [self window] loads things, is there any way to obtain the window's address without loading it? I found it useful to assign a (superfluous) instance variable since I was doing so much with the window. I didn't want to have to use [self window] each time, especially if [self window] actually tries to load each time.

Perhaps the proper thing to do is pass the extra data into the init method of your custom controller class.
I've opted for a different approach: simply redraw the window after passing the data that determines window parameters. Maybe not the most elegant solution, however.... I'm still wondering how you can access the window's address without loading it.

On a related note, where's the model in the MVC design? Are the values with which you're configuring the controller (and subsequently the window) things which should be coming from the model? Maybe the controller needs to be initialized with a relationship to a model, and then it will get what it needs from that model.
Oh, I didn't mention it. The master controller determines which window controller (and process step) to load, but each individual controller is in fact associated with model stuff that I didn't even mention. The "local data" is simply critical data that needs to be passed from one part of the model to another. Doing this lets me keep each step self-contained, and avoids a bunch of code nesting.

Another thing to consider: the above code looks as though it's designed to be run through multiple times. Note, though, that the controller will only load the window once during its lifetime. So, what do you hope [fieldIDController setLocalDataCopy: [self dataValues]]; will accomplish on subsequent passes through that code?
If I make a mistake entering values at a certain step, I can redo that step by hitting the appropriate button in the master controller. At that point, the step's windowController will already exist.

Thanks for the comments.... For what it's worth, I've got the thing to run properly. Defining the segments within frames, and adding them (as a subview) to the window view was the critical missing step.
_______________________________________________


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


  • Follow-Ups:
    • Re: best time to alter GUIs
      • From: Ken Thomases <email@hidden>
    • Re: best time to alter GUIs
      • From: Quincey Morris <email@hidden>
References: 
 >Re: best time to alter GUIs (From: Ken Thomases <email@hidden>)

  • Prev by Date: Re: Using NSPredicate to parse strings
  • Next by Date: Re: Typing attributes and the location of the insertion point
  • Previous by thread: Re: best time to alter GUIs
  • Next by thread: Re: best time to alter GUIs
  • Index(es):
    • Date
    • Thread