Re: re Hiding controls and another question
Re: re Hiding controls and another question
- Subject: Re: re Hiding controls and another question
- From: John Saccente <email@hidden>
- Date: Sat, 2 Mar 2002 02:19:31 -0600
On Saturday, March 2, 2002, at 12:29 AM, Andy Lee wrote:
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?
No, you're right. The first occurrence in his code used self as the
key, and the rest used [self description] as the key, so I just
mindlessly suggested the smallest change to make it consistent. It
would seem to make more sense to just use the object itself. But this
might still be a problem for some objects, depending on their
implementation of isEqual, no? Actually, the docs say that the key
object needs to conform to the NSCopying protocol, and NSView doesn't
seem to do that. ... Ok, I just tried and it doesn't work.
You might need a more direct way to ensure some kind of pointer
comparison takes place, like maybe
[gViewDict setObject:proxyView forKey:[NSString
stringWithFormat:@"%x",(int)self]];
I don't know if that's the most elegant way to do it, but it seemed to
work just fine.
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.")
Right, I didn't think that through.
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.
Right.
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.
Or you can just go to bed now. This was supposed to be a 20 minute job,
right? :o)
John Saccente
email@hidden
_______________________________________________
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.