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

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.
The first column gets same label in both queries
("?column?\nunknown"). The original code behaves identically.

DK> Note: Yours 1st patch is working fine with the above case.
Due to my inadvertence it didn't honour previously saved sizes at all.

Here is another idea:
Do save the sizes only for those columns which were explicitly
resized by the user. Every user's resize results in new (or update to
existing) element in some associative array, whose key is composed of
colIndex and colLabel, and value is user-specified size. Elements
never get deleted out of this array for the life of Query window.
When displaying new result set, each column is inspected, if it's
index and label have corresponding element in array, it's size is
restored. Else it falls under automatic sizing.
Good points here:
0. Automatic sizing works by default for every result set - so is
responsive (unlike last patch!) to changes in query results where
labels don't change - that's a very frequent case.
1. Can save and restore user-specified sizes for columns in several
_different_ queries (run in the same window in arbitary order).
2. Undesired sizing artefacts may appear in rare cases where user has
manually resized the column AND later he got column with same label
and in same position but of positively improper size (your last case
is about it). This still can be overcome by introducing restrictions
on applying saved sizes ("if saved and auto sizes differ more than n
times, discard the saved one / resize to something between / etc").

I'll try to implement this approach soon.
Opinions are welcome!

Wednesday, November 20, 2013, 12:16:31 PM, you wrote:

DK> Hello,

DK> Thanks for fixing this case as per my previous comments.

DK> Could you also check one more case with the latest submitted patch.

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> Note: Yours 1st patch is working fine with the above case.

DK> Thanks for your time and excellent support.

DK> Dinesh

DK> -- 
DK> Dinesh Kumar
DK> Software Engineer

DK> Ph: +918087463317

DK> Skype ID: dinesh.kumar432

DK> www.enterprisedb.com

DK> Follow us on Twitter
DK> @EnterpriseDB 

DK> Visit EnterpriseDB for tutorials, webinars, whitepapers and more

DK> On Wed, Nov 20, 2013 at 12:06 PM, Dinesh Kumar
DK> <dinesh(dot)kumar(at)enterprisedb(dot)com> wrote:
DK> Thanks for fixing.

DK> Let me look into this.

DK> Dinesh

DK> -- 
DK> Dinesh Kumar
DK> Software Engineer

DK> Ph: +918087463317

DK> Skype ID: dinesh.kumar432

DK> www.enterprisedb.com

DK> Follow us on Twitter
DK> @EnterpriseDB 

DK> Visit EnterpriseDB for tutorials, webinars, whitepapers and more

DK> On Tue, Nov 19, 2013 at 10:49 PM, J.F. Oster <jinfroster(at)mail(dot)ru> wrote:
DK> Hello Dinesh,

DK>> Could you check the following thing in your development machine.
>>>> After applying your patch, i am not able to re-size the grid
>>>> columns in windows 7 (64-bit) machine.

DK> That possibly was a wide column that didn't want to shorten?
DK> Ok, I changed AutoSizeColumns(bool setAsMin = true) to false.

DP>> please check it retains the column sizes following refresh if the
DP>> user has customised them,
DK> I missed this, but now it should work as it did before.

DP>> I would suggest that a column should never take up more than 50%
DP>> of the visible space, unless that space would otherwise be unused
DK> That's exactly what is done :)

DK> Please see the modified patch attached.
DK> Thanks.

DK> Tuesday, November 19, 2013, 4:35:05 PM, you wrote:

DK>> On Tue, Nov 19, 2013 at 2:38 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
DK>> Dinesh, can you review this please? In particular, please check it
DK>> retains the column sizes following refresh if the user has customised
DK>> them, and that it puts a limit on the size of very long columns so the
DK>> user doesn't potentially end up with extremely wide columns that
DK>> require excessive scrolling (I would suggest that a column should
DK>> never take up more than 50% of the visible space, unless that space
DK>> would otherwise be unused (e.g. you have 1 very narrow column, and one
DK>> large).

DK>> Thanks.

DK>> On Sun, Nov 17, 2013 at 6:41 PM, J.F. Oster <jinfroster(at)mail(dot)ru> wrote:
>>> Hi All,
>>>
>>> Please see the attached patch.
>>> It makes use of wxGrid's AutoSizeColumns() and applies some reasonable
>>> limits afterwards. Works nicely in most scenarios I could imagine.
>>> Tested with wxWidgets 2.8.12 on Ubuntu Linux.
>>>
>>> Possibly this code should be moved to some procedure and triggered
>>> from on-resize event handler as well?
>>> Also it would be nice to have same behavior in "Edit Data" window
>>> (ctlSQLEditGrid). But I'm new to wxWidgets... so please let me know
>>> how to implement that better.
>>> Thanks!
>>>
>>>
>>> P.S. My company is moving from Oracle and a perfect IDE called "PL/SQL
>>> Developer" (by allroundautomations.com) to PostgreSQL and pgAdmin III.
>>> Having used pgAdmin years before, I see it gaining functionality to
>>> support fast-growing PostgreSQL's features (great job!) but not
>>> usability that well. Hope I can work on that (as far as I can :))

--
Best regards,
Vadim