home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / next / programm / 8269 < prev    next >
Encoding:
Text File  |  1993-01-23  |  3.2 KB  |  76 lines
  1. Organization: Sponsored account, Mathematics, Carnegie Mellon, Pittsburgh, PA
  2. Path: sparky!uunet!usc!howland.reston.ans.net!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!bb3.andrew.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!da0g+
  3. Newsgroups: comp.sys.next.programmer
  4. Message-ID: <ofM9y2200WA78Jzh9B@andrew.cmu.edu>
  5. Date: Fri, 22 Jan 1993 20:29:38 -0500 
  6. From: David Apfelbaum <da0g+@andrew.cmu.edu>
  7. Subject: DBTableView bugs??
  8. Lines: 66
  9.  
  10.  
  11.  
  12. Working with the DBTableView delegate messages:
  13.  
  14. - (BOOL)tableViewWillChangeSelection:aTableView
  15. and
  16. - tableViewDidChangeSelection:aTableView
  17.  
  18.  
  19.     As I mentioned before, returning a value of NO from
  20. tableViewWillChangeSelection will result in the Window being left in a
  21. disableFlushWindow mode.  (Window's "Display" is not affected, however
  22. the Appkit documentation concerning the isDisplayEnabled message is
  23. incorrect -- like a large number of other mistakes in the docs -- looks
  24. like someone did a careless cut&paste job creating them...)
  25.  
  26.     An additional problem has shown up in that not every YES-returning 
  27. "Will" message is followed by a corresponding "Did" message.  And
  28. "Will"s that return NO ARE (sometimes) followed by a "Did" message...
  29.  
  30.     More critically for me, if you use a NXRunAlertPanel() inside the
  31. "Will" message, the DBTableView object seems to 'halt' and wait for the
  32. next mouse-down event.  (I get the disk-busy-please-wait icon
  33. indefinitly.)  Upon receiving this, the DBTableView instance finishes
  34. what it was doing...  (ie, the "Did" message, or secondary fetches for
  35. other (connected) dbModules.)  Occasionally, this second mouse-down will
  36. cause the DBTableView to change rows again, or (much more rarely) to
  37. core dump, even though the mousedown event location is well outside of
  38. the DBTableView.  Also, the mouse-down event continues to get processed
  39. by whatever object was under it.. ie textfield, button, etc...
  40.     My attempts to alleviate this where hopeless.  The DBTableView is
  41. not lockFocus'ed in any way.  (Nor in any subView.)  PSgsave/PSgrestore
  42. and PSsave/PSrestore did not help.  My instinctive guess from this is
  43. that pressing a button on the Alert Panel modifies the event-queue in a
  44. manner that upsets DBTableView.  But that's just a guess...  (Anyone
  45. have the source so we could find out?)
  46.  
  47. Lastly, and rather irritatingly, if you return NO from the "Will"
  48. message, you would think that that would prohibit the DBTableView from
  49. changing rows...  BUT, if you drag the mouse instead of just a pressing
  50. & releasing the mousebutton, you can select which row you want BEFORE
  51. the "Will" message is sent (thereby changing the row).
  52.  
  53.  
  54.  
  55. Anyway, words to the wise -- & has anyone else been able to generate any
  56. of these bugs???
  57.  
  58.  
  59. (For what it's worth, I still love the object & it's UI -- It's just
  60. that my head is getting too bloody to see the screen...  ;-)
  61.  
  62.  
  63.         -David.
  64.  
  65.  
  66.  
  67.  
  68. P.S>  For those of you who are wondering how I'm coping with it all:  I
  69. maintain an instance variable to communicate to "Did" whether "Will"
  70. said YES or NO.  If they're going to lose data, "Will" now always
  71. NXBeeps() and returns NO.  If they want to overide it, they can drag the
  72. mouse.   (And I'm billing it all as a "feature" to the commissioners. 
  73. ;-)))
  74.  
  75.  
  76.