Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

autosize columns

I am using an edittable to display a schedule where the number of columns are dynamic, controlled by the user, depending on whether they want to see, a week, fortnight, month. Each day of the period is a new column.

I was intending to autosize the columns but it doesn't seem to work as I was hoping.
Scenario 1 - viewing a week, plenty of room in the control to show seven days so autosize should make the columns quite wide and easy to read.
Scenario 2 - viewing a month, the control is not wide enough to fit 28 or more columns at a width that make it legible. Want to then have a minimum column width and the horizontal scroll bar can appear for access to columns that don't fit.

The relevant part of the datacolumn doc says this
If the total width of all columns is greater than the table's width, then all autosized columns revert to their preset Width values
but it doesn't seem to apply unless I've misunderstood or coded it wrong either of which could be so.

I have the column widths set to 80 but when autosizing they will reduce to whatever width necessary to fit all within the confines of the space.
I want it to expand to fill the space or reduce only to the preset width.
Possible?

Comments

  • I think what the documentation is referring to is when you have a mixture of non-autosized and autosized columns. If the total width of all columns (which must include one or more non-autosized columns) is greater than the table's width, then those autosized columns revert to their preset Width values. Otherwise, the autosized columns are doing their job...autosizing.
  • Ah yes but column 1 is non autosized. The remaining are auto.
  • But is column 1 narrower than the width of the EditTable itself?
  • In the second screen shot, are all columns visible or are there some that are beyond the edge of the EditTable control?
  • All columns are visible. As a minimum those auto columns should be probably three times their current width thereby forcing some beyond the edge of the control.
    It appears though that the column width is just ignored on all auto columns. I think based on previous experience that the set width may be used to determine it's proportion in relation to other auto columns but not as a set value.
    In other words if I have two autosize columns, one with a width of 50 and the other 100, then regardless of the amount of space, the second will always be twice the width or at least significantly larger than the first. I'm looking for a minimum width.
  • First, my comments are not based on internal knowledge of the control. Kevin would have to give the definitive "here's how it was designed" type of answer. I'm speculating based on my own experience and interpretation of the documentation.

    Second, I think we are talking past each other. I get the impression you are assuming that the total width of non-autosized columns + the total preset width of autosized columns is what matters. I'm suggesting that the preset width does not factor into the calculation. Only if the actual width of all columns exceeds the width of the EditTable control will the autosized columns revert to their preset width. Thus, in your case, this never happens because the total of all widths is less than the EditTable's width.
  • Firstly, I appreciate your comments and Kevin's role. I'm speculating too.

    Second, your impression of my assumption is accurate in its description. I too was suggesting that the preset width does not factor into the calculation though I thought it should based on the excerpt from the wiki. That led me to question how your suggestion of the actual width could come into play or I guess more accurately, "what's the actual width?".

    So I made the edittable 100 columns wide thinking maybe the autosize needs to go negative before I get what I'm looking for.
    Voila.


    Based purely on eyeballing all this, I think preset width never actually comes into play, regardless of edittable size. What seems to be actually happening is the columns are now the same width as the row height which would suggest this property MinCellSize is being used instead of the preset width.
    This would work for me too if the property was an array for width and height but alas it's one number for both so I can't specify 80 as a min width for my columns unless I'm prepared for the table to look like this.


  • Based purely on eyeballing all this, I think preset width never actually comes into play, regardless of edittable size.
    Yes, that is really what I've been trying to say. Maybe we can come up with something else. Stay tuned.

  • Roger that.

    Four suggestions
    1. Change the wiki to say mincellsize instead of preset width or
    2. Change the function to use preset width as per the wiki or
    3. Change the mincellsize property to accept values for both width and height and change the wiki accordingly or
    4. Whatever you damn well please because I'm only guessing anyway
Sign In or Register to comment.