Hi Todd,

That method was specifically added to avoid problems where the grid would cause the parent window to scroll when tabbing through the cells.

The problem is that when you tab into a normal text cell in the grid, the grid displays a TextBox over the cell and the form scrolls the TextBox control into view, even if it's already in view and even if the entire grid is already in view.

So this code is intended to prevent that scrolling. So perhaps your workaround is somehow interfering with the workaround.

Anyway, I have sent a message to Infragistics Developer Support and they are going to create a case for you where you can attach a sample so we can take a look.

Hello Todd, 

I already create a private case for you with reference number CAS-88469-MT9KQZ. Could you please upload the sample (through the case) that reproduce your issue and we will be glad to research it. Let me know if you have any questions

Regards

Update: I did find the old project - had it on my VM WIndows XP environment.

The bad news - the source I found the bug in was 7.3.20073.1070 - I think I might have made up that # to get it to ignore the assembly build - in any case, it will not compile since updating to 11.2 and it's license is not registered.  I get a 'The located assempbly's manifest definition does not match the asembly reference.' error.

The good news - it still has my breakpoint settings - and one is where I put it to fix the old scroll issue problem. It was in Utilities.cs on the method at line 4082:

// MD 11/7/06 - BR17484
#region FocusControlWithoutScrollingIntoView
/// <summary>
/// Focuses a control without scrolling it into view if it is contained in a ScrollableControl.
/// </summary>
/// <param name="control">The control to focus.
</param>
/// <remarks>
/// This will only work properly in CLR version 2.0 or later.
/// Otherwise, it will just focus the control.
/// </remarks>
public static void FocusControlWithoutScrollingIntoView( Control control )
{

return; // This is my fix - ignore the entire method

Point oldAutoScrollOffset = control.AutoScrollOffset;

try
{

Point newOffset = control.Location;

// MBS 12/19/06
// Use safe parent accessors
//Control parent = control.Parent;
Control parent = GetParent(control);

// MBS 7/5/07 - BR23957
// We only want to take non-default action when the control is wider and taller
// than its immediate parent, otherwise we'll end up constantly shifting the control
// by an incorrect offset.

if (parent != null && control.Height <= parent.Height && control.Width <= parent.Width &&

// MBS 9/24/08 - TFS6762
// For the same reason as below, we only need to make this compensation when the parent
// is set to AutoScroll
parent is ScrollableControl && ((ScrollableControl)parent).AutoScroll)
{

FocusControl(control);

return;

}
... rest you can find...

Hopefully that is enough for you to get a clue where I had the work-around before - So yes, this was called during the grid processing I think - cannot debug into it now so not sure how it got called - but without it the form worked normally.  If you want to try and replicate it - use the OnGridEnter with the FirstNonHiddenColumn  code - one you fixed - and maybe it will tell you something...

later, Todd

Hi Mike,

The above sample OnGridEnter you fixed was the 'problem' version we commented out - replaced by the working version in my first post.  This older version caused the form to jump to the bottom of the form when the grid was in the middle I believe - maybe due to recursion as you said.

Manually scroll the form - most of our users are using keyboards only for data entry - they enter this info in like 50 different tables - and are supposed to TAB from one to the next, reading the title and asking the person being questioned if that topic affected them - if not, TAB ing to the next table.  So - manually repositioning the form so the entire grid is shown is not a consideration - it worked before in 7.3... with the code you fixed... which didn't work in 11.2, prompting my re-write OnGridEnter to find the first TabStop enabled cell and setting it as the Active cell - or creating a new row from template if no rows are found in table. This works - but just does not auto-scroll the entire table - leaving just enough below the form to cause the recorded bug.

Mike Saltzman"]
The video here doesn't show the form's scrollbars, but as I understand it, the the issue is that the form is scrolling as you tab between cells in the grid when the grid is partially out of view.

Is that right? I just want to make sure I am looking at the right problem.
...
**- There's nothing in the grid that scrolls the form or the container that the grid is in.

yes - the video has the form located in the middle - imagine a form with a 1/2 page of text boxes at the top, then 20-50 yes/no radio button + grid sets as content, ending in a few more text boxes. 

**- And no - as I remember it, there was a call within the Ultragrid source that told the parent to reposition itself - same code I imagine that causes the grid to partially pop into view when you enter it the first time - it just doesn't position the entire grid, leaving about 5 - 10 pixels below the form and thus causing this issue. If it scrolled the entire grid - this problem would not exist.  I had commented this out in Infragistics source when trying it months ago and fixed the old code bug...

Just don't have time to look it up now (the original test solution was deleted), and this issue is not a stopper - only happening now if the user tries to go back through a table with existing data, and the work-around - manually scroll the form so the grid is in full view works. 
(Oh, and note: they must use the mouse on the scroll icon on the form to move it - cannot just click the form, not on a control, but on the form and use arrow keys like a web-form - would've thought it would allow that...?).
I wonder if this problem is not some our-side code someone entered I just haven't found yet...

 Thanks for trying... maybe I'll dig into this more later this week... try and whip up a sample. Can you find my email and shoot me one (I promise to not email without going through support first on any 'other' issue.) - if I can produce a sample - I know I cannot post it on here - would exceed the 200k limit for one, and company policy for the other I'm sure... we do have email basic support the rest of the year I think...

Thanks, Todd

Hi Todd,

Okay, I downloaded the video and I can see it, now.

The video here doesn't show the form's scrollbars, but as I understand it, the the issue is that the form is scrolling as you tab between cells in the grid when the grid is partially out of view.

Is that right? I just want to make sure I am looking at the right problem.

If that is the case, and the problem does not occur when the grid is fully in view, then couldn't you work around this by always scrolling the grid completely into view in the grid's Enter event? I haven't tried it, but there must be some way to detect the current scroll position and bounds of the form and detect whether the grid is entirely in view or not, and then scroll it into view it's not.

Todd N said:

You'll note two versions of OnGridEnter(..) - in my first original post is the working version - directly above is the version that worked in 7.3 that had to be commented out to avoid the page scrolling problems in 11.2. 

I was asking what code in the grid's source you were referring to. There's nothing in the grid that scrolls the form or the container that the grid is in.

Anyway, I tried reproducing the issue and I cannot reproduce it. If I have a grid that is partially cut off on a scrollable form and I tab between cells, everything works fine for me. The form does not scroll.

I also tried using the same code you have for your OnGridEnter method. In this case, I do see a problem when I tab into the grid. It looks like this code is causing an infinite loop. When I call PerformAction(EnterEditMode), I end up getting back into the Enter event of the grid. This looks like a timing issue.The grid is apparently still in the middle of processing something when the Enter event fires.

I was able to get around this problem by moving the code form the Enter event into a method and calling it from the event handler via a BeginInvoke. That way the grid's processing completes before the call to PerformAction occurs:

        private void ultraGrid1_Enter(object sender, EventArgs e)
        {
            UltraGrid grid = (UltraGrid)sender;
            grid.BeginInvoke(new MethodInvoker(this.EnterEditMode));
        }

        private void EnterEditMode()
        {
            UltraGrid grid = this.ultraGrid1;           

            UltraGridColumn FirstNonHiddenColumn = this.ultraGrid1.ActiveColScrollRegion.VisibleHeaders[0].Header.Column;
            if (FirstNonHiddenColumn != null)
            {
                grid.Rows.TemplateAddRow.Cells[FirstNonHiddenColumn].Activate();
            }

            grid.PerformAction(UltraGridAction.EnterEditMode);
        }

Also... note that I changed how you are getting the first visible column. I'm not sure why your code is using a 'using' statement there, but it seems to me that if you do it like that, the column will get disposed as soon as they code block exits. So I don't see how that can possibly be working for you, unless the code you are using is somehow cloning the column.