I've been very happy with the DevExpress controls. I've had no issues related directly to CSLA other than the parent + child collection in a grid issue a couple of weeks ago. That turned out to be mostly an exercise in how Windows DataBinding works with CSLA child collections and grids. (The DevExpress grid does indeed work slightly different than the standard Windows one but that was only the last 10% of solving the problem.)
Their layout control is way cool. If you want you can go as far as allowing users to customize the layout of the forms. But in any event it makes creating nice layouts a snap. Similar to the new layout controls in .NET 2.0, but these actually work in a useful way.
I got their whole suite with source code for the reason you state - by the time you buy the second product individually the price is the same.
The controls are also null friendly, but I imagine that's not so unique. Don't need SmartDate at all.
I know you don't want a feature commercial, but I've gotten a big boost in UI productivity from using these controls.
We've used infragistics for a few years now, and like other users in here have tried other controls and gone back to infragistics.
The only thing I don;t like about infragistics is there controls seem to make my screen draw slowley. If I bind to a standard MS grid the screens show up instantly, but the infragistics stuffs sometimes make the apps look a little sluggish, i.e. you can see the different parts drawing (a bit annoying) <-- has anyone else had this, I get this on my xeon development machine which is even more annoying.
Even the infragistics text box controls when binded to objects seems to be a little sluggish when tabbing through them. Nothing bad but its like a half second delay or something that is only just noticiable but there and annoying (Probably just me, been too anal about things :) ).
Do the devexpress controls work well with CSLA, We use there Reporting controls Xtra Reports and its fantastic, so I may have a look into there controls now, never really looked at them.
Craig
Hello Craig,
Have you had a chance to create a Hierarchial Grid by creating a Parent Child Relationship using CSLA?If so can you please let me know how you did It.I am new to CSLA and right now working on a prototype to test the frameworks capability.I have created the parent and child classes but when I bind it the grid still displays just the parent reord.The viewtype of the Grid has been set to Hierarchial.I am using Infragistics controls
Thanks In Advance
bobfox:
yeah, VS 2005 is a Volkswagen, with Refactor! it's an Audi and with Coderush it's a Porsche ;-)
Infragistics: That's two votes, and both working successfully with CSLA. I guess we'll have to play with them to see if performance is a problem too. If they are easy enough to digest then
That reminds me of one of the biggest reasons I leaned towards Infragistics in the first place - and have gone back: One purchase and I have everything I need for both Windows and Web apps. You can count on 3 updates a year, so the products are constantly keeping pace and they have been incredibly quick at implementing the new stuff. They had a version of the MS Band control out around the same time MS actually released Office 2k7. And, for a little extra cash, you can have the source code which I have found incredibly helpful when trying to understand how things work - especially the client-side features.
I really like not having to learn multiple products in order to have a complete suite.
pelinville
"This last one really drives me nuts. THEY DO NOT HAVE A GOOD REPLACMENT FOR THE DEFAULT COMBO BOX CONTROL. The one they have you can't just bind to a datasource and then set the display/value members. This frustrates me to no end because in the middle of all the beutifully skinned controls I have these plain window combo boxes. "
Try the LookupEdit control instead of the ComboBoxEdit control. I believe that is what you are looking for.
as to 3rd party controls I am currently using devexpress, and have been very pleased with them.
I selected devexpress because I thought their design was more intuitive/ better than the others.
lawrencek:
pelinville
"This last one really drives me nuts. THEY DO NOT HAVE A GOOD REPLACMENT FOR THE DEFAULT COMBO BOX CONTROL. The one they have you can't just bind to a datasource and then set the display/value members. This frustrates me to no end because in the middle of all the beutifully skinned controls I have these plain window combo boxes. "
Try the LookupEdit control instead of the ComboBoxEdit control. I believe that is what you are looking for.
Two problems with that, maybe you can solve one of them for me.
First is a minor one. My users expect controls look a certain way. Anything new throws them for a loop and that thing with it's sorting and what not didn't sit with them very well. I could probebly figure this out if not for..
The second and big one (and the one I hope you can help me with) is that there is no way to tell what object is currently selected. When I ask devexpress about this they say I can get the id of the selected item. Problem is my "IDs" sre all marked with the "not bindable" attribute (guids are ugly and I don't want them accidently shown.)
So how can I find out the selected object? Not the value shown but the underlying object that the value corrisponds to.
pelinville
1. There are properties that control "AutoFiter" etc. so you can get similar behavior to standard combobox
2. Get datasource with following code
if (lookUpEdit1.EditValue != null)
{
CSLAItem myItem = (CSLAItem)lookUpEdit1.Properties.GetDataSourceRowByKeyValue(lookUpEdit1.EditValue);
XtraMessageBox.Show(myItem.ID.ToString());
}
Hope this helps.
Hi pelinville
I use the devexpress suite with the Csla and it works perfectly for me. I am curious about your lookupedit problems. Regarding the first one, what is it that looks different that your users don't like? You can make the drop down look more normal with the Properties.Columns property. Here you can set it to only show one column and then set ShowHeader to false to hide the column headers.
I don't understand why you mark your Ids with not bindable. I understand that guids are ugly, but you don't have to display them if you don't want to. All the controls allow you to configure what properties of an object get displayed. If you remove this attribute you can then set the ValueMember to the Id property and use the EditValue property to determine the currently selected item.
HTH.
Hi pelinville
I use the devexpress suite with the Csla and it works perfectly for me. I am curious about your lookupedit problems. Regarding the first one, what is it that looks different that your users don't like? You can make the drop down look more normal with the Properties.Columns property. Here you can set it to only show one column and then set ShowHeader to false to hide the column headers.
I don't understand why you mark your Ids with not bindable. I understand that guids are ugly, but you don't have to display them if you don't want to. All the controls allow you to configure what properties of an object get displayed. If you remove this attribute you can then set the ValueMember to the Id property and use the EditValue property to determine the currently selected item.
HTH.
The first problem is that it would require extra work to get it to look like a combo box. I know that can be overcome but I spend money on 3rd party control to avoid extra work.
And as far as preventing binding of the GUID, that is also just extra work in a whole bunch of places. To avoid this work we put thought up front to what a user does and does not need to see. We do this so that the GUI developer can focus on design and usability, not what fields should be hidden. That logic, to me, definitely falls in the realm of 'middle tier business rules'. Again spending money on a third party control should mean less work for me.
But there are other reasons. We also have allot of runtime generated forms that given a root object will build themselves. There are rare cases where a GUID should be seen by the user. So knowing when and when not to show a GUID becomes more work than I care to do.
And we have more than a handful of collections that contain objects which cannot be uniquely identified by any of the fields. Some of them are classes that use containment/aggregation of two or more other classes. These BO's don't have field(s) that uniquely identify them.
There are some places where the collections have objects whose IDs are the same. But still they are different objects and must be treated differently. An example of this is when we find a concurrency problem. The object that was previously loaded and modified is checked against the object freshly loaded from the DB and the user is choosing which one to use.
"Objects are defined by their behavior and not data". Following that I have found that often there is no data that uniquely identifies an object. I can only think of one or two places where I care what data is displayed/chosen by the user. ALL I care about is what object(s) the user has selected. Behavior takes over after that.
And in the end I find it absolutely mind boggling that with all the work they put into their controls they fail to have one that mimics one of the most highly used controls in windows forms.
pelinville
To respond to your points, even if we are straying a little off topic from the original question...
The first problem is that it would require extra work to get it to look like a combo box. I know that can be overcome but I spend money on 3rd party control to avoid extra work.
It takes me only a few seconds to set up a LookupEdit, and the extra functionallity the control provides makes this someting I can bear.
That logic, to me, definitely falls in the realm of 'middle tier business rules'.
Not sure I agree. If a user can't see a property for secuirty reasons then it should be in the middle tier. If they can't see it because you don't want them to see it for seom other reason than this is a UI issue IMHO.
And we have more than a handful of collections that contain objects which cannot be uniquely identified by any of the fields
Could you not use a composite key dervived from the properties that make the object unique? There have been some previous threads on doing this in this forum. You could return this in a property and use that to drive the combo.
There are some places where the collections have objects whose IDs are the same
Ah. I can see the problem here, haven't faced this one myself.
And in the end I find it absolutely mind boggling that with all the work they put into their controls they fail to have one that mimics one of the most highly used controls in windows forms
Think this is a bit harsh as it is very easy to setup the LookupEdit to mimic the ComboBox in the majority of situations. Just my two cents..
pelinville
To respond to your points, even if we are straying a little off topic from the original question...
The first problem is that it would require extra work to get it to look like a combo box. I know that can be overcome but I spend money on 3rd party control to avoid extra work.
It takes me only a few seconds to set up a LookupEdit, and the extra functionallity the control provides makes this someting I can bear.
That logic, to me, definitely falls in the realm of 'middle tier business rules'.
Not sure I agree. If a user can't see a property for secuirty reasons then it should be in the middle tier. If they can't see it because you don't want them to see it for seom other reason than this is a UI issue IMHO.
And we have more than a handful of collections that contain objects which cannot be uniquely identified by any of the fields
Could you not use a composite key dervived from the properties that make the object unique? There have been some previous threads on doing this in this forum. You could return this in a property and use that to drive the combo.
There are some places where the collections have objects whose IDs are the same
Ah. I can see the problem here, haven't faced this one myself.
And in the end I find it absolutely mind boggling that with all the work they put into their controls they fail to have one that mimics one of the most highly used controls in windows forms
Think this is a bit harsh as it is very easy to setup the LookupEdit to mimic the ComboBox in the majority of situations. Just my two cents..
I have to agree on all points with razor.
I didn't like the LookupEdit at first but now that I understand it I love it. I have never felt like it was terribly costly to make it work however I wanted, once I figured out how to do so (which I agree takes some up-front effort).
Saying it's a business layer responsibility to determine what looks bad in the UI seems self-contradictory to me. In fact, I'd personally suggest that that position is in fact a violation of the very principle you claim to be supporting. :)
Hi pelinville
I use the devexpress suite with the Csla and it works perfectly for me. I am curious about your lookupedit problems. Regarding the first one, what is it that looks different that your users don't like? You can make the drop down look more normal with the Properties.Columns property. Here you can set it to only show one column and then set ShowHeader to false to hide the column headers.
I don't understand why you mark your Ids with not bindable. I understand that guids are ugly, but you don't have to display them if you don't want to. All the controls allow you to configure what properties of an object get displayed. If you remove this attribute you can then set the ValueMember to the Id property and use the EditValue property to determine the currently selected item.
HTH.
The first problem is that it would require extra work to get it to look like a combo box. I know that can be overcome but I spend money on 3rd party control to avoid extra work.
I think there's maybe no point in going back and forth on the DevExpress control any further, but I for those reading this more generally I wanted to state that I personally think this is not a very good measure of the value of a 3rd party tool. I buy a tool to build a better product, in all the ways I measure better - more performant, more user-friendly, more maintainable, etc. It almost always requires "extra work" to make a better product, with a 3rd party tool or not.
I've never used the full suite from any other vendor, so I honestly can't say A is better than B. But I'd say the DevExpress LayoutControl is so powerful that the relatively minor cost of tweaking the LookupEdit compared to the efficiency of the LayoutControl is not enough to sway me.
In other words, my first paragraph above in this response is not meant to pick a fight, but rather to suggest that I've found any tool you buy is going to have limitations and quirks you have to discover the hard way. The question is always one of simple cost-benefit analysis. Asking the question "which suite gives me zero extra work working with CSLA" is perhaps the wrong question. Food for thought.
re: >> This last one really drives me nuts. THEY DO NOT HAVE A GOOD REPLACMENT FOR THE DEFAULT COMBO BOX CONTROL. The one they have you can't just bind to a datasource and then set the display/value members. This frustrates me to no end because in the middle of all the beutifully skinned controls I have these plain window combo boxes. <<
Have you tried their LookUpEdit control? It behaves as you seem to be describing here. Bind to the EditValue property and it works pretty well for me.
re:>> the thread subject in general....
I like the DevExpress stuff, too. Their forum participants are pretty helpful, but support is a bit slow sometimes.
The major benefit is that you have a controls suite AND a report tool all in the same package and there's pretty good consistency in all of it.
Microsoft uses Xceed controls in their latest Office products.
Just thought you might find it helpful.
Ben
I think it is which ever package you already know... I learned on Infragistics (and Sheridan Controls before that) and it had a huge learning curve... but now (and with Infragistics latest package) i will not look any where else.
I most like infragistics for the Win Controls.. the look and feel.. color gradients and apperances really make my apps look sweet. and of course their functionality
ward0093
Did you have any problems setting the datagrids datasource to be the CslaDataSource?? In my code the grid doesnt execute the SelectObject method of the CslaDataSource.
Any help would be really appreicated. Thanks
Hi Kip,
We are looking into using ComponentArt and CSLA.NET framework. We are running into basic issue of binding CslaDataSource to ComponentArt grid. Have you resolved this issue and how?
Thanks for any help, response in advance.
Regards,
I use Developer Express products without any complications. XtraEditors, XtraGrid, XtraBars and XtraNavBar are all products that can be used with CSLA-base projects.
For support matters, I can say that I am also very satisfied that I bought these products. Most Issues are solved within a day, sometimes it takes 2 days. I asked them CSLA related questions, and they are very aware of the existence of CSLA.
If you describe your problem properly, you don't need to send them your project or anything. For most common Issues they allready have sample project. Just use the right description of your problem. You can search their knowledge base for known issues. Again, use the right keywords for your problem.
For databinding; You use a bindingsource anyway. And DevExpress works great with the bindingsource. No Issues here.
As for any product, including CSLA; You should read the documentation first before you start working with the product.
I think I stay with CSLA, Visual Studio 2005, and Developer Express. Why? Because they are professional products.
Is it just me that uses ComponentOne controls?
I principly use the "Lightweight" list.net control to replace the windows Listview to display child lists etc.
I find the combo box much faster to bind than the Windows combo.
And if you need editable gird, then there's True DBGrid (or Flexgrid)
Cheers,
Graeme.
n.b. the Forums (at componenetone) could be better monitored.
Copyright (c) Marimer LLC