Dear DevExpress Support,
I am facing a situation when having a master/detail scenario using 2 grids… Attached you can have the sample…
Basically the master grid is OK… But on the second grid(detail), when a row is expanded and I call the “Accept Changes” method on my dataset (there is a button on the form to call it), the expanded row gets collapsed… It is important to remark that on my scenario I have compound keys, but, this problem happen also with simple keys…
Can you help me to get this right?
Kind regards,
Pedro.
Ticket
B222491
Visible to All Users
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.
Hi Pedro,
Thank you for contacting us. We have researched this issue and realized that GridView collapsed master rows because it received the ListChanged event from the datasource with the ListChangedType.Reset parameter. In this situation, GridView returns into the initial state. This is the only appropriate reaction to this event, because it is not possible to predict changes made in the datasource.
Thus, this behavior is by design.
To avoid the issue with GridView row collapsing, you can simply expand a corresponding master row via the GridView.ExpandMasterRow method. Look at the following code:
int iFocusedRowHandle = gridView2.FocusedRowHandle; ds.AcceptChanges(); gridView2.ExpandMasterRow(iFocusedRowHandle);The most common approach for saving and restoring GridView state is described in the following article How to preserve the XtraGrid View state.
I hope you find this information helpful. Feel free to contact us if you need any further assistance.
Thanks,
Oleg
OK. Thanks for you response.
Actually I have researched the article from http://www.devexpress.com/scid=A2161 and the issue that I found out was that it actually only works for scenarions where there's no compound key.
On my sample I send you I have compound primary keys.
Do you have any implementation of this class supporting compound keys? Can you help me with that?
Kinbd regards,
Pedro
Hi Pedro,
I'm afraid it is impossible to rewrite this example to make it work with compound keys. It requires a single column with a unique value in order for the GetRowCellValue and LocateRowByKeyValue methods to work properly. I suggest you add a single column with unique values as a key.
Thanks,
Ted
Hi!
I cannot believe it is impossible. And I also believe that I am definitivelly not the first one to have such an issue.
Add one column with unique values is not an option in my scenario.
I'm little disappointed with DevExpress lately. If you look most of my previous questions are always not solved…
This issue is very crucial to my application and when I have to fix everything by myself, I start thinking if the usage of DevExpress Components is really bringing all value I expect for.
It is not the first time that I have to do a lot of effort to workaround very silly limitations from DevExpres…
Pedro
Hi Pedro,
I understand your concern, but I'm afraid there is nothing we can do here. Our data-aware controls aren't designed to work with compound keys, so without adding an additional data column this task cannot be solved.
Thanks,
Ted
Hi again,
Attached you can have the modified version of your sample program from http://www.devexpress.com/Support/Center/p/A2161.aspx converted to work with compound keys.
As you could see it was not impossible as you told. This just reflects how dissapointed I am with the support level that I amd getting from DevExpress. You did not even said: You should do yourself… You just said: It is not possible to solve?! If you are telling this kind of things to your customers, are you getting somewhere!?
Please watch yourselves and improve your support level. Otherwise you will start losing customers with this behavior.
Sorry for my tough words but I hope it helps you to take actions.
Br,
Pedro
Hi Pedro,
I apologize, the approach you implemented simply didn't come to my mind. I have reviewed the project you sent to me and I see that you are traversing through all matching values from all columns participating in a compound key. This approach might lead to performance problems, if you have a lot of rows. Anyway, I understand your concern and I'm happy to hear that you have managed to find this solution. Thank you for informing us of that.
Thanks,
Ted
Hi Ted,
Actually the sample from DevExpress that works without compound keys does things like:
for (int i = 0; i < view.DataRowCount; i++)
{
if (Equals(value, view.GetRowCellValue(i, descriptor.keyFieldName)))
return i;
}
So I did not invented that and I am fully aware of potential performance problems that I might have. But the problem is that I am not seeing another solution and the DevExpress support(which is intended to help me out) just said would be impossible. :)
To my mind the state should be kept internally by the grid itself as this is a expected feature from the people using the grid.
If you have any other proposition to improve performance please let me know.
Thanks!
Pedro
Hi Pedro,
I regret to tell you there is no another way to work with compound keys. All GridControl methods are designed to be used with the usual keys and the approach you have found is only way to work with this type of keys.
Thanks,
Ted