I have a list grid with cell size 45 and with ImgButtons as 1 field. Whenever I groupBy anything, the group title row is initially the default size, but then after I mouseover it, it changes to 45. This wouldn’t really be a problem, except that it is messing up the alignment of my ImgButtons (see picture). I created these buttons using the Grid Cell Widgets showcase example, so the code is very similar. Any ideas on how to either disable this resizing of the title row from the default to 45 or ensure the alignment of the ImgButtons?
Update: The problem still persists in Chrome (despite new CSS rules), however in Firefox the problem is fixed. Any ideas why or what I could do to make it work in Chrome??
Running SmartGWT 2.5, GWT 2.3, and IE9 (in IE8 mode) as well as other browsers with the default Enterprise theme, I’m seeing the same issue.
Naturally there is no information in the developer console I can give because it’s not an exception throwing error but rather what appears to be a calculation error.
For some reason running the mouse over a list grid appears to reduce the height of the grouped rows by 2px. The height attribute of the <td> tag changes from 21 to 19. It also resets back to 21 whenever I expand/contract a group.
This appears to be related to the fact that I set a 2px bottom-border on .groupNode in the CSS. Removing all borders cause the rows to grow when I mouse over them, setting a 1px bottom-border maintains constant height in all browsers.
Looking into it a bit more, the conclusion I’ve come to is that I’m using setStyleName() to load styles for the ungrouped rows. Those rows have a bottom-border of 1px. Setting that value to 2px (along with the value in .groupNode) maintains the height as expected. So it looks like the grouped and ungrouped rows need to have the same border settings, otherwise you get magically self-adjusting rows.
What I want to know, is why the “group node” heights are recalculated on mouseover?
When you use a strict docType (including the HTML5 docType) some browsers will change the row height in a table when a new cell style is applied that has a different total pixel size for border+padding. You can reproduce this with just a simple HTML table with no SmartClient involved - it’s an unfortunate consequence of some ambiguity in the CSS spec regarding tables.
We have already modified the CSS for Enterprise in nightlies to make the total border+padding for group nodes match the size for other rows. You can grab a nightly, or just make the same modification yourself.
I believe that, and we are using the html5 doctype. However, what CSS won’t do is change the height attribute on a <td> tag (as in <td height=“21” />). It is the html attribute that is changing, not the css property.
Depending on what tool you’re using, it can falsely show a height attribute changing when in fact it’s just the size changing and not an actual programmatic change to the height attribute as such.
However, if you’ve set fixedRecordHeights:false (or other similar auto-size settings) then you would also expect to see this effect and in this case we would be programmatically setting the height attribute based on the measured size (and it would likewise be correct and expected behavior since the row has actually shrunk).
Hmm, that’s interesting. We are using SmartGWT and it looks like fixedRecordHeights = true by default. Calling setFixedRecordHeights(false) on the ListGrid does in fact fix the issue (though our rows are rather large now, but that’s an issue i can fix later).
However, for one point of clarification, it now appears as though the row height being recalculated is expected. What is not expected is that it uses the border values for the non-grouped (leaf) rows to determine the height of the grouped rows.
Thanks though, for at least pointing why the dimensions were being recalculated.
