RE: Swapping isa's (was Re: Hex Edit controls (resknife))
RE: Swapping isa's (was Re: Hex Edit controls (resknife))
- Subject: RE: Swapping isa's (was Re: Hex Edit controls (resknife))
- From: Jeff Laing <email@hidden>
- Date: Wed, 1 Dec 2004 09:51:20 +1100
> From: glenn andreas [mailto:email@hidden]
> >>> @implementation NSTextView (HexTextView)
> >>> - (void)swapForHexTextView
> >>> {
> >>> isa = [HexTextView class];
> >>> }
> >>> @end
> >>>
> >>> Is 'isa' really writeable? Is this not going to crash and burn???
>
> Changing isa is usually only safe if the old class and the new class
> have the same instance variable layout (such as having the new class be
> a subclass of the old one without any new instance variables). In
This was what I figured as well. Since the above nastiness happens in a
subclass that adds no extra instance variables, I figure it scrapes by.
> general, though, you are better off adding the new class to IB and
> setting it in your NIB to start with (and then you can have
> additional ivars in your subclass).
You'd think so, wouldn't you?
I grabbed the ResKnife sources (thanks again Nick and Uli) and tried doing
this, and the nightmare still goes on.
One reason for the isa hackery is that pre-10.2 Nibs don't support custom
subclasses of NSTextView. Ok, I don't really care there, I'm prepared to
set 10.2 as my baseline.
A better reason, so far, is that <RANT>Interface Builder is the dumbest
crappiest most insane idea that anyone ever in the history of time and space
has invented</RANT>
There, got that out of my system. I am currently stuck in a situation where
I cannot create a NIB that contains a "legal" window layout that would suit
that code.
Irrespective of how careful I try to do it, Interface Builder insists on
corrupting the HexWindow.nib. The symptoms started out as:
- make a minor change
- save the nib
- exit the session
- double-click the nib
- warning shows saying "I found 'n' problems and repaired them. Please
resave"
- save
- Interface Builder disappears
- Crash Reporter dialog shows "Would you like to tell Apple about this?"
- fist shakes at screen as mind considers what it would like to tell Apple
(and yes, I *have* let Crash Reporter tell Apple about it, along with a
uuencoded, compressed copy of the NIB it was trying to munge)
I have managed to do all but remove the 'continuous spell checking' bit from
one of the text controls. If I
- open the nib
- change that one flag
- save
Interface builder crashes, after saving a new corrupt copy of the Nib.
Fortunately, in this particular instance, the ~.nib file is retained and
I've been able to go round the loop.
There've been other stupidities like you open the nib, edit something, then
save and it says "The nib was renamed, please save again" - from experience,
at this point its all toast anyway, but I tried saving again and it always
crashes.
I've tried creating the nib from scratch (which is a real pain when you
consider all the inter-connections you have to remember. (There appears to
be no mechanism that will output a completely text-readable format NIB that
I could work through with a text editor to repair. Apple, download graphviz,
look at how it works, then integrate it into Interface Builder so you can
print out a nice illustration of what interconnectivity lives in one of
those otherwise opaque files).
Didn't help. The conclusion I've come to is that Interface Builder *claims*
to support custom classes for NSTextView but really it doesn't. One display
anomaly I've noticed during these sessions is that you select the textview
in an Instances tree, and display the Custom Class tab in the Info window,
the first click you do on the custom class names does not "stick" - it snaps
back to NSTextView, and you have to select the custom class name again -
this time, it does stick. It also appears to take quite a while for the
NSScrollView text in the Instances tree to update to show the class of its
content.
What I really *really* hate about all this is that I'm a *programmer*, I've
developed systems with millions of lines of code (yes, millions - I've
counted), and Interface Builder has reduced me to pushing buttons, and
dragging around graphics, with the hope that I can find the magical
combination that will let me through, giving me absolutely no control
whatsoever of the result, nor confidence that even if it works, its correct.
There is no auditabiliy whatsoever, and those of us who actually *live* by
code review will tell you that thats a recipe for disaster, always, no
exceptions.
(Oops, must have misplaced that </RANT> tag :)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden