🚀 go-pugleaf

In article <1992Aug12.002320.2320@afs.com> greg@afs.com writes:
>
>You are doing an inherently problematic thing, because PopUpLists are NOT  
>controls, like TextFields and Buttons. They inherit through the Window  
>hierarchy and are actually subclasses of Menus. By definition, you cannot  
>ask a Window what Window it lives on. The Matrix lives on the PopUpList,  
>not the Window it appears to be on, so it's no help either. Even the cover  
>button is no help, because it's not directly attached to the PopUp.
>

I think NeXT should implement the concept of parent/child windows to
provide a generic solution to this problem (i.e. the PopUpList window
becomes the child of the main window). There would probably be many uses
for such a feature besides PopUpLists. Also, closing/hiding the parent
window could automatically close/hide the children.

Dave Griffiths

dhg@sinix.UUCP (David Griffith) writes:
>In article <1992Aug12.002320.2320@afs.com> greg@afs.com writes:
>>You are doing an inherently problematic thing, because PopUpLists are NOT  
>>controls, like TextFields and Buttons. They inherit through the Window  
>>hierarchy and are actually subclasses of Menus. By definition, you cannot  
>>ask a Window what Window it lives on. The Matrix lives on the PopUpList,  
>>not the Window it appears to be on, so it's no help either. Even the cover  
>>button is no help, because it's not directly attached to the PopUp.

So keep the button around.  (This is the reverse of my problem, which is
usually how to munge with the PopUp List itself, or it's matrix).  When
you create the PopUp programmatically, keep the button (perhaps in your list
of things to free) as an id instance variable.  Overhead is small, since it
is a pointer.

The other alternative is to create the popUp in IB, where you get a handle to
the button.  Now, reference the popUp with [button target], or add a category
to PopUp to return the matrix (which is what I do) and munge it directly.

>I think NeXT should implement the concept of parent/child windows to
>provide a generic solution to this problem (i.e. the PopUpList window
>becomes the child of the main window). There would probably be many uses
>for such a feature besides PopUpLists. Also, closing/hiding the parent
>window could automatically close/hide the children.

I'm not so sure about this, but I really hope PopUp list has been debugged
and better integrated into 3.0; it's kind of a bastard child now.

-- 
Subrata Sircar | ssircar@canon.com | Prophet & SPAMIT Charter Member
Canon Information Systems and I do not speak for each other on all things.
"I wish people wouldn't instantly assume that I am an idiot." (Valentine)
"A restaurant is a whorehouse that does food instead of sex." (Roger Lustig)

One small PopUp problem I haven't seen addressed is having a lot of
entries in a PopUp or PopDown (whatever those downward expanding PopUp
menus are called).  There needs to be something that is able to,
perhaps, scroll the choices up and down the way Mac pull-down menus do
when the menu is too long to display on the screen.

Has anything been done in 3.0 to handle this situation?

I wish that merely using a scrollView were a suitable replacement for
such problems, but the ability of the PopUp to give an infinite number
of choices as well as show the chosen one in a very small space and
almost instantly is *very* handy.  I would hate to have to revert to a
button bringing up a panel that had a scrollView in it.  That would
seem so cumbersome to me as a user.

-- 
-- Jeff (jeffo@ux1.cso.uiuc.edu)
-- No NeXTmail please