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.

Hello Mike,

Thanks for the reply.  I have turned off anchoring in my custom control and I turned off docking of the custom control in the cell.  However I am still seeing the problem.

I overloaded the resize and the visiblechanged event in my custom control. When I am debugging these the Location is correct and the screen coordinated are correct (meaning they are showing the values I would expect).  However, the controls are at a totally different screen coordinate when I look at it in spy++.

Just for clarification, this is a problem when I click on the control(going to edit mode) scroll all the way to the right...then scroll back.  Click on the control again.

If I set the grid so that no scroll bars are needed by confining the size of columns this never happens.

-Dan

Hi,

I just wanted to know if you were able to solve your issue based on Mike's suggestions or you still need help? Just let me know.

Thank you.

Hello,

I am experiencing the same issue with a UC inside the UltraControlContainerEditor.  I cannot get it to happen all the time, but i have noticed with enough of scrolling to the bottom of the grid (where this UC is located), and then scrolling to the top, clicking on a row, and then scrolling back down to the UC will sometimes cause this problem, but unfortunatly, cannot duplicate.  Wondering if anyone else has seen this issue, and if a fix could be recomended, thanks!

-Chris

Hi Chris,

What version of the controls are you using?

If the controls inside your UserControl are Docked or Anchored, then perhaps what's happening is that at some point, only part of a cell is visible and the grid is therefore setting the size of your control to something really small which causes the docked/anchored controls to be moved incorrectly.

In theory, that should not happen, but I suppose it depends on your UserControl and the Dock/Anchor settings you are using and could also be affecting by any control resizing or repositioning you are doing in your code.

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