On Jul 18, 2009, at 01:18, Dale Miller wrote:
I've satisfied myself that trying to use IB which is essentially a
bind-at-compile-time approach is a pita when trying to deal with an
execution-time-specified number of windows which must accommodate a
tab view which must accommodate a workspace (text view imbedded in a
scroll view), the size of which is run-time-specified.
If I can't create an object programmatically using the documented
class interfaces then I think one of the following is true:
1)The documentation is incomplete or incorrect
2)The public class interface is insufficient
3)There is a bug in the framework
4)I have missed or misunderstood something, or did a boo-boo in my
code (I'll accept that as the most likely).
In any case, something needs to be fixed, or I need to be shown what
I'm doing wrong.
a. It's #4. Possibly with a tiny bit of #1. It really is possible to
create windows and views programmatically. There is no bug in the
framework. (At least, you'd have to *prove* that there is. These
NSView APIs have been tried and tested countless times.)
b. You'll likely have trouble getting expert help on this, because the
expert help on this list will likely think it's waste of time to do it
programmatically.
c. A far better approach is to use IB to create the pieces you want to
assemble at run time, each as a separate view subtree, probably but
not necessarily in a separate NIB file. Then you have only two things
to do at run time: add the subtrees to your window's view hierarchy
(which is very easy), and resize the subtrees you add to your window's
view hierarchy (sometimes fiddly, but writing code to resize views is
much easier than constructing the views). If you've set the
autoresizing up right in your NIBs, then often all that's necessary is
to resize the subtree root view to fit view it's becoming part of, and
everything else just happens automatically.
d. Debugging hand-constructed views is a much bigger PITA than pretty
much any way of doing it that involves IB.
e. Notwithstanding a-d, your app *may* have a valid reason for doing
this the hardest way, but if so we haven't heard it yet.
FWIW.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
