As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have an upcoming project which will have to be able to print simple reports from its data. It'll be WPF-based, and I'm wondering which way to go.
I know that WPF introduces its own printing technology (based on XPS) which looks quite easy to use. However, part of me wonders whether it would just be easier to use the ReportViewer control and embed it in a Windows Forms host control, since that will give users the ability to export to a variety of formats as well as print.
Has anyone had any experience with printing/reporting from WPF? Which direction would you recommend?
Limitations of RDL
I originally went with RDLC/ReportViewer for printing with WPF but found it very limiting. Some of the limitations I found were:
RDL could only create the most boring of reports
It was much more work to create a report using RDL than in straight WPF: The design tools are very primitive compared to Expression Blend and RDL deals only in tables
I didn't have the ability to use ControlTemplates, DataTemplates, Styles, etc
My report fields and columns could not effectively resize and rearrange based on data size
Graphics had to be imported as images - it could not be drawn or edited as vectors
Positioning of items required code-behind rather than data binding
Lack of transforms
Very primitive data binding
Printing directly from WPF is very easy
Because of these limitations I looked into creating reports using pure WPF and discovered it was really quite trivial. WPF allows you to implement your own DocumentPaginator subclass that can generate pages.
I developed a simple DocumentPaginator subclass that takes any Visual, analyzes the visual tree, and hides selected elements to create each page.
DocumentPaginator details
Here is what my DocumentPaginator subclass does during initialization (called when first PageCount is fetched, or during the first GetPage() call):
Scans the visual tree and makes a map of all scrolled panels inside ItemsControls
Starting with the outermost, makes items in the ItemsControls invisible last to first until the Visual fits on a single page without any need to scroll. If the outermost can't be reduced enough, reduces inner panels until it succeeds or has only one item at each level. Record the set of visible items as the first page.
Hide the lowest-level items that have already been shown on the first page, then make subsequent items visible until they no longer fit on the page. Record all but the last-added item as the second page.
Repeat the process for all pages, storing the results in a data structure.
My DocumentPaginator's GetPage method is as follows:
Look up the given page number in the data structure generated during initialization
Hide and show items in the visual tree as indicated in the data structure
Set PageNumber and NumberOfPages attached properties so report can display page numbering
Flush the Dispatcher (Dispatcher.BeginInvoke(DispatcherPriority.ApplicationIdle, new Action(() => {} ));) to get any background rendering tasks to complete
Create a Rectangle the size of the page whose VisualBrush is the visual being printed
Measure, Arrange, and UpdateLayout the rectangle, then return it
This turned out to be quite simple code, and allowed me to turn practically anything I could create with WPF into pages and print it.
Additional reporting support
Now that my paginator is working, I no longer have to worry very much about whether I am creating my WPF content for screen or paper. In fact, often UI that I build for data entry and editing also works very well for printing.
From there I added a simple toolbar and some code behind, resulting in a full-fledged reporting system built around WPF that was far more capable than RDL. My reporting code can export to files, print to the printer, cut/paste page images, and cut/paste data for Excel. I can also switch any of my UI to "print view" with a click of a checkbox to see what it will look like if printed. All this in just a few hundred lines of C# and XAML!
At this point I think the only feature RDL has that my reporting code doesn't have is the ability to generate a formatted Excel spreadsheet. I can see how this could be done but so far there has been no need - cutting and pasting the data alone has been enough.
From my experience my recommendation would be to write a paginator, then start using WPF itself to create your reports.
We had this same issue, and ended up using RDLC/ReportViewer for now. There's no native WPF reporting tool (that I know of) and RDLC is pretty simple to use, and is free. The runtime overhead for it is small (around 2Mb) but you must remember to distribute it as it isn't part of the .NET Framework.
Look at http://wpfreports.codeplex.com/
Take a look at PdfReports. It's a code first reporting engine, which is built on top of the iTextSharp and EPPlus libraries. It's compatible with both .NET 3.5+ Web and Windows applications.
How about Scryber? It allows PDF report templates to be defined using xml and bound to data within your application at run time. http://scryber.codeplex.com/
To elaborate on Ray Burns answer, if you are looking for an implementation example, see:
Custom Data Grid Document Paginator
Which is a great starting point.
I've reccently accomplished task of developing own reporting system, which basically consist on design enviroment and data Source manager. The first task was to develop WYSWIG-like design enviroment. I've done this using GDI+, without even bothering about printing, as it came out printing/generating print preview was easiest than i expected, In general it only takes to draw all things on screen to graphics object of printing event.
I think that in case of WPF it would be similar, so all you should worry about is to display you report on screen and printing would be only few lines of code.
Without getting into a whole political discussion about the future of WPF, the best option we found was to wrap the ReportViewer in a Windows Forms host control.
http://blog.pineywoodstech.com/index.php/2012/01/using-microsoft-reportviewer-with-wpf/
Related
We need to get rid of DevExpress Bootstrap Controls for ASP.NET Core from project.
What would be the easiest/cheapest/feastet solution?
To simply rewrite everything with a different framework like Angular/Vue/React?
Maybe there is a known framework/method of migrating to DevExpress ASP.NET Core Controls? Or to something else?
How many controls were used from DevExpress?
If you only used a few controls, then you only need a few replacements.
I would not call purchase of some controls from DevExpress a whole "framework", but that of only purchasing some controls to use with your project.
So, does the project use 3-5 or 50 of those DevExpress controls? (by using, I mean DIFFERENT kinds of controls).
If you only used a few, say like their GridView, then you would only need to find a replacement for their gridview control, or simply use the built-in one, and fancy it up with some css, and addtional options. (I would make a user control).
So, you want to determine what the controls used did, how many different controls were used, and then find some controls that have a great look and feel that you like.
Their grid controls are VERY nice, since they have some "really" nice filter options for the header of that grid control.
So, you need to find some control replacements, but how many did the project use will quite much determine scope here.
So, in place of say their tab control, then consider using the jQuery one. As noted, I would wrap say the jQuery.UI tab control into a user control, so then you can just drag + drop in that jQuery.UI "tab" control in place of the devExpress one.
Same goes for the multi-select combo box (dropdown list).
So, either you cobbile together some replacements of your own, or you find some replacemetns, or you buy some more controls from another vendor.
The challenge and issue will of course be that each of their controls has a specific object and event model.
However, that's not really any different then say if you started used sweet-alert, and now want to replace sweet-alert say with some jQuery.UI dialogs.
I would say that the real challenge of replacing their controls is often not so much finding a replacement, but finding something that has a great look and feel. The main huge wonderful bonus of the devExpress controls tends to be their look and feel. In other words, they had someone with REALLY good taste in terms of look and feel.
I mean, for years I used the ajaxtoolkit. (free, open source). it was and still remains a fantastic set of controls. The pop dialog, the tab control, the multi-select combo box, the HTML editor?
They are all great, but their HUGE downside is not the features, but the controls from that free toolkit look like something from the 1980's!!!
The popular jQuery.UI? Same thing, the controls look ugly and something designed by a un-employed rodeo clown living in a trailer park.
There is a HUGE but BEYOND huge reason that bootstap is so popular.
Know the answer?
Why of course bootstrap is popular for ONE big HUGE massive SIMPLE reason:
Bootstrap has a fantastic look + feel. (zero other reasons for bootstrap being popular!!).
If you ever hired a graphic artist to re-work the look and feel of your web site? Guess what? Their resulting work and suggestions will look like the default of bootstrap!!!
So, someone in the print and graphic design industry or someone with VERY good talent and great taste created the bootstrap system. So, when you use bootstrap, then you get fantastic looking results, results that normally would take a full time graphic artist on your staff.
Regardless, we are wondering off topic here.
The main issue you have to determine is how many controls were used from devExpress. Most of their controls do follow a similar object model as the base controls found in asp.net webform controls.
So, for example, jQuery.UI controls has a great set of features (a great set of UI components), but they look way too dated and old fashioned.
The issue you have is not that you want to replace some of the devExpress controls you used, but how much work it would be to replace say a dev-express "gridview" with another different grid control. Every single one of those controls used will not only require you to spend HUGE amounts of time finding a replacement, but I think the LARGER issue is finding something that don't look like it was created by someone living in mom's basement, or by that drunken un-employed rodeo clown that does not belong in our industry.
your issue is not finding some replacement controls, your issue is how much code and money (time and resources) you have available to replace those controls.
You can no more change a bunch of code in c# to then using say client side JavaScript can then you take some Pascal code, and covert that code to vb.net code.
There no more a replacement for those controls from dev-express then there is deciding tomorrow to re-write some server side code in vb.net to now being client side JavaScript code.
In fact, what I am quite much telling you?
How the computer and IT industry has worked for 50+ years has NOT change one bit, and it not change one bit if you decide to rip out some existing controls and replace them with different controls.
Its possible you are asking for something you never seen, never heard of, and thus are imagining some magic wand here, but those don't exist in our industry either, do they?
As I noted, for quite some time, I used the AjaxToolKit. Turns out that jQuery.UI has near EVERY the same kind of controls available. But, the massive difference is jQuery.UI controls are client side ones, but worse yet, they don't work the same as the AjaxToolKit ones. In other words, there is a nice "tab" control in AjaxToolkit, and there is a nice tab control in jQuery.UI. So, they both are tab control, but THEY are VAST different in their operations, how you use them, how they work.
However, both the jQuery.UI and the AjaxToolkit tab control?
My gosh, do they look like crap.
At least the jQuery.UI one can be easy bootstrapped styled.
Again, note how we not really now back to a JUST having a control replacement, but one that looks VERY nice and VERY tasteful out of the box, and a control that should take zero efforts on your part to obtain that great look and feel.
Want to know what product has those great looking controls and great look and feel out of the box?
the DevExpress ones!!!
I'm writing an application that is supposed to show and hide the content of the main window stack panel based on the user choice. For example, the user clicks on the button that displays the list of the customers, then click on the button that displays the ordering form. The customers content should be hidden and the ordering form should be visible. Moreover, if there are contents with related information (like customers and their data) I want to be able to change the data in one window and it should automatically refresh the data in the other window when the user decides to open it. Is there a good way to do it in MVVM?
Thanks for any suggestions.
Because this question is so generic, the answer must be as well, and the answer is that this is exactly what MVVM is for - modeling data and binding it as needed. In fact, I would argue that a majority of MVVM examples you find online will be some flavor of an answer to your question, most likely using good ol' Northwind.
It sounds like you need to really take a good look at how you want to do your design before you jump in and start coding.
You might want to check out Prism (or as it is really named Composite Application Guidance). You can build really complex and modular designs with it.
You might be interested in the MVVM sample applications of the WPF Application Framework (WAF).
Writer: Shows how the Views (UserControls) can be switched (Edit mode; Print Preview mode).
BookLibrary: Shows how data modified in one View is automatically updated in other Views.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm mostly a C# programmer, I stopped writing Java about 10 years ago, but I try to keep up with the technology in Java by reading articles, talking with friends, etc.
I've heard about the new rich GUI framework called JavaFX, but couldn't find any resource comparing it with non-Java parallels.
Since I'm very familiar with C# and WPF, I'd like to get a feel about how similar or different the two technologies are.
EDIT: Seeing as there's no answers coming, I'll try to be more specific:
WPF uses XAML to create the visual tree, does JavaFX have something similar?
WPF is best used with binding to a view model in an MVVM pattern, does JavaFX also make extensive use of binding?
WPF utilizes the GPU for rendering, does JavaFX do the same?
How does Silverlight compare to JavaFX when run through a browser on a net pc?
... More to come...
I'm changing this to community wiki so that the comparisons can keep getting updated (hopefully).
I have been learning JavaFX for the last couple of weeks. Here is a high level overview of how it compares to WPF in my eyes:
All of my comments are related to JavaFX 2.0. This information will probably be subject to change as the platform is still fairly immature and is being actively developed.
Graphics
Like WPF, JavaFX uses a retained graphics rendering system. The user interface comprises a scene graph which is composed of 'nodes' which can be thought of as conceptually similar to WPF's UIElement.
JavaFX will offload the graphics rendering to the GPU if available. The graphics system uses DirectX on Windows and OpenGL on other platforms.
Markup
JavaFX user interfaces can be created both in code and via FXML markup which is similar to XAML in that the object graph can be created by nesting elements.
FXML has some similar features to XAML such as property binding (simple expressions only) and binding to event handlers (any onEvent method). Event handlers can be declared in-line but typically you would bind to an event in the associated controller.
FXML files can have an associated controller which allows you to declare complex event handlers and to set up bindings between properties. This is a controller in the MVC sense and is not the same as a viewModel in the WPF world (typically a controller will have references to nodes and controls).
One difference to WPF is that it appears that the FXML is not compiled into an intermediate binary representation like BAML. I haven't noticed any performance issues yet but have not used the system extensively. I have noticed though, that FXML usually tends to be shorter than any XAML as the platform still encourages you to write code and styles are declared separately.
An introduction to FXML can be found here.
A scene builder is provided free (as in beer), so if you don't like hand coding the UI you can drag and drop elements, set properties and bind to code in your controller and the FXML will be generated automatically. Obviously the scene builder is nowhere near as powerful as Expression Blend but it is still better than the 'designer' provided by Visual Studio.
Binding
JavaFX has a very powerful property and binding system. The Java Bean pattern has been extended to include classes that encapsulate a property (similar to the way WPF dependency properties represent properties). These classes implement interfaces that provide invalidation and change notification.
There is a distinction between invalidation notifications and change notifications. Invalidations just tell you that the binding expression is now invalid and needs to be recalculated; the recalculation does not actually occur until you request the property value via its get() or getValue() methods. If you have registered a change listener, however, then the expression will be re-evaluated immediately and anything that is bound to that property will reflect the changes.
JavaFX exposes these properties in a similar way to WPF with a get and set property and a method that returns an instance of the property wrapper (which are not static like WPF properties).
Complex bindings can be created between multiple properties. Want an integer property to be the sum of two others (a = b + c)? No problem, JavaFX provides a Fluent API to express these kind of relationships E.G.
A.Add(B, C);
If the value of either B or C changes then the appropriate notifications will be raised so that the system knows that A needs to be re-evaluated. Note that in this case, an exception will be thrown if you try and set the value of A as it is bound to the other properties so it does not make sense in this context.
These expressions can be fairly complex E.G. a = (b + c) * (d - e) and can include any number of properties. The fluent API is fairly easy to read and use but is not as nice as some of the Fluent API's provided by some of the Microsoft libraries but this is more down to the Java language limitations rather than JavaFX itself.
Simple bi-directional bindings can be created between properties of the same type so that if one is updated the other automatically reflects the change.
JavaFX also provides a low level API to customise bindings yourself if you want to create a custom binding expression that is not provided by the API or if you are concerned about performance.
One of the biggest differences between JavaFX and WPF is that bindings are primarily carried out in code in JavaFX vs. the WPF way of establishing bindings in mark-up.
An introduction to properties and bindings can be found here.
Styles
JavaFX uses CSS to change the looks of the nodes contained in the scene graph. There is a full specification available which explains the types and the properties that can be set on each node type.
JavaFX also provides some additions that help to improve CSS such as variables that can be defined and used elsewhere E.G.
.button {
my-custom-color: RGB(234, 44, 78);
}
.my-control {
-fx-background-color: my-custom-color
}
It also provides a couple of functions that allow you to derive colours from other previously defined colours which is useful for creating things like gradients. This means a base palette of colours can be defined and the rest can be generated from these values (this is what the default JavaFX CSS file does).
JavaFX CSS does not allow you to define the type of layout used by a node (as of writing this all layout needs to be performed in code). This works really well for me as this was the one aspect of CSS that really caused me pain when using it with HTML.
Personally I prefer CSS to XAML styles which tend to be too verbose for my liking.
A guide to JavaFX CSS can be found here.
Layout
JavaFX provides a number of layout panes that are similar to those provided by WPF. One difference I have noticed is that the measure and layout contract is defined further up the inheritance chain in the Region class.
As previously mentioned, Layout cannot be carried out using CSS but can be expressed using the code, FXML or created using the scene builder (which is ultimately converted to FXML).
Controls
JavaFX provides an ever growing library of controls that we have come to expect. One major difference between JavaFX and WPF is that the controls are essentially black boxes and cannot be re-templated in the way that WPF controls can. They also seem to expose far less properties than the WPF controls.
The controls do expose some of the implementation specific regions to CSS allowing specific areas of a control to be targetted by your styles. This is known as the substructure of the control. E.G. a CheckBox exposes two substructures; the box and the check mark allowing each part of the control to be styled independently. Note that as described earlier only the look of a control can be altered using CSS but the feel cannot. E.G. you cannot dramatically alter the way a TabPane lays out its content by altering its internal layout panel in the way you can with the WPF TabControl.
Whilst this sounds fairly limiting, the preferred way of creating custom controls in JavaFX seems to be using composition along the lines of deriving from a layout panel to position standard controls and re-styling them using CSS.
Conclusion
Overall I am very impressed with what JavaFX has to offer at the moment. Whilst it is no where near as mature as WPF it is being actively developed and Oracle certainly seem to be backing this. Time will tell if it's successful or not.
I would recommend giving JavaFX a try. Read the documentation and try putting together a small application and see what you think.
You should also check out FXExperience.com which is updated regularly with information from the development team.
I think the best way to to get a feel for JavaFX is to just try it out. There are some good tutorials on the JavaFX website. Here's a couple:
The JavaFX language
Creating a UI in JavaFX
They are pretty quick and give you a good feel for the language. There are many others on the JavaFX site if you are interested in more tutorials and articles.
For specific answers to your questions:
JavaFX has it's own declarative language for creating the "visual tree" which is not an xml derivative. The UI is based on a scene graph so you can apply various effects and animation to any node in the graph. See the tutorials for more information. There is also a designer tool for JavaFX (which I have not yet tried).
JavaFX has binding built into the language.
JavaFX on the desktop uses Java AWT/Swing which does use GPU rendering. Every version of Java seems to offload more of its graphics to the GPU. Chris Campbell from Sun has blogged some about GPU acceleration. I'm not sure if the mobile version of JavaFX has GPU acceleration. I found that earlier versions of JavaFX weren't performant enough for what I needed, but I know the latest version does have significant performance improvements over previous versions and they are still working on making it faster.
JavaFx uses Java Applets to run in the browser. As of Java 6 update 10, the Java applet framework has been reworked and though it is not as seamless as Adobe flash, it is much improved. I'm not sure how it compares to Silverlight other than I've had trouble getting Silverlight to work on Linux, but did get JavaFX working on Linux.
Here's another related question.
I am currently using Telerik's carousel control, but it is lacking many features and is buggy. Is there a good control out there that looks the the coverflow control in itunes?
WPF Cover Flow Tutorial
Source Code: Part 7, Download
Author's rebuttal to claim of memory leak (it doesn't): Part 8
In Action: Videos
Contains a detailed walkthrough for building a coverflow control, including features such as reflection. I compiled and tried it out and pointed it to a directory containing hundreds of smallish images (you'll need to edit TestWindow.xaml.cs to point to a directory containing jpg's) and I was impressed with the performance and smoothness of the animation.
I noticed that using very large images degrades the performance though, so I'd recommend using images that are just the size needed for display. For example, when pointed to my desktop background images directory, there was nearly a one-second delay after pressing the arrow key and the item going through the transition (although the animation itself was still fluid, it took a moment to begin).
This is the best one that I found, for what I was looking for - namely, non-commercial, reflections, and smooth animation. I did look at the other ones currently mentioned in the other answers though, here are some comments on them (in no particular order):
FluidKit's ElementFlow
Open source, I used the latest source code, but did not try out any patches
Animation was smooth
Transition didn't feel very refined, the pictures clip each other in an odd way
Didn't seem geared for showing a handful of element's on the screen at once, it tries to show everything, and from some of the discussion comments, apparently isn't virtualized
After adding some images to the demo through the provided button, a large portion of them couldn't seem to get selected
Doesn't have reflections
Mindscape CoverFlow
Commercial
Animation was smooth
Doesn't "popup" selected item, feels very 2D
Has reflections
DevExpress Carousel
Commercial
No online demo and I didn't try to obtain the trial, looks polished though
Telerik Carousel
Commercial
Animation was smooth
The transition wasn't as pleasing to me, the new picture passed through the old one
Doesn't have reflections
Xceed Cardflow 3D
Commercial (professional edition only)
Animation was smooth, if you went quickly it would show blank cards speeding by and then fade in the actual data on the cards when you slowed down
Supports flipping the selected item, like in iTunes
Has reflections
ElementFlow control is inside the codeplex project called FluidKit - can be downloaded from here
For more details about the control - ElementFlow control at Pavan's blog
Mindscape now provide a commercial WPF Coverflow control as part of their WPF Elements control pack that might be useful also.
http://www.telerik.com/products/wpf/carousel.aspx
http://www.devexpress.com/Products/NET/Controls/WPF/Carousel/dependency_properties.xml
Both of these are FAR more versatile than your average cover flow clone (though they can easily just do that too if you want). I'd recommend Telerik well above DevExpress as WPF is still a relatively immature technology and DevExpress are very poor at keeping up with the tech game (they only JUST released a VS2010-supporting version of their DXperience suite despite promising it "just around the corner" since the start of January, while Telerik, ComponentOne etc all keep up with current tech. Not good enough for enterprise).
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.