Re: Legacy nibs containing views served by new IB plug-in not recognized
Re: Legacy nibs containing views served by new IB plug-in not recognized
- Subject: Re: Legacy nibs containing views served by new IB plug-in not recognized
- From: Jonathan Hess <email@hidden>
- Date: Wed, 29 Oct 2008 12:29:29 -0700
On Oct 29, 2008, at 6:43 AM, Martin-Gilles Lavoie wrote:
Now that I have a functioning Interface Builder (3) plug-in for one
of our custom views,
Congratulations.
I found out the IB doesn't let me edit those legacy NIB objects with
my new inspector because of the way it encodes the object's XML
representation in the nib bundle.
Custom views given our view type, "OhViewStacker", got saved using
containers such as:
<object class="NSCustomView" id="695194798">
...
<string key="NSClassName">OhViewStacker</string>
</object>
whereas new NIB content created using our plugin end up having a
container such as:
<object class="OhViewStacker" id="210503889">
...
</object>
It sounds like you have a bunch of NIB files with instances of
NSCustomView, with their custom class set to OhViewStacker. When you
set the custom class in Interface Builder, that's just metadata that
is used at runtime to indicate which class should be instantiated when
the NIB is loaded into your running program. In Interface Builder, a
custom view is just an NSView instance that you can set the custom
class on, like you can set the custom class on any other object.
If you were to drag a custom view from the library and change it's
custom class to NSButton the custom view wouldn't change into an
NSButton in Interface Builder, it would remain as a custom view with
the custom class set to NSButton. At runtime, an NSButton would be
instantiated instead of an the NSView. This is the same thing you're
seeing with OhViewStacker.
You could edit the XIB file, but that's risky, and would be
unsupported. It's probably best to file an enhancement request at http://bugreport.apple.com.
Then, as you encounter NIBs with NSCustomView's with the custom
class set to OhViewStacker, you can replace them one at a time as you
encounter them, and want to use the custom inspector that you've built.
Since you're using XIB files, I should point out one more thing. If
you're project defines an Interface Builder Plug-in target, framework
target, and app target, and the plug-in target depends on the
framework target, and the framework target uses XIB file's, and the
XIB file's use OhViewStacker's integrated by the IB Plug-in, then you
can get yourself into a circular dependency where you can't build the
framework because the plug-in used to process the XIB files durring
XIB compilation isn't available. There are multiple ways around this.
The simplest is to use NIB 3.x file instead of XIB files in the plug-
in, and framework. Alternatively, you can always keep a previous
binary of your plug-in and framework installed, or you can have your
framework classes live in both your plug-in target, and your framework
target so that your plug-in doesn't need to link your framework.
Good Luck -
Jon Hess
So, other than editing the NIB XML data by hand (wich seems to
work ...), is there a way for IB to actually clean itself up and
correct the NIB files?
It's because we have a *whole lot* of those and I'm facing a long
editing period...
Martin-Gilles Lavoie | Senior software developer | 514.905.8658
Oracle - Macintosh Native Desktop Client, Beehive
600, boul. de Maisonneuve West, Suite 1900 | Montréal (Québec) H3A
3J2
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden