Re: edit grid: issues involving marking, selecting,

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.