Re: Finding windows made in Interface Builder?
Re: Finding windows made in Interface Builder?
- Subject: Re: Finding windows made in Interface Builder?
- From: Uli Kusterer <email@hidden>
- Date: Wed, 11 Jul 2007 18:44:41 +0200
On 11.07.2007, at 18:21, Kai-Mikael Jää-Aro wrote:
I'm laying out a circuit design and the user can double-click on
each unit to get up an info window specific for that type of unit.
So, the window depends on the clicked-on unit and ideally I'd like
to bind the window identity to the unit, but the units are of
course created dynamically by the user. I'd rather not tie
knowledge of the info window to the layout view, but AIUI, I have
to connect an instance of some class to the window. Should I use a
prototype object that I then copy for each new unit, rather than
instancing new ones directly from the class? In that case I could
have an outlet
In general, you'll want a class that wraps one window. You could
have this class load a different NIB file each time by simply passing
in the NIB name. So, if you had a capacitor, a reed contact and a
lightbulb, you'd do:
[[KMJADescriptionWindowController alloc] initWithNibName:
[currentObject name]];
(where [currentObject name] would return "Capacitor", "Reed Contact"
or "Lightbulb", depending on the current object and then you'd just
have -initWithNibName: pass that string to loadNibNamed. You could
then build an array of KMJA DescriptionWindowController objects in an
array if you have to show several of those at the same time.
Alternatively, you could just have one such object that gets created
and torn down again, replaced by a new one.
The advantage of having a dedicated controller, besides allowing to
reuse the same class for all 50 windows, and thus only needing one
outlet, is manifold. For one, you can treat all of these windows the
same. On the other hand, if you need to have custom behaviour in one
of your windows, you can build a string from "KMJA" + [currentObject
name] + "WindowController" and use NSClassFromString() to see whether
a class of that name exists. If it does, you instantiate that,
otherwise you instantiate a generic KMJADescriptionWindowController.
That way, you just add a new class and a new NIB, and the rest of
your app picks it up automatically, without additional code changes,
and the rest of your app doesn't even have to know that this
controller subclass got instantiated and is actually downloading its
description from the web, or it contains a WebView that loads a
different description HTML page for each object and sizes itself to
fit, or whatever.
As the saying goes: In Cocoa, if you find yourself doing a lot of
work, chances are you're doing it wrong.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
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