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: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 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
> 

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq

Reply via email to