//-----------------------------------------------------------------------------
// MiscTableScroll BUGS
// $Id: BUGS.txt,v 1.43 97/07/08 14:38:59 sunshine Exp $
//-----------------------------------------------------------------------------

BUGS:
----
- Text on row titles is still getting clipped when dragged if the row wasn't 
	entirely visible when dragging was initiated.  

- Incorrect coordinate transformations
	draw_view() in MiscTableView is *not* transforming the PostScript 
	graphics state.	 It is doing the appropriate transformation calculations, 
	but never actually applies them to the gstate.	

	Eric took a different approach to drawing a slot for the drag-cache than 
	Pawl's draw_view().	 Eric tried using -copyPSCodeInside:to: to create the 
	drag cache.	 It automatically includes all the subviews (good) and 
	doesn't have the problem with row title-cell text being clipped which 
	draw_view() has (good).	 However, it thinks it is creating PostScript 
	code for a printer, so it uses printer fonts instead of screen fonts 
	(bad), and it doesn't draw images with alpha (transparency) because it 
	thinks it's going to a printer (bad).  

- Problems with dragging columns
	zarnuk says: Dropping a column in the same location that it was dragged 
	out of causes the column to be re-drawn, but does not draw the subviews.  

- Auto-scrolling broken.
	Eric broke auto-scrolling during mouse tracking by giving the cell a 
	chance to track the mouse first.  Apparently one should be clipping the 
	tracking rect to the visible rect so that the cell's tracking loop exits 
	if the mouse is dragged past the edge of the visible rect.	This way 
	TableView will be able to scroll the view as appropriate.  

- Border views get out of sync with docView.  To reproduce:
	1) In IB, create a window with a TableScroll on it.
	2) Turn on row border.
	3) Add 5 or 6 rows.
	4) Enter test-mode.
	5) Make the window small enough so that there is avertical scroll knob.
	6) Scroll down to the bottom.
	7) Resize the window width-wise only (make it wider).
	8) Note that the scroll knob jumps and the views get out of sync.  You 
	   can see this visually by clicking on a row in the docView.  
	This also happens to the column border view if one swaps column for row 
	and row for column in the above description.  

- Resizing 'autosize' slots generates truly bizarre behavior.  Needs to be 
	fixed.	

- TableCell's "extra" data will probably have alignment problems on HPPA and 
	Sparc.	

FIXED:
-----
v129
- Editing with MiscTableCell in non-default zone causes crash upon first edit
	in some other zone.	 This occurs in ScrollDir.	1) Launch, 2) cmd-n to
	open /tmp, 3) double-click on "console.log", 4) cmd-w, 5) double-click
	on a filename in home directory, 6) BOOM! [Eric: I disassembled portions
	of the AppKit to find out what was going on.  It turns out that this is a
	NeXT bug.  They allocate ClipViews from transient zones -- such as in
	ScrollDir -- and cache them for later re-use.  They don't bother to
	consider that the zone may become defunct.	To get around the problem, I
	disabled use of private zones in the demo programs.]

v127
- getRow:col:forPoint: is incorrectly returning 'self' even when point is 
	outside of bounds, in which case it should return 'nil'.  
- Tabbing from cell to cell during editing doesn't adjust keyboard cursor.
- MiscTableScroll is drawing the keyboard-cursor when it shouldn't be.	When 
	you call -setCursorRow: (or -setCursorCol:) the cursor is unconditionally 
	being drawn -- even if it shouldn't be (for instance, if the 
	MiscTableScroll is not first responder, or the cursor has been disabled).  
- drawCellAt:: subverts drawing of the keyboard cursor.	 It draws right on 
	top of the keyboard cursor without restoring it.  [This wasn't a bug 
	after all.	It was merely a display artifact from the preceding bug.] 
- The feedback from MiscTableScroll's incremental-search draws outside of the 
	view's frame.  When the feedback is later erased, the portion outside of 
	the frame does not get erased.	(This problem can be observed by making 
	the Table Selector in PCS narrow and typing the name of a long table, 
	such as "Surgical Positioning Aids".) 

- LAZY MODE BUG:
	If you edit a cell which is only partially visible (by double- clicking, 
	for instance) the cell is scrolled to visible before editing is started.  

	However, the cell is latched *before* scrolling.  The scrolling may blast 
	the contents of the cell when drawing the newly exposed portions of the 
	view.  Therefore, when editing is finally started, the cell contents are 
	not what they were when it was latched.	 

	There is a FIXME in the source suggesting copying the cell in lazy mode.  
	This seems like a good solution.  (Even just scrolling around after 
	editing has begun will destroy the old cell.) 

- Sometimes editing is started with the wrong frame rectangle. To reproduce:
	1) Bring up the Workstation table editor in PCS.
	2) Start editing the very last field on the very last row.
	3) Tab.
	4) It is now editing the very first field on the very first row.
	5) Notice that the rectangle which was used for the editing is wrong 
	   (doesn't cover the entire cell).	 
	[This turned out to be another guise of the preceding LAZY MODE BUG.]

v125
- Fixed v121 bug -- fonts were not restored properly in
	-[MiscTableCell tableScroll:reviveAt::].