Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog
 
 Archive
 
 Blog Topics
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

More...

Taking advantage of validateUserInterfaceItem

Most of you will already know how convenient it is to use -validateMenuItem: and -validateToolbarItem: in your controller to make sure the toolbar/menu items are accurately enabled. These methods also let you perform some more accurate validation than simply "first responder provides that function"; for example, you can check whether there is anything selected and disable the "clear" menu item for your custom view. One of the annoyances of this approach is that usually toolbar items duplicate items that already exist in the menus, forcing you to write a dummy-validateToolbarItem that just calls through to validateMenuItem. But there's an easier way than that:

If you do not provide -validateMenuItem: or -validateToolbarItem:, AppKit will instead call -validateUserInterfaceItem: for both of them. So, if you have menu items that are also available on the toolbar, this method lets you use the same method to validate them both.

But this often-overlooked method isn't reason enough for a blog entry. What is, is that you can also use this method to validate buttons in your window. Well, not out of the box, but with help from a small method. Most apps have an -updateUI method in some controller that uses dozens of outlets to set up all buttons in your window according to the current state of the model. Let's replace that method with another one and get rid of all those outlets:

-(void)    updateUI
{
    NSWindow*       win = [self window];
    NSView*         cView = [win contentView];
    NSEnumerator*   enny = [[cView subviews] objectEnumerator];
    NSView*         sView = nil;
    
    while( (sView = [enny nextObject]) )
    {
        if( [sView isKindOfClass: [NSButton class]] )
        {
            [(NSButton*)sView setEnabled: [self validateUserInterfaceItem: sView]];
        }
    }
}
This loops over the buttons in your window (top level only -- deep search is left as an exercise to the reader) and calls -validateUserInterfaceItem: on each of them, and uses the result to enable/disable them. Every time you do something that may need a change in the UI, call [self updateUI] and all your buttons will refresh correctly.

Instant User Interface Feedback!

While this may be too generic and perform badly for very complex GUIs, it's very handy for creating the initial version of a GUI and for smaller apps. Moreover, you can easily move items between buttons, toolbars and menus without the need to change your code. We're one step closer to the Model-View-Controller ideal. And that without relying on any 10.3- or 10.4-specific features.
 
Created: 2005-06-09 @574 Last change: 2005-06-09 @589 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.