Re: pgAdmin 1.4.3 bug with delete button in win32 & OTHER

> -----Original Message-----
> From: pgadmin-support-owner(at)postgresql(dot)org
> [mailto:pgadmin-support-owner(at)postgresql(dot)org] On Behalf Of
> George Pavlov
> Sent: 03 August 2006 19:47
> To: pgadmin-support(at)postgresql(dot)org
> Subject: Re: [pgadmin-support] pgAdmin 1.4.3 bug with delete
> button in win32 & OTHER

OK, I've committed some changes to TRUNK that should improve things. It
needs more testing on Mac & Linux (these sort of issues are the least
x-platform friendly :-(, but I'll move onto that shortly...

> 1. if only one cell is selected (but not in cell-edit mode)
> and i press
> DELETE i get a confirmation dialog, saying "yes" to that does not do
> anything -- this is what i was referring to. this is bad.

Fixed.

> 2. if i click on a rownumber (highlight a whole row) and
> press DELETE i
> get a confirmation dialog and the row gets deleted. this is good.

Already working :-)

> 3. if i get into edit mode on a cell (press F2, or double click) i can
> edit (except for the delete key bug) and the changes get saved.

Delete key fixed.

> 4. if in the above scenario (3) i have pressed DELETE at any time F2,
> the UP, DOWN, LEFT, RIGHT keys stop working until i click someplace.

Fixed.

> 5. if i highlight a COLUMN and press DELETE, it asks me about
> deleting a
> ROW, but of course nothing happens.

Fixed.

> now that i am looking at that grid in detail here are a few other
> bugs/questions/enhancement ideas:
>
> a. click on a row number and select a whole row (as in (1) above), now
> holding the SHIFT key start pressing the DOWN key -- you would expect
> subsequent rows to be fully highlighted, instead only one column of
> cells of those rows are highlighted (the cells below the cell that was
> highlighted before you selected the whole row), resulting in
> a funky T-
> or L-shaped pattern. not sure what pressing DELETE should do
> after that
> -- the confirmation dialog comes up but nothing really
> happens when you
> say "yes" -- i guess this is behavior similar to (1).

That's really down to the grid control. It will no longer prompt you
about deleting.

> b. how can one insert a tab character in a cell? by analogy with a
> newline (CTRL+ENTER) i would have expected CTRL+TAB to work, but that
> just moves you to the next cell.

Ctrl+Tab should now work.

> c. pressing CTRL+SPACE on a cell highlights the cell and
> makes the save
> icon enabled in the toolbar even though no visible data change is
> observed.

Not sure what's causing that.

> d. double-clicking the column separator in the column header sizes the
> column to the width of the HEADER, ignoring the width of the
> data, this
> is behavior that is the exact opposite of the behavior of the
> data grid
> in the query tool (there double-clicking sizes the columns to
> the width
> of the data ignoring the header/column name width). i personally like
> neither behavior--it would be best if it got sized to a width that
> accomodates BOTH the header and the data width.

Both now size to the cell contents. I can't find a useful function to
get the correct label size, so something more complex would need to be
written for that.

> e. double clicking a column separator sizes the column back to the
> single row height -- sizing to the height of the tallest entry (if you
> have multi-line data in any of that row's cells) would probably be a
> more standard behavior.

Already works that way in trunk.

> f. when entering a new row of data and suing TAB to move
> between columns
> there is no per-cell validation (which happens when you press ENTER
> after each cell), so if you have messed up something (say, entered two
> characters in a char(1) field all your data entry gets wiped out once
> you have completed a row -- would be nice if you just got
> asked to edit
> your faulty entry rather than having to start from scratch again.
> actually it is not even clear the data is completely lost (maybe it is
> somewhere in the background, because clicking on the * row sometimes
> gives you errors about other fields that violate constraints, etc. --
> this is hard to fully describe in a few sentences).

There is still no per-column validation (I'm not sure that it would ever
be feasible as it would mean attempting inserts/updates when the user
hasn't finished entering data which may well throw errors for columns
they haven't got to yet). It does now retain all values after an error
has occurred.

> all for now. don't mean to be too critical/overwhelming, just thought
> i'd put down in writing what i saw.

No problem - I'd prefer to get things working well. Thanks to all those
who've tested the editor today and provided feedback.

Regards, Dave.