I would like to add excel spreadsheet functionality to the WPF toolkit datagrid, can this be done?
I am building a wpf client-server application and I want client tohave wpf toolkit datagrid cells which would behave like excel spreadsheet cells would behave... Meaning they would have formulas and such... just like the spreadsheet would.
I am trying to accomplish this without the usage of Farpoint datagrid product that i already use for a winforms client-server application.
Thanks.
Did you have a look at Clear Office?
It is similar to farpoint but written in WPF. Very easy to use. No COM interop.
Theoretically it could be done, but it will require a fair bit of coding (I'm talking weeks to months here rather than days). You could possibly knock up a simple implementation using limited functions reasonably quickly, but you'll soon start to run into problems. If I were you, I'd look into alternatives.
Related
Which library to use for WPF?
Infragistics
ComponentOne
SyncFusions
ActiProSoftware
Telerik
#Reed - None of the Syncfusion WPF controls were ported from Windows Forms. With the grid control, most vendors use a simple ItemsControl based architecture. We have a much more elaborate infrastructure for highly optimized cell oriented rendering. This was implemented to achieve performance as close to Windows Forms performance as possible. The effort on our end to deliver this solution when contrasted with a pure ItemsControl based approach was at least 5x. We have a lot of customers using our Windows Forms controls in real-time scenarios and we wanted to give them the ability to move over to WPF without losing on the performance front. Our key controls offer excellent rendering performance even with millions of data points in direct contrast to solutions that are based on a simple ItemsControl based approach. Our controls often have a steeper adoption curve than others but in the long term we do believe that they are easier to maintain and update. Just my two cents:) Also, we are really keen to work with you on any issues that you are running into. Please let us know. My email is danielj(at)syncfusion.com.
#Tom - If you can send us feedback on the gauge we would greatly appreciate it. We are always looking for ways to improve and your feedback will be really useful.
Ultimately it depends on what you need. I think Syncfusion offers the widest and most actively deployed control suite on the WPF front. Disclaimer - I work for Syncfusion.
I work for a large firm which has long-term license agreement with Syncfusion so I had to use their products for years in pain.
I agree with Reed for Syncfusion's model. They converted their Winforms model (which has major bugs) to look it like WPF, I believe the whole suite is nothing to do with WPF, most of their controls cannot be controlled in XAML, you need to use code behind in order to style even simple things.
They are actually improving this to look more like WPF however with Syncfusion one issue is when you upgrade to a new version, it always breaks previous version based code. It is their marketing strategy and you spend weeks to figure out the new system.
One other issue with Syncfusion is they have quite poor documentation, their support is very weak, so you need to discover things on your own.
I used Telerik WPF in one project which is a much better choice, the performance is much better and the model is really easy to maintain.
We just started to buy DevExpress due to the pain of Syncfusion over years and I believe this is quite good WPF product. It is easy to use, they have really good support and nice documentation. The controls look very professional. First time I feel like I am using actual commercial .NET toolset.
*I do not work for DevExpress or Telerik.
They all have advantages and disadvantages.
Personally, I've found Telerik and Infragistics seemed more like they were designed specifically with WPF in mind.
Syncfusion's offering is more of a port of their Windows Forms product, so the design is more like they're other product lines.
That being said, each product you listed is good - and each have their own feature set. There is no substitute for trying a demo and seeing how you like working with the products in question.
I'm a fan of Component One, mainly based on personal taste.
ActiProSoftware have some good controls, but I find that they don't expose enough properties to make it easy to style and customize, though you can get around this with implicit styles.
Xceed have my favourite Grid control, lots of cool features and easy to work with.
I don't particularly like Telerik and I've never tried SyncFusion.
I would love to try Infragistics as that is one that I haven't tried, but have been really impressed with the demos. Does anyone have any comments on the architecture of Infragistics?
Like Reed said, they all have their advantages and disadvantages, but from my experiences I would recommend Component One.
HTH
None of the above, just use WPF Toolkit for DataGrid and VisualStateManager. It is not that hard to style the controls in WPF/Blend, plus it makes YOU more proficient and your code leaner.
P.S. Though, you might still use third-party reporting, since there no built in support for reporting in WPF.
If you are looking for a WPF Control Library there is the WpfDynamicUI Library.
It is an open source control building the user interface for the DataContext you provide.
It supports Charting, DataGrid, Map, Filtering, Paging, Nesting views and more...
Can be an alternative for building Line Of Business application.
PS: I am the coordinator of WpfDynamicUI
Well we are considering to move from WinForms to WPF, what pitfalls does WPF have? And we got component one's flexgrid is there any wpf grid that has the same functions? one nice thing with it is that you can implement your own draw method for the cells... It can merge cells print and save to many file formats..
In general, WPF development is very different from WinForms. You should expect it will take some time to learn the new technology (or you might even need to hire new developers =)).
WPF approach is in many ways better than WinForms' one: check out styles and triggers, data binding, control templating, eventing model.
I would recommend you to start exploring it, but wait for the WPF 4 (and the boring MSDN page) to start the actual migration, because it is going to be even better and close some of the very annoying gaps.
First of all, WPF works pretty different from Windows Forms and likely requires a different approach on how to structure and design the application. At least it works way better if you do it the way it was conceived.
As for single Windows Forms controls, this shouldn't be a problem. There is a WindowsFormsHost which enables you to include Windows Forms controls in WPF.
The change from winforms to WPF is not a change I'd reccommend unless you have specific requirements which WPF fulfills - WPF is not intended to be a replacement, simply an alternative which is more suited towards graphically rich applications.
If you do have a specific requirement then you also might want to consider embedding WPF controls into winforms applications, rather than converting your entire application.
The learning curve is slow to get going, but once you get the idea it all starts to make sense. We have "Pro WPF in C# 2008" book floating round the office and its been a great help. Of course most things get googled to find an answer, but to find out why something is done the way it is this book was a great hope - to me anyway.
There are some annoying features but its still WPF is still quite new. Like most things, if you come across a problem someone has likely come across it before and there is an answer out there!!
J
Take a look here for a datagrid: http://wpf.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=29117
The main hurdle with WPF is simply the huge amount of new stuff to learn (if you wish to use it properly). I'd think twice if you're on a tight schedule, but it might be worth it if you have 6 months to spare...
Speaking from just my experience, moving from Windows Forms to WPF took some re-learning. A few months into the transition most changes made total sense. WPF removes much of the frustration associated with using Windows Forms. It allows for a truly rich UI development experience especially when working in tandem with designers. I strongly recommend WPF Illustrated by Daniel Solis as a learning aid.
With reference to the grid, Syncfusion offers a WPF grid control that implements the features you have asked for. It implements true virtual mode with cell level customization, printing and export to multiple formats including Excel. Disclaimer - I work for Syncfusion.
I've recently been using Excel and Powerpoint 2007, and it's seems clear that the shapes are using WPF.
Edit - I know the shapes have existed in Office for ever, that is not my question. Look at the fill possibilites for shapes in 2007, look at that gradient fill, look at its parameters - that's the same as WPF as far I as I can see. So back to the original question, does anyone know what Office is using to do that? I'd be pretty sure that MS didn't re-invent all that graphical niceness, 3D, rotation and so on just for Office, when they have the exact same stuff in WPF already.
Can anyone confirm that office is using WPF? If so what I'd like to do is get to those WPF items so we can use them in our own apps, effectively use Excel/Powerpoint as a WPF generator.
The shapes you see in Office 2007 have been around since long before WPF. These vector graphics could in fact have been rendered by WPF, and if Office is ported to WPF some time in the future, they probably will be.
If you are looking for an easy way to create vector graphics for your WPF app, you might want to take a look at Microsoft Expression Design.
I doubt. You can always make any effect you like without WPF it's just a matter of code
Office is old code it pre-dates .Net!
As far as I know, you could create the Office 2007 look and feel using MFC Feature Pack (See this tutorial: http://nibuthomas.com/tutorial_mfc_feature_pack1_part1 )
I also have a desktop application written in Windows Forms that is a middling size (a couple dozen major forms backed by 46 tables in the database). I'm thinking about rewriting the UI in WPF, but before I go there I was curious if there were any war stories about doing such a conversion.
I use LLBLGen to generate my low level data access objects, and I have a business logic layer above that. The forms are databound to the business logic objects, although the main form uses caching objects to minimize round trips on the more common navigation routes. The UI never speaks directly to the database: always through the UI -> business logic -> low level -> datastore path.
One control that I use heavily is the TreeView, which acts as a visual guide and short range navigation tool. The tree has been heavily customized with icons, highlight colors and it is the control I worry most about porting.
Is there a story that might convince me to go ahead and convert (or conversely, wait until Microsoft is closer to pulling the rug out from under Windows Forms)?
EDIT: I was asked in a comment what motivation for conversion I have. I have some concern about future proofing: I have 500,000 lines of code that were originally ASP and VBScript. We have been porting the functionality over time to ASP.NET and C#, but only as we make changes to the code. The upside is we have kept costs minimized, the downside is half the code remains ASP and VBScript. I'm concerned about a similar situation arising with Windows Forms applications.
Am I worried today about Windows Forms going away? Not even close to it... but the application is moving from ASP and VBScript to ASP.NET and C#, has nine years of history behind it, and probably won't be replaced this decade (instead, simply it will evolve). The desktop application is likewise a long term project with years of history.
For me, the WinForms vs. WPF decision is a simple one - if normal people are going to use it, the user interface can make the difference between a winner and a loser.
It is definitely a steep learning curve. But I have NEVER gotten done with a nice looking WPF application and said "Man, I should have used WinForms".
I'd say invest in the effort to make your UI better whenever possible for your customers, so yes to WPF if that's the case.
WPF has a ridiculously large learning curve. It will most likely require you to rewrite a lot more than you think for just changing the UI. Also, a lot of features that would make WPF nicer to use just aren't implemented or included in WPF yet. Unlike routeNpingme, I have written nice looking WPF applications and have said, "What a waste of time, I should have used Windows Forms and completed in 70% less time".
EDIT:
Also, unless Microsoft figures out a way to make WPF easier to learn, I don't see it catching on to the masses at all. WPF can do some very cool things, but a little effort to make it easy to understand instead of throwing stuff over the wall would have gone a long way. It would not surprise me in the slightest to see Microsoft drop WPF for something easier to work with in the not too distant future. So don't go changing your Windows Forms application just for the sake of changing it.
Pros:
Ridiculously easy data-binding (most of the time)
Ridiculously easy customization of look and feel
Cons:
Very steep learning curve
Some obvious bugs or issues. Similar to .NET 1.0 Windows Forms
Little or no tool support
In my opinion, WPF will definitely replace Windows Forms at some point. However, right now the tools are the main thing keeping it back. I disagree with Dunk that Microsoft will drop it for something else. Change it yes, but I think it's here to stay.
Should you change your application to use WPF now? No. Feel free to learn WPF but if your application works fine currently, then WPF won't give you anything extra. It just makes doing what is possible in Windows Forms much easier.
WPF is great. It is particularly good for extending controls like TreeView with customisations. You can add a string as an item in a TreeControl. You can also add a small panel containing an image and some text in various fonts and colours. Or you can add buttons, or anything you like. It has a completely general composability system. Same goes for ListBox, ComboBox, Button, etc. All their content or child items can be as simple as a string or as complex as a multipage document viewer with zoom buttons (if you want).
But the only way to find out is to try porting one of your forms. It shouldn't be too hard to make a WPF Window open from within your existing app. I started using WPF by making new GUI panels that were hosted inside a C++ Win32 application. Eventually it was so obvious that WPF was the way to go that we switched it around and made the outer shell WPF, with some ancient dialog boxes still implemented by the old C++ code where we couldn't be bothered to rewrite them (probably exactly what will happen with Visual Studio 2010).
Porting is a tough decision. So just some thoughts to help you decide.
WinForms is OK while you work by the rules and keep everything drawn as is. But even redrawing a border on some controls may require complex and precise work and skill, as you already know from tree customization. The same tasks can be done in a very elegant way in WPF.
Also, the data-binding in WPF saves me a lot of time. In the long term, you end up thinking about data-binding scenarios that could not be remotely possible in WinForms without special-case coding.
I do not even consider WinForms for new development -- there is no excuse for customization costs.
I have started introducing WPF elements within my WinForms application and so far have had a lot of success.
The application's main component is a grid control and I haven't yet found the text rendering of WPF sharp enough to present a table of important textual data.
But the application has several additional panels, and the majority of these are implemented using WPF. So, I'm going for a hybrid of WinForms and WPF via the ElementHost control.
I have found the flexibility of WPF to allow for a much more attractive and usable UI, and my users seem very happy with it. In my case, it's also been politically easier to introduce WPF one panel at a time.
WPF's main value to me is in the binding, not in the cooler UI. The worst WPF I've ever seen is when people use WPF just because it's newer, and put all the work in the code-behind, including not using binding. What you get is WinForms data management. So be sure you're going to use the wonderful binding when you do WPF.
I would port the OP's business logic to a business layer for ease of maintenance and conversion. I wouldn't port the WinForms to Xaml at all unless new Xaml functionality was needed, and preferably not until after the functionality was ported.
I have seen a lot of discussions going on and people asking about DataGrid for WPF and complaining about Microsoft for not having one with their WPF framework till date. We know that WPF is a great UI technology and have the Concept of ItemsControl,DataTemplate, etc,etc to make great UX. Even WPF has got a more closely matching control- ListView, which can be easily templated to give better UX than a traditional Datagrid like display. And I would say a readymade DataGrid control will kill or hide a lot of creativity and it surely will decrease the innovations in User Experience field.
So what is your opinion about the need of DataGrid in WPF as a Framework component? If you feel it is necessary then is it just because the world is so used to the DatGrid way of data display for many years?
Some other threads having the discussion about DatGrid are here and here
Link to WPF ToolKit - Latest WPF DatGrid
DataGrids are excellent for displaying large amounts of tabular data bound to a backing store.
But what happened in the WinForms world was that people often used them for everything that required a multi-element scrolling list. Souped-up third-party DataGrids soon became available that allowed columns and fields to contain buttons and ComboBoxes and icons, etc.
The DataGrid became a workhorse because there was a need for something it could be coaxed into behaving like. Similar happened to DataTables before generic collections came along--and when you're using lots of DataTables, presenting it in the UI with a DataGrid is the path of least resistance.
I think that when WPF came out, a lot of programmers like me were still thinking in this fashion, and sought out WPF ports of the DataGrid concept.
Can't think of a better control to display tabular data, especially in business apps where you don't want to reinvent the wheel by templating/developing a (Headered)ItemsControl to make it behave like the good old DGV. I'm sure you saw this.
Nobody is disputing that you can make a DataGrid control in WPF yourself. The same can probably be said about WinForms, although it would be more difficult. I've implemented some functionality with ListView - presenting tabular data is easy, you could even say it's well supported. However, the amount of code, manually written code, needed to make an editing ListView is enormous.
The business applications usually require editing of many tables, and you don't want to be creative, you want to be quick. That's why DataGrid is needed in my opinion.
Yes DataGrids will never go away as essential business UI components. People love their spreadsheets and we want to share in that love!
Note that MS are shipping these extra controls - they have created the WPF Toolkit on CodePlex to provide a fast-turnaround, open-source style of deployment.
It already includes a DataGrid and Calendar.
Yes it is!
Among many other controls that ms failed to deliver. (Datepicker, NumericControl)
MS should first give us the tools to get the job done, that is the least i expect from a programming enviroment with the hype of wpf.
It is essential, but you can achieve nearly the same effect with a ListView that is using a GridView, can't you?
After working with WPF for about 2 years now. I would say that a DataGrid is really just a glorified ListBox (since [almost] everything in WPF is styleless).
One could style a ListBox to take an Entity of some sort and show a "record" control for each entry. Depending on how flexible these are made, they could automatically adjust based on the entity passed.