Bug Report T110105

Visible to All Users

Duplicate

Master rows are collapsed when the ListChanged event is raised

Vince Noga

created 11 years ago (modified 11 years ago)

I have a Visual Studio 2008 application targeting Dot 3.5 using Dev Express v2012 version 2.16. In my application I have a GridControl with a master-detail relationship where the GridControl is configured to Auto-Zoom the detail.

When I expand the Customer master record, the Part Number detail GridView is displayed. When in the Part Number GridView I am able to do everything except post data changes. There are two problems.

One, if I select a cell, modify the data, and the use the up or down arrow key to scroll off the current record and thus fire the RowUpdated event the follow except is thrown
=======
System.NullReferenceException was unhandled
Message="Object reference not set to an instance of an object."
Source="DevExpress.XtraGrid.v12.2"
StackTrace:
       at DevExpress.XtraGrid.Views.Grid.Handler.GridRegularRowNavigator.OnKeyDown(KeyEventArgs e)
       at DevExpress.XtraGrid.Views.Grid.Handler.GridHandler.OnKeyDown(KeyEventArgs e)
       at DevExpress.XtraGrid.Views.Grid.Handler.GridHandler.ProcessKey(KeyEventArgs e)
       at DevExpress.Utils.Controls.BaseHandler.ProcessEvent(EventType etype, Object args)
       at DevExpress.XtraGrid.Views.Base.Handler.BaseViewHandler.ProcessEvent(EventType etype, Object args)
       at DevExpress.XtraGrid.GridControl.RaiseEditorKeyDown(KeyEventArgs e)
       at DevExpress.XtraEditors.Container.EditorContainer.DevExpress.XtraEditors.Container.IEditorContainer.OnEditorKeyDown(KeyEventArgs e)
       at DevExpress.XtraEditors.BaseEdit.OnEditorKeyDown(KeyEventArgs e)
       at DevExpress.XtraEditors.TextEdit.OnEditorKeyDown(KeyEventArgs e)
       at DevExpress.XtraEditors.BaseEdit.OnKeyDown(KeyEventArgs e)
       at DevExpress.XtraEditors.TextEdit.OnMaskBox_KeyDown(Object sender, KeyEventArgs e)
       at System.Windows.Forms.Control.OnKeyDown(KeyEventArgs e)
       at DevExpress.XtraEditors.Mask.MaskBox.OnKeyDown(KeyEventArgs e)
       at System.Windows.Forms.Control.ProcessKeyEventArgs(Message& m)
       at DevExpress.XtraEditors.Mask.MaskBox.ProcessKeyEventArgs(Message& m)
       at System.Windows.Forms.Control.ProcessKeyMessage(Message& m)
       at System.Windows.Forms.Control.WmKeyChar(Message& m)
       at System.Windows.Forms.Control.WndProc(Message& m)
       at System.Windows.Forms.TextBoxBase.WndProc(Message& m)
       at System.Windows.Forms.TextBox.WndProc(Message& m)
       at DevExpress.XtraEditors.Mask.MaskBox.BaseWndProc(Message& m)
       at DevExpress.XtraEditors.Mask.MaskBox.MaskStrategy.SimpleStrategy.DoWndProc(Message& m)
       at DevExpress.XtraEditors.Mask.MaskBox.WndProc(Message& m)
       at DevExpress.XtraEditors.TextBoxMaskBox.WndProc(Message& msg)
       at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
       at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
       at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.Run(Form mainForm)
       at WindowsFormsApplication1.Program.Main() in D:\VSN2008\MyDocuments\Projects\Net35\TestWindowsFormsApplication\WindowsFormsApplication1\Program.cs:line 17
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
InnerException:
=======

Two, if I select a cell, modify the data, and use a ControlNavigator’s EndEdit button to post the data change, while the data posts, the GridControl closes the Part Number GridView detail and reverts to displaying the Customer master GridView, which should not happen.

Both these issues need to be fixed. Neither of these issues existed in Dot Net 2.0 using Dev Express v2011 version 1.10. When I reverted my current Dot 3.5 / DevX 12.2.16 application back to Dot Net 2.0 / DevX 11.1.10 both problems above went away. In addition, I have an older, existing, similar Dot 2.0 / DevX 11.1.10 application that works fine as well, which is what prompted me to revert my current application back to Dot Net 2.0 / DevX 11.1.10 in the first place.

I am attaching a sample (or will when you request it… this won't go through with the sample attached). I hate to have to mark this as urgent, but I don’t want to deliver my current customer project as a Dot 2.0 / DevX 11.1.10 application.

Any help with this will be appreciated.

Thanks,

Vince

TestApp.zip

Show previous comments (2)

DevExpress Support Team 11 years ago

Hi Vince,

Thank you for your patience. I can't reproduce this issue on my side. I have attached my project. Test how it works on your side. Is the issue reproducible with it? We had a similar issue before. Review the NullReferenceException when editing in an detail grid and reloading datasource ticket. In that ticket, the cause of the issue was that the Grid data source was changed in the data source' ListChanged event handler. This broke the normal Grid behavior. Check if you have similar code in your project. If it's not the case, please provide us with a small project that illustrates the issue.

dxSample.zip

Vince Noga 11 years ago

I have downloaded your example but still cannot attach mine. How small does it have to be? Everything is in a zip file that is all of 264 KB.

Vince Noga 11 years ago

Your example is not posting data changes. My app posts data changes to the database in the GridView's RowUpdated event. This works fine using DevExpress v2011 version 1.10. Use DevExpress v2012 version 2.7 to 2.16, that exact same code causes access violations and diplay glitches. Didn't try DevExpress versions in between, so I'm not sure where/when the master/detail quit working as it did in 11.1.10.
Please let me know how to submit my sample.
Thanks.

Answers approved by DevExpress Support

DevExpress Support Team

created 11 years ago (modified 7 years ago)

We have fixed the issue described in this ticket and will include the fix in our next maintenance update. To apply this solution before the official update, request a hotfix by clicking the corresponding link for product versions you require.

Note: Hotfixes may be unavailable for beta versions and updates that are about to be released.

Additional information:

We have decided to persist the current behavior, i.e. collapse detail views when the ListChanged is raised with Reset type = Reset. However, due to many requests from many customers, we also provided an opportunity no prevent collapsing detail views in this case. This behavior can be enabled by using the CollapseDetailRowsOnReset property at the internal DataController class level:

C#
gridView1.DataController.CollapseDetailRowsOnReset = false;

(Take special note the DataController property is not visible in IntelliSense)

In older versions, store the Grid's state using the approach illustrated in the How to preserve the XtraGrid view state in multi level master/detail example.

v14.1.4Download Official Update

Show previous comments (3)

Yannik 7 years ago

unfortunately its still collapsing, even with this property set to false. I'm using v17.1

DevExpress Support Team 7 years ago

Hello,

I've created a separate ticket on your behalf (T625346: Master rows are collapsed when the ListChanged event with Reset is raised). It has been placed in our processing queue and will be answered shortly.

Vince Noga 7 years ago

I received a notification when you commented.

Concerned about my applications that still rely on this feature and are compiled against v17.x, I tested them.

Assigning "false" to CollapseDetailRowsOnReset works right for me. Here's an excerpt of my code:

private void frmAEDCustomerVehicle_Load(object sender, EventArgs e)
       {
           //The GridView's DataController Property is not visible to intellisense.
           //DevExpress added the CollapseDetailRowsOnReset property in 14.1.4 to
           //enable restoring the default master/detail behavior in 11.1.10.
           gvCustomer.DataController.CollapseDetailRowsOnReset = false;

//Save the grids designed layout
           dbGrid.ForceInitialize();
           gvCustomer.SaveLayoutToStream(FCustomerGridLayout);
           gvVehicle.SaveLayoutToStream(FVehicleGridLayout);

Vince Noga 7 years ago

Actually, it is broken in 17.1.7. If you edit and post on the master record while the detail is expanded, the detail, while the detail itself remains expanding, all the detail records disappear from the display.

With 17.2.7 this doesn't occur and works fine.

Yannik 7 years ago

thanks for your answers. I posted in new ticket opened by Svetlana.

Sasha (DevExpress Support) 7 years ago

Hello Vince and Yannik,

@Vince
To process your recent post in the most efficient manner, I've created a separate ticket on your behalf: GridControl - Detail view's rows disappear after editing the key column in the master view. I will address it shortly.

@Yannik
I see your comment in the Master rows are collapsed when the ListChanged event with Reset is raised thread. Let's continue the discussion there.

DevExpress Support Team

created 11 years ago

Hi Vince,

Thank you for your project. The cause of the issue is that you call the DataSet.AcceptChanges method in the GridView.RowUpdated event handler. This sends the Reset notification to the Grid and the latter recalculates its layout. To resolve the issue, save changes via BeginInvoke and save the current expanded master row to expand it again after calling the DataSet.AcceptChanges method. This behavior is described in the Q483431 ticket. I have attached a modified project.

dxSample.zip

Show previous comments (5)

Vince Noga 11 years ago

I appreciate the example, however you have just worked around bugs that didn't exist. I have converted the sample project we have been passing back and forth to .Net 2.0 and DevX 11.1.10 .dll files and commented out the workaround code you added. As you can see, the issues you worked around do not exist in the first place. What's more, the workaournd is not sufficient. The screen flicker caused by re-expanding the master row after the fact is terrible.
May I ask why the workaround code you provided is required now? In the past the GridControl did not have the problems I'm reporting.

TestApp1.zip

Yaroslav (DevExpress Support) 11 years ago

Hi Vince,
Thank you for the project. Indeed, the Grid works differently with version 11.1.10. I'm going to discuss this behavior with our developers to see what changes caused this behavior and whether or not Gosha's workaround is required in this situation.
We'll come back to you as soon as we can. Please bear with us.

Yaroslav (DevExpress Support) 11 years ago

Vince,
We've instigated this behavior and found that it was caused by fixing the issue reported by another customer. Here is the corresponding report: GridControl - Master Rows are not collapsed when the IBindingList.ListChanged event is raised with the ListChangedEventArgs.ListChangedType property set to Reset. So, from a technical point of view the GirdControl works correctly and listens to the underlying datasource events. Unfortunately, as was explained above, the DataSet.AcceptChanges method internally calls the ListChanged event and this causes detail view collapsing. The only feasible workaround we see is to use Gosha's suggestion with posting changes asynchronously via BeginInvoke.
I hope this information helps.
Should you need any further assistance, don't hesitate to contact us.

Vince Noga 11 years ago

I'm not sure what to do here. AcceptChanges() commits all the changes made to the DataSet since it was loaded or since the last time AcceptChanges() was called. All AcceptChanges() does is iterate through the changes, setting Added and Modified rows to Unchanged and removing rows that were deleted. None of this should affect the what is currently being displayed by the GridControl. Added/Modified rows are already displayed. Deleted rows are already removed from view. Even with AcceptChanges() raising the ListChanged event with ListChangedType.Reset, for this case the GridControl does not need to refresh itself with all the data from the list. The GridControl is already correct and showing the current state of affairs.
Anyway, putting this aside, I need a workaround that doesn't cause screen flicker. I need a solution where the end user will not be aware the detail view and its current focused DataRow was lost and then restored. The current workaround causes screen flicker and while the detail view is restored by re-expanding the master row, the detail view's row that was focused when the detail view disappeared is not restored.
What code can be written to recreate the 11.1.10 behavior? What code was used in 11.1.10 to ignore or not listen to ListChangedType.Reset? Not being built-in to the GridControl any longer is fine as long as I can recreate the behavior.

Vince Noga 11 years ago

There is also the issue that the master row should not always be re-expanded. If the user simply edits the master record and posts the change, the master row should not be expanded. The user wasn't viewing/editing records in the detail view.

Vince Noga 11 years ago

For the record, I ran the user's sample for B213226. I agree the issue needed to be fixed. But at the same time, the GridControl also needs to support the behavior of 11.1.10. To me both use cases are valid and need to behave correctly. Also, you have the code for both scenarios, cannot a new boolean property be added to toggle the behavior? Depending on the situation neither implementation always provides the desired result, but with both implementations and a new boolean property an application developer could achieve the desired result, by simply changing a property setting. Thoughts?

Yaroslav (DevExpress Support) 11 years ago

Hi Vince,
I'm afraid there is no such workaround that will remove the flickering issue completely in the current version of our components. As for a custom property, I agree with you that it will be useful for many customers. I'll contact our developers again to check if it's possible to implement such an approach without breaking the existing functionality. I'll reply in this ticket once I have any results.

Vince Noga 11 years ago

Yes, while I was able to code around the rest I could not get rid of the flickering. For now, I'm just going to deploy my app with the 11.1.10 .dll files.
I look forward to hearing the Developers reply.

Created: May 24, 2014 7:28 PM

Modified: August 30, 2018 2:13 PM

Platform: WinForms

Product: XtraGrid Suite

Build: 12.2.16

IDE: Microsoft Visual Studio 2008

Reproduced: True

Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

Master rows are collapsed when the ListChanged event is raised

Answers approved by DevExpress Support

Recently viewed tickets