The problem seems to be that some (perhaps all) browsers are reporting fractional coords for the top of the table, even though top, padding, scrollTop etc are all integers. So the formula sometimes computes 1.9999999 when it should compute 2. Math.ceil is not the solution, because the same rounding errors could produce 2.00001 and Math.ceil would then compute 3. But Math.round should be good enough.

I'd still like to figure out where the fractional pixels are coming from – but for now Im pretty sure that Math.round will solve the problem.

Mark

While debugging another issue, I was using Fiddler to track network events for my page.

I noticed that in ie6 and ie7, if you wave the mouse in front of a grid, /lots/ of network events fire. And they're all fetching the same background image.

I googled around a bit, and found that ie6 has a known bug where setting the background image of an element will cause “flicker”, because it fetches the image from the server (regardless of caching setting). The bug is supposedly fixed in ie7.

Well, the flicker may be fixed, but fetching the background image certainly isnt. Also, the well documented fix for ie6 'document.execCommand(“BackgroundImageCache”,false,true)' doesnt seem to stop the traffic with either ie6 or ie7.

Not sure what can be done, except to minimize the changes – so rather than changing the css on every mouseover and mouseout, we should verify that the row has actually changed. That would certainly cut down on the traffic…

Mark

None of the grid methods end up in the jQuery.fn namespace, so they cant collide with methods provided by other plugins.

When you consider that there are functions with names such as showCol, that seems like a pretty significant benefit to me…

Mark

The problem I am having is that when my #masterGrid loads and there are several none unique id fields within that first 30 loaded rows and I click on any row whose id appears more than once in that list of 30 it highlights all the rows with the id I highlighted instead of showing Master Detail information for that id like Safari/FF would

There's your answer. Ids are required to be unique. If they're not, the grid will misbehave in strange ways. This particular thing may appear to “work” in FF, but lots of other things will fail.

Mark

My guess is you're doing something wrong… but without know which params you're setting with setGridParam its hard to know.

The thing to be aware of is that when you reorder the columns, they are reordered in the colModel itself. The grid keeps a record of the permutation of the columns, and when you request data from the server, it re-orders it based on that permutation before loading it into the grid (at least, in the repeatitems:true case – for repeatitems:false the order of the data is irrelevant).

So if you use setGridParam to replace the colmodel, for example, bad things are going to happen (unless you are very careful).

Also, if you try to load data into the grid programatically (and not via addJSONData or addXMLData), yuo will have to take account of the new column order.

Finally, if you're just trying to show/hide columns, and dont want them to be re-ordered at all, you can replace the “done” function in the column chooser with a no-op.

Mark

The ideal solution would be to use the css pseudo class :hover in all browsers that support it (ie everything except ie6), and not have the event handlers at all for most browsers.

Unfortunately, you cant do that and stay compatible with themeroller, as far as I can tell (this seems to be a flaw with jquery-ui/themeroller).

Mark

There is a workaround.

Your beforeSubmit handler can delete the postdata.id field, and add postdata.row_id.

You need to be careful handling the “add” case (rather than edit), because the grid differentiates the two by checking whether postdata.id == “_empty”.

You can solve that by /not/ deleting the “id” field (in which case the server will see both id, and row_id), or by adding it back in your afterSubmit function.

Mark