🚀 go-pugleaf

I looking for some ideas of how I might solve my problem in a cleaner way...

I am writing an app to browse and edit a relational database.  I have created  
Inspector panels for viewing or editing records of each type.  These Panels can  
be brought up from the main window.  There are a few cases where some records  
can contain references to subrecords of another type.  In the latter case, a  
new subpanel can be created by another panel.  In each of the panels are  
PopUpLists for such common operations as "Add", "Remove" or "Move" for working  
with potential subrecords.  The relations can get a couple of levels deep.

My problem is that the keyEquivalent for "Add" is the same for all PopUpList  
MenuCells and this results in strange behavior when the user presses Command-a  
with multiple Inspectors on the screen.  This happens when one inspector  
creates another and both are still on the screen.  Usually, the PopUpList in  
the Panel with the key focus gets sent the command key, but many times the  
PopUpList in another panel gets the command key even though the Panel they  
belong to is not currently -makeKeyAndOrderFront:.

I suspect that the PopUpLists, which are actually subclasses of Window, are  
maintained in NXApp's window list in an arbitrary order - completely separate  
from the Panels they belong to, thus the unpredictable manner in which Command  
keys are sent to the PopUpLists.  Chapter 7 of 1.0 Concepts doesn't mention any  
attempt by the Application object to send commandKey: messages to the keyWindow  
before traversing the unordered list of Windows, which seems to be my problem.

I have a couple of ideas so far for solving this (which I have not implemented  
yet):

a) catch the delegate methods -windowDidResignKey: and -windowDidBecomeKey to  
add and remove the keyEquivalents from the PopUpList MenuCells with  
-setKeyEquivalent:  Thus, there would only be one PopUpList at any given time  
with a particular command key.  The problem with this approach is that it is  
not elegant, and that leads me to believe that I should restructure the  
keyboard access to my program.

b) take NeXT's advice and move the PopUpList operations to the app's main Menu  
- using the firstResponder to direct the action to the appropriate object  
whenever multiple inspector Panels are visible at once.  The problem with this  
approach is that for every case that I have a PopUpList, I am editing elements  
in an NXBrowser.  I've already had to do some serious subclassing of NXBrowser  
just to allow tabbing in and out of the panel's browser from the TextFields in  
the Panel, and I think that it would be a lot of work to make NXBrowser handle  
firstResponder in an intelligent manner.  Another disadvantage of this approach  
is that the commands would no longer work when the browser was not the  
firstResponder, while they currently are not dependent upon what is currently  
selected.

c) I suppose I could just subclass the Application object method  
-makeWindowsPerform:inOrder: and modify it to send to the keyWindow first, but  
there is no guarantee that NXApp uses this method to pass on commandKeys nor  
that I wouldn't break something else by changing this method.

If anyone has any suggestions or comments, please (at least) copy me on your  
response since I'm spending more time programming than reading UseNet...

Thanks!
-- 
Brian Willoughby	Software Design Engineer, BSEE
BrianW@SoundS.WA.com	SoundSoftware
NeXTmail welcome