Re: PATCH: Choose best width for Data Output columns of Query tool

Hi ,

On Thu, Nov 28, 2013 at 11:05 PM, J.F. Oster <jinfroster(at)mail(dot)ru> wrote:

> Hello Dinesh,
>
> Please have a look at this version.
>
> At first I've done it all as planned. Then I wanted a user to be able
> to remove a column from array (switch back to auto-sizing). Clicking
> on column's label seems good way to achieve that. And then I came
> across ctlSQLGrid::OnLabelDoubleClick, which implements some column's
> sizing for ctlSQLResult and ctlSQLEditGrid. As I was planning
> auto-sizing feature for both "Query tool" and "Edit data" windows, I
> decided to move new code into ctlSQLGrid and do it all at once.
>
> Double-clicking a column's label with Ctrl pressed switches a
> column back to auto-sizing. Without Ctrl the behavior is same as
> before (toggling between several predefined scales?) + saving them to
> array as manually specified.
>
> *Question:*
Are you saying like double click on column header while holding "*CTRL" *in
keyboard. If so, in mac i have tried it with "control" and "command"
buttons, which is not working.

Explain command's raw output column is also auto-sized now, I hope
> it will be better than before on small screens.
>
> Also I've noticed a slowdown in wxGrid::AutoSizeColumns() with large
> result sets, and implemented it with some "optimization", see comments
> in ctlSQLGrid::AutoSizeColumns().
>
> Everything turned out fine except a problem in
> frmEditGrid::Go() (frmEditGrid.cpp:1468)
> sqlGrid->SetSize(10, 10);
> This hack makes auto-sizing choose very small widths.
> I couldn't see any changes with it commented out (Linux). Is it still
> required? If yes,
> it's comment says:
> > later, we will resize the grid's parent to force the correct size
> I could call sqlGrid->AutoSizeColumns() after, but didn't find
> the place where that resizing is done.
>
>
Sorry for the delay on revising this patch. I have tested and looked into
the patch and it's working as expected :).
However, i do have some concerns on this patch, which i would like to share
with you.

1. Use wxRound() rather than round(). We don't have round() in windows. :(
Or use an integer value for pointing rows.

2. Could you implement the same as below if possible. Since, while
performing double click on a column, i am getting noticeable delay.

==>While creating the grid it self, store each fields max length in a
custom variable.

==>Do AutoSizeColumns() Based on this max length, column header length.

In the current implementation, we are re-visiting each row for getting the
BestSize of a cell in each column. If we have so many rows with so many
columns, then it will take sometime to render these cell values.

Thanks for your support to pgAdmin. :)

Regards,
Dinesh

>
>
> Thursday, November 21, 2013, 12:03:04 PM, you wrote:
>
> DK> Hi,
>
>
> DK> On Wed, Nov 20, 2013 at 11:02 PM, J.F. Oster <jinfroster(at)mail(dot)ru>
> wrote:
> DK> Hello Dinesh,
>
> DK>> Do
> SELECT '1', 'f'; ==>>> And then re-size the 1st
>
> SELECT '1', 'f'; ==>>> column to the end of the screen.
> DK>> Then do,
> DK>> SELECT 'f', '111111......Wide column' ==> This should re-size
> DK>> the grid as per the query result, which is not happening currently
> DK>> in my windows machine.
> DK> The first column gets same label in both queries
> DK> ("?column?\nunknown"). The original code behaves identically.
>
> DK>> Note: Yours 1st patch is working fine with the above case.
> DK> Due to my inadvertence it didn't honour previously saved sizes at all.
>
> DK> Here is another idea:
> DK> Do save the sizes only for those columns which were explicitly
> DK> resized by the user. Every user's resize results in new (or update to
> DK> existing) element in some associative array, whose key is composed of
> DK> colIndex and colLabel, and value is user-specified size. Elements
> DK> never get deleted out of this array for the life of Query window.
> DK> When displaying new result set, each column is inspected, if it's
> DK> index and label have corresponding element in array, it's size is
> DK> restored. Else it falls under automatic sizing.
> DK> Good points here:
> DK> 0. Automatic sizing works by default for every result set - so is
> DK> responsive (unlike last patch!) to changes in query results where
> DK> labels don't change - that's a very frequent case.
> DK> 1. Can save and restore user-specified sizes for columns in several
> DK> _different_ queries (run in the same window in arbitary order).
> DK> 2. Undesired sizing artefacts may appear in rare cases where user has
> DK> manually resized the column AND later he got column with same label
> DK> and in same position but of positively improper size (your last case
> DK> is about it). This still can be overcome by introducing restrictions
> DK> on applying saved sizes ("if saved and auto sizes differ more than n
> DK> times, discard the saved one / resize to something between / etc").
>
> DK> I'll try to implement this approach soon.
> DK> Opinions are welcome!
>
>
>
>
>
> DK> This is a good approach. But i am worrying about the performance.
>
> DK> For Ex:-
> DK> What if the query is having two many columns in a table,
> DK> which will be storing in a Hash/Assoc array, following by a SELECT
> DK> query with a single column.
>
>
> DK> @Dave,
>
>
> DK> Could you share your inputs on this please.
>
>
> DK> Thanks,
> DK> Dinesh
>
>
>
> --
> Best regards,
> Vadim