Hi Peter,

Thanks for the offer but it was Ertan who was asking about the DevExpress wrapper. I was simply sticking my big nose into it and questioning why so much emphasise was being placed on the wrapper when a BBS should have done the same job

Glad to hear you have the LookupEdit control working though with the BBS as it kind of proves the point and should be good news for Ertan.

Thanks,

Aaron

Hi Aaron,

We use DX and have no problems using the SF BBS. If you specifically have a problem with associating a BBS with (say) a lDX ookup edit let me know and I can take you through the steps we use.

Cheers, Peter

Hi

Have you used the ComboBoxEdit control? I mean the StrataFrame/DevExpress.

The LookUpEdit control has data binding, same with the ComboBoxEdit, so I think that you can easily use it in your application.

Kindest Regards

Everything is possible, just keep trying...

If you or I decide to use our controls in a certain way then that is our choice and the question is really who is responsible for doing this. Personally, I would like SF to write my entire application while I take a holiday but that isn't going to happen

I don't know much about DexExpress but as far as I can tell this control does support standard .NET databinding so a SF Business Binding Source should work. I am sorry but I don't see what a wrapper is going to give you here that a SF BBS doesn't already provide. I use similar controls in Infragistics with regular SF BBSs with no additional programming. It takes about 10 seconds to create a BBS/BO so there is no major overhead during development time.

While you are mainly looking for a wrapper for LookUpEdit, I simply don't see how SF (or any other company) is going to be able to come up with a wrapper for every single control from every third party control provider - it is a task I wouldn't want to do and the time spent doing this could only detract from moving the overall framework forward. As I have already said I don't see the point in doing it either - there is an Infragistics wrapper and I don't use it as I have no need to use it. I would fully expect that if I was using DevExpress then I wouldn't want to use a wrapper either. Now others may say they would like a wrapper but I am still waiting to hear what features a wrapper provides that isn't already available with straight forward data binding with a BBS.

If your real problem is speed as mentioned in one of your other threads then the BBS is not the cause and I doubt a wrapper is going to improve this either.

Sorry for being stupid but I simply don't see what a wrapper is going to give you and what therefore justifies the effort in SF providing a wrapper for each and every third party control on the market.

Aaron

Especially, Devexpress Wrapper for LookUpEdit.

Since I've decided to use devexpress, I want to use all of them as strataframe wrapped component.

Just to clarify, I haven't extended or written any additional code to make Infragistics work with SF Business Binding Sources - it does it out of the box as a BBS can be bound to any .NET control.

What functionality are you expecting a "wrapper" to provide that goes beyond BBS databinding?

Aaron

Hi Ertan.

I guess this has already been thought, and there is an area right here on the forum where all users can post samples and contributions. If you extendend the funtionality of your controls you could post them as well.

Have a look at it:

http://forum.strataframe.net/Forum26-1.aspx

Thanks for the details.

I don't think like you but I couldn't put you that way. I've expected that customers can join this discussion.

Every customer can extend the framework but same thing must be provided by centralized vision, by producer or open source strataframe community.

Ertan, I use Infragistics and don't use DevExpress. However, although there is an Infragistics wrapper, I don't use it. As Trent says you can use the Business Binding Source against any 3rd party control and I would imagine the same is true with DevExpress. If not then this is a problem with DevExpress as the BBS will bind to any control supporting standard .NET data binding. That said I have no doubt DexExpress will bind to the BBS as it wouldn't be worth 2 cents otherwise.

Technically, a BBS will be "slower" than straight binding to the BO, but (for the record) I have many forms containing multiple BBSs bound to Infragistics grids and performance is not an issue. I can recall several forms containing around 10+ Infragistics ultragrids each bound to a BBS and they are not "slow". 

I think the fact that the SF guys have produced wrappers in the past shouldn't be viewed as being the only way of using 3rd party controls - that is definitely not the case. You need look no further than the BBS.

Aaron

It is actually very easy to implement native SF data binding to 3rd party controls, but you don't have to.  You can bind to them using the BusinessBindingSouce without having to implement the IBusinessBindable interface at all.  The reason that we have not expanded the DevExpress wrappers or any other 3rd party vender wrappers past the standard classes is that there is very little demand.  Secondly, this requires more resources dedicated from inside of our shop to stay on top of 3rd party versions and controls and ultimately detracts from the growth of the framework.  But we knew that these types of enhancements would be needed by customers in the field, so we have made it as easy as possible to create your base classes, implement our interfaces, and then from that point forward you have the best of both worlds.

The extended framework focus will be towards creating more framework level enhcancements as well as extending the standard StrataFrame control collection.  This doesn't mean, however, that we will cease to support 3rd party control companies such as DevExpress or Infragistics, but we will only create the standard or basic controls in the pre-built wrappers.  Finally, you get the source code for these wrappers so you can see exactly what we have done to extend them.  I hope this helps.

You should have created a base assembly that doesn't inherit from anything other than StrataFrame and other .NET assemblies (in other words none of your application assemblies).  When you do this, you are creating an extension of your own classes and tools that you use.  We have two types of these base assemblies when we develop: company level (used for multiple applications) and application level (used specifically for one application).  In this case, you would want to create this in your company level base assemblies so that you can use them over and over again.  This is actually a topic we cover during our training class.