• 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: User Interface linked to two classes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: User Interface linked to two classes


  • Subject: Re: User Interface linked to two classes
  • From: Geoffrey Holden <email@hidden>
  • Date: Fri, 09 Dec 2011 20:25:43 +0000

Thanks for this, Graham.  I'll give this a go.  To clarify though, I've got two classes - one which handles the view for a game, and the other which handles the scoring (amongst other things, this involves displaying a timer which shows how long game play has lasted).

The game class updates its UI elements correctly.  The scoring class (which uses the following code.  timeElapsedField is only linked to the scoring class:

.h

IBOutlet NSTextField* timeElapsedField;


.m

- (void)initializeCounters
{
	startDate = [[NSCalendarDate alloc] init];
	[timeElapsedField setStringValue:@"0:0:0"];
	timer = [[NSTimer scheduledTimerWithTimeInterval:1.0
                                             target:self
                                           selector:@selector(updateClock:)
                                           userInfo:nil repeats:YES] retain];
}

- (void)updateClock:(NSTimer *)timer
{
	NSCalendarDate *now = [NSCalendarDate calendarDate];
	int hours, minutes, seconds;

	[now years:NULL months:NULL days:NULL hours:&hours
     minutes:&minutes seconds:&seconds sinceDate:startDate];

	[timeElapsedField setStringValue:[NSString stringWithFormat:@"%d:%d:%d",
                                     hours,minutes,seconds]];
}

If I understand you correctly, I need to have a controller class which handles updating the screen.  That's fine for the simple timer, but could be rather tricky for the game view!  I'm sure I didn't do it this way in the past - although, as you say, my technique might be (probably is, actually) very wrong.

In debug, I can see that the updateClock code is getting executed.

On 6 Dec 2011, at 22:06, Graham Cox wrote:

>
> On 07/12/2011, at 7:35 AM, Geoffrey Holden wrote:
>
>> My apologies for subjecting you all to such a dim question - but I'm coming back to cocoa programming after a bit of a lay off and I can't remember what to do!
>>
>> I have a nib (xib - sorry) with my interface nicely laid out but I want it to be updated by two classes.  The class which is hooked up to first responder is able to update its UI elements with no problem, but the other class doesn't update its UI element at all.  I can see in debug that the right functions are executing - but the UI isn't getting updated.
>>
>> As far as I can see I've hooked everything up correctly.
>>
>> Please someone, nudge my memory.  What have I forgotten?
>
>
> Hard to say, but it sounds as if you've attempted to connect the same control to more than one outlet, which is impossible.
>
> The usual design is that there will exist a controller which handles a set of related UI elements. For example, if the elements are all part of a dialog panel, then the window controller for that panel will have outlets to each control, and an action method to respond to each control. It is the controller that then a) invokes model changes according to what controls the user interacted with and b) provides an interface to the rest of the app that changes the controls in response to data model changes.
>
> Bindings can automate this to a degree, but for a beginner is a pretty big chunk of behaviour to get one's head around, so probably best to stick with the relatively simple target/action approach at first.
>
> So rather than try to link your controls directly to objects that implement the data model, use a controller as an intermediary and have everything go through that. A typical way for a controller to update its controls when the model state changes is for it to receive notifications from the model, either classic NSNotificationCenter ones, or through the use of KVO, which is what bindings uses. Then, when a change is made to the model, no matter where it comes from, the UI reflects the change. If you find yourself writing code in your model that is setting control states to reflect its internal state, you've done it very, very wrong.
>
> hth,
>
> Graham

_______________________________________________

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: User Interface linked to two classes
      • From: Conrad Shultz <email@hidden>
References: 
 >User Interface linked to two classes (From: Geoffrey Holden <email@hidden>)
 >Re: User Interface linked to two classes (From: Graham Cox <email@hidden>)

  • Prev by Date: Best way to manage double-clicked files?
  • Next by Date: Re: User Interface linked to two classes
  • Previous by thread: Re: User Interface linked to two classes
  • Next by thread: Re: User Interface linked to two classes
  • Index(es):
    • Date
    • Thread