🚀 go-pugleaf

Working with the DBTableView delegate messages:

- (BOOL)tableViewWillChangeSelection:aTableView
and
- tableViewDidChangeSelection:aTableView


    As I mentioned before, returning a value of NO from
tableViewWillChangeSelection will result in the Window being left in a
disableFlushWindow mode.  (Window's "Display" is not affected, however
the Appkit documentation concerning the isDisplayEnabled message is
incorrect -- like a large number of other mistakes in the docs -- looks
like someone did a careless cut&paste job creating them...)

    An additional problem has shown up in that not every YES-returning 
"Will" message is followed by a corresponding "Did" message.  And
"Will"s that return NO ARE (sometimes) followed by a "Did" message...

    More critically for me, if you use a NXRunAlertPanel() inside the
"Will" message, the DBTableView object seems to 'halt' and wait for the
next mouse-down event.  (I get the disk-busy-please-wait icon
indefinitly.)  Upon receiving this, the DBTableView instance finishes
what it was doing...  (ie, the "Did" message, or secondary fetches for
other (connected) dbModules.)  Occasionally, this second mouse-down will
cause the DBTableView to change rows again, or (much more rarely) to
core dump, even though the mousedown event location is well outside of
the DBTableView.  Also, the mouse-down event continues to get processed
by whatever object was under it.. ie textfield, button, etc...
    My attempts to alleviate this where hopeless.  The DBTableView is
not lockFocus'ed in any way.  (Nor in any subView.)  PSgsave/PSgrestore
and PSsave/PSrestore did not help.  My instinctive guess from this is
that pressing a button on the Alert Panel modifies the event-queue in a
manner that upsets DBTableView.  But that's just a guess...  (Anyone
have the source so we could find out?)

Lastly, and rather irritatingly, if you return NO from the "Will"
message, you would think that that would prohibit the DBTableView from
changing rows...  BUT, if you drag the mouse instead of just a pressing
& releasing the mousebutton, you can select which row you want BEFORE
the "Will" message is sent (thereby changing the row).



Anyway, words to the wise -- & has anyone else been able to generate any
of these bugs???


(For what it's worth, I still love the object & it's UI -- It's just
that my head is getting too bloody to see the screen...  ;-)


        -David.




P.S>  For those of you who are wondering how I'm coping with it all:  I
maintain an instance variable to communicate to "Did" whether "Will"
said YES or NO.  If they're going to lose data, "Will" now always
NXBeeps() and returns NO.  If they want to overide it, they can drag the
mouse.   (And I'm billing it all as a "feature" to the commissioners. 
;-)))