Re: edit grid: issues involving marking, selecting,

Hi Dave!

dpage(at)postgresql(dot)org wrote:

<explanation snipped>

Thanks for the insight.

>
> So, onto the changes I've made:
>
> 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:

If I am in the middle of editing a row and press <ctrl><v> then a
number of things happen.
(While editing a row, I am not necessarily in edit mode! Also, it
happens to me on a regularly bassis that I press <ctrl><v>
(inadvertantly) before having entered edit mode.)
1.) The row I am editing is being saved. That's not what I wanted when I
pressed <ctrl><v>. Whether you force to save or to discard pending
changes in the current row, data may be lost in either case.
2.) The curser goes to the end of the table, and out of sight if there
are many rows. Inexperienced users will not know _at all_ what just
happened. They most probably wanted to insert data into the marked field.
3.) If I click anywhere now (with the cursor out of sight), the new row
will be saved - hopefully raising an error. Again, that is probably not
what the user wanted.

It would be more obvious (and solve all issues at hand) to insert data
only starting from the position of the cursor. In case anything would be
overwritten, you might issue a warning before proceeding. But that may
be redundant as long as we don't leave the current row and can undo it all.

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.

>
> 2) When the new row paste is completed, the Save and Undo options are
> enabled.
That seems to work fine 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.

>
> I think it's all working as it should now apart fromt he know issue
> that things get marked dirty upon edit mode start, rather than when
> the data is actually changed. But that's much harder to fix as we
> already discussed. I'll send you an exe off list.

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?

>
> > 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.
>
> I'll fix what I can - but we are getting very close to release now so
> I will be much more critical about what is or isn't a showstopper -
> especially as I think they are becoming corner cases far more often.
>
> Thanks for the reports though, they are appreciated even if frustrating!

Sometimes you have to do unpleasant things if you care. ;)

Regards
Erwin