edit grid: issues involving marking, selecting, inserting, undoing

Hi developers! Hi Dave!

Testing RC2. Client Win XP, Server Debian Sarge, PostgreSQL 8.1.4.

I think I have found more issues in the edit grid, which have some 
potential to damage things.
Sorry to bring this up so close to release. I did not find it any 
earlier. Anyway, it is up to you what you fix, what you postpone and 
what you reject.

Definition:
I use the term "marked" for the field with the bold frame, which is 
edited when you start typing.
I use the term "selected" for the field or range that is being highlighted.

In the edit grid try the following:
Copy a string.
Mark a field of an existing tuple. Only mark it, do not click a second 
time to get into edit mode.
Press <ctrl><v>.
Popup warns me (my primary key is a serial field):   "This table contains serial columns. Do you want to use the values

in the clipboard for these columns?"
Say YES.
!! I wouldn't actually say YES, but if there was no sequence involved, 
we would not even get a warning.
A NEW tuple is inserted at the end and the value is copied to the first 
field.
!! <esc> does not help, "undo" button stays inactive. Looks like I am 
trapped.
Actually, "undo" gets activated after I have entered edit mode in the 
field with the value in the newly inserted row. And I can get rid of the 
new row by pressing "undo".
The "undo" feature even works _without_ entering the new field. Even 
though the button is inactive, <ctrl><z> will fire.
!!! BUT if you do this, the "current" row (where the field is marked) 
gets deleted. (Or so it seems.) And this row has gone for good. No 
undoing the buggy "undo" ...
(Actually, a reload shows that the row is still there, so the last part 
seems to be a display issue.)
I think you get the idea ..


Several issues are involved:

# I think it is misleading to start a new tuple, while a field of an 
existing tuple is marked and I press <ctrl><v>. Rather, it should (enter 
edit mode and) replace the value of the marked field.
I am not sure if pgAdmin is aware of the data structure in the 
clipboard. If it is, then it might act depending on the data in this 
case. If it is a record, do nothing, if it is simple data, insert it in 
the marked field.
Or, if that causes problems, do nothing at all, rather.
New tuples should only be inserted if the "new" tuple is marked. (Or 
more precisely, starting from the field that is being marked.)

# When a new tuple is inserted, the "undo" button should be activated. 
Generally the "undo" feature is quirky:
If I edit a field, the button gets active.
If I leave the field, by clicking another field in the same row, the 
button stays active and I can click any number of times on it. It stays 
activated. Only the first click, however, has an effect: it reverts the 
changes. Button should fall back to inactive, after the feature has "run 
out of ammo".
However, if I leave the field, by pressing <tab>, thus marking the next 
field in the same row, the button stays INACTIVE and clicking it has no 
effect. I can still press <ctrl><z> to revert my changes, though.
Button should stay activated, regardless of _how_ I leave the field, as 
long as the changes can be undone.

# Undoing the changes after inserting a new row (inadvertently or not) 
should not wipe out the wrong row (the one that holds the marked field)
You might circumvent this problem if you automatically mark the (first?) 
field of a newly inserted row, but this fix would only go half the way. 
It would force a save if one was in the middle of editing another row. 
Rather, you should insert values or records only at the position of the 
marked field.


I think much arises from the management of marked fields and selected 
ranges.
Try this:
Mark a field.
Select a different row.
Press <shift> and try to select a range of rows. Start of the range is 
(to my surprise) defined by the _marked_ field, not the _selected_ row.

Or try this:
Mark a field.
Press <shift> and select another field, the whole area gets selected, 
_including_ the marked field.
Now, start over, mark a field.
Press <ctrl> and select another field (or a number of fields). The 
marked filed is _excluding_ from the selection. (Should be included.)


Maybe, the general cure for most of the above mentioned symptoms would 
be to mark what you select and select what is marked (not: what you 
mark!). It would make things easier to manage - or that is what I 
assume, not actually knowing the code.
If you look at OOo Calc for instance, the last field selected is always 
the one being marked.


Sorry for the longish report. I have gone over it several times to try 
and avoid misunderstandings. After all, English is not my first language.


Regards
Erwin