Re: PATCH: Choose best width for Data Output columns of Query tool - Mailing list pgadmin-hackers
| From | Dinesh Kumar |
|---|---|
| Subject | Re: PATCH: Choose best width for Data Output columns of Query tool |
| Date | |
| Msg-id | CAKWsr7jTQPmhoMW1VZPZObU-ZFKTR62AHgmpY3dfveASxKxreQ@mail.gmail.com Whole thread Raw |
| In response to | Re: PATCH: Choose best width for Data Output columns of Query tool ("J.F. Oster" <jinfroster@mail.ru>) |
| Responses |
Re: PATCH: Choose best width for Data Output columns of Query tool
("J.F. Oster" <jinfroster@mail.ru>)
|
| List | pgadmin-hackers |
Hi,
On Mon, Dec 2, 2013 at 11:21 PM, J.F. Oster <jinfroster@mail.ru> wrote:
Hello Dinesh,
Monday, December 2, 2013, 4:30:18 PM, you wrote:
DK> Are you saying like double click on column header while
DK> holding "CTRL" in keyboard. If so, in mac i have tried it with
DK> "control" and "command" buttons, which is not working.
Yes. I'm not familiar with Mac... but some googling gave this:
>Use CmdDown if you want to test for either the Meta key (on Mac OS X)
>or the Control key (other platforms)
So changed it to event.CmdDown().
By the way, event.ControlDown() is used in ctlSQLGrid::OnMouseWheel()
to adjust font size - I assume it also needs to be changed.
Thanks for this. Could you change this like "event.CmdDown() || event.CtrlDown()" for supporting both Mac, as well non-mac keyboards.
DK> 1. Use wxRound() rather than round(). We don't have round() in windows. :(
DK> Or use an integer value for pointing rows.
Oops. I'll use wxRound(). Float is there intentionally to achieve
irregular loop step.
Thank You.
DK> 2. Could you implement the same as below if possible. Since,
DK> while performing double click on a column, i am getting noticeable
DK> delay.Ok, now in AutoSizeColumns() I save max column sizes to colMaxSizes
==>>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.
array which will be used in AutoSizeColumn() and OnLabelDoubleClick()
without looping through rows again.
Please see the fixed patch attached.
Thank You.
I believe, the column size should not exceed to the half of the available screen. But in this patch, the column size grows to end of the screen.
Ex:-
SELECT 'Big column.........', 1;
And also suggesting to change the AutoColumns() function like below.
From
row = wxRound(r);
wxGridCellAttr *attr = GetCellAttr(row, col);
wxGridCellRenderer *renderer = attr->GetRenderer(this, row, col);
if( renderer )
{
wxSize size = renderer->GetBestSize(*this, *attr, dc, row, col);
if( size.x > newSize )
newSize = size.x;
renderer->DecRef();
}
attr->DecRef();
TO
if
( size.x > newSize )
newSize = size.x;
Thanks in advance.
Regards,
Dinesh
--
DK> 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.
Best regards,
Vadim
pgadmin-hackers by date: