I think I have a workaround. (I haven't tested it, it's theory, but it might work).

The ASPxGridView has an event: PageIndexChanged. Bind a handler to that event. When that event is raised, grab the new page number and store it in the viewstate. Set the datasourcecontrol's LivePersistence property to false. Bind an event handler to PerformSelect and PerformGetDbCount. When the call comes, read the viewstate's value for the current page of the grid. Then simply fetch that page in PerformSelect (and in PerformGetDbCount, you simply fetch the db count)

It might also be simpler, if you can read the grid's current page value from the grid, when the PerformSelect event is raised, you can fetch the page's data.

There's one caveat: if the grid thinks paging isn't necessary because there are just say 10 rows in the data, it's over, but if the grid obeys at least the standard to obtain the total # of rows through the ExecuteSelect call for fetching the number of rows, it might work.

I haven't heard back from DevExpress since yesterday morning. they also didn't publish my replies to the blog entry... Anyway, if this workaround makes things at least usable for some people, you all can continue working on your projects and don't have to wait till DevExpress fixes this issue (if ever).

Otis wrote:

I haven't heard back from DevExpress since yesterday morning. they also didn't publish my replies to the blog entry... Anyway, if this workaround makes things at least usable for some people, you all can continue working on your projects and don't have to wait till DevExpress fixes this issue (if ever).

That is interesting, I responded to Julian in that thread saying I respectfully disagreed that paging was considered an "advanced" feature... My post was not added either, it seems that have shut posting to it down... That seems wrong to me. Oh well.

I will take a stab at your suggestion Frans, and post back here if it works.

Good news from DevExpress! In the next minor release (2008.1.4) they're planning a feature to turn off the advanced paging/grouping stuff so the paging parameters are passed to ExecuteSelect().

Otis wrote:

Good news from DevExpress! In the next minor release (2008.1.4) they're planning a feature to turn off the advanced paging/grouping stuff so the paging parameters are passed to ExecuteSelect().

That is excellent, the next minor release should be out soon, as they seem to release minors about every month. Let's hope it just "works' then... :-)

I think that is a great step forward and will really help them in the marketplace.

my only fear, they take out filtering... grouping, summaries/totaling... I can live without ... but filtering that would be a mistake.

tzarger wrote:

my only fear, they take out filtering... grouping, summaries/totaling... I can live without ... but filtering that would be a mistake.

Filtering isn't done through the datasourcecontrol as in: grid -> datasourcecontrol, that's not done this way. A datasourcecontrol filters based on the SelectParameters contents, which is filled by adding parameters to that collection. It's also filtered by a filter you set in the code behind. It's not filtered by data passed from grid to the datasourcecontrol.

A filter from the grid to the datasourcecontrol only works if the datasourcecontrol is build to accept a filter from a bound control, which is the case with their IListServer implementing datasourcecontrol.

http://community.devexpress.com/blogs/ctodx/archive/2008/05/19/quot-paging-grid-team-paging-grid-team-quot.aspx

DvK wrote:

http://community.devexpress.com/blogs/ctodx/archive/2008/05/19/quot-paging-grid-team-paging-grid-team-quot.aspx

Why does Julian keep referencing LINQ paging parameters... it sounds like you would have to be using a LinqDataSource, rather than any generic datasource control... Most likely I am reading too much into it.

tzarger wrote:

DvK wrote:

http://community.devexpress.com/blogs/ctodx/archive/2008/05/19/quot-paging-grid-team-paging-grid-team-quot.aspx

Why does Julian keep referencing LINQ paging parameters... it sounds like you would have to be using a LinqDataSource, rather than any generic datasource control... Most likely I am reading too much into it.

Dunno. For some reason the word LINQ was sticking in my mind... Sigh.

JulianBucknall wrote:

tzarger wrote:

DvK wrote:

http://community.devexpress.com/blogs/ctodx/archive/2008/05/19/quot-paging-grid-team-paging-grid-team-quot.aspx

Why does Julian keep referencing LINQ paging parameters... it sounds like you would have to be using a LinqDataSource, rather than any generic datasource control... Most likely I am reading too much into it.

Dunno. For some reason the word LINQ was sticking in my mind... Sigh.

:-) Better to hear that from the man himself. I'll take that as a yes that generic datasource controls will receive the paging as well. Thanks Julian.

http://community.devexpress.com/blogs/ctodx/archive/2008/05/22/paging-is-good-but-throughout-the-stack-please.aspx

Otis wrote:

Filtering isn't done through the datasourcecontrol as in: grid -> datasourcecontrol, that's not done this way. A datasourcecontrol filters based on the SelectParameters contents, which is filled by adding parameters to that collection. It's also filtered by a filter you set in the code behind. It's not filtered by data passed from grid to the datasourcecontrol.

A filter from the grid to the datasourcecontrol only works if the datasourcecontrol is build to accept a filter from a bound control, which is the case with their IListServer implementing datasourcecontrol.

Hi Frans, quick question, the paging in DevExpress removes the ability to group, filter, summarize, unbound events... which I understand based on what you have said here, and what Plato at DevExpress has explained as well... So in order to make it all work, you can capture the FilterExpression manually in the format of: "[Product] Like 'Test%'" ... Is there a good and easy way to use that as a select parameter with the LLBLGenProDataSource?

I know you could build your own SQL query and execute it ... just checking to see if you can think of a more type safe way to do it. Thanks so much!

DvK wrote:

http://community.devexpress.com/blogs/ctodx/archive/2008/05/22/paging-is-good-but-throughout-the-stack-please.aspx

I don't get the point of the post. Grouping of data through linq makes it automatically readonly data. If you want to edit the rows in the grid which have to be roundtripped to the server and db, how's that done then? Or is that 'magic' that appears to be there all of a sudden? I don't think so. But I disgress...

tzarger wrote:

Otis wrote:

Filtering isn't done through the datasourcecontrol as in: grid -> datasourcecontrol, that's not done this way. A datasourcecontrol filters based on the SelectParameters contents, which is filled by adding parameters to that collection. It's also filtered by a filter you set in the code behind. It's not filtered by data passed from grid to the datasourcecontrol.

A filter from the grid to the datasourcecontrol only works if the datasourcecontrol is build to accept a filter from a bound control, which is the case with their IListServer implementing datasourcecontrol.

Hi Frans, quick question, the paging in DevExpress removes the ability to group, filter, summarize, unbound events... which I understand based on what you have said here, and what Plato at DevExpress has explained as well... So in order to make it all work, you can capture the FilterExpression manually in the format of: "[Product] Like 'Test%'" ... Is there a good and easy way to use that as a select parameter with the LLBLGenProDataSource?

I know you could build your own SQL query and execute it ... just checking to see if you can think of a more type safe way to do it. Thanks so much!

What's that 'FilterExpression'? Is that some filter in a format defined in a generic way? Or is that DevExpress specific?

SelectParameter parameters are always field == value

Otis wrote:

What's that 'FilterExpression'? Is that some filter in a format defined in a generic way? Or is that DevExpress specific?

SelectParameter parameters are always field == value

Yes, FilterExpression comes off the ASPxGridView ... and it give the filter as a string in that format... I was thinking you had to assign a filter value to a SelectParamter, which would mean I have to parse the string to get the key / value pair, not to mention determine the operator.