Hi,

I can't see any reason why the ControlContainerEditor might move the controls within your Editing or Rendering control. But the ControlContainerEditor will manipulate properties on your control such as it's size and position on the screen. So maybe your control is anchoring or docking the controls within it and this docking/anchoring is somehow getting corrupted at some point. I've seen some very strange things happen in Visual Studio when using anchoring and docking. There seems to be some timing bugs that can crop up occasionally.

You might want to handle the Resize event on the control and position the controls within it manually instead of relying on the Docking or Anchoring and see if that helps.

Hi Chris,

Thanks for the video. I am able to reproduce the issue now. The steps you provided previously don't match up to what you are actually doing to reproduce the issue as shown in the video, so that's probably why I could not get it to happen before.

ChrisBrooks said:

If you run the sample, then scroll to the bottom where the UCAuthentication controls are, then activate them, then scroll up and click on one of the radio buttons, then scroll back down and click on the UCAuthentication again, sometime the issue will happen.  I will continue to work at the exact way to duplicate the behavior, and when I figure it out, post how to do it here.

Anyway, I still can't reproduce it every time, but there is definately something weird going on in your sample application.

I noticed that when I drag the scroll thumb all the way to the bottom, the last row lines up flush with the bottom of the grid. But as soon as I release the mouse, the grid jumps and everything shifts up and there's a gap between the last row and the bottom of the grid.

This shift is about the same height as the controls shift sometimes when the problem happens. So I think they are related.

My guess is that both issues have the same cause and that it's your CreationFilter. Inside your CustomCreationFilter class, you are changing the Height property on the grid row. This is a very bad idea. The UIElements in the grid are created an positioned based on the properties that the grid returns. You should never set properties on the 'real' grid objects inside a CreationFilter.

It looks like you are simply trying to determine the correct height for the row, but you cannot do this inside a CreationFilter.

If I leave the CreationFilter on and simply remove the line of code that sets the Row.Height, then once again, the problem with the scrollbar goes away and I cannot reproduce the problem you are having, either.

So I'm pretty sure that the problem here is caused by your CreationFilter.

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;

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

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.