Обсуждение: edit grid: issues involving marking, selecting, inserting, undoing
Hi developers! Hi Dave! Testing RC2. Client Win XP, Server Debian Sarge, PostgreSQL 8.1.4. I think I have found more issues in the edit grid, which have some potential to damage things. Sorry to bring this up so close to release. I did not find it any earlier. Anyway, it is up to you what you fix, what you postpone and what you reject. Definition: I use the term "marked" for the field with the bold frame, which is edited when you start typing. I use the term "selected" for the field or range that is being highlighted. In the edit grid try the following: Copy a string. Mark a field of an existing tuple. Only mark it, do not click a second time to get into edit mode. Press <ctrl><v>. Popup warns me (my primary key is a serial field): "This table contains serial columns. Do you want to use the values in the clipboard for these columns?" Say YES. !! I wouldn't actually say YES, but if there was no sequence involved, we would not even get a warning. A NEW tuple is inserted at the end and the value is copied to the first field. !! <esc> does not help, "undo" button stays inactive. Looks like I am trapped. Actually, "undo" gets activated after I have entered edit mode in the field with the value in the newly inserted row. And I can get rid of the new row by pressing "undo". The "undo" feature even works _without_ entering the new field. Even though the button is inactive, <ctrl><z> will fire. !!! BUT if you do this, the "current" row (where the field is marked) gets deleted. (Or so it seems.) And this row has gone for good. No undoing the buggy "undo" ... (Actually, a reload shows that the row is still there, so the last part seems to be a display issue.) I think you get the idea .. Several issues are involved: # I think it is misleading to start a new tuple, while a field of an existing tuple is marked and I press <ctrl><v>. Rather, it should (enter edit mode and) replace the value of the marked field. I am not sure if pgAdmin is aware of the data structure in the clipboard. If it is, then it might act depending on the data in this case. If it is a record, do nothing, if it is simple data, insert it in the marked field. Or, if that causes problems, do nothing at all, rather. New tuples should only be inserted if the "new" tuple is marked. (Or more precisely, starting from the field that is being marked.) # When a new tuple is inserted, the "undo" button should be activated. Generally the "undo" feature is quirky: If I edit a field, the button gets active. If I leave the field, by clicking another field in the same row, the button stays active and I can click any number of times on it. It stays activated. Only the first click, however, has an effect: it reverts the changes. Button should fall back to inactive, after the feature has "run out of ammo". However, if I leave the field, by pressing <tab>, thus marking the next field in the same row, the button stays INACTIVE and clicking it has no effect. I can still press <ctrl><z> to revert my changes, though. Button should stay activated, regardless of _how_ I leave the field, as long as the changes can be undone. # Undoing the changes after inserting a new row (inadvertently or not) should not wipe out the wrong row (the one that holds the marked field) You might circumvent this problem if you automatically mark the (first?) field of a newly inserted row, but this fix would only go half the way. It would force a save if one was in the middle of editing another row. Rather, you should insert values or records only at the position of the marked field. I think much arises from the management of marked fields and selected ranges. Try this: Mark a field. Select a different row. Press <shift> and try to select a range of rows. Start of the range is (to my surprise) defined by the _marked_ field, not the _selected_ row. Or try this: Mark a field. Press <shift> and select another field, the whole area gets selected, _including_ the marked field. Now, start over, mark a field. Press <ctrl> and select another field (or a number of fields). The marked filed is _excluding_ from the selection. (Should be included.) Maybe, the general cure for most of the above mentioned symptoms would be to mark what you select and select what is marked (not: what you mark!). It would make things easier to manage - or that is what I assume, not actually knowing the code. If you look at OOo Calc for instance, the last field selected is always the one being marked. Sorry for the longish report. I have gone over it several times to try and avoid misunderstandings. After all, English is not my first language. Regards Erwin
Erwin Brandstetter wrote: > Hi developers! Hi Dave! > > Testing RC2. Client Win XP, Server Debian Sarge, PostgreSQL 8.1.4. > > I think I have found more issues in the edit grid, which have some > potential to damage things. <Snip comprehensive bug report> I've committed some changes which I think address most of the issues you mentioned. A bit of background on the copy/paste thing first though for info: - pgAdmin has no knowledge of the format of data on the clipboard - it simply checks that it is text that it can do something with. - The wxGrid control has both selections and a cursor. Selections are rows/columns/cells that are highlighted. The cursor is the cell with the thick border. These concepts can be a cause of confusion for us as well as end users unfortunately (long time list members will remember Andreas' hatred of the control). At the moment though, it's all we've got. - If you are in edit mode in a cell, a paste operation will insert the data into that cell where possible. - If you are not in edit mode, no matter where the cursor cell is, the paste operation will happen on the 'new' row at the bottom. The data will be split based on the Copy column seperator and quote character (see File -> Options -> Query), and the columns populated sequentially. If any column is a serial, the data in that positionwill be left blank if you choose. So, onto the changes I've made: 1) When a new row paste occurs, the cursor cell is moved to the position of each column as data is inserted, such that it will be on the last affected cell when the paste has completed. This ensures that any undo operation will happen on the correct row. 2) When the new row paste is completed, the Save and Undo options are enabled. 3) When an Undo has been performed, the Undo and Save buttons are disabled. I think it's all working as it should now apart fromt he know issue that things get marked dirty upon edit mode start, rather than when the data is actually changed. But that's much harder to fix as we already discussed. I'll send you an exe off list. > Sorry to bring this up so close to release. I did not find it any> earlier. Anyway, it is up to you what you fix, whatyou postpone and> what you reject. I'll fix what I can - but we are getting very close to release now so I will be much more critical about what is or isn't a showstopper - especially as I think they are becoming corner cases far more often. Thanks for the reports though, they are appreciated even if frustrating! Regards, Dave.
Hi Dave! dpage@postgresql.org wrote: <explanation snipped> Thanks for the insight. > > So, onto the changes I've made: > > 1) When a new row paste occurs, the cursor cell is moved to the > position of each column as data is inserted, such that it will be on > the last affected cell when the paste has completed. This ensures that > any undo operation will happen on the correct row. Undoing the wrong row is now out of the picture, I'll give you that. But I think it should be the other way round: the user should have to set the cursor _first_ and then insert at the marked position. The current order of events can be a trap for various reasons: If I am in the middle of editing a row and press <ctrl><v> then a number of things happen. (While editing a row, I am not necessarily in edit mode! Also, it happens to me on a regularly bassis that I press <ctrl><v> (inadvertantly) before having entered edit mode.) 1.) The row I am editing is being saved. That's not what I wanted when I pressed <ctrl><v>. Whether you force to save or to discard pending changes in the current row, data may be lost in either case. 2.) The curser goes to the end of the table, and out of sight if there are many rows. Inexperienced users will not know _at all_ what just happened. They most probably wanted to insert data into the marked field. 3.) If I click anywhere now (with the cursor out of sight), the new row will be saved - hopefully raising an error. Again, that is probably not what the user wanted. It would be more obvious (and solve all issues at hand) to insert data only starting from the position of the cursor. In case anything would be overwritten, you might issue a warning before proceeding. But that may be redundant as long as we don't leave the current row and can undo it all. Or, if you have to insert into a new row, the user should be warned before saving (or discarding) pending changes. And if the cursor jumps to the new row, so should the visible range of the window. > > 2) When the new row paste is completed, the Save and Undo options are > enabled. That seems to work fine now. > > 3) When an Undo has been performed, the Undo and Save buttons are > disabled. That seems to work, too. Although there is still a quirk: If I leave the edit mode by pressing <tab> and thus moving the cursor to the next field, the undo button will be incorrectly inactivated, while <ctrl><z> still works. > > I think it's all working as it should now apart fromt he know issue > that things get marked dirty upon edit mode start, rather than when > the data is actually changed. But that's much harder to fix as we > already discussed. I'll send you an exe off list. It may be noteworthy that the undo-feature correctly recognizes whether data has actually been changed (is only activated in these cases). Seems to operate independently? > > > Sorry to bring this up so close to release. I did not find it any > > earlier. Anyway, it is up to you what you fix, what you postpone and > > what you reject. > > I'll fix what I can - but we are getting very close to release now so > I will be much more critical about what is or isn't a showstopper - > especially as I think they are becoming corner cases far more often. > > Thanks for the reports though, they are appreciated even if frustrating! Sometimes you have to do unpleasant things if you care. ;) Regards Erwin
Hi developers! Hi Dave! Testing RC2, rev 5607:5610. Client Win XP, Server Debian Sarge, PostgreSQL 8.1.4. In the SQL dialogue window, if a view has a long line of code the vertical scrollbar will get it wrong. Trying to scroll to the right end ends halfway into the line. Same thing in the SQL pane in the main window. In case it matters: I am using the standard fonts out of the box (I think): ms shell dlg 2 windows-1252 under "Preferences" and courier new 11 under "Query" Regards Erwin
Erwin Brandstetter wrote: > Hi developers! Hi Dave! > > Testing RC2, rev 5607:5610. Client Win XP, Server Debian Sarge, > PostgreSQL 8.1.4. > > In the SQL dialogue window, if a view has a long line of code the > vertical scrollbar will get it wrong. > Trying to scroll to the right end ends halfway into the line. > > Same thing in the SQL pane in the main window. > > In case it matters: I am using the standard fonts out of the box (I think): > ms shell dlg 2 windows-1252 under "Preferences" and > courier new 11 under "Query" This is a known bug in the styled text control which we can't do anything about except wait for an upstream fix. Keyboard/cursor navigation should work fine. Regards, Dave
Erwin Brandstetter wrote: >> 1) When a new row paste occurs, the cursor cell is moved to the >> position of each column as data is inserted, such that it will be on >> the last affected cell when the paste has completed. This ensures that >> any undo operation will happen on the correct row. > > Undoing the wrong row is now out of the picture, I'll give you that. > But I think it should be the other way round: the user should have to > set the cursor _first_ and then insert at the marked position. The > current order of events can be a trap for various reasons: > ... > Or, if you have to insert into a new row, the user should be warned > before saving (or discarding) pending changes. And if the cursor jumps > to the new row, so should the visible range of the window. This is the change I've committed. You now get a "Save? Yes/No/Cancel" message. Changing the way the cursor works isn't really an option right now. >> 3) When an Undo has been performed, the Undo and Save buttons are >> disabled. > > That seems to work, too. Although there is still a quirk: If I leave the > edit mode by pressing <tab> and thus moving the cursor to the next > field, the undo button will be incorrectly inactivated, while <ctrl><z> > still works. Also fixed. > It may be noteworthy that the undo-feature correctly recognizes whether > data has actually been changed (is only activated in these cases). Seems > to operate independently? Well the button is activated at the same time, but the underlying data structure (sqlTable) keeps track of the old/new values and thus ensures that the undo actually does the right thing. To fix things properly (for the next release), I need to conditionally activate the buttons based on whether or not the sqlTable reports a data change in the row (which it currently can't do). Cheers, Dave.