Re: PATCH: Choose best width for Data Output columns of Query tool - Mailing list pgadmin-hackers

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.

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.




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@mail.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