StrataFrame objects and BusinessBindingSources were dropped on the form and bound with the related objects.

The form is openning very slowly. The first tab behaves like a maintenance form with two objects. (Edit and New Record).

Grids are on the other tabs and objects are populating after pressing the related tab.

What are the points to be careful ?

Note : I 've also two combos loaded by requery methods. This is also slow.

Thanks

Thanks.

Optimized For Speed
StrataFrame data-binding is six times faster than standard ADO.NET data binding to custom controls. This functionailty is provided through the Business Object Mapper and the strong-typed properties. Binding to a property versus a data row is natively faster. But to achieve extremely fast binding, a field property descriptor is dynamically created for each field property which eliminates the need for reflection and provides all of the information required by .NET when binding to data. Since no reflection is used and all of the field property descriptors are compiled within the assembly, forms instantiate much faster. This is especially important for forms that will house a large number of bound controls.

You have detailed your problem in your comments and questions.  Setup this same scenario using SF controls and see if you have a performance issue.  If you look through the forum, you will see where fevelopers have had issues with DevExpress controls and performance, especially when the application gets larger and larger.  Generally this can be worked around by changing some of your development techniques.  But before you start casting aspersions in our direction, I would recommend that you actually try and trouble shoot your slowness.

For starters, re-create a scenario that seems to be slow and try using a standard DataGrid versus the XtraGrid and see if they performance the same.  Take grids out of the forumula and bind to standard TextBoxes. Remove the BBS and bind directly to a BO (which is what the comment you are quoting is based on) and see what happenes then.  Get a code profiler and really find out where your trouble spots are.

I already know without arguing with you that SF is extremely fast and so I have no need to defend that.  We have extremely large applications on SF all over the world including our medical application which to date, I have not yet seen a larger application on SF.  And the reason our medical application is so scalable and fast is due in large part to StrataFrame.  But is also is in part to good programming practices and standards which is paramount in any application development environment.  So I would recommend taking a step back and really start looking at your application, programming standards, data being retrieved, queries, and 3rd party tools before you point the finger here.

Now, it is my desire to help you, but just throwing a quote at me and then expecting me to tell you where your problem is will never happen.  You have given me absoltely no concrete information in regards to your application, samples reproducing the problem, etc. 

Finally, reproduce your issues outside of the DevExpress environment and then let's start from there.  Once you have this reproduced using a DataGridView, then we can start to work through your problem.  StrataFrame is an application framework, which means that is does a phenominal amount of work for you to get up to the point of developing your application.  But it still is programming any way that you cut it which means that a countless number of external variables could be affecting your application. 

There are MANY reasons why your application can be slow and they are all outside of SF. I would recommend that you read the following thread as a starter:-

http://forum.strataframe.net/Topic17575-7-1.aspx?Highlight=aaron+grid

Although it relates to an Infragistics Grid I would imagine some of the issues will apply to DevExpress. Please read it all.

When you say your form is slow, are you running this inside Visual Studio with debugging? If so, please read some of my posts in the above thread as there is a considerable difference between a release build run in VS with debugging and without it (or outside of VS). In my example, an Infragistics grid took 3 mins 20 seconds to load 15000 records when run in VS with debugging and this dropped to 7 seconds when the application was run outside of VS.

As Trent has said, you need to establish if you can improve performance by binding to standard .NET controls. DevExpress and Infragistics will be slower than their basic .NET equivalents but that is no fault of SF. If your BO/BBS can bind to a regular control without problems then you know the business object to database is correct and the problem is with the grid. The bottom line is the BBS works at the same speed regardless of the control. However, the time taken for the control to work with the BBS is a different matter.

Of course, we are also making the assumption that your SQL queries are fully optimized and your database has the proper indexes, etc. That alone can kill performance as can the setup of your database engine (if it is SQL Server, etc.). In fact, I have just realised I have made the assumption you are using a SQL database The fact you claim you have two combos which are slow to query makes me suspicious about this.

There isn't much in your post to go into this any further but I hope the above helps and gives you somewhere to start. The main point to take from this is you are not the first person trying to build complicated forms around SF - so at least you know you are not trying to overcome a problem in SF as there isn't one.

Aaron