This is a guest blog post written by Johnny Tordgeman from Guardian Information Systems. He has his own blog, check it out.

---

Hey everyone, my name is Johnny Tordgeman and I will be posting some guest posts here on SharePoint 2010 integration with Xceed DataGrid for Silverlight. I would like to thank Odi for giving me the opportunity to show everyone how easy it is to combine Xceed DataGrid for Silverlight with the SharePoint 2010 platform.

In this first post I’m going to show the basic connection of a SharePoint list with the datagrid by building a simple web part that will show all the fields of the default Tasks list using Xceed’s datagrid.

To keep things simple, I will only concentrate on the Silverlight portion for this web part and display it using SharePoint’s Silverlight web part, but on a later post we will add a custom web part to render our Silverlight application and pass parameters such as the list we want to show from SharePoint.

[Ed. note: If you are going to try to run the Silverlight web part on your development machine, see the note at the end of this post]

To get started, create a new Silverlight project and name it SLSPDataGrid then uncheck the “Host the Silverlight application in a new Web site” box and click OK.

To make this example as simple as possible we will use SharePoint’s REST web service to get the data from our Tasks list.

Right click on the project name and select “Add Service Reference”. You will get the following screen:

In the address box type in the address of your SharePoint site and add "/_vti_bin/ListData.svc" to it.

For example, if your site is http://jtordgeman the address box should read: http://jtordgeman/_vti_bin/ListData.svc. [Ed. note: If you have trouble accessing this .svc file, see this solution: http://blog.hompus.nl/2010/03/26/could-not-load-type-idataserviceupdateprovider-when-using-rest-with-sharepoint-2010/]

Change the namespace to SharePointContext and click OK.

Next, let’s add the Xceed datagrid dll to our project. Right click on "References" and choose "Add Reference", then click on “Browse” tab and navigate to where Xceed is installed. Click on "Bin" and then add "Xceed.Silverlight.DataGrid.v1.0.dll".

Your solution should look similar to this:

In MainPage.xaml add the following line to the UserControl declaration:

xmlns:sldg="http://schemas.xceed.com/silverlight/xaml/datagrid"

Now add the control under LayoutRoot using the sldg namespace. Your MainPage.xaml file should look like this:

We have added the control to our UI layer, so all we need now is to set its data. Switch to MainPage.xaml.cs file and following using statements:

Inside the MainPage constructor register the Loaded event by typing the following line under InitializeComponent():

Finally, type the following method to your code:

A few things to note:

1) Your context name might be different then mine (HomeDataContext). It’s best to type SharePointContext. And check in the intellisense for your context name.
2) The url that you pass to the context instance must be the same one you typed when we added the service reference.

Build your project, upload the .xap file to a dir in your SharePoint site and add the Silverlight web part to a page. Provide the web part with the address for your xap file and… you’re all done! You should see all the fields of the task list in your Xceed datagrid, with smooth scrolling, and automatic background data virtualization (in case you have hundreds or thousands of tasks) already enabled.

Please feel free to contact me on Twitter (@jtordgeman) or on my blog with any question you might have, and I’ll see you on the next post :)

---

Note: You will need to add a clientaccesspolicy.xml or crossdomain.xml file to the root of your SharePoint website if you don't use the Silverlight web part on the same server as SharePoint (for example if SharePoint is hosted on http://mysharepoint.com and you query it from a silverlight app hosted on http://mysharepoint2.com).

Xceed has been working for over 1.5 years and has put over 18000 person-hours of work on one single new Silverlight control, so that with only a couple of lines of code, you can achieve some magic.

A bit of history.

At Xceed, we've been creating components and class libraries for Windows developers for 16 years. Our first datagrid control was started 10 years ago. We offered a variety of other UI controls as well, such as charts, treeviews, menus, navigation and docking window controls. Like other component vendors, we created a “collection” or “suite” of many controls. Five years ago, our entire UI controls team began to focus solely on developing datagrid controls.

By putting all our energy exclusively behind datagrids, we felt we could do a better job than by spreading ourselves thin working on many controls. We could elevate datagrids to the next level, and cater to developers who would rather have a great datagrid than a collection of mediocre controls. We would target developers who value quality over quantity.

This move was made when we began developing Xceed DataGrid for WPF. It allowed Xceed to be the first to market with a datagrid for WPF (released January 2007, months to years before the other component vendors had theirs ready). We were not only first, but we had an amazing product that got impressive testimonials. Microsoft even used it in parts of Visual Studio 2010.

Our competitors kept their existing strategy of creating a wide variety of UI controls. Their datagrids received relatively little love. In contrast, with only one product type to think about, we were able to churn out an impressive 39 updates in 3.5 years. Customers were rarely kept waiting for resolutions to issues or new features. Today our WPF datagrid leads in stability and features, and offers perhaps the best user experience of any datagrid on any platform.

So what's new in the datagrid department that’s magical?

If you take a look at the competition's Silverlight datagrids and marketing for them, you'll see a recurring message: everyone claims that their datagrid is fast. "Blazing fast" says one. "The fastest" says another. Some of them are indeed fast, but in order to be fast, they have to load up the entire data source first.

That might be OK for Windows Forms applications accessing a local SQL server, however, this is Sparta Silverlight. Many apps built with Silverlight will be accessing data sources that are somewhere else on the internet, not located on the user’s own computer or on a company’s speedy intranet. Having to wait for hundreds (or thousands) of data rows to be transferred over the internet before your datagrid is functional yields a poor user experience. It also drains server and network resources, and client memory.

Web developers have been facing this challenge for years.

To avoid having to load all the data, Web developers use a pattern called "paging". If you've ever performed a Google search, you are familiar with paging. A Google search often yields thousands or millions of results, but Google only displays the first 10, and then presents you with a paging interface, providing you with “next page” and “previous page” navigation.

Most Silverlight datagrids have adopted paging as their solution to working with remote data sources. You put them into a special “virtual” or “server” mode. That’s where things fall apart.

The fast scrollbar experience disappears, replaced with paging navigation. Clicking on “next page” does nothing until a round trip to the database is completed and the next page of results is delivered. Unlike with Google searches, this can take seconds, and meanwhile the datagrid’s user interface is frozen. These delays are frustrating and reflect upon your entire application.

There’s nothing blazing fast about it.

That might explain why no other Silverlight datagrid currently provides a demo of the datagrid accessing a remote data source.  The paging or data virtualization demos all use local or randomly generated data, not data on a server somewhere on the internet.

Now wouldn’t it be great if a datagrid could feel and behave as if all the data was already loaded, even if the data was on a remote server? Using a scrollbar instead of a paging interface? Wouldn’t it be great if we didn’t have to wait every time we navigated forwards or backwards for the remote database to respond?

That’s what Xceed set out to do, and we believe we have achieved this goal. We designed and built an entirely new datagrid built from the ground up with asynchronous data virtualization in mind. We implemented a number of important advances in data virtualization and datagrid user interface behavior that all work together to make browsing and editing remote data feel almost as fast as as working with local data. None of these advances have ever been done in a datagrid up until now.

These advances are, on a high-level:

• A Fluid UI that helps mask network lag
• An intelligent background record retrieval system
• Optimized network communications
• Asynchronous editing and validation
  

Let’s start with the Fluid UI. A Fluid UI is an animated one, where the content it presents is given a real-world feel. When items move in a Fluid UI, they don’t jump to their new position, they animate, with physics-like motion, to their new location. Things happen smoothly.

So how does that help mask network lag? It’s all about perception. Here is the scenario with typical datagrids: the user clicks “line down” or “page down” or “next page”. The datagrid immediately launches a query for more data. When that data comes in, only then does the datagrid update its display by jumping down one line or displaying the next page. The perceived response time is that of the complete round-trip of request/response to the server.

For example, if clicking “next page” takes 1.5s to obtain and display data from the data source, then the perceived waiting time is the entire 1.5s, even if a “loading” animation is displayed somewhere on the grid’s surface to acknowledge the command.

On the other hand, with a Fluid UI, when the user clicks “line down” or “page down”, an animation to the next line or page immediately begins. This animation typically takes about 0.8s to complete. During this time, the end user sees “dummy” data rows animate into view – exactly as expected. The end-user feels that everything is responding and working as expected, even if the dummy data rows have no data in them yet. When the data arrives, it fades in smoothly.

In this scenario, even if the database query (launched at the same time as the animation starts) takes 1.5s to complete, the true perceived waiting time starts only after the animation has completed, and only if the data hasn't arrived by that time. The effective waiting time in the above example is reduced to 0.8s – half the time.

The next advance is the use of an intelligent background record retrieval system. We also call it Asynchronous Data Virtualization, but either way, it’s new in datagrids.

In order to be able to launch database queries for more rows to display without freezing the UI, the data virtualization mechanism has to work in the background. No other Silverlight datagrid does this (actually we believe no other company's datagrid on any platform does this). Without being asynchronous, when data is being accessed from the data source, all UI interaction is halted. That means users can’t click at their pace to move forward a few pages, nor change their mind and scroll in the opposite direction (until a round-trip to the server completes). It feels sluggish.

One Silverlight datagrid has implemented “background loading”, but that only works when you are loading the entire data source into the datagrid, not when getting the data in portions as needed. It also means that while the entire data source is being transferred to the datagrid, the scrollbar thumb is constantly getting smaller, moving up, and the datagrid is slow. Another datagrid has implemented "Stealth Paging" but it offers no advantages whatsoever over regular paging UI except to provide a scrollbar.

Why is Xceed’s background retrieval “intelligent”? Because we have added “passive and active pre-fetching” to the mix.

What is passive pre-fetching? When a typical data virtualizing or paging datagrid first loads up, it queries for the first page of data to display. But why stop there? We know that there are two possible navigation commands an end-user can do. The first is to scroll down or go to the next page. The second is to go to a specific page. In a typical datagrid, if the user scrolls down (or up), it is guaranteed that the end-user will be kept waiting, because the next (or previous) page of data has to be requested from the server.

Why not, when requesting data from the server, ask for a bit more data than we need to display on that first page? Why not ask for an additional few pages, if the overhead of doing so is acceptable? The result is that, when the user starts scrolling down, there is no waiting. When the buffer runs out, a new request is made for more data, again asking for more than the next page.

Active pre-fetching: the icing on the cake.

When the datagrid is idle, meaning the end-user is not performing any actions, the datagrid runs a background task that makes sure that the buffer of pages before and after the one currently being displayed is kept full. If the buffer is nearly empty, why should the datagrid just sit there doing nothing? Doing nothing means that it will be a near certainty that the buffer will run out sooner and the end-user will experience lag.

Active pre-fetching makes the datagrid work harder to preserve the illusion that all the data is actually already loaded. It helps silently query for more data so that the datagrid is more often able to display the previous or next page with absolutely no lag at all.

Optimized network communications.

We’ve also advanced the state of the art in how queries are made to the data source. This comprises 3 innovations:

1. No discovery required: Unlike other data virtualized datagrids, this datagrid does not require knowing the total row count, number and size of groups, or any other information about the data source. This eliminates a sizeable extra query that all other datagrids that support data virtualization require, making the Xceed datagrid load faster than any other.

2. Optimized navigation: The datagrid requests data from the data source using relative queries instead of absolute index-based queries. Such queries execute faster on the server so navigating through the datagrid is snappier. We know of no other datagrid that works this way.

3. Query grouping and throttling: During scrolling, queries to the server for more data rows are grouped together when possible. This works because queries are asynchronous and are typically obtaining data not currently in view. During heavy scrolling, queries that are no longer needed are cancelled, thereby reducing the load on the server as well as the datagrid’s own CPU use.

So to conclude, I’ve talked about 7 techniques (Fluid UI, background data virtualization, passive and active pre-fetching, and three query optimizations) that we’ve applied to the datagrid’s data virtualization that all aim to make our Silverlight datagrid the only one to provide seemingly lightning fast access to remote data. Or put another way, it lets end-users access remote data as fast as local.

For a description of what is actually happening under the hood, see Jenny's blog post.

Odi

Today marks the release of v3.2 of Xceed DataGrid for WPF. This is the 9th major update since the product was first introduced 2.5 years ago. Another one is coming, hot on its heels for August, with smooth scrolling innovations and other UI improvements, but here's what's new in today's release.

-          The new Standard Edition is aimed at folks who don’t need a whole lot of advanced features, but would still like to save time and get better results than when using Microsoft’s upcoming datagrid for WPF. The time saved, from the more complete design, abundant data binding options, documentation and helpful Xceed staff should easily outweigh its affordable $300 cost. It also has more features than the Microsoft grid, such as rich grouping support, more cell editors and input validation. Best of all, there’s a built-in instant upgrade path, so if your users eventually want filtering, printing, exporting, field chooser or other features, you can just upgrade and turn those capabilities on, instead of being painted in a corner with a control not designed to do them.

So what’s new in v3.2? For this release, we’ve made getting to your data, and presenting it properly, a lot easier to do.

-          First, the datagrid now autodetects foreign keys in your datatables, so now it is easier than ever to display the corresponding values you want to display, instead of IDs. It also works with enumerations. To activate this new feature, just set AutoCreateForeignKeyConfig to True.

-          Next, we added support for custom key value mappings. This makes it easy to map any kind of values or objects to fields in your data that represent keys. For example, if your table of employees has an Employee ID integer field representing an employee object, you can easily map that field so that the datagrid uses corresponding employee’s First name and Last name fields formatted as “Last name, First name”  as the value to be displayed instead of the integer.

-          Next, for users of the powerful Data Virtualization feature – which in v3.2 now also supports grouping –  if your data source implements IQueriable, and LINQ does, we’ve made providing data to the datagrid a snap. You no longer have to handle a bunch of events to provide the datagrid with data, and you no longer have to worry about how the datagrid is sorted or grouped. Doing so was tiresome, now it’s code free.

-          We also completed full support for the Entity Framework, which makes it super easy for Entity Framework users to get the grid to display hierarchical data. When binding the datagrid to a list of Entity objects, the datagrid will now automatically find and load the detail data into subgrids and use master/detail view. To turn this on, set AutoCreateDetailsDescription to True on the DataGridColectionViewSource and AutoCreateDetailConfigurations  to True on the datagrid.

-          We’ve also made it easier to work with unbound columns, in two ways. First, we support unbound data, which appends data to business objects that the grid displays. This method is great for displaying calculated columns or anything else which depends on the data. Second, we now directly support unbound columns, for displaying static information, such as a delete button for every row, progress bars, or any other controls or content which don’t depend on data.

The other important updates in this release deal with filtering. In previous versions, we offered Excel-like auto filtering, which provides a button for each column so that users can filter in the same way Excel does. In this version, there are two important additions to filtering capabilities for end users.

-          First, we’ve added the ability for developers to define their own custom distinct values to add to the AutoFilter drop-down. You can use this to make the auto-filtering choices a lot more useful for end-users. For example, on a column with dates, you can offer the choice to filter by month. For names, the filtering choices could now be “A-C”, “D-F”, and so on. For numbers, you could group them into appropriate ranges, such as “0-99”,”99-1000” or “Odd numbers” and “Even numbers” – anything you want.

-          Next, we’ve added a new row type, called the Filter Row. This row can be placed in the grid’s fixed or scrolling headers or footers, and provides users with an alternate way to set and view the datagrid’s current filter settings. It’s always visible, and works great with date ranges, as you can set a start and end date to filter by, or set value ranges such as “>5 AND  <10”. You can filter Booleans using a three state checkbox, and strings can be filtered by typing a value that is contained in the string.

One last thing. The datagrid is now compiled for .NET 3.5 SP1. This service pack has been available for some time, and according to Microsoft, should be automatically pushed out and installed everywhere through Windows Update around the November timeframe.

Thanks, and I can’t wait to show you the a video of what’s in the next release, a release that’s coming soon, and has lots of amazingly responsive smooth scrolling and animation.

Let us know what else you want us to implement, by posting in the Roadmap 2009 thread on the forums at Xceed.com.

Good programming!

The question isn't "Wither WPF?" or "Will Silverlight marginalize WPF?"

With announcements at MIX09 that Silverlight will gain many of the key features that made WPF special, developers, component vendors and the media are now concerned more than ever about the future of WPF.

It's not WPF they should be worried about.

When you elect to use Silverlight, you are really choosing to forego the full .NET framework and everything that goes along with it that isn't in the latest flavour of Silverlight. Tons of useful capabilities, thousands of APIs, file system access, you name it. And also lots of new .NET 4.0 capabilities as well, like dynamic languages, MEF, parallel programming, hard-core multi-touch support, and so on, that aren't in Silverlight.

Silverlight isn't just a compact, streamlined version of WPF, it is a compact, streamlined version of the entire .NET framework. To say the debate is about whether or not you want to forego some particular WPF features that aren't in Silverlight 3 is focusing on too fine a point. The issue at hand, and the choice being made when selecting the platform to use, is much larger than that.

Think about this question instead: Do you think there will be a significant amount of developers that will continue to use the full .NET framework for their projects? Or will they be using the more cross-platform, quick-to-install Silverlight, whether they are targeting the web or not? Consider both run-of-the-mill business apps which Silverlight 3 tries to easily enable, as well as other kinds of apps, such as “media” apps like movie players and games.

If your answer is that, Yes, there will still be many developers using the full .NET framework instead of Silverlight, then you have nothing to worry about when it comes to WPF. WPF is arguably at the point where it knocks the socks off of Windows Forms. With .NET 4, Visual Studio 2010 and Expression Blend 3, WPF will be the UI framework "par excellence" for those using the full .NET framework.

If your answer is No, you think very few developers will resist Silverlight's temptations such as being able to run on OS X and potentially other platforms, then it isn't just WPF that you should be concerned about. It's the entire .NET framework, even the Windows platform itself.

After all, if there weren't enough reasons left to develop specifically for Windows, well, all that would be left going for Windows would be features. There would be fewer and fewer Windows-only apps. That seems suicidal to me, Microsoft wouldn’t let it happen without a fight. What did Steve Jobs recently say? He insists it’s the apps that will differentiate Apple’s latest product, the iPhone, from the competition.

So what’s my answer?

Yes, moving forward, there will still be plenty of developers that choose to use the full .NET framework, for not-so-run-of-the-mill business apps as well as for a million and one other kinds of apps. I'm talking about a pretty big 'Long Tail'. And many of those apps will need a UI, and that means WPF, not Silverlight. Sure, Silverlight 3 has multi-platinum superstar potential, but WPF should get a few gold records as well. I think it’s far from withering away or being marginalized, as many are worried about.

Note: This blog post is edited from time to time to keep it up to date.

Microsoft has completed development of a basic WPF grid. It isn’t distributed as part of any RTM runtime of WPF, but is included in the .NET / WPF 4.0 beta. Many people are already trying it out.

Meanwhile, Xceed has released v3.2 of our entry-level datagrid for WPF called Xceed DataGrid for WPF Standard Edition, improving the feature set and supporting the latest .NET capabilities, such as Entity Framework, which even Microsoft's own datagrid doesn't have built-in support for. Xceed DataGrid for WPF version 1.0 was released about 2.5 years ago on the same day as Windows Vista and .NET 3.0 were released. We clocked 11000 hours of R&D to bring that initial version to market. I suspect we've quadrupled that effort for the latest version and for the additional features in the Professional Edition. These are, by far, the most mature products for WPF available.

We've priced the Standard Edition at an affordable $299.95 per developer. We think the return on investment will come back to you many times over. Here's why:

10 reasons why you should pass on using the basic Microsoft grid, and adopt Xceed’s Standard Edition instead. 

1. Greater reliability

Even though the new grid has Microsoft’s signature on it, the product is still raw, unproven, and has its share of bugs. Xceed on the other hand has released 9 major updates, 26 total updates to our datagrid, tweaked hundreds of items to satisfy developers, and has brought the product to a highly stable state. Stable enough to be used by Microsoft in Visual Studio Team System 2010, and by IBM in SystemBuilder, for example.

2. More features

Xceed’s Standard Edition not only provides the capabilities the basic Microsoft grid does, but packs a total of over 100 built-in features, so you have more to work with. You’ll spend less time hunting in forums and blog posts, or experimenting to achieve your goals. Features such as grouping with UI virtualization and group-by row, masked textbox and other cell editors, fixed headers and footers, support for XML data sources, scroll tips, input validation and additional themes.

3. Instant upgrade path / Don’t paint yourself into a corner

If you use the basic Microsoft grid, and find you need one or more capabilities that it does not provide, you are effectively stuck. You must either attempt to develop them yourself (which may be very costly or perhaps not even feasible if the datagrid was not designed with that scenario in mind) or lose all your development investment to replace the control with a more suitable one. With Xceed’s Standard Edition, the impressive set of advanced features from the Professional Edition of the product are already built-in, tested, and ready to be immediately activated with a new license key if needed.

4. Less hacks

Developers are already spending time and money attempting to make the basic Microsoft grid do things it is not designed to do out of the box. This often results in workarounds with mediocre results. For example, attempting to achieve a Master/Detail view by placing a second grid instance in a row’s “Row Detail” area. This will, at best, provide a confusing scrollbar-within-scrollbar scenario with a poor user experience.

5. Frequent updates

If you encounter an issue with the Microsoft grid, do not expect a speedy update. Need support for the new Entity Framework but it doesn’t support it yet? It could be a long wait. Once a Microsoft control is finally released inside a platform as opposed to being released on Codeplex, it typically receives little attention until the next major platform release, historically a year or more later. On the other hand, Xceed DataGrid for WPF Standard Edition is updated often, providing timely updates that address the wide variety of new needs customers have.

6. Increased productivity

Becoming productive with Xceed’s datagrid is easy because it comes with extensive documentation and a wide variety of sample applications. At present, Microsoft grid includes little, if any documentation. There’s also an easier installation experience and a much better design-time experience thanks to a design-time configuration window that lets you set up most features quickly and easily.

7. Wow factor

Why make the switch to WPF if nobody can tell the difference? The Microsoft grid looks and feels like a typical Windows Forms datagrid. There’s nothing WPF-like about it, it doesn’t include any themes and there are no subtle animation cues anywhere. While it can be styled by a designer, and is a true WPF control, out of the box it doesn’t bring any new UI goodness to the table, and doesn’t raise the bar. In contrast, Xceed has developed and offers a variety of themes that have wowed developers over the past two years. Xceed is proactive as well, having already demonstrated the upcoming smooth scrolling feature (easy for WPF to handle thanks to offloading the task to the GPU), touch gestures and sticky group headers. This isn’t your father’s WPF.

8. New interface styles

Commercial components typically incorporate support for new interface styles much sooner than Microsoft does. For example, Microsoft’s own components only started supporting the Office 2003 style in 2005. If Microsoft introduces yet another style (and this is sure to be the case), you’ll either have to wait for Microsoft or someone else to style and code it for the Microsoft grid, or do it yourself. With Xceed’s datagrid, you can be sure a theme for the new style will promptly be available. In the case of the basic Microsoft grid for WPF, even the Office 2007 themes aren’t available. They are available as an upgrade to Xceed’s Standard Edition.

9. Better support to help you get to the finish line.

The technical support offered with Xceed’s components is far more targeted and can make all the difference on the road to completing your project on time and on budget. If you use the free Microsoft datagrid, there is currently no consistent source of help, only forums. With Xceed, it is in our best interest to ensure everyone gets help. If you want priority support, it is also available, without breaking the bank. To enlist guaranteed help from Microsoft can be prohibitively expensive, and may not be available yet for the WPF grid.

10. Built to last

Remember the improved Microsoft datagrid for Windows Forms 2.0? It was a complete redesign, with a new API that you had to learn. You could not swap out the previous version, make a few minor changes, and recompile. Microsoft’s free new WPF datagrid also has the potential to follow the same path. Xceed datagrids, on the other hand, are designed with a wide variety of future features in mind. The products are architectured to evolve without causing you to make major changes or to restart with new controls.

Conclusion

Xceed’s user interface division exists solely to produce datagrids. As a result, the entire development team focuses on datagrids and what they need to be first in their class. Microsoft, on the other hand, does not seem to aim to build the best controls, but rather to provide basic implementations with enough extensibility to enable common development scenarios. Xceed products give you the best return for your time and money.

At PDC 2008, I just went over to the Channel 9 lounge this thursday morning 10:30 am and with the help of a third-party witness sitting near the folks playing Rock Band 2, Dan Morphis from AFHCAN.org Alaska, drew the three XBOX 360's, one for each day we spotted PDC 2008 attendees wearing the "Datagrids, transformed." badge.

Day 1 winner was: Bill Janczac

Day 2 winner was: Kris Bruland

Day 3 winner was: Bob Sampson

Congratulations to the winners, you will be contacted by email shortly to obtain your address information. Thanks to all the hundreds of people that wore the badge at PDC 2008, I was told it was the third most popular badge by a friend. The first being the default PDC badge, the second being the white "brains" badge, and Xceed's being third. Nice.

This past week we released our second Silverlight 2 component, Xceed Real-Time Zip for Silverlight. Our first Silverlight 2 component, Xceed Upload for Silverlight, was the industry’s first commercially available control for Silverlight 2. I think it’s great that we’ve been first to release a component for many of Microsoft’s new development platforms in the past 10 years:

·         1st .NET component (Xceed Zip for .NET, alpha, Nov. 2000)

·         1st WPF component (Xceed DataGrid for WPF, RTM, Jan. 2007)

·         1st Silverlight 2 component (Xceed Upload for .NET, RTM, May 2008)

·         1st Workflow Foundation activity (Xceed Activities for WF, RTM, Apr. 2007)

·         1st Biztalk Server 2000 component (Xceed FTP for Biztalk, RTM, Jun. 2001)

·         1st .NET Compact Framework component (Xceed Zip for .NET CF, Beta, Apr. 2003)

And, I couldn’t confirm this through Archive.org, but I seem to remember Xceed being the first to release a 32-bit OCX during the changeover from 16-bit OCX components to 32-bit ones about 12 years ago. By the way, our domain name back then was xceedsoft.com.

Back to Xceed Real-Time Zip for Silverlight, what’s great about this product is that it compresses files or streams into Zip archives and decompresses Zip archives in a streaming fashion without using intermediate disk/memory storage or temporary files. That really jives with the likes of Silverlight, which doesn’t allow local write access.

Why is it called “Real-Time Zip”? Not because it is faster, since it avoids disk writes, but because it starts outputting a Zip file as soon as the first bytes of the first file to compress are provided.  In the same way, it can also start unzipping a Zip file as soon as the first bytes of the Zip file are available. By the way, the size or number of files to compress or uncompress has little bearing on the memory footprint. You can Zip many multi-GB files without worrying about memory, though if you are Zipping tens of thousands of files (regardless of their size), memory use might start to become be a factor. The component must keep some information (filename, path, checksum, size...) about each file in memory in order to be able to write the Zip file’s “central directory” portion at the end of the Zip file.

I should also mention that strong 128- to 256-bit AES encryption is also supported while compressing/uncompressing.

What use is there for a Zip library with Silverlight you might ask? First, it will let your Silverlight application read and consume the contents of a Zip file that’s stored on your user’s local filesystem. In the same fashion, it will allow your app to receive a Zip file from a server and unzip and consume the contents as the Zip file is coming in over the wire. Second, it will allow your code to compress a bunch of user selected files from their local filesystem into one Zip file that you can start uploading to a server or another user even before the complete Zip file is ready.

Well, hope to see you at next week’s PDC 2008 event, where Xceed will be dedicating the our booth to exhibiting our advanced datagrid for WPF.

Odi