Yes FARNS, VB does support Lambda statements (single line functions) through the Function keywoard.

The following is a Boolean Lambda expression that takes 2 parameters (parameterless expressions are also supported)

Function(person, minAge) person.Age >= minAge

The lack of support for Lambda statements stems from the fact that VB.NET2008 still does not support Anonymous methods which really ticks me off as that is like in VB.NET203 when it was lacking the support for operator overloading

omar wrote:

Yes FARNS, VB does support Lambda statements (single line functions) through the Function keywoard.

The following is a Boolean Lambda expression that takes 2 parameters (parameterless expressions are also supported)

Function(person, minAge) person.Age >= minAge

The lack of support for Lambda statements stems from the fact that VB.NET2008 still does not support Anonymous methods which really ticks me off as that is like in VB.NET203 when it was lacking the support for operator overloading

Oh, then you have nothing to worry about. All code takes either llblgen pro constructs or lambda expressions, no lambda statements are required.

Btw, why don't you come over to the 'dark side', i.e. C# ?

Otis wrote:

Btw, why don't you come over to the 'dark side', i.e. C# ?

lol... problem all my team are hard core VB'ers and if I know better I should not even joke about this thing, beleive I did try but thats what you get for being a democratic manager

Frans,

This is what one of the DevEx people said about the upcoming Linq implementation, he also mentions LLBLGen...

In essence, the paging and resource (memory) minimization technology we have with our .NET grids, both XtraGrid and ASPxGridView, use a particular implementation of IListServer that uses our XPO. We've received feedback from our customers that we should provide more implementations, ones that don't require XPO.

Well, the XPO team decided that the first they should write would be an implementation that uses a Linq server instead, that is, some object that implements IQueryable of T (I'd use angle-brackets, but the CommunityServer NNTP server strips them). Since there are a bunch of such classes out there at the moment (Linq to SQL, Linq to XML, LLBLGenPro, etc) it would mean that we only have to write the implementation code once for a myriad of different scenarios.

Once that is done, both grids will be able to use Linqable data sources for their data. We are also proposing in the roadmap to extend this IListServer interface (aka Server mode) to other grid-like controls in our products.

This Linq support is due most probably in release 2008.1.

So, it seems it should be able to cooperate : LLBLGen vs servermode of the DevEx grids.

I still have no idea how they would do this, other than: an event is raised, the query has to be written in code by the developer, the query is then passed to the grid.

Other than that, how are they going to formulate the query? Linq queries contain the provider etc. to use for execution, they're not specifications.

Otis wrote:

I still have no idea how they would do this, other than: an event is raised, the query has to be written in code by the developer, the query is then passed to the grid.

Other than that, how are they going to formulate the query? Linq queries contain the provider etc. to use for execution, they're not specifications.

As for now they are using XPServerCollectionSource component (uses XPO) that does provide data. I guess the LINQ approach will be done through a similar component.

mihies wrote:

Otis wrote:

I still have no idea how they would do this, other than: an event is raised, the query has to be written in code by the developer, the query is then passed to the grid.

Other than that, how are they going to formulate the query? Linq queries contain the provider etc. to use for execution, they're not specifications.

As for now they are using XPServerCollectionSource component (uses XPO) that does provide data. I guess the LINQ approach will be done through a similar component.

Hmmm... according to what they posted in the thread, it should work regardless of what o/r mapper is used, as long as it supports linq. But if it requires a component, how would it work if the component has to produce the query?

If I think about it, it looks like they want some IQueryable object to be provided and they then go from there. So say I want to fetch customers with a filter, I then do: LinqMetaData metaData = new LinqMetaData(adapter); someDevExpressControl.RootSource = metaData.Customer; // implements IQueryable

and from there they'll query the data as they'll call extension methods on metaData.Customer... at least that's what I think they'll do. I see no other way.

(this comes down to this code: var q1 = metaData.Customer; var q2 = q1.Where(c=>c.Country=="Slovenia"); var q3 = q2.Select(c=>c.CompanyName);

and then enumerate q3

Beta of Linq to LLBLGen Pro likely tomorrow (wednesday). !

Look, that's talk !!

Otis wrote:

Hmmm... according to what they posted in the thread, it should work regardless of what o/r mapper is used, as long as it supports linq. But if it requires a component, how would it work if the component has to produce the query?

If I think about it, it looks like they want some IQueryable object to be provided and they then go from there. So say I want to fetch customers with a filter, I then do: LinqMetaData metaData = new LinqMetaData(adapter); someDevExpressControl.RootSource = metaData.Customer; // implements IQueryable

and from there they'll query the data as they'll call extension methods on metaData.Customer... at least that's what I think they'll do. I see no other way.

(this comes down to this code: var q1 = metaData.Customer; var q2 = q1.Where(c=>c.Country=="Slovenia"); var q3 = q2.Select(c=>c.CompanyName);

and then enumerate q3

Well, yes, absolutely. I was thinking the same. In fact there is LinqServerModeSource control that does what we thought. And the code might look like (Linq to Sql):

DataClasses1DataContext  context = new DataClasses1DataContext();
linqServerModeSource1.QueryableSource = from c in context.Categories select c;
gridControl1.DataSource = linqServerModeSource1;

So, to answer whether XtraGrid will work with any Linq thing out there: yes, as long as it implements IQueryable.

The only drawback is: how are they going to find the properties which represent a related entity ? I hope through ITypedList, as otherwise it might be that they're invoking lazy loading on selfservicing (as they've to use reflection).

Oh well, let's wait for their first release

Otis wrote:

The only drawback is: how are they going to find the properties which represent a related entity ? I hope through ITypedList, as otherwise it might be that they're invoking lazy loading on selfservicing (as they've to use reflection).

Oh well, let's wait for their first release

I guess the later. If I add Products entity to my previous DataContext (but still use the same query) the grid is capable of showing products detail view. But since the thing is supposed to run on the server it isn't such a bad idea. You can suppres this behaviour, too, by configuring grid properly.

Hmm. Ok Well, perhaps it works out ok. Let's wait and see.

Btw, the first beta of our linq stuff is available: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=12771