wxWidgets 2.9 support

Bugs to fix:

Execute plugin error 1. open pgadmin 2. click menu item "execute the last used plugin" 3. error below

Strange character in Table Properties 1. open pgadmin 2. drill down and right click a table name, click on properties 3. click the 'columns' tab 4. columns are listed. Window shows: ['Column name','Definition','Inherited from table'] data for my columns appear in the first two but the inherited from is blank since it is not inherited from anything. Dotted box appears around the three columns so this is a group. 5. however there appears to be an untitled ghost 4th column since there is a text numeric character (I have seen 2,3) to the right of the third column.

Window behaviour parenthesis matching With regard to the bad window behaviour I am seeing on OpenSUSE 12.1 in the query builder regarding parenthesis matching, I had an idea it might be related to some configuration such as user preferences. So far I have not found anything that influences the situation. Using Gnome 3. Desktop effects are disabled since attempting to switch them on results in immediate but controlled system crash. This is widely reported as an issue for Gnome3. I have tried tweaking Qt configuration schemas but nothing has an effect. I have tried a user session in ICEwm and get the same behaviour. This should have eliminated a large number of the configuration possibilities. If anyone has an idea what settings might influence text editing window behaviour it would be interesting to know.

Cut and paste 1. open database, drill down to table, select show data from context menu 2. select a record with some text fields. Highlight one entry so that it goes into editing mode 3. right click to get editing context menu and select copy 4. now select another record and highlight the same field to go into edit mode 5. context menu shows Paste active, but clicking on it does not paste anything; no error. 6. Ctrl+v successfully pastes the contents of the buffer.

Constraint column missing from properties? If I create a table and later add a primary key or unique index to the table the process works fine. However if I subsequently go in and view the properties for the index constraint and look under the columns tab, the column that the constraint refers to is not listed. This seems a bit strange but it might be deliberate to avoid mistaken deletes, etc. If it sounds like an error I can post detailed process to arrive at the situation. Fixed (but not yet commited).

In this version the editor window issue continues. Try to edit a ( in multi-line sql and the window port blanks. New additional detail: slide mouse up to right to the small down arrow that offers a dropdown box with choice editor/graphical design. Just rolling the mouse over that little button redraws the window port.

When using large table (happens with 20K records), right click table in browser window, choose view all data. Table has PK. Select a record in the middle of the listing and click to edit contents of a column in viewport. Viewport immediately navigates away from the record to be edited, either up or down and by several hundred records. It is very difficult to readjust the viewport using sliders to find the editing box. Using keyboard (up down left right arrows) to try to relocate it does not work. Solution is to subset the records to a much smaller number.

Fri, 08 Jun 2012 03:57:50 -0400

I previously reported mixed results regarding the issue of the viewport losing focus in long tables. Specifically, viewing all data in a long table, select a field for editing, and the record being edited disappears from the viewport.

I think I may have more of a pattern.

1. open the table for editing 2. drag the vertical slider to somewhere in the middle of the dataset 3. attempt to edit a record by double click in field/column 4. focus (place in the table) remains on the correct record 5. *without moving the vertical slider*, select a different record in the viewport for editing, focus remains on the correct record 6. now use the vertical slider (or up/down arrows) to change to a different place in the table 7. select a record for editing, focus (place in the table) is lost. 8. close window, reopen, use slider to go to the same position as in 6, focus remains correct until vertical slider moved the second time.

Perhaps a variable initialization issue? The first time I move the vertical slider it knows where it was, at the beginning. But on second slide it either does not know where it was or where the new location is.

You can move around in the table viewing data using the slider without problem. The issue only starts once you go into editing mode on a column.

Workaround is simple, use filtered records or just close/reopen the editing window and just use the vertical slider once.

Colin, 2012-07-13 This is not an error, just a suggestion for improved interaction.

When viewing data from a table or view, begin by selecting all data. Then click on the funnel icon to get the dialog that allows you to enter a sorting order or a filter. Pops up no problem.

Now, the issue is that when it pops up it obscures important information that you might need for the sort or filter. It appears to very effectively cover not only the existing data (not much of an issue, since you are about to change that), but also a whole chunk of the field names which you will need for typing into the dialog box.

Thinking that all you have to do is move the dialog box to reveal the field names, you find that dragging the dialog box drags the parent window with it. Objective defeated.

Ok so you think, no problem, I will get the field names from the SQL pane on the main pgadmin window which contains the create ... instructions with the field names. But here, while the main window is selectable, the vertical and horizontal sliders are non-functional until the dialog box in the child is dismissed.

So the only way so far is to cancel the dialog, gather all the info, and start the dialog over again.

I guess there are a number of ways of dealing with this, including making the field names available inside the child's dialog box (provided in the sort dialog but not the filter). But the simplest would appear to be, if possible, make the dialog box draggable independently of the parent to reveal the field names and types.