SQL Power Software Forum

Hi,

Here are a few bugs I noticed while playing around with this build: 0.9.8-20090817222009

- The properties panel is 'too' shrinkable (need to set minimum height & width)
- In the demo query 'highly rated actors', when I drag in the director table, it brings up the cross join warning box when it shouldn't (or maybe I'm wrong..).
- Tables overlap based on the order with which they entered the playpen. If a table is selected, shouldn't it be moved to the absolute foreground?
- The cross join warning is given for every column when the select all/none is checked/unchecked, instead of just once for the whole table.
- When I fill in the 'where' column filter field with a bunch of stuff (expand the column), then I delete the filter, the space remains large and empty rather than retruning to its original size.
- Related to the point above: When that where filter column (in a table) expands, shouldn't the entire column width be selectable for the next (empty) row (rather than just the far left corner of the cell)?

Regards,
Steve

Hi Steve,

The properties panel is 'too' shrinkable (need to set minimum height & width)

Which properties panel are you talking about?

In the demo query 'highly rated actors', when I drag in the director table, it brings up the cross join warning box when it shouldn't (or maybe I'm wrong..)

You are correct. Reopened bug 2020 with this problem.

Tables overlap based on the order with which they entered the playpen. If a table is selected, shouldn't it be moved to the absolute foreground?

Threw in a fix for this just now. You can try it out in the latest build.

The cross join warning is given for every column when the select all/none is checked/unchecked, instead of just once for the whole table.

Added this to bug 2020 as well.

When I fill in the 'where' column filter field with a bunch of stuff (expand the column), then I delete the filter, the space remains large and empty rather than retruning to its original size.
Related to the point above: When that where filter column (in a table) expands, shouldn't the entire column width be selectable for the next (empty) row (rather than just the far left corner of the cell)?

Yes, these are both issues that should be addressed. I've created bug 2115 to track this issue.

Thanks for the feedback,

Thomas

Thomas wrote:

The properties panel is 'too' shrinkable (need to set minimum height & width)

Which properties panel are you talking about?

Thanks for the response, Thomas. I'm referring to the properties button in the QueryPen and SQL editor, with the 'always if query contains cross joins' checkbox.

Steve

Hi Steve,

I've created a bug for this, bug 2119 so you can track the progress of this issue.

Thomas

Here are a few (minor) bugs:

- When I highlight a query (single click, left window) and hit the delete button, shouldn't the query be deleted? (maybe with a confirm box - or not)
- The only way to rename queries is by right-click -> rename, instead of a slow double click, or whatever.
- When I create two new relational queries one after the other, shouldn't the second one be named differently than the first by default? (e.g. New Relational Query(1), or whatever). The same goes for copy query. Related to this, shouldn't user defined identically named queries be prevented?

Steve

Hi Steve,

When I highlight a query (single click, left window) and hit the delete button, shouldn't the query be deleted? (maybe with a confirm box - or not)

I've added bug 2127 to add the delete shortcut keys to the workspace tree. For everything except reports I am receiving a confirmation dialog to delete the object. If you are not seeing the dialog then this is a bug and we should fix it. I've added bug 2128 to add a similar confirm dialog for reports.

The only way to rename queries is by right-click -> rename, instead of a slow double click, or whatever.

In Wabit 0.9.8 we are changing the left tree to be a drag source which means you will be able to drag objects from the left to the current editor. This change also means you now double click on an object in the tree to change editors. If we left the single click to change editors the editor would change every time you tried to drag from the left tree. So, now that the editor is changed by double clicking on an object in the tree it would be confusing if it also edited the name of the object. At current we have the right click and rename to change the name of the query. We also have the suggestion from irnbru in bug 2088 to add a properties tab to each object's editor. With a properties tab you would then be able to edit the queries name from there. Finally we have bug 2002 which will prompt users to save when they change editors and if the object is new it will prompt for name for the new object.

When I create two new relational queries one after the other, shouldn't the second one be named differently than the first by default? (e.g. New Relational Query(1), or whatever). The same goes for copy query. Related to this, shouldn't user defined identically named queries be prevented?

Bug 2002 should fix the problem where new objects have the same name and that they can be given a currently existing name. I've added bug 2126 to create a prompt for a new object name when copying an object in the left tree. Then if you copy the same object multiple times you can give each copy a unique name.

Thanks for the feedback,

Thomas