Re: pgAdmin 1.4.3 bug with delete button in win32 & OTHER - Mailing list pgadmin-support

> > also as described by heiko selber the data edit
> > functionality seems to
> > be completely non-working.
>
> *Completely non-working*? You mean you cannot edit data and save it
> even if you don't hit the delete key? You cannot delete rows by
> selecting the row and using the delete key or button?

sorry, i should have tried more scenarios and been more specific. i
don't use this part of the application at all, so don't have much by way
of volume of observations. here's what i see:

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.

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.

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.

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.

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


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).

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.

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.

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.

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.

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).

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

george