Обсуждение: A couple of quirks in the edit grid
Hi developers! Hi Dave! Testing bet4, rev. 5567:5572 on Win XP I found a couple of quirks in the edit grid. - If I mark part of the text in a field and press <del> only first character of the marked text gets deleted. One would expect all of the marked text to be deleted. (That's what happens if I press the <back> key) - Boolean field: Cycling through the values by hitting <space> starts the cycles differently from clicking with the mouse. The regular cycle is FALSE - TRUE - NULL. Mouse click follows that order at all times. But <space> doesn't at the start, which is confusing. If the field is TRUE, it goes to FALSE first, then starts the cycle. If it is NULL, it goes to TRUE first, then starts the regular cycle. If it is FALSE, it works as expected. - Boolean field: If I edit a boolean field, then switch the focus to another application and switch back, the field is still highlighted, the value has changed back to text (from the little box icon) and keystrokes are being ignored. <Esc> doesn not help. Nothing happens until I click with the mouse. Does not happen with text or integer fields. - If I mark a field (to copy the text) without changing anything, then hit <Esc> to unselect again, the edit grid still (incorrectly) tells me, that .. "There is unsaved data in a row Do you want to store to the database?" - <tab> key jumps to next column in the edit grid. It stops at the last column. Other spreadsheet-applications would keep going and jump to the first column of the next row. (But maybe that is by design?) Regards Erwin
Erwin Brandstetter wrote: > Hi developers! Hi Dave! > > Testing bet4, rev. 5567:5572 on Win XP > I found a couple of quirks in the edit grid. > > - If I mark part of the text in a field and press <del> only first > character of the marked text gets deleted. One would expect all of the > marked text to be deleted. (That's what happens if I press the <back> key) Fixed in SVN. > - Boolean field: Cycling through the values by hitting <space> starts > the cycles differently from clicking with the mouse. > The regular cycle is FALSE - TRUE - NULL. Mouse click follows that order > at all times. But <space> doesn't at the start, which is confusing. > If the field is TRUE, it goes to FALSE first, then starts the cycle. > If it is NULL, it goes to TRUE first, then starts the regular cycle. > If it is FALSE, it works as expected. They're actually doing different things the way you have tested. The mouse works in one of two ways: 1) It begins an edit on the field, then cycles through the values allowed by the underlying checkbox control. The new value is set when the cell loses focus. This occurs when you click directly on the checkbox. 2) It begins an edit on the field, cycles to the next value, and stores the value, returning the cell to the text value The space bar works per 1). This behaviour is somewhat difficult to change in a sensible way, and is not something I'm going to try to fix this close to release, if at all. > - Boolean field: If I edit a boolean field, then switch the focus to > another application and switch back, the field is still highlighted, the > value has changed back to text (from the little box icon) and keystrokes > are being ignored. <Esc> doesn not help. Nothing happens until I click > with the mouse. Does not happen with text or integer fields. Either Windows or wxWidgets is not causing the appropriate event to fire when the keypress re-occurs on the cell. I don't know how this can be fixed unfortunately. > - If I mark a field (to copy the text) without changing anything, then > hit <Esc> to unselect again, the edit grid still (incorrectly) tells me, > that .. > "There is unsaved data in a row> Do you want to store to the database?" Data is currently flagged as dirty as soon as an edit on a cell begins, not when the data is first changed. This behaviour is also somewhat difficult to change in a sensible way (though less so than your second issue), and is not something I'm going to try to fix this close to release. > - <tab> key jumps to next column in the edit grid. It stops at the last > column. Other spreadsheet-applications would keep going and jump to the > first column of the next row. (But maybe that is by design?) By design of the wxGrid control, yes. Thanks, Dave.
I think Dave fixed one of the cases that caused this a few revs ago, but another one still remains. Steps to reproduce: In pgAdmin 1.4.2: * connect to a configured DB running on a networked machine * open query * issue a query * observe result set * disconnect your network connection (plug out and back in your cable, e.g.) * issue the query again * get meaningful error message: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processingthe request. In pgAdmin 1.6 RC1 (5574M): * repeat the exact same steps as above * get message ":" (just a colon) in the message window George
Shouldn't it be fairly easy to make pgAdmin reconnect do servers it has lost its connection to? After all it has all the connection information (assuming password is saved) and could try to re-establish it? I personally use a laptop and often switch connections (wired LANs, wifi, cellular broadband) and find it a major drag having to reestablish all connections: go through all the dialogs for broken connections, close and reopen all query windows (I often have about half a dozen going), making sure unsaved ones are taken care of, reopen all query files (or cut and paste from "dead" windows, etc.) Thanks! George
George Pavlov wrote: > I think Dave fixed one of the cases that caused this a few revs ago, but > another one still remains. Steps to reproduce: Actually, I didn't. Harald reported it once at the end of a very long query, but I couldn't reproduce. I think you've found the cause. > In pgAdmin 1.6 RC1 (5574M): > > * repeat the exact same steps as above > * get message ":" (just a colon) in the message window Thanks, fixed in SVN. Regards, Dave
George Pavlov wrote: > Shouldn't it be fairly easy to make pgAdmin reconnect do servers it has > lost its connection to? After all it has all the connection information > (assuming password is saved) and could try to re-establish it? In theory it should be easy to try to reconnect - I'll add it to the todo list. Regards, Dave
dpage@postgresql.org wrote: > Erwin Brandstetter wrote: >> Hi developers! Hi Dave! >> >> Testing bet4, rev. 5567:5572 on Win XP >> I found a couple of quirks in the edit grid. >> >> - If I mark part of the text in a field and press <del> only first >> character of the marked text gets deleted. One would expect all of >> the marked text to be deleted. (That's what happens if I press the >> <back> key) > > Fixed in SVN. In RC1, the problem seems to be present still. <DEL> only deletes the first character of the marked text. Regards Erwin
Erwin Brandstetter wrote: > dpage@postgresql.org wrote: >> Erwin Brandstetter wrote: >>> Hi developers! Hi Dave! >>> >>> Testing bet4, rev. 5567:5572 on Win XP >>> I found a couple of quirks in the edit grid. >>> >>> - If I mark part of the text in a field and press <del> only first >>> character of the marked text gets deleted. One would expect all of >>> the marked text to be deleted. (That's what happens if I press the >>> <back> key) >> >> Fixed in SVN. > > In RC1, the problem seems to be present still. <DEL> only deletes the > first character of the marked text. RC1 was rev 5577, the delete fix was rev 5579. http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=5577&view=rev http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=5579&view=rev :-) Regards, Dave.
Hi developers! Hi Dave! Testing RC1. Client is Win XP. Server is Debian Sarge. I have come across a peculiar effect while editing boolean fields. With other fields, if you want to discard your changes while editing a field, you hit <esc> and the original value is back (as long as you haven't saved yet). Not so with boolean fields. Pressing <esc> leaves yields seemingly random results. One of the most peculiar show cases: I click with the mouse. Value is TRUE. 1st click only sets the focus. 2nd click --> NULL 3rd click --> FALSE 4th click --> TRUE (again) If I hit <esc> now, I end up with FALSE (!). That wouldn't be by design, would it? Regards Erwin
Erwin Brandstetter wrote: > Hi developers! Hi Dave! > > Testing RC1. Client is Win XP. Server is Debian Sarge. > > I have come across a peculiar effect while editing boolean fields. With > other fields, if you want to discard your changes while editing a field, > you hit <esc> and the original value is back (as long as you haven't > saved yet). Not so with boolean fields. Pressing <esc> leaves yields > seemingly random results. > One of the most peculiar show cases: > I click with the mouse. Value is TRUE. > 1st click only sets the focus. > 2nd click --> NULL > 3rd click --> FALSE > 4th click --> TRUE (again) > If I hit <esc> now, I end up with FALSE (!). That wouldn't be by design, > would it? Probably not :-). I've committed a change which modifies the behaviour such that simply clicking on the cell no longer cycles the value - it now just displays the checkbox which must be explicitly clicked to change the value. <ESC> now seems to do what is required, and I believe this also has the side effect of curing the other inconsistency you reported previously. Thanks, Dave.
dpage@postgresql.org wrote: > Erwin Brandstetter wrote: >> (...) >> If I hit <esc> now, I end up with FALSE (!). That wouldn't be by >> design, would it? > > Probably not :-). I've committed a change which modifies the behaviour > such that simply clicking on the cell no longer cycles the value - it > now just displays the checkbox which must be explicitly clicked to > change the value. <ESC> now seems to do what is required, and I > believe this also has the side effect of curing the other > inconsistency you reported previously. I have checked out RC2 and the problem with <esc> seems to be gone. Nice! About the previously reported issue: the mouse sticks to the regular cycle (FALSE-TRUE-NULL) at all times, while <space> starts off irregularly, before following the same sequence. This issue is not as important IMO. It is, however, still there. Regards Erwin