Question about "advanced" databinding

Hi everyone,
I'll try to make this as detailed as possible. I am writing an application that requires me to pull out multiple different tables from a database. Basically, I'm pulling out 21 different tables with a wide range of rows inside those tables (from 0-1000's). The 21 tables are 21 different types of tests, and the data stored in those tables are all of the different tests of that type and the values gathered from the test. I am attempting to display the data in a fashion like this:

Name of BaseTest (expander)
ListView (Has ALL the test from ALL the different test types)
Name of SecondTest(expander)
ListView....
(Continued for the 21 tests done)

My problem is that I am fumbling with how to go about storing/binding the data. I've spent all afternoon playing around with using an array of datatables, a big dataset, an arraylist, and I even tried writing a function to go and bind the data to the right source. I've got single source databinding down really well, but now that I'm into single source with multiple different sets of values, I'm in over my head again.

Is there a way to pull paths from one of these lunker datasets so I can reference them in the XAML tags?
e.g:
<Page.Resources>
<Style TargetType="{x:Type ListBoxItem}" x:Key="ResultsItem">
<Setter Property="Template">
<Setter.Value>
<ControlTemplate TargetType="{x:Type ListBoxItem}">
<Grid>
<Expander Name="exp_Info" Header="{Binding Path=Name1}">
<ListView Height="300" Name="lv_ExpandedInfo">
<TextBlock>
<TextBlock Text="{Binding Path=InnerTable.Name1}"/>
<TextBlock Text="{Binding Path=
InnerTable.ID}"/>
<TextBlock Text="{Binding Path=InnerTable.Result}"/>
<TextBlock Text="{Binding Path=InnerTable.Result2}"/>
</TextBlock>

</ListView>
<!--<Frame Source="{Binding Path=Description}" /> -->
</Expander>
</Grid>
</ControlTemplate>
</Setter.Value>
</Setter>
</Style>
</Page.Resources>

Or something similar to that manner? I'm not sure what the best way is for doing this.

The C# running in the back looks like this (edited):

DataSet dsTables = new DataSet(); //new dataset
foreach (DataRow row in dtContainingAllTables.Rows)
{
String sqlGetCommand = "get stuff from db"
DataTable dtTemp = databaseObj.SQLSelect_Generic(sqlGetSpecificMetrics);
try
{
int iTemp = (Convert.ToInt32(row["ID"]) - 1);
//if the table is empty don't put it in the set
if (dtTemp.Rows.Count == 0)
Console.Out.Write("No data in table\n");
else
dsTables.Tables.Add(dtTemp);
}
catch (Exception)
{
//
}
}
listboxOnPage.DataContext = dsTables;

Just an added note, I've thought about making a class to hold the test items, and do binding that way, but I feel that that would kill the applications speed having to go and make all those objects and then load them in. (All of this is being controlled by a selected item, which could change instantly.. so the data does have to move around fairly rapidly)

Any help would be greatly appreciated.. I'm really kind of stuck on this one, and I need it to work to be able to move on. If there is something I missed please don't be afraid to point it out! :-P
Thanks in advance,
~Elliot

[6471 byte] By [enf_Elliot] at [2008-1-4]
# 1

Hi Elliot,

If I understand you correctly, your users want to see a mass of data resulting from 21 odd tests, then the data from each test.

I’m not going to give you a programming solution, because I think what your trying to do is bad for you and your users, even if they don’t know it.

Each test could result in a lot of rows of data? If so, the problem you have here is not one of implementation, it’s one of education.

Ask yourself, why does a users want to see so much data? Would they not be able to make a business decision based on a summary of the data? If they really want to see such detail, why not present it differently?

For example, using your tests, what’s the data that’s most interesting? I guess that it’s what tests passed and failed. Present that to your users first. Forget about detail. Give them a way of viewing the detail in a separate form or page.

Expanders et al are not designed for handling large amounts of data. Just a few choices, no more.

Users that are used to seeing spreadsheets will expect to see large amounts of data. In reality, they only want simple information to enable them to do their jobs. Sifting through large sets of data only makes them less efficient.

By all means, allow them to drill into your test results, but don’t give yourself a databinding nightmare because of it.

I sat in on a meeting recently where the original brief was a report that would have resulted in a spreadsheet that had over 17,000 rows. It turned out that the person that asked for the report needed five rows and six columns of data. He didn’t even need a drill down.

Sorry if that does not help now, but I hope it helps in the long run.

Pad at 2007-10-3 > top of Msdn Tech,Visual Studio Orcas,Windows Presentation Foundation (WPF)...
# 2
Hey Pad,
I understand what you mean. The people I'm doing this for want to be able to view all of this data, unfortunately. There is a summary of that test run with which tests failed, and then the expanders were meant to give them (The people working in the Metrics group) the ability to click and view all of the data collected (This was a specific request). I had thought about using trees to do this, but we both noticed.. After going home and looking at it, and reading your post I've admitted to myself that this will turn into a databinding nightmare quickly. I think you had some really valid points about throwing too much at the user at once, or making them sift through things, so I will be trying to keep that in mind while designing this part of the app.

I know that some of the guys wanted a "dashboard" look and feel, so perhaps I'll make a piece of that where they can drill down into the data as much as they want, and just keep the basics on the screen until the user does so.

Thanks for your help!
~Elliot

enf_Elliot at 2007-10-3 > top of Msdn Tech,Visual Studio Orcas,Windows Presentation Foundation (WPF)...

Visual Studio Orcas

Site Classified