I will do my best to explain this senario.
I am using an UltraGrid to display data of which I will have no knowedge of at run time. I am parsing an xml file that will create a list of queries and their relations.
when I run through this squence of events the child bands do not display. Is it possible to add child data to the UltraGrid and display it? Am I doing this out of order somehow? Does the data have to be there before the expand event fires? Can I get any alternate suggestions? My biggest problem seems to be that Data is completely dynamic.
I seem to recall an issue that was fixed a while ago regarding populating the child band in the BeforeRowExpanded event, so depending on your version this may be the same issue. I hacked together a quick test, which seemed to work for me:
private static DataTable GetTable(){ DataTable dt = new DataTable(); dt.Columns.Add("Col 1", typeof(string)); dt.Columns.Add("Col 2", typeof(int)); dt.Columns.Add("Col 3", typeof(decimal)); dt.Columns.Add("Col 4", typeof(bool)); dt.Columns.Add("Col 5", typeof(DateTime)); for (int i = 0; i < 30; i++) { dt.Rows.Add(new object[] { "Row " + i.ToString(), i, i * 1.234m, i % 2 == 0, DateTime.Now.AddYears(i) }); } return dt;}public Form1(){ InitializeComponent(); DataSet ds = new DataSet(); DataTable dt = GetTable(); DataTable dt2 = new DataTable(); dt2.Columns.Add("Col 1"); ds.Tables.Add(dt); ds.Tables.Add(dt2); ds.Relations.Add(dt.Columns[0], dt2.Columns[0]); this.ultraGrid1.DataSource = ds;}private bool hasPopulatedChildBand;private void ultraGrid1_BeforeRowExpanded(object sender, Infragistics.Win.UltraWinGrid.CancelableRowEventArgs e){ if (this.hasPopulatedChildBand) return; DataTable dt = ((DataSet)this.ultraGrid1.DataSource).Tables[1]; dt.Columns.Add("Col 2", typeof(int)); dt.Columns.Add("Col 3", typeof(decimal)); dt.Columns.Add("Col 4", typeof(bool)); dt.Columns.Add("Col 5", typeof(DateTime)); for (int i = 0; i < 30; i++) { dt.Rows.Add(new object[] { "Row " + i.ToString(), i, i * 1.234m, i % 2 == 0, DateTime.Now.AddYears(i) }); } this.hasPopulatedChildBand = true;}
Is this roughly the same approach that you described (ignoring how you're getting your data, since that shouldn't be relevant)? I add a column and the DataRelation at first, but no data, and populate the child band once I try to expand a row. When I do this, the child data correctly shows up. If my approach is the same, then you should try to download the latest service release to see if the issue is resolved in your application.
-Matt
Yes, this almost look like my code, but I am still not showing the child data. I have checked the datasource while debugging and the updates are there in the table. Plus the child band reflects the changes to the columns, but when I check the cells in the row of the child band, its value is null.
I am already using the 2009.1 trial addition.
It's possible that something was fixed past the 9.1 release that affects this functionality. If you can post a sample project here that I can run, I'd be happy to see if it works in the latest version, or you could submit it to Developer Support so that they can look at it.
I found my issue. It is case sensitive when looking for relations values. The parent GUID, 1A6717C4-93BF-4317-95CD-71153904010E, uses capital letters and my child table was using lower case letters 1a6717c4-93bf-4317-95cd-71153904010e.
Can I turn that off or should I update the data as I am saving it to the child table?
I don't believe that you can control whether the relation names are case-sensitive or not; I think that this is mainly due to how the .NET BindingManager works as opposed to the grid. Is there any way for your child table to update the case of its GUID values? I'm not sure what you mean by "...update the data as I am saving it...", unless you mean to convert the GUID at this point, which seems like it would work to me.
What I am doing now is changing the casing of the values as I read them from the datareader. Thanks for all your help. I need to see a working copy of the code so that I know I was not going crazy. It took me hours to try to break your code so I can see what was so different in what we where doing. Turned out to be a data issue.
Thanks again.