Re: pgAdmin 1.4.3 bug with delete button in win32 & OTHER - Mailing list pgadmin-support
From | George Pavlov |
---|---|
Subject | Re: pgAdmin 1.4.3 bug with delete button in win32 & OTHER |
Date | |
Msg-id | 8C5B026B51B6854CBE88121DBF097A86332E31@ehost010-33.exch010.intermedia.net Whole thread Raw |
In response to | Re: pgAdmin 1.4.3 bug with delete button in win32 & OTHER ("George Pavlov" <gpavlov@mynewplace.com>) |
List | pgadmin-support |
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@postgresql.org > [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of > George Pavlov > Sent: Thursday, August 03, 2006 11:47 AM > To: pgadmin-support@postgresql.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 >
pgadmin-support by date: