Split Grid Misalignment when Scrolling in FF

Suite and Optimus Suite 5
#1

Hello -

We have the Pro Suite v2.5, and have the following issue…

In a grid using splitAt() functionality, running on FireFox with the zoom level set to something other than 100% (that is, use ctrl - or ctrl +), vertical scrolling will get out of sync between the left and right portions. You need roughly 300 to 400 records to begin to see the phenomena - 1,000 records makes it really obvious.

Oh - and we are using the “every other line is colored” style as well, which really points up the difference.

TreeGrids, displaying a grid at 100%, or using IE 7 all work fine, or it appear to.

Is this a known issue?

#2

Hello,

Unfortunately this is browser-specific behavior and cannot be fixed with JavaScript.

#3

Hi Olga -

We’re still having trouble with the Split Grid row-misalignment issue. My boss wants it fixed, and if it cannot be fixed, to use another tool (besides DHTMLX). We cannot control the zoom desires of our customers.

I don’t think this is browser-specific, necessarily. True, the problem shows up in FF and not IE, but treeGrids work fine even with the split. It is only ordinary Grids with a split that show the issue. Perhaps the functionality for painting rows between the left and right sides can be compared in grid and treeGrid? As I said, treeGrid works fine in any zoom factor.

One way to reproduce the problem is to define a grid with a split column, highlight a few rows down, then change the zoom. You might have to go more than 1 zoom step (that is, hit ctrl +/- more than once). The highlight gets offset between the left and right sides. Sometimes scrolling up or down from there re-sets it; most of the time it does not.

Are there any specific changes in the 2.6 (from 2.5) that might have addressed this issue?

Thanks.

#4

Are there any specific changes in the 2.6 (from 2.5)
If issue occurs only in zoomed mode - probably not.
From components logic, it is not possible to detect the zoomed state, it is fully browser rendering logic.

#5

Ok… then why do split TreeGrids work fine? What is different about the split rendering between Grids and TreeGrids?

Thanks,
Will

#6

The basic concept is the same for both grid and treegrid.
Treegrid cell uses a bit different styling to correctly align text and image inside, but it has the same size and the same structure.

Styles and logic of grid are define to render valid structure for 100% zoom level. At this point it all rendered correctly. During zooming, browser uses their own logic for elements rendering ( the logic is component doesn’t know about zoomin, its all done by browser ) - and component can’t affect the zooming in any way.

#7

It seems to me that, whatever you are doing in the tree version handles the browser zooming correctly, but for whatever reason the grid version does not. Or, alternatively, the tree version does not set up the same conditions as the grid version for the browser to trip over.

I understand that you have no control over the browser, but since you are able to get around this limitation in the tree view, couldn’t the same/similar logic be applied to the grid version to resolve the issue?

I’m sure we are not your only FF customers. I know that our customers are not happy; neither is my boss… There must be something that can be done. I don’t think I’m doing anything particularly fancy with the grid - maybe I’m missing something? Have you encountered this issue, or have others (FF users) complained about it?

Thanks.