Re: re Hiding controls and another question
Re: re Hiding controls and another question
- Subject: Re: re Hiding controls and another question
- From: Andy Lee <email@hidden>
- Date: Sat, 2 Mar 2002 01:29:42 -0500
At 9:45 PM -0800 3/1/02, Graeme Hiebert wrote:
>
On Friday, March 1, 2002, at 09:14 PM, John Saccente wrote:
>
>
>Not quite yet! :o)
>
>
>
>I think this:
>
>
>
> if ( ![gViewDict objectForKey:self] )
>
>
>
>should be
>
>
>
> if ( ![gViewDict objectForKey:[self description]] )
>
>
Thanks. You caught a glimpse of my first failed attempt. I forgot to fix one instance apparently. :^)
>
Guys, I don't get this. It seems to me that "self" is exactly the right key to use in the dictionary, as opposed to "[self description]", which is not even guaranteed to be unique. You could have a wacky NSView subclass whose -description method always returns @"me" -- or even a not-so-wacky NSView whose -description depends on its -stringValue, which could change at any time. Am I missing something?
>
>Anyway, one possible problem might be that if the superview is destroyed, the detached subview will be left floating in limbo, no?
Good point. The global dictionary would keep a reference to it, so it would never get released. Maybe a background task could search the dictionary for views whose release count is 1, and discard them.
>
> Plus, any messages sent to the hidden subview will go to the proxy and will be lost (like a setStringValue: or something.)
Anything with a pointer to the "real" view will keep sending messages to the right place. Only messages that propagate down the view hierarchy -- which is the only place besides the global dictionary that references the proxy view -- will go to the proxy view. (It isn't a "proxy" in the sense of Distributed Objects, just in the sense of "placeholder.")
>
> Perhaps you'd want a special NSView subclass for your proxy object which was aware of its disembodied doppelganger and would forward messages accordingly?
>
>
True, it's not perfect.
A nice thought-provoking piece of code, though! And could be perfectly adequate in many situations.
I'm sure you were hoping we'd all accept the remaining issues as "an exercise left for the reader." No such luck! ;)
>
Messages should still go to the original object though, I think, unless they were going through the responder chain.
That's what I would think. Actually I forgot about the responder chain when I said "view hierarchy" above.
>
Like you say, using a special View class instead of a global dictionary would pretty much take care of the biggest issues: memory management.
>
I thought John meant using a special View class for use *in* the global dictionary. Even if you create a ProxyView subclass that knows about its disembodied "real" view, the real view still won't know about the proxy view. So when you send the real view a -show message, it won't know which proxy view to relieve of proxy duty. In a way, the dictionary is a way of adding a "myProxyView" instance variable to views -- something you can't do for real without altering NSView itself.
Other things to consider if someone wants to take this code further:
* You should handle the case where someone sends a *proxy view* a -hide message. You should disregard this, and maybe raise an exception or log a warning.
* There's still the issue of tab order when a text field is hidden.
--Andy
_______________________________________________
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.