home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / next / programm / 5577 < prev    next >
Encoding:
Text File  |  1992-08-12  |  3.9 KB  |  74 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!nwnexus!sounds!brianw
  3. From: BrianW@SoundS.WA.com (Brian Willoughby)
  4. Subject: Conflicting PopUpList keyEquivalents in multiple panels
  5. Message-ID: <Bsv41E.3s8@sounds.wa.com>
  6. Keywords: MenuCell Inspector windowDidResignKey windowDidBecomeKey makeWindowsPerform:inOrder:
  7. Sender: brianw@sounds.wa.com (Brian Willoughby)
  8. Reply-To: BrianW@SoundS.WA.com
  9. Organization: SoundSoftware, Bellevue, WA, USA
  10. Date: Wed, 12 Aug 1992 08:39:13 GMT
  11. Lines: 61
  12.  
  13.  
  14. I looking for some ideas of how I might solve my problem in a cleaner way...
  15.  
  16. I am writing an app to browse and edit a relational database.  I have created  
  17. Inspector panels for viewing or editing records of each type.  These Panels can  
  18. be brought up from the main window.  There are a few cases where some records  
  19. can contain references to subrecords of another type.  In the latter case, a  
  20. new subpanel can be created by another panel.  In each of the panels are  
  21. PopUpLists for such common operations as "Add", "Remove" or "Move" for working  
  22. with potential subrecords.  The relations can get a couple of levels deep.
  23.  
  24. My problem is that the keyEquivalent for "Add" is the same for all PopUpList  
  25. MenuCells and this results in strange behavior when the user presses Command-a  
  26. with multiple Inspectors on the screen.  This happens when one inspector  
  27. creates another and both are still on the screen.  Usually, the PopUpList in  
  28. the Panel with the key focus gets sent the command key, but many times the  
  29. PopUpList in another panel gets the command key even though the Panel they  
  30. belong to is not currently -makeKeyAndOrderFront:.
  31.  
  32. I suspect that the PopUpLists, which are actually subclasses of Window, are  
  33. maintained in NXApp's window list in an arbitrary order - completely separate  
  34. from the Panels they belong to, thus the unpredictable manner in which Command  
  35. keys are sent to the PopUpLists.  Chapter 7 of 1.0 Concepts doesn't mention any  
  36. attempt by the Application object to send commandKey: messages to the keyWindow  
  37. before traversing the unordered list of Windows, which seems to be my problem.
  38.  
  39. I have a couple of ideas so far for solving this (which I have not implemented  
  40. yet):
  41.  
  42. a) catch the delegate methods -windowDidResignKey: and -windowDidBecomeKey to  
  43. add and remove the keyEquivalents from the PopUpList MenuCells with  
  44. -setKeyEquivalent:  Thus, there would only be one PopUpList at any given time  
  45. with a particular command key.  The problem with this approach is that it is  
  46. not elegant, and that leads me to believe that I should restructure the  
  47. keyboard access to my program.
  48.  
  49. b) take NeXT's advice and move the PopUpList operations to the app's main Menu  
  50. - using the firstResponder to direct the action to the appropriate object  
  51. whenever multiple inspector Panels are visible at once.  The problem with this  
  52. approach is that for every case that I have a PopUpList, I am editing elements  
  53. in an NXBrowser.  I've already had to do some serious subclassing of NXBrowser  
  54. just to allow tabbing in and out of the panel's browser from the TextFields in  
  55. the Panel, and I think that it would be a lot of work to make NXBrowser handle  
  56. firstResponder in an intelligent manner.  Another disadvantage of this approach  
  57. is that the commands would no longer work when the browser was not the  
  58. firstResponder, while they currently are not dependent upon what is currently  
  59. selected.
  60.  
  61. c) I suppose I could just subclass the Application object method  
  62. -makeWindowsPerform:inOrder: and modify it to send to the keyWindow first, but  
  63. there is no guarantee that NXApp uses this method to pass on commandKeys nor  
  64. that I wouldn't break something else by changing this method.
  65.  
  66. If anyone has any suggestions or comments, please (at least) copy me on your  
  67. response since I'm spending more time programming than reading UseNet...
  68.  
  69. Thanks!
  70. -- 
  71. Brian Willoughby    Software Design Engineer, BSEE
  72. BrianW@SoundS.WA.com    SoundSoftware
  73. NeXTmail welcome
  74.