Re: IB bug? - copyWithZone: selector not recognized
Re: IB bug? - copyWithZone: selector not recognized
- Subject: Re: IB bug? - copyWithZone: selector not recognized
- From: Bill Cheeseman <email@hidden>
- Date: Tue, 27 Aug 2002 18:47:17 -0400
I appreciate your response, but I'm having a little difficulty interpreting
it.
on 02-08-27 5:45 PM, James DiPalma at email@hidden wrote:
>
First, please note that archiving errors are typically bugs in archiving
>
code. InterfaceBuilder is not responsible for unarchiving windows at run
>
time when your application opens a new document, nor is InterfaceBuilder
>
responsible for archiving that window when you save your document's nib
>
file from IB.
>
>
Some specific problems with archiving can be IB bugs, but my experience
>
suggests that 95% of these bugs are not IB bugs. I may be a little over
>
sensitive about this issue, but its really just a suggestion and a hint
>
about what is happening.
My nib file was created in Interface Builder, so it seems to me that
Interface Builder was responsible for archiving all the items I created in
Interface Builder.
As for unarchiving the nib file, I use standard, out-of-the-documentation
techniques that have worked for two years in this application, until now. I
just call the usual Cocoa routines.
>
> I posted this question on the Project Builders list over the weekend
>
> but got
>
> no reply. Any ideas?
>
>
ProjectBuilder isn't responsible for unarchiving windows either?
The managers of the Project Builder mailing list have many times advised us
that the list handles IB questions, too.
>
> Every third or fourth time (somewhat random) I open a new document
>
> window in
>
> my application, I get this error message: "-[MyTextField copyWithZone:]:
>
> selector not recognized". Or sometimes "-[MyForm copyWithZone:]:
>
> selector
>
> not recognized".
>
>
If you are getting non-repeatable errors like this one, it might be a
>
reference to a released object; have you tried using zombies to prevent
>
addresses being reused and to raise an exception where you can see what
>
object is being sent copyWithZone:. Look at NSDebug.h or check google
>
for zombies and cocoa (I don't think there is a chocolate zombie movie,
>
but I could be wrong).
I haven't tried zombies or anything like that, since this is apparently a
problem with PB (or, rather, Cocoa) unarchiving a nib file created in IB. I
have no responsibility for or access to the PB, IB, or private Cocoa code. I
raise the question of a bug in IB (or, as you suggest, in PB, or Cocoa)
precisely because I wonder if the PB or IB code references a released
object, or whatever.
>
> My Interface Builder preferences are set to "Nib File Compatibility -
>
> Both
>
> Formats." When I resave the nib file using a different preference --
>
> either
>
> "Pre-10.2 format" or "10.2 and later format" -- and rebuild, the problem
>
> goes away. (To be precise, it apparently goes away. It doesn't show up
>
> after
>
> opening 20 or 30 new windows. And to make it go away in "10.2 and later
>
> format" I first have to save the nib in "Pre-10.2 format".) When I
>
> return to
>
> the both-formats setting, the problem returns.
>
>
Odd. I don't have a 10.2 install, but I would look at what actually gets
>
written into your .nib bundle. pre-10.2 files and 10.2 files are
>
probably both there, maybe you can see what is different. If none of a
>
both-format nib bundles actual files differ from either single-format
>
nib bundle, then you have an interesting problem.
Vince Demarco at Apple now has all three versions of my nib file (pre-10.2,
10.2, and both). We'll see what he finds.
>
> The stack frame list suggests this is happening while my window is being
>
> unarchived from the nib file. That makes sense, since I understand from
>
> the
>
> IB Release Notes that the difference between 10.2 and pre-10.2 IB nib
>
> file
>
> formats is the use of keyed archiving in the former.
>
>
Is your logic that given an exception in window unarchiving, you know
>
that this nib file was saved with 10.2 developer tools? You already know
>
how this nib file was saved and you also know that it works fine if
>
saved 10.2 only.
>
>
If you have a stack trace, including that in your original post might
>
have helped someone figure out what went wrong.
Yes. I should send that to Vince.
>
> Could this be a result of a bug in the IB both-formats setting?
>
>
By your evidence, yes. Something wrong is happening between writing a
>
dual format nib and reading it, but it almost certainly isn't a bug with
>
this setting in IB (unless you have evidence that this setting doesn't
>
actually try to write out a both-format nib file -- unlikely since it
>
does break your nib, so something is different when this setting is set).
I don't follow you. I guess you know more about the innards of IB than I do.
But I would have thought that the introduction of these three nib settings
in IB was an opportunity for an error to creep in. Of course, the error
could also lie in PB's, or rather Cocoa's, trying to read the new
multi-faceted nib file.
My fear is, as always, that the error is mine. But I don't see how I could
have made a mistake in designing my nib file in IB. I just dragged things
around and set connections and attributes, like the documentation advises.
And I haven't changed my code to read the nib file in two years. I've been
working on the app constantly all that time, and I haven't encountered this
problem until I turned on Both Formats nib files.
What brand of scotch are you drinking? My favorite is Lagavulin. :-)
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.