Re: setHidden: on MacOS 10.2
Re: setHidden: on MacOS 10.2
- Subject: Re: setHidden: on MacOS 10.2
- From: "M. Uli Kusterer" <email@hidden>
- Date: Sat, 1 May 2004 10:24:49 +0200
At 11:44 Uhr -0700 30.04.2004, cricket wrote:
- Moving the widget in question to (-100, -100) is a common tactic
that I've seen used in many other circumstances (although never in
Cocoa to hide a widget), and I've seen it bite people later on, when
the assumption of -100, -100 being a good place to park things
suddenly is no longer the case.
Well, -100, -100 definitely is bad, because the value is just too
low. But in the case of views like NSScrollView and in the absence of
a real hiding feature, I think it's acceptable use (after all,
NSScrollView's job is to control the coordinate system. But I agree,
it's not a generally viable solution for "faking" setHidden:, and I
could see why one would argue against using this approach at all.
- Using a tabview (and hiding the tabs) can be a good idea in many
cases. However, consider the case where you have a view with 100
widgets in it and you want to hide one. Duplicating 99 of them in a
second view uses up extra disk space, could affect nib loading
times, and is just inviting potential problems (i.e. did I hook up
all 99 widgets the same way in both views?)
That would of course be stupid. But there's nothing keeping the
developer from creating a tab view that wraps around a single item.
And used that way, I really don't see anything wrong with this
approach.
I take from your post that you think taking out the view and
re-inserting it into the hierarchy for hiding it is okay? From your
posting, it sounded (maybe only to me) as if you were against *all*
the approaches suggested. I think taking out a view is awkward and
error-prone, not to mention that if you expect correct overlapping
you'll have to remember the positions of views you take out, and
you'll also need some object that retains the view until it is
re-inserted. Therefore, I think this solution isn't really complete
either.
IMHO, the best option for those who can't use setHidden: would be to
create some sort of "placeholder view". When hiding a view, exchange
it for an empty placeholder view (an NSView subclass that draws
nothing). The placeholder view retains the original view until it is
deleted. That way, you have a very self-contained generic solution,
and can use NSView's support for exchanging two views in the
hierarchy to show/hide the critter.
If you're not using auto-resizing, an NSClipView around a group of
views to hide may also work. Just set the clip view's height to zero
and everything's hidden. I think there was an implementation of a
Finder-style collapsible "Info"-window by someone that used this
approach. This is of course lethal when you're auto-resizing, because
then the views may get negative sizes and screwy positions as soon as
you make them too small.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
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.