Hello Chris,

Base on this forum thread I have created a case for you with id CAS-71749-4JRB4S in order to investigate this issue further for you. I will update you for the progress of this as soon as I have information for you.

Thank you for using Infragistics Component.

Mike,

Thanks for your reply, and looking so deeply into this issue.  It does sound truely strange. It seems like the work around you suggested is working, so thanks for that as well.  I will be excited when a fix for this is done, because I can notice the performance hit without using the scroll window.

-Chris

Hi Chris,

ChrisBrooks said:

On a side note, thanks for your suggestion on not setting the row height property inside the creation filter for the grid.  Could you suggest a better place to determine and set the corret height for the row, so that the row is displayed properly, like the first screenshot below, not the second

You could explicitly set the height of the row in the InitializeRow event. But you won't be able to get the UIElements for rows that are not in view. I'm not sure there is any better way to do this, though. Maybe what you need to to make the option buttons another control that provides a PreferredSize so the rows will size themselves correctly.

Anyway, I tried again with your sample. I removed both the CreationFilter and the DrawFilter and I am able to reproduce the issue.

The trick is that when you scroll up, you have to do it slowly so that at some point, the UserControl is partially in view. If you scroll up very quickly so that the UserControl is visible during one paint operation and completely out of view in the next, then the problem does not occur. But if you scroll up slowly so that it remains partially in view at any point, the problem occurs.

In fact, you can reproduce the issue reliably by doing this:

1. Run the sample
2. Scroll all the way to the bottom of the grid.
3. Click on either of the TextBoxes in the last row to place the cell in edit mode.
4. Click the scroll up arrow in the grid exactly 4 times so that the last row is no longer in view.
5. Click the down scroll arrow 4 times so that you are all the way at the bottom again.
6. Click on the last cell to go into edit mode.

I spent a couple of hours looking into this and it's really bizarre.I put in some code to walk over all of the controls on the form recursively and display the Bounds property of every control so I could see which control(s) were moving when the problem occurs. 

So I ran the sample, scrolled all the way to the bottom and went into edit mode on the textbox in the last cell and display the Bounds of every control. Then I got the problem to occur and displayed the Bounds again.

Much to my surprise, they were all exactly the same. Using SPY++ to examine the windows, the rects of the controls on the screen is actually different. So somehow, the controls are out of synch with their own properties.

I think this is ocurring because of the grid's use of the ScrollWindowEx API call. The grid does this for efficiency so it can scroll faster. But it seems to be causing a problem with child controls. Why this is happening only for the controls inside the GroupBox and not for the GroupBox or the UserControl is beyond me.

I think part of the problem may be that when the grid exits edit mode, the grid is making the UserControl invisible, but it is not moving the control to a new location. So when it comes back into view, it's already at the correct location and thus some internal state on the window is not getting cleared. I beleive we can fix this in the UltraControlContainerEditor code in a future service release.

So I'm going to ask Infragistics Developer Support to open a case for you (if they haven't already) and write this up as a bug for developer review.

In the mean time, you can work around the issue simply by turning off ScrollWindow in the grid:

this.gridQuestions.DisplayLayout.UseScrollWindow = UseScrollWindow.None;

Attaching ZIP folder with video.

Thanks,
Stephani