> -----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.
> 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.
> 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).
That's really down to the grid control. It will no longer prompt you
> 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
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
> 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.
In response to
pgadmin-support by date
|Next:||From: Benjamin Krajmalnik||Date: 2006-08-04 18:09:55|
|Subject: Error installing instrumentation functins on FreeBSD 6.1|
|Previous:||From: George Pavlov||Date: 2006-08-03 18:51:41|
|Subject: Re: pgAdmin 1.4.3 bug with delete button in win32 & OTHER|