Hi,
On Mon, Dec 2, 2013 at 11:21 PM, J.F. Oster <[email protected]> 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. > > ==>>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. > > Ok, now in AutoSizeColumns() I save max column sizes to colMaxSizes > 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* size = GetBestSize(row, col); 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 <[email protected]> > 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
