In NetVantage_2008 CLR3X ASP.NET, in ig_WebGrid_dom.js, there is something that is screwing up my usage of the web grid control (I need finer control of the scrolling for Virtual mode) something fierce:
"getDefaultRowHeight",function(){ var rh=igtbl_parseInt(this.Bands[0].DefaultRowHeight); if(!rh) rh=22; if(igtbl_isXHTML) rh+=2; return rh;},
igtbl_isXHTML is set when the document.compatMode is "CSS1Compat, i.e. non "Quirks Mode".
The problem is that these two extra pixels that getDefaultRowHeight adds to the row height are not actually there in IE7. With a server-assigned default row height of 16, this function returns 18, but it is clear from a count of the rows on-screen that the row height is actually 16.
I tried looking at the Infragistics samples page to see if there were any issues from this, but the Infragistics ASP.NET samples page uses quirks mode, and thus would not trigger the extra two pixels.
(For those who want to see what mode a page uses, type this into the address bar after the web page loads, type javascript followed by a colon and then alert(document.compatMode) )
What are these extra two pixels for? IE6? Firefox?
Is there any proper way to get rid of these? There are too many things using getDefaultRowHeight for me to just use igtbl_parseInt(this.Bands[0].DefaultRowHeight) everywhere I go.
Regards,
-- Ritchie Annand
Ritchie,
My guess is that the extra 2 pixels are for the a 1px border, or padding on the cell. When IE is in quirks mode, setting a row height of 16 px will indeed give you 16px (including any borders, margins or padding). Those values need to be accounted for separately if you're using a valid XHTML (css1compat) doctype. I'm not sure why the scrpit is using a hard coded value though, that seems fragile - especially if you change the border height.
I certainly recommend you log this as a formal support request through (http://es.infragistics.com/gethelp) In the mean-time, you have 2 options as I see it.. You can add 1px padding, margin or border to the default row style - which should then make the calculation correct. The second option would be to actually modify the Infragistics script and remove the +2 correction factor.
-Tony
That's a reasonable explanation, though I'm not entirely sure what IE is doing in this case, because poking around with the IE Developer Toolbar on one of the cells gives internal heights of 14 with a 1px border and no padding. Perhaps there are some quirks which even non-quirks mode evades?
What I might do in that case is to override getDefaultRowHeight, then. I think I might be able to do that by assigning a function to igtbl_Grid.prototype["getDefaultRowHeight"], though I must admit some confusion over how to delay that until the Infragistics JavaScript "classes" are already initialized.
Thanks, Tony
-- Ritchie