[Kmymoney-devel] Re: Review Request: Allow the resizing of the table in the csv importer plugin

[allan]

On 13/01/11 08:30, Cristian Oneț wrote:
> On Thu, Jan 13, 2011 at 2:20 AM, allan<agander93 at gmail.com>  wrote:
>> On 12/01/11 05:51, Cristian OneÈ› wrote:
>>> On Tuesday 11 January 2011 20:22:36 allan wrote:
>>>> Just a query about this patch of yours. Â Is it the intent that when a
>>>> file is loaded into the UI, it should all be viewable by scrolling, but
>>>> without resizing?
>>> The main objective was to have the columns show all the content and the user
>>> could scroll or make the dialog larger to see all the content. If the columns
>>> are not sized to content correctly then that should be fixed.
>> Hi Cristian
>>
>> This is a rambling one, I'm afraid. Skip to the last paragraph or two if
>> you don't want the full gory details.
>>
>> I've spent several hours on this, without being able to achieve what you
>> wanted.
>>
>> The problem, so far as I have seen it, is that in one particular file,
>> just one line does not initially display fully. The last column should
>> display '(20,000.00)', but the '00)'is replaced by ellipsis.
>>
>> Â From the UI, clicking anywhere on the column headers causes a redraw,
>> which results in the column showing correctly. Or, alternatively, a
>> slight resize of the form width achieves the same result.
>>
>> I have tried making the form larger, numerous variations of
>> resizecolumns to contents and other settings. I was even thinking I
>> might have to revert to calculating the screen width, but you wouldn't
>> have been happy with that!
>>
>> There were only two ways in which I could get that column to display
>> fully. The first way, whilst showing the last column fully, initially
>> showed the whole table as filled with the first column, but a scroll-bar
>> scroll followed by a single '>' scroll (or vice-versa) showed the final
>> column correctly.
>>
>> The last way, I removed your
>> 'tableWidget->horizontalHeader()->setResizeMode(QHeaderView::ResizeToContents);'
>> from csvimporterdlg.cpp. This correctly showed the last column fully,
>> but all other columns were at default width, but individually resizeable
>> to show their full contents.
>>
>> I'm happy with this arrangement. I don't need to see each and every
>> character in every column, but I know I can resize any column I may need
>> to see in full.
>>
>> Unless you can think of an alternative, then that's the way it seems for
>> now. If you want to explore I'll send you a file to use....(Breaking off).
>>
>> Erm.... It's turned out to be a bit less straight forward than that.
>> I've tried to produce a simple test file. (The data is not mine, and
>> private.) Just that single line worked correctly, nothing missing and
>> column data fully visible. I tried adding back the lines above and
>> below. Still OK. Tried adding back the line with column headings. Still
>> OK. Then, it dawned on me that the suspect line doesn't initially appear
>> - it's off the bottom of the table and an upward scroll is necessary to
>> see it. So, I removed four header lines from the full file, so the
>> suspect line is initially shown. Problem gone! Those dropped lines would
>> have been dropped anyway as part of the import. Increasing the form
>> height to 1000 allows the full file to be displayed with no vertical
>> scroll needed and the whole original file displays with no problem.
>>
>> Verdict - leave as is, with
>> 'tableWidget->horizontalHeader()->setResizeMode(QHeaderView::ResizeToContents);'
>> removed.
> OK.

Hi Cristian

I've had to revisit this, I'm afraid as it turned out that other columns 
in other files were not being displayed in full.

It looks to me that

'tableWidget->horizontalHeader()->setResizeMode(QHeaderView::ResizeToContents);'

does not in fact resize to contents fully in all circumstances, and the 
docs say it resizes to 'optimal' size, what ever that means.The problem 
mainfests itself especially with extremely wide fields that I've 
encountered quite a few times, including some of my regular imports. The 
results vary, too, between before and after dropping header rows.

So, more investigation was necessary, and I've spent quite a bit more 
time trying various options.

With 'ResizeToContents'in csvimporterdlg ctor, the file I originally 
noticed having trouble, has three lines with a very long field (947 px) 
truncated, and one of those also having the final field, which happens 
to be the amount field, truncated. Although most of the columns do get 
resized, those particular ones are still not wide enough. The final 
column does not get resized at all, retaining the header line width. 
When the six header lines are dropped, the wide columns are now OK and 
turn out now to be 1028 px wide, hence the original clipping. The final 
column is now OK.

Changing'ResizeToContents' to 'Stretch' avoids the need to resize and 
avoids the need to scroll past possibly very wide columns filled with 
data you're not interested in. All, or many, of the columns are 
immediately visible, and all the columns may be individually stretched, 
should that be required.

I think the problem is that the widths appear to be set based on the 
visible rows. The widths do not get changed when the table is scrolled 
down, as the updateScreen routine now does nothing.

Do you really need to have all the columns fully visible? If so, the 
updateScreen routine needs to be reinstated, although not necessarilyas 
complex as I originally had it, which was partly to expand/shrink the 
table to the data size. To my mind, the user just wants to decide which 
columns to select. The date and amount fields are pretty obvious, 
leaving just the payee and memo fields, which need a little study, and 
they could be manually stretched if necessary.

Allan