Hi,
On Wed, Nov 20, 2013 at 11:02 PM, J.F. Oster <[email protected]> wrote: > 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! > > This is a good approach. But i am worrying about the performance. For Ex:- What if the query is having two many columns in a table, which will be storing in a Hash/Assoc array, following by a SELECT query with a single column. @Dave, Could you share your inputs on this please. Thanks, Dinesh > > > > 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> <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 > >
