Hi, I have a wingrid embedded in a tab pane of a tab control. The wingrid displays data in 4 band levels. When clicking on a column header in the lowest band level, sometimes the wingrid will scroll to the top, causing the user to lose track of where they were. I have attached a short video that demonstrates the problem.
Thanks, Bill
The short video is attached.
Hi,
I've watched the video again and the problem seems to be very specific to a series of steps. I've tried this out in a very simple case with a grid in a Tab Control and three levels of grouping like it appears you have here, but I am unable to reproduce the issue.
My best guess is that this was a bug in an older version of the grid. What version of the grid are you using? I did my testing with 15.1 and the latest service release.
Another possibility is that there's something in your code that is causing the grid to re-position. The obvious way to do that would be to set the ActiveRow, set the FirstRow on the RowScrollRegion, or call ScrollRowIntoView. It could also happen if the grid is re-building the rows collection, which it would do if the grid's DataSource sends a Reset notification. The obvious place to look for these kinds of things would be in the BeforeSortChange or AfterSortChange events, which will fire when you click the column header.
Also, you specifically mentioned that the grid is inside a tab control. That seems unlikely to be a factor, but since you mentioned it - is there some reason you think that's related? Have you tried taking the grid out of the tab control?
If none of that helps, it might be a good idea to put a breakpoint in the BeforeRowRegionScroll event of the grid. Disable the breakpoint, then get the grid into a state where the problem will occur when you click on the column header and enable it and then click the header. Frankly, this is kind've a grasping-at-straws approach, because the call stack will probably show that the scroll started with the grid's Paint event, which doesn't really tell us much, but on the off chance that it's something else, it might be worthwhile and it's something very easy to try.
If that's still no good, we will probably need a small sample project demonstrating the behavior so we can debug it and check it out.
Hi Mike,
I am using Infragistics version 2012.1. I looked through the code looking for something that would make it reposition, but didn't find anything, i.e. I looked at all occurrences of ActiveRow, FirstRow, RowScrollRegion and ScrolLRowIntoView. How would the DataSource send a Reset notification? Nothing is going on with the DataSource as far as I can tell. I created a BeforeSortChange handler and set a breakpoint in it but the only code in the call stack was Infragistics and System.Windows.Forms.
I tried setting a breakpoint in the BeforeRowRegionScroll event handler but everything in the call stack is just Infragistics and System.Windows.Forms.
Regarding taking the grid out of the tab control I was thinking of doing that, i.e. progressively dismantling the app until the problem can be isolated. Then once isolated I should be able to create a sample project and send it to you. I will pursue this.
Thanks,
Bill
Hi Bill,
wugates said:How would the DataSource send a Reset notification?
The DataSource will send a Reset in response to some action that may change a lot of rows or the entire data structure. For example, if you are using a DataSet and you use a DataAdapter.Fill to fill a table, this will cause a Reset. There are others, of course.
wugates said: I created a BeforeSortChange handler and set a breakpoint in it but the only code in the call stack was Infragistics and System.Windows.Forms.
If you could post the call stack so I can see where it's coming from it might give us a clue.
wugates said:Regarding taking the grid out of the tab control I was thinking of doing that, i.e. progressively dismantling the app until the problem can be isolated. Then once isolated I should be able to create a sample project and send it to you. I will pursue this.
That's probably the most reliable way to see for certain exactly what's happening. If I can reproduce it here, I can track it down for sure. :)
There isn't anything occurring with the DataSource while the user is scrolling and sorting the grid, so no resets should be occurring.
Regarding the BeforeSortChange call stack see below.
One other thing I noticed. When this scrolling problem occurs, the grid's BeforeRowRegionScroll handler is not being invoked. But if I manually scroll the grid it does.
Call stack:
> ProductionScheduler.dll!QAD.Plugin.PlanningScheduling.SequencingGridControl.Grid_BeforeSortChange(object sender, Infragistics.Win.UltraWinGrid.BeforeSortChangeEventArgs e) Line 66 C# Infragistics.Win.UltraWinGrid.dll!Infragistics.Win.UltraWinGrid.UltraGridBase.OnBeforeSortChange(Infragistics.Win.UltraWinGrid.BeforeSortChangeEventArgs e) + 0x87 bytes Infragistics.Win.UltraWinGrid.dll!Infragistics.Win.UltraWinGrid.UltraGrid.FireEvent(Infragistics.Win.UltraWinGrid.GridEventIds id, System.EventArgs e) + 0x972 bytes Infragistics.Win.UltraWinGrid.dll!Infragistics.Win.UltraWinGrid.UltraGrid.FireCommonEvent(Infragistics.Win.UltraWinGrid.CommonEventIds id, System.EventArgs e, bool checkInProgress) + 0x154 bytes Infragistics.Win.UltraWinGrid.dll!Infragistics.Win.UltraWinGrid.SortedColumnsCollection.ProcessNewSortedColumnsHelper(Infragistics.Win.UltraWinGrid.SortedColumnsCollection newSortedColumns, bool fireEvents, bool groupBy) + 0x3a5 bytes Infragistics.Win.UltraWinGrid.dll!Infragistics.Win.UltraWinGrid.SortedColumnsCollection.SetSortedColumn(Infragistics.Win.UltraWinGrid.UltraGridColumn column, Infragistics.Win.UltraWinGrid.SortIndicator sortIndicator, bool groupBy, bool clearExistingNonGroupByColumns, bool fireEvents) + 0x5c8 bytes Infragistics.Win.UltraWinGrid.dll!Infragistics.Win.UltraWinGrid.UltraGridBand.SetSortedColumn(Infragistics.Win.UltraWinGrid.UltraGridColumn column, Infragistics.Win.UltraWinGrid.SortIndicator sortIndicator, bool clearExisting) + 0x60 bytes Infragistics.Win.UltraWinGrid.dll!Infragistics.Win.UltraWinGrid.UltraGridColumn.ClickSortIndicator() + 0x1c4 bytes Infragistics.Win.UltraWinGrid.dll!Infragistics.Win.UltraWinGrid.HeaderUIElement.EndDragHelper(bool cancelled) + 0x1bf bytes Infragistics.Win.UltraWinGrid.dll!Infragistics.Win.UltraWinGrid.HeaderUIElement.OnMouseUp(System.Windows.Forms.MouseEventArgs e) + 0x24 bytes Infragistics.Win.dll!Infragistics.Win.ControlUIElementBase.ProcessMouseUpHelper(object sender, System.Windows.Forms.MouseEventArgs e) + 0xa3 bytes Infragistics.Win.dll!Infragistics.Win.ControlUIElementBase.ProcessMouseUp(object sender, System.Windows.Forms.MouseEventArgs e) + 0x16e bytes Infragistics.Win.dll!Infragistics.Win.Utilities.ProcessEvent(System.Windows.Forms.Control control, Infragistics.Win.ControlUIElementBase.ProcessEvent eventToProcess, System.EventArgs e) + 0x3dc bytes Infragistics.Win.dll!Infragistics.Win.UltraControlBase.OnMouseUp(System.Windows.Forms.MouseEventArgs e) + 0x2a bytes System.Windows.Forms.dll!System.Windows.Forms.Control.WmMouseUp(ref System.Windows.Forms.Message m, System.Windows.Forms.MouseButtons button, int clicks) + 0x274 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x892 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) + 0x11 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x39 bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x80 bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m) + 0xfb bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x5 bytes Infragistics.Win.dll!Infragistics.Win.EditorWithMask.AccessibleTextManager.AccessibleTextSubclasser.WndProc(ref System.Windows.Forms.Message msg) + 0xbb bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x80 bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m) + 0xfb bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x5 bytes Infragistics.Win.dll!Infragistics.Win.FormattedLinkLabel.FormattedLinkEditor.AccessibleTextManager.AccessibleTextSubclasser.WndProc(ref System.Windows.Forms.Message msg) + 0xac bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x80 bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m) + 0xfb bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x5 bytes Infragistics.Win.dll!Infragistics.Win.FormattedLinkLabel.IMENativeWindowManager.IMENativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x4c bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x80 bytes [Native to Managed Transition] [Managed to Native Transition] System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(System.IntPtr dwComponentID, int reason, int pvLoopData) + 0x24d bytes System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason, System.Windows.Forms.ApplicationContext context) + 0x155 bytes System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) + 0x4a bytes System.Windows.Forms.dll!System.Windows.Forms.Application.Run(System.Windows.Forms.Form mainForm) + 0x31 bytes QAD.Shell.exe!QAD.Shell.ShellLoader.StartGui(string[] args) + 0xa7f bytes [Native to Managed Transition] QAD.Client.exe!QAD.Shell.Bootstrap.Main(string[] args) + 0xbb7 bytes
Sorry, that's the wrong event. I meant BeforeRowRegionScroll, actually. But if that's not firing, then maybe you could try AfterRowActivate and post the call stack from there. To be honest, it probably won't help, but it might give us an idea and it's a lot quicker than creating a small sample project so it might be worth a shot.
Well, that makes sense, I suppose. Store the row and then restore it's position. Thanks for the update.
It would still be nice to know why it's happening in the first place, though.
Our staff discovered a clever workaround fix for this which is to implement BeforeSortChange and AfterSortChange handlers to reposition the scroll bar:
void OnBeforeSortChange(object sender, BeforeSortChangeEventArgs e)
{
//remember current scroll position _scrollPosition = this.ActiveRowScrollRegion.ScrollPosition; }
void OnAfterSortChange(object sender, BandEventArgs e) {
//restore remembered scroll position this.ActiveRowScrollRegion.ScrollPosition = _scrollPosition; }
Regards,
Let's close it for now because I don't know when the other group will be able to get to it.
Do you have any kind of estimate as to when you will be ready to revisit this issue? If you know when, I can put the case on hold and check back with you then. Otherwise, it might be better to just close this came and you or someone at your company can open a new one when you have time. :)
Not yet. I've been sidetracked with some other responsibilities. I may need to turn this over to another group in my company.