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.