Erwin Brandstetter wrote:
1) When a new row paste occurs, the cursor cell is moved to the
position of each column as data is inserted, such that it will be on
the last affected cell when the paste has completed. This ensures that
any undo operation will happen on the correct row.
Undoing the wrong row is now out of the picture, I'll give you that.
But I think it should be the other way round: the user should have to
set the cursor _first_ and then insert at the marked position. The
current order of events can be a trap for various reasons:
...
Or, if you have to insert into a new row, the user should be warned
before saving (or discarding) pending changes. And if the cursor jumps
to the new row, so should the visible range of the window.
This is the change I've committed. You now get a "Save? Yes/No/Cancel"
message. Changing the way the cursor works isn't really an option right now.
3) When an Undo has been performed, the Undo and Save buttons are
disabled.
That seems to work, too. Although there is still a quirk: If I leave the
edit mode by pressing <tab> and thus moving the cursor to the next
field, the undo button will be incorrectly inactivated, while <ctrl><z>
still works.
Also fixed.
It may be noteworthy that the undo-feature correctly recognizes whether
data has actually been changed (is only activated in these cases). Seems
to operate independently?
Well the button is activated at the same time, but the underlying data
structure (sqlTable) keeps track of the old/new values and thus ensures
that the undo actually does the right thing. To fix things properly (for
the next release), I need to conditionally activate the buttons based on
whether or not the sqlTable reports a data change in the row (which it
currently can't do).
Cheers, Dave.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
