I'm having a minor issue using llblgen datasource (2) with devexpress. Specifically the Scheduler and Grid.

The problem I am having is that after modifying an item in the scheduler or grid, if the user then clicks a sorting link or changes page or change schedule view (pretty much any interaction with the server requiring a callback) the original data is shown. So if I have a grid with 3 items in it, then i delete one, two are shown, then sort a column I see the original 3.

Turning off Callbacks on the devexpress controls seems to fix this. Disabling Viewstate on the llblgen pro data source also fixes it. Neither are very attractive options. It seems something is iffy with the data source's caching in the callback scenario...

I tried setting Refetch to true in the event handler for updating, inserting and deleting, but this property doesn't seem to do anything It certainly doesn't "refetch the data at the next select call from the bound control(s)" cause if it did I can't see that I would have this problem.

Any ideas?

Sorry I don't have devexpress, can you reproduce this using MS GridView ?

Can this be ajax related? The 'delete' isn't taking place till you save the grid by clicking the 'V' button (IIRC), as then the grid makes a callback to the server. When you sort, it will also callback to the server and will retrieve the original data. So it either: 1) should sort on the client or 2) you have to make a callback after every action to make the changes take effect.

Hi Frans,

It does appear to be ajax related. If is disabled callbacks (EnabledCallbacks="False") everything magically starts working. Except now that I have to postback all the time, I'll try wrapping the grid in an UpdatePanel and see if it still works...

Devexpress is really disappointing! Nice features... if you can get em to work

Thanks

worldspawn wrote:

Devexpress is really disappointing! Nice features... if you can get em to work

I wouldn't say that DevEx is disappointing (they are very strong in asp.net world right now). I would rather say that one has to know what he/she is doing. This Ajax thing is causing many collateral issues here and there - and those are hard to understand unless you really know the stuff.

Not sure i want get in to a debate but:

3rd Party controls are supposed to increase development speed. I have had a constant uphill battle getting them to function correctly, especially inregard to compatibility with UpdatePanels (which they claim to support) as well as the datasource/callback issues I've mentioned above.

Sorry, but they just don't work as advertised. Their demo site is very misleading. In the "lab" they work fine, in the real world they just can't hack it. It's a commerical product so I expect commercial quality, otherwise I may as well use an open source free grid. I (well my boss) pay money for LLBLGen and it's a fantastic product, highly hackable/customisable, indeed it's the swiss army knife of code generation. Most importantly though, it's works just as advertised (if not better). And when I ask a support question I don't get "can you please send us a sample, if not then tough luck getting a solution" as a reply from SD, instead I get useful suggestions/solutions because the support staff know their product really really well.

I've been coding .net for seven years and have my own library of controls i use that I have developed. If I need to be more experienced than that to have success using "RAD" components then we're all screwed

I've to add that control vendors often try to make the world look like a better place than it really is. In the past 4-5 years I've seen so many crappy controls, often they were sold for a lot of money. Need a bugfix? Wait for the next version. Oh, you didn't buy the subscription? Tough luck!

About devexpress... In general their stuff works OK, the winforms stuff that is. The webstuff isn't that great IMHO, compared to e.g. telerik.

Devexpress isn't free of misleading customers though. They tell their customers their xpo linq provider is solid and there are no known issues... However, any query-argument, any join, any select many, any let query, it will fail.

@worldspawn: thanks for the kind words!

I have used both DX and telerik pretty extensively and they both have their problems. I think the new DX version 7 is far ahead of telerik though, their API is much cleaner and more consistent than Telerik. This is especially true when it comes to writing client side javascript which is a downright nightmare with telerik due to their API inconsistencies and often completely useless documentation. I hear they are working to fix this in their new 'prometheus' version which is basically a complete re-write, but it is still in beta/development at the moment I believe.

Like Miha said though, really this boils down to a lack of understanding of the Ajax library, you will run into that kind of issues no matter what kind of components you use. I would highly suggest the book ASP.net AJAX in action. Yes in the most simple of cases you can get away with just slapping controls in an UpdatePanel, but believe me you will live to regret that decision when you want to do something slightly more complicated or you discover that you need more performance, I have learned this the hard way. You can realize tremendous decrease in callback payload by writing a custom callback which is very easy to do using the ajax library once you know the pattern.

Completely agree about DX advertising in certain cases, case in point their new XPO based application framework.. yes you can develop apps with lightning speed, but you are going to feel like an idiot when you have to tell a customer that you can't implement feature xyz because your framework wasn't designed for that

I agree with tangent.

I've been using telerik web controls (r.a.d. suite) for 2 years and devexpress (dxperience 7.3.x) for about 5 months now and I can tell you that devexpress indeed managed to implement a clean, straight forward API.

As tangent also pointed out, the client-side API (I'm impressed by the client-side validation features) is really great and makes your (client-side/javascript) life easier particulary when used together with the Prototype framework.

Anyway I seem to have some troubles when it comes to databinding an ASPxGridView via the LLBLGenDataSourceControl (self-servicing). I managed to get the data displayed in the grid but any further sorting attempts fail, the data is obviously not sorted and the grid's behavior is kind of weird.

Do you suggest to set the grid's EnableCallbacks (or any AJAX actions) to false to get it to work properly? I think that was suggested by the thread opener some time ago.

What about the cache location? What could be here the right setting for the grid and the LLBLGen control?

Regarding your LLBLGenDataSourceControl I'd like to know what exactly does the control do when setting CacheLocation to AspNetCache. Am I right assuming the control fetches the data (TypedList of EntityCollection) just once (PerformSelect), serving subsequent data requests from the cache? How can I force the control to refech from the data source?

Thank you.

Regards, Tino

Anyway I seem to have some troubles when it comes to databinding an ASPxGridView via the LLBLGenDataSourceControl (self-servicing). I managed to get the data displayed in the grid but any further sorting attempts fail, the data is obviously not sorted and the grid's behavior is kind of weird.

Do you suggest to set the grid's EnableCallbacks (or any AJAX actions) to false to get it to work properly? I think that was suggested by the thread opener some time ago.

Please check the ASP.NET 2.0 databinding example posted in the downloads section.

This example shows, using SqlServer's Northwind database, how the LLBLGen Pro datasource controls for both Adapter and SelfServicing should be used in various scenarios and all kinds of different webforms. Comes with two variants: one Ajax enabled and one normal, non-Ajax based

What about the cache location? What could be here the right setting for the grid and the LLBLGen control?

There is no one right answer here, it depends on each case.

Regarding your LLBLGenDataSourceControl I'd like to know what exactly does the control do when setting CacheLocation to AspNetCache. Am I right assuming the control fetches the data (TypedList of EntityCollection) just once (PerformSelect), serving subsequent data requests from the cache? How can I force the control to refech from the data source?

No this is to cache data between postbacks. LLBLGenProDataSource will automatically fetch the data from the database when it recieves a select call from the bound control.

Also you can force Ref