Good day,

I'm trying to get a WPF application working that has a simple GridView to display the contents of a CompanyCollection.

It seems, though, that as an ObjectDataProvider the LLBLGen Pro generated classes do not play nicely.

I have the following defined in my window:

    <Window.Resources>

    <ObjectDataProvider x:Key="CompanyCollectionDS" d:IsDataSource="True"  ObjectType="{x:Type llblgen:CompanyCollection}" />
    
        <DataTemplate x:Key="ItemsTemplate">
            <StackPanel>
                <TextBlock Text="{Binding Path=CompanyId}"/>
                <TextBlock Text="{Binding Path=ContactNumber}"/>
                <TextBlock Text="{Binding Path=ContactPerson}"/>
                <TextBlock Text="{Binding Path=Name}"/>
            </StackPanel>
        </DataTemplate>

  </Window.Resources> 

This sets up the resources I need for my grid, primarily a data source that is of type CompanyCollection from the llblgen namespace. The llblen namespace is declared at the top of the document as the assembly/namespace which contains my generated collection classes.

Also in there is the template for the grid layout, which renders correctly.

Finally, the GridView is declared as follows:

    <Grid x:Name="LayoutRoot">
    <ListView d:UseSampleData="True" Margin="64,0,306,101" VerticalAlignment="Bottom" Height="100" ItemTemplate="{DynamicResource ItemsTemplate}" ItemsSource="{Binding Path=Items, Mode=Default, Source={StaticResource CompanyCollectionDS}}" IsSynchronizedWithCurrentItem="True">
            <ListView.View>
        <GridView AllowsColumnReorder="True">
          <GridViewColumn Header="ID" DisplayMemberBinding="{Binding Path=CompanyId}" Width="50"/>
          <GridViewColumn Header="Name" DisplayMemberBinding="{Binding Path=Name}" Width="200"/>
        </GridView>
      </ListView.View>
        </ListView>
    </Grid>

I have added the connection string to the App.Config file and am able to retrieve the connection string from the app through ConfigFileHelper, so I know that entry is correct.

I can create an instance of, for example, a CompanyCollection and List.Count has the right number of elements.

SOOOOO....the generated code seems to have everything it needs to get itself talking with the DB, but when the collection is used as a DS it doesn't seem to output any data.

Any ideas on WPF binding?

Cheers, James Chambers

I'm surprised you have trouble binding the collection classes because the collection classes implement ITypedList, IBindingList (all through the entity view) and IListSource, and all entities implement INotifyPropertyChanged which is necessary to get events hooked up by WPF.

What you have to do still is fetch the data. This is similar to what you do when you create a winforms form and drag a bindingsource + collection on the form: nothing happens. You have to fetch the data manually. Is this what can be the case?

There's no Datasourcecontrol for WPF similar to what we have for ASP.NET (LLBLGenProDataSource(2))

How would you otherwise expect that the objectdataprovider was able to fetch data?

I think what you describe is what is happening. I'm using self-servicing, so I'm familiar with LLBLGenProDataSource (without the 2).

Is this an effect of the lazy-loading?

I have the option in XAML to call a method that returns the list of data, with the ability to pass in parameters. Which of the methods would you suggest?

Cheers & thanks for the help/direction,

James

I think the entityCollection should be initialized first. And then you should try to call its GetMulti() method.

Walaa wrote:

I think the entityCollection should be initialized first. And then you should try to call its GetMulti() method.

Your suggestion is how we have it implemented, but it's not something you can do in XAML, which is what we suspected.

I guess, for now, we use the code-behind .cs files.

A couple of us here are working on some generics that we hope we can build into the template engine and use in partial classes to enable XAML-only bindings.

cheers, -jc

For XAML usage, indeed something like a datasourcecontrol is required. We won't have one till Orcas is fully released ,so for the time being, code-only approaches is what's there.

The decision to push this further away is made on the fact that MS doesn't have a developer-oriented designer for WPF out anyway (I don't see the expression stuff as a developer tool)