In a recent bug report where I found a fault with the ASPxGridView binding to the LLBLGenProDataSource with server mode paging on (DataSourceForceStandardPaging="True"), DevExpress stated that

Unfortunately LLBLGenProDataSource is not supported

Furthermore, they appeared to refuse to even investigate a showstopping bug which is quite possibly in their own control merely because it was used in conjunction with LLBLGen.

http://www.devexpress.com/Support/Center/p/B135810.aspx

Given all the fuss and bother we've had about paging level compatibility between the ASPxGridView and LLBLGen's datasources I'm reluctant to open up another thread on this, especially as it all appeared to be fixed:

http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=13297&StartAtMessage=75&#74444

But ultimately, like most other developers in the real world who pay for tools, my livelihood and that of my coworkers (and clients), not to mention tens of thousands of development dollars, depend on the tools we've invested large amounts of time and effort into being compatible.

So, what's the purpose of this thread? I've asked DevExpress to categorically state whether they consider the ASPxGridView to be compatible with the LLBLGenProDataSources or not. I will report the answer back here. * If they say yes, then in future when DevExpress deny support for the LLBLGenProDataSource then the user in question can link to this thread which will link to their response. * If they say no, then we will have official confirmation of this and hopefully my warning will be able to prevent other teams going down a road which involves investing heavily in both technologies only to find them subtly incompatible.

As a further measure (which would have helped my team immensely when we were making our toolset choices some years ago), can I suggest that the main LLBLGen website prominently host in plain site a list of GUI toolsets (particularly grids) that are known to be fully compatible with LLBLGen? This could save a lot of developers a lot of frustration and unnecessary expense.

As stated in the documentation, the DataSourceForceStandardPaging property can be applied only to the ObjectDataSource, LinqDataSource, XpoDataSource, and LinqServerModeSource data sources. Unfortunately LLBLGenProDataSource is not supported.

Which is pretty strange, because when I use their grid (9.1.2) with our datasourcecontrol and set that property to true I get proper paging. the only thing that property does is sending the paging parameters to the ExecuteSelect() method. It's also wrong what he says, because the documentation of that property only says that the datasourcecontrol has to support paging, which we do (you have to enable it with EnablePaging=true of course on the datasourcecontrol) and gives an example of two (hence the 'e.g.') datasources which do. I think this Ivan is a bit mistaken about what he had to respond

We do nothing different from all the datasource controls they enlist there: the ONLY way the grid communicates with the datasourcecontrols is through ExecuteSelect() which is a method in the base class of all the datasourcecontrols: DataSourceControl (and also ours, for that information).

That property is limiting your features on the grid, so you could better use one of the following: 1) use LinqServerModeSource and use our linq implementation (if possible). This gives you proper paging and all the grid features 2) use LivePersistence set to false and do the calls to the fetch logic in the code behind file of the webform by passing the values for the particular page to fetch grabbed from the grid directly. This can be a bit tricky though.

Yes, we are aware that some control vendors aren't really helpful with supporting third party class libraries. DevExpress and us have had a row on this in the past when this paging issue was brought forward by a customer of ours and we asked devexpress to fix it. They told us that our datasourcecontrol needs an implementation of their interface which we won't do as we won't ship devexpress controls with our runtime library. They added the property to overcome teh issue although it has a limiting factor on the features of the grid.

In the past we threatened to do what you are suggesting to Infragistics (as in: tell our customers not to purchase their controls) and they were quick to fix the ITypedList issue they had refused to solve for years on end. I'm not sure what devexpress' motives are to ACTIVELY deny support for any 3rd party datasourcecontrol by not implementing normal code (as in: pass the proper info to ExecuteSelect()) but again, I couldn't reproduce it (I recently had to, see this thread: http://www.llblgen.com/tinyforum/GotoMessage.aspx?MessageID=88030&ThreadID=15739 )

Please let me know if I have to contact DevExpress to get proper responses, as I hate to be at the receiving end of flak while we are the last person to blame in this.