ListGrid AutoFit and remaining space

[tgilbert]

Hi,

In a listgrid, for example the one in this showcase sample (http://forums.smartclient.com/showthread.php?t=30360), when we right-click on a column and select "auto-fit", it will shrink the column as expected, but the space we save is not given back to the other columns, resulting in an unwanted white space on the right side of the grid.

Is there a way to force the grid to always fill the whole width with columns ?

Many thanks for your help,

Thomas

[Blama]

Hi tgilbert,

please see this thread, perhaps it does help you. I did not try the suggestion from Isomorphic in the last post, yet.

Best regards,
Blama

[tgilbert]

Many thanks,

I tried to use the setAutoFitFieldsFillViewport() API, but without success, even by exlicitely also calling setAutoFitExpandField(). A blank, unused, space still appears on the right side.

[Blama]

Hi tgilbert,

Isomorphic suggests to use setFields() again. See the last post in the thread.

Best regards,
Blama

[tgilbert]

Hi,

No setFields() does not help neither. Also, my goal is not to get back to the original layout. I just the whole space to be used even if I have used autoFit on a column.

Thanks,

Thomas

[Isomorphic]

By design, the APIs you are looking at apply at original render (or setFields()), and not when the user is resizing fields.

The primary reason is that it's easy for the system to end up "fighting" the user if they are trying to resize multiple fields, by resizing a field they previously set to a particular size.

If you avoid all fields that the user has previously resized manually, and ignore all fields where you can tell there's no point is adding space (icon fields, date fields, fixed-width valueMap fields, etc) then you could potentially avoid the "fighting" problem but the behavior would be confusing - sometimes space would be filled, sometimes not.

So, this is not a behavior we want for the framework, but if you wanted to take a crack at it, you could react to the FieldResized event and try to pick a field to enlarge.

[Isomorphic]

Actually, introducing this behavior is worse even than we said: you could also end up enlarging the wrong field, when the user had intended to resize a different field to take up the space they just freed.

And there's ambiguity about what to do when the user introduces horizontal scrolling: leave the scrolling in place, or shrink a field?

Things become yet more complicated if you consider than the user might have intended to freeze or autofit some other field, or introduce a new formula field, and is starting by resizing a particular field..

Overall, the grid does not have the context necessary to make the right choice about growing a field in response to end user resize.

[tgilbert]

I understand it's more complicated than it seems, but I "just" would like the autofit functionality to work like the "Add/Remove column" you have in that very same contextual menu: when you hide a column, the freed space is reused as expected by enlarging existing columns no? Why does the API not do the same when I select autofit in the contextual menu as well?

Also there are two methods in the API which seem to suggest it should work:

setAutoFitFieldsFillViewport()
setAutoFitExpandField()

What's the purpose of those two methods then?

[Isomorphic]

It doesn't matter which way the user resizes a column: dragging or requesting AutoFit - the concern are the same as we've already cited. Adding or Removing columns on the other hand is a fundamentally different operation where the grid has a better idea of what's going on.

Also, as we've already explained, the two APIs you asked about apply to initial render.

[tgilbert]

All right. I get your point and I understand this is a tricky situation.
I just wanted to underline that many of our testers and users have complaint about the fact that when their narrow the size of a colum, a white space appears on the right... they would have expected (as I did) the last column column to just increase its size accordingly, as it's the case in regular tabular applications. So, there is perhaps some space for improvements there...

A good step forward, might be that you add a blank header on top of the free space instead cutting it, so that the header part always covers the whole width, if you see what I mean... What do you think?

[Isomorphic]

It is not actually true that the behavior you want is typical of "regular tabular applications" - what our grid does is the same as many of the most common places where you see a grid.

It sounds like your testers are probably comparing to some specific application they are familiar with, and perhaps the behavior is appropriate *in that particular application* - but we have already explained how to get the behavior you want if it actually works for a specific app. It does not make sense as a general framework behavior.

And while the skinning system allows you to style the background area so that it looks like the header, we don't recommend doing this as it would look like there was another header there, partly offscreen.

[tgilbert]

Well, I just checked Sencha and Vaadin tables and it does not work as you describe, the header always fills the whole space whatever the width of the last column; which IMO looks a lot better. Also, I understand this should not be considered as the best way to go, but adding this as an option would be a nice improvement.

My two cents,

Thomas

[Isomorphic]

We're not sure what you're looking at, but no, the Sencha and Vaadin samples do not behave as you describe. None of the headers expand to fill the space vacated by a header that the user resizes smaller.

If you're referring to the choice of background color, that's theme-specific and easy to modify.