Interactive Grid column widths

Since the first Early Adopter release of APEX 5.1 I have seen a number of questions or complaints about how column widths are handled in Interactive Grid. I think the complaints may be based on misunderstandings of how things work. I hope to explain here everything you need to know about column widths in Interactive Grids. Still, I’m not 100% sure that in implementing Interactive Grid we got it all exactly right. You can let me know in the comments after reading this.

First lets review how Interactive Reports handled the column width. Basically it didn’t. It used a table with CSS table-layout: auto. This means that the browser decides how wide each column is and it generally takes into consideration the data that is in all the rows and all the columns. The algorithm isn’t standardized so it is possible that different browsers do it differently. It is also a little less efficient since the browser has to see the whole table markup before it can settle on the column widths. For the most part people seemed pretty happy with how the browser did things. It gives more width to columns with lots of text and less width to columns with less text and tries to fit as best it can before giving up and adding a horizontal scroll bar (by being wider than its container). It would also wrap text that didn’t fit. This means that the column widths are different depending on which rows you are looking at. When paging through a report I think the changing widths are distracting. Some people wanted control over the width of Interactive Reports columns and if you search you can find lots of advice on this; some better than others.

But Interactive Grid (IG) is a different beast. It uses fixed table layout and lets the user adjust column widths. It also fixes the row height of all rows. The consistent fixed row height is often very nice when looking over many rows but it can be annoying if some cells have lots of data you want to see. We choose a fixed row height because it is often what you want, especially for editing, but also because it made many of the fancy things that IG does, such as frozen columns and scroll paging, easier to implement and more efficient. We hope to have an option in the future for variable height rows.

I know this is supposed to be about column widths but permit me to go on a row height tangent for a moment. The row height is set with CSS. When there are frozen columns there are separate tables for the frozen and not frozen columns so if the heights of rows in the two tables don’t match the rows get out of sync and it looks terrible and becomes unusable. The browser’s table rules seem to care more about showing what is in a cell than any rules about cell or row height or overflow settings. So keeping the row heights in sync is a shared responsibility. If you add markup to a column you need to make sure it isn’t taller than what the default IG CSS rules allow for. Or you can override the row height for the grid using CSS. More on this in a moment.

I made this very mistake in the Sample Interactive Grids app. If you go to the Reporting: Icon and Detail Views page and freeze a column you will see that the heights don’t match because of the button. The button padding plus the cell padding is too much. (If you are reading this far enough in the future the problem may be fixed.) If you add your own buttons you should add class has-button to the column Appearance: CSS Classes attribute. This takes away the top and bottom cell padding and could be used for other cell markup; not just buttons. This should work with buttons using the t-Button* classes but it is still a little off. I found that using the following for the button class worked much better:

a-Button a-Button--icon a-Button--noLabel a-Button--action js-actionButton

Lets say you have a column that generally contains a lot of text that you want to see more than just one line but not necessarily all of it. You can make all the rows a little higher and let the text wrap for just that column. Here is how.

Its nice to target the CSS rules just to the grid they apply to. So give your IG region a Static ID. You could instead use a class. If you want to follow along you can modify the Icon and Detail Views page of Sample Interactive Grids app. It already has a static id of emp for the grid.

Select the NOTES column and change the Type to HTML Expression. Then enter the following for the HTML Expression attribute:

<div class="wrap-cell">&NOTES.</div>

Add the following to the page CSS Inline attribute.

#emp .a-GV-cell {
    height: 80px;
.wrap-cell {
    max-height: 64px;
    white-space: normal;
    overflow: hidden;

This sets the fixed height to 80px. The reason for wrapping the notes column in a div is that if we just turned off white-space: nowrap; for the cell the table layout rules would show all the text no matter how much making the row arbitrarily high.

This shows how simple it is to customize the height of IG rows. Setting the row height can be used for other purposes such as if the report contains thumbnail images. The technique for letting text wrap relies on using an HTML Expression so precludes editing that column. You may also want to take a look at the Sample Interactive Grids Advanced: Tooltips page to see how the full text of a cell can be displayed in a tooltip.

Now back to column widths. The first point of confusion is the Appearance: Width attribute on column types such as Text Field. This does not affect the column width. As the help text says, it is the “width of the form element” so it affects the width of the input element just like it does for a page item. But when editing in the grid it is more important for the width to match the column than what is specified for Width attribute. So the only place the column’s Width attribute comes into play is in Single Row View.

The important thing to realize is that the column widths are a report setting. That is to say they are a runtime setting not design time metadata. So just like other report settings, such as sorting or column order, to set the widths you run the page and then adjust each of the column widths (and any other report settings) and then save the report. As a developer you can save the default (primary) report that is used for all users. You can also create an alternate report. So part of creating an Interactive Grid is setting the default report settings. This is no different from Interactive Reports.

To set the width of columns you can drag the end (right for left to right languages) border of the column header. Or you can focus the column header with the keyboard and use the Ctrl-Right and Ctrl-Left keys. You can also set the widths in the Columns dialog. Choose Actions > Columns to open the dialog.

Once you have set all the widths choose Actions > Report > Save to save the default (primary) report. When you first create an Interactive Grid there is just the primary report. If you are editing the widths after other reports have been saved make sure the intended report is selected first. Each saved report can have different width settings. If allowed, end users can save their own reports.

Some advice about setting the column widths. You don’t know how wide the users browser window will be so try to pick the smallest reasonable width that fits the typical data that will be in the column. For some columns this will be easier than others. Using reasonably small widths by default will reduce the chance of their being a horizontal scroll bar when the end user views the grid. Also don’t forget to set the width of columns that are hidden by default.

The next point of confusion, complaint or frustration is the way widths are distributed across the columns. This is most notable on a grid with just a few columns. You can try this out on the Sample Interactive Grids app Master Detail page. The Departments grid has only 3 columns. When all the columns fit (no horizontal scroll bar), if you make any column smaller (less wide) then the extra width is given to the other columns. Also if you make the browser window wider the extra width is distributed among the columns. The reason for this is that we though that in general it looks odd to have extra dead space at the end (right or left depending on direction) of the grid. That extra space may as well be used for the columns even if it makes them wider than needed. If you you make a column wider eventually a horizontal scroll bar is added.

From this it should be clear that what you are actually adjusting is the minimum width of the column. If you open the Columns dialog you can see that indeed the field label is “Minimum Column Width”.

So columns have two width settings. One is the minimum width and the other is the current width. When you drag or use the keyboard to set the width you are setting the minimum width and also the current width. Then any substantial extra width is distributed to the other stretchable columns in proportion to their current width but it doesn’t change their minimum width. If there are just a few extra pixels it is given to the last stretchable column. If the browser window is resized then the current widths are cleared so that horizontal scrolling can be removed if possible or minimized. The current widths are never saved as part of the report settings.

Hopefully this explains the possibly confusing behavior of column widths. But what if you don’t agree with us that dead space at the end should get put to good use. Or perhaps you are fine with some columns getting stretched but stretching other like a Yes/No switch or date column just looks silly. A hint of the solution is in the term “stretchable column” I just used. The grid widget has a column property called noStretch and if it set to true then that column will not be bigger than its minimum width. This was supposed to be an advanced column configuration setting. You should have been able to set it with a Column Advanced JavaScript attribute something like:

function(config) {
    config.defaultGridColumnOptions.noStretch = true;
    return config;

But sadly this doesn’t work. Here is the best workaround I can think of. Add code similar to the following to the Execute When Page Loads page attribute.

var grid = apex.region("dept").widget().interactiveGrid("getViews","grid");
grid.modelColumns.DEPTNO.noStretch = true;

This will set the DEPTNO column of a grid with static id dept to not stretch. It relies on IG APIs that are not yet stable. Namely the getViews method and that the views have view$ and modelColumns properties.

And if you want all the columns to not stretch use this code.

var grid = apex.region("dept").widget().interactiveGrid("getViews","grid");
for (c in grid.modelColumns) {
    grid.modelColumns[c].noStretch = true;

Now all the columns will be exactly the width you set and there may be dead space at the end.

The absolute minimum width a column can be is hard coded to 40px not counting padding. We needed some minimum just so there would be room for column header controls. There is no maximum width for a column. We saw no need to restrict the user.

You can programmatically set the grid column width using code such as:

apex.region("dept").widget().interactiveGrid("getViews","grid").view$.grid("setColumnWidth", "DEPTNO", 180);

Change the region dept, column DEPTNO and width 180 as needed.

That’s everything I can think of about how column widths work.

6 thoughts on “Interactive Grid column widths”

  1. The code I give to set a column or all columns noStretch = true does not work perfectly. At this time I don’t have a robust solution. The problem is that the grid view is created and destroyed at various times such as when the report changes. When this happens the column settings are lost. I’ll update if I find a robust solution.

  2. Hi,
    thank you for the detailed explanation, however to reach this:
    “Now all the columns will be exactly the width you set and there may be dead space at the end.”
    … there should be an declarative way (option) – also and in particular! – for the end user.
    All these folks never may want or will read your explanation – they want it to work e.g they know it from their Excel experience.
    Usually they are less interested why things work as they do,
    but rather users wants to have things work as it makes sense for them and how they expect it has to work.
    If they adjust a column width they expect that it will live as long as they change it again
    and at least for the duration of the current session.
    I know you wanted to do things best and optimized, however sometimes the user wants to have the last word.
    I think IG in the first place is for our end users.
    So in this case please make a step back in your willing of optimization
    an a step toward the end user to fullfill what they want and expect.

    Once again – thank you very much for the great work and explanation
    and best regards.

  3. Me again .. on a Editable Grid, where by default the APEX$ROW_SELECTOR and APEX$ROW_ACTION columns are “Frozen” – how does one adjust the height of those columns to fit the rest of the row, given that the my other columns have LOVs and Radio Groups and/or a Calendar.
    In fact I am seeing different row heights – that makes it worse. I am seeing this on username /pwd guest/demo.
    My rows are different heights, depending on what I edited when. How to handle that? Suggestions?

Leave a Reply

Your email address will not be published. Required fields are marked *