Bring some of the developers off XamRibbon and XamChart, and these largely pointless Caraosel controls, and let's clean up the bugs and issues with apparently established controls like XamDataGrid and XamEditors, there are issues with are present in the old forums from over six months ago that have still not been fixed, there are loads of issues in this forums which haven't even had an aknowledgement, compare this to Xceed and MSDN WPF and Infragistics seriously lacks behind, who signs off these projects as complete? You do have a basis for a good product if only you put a little more attention to them.
Some of my issues:
1) Cell resizing to fit content.. No other way than hardcoding pixels in declarative XAML, defeats point of WPF? CellWidth, CellMaxWidth, dont work with AutoFit and only accept double values rather than relative, WPF grid seems more powerful in this respect.2) XamEditors are badly broke... See example code in xameditors forum3) Databinding doesnt follow WPF principles , can't dot into stuff, converters etc.. Why break the standard? Seem to need to use CellValuePresenter on nearly all columns4) Extensibility poor, workarounds presented seem dirty
<igDP:XamDataPresenter x:Name="DP1" AutoFit="Treu" >
<igDP:XamDataPresenter.FieldLayoutSettings>
<igDP:FieldLayoutSettings>
<igDP:FieldLayoutSettings.DataRecordCellAreaGridTemplate>
<ItemsPanelTemplate>
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="Auto"/>
<ColumnDefinition Width="*"/>
</Grid.ColumnDefinitions>
</Grid>
</ItemsPanelTemplate>
</igDP:FieldLayoutSettings.DataRecordCellAreaGridTemplate>
</igDP:FieldLayoutSettings>
</igDP:XamDataPresenter.FieldLayoutSettings>
</igDP:XamDataPresenter>
To bind a Field to a sub-property of a record's property, you would need to create and add an UnboundField defintion to the FieldLayout.Fields collection. Here's an example of an UnboundField definition that binds to the DisplayName property of the record's Author property:
<igDP:FieldLayout>
<igDP:FieldLayout.Fields>
<igDP:UnboundField Name="author_displayname" BindingPath="Author.DisplayName", BindingMode="TwoWay" DataType="sys:string"/>
</igDP:FieldLayout.Fields>
</igDP:FieldLayout>
"matt83uk" wrote in message news:11768@forums.infragistics.com... Bring some of the developers off XamRibbon and XamChart, and these largely pointless Caraosel controls, and let's clean up the bugs and issues with apparently established controls like XamDataGrid and XamEditors, there are issues with are present in the old forums from over six months ago that have still not been fixed, there are loads of issues in this forums which haven't even had an aknowledgement, compare this to Xceed and MSDN WPF and Infragistics seriously lacks behind, who signs off these projects as complete? You do have a basis for a good product if only you put a little more attention to them. Some of my issues: 1) Cell resizing to fit content.. No other way than hardcoding pixels in declarative XAML, defeats point of WPF? CellWidth, CellMaxWidth, dont work with AutoFit and only accept double values rather than relative, WPF grid seems more powerful in this respect.2) XamEditors are badly broke... See example code in xameditors forum3) Databinding doesnt follow WPF principles , can't dot into stuff, converters etc.. Why break the standard? Seem to need to use CellValuePresenter on nearly all columns4) Extensibility poor, workarounds presented seem dirty http://forums.infragistics.com/forums/p/1289/11768.aspx#11768
is XamDataPresenter a private class or only in the full WPF version? I'm using express and when I put the
<igDP:XamDataPresenter x:Name="DP1" AutoFit="True" >
code in, I get a compiler error saying it cannot find it even though I have
xmlns:igDP=http://infragistics.com/DataPresenter
declared at the top. Ideas?
-Matt
1) Cell resizing - The solution works :) And despite being a little verbose way to accomplish it, it does the trick and rather cleanly.
2) Yes the XamEditors are badly broken in data binding, I have posted source code in that example that illustrates the problem in my post, this has been acknowledged as a bug now so presumably it will be fixed before the next release.
3) Again, it works :)
4) I think this could be partly down to documentation. Most of the answers are buried in the API section rather than the general tutorial content so unless I know the member name it is difficult to find the answer. Also I imagine a lot of newbies would fall at the first hurdle when attempting to override common behaviours by styling elements deep within the visual tree, I had to use Mole a few times to find the right type I need to style. Also if you use the online help, you'll run into lots of 404s in the API section, a link checker probably won't find them but whip up a little spider and you'll see what I mean. Whilst you can't cater for all scenarios, the common ones need to work out the box, I'm not sure why we have so many enums instead of an event handler, this could be refactored to have both, when an event is fired and an eventhandler is present this is executed rather than the restrictive enum behaviour.
When I wrote this post I was under a lot of pressure so I do apologise for the tone, and as illustrated some of issues are not relevant. However I have 2 genuine/verified bugs discovered within only a few days of using Infragistics WPF suite which are present in both 2007.1 release and 2007.2 beta, which is making me a little concerned, as the scenarios in which these appear in a real-world app are not rare (1) xamedtiors (2) validation exceptions throwing (see my posts).
I've had a replied from the Product Manager so hopefully we can open some constructive dialogue. Thanks for your help Joe, it is appreciated!