Greetings Frans, I am trying to use a new grid (9rays FlyGrid) with LLBL's entity collection. Although the new release of the grid is supposed to support design-time data-binding, it only works with DataSets. Their support requested a sample application to assist in properly supporting EntityCollections. Can you please tell me the interfaces the grid control should check for in the data-source collection to populate its columns collection and to discover hierarchal relations. Any other information that I could pass on to their support would also be useful.

Since it only supports Datasets, You could us the result of GetMultiAsDataTable to bind to the grids.

omar wrote:

Greetings Frans, I am trying to use a new grid (9rays FlyGrid) with LLBL's entity collection. Although the new release of the grid is supposed to support design-time data-binding, it only works with DataSets. Their support requested a sample application to assist in properly supporting EntityCollections. Can you please tell me the interfaces the grid control should check for in the data-source collection to populate its columns collection and to discover hierarchal relations. Any other information that I could pass on to their support would also be useful.

Their grid should call ITypedList's GetItemProperties on the datasource bound, and work with the IBindingList properties for grid behavior like sorting.

THey should obey a 'Designer' attribute on the bound datasource as well. Though, if they don't even do that, it's a pretty bad piece of software, as the minimum a 3rd party control should be able to do is what the vanilla MS controls are able to do.

sparmar2000 wrote:

Since it only supports Datasets, You could us the result of GetMultiAsDataTable to bind to the grids.

This doesn't work well in our case. we need to support EntityCollections as well as DataTables.

Before spending too much time trying to create a sample with llbl (I'm not even sure if you could send a sample. I guess they could download a trial version [or maybe buy it (do I get a commision? )]), I would create a test just using simpler objects like arrays or objects derived from collectionbase.

Fishy

Fishy wrote:

Before spending too much time trying to create a sample with llbl (I'm not even sure if you could send a sample. I guess they could download a trial version [or maybe buy it (do I get a commision? )]), I would create a test just using simpler objects like arrays or objects derived from collectionbase.

I created them a simple sample application for the Northwind SQL database. I build one screen with two grids, FlyGird and .NET's native grid to show behaviour of both design-time and run-time with LLBL's entityCollections

Omar, let me know if they need extra info and you need my help on that.

Otis wrote:

Omar, let me know if they need extra info and you need my help on that.

They are already working on the info you gave me in this thread. I am promised a new update today or tomorrow. I am very excited about FlyGrid for two reasons: 1- It has an excellent support for right-to-left languages (Arabic and Hebrow) 2- It very compact (less than 400k dll) and very fast (100,000 records in less than 0.2 seconds) I am hoping for the next JCL update to add support for FlyGrid once I make sure it plays nice with LLBL's entity collections at both design-time and run-time.

100,000 rows in .02 seconds is indeed top speed and smells like native C++ code .

Nevertheless, sounds promising.

Otis wrote:

100,000 rows in .02 seconds is indeed top speed and smells like native C++ code .

Nevertheless, sounds promising.

Their website asserts its

100% C#, Windows.Forms, CLSCompliant Control

that is

compatible with .NET 1.0, 1.1 and 2.0

One more thing I like about this control. It is designed to work as a Tree-control and as a Vertical grid (for property grid functionality). Yet I can't help but to think how can they do that with 340KB (I have noticed that they do have another DLL for the design-time support)

omar wrote:

Otis wrote:

100,000 rows in .02 seconds is indeed top speed and smells like native C++ code .

Nevertheless, sounds promising.

Their website asserts its

100% C#, Windows.Forms, CLSCompliant Control

that is

compatible with .NET 1.0, 1.1 and 2.0

Heh, but GDI+ in C# is way too slow to render that much rows in such a short time. That's why all these grids are so slow, they have to render the lines and boxes using .NET code. But perhaps they found a new way of doing things Though when I look at the gridview in .NET 2.0 which is SO SLOOOOOOOW you really think why VB6 was considered slow, I'm interested how they did it.

Frans, Is there an alternative - in your opinion - to GDI+ to rendering? Is there a better server side API's that could be utilized istead?

Thaks in advance Regards. Suresh...

sparmar2000 wrote:

Frans, Is there an alternative - in your opinion - to GDI+ to rendering? Is there a better server side API's that could be utilized istead?

I'd definitely go for a win32 api targeting C++ library, called from .NET, especially if you can delegate the drawing completely to that api. GDI+ in .NET isn't the fastest. It's the main reason why the gui's in .NET are sluggish, compared to for example VB6 gui's which use native win32 controls. So if you draw a grid with lines drawn using GDI+, it's not going to perform top notch.