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

ERRATA: substitute ROW for COLUMN in (e):

e. double clicking a ROW separator sizes the ROW 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.

> -----Original Message-----
> From: pgadmin-support-owner(at)postgresql(dot)org
> [mailto:pgadmin-support-owner(at)postgresql(dot)org] On Behalf Of
> George Pavlov
> Sent: Thursday, August 03, 2006 11:47 AM
> To: pgadmin-support(at)postgresql(dot)org
> Subject: Re: [pgadmin-support] pgAdmin 1.4.3 bug with delete
> button in win32 & OTHER
>
> > > 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
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>