I would like to generate an invoice and print it in the background (without being showed to the user of the application),once the cashier has received the cash from the customer.
I don't know how to do that in WPF,i tried to create a user control and pass the needed objects and bind it to a DataGrid control into this user control and print it.
Someone suggested to use Crystal Report and pass a parameter then generate the invoice and print it,but i don't know how to do that technically.
Thanks in advance
In WPF you have many possibilities:
Printing via XPS, look here for more information. It's really flexible and powerfull but also a little complex. Here you will find a short example.
Create a FlowDocument and print out this. This way is more simple, has a lot of features and also gives you good print quality. However it has a specific goal: Support of flowing documents. Therefore it's not always the best choice because of formatting limitations.
A very simple possibility to use PrintDialog.PrintVisual. With this you can print out quickly the contents of a visual. This is good for a simple solution but very limitted.
Use a reporting tool such as Microsoft Report Viewer. You can use it also from WPF and it is very powerfull and free. Take care, there are many different versions out there. I would use the newest one (V3). This is the version VS2010 has an integrated designer.
All these ways can be used to print out without direct user-interaction.
You have written: I don't know how to do that in WPF,i tried to create a user control and pass the needed objects and bind it to a DataGrid control into this user control and print it.. To see how the result becomes, take the PrintDialog.PrintVisual-method, it seems you also have all you need and then you will see if it fits your needs. Otherwise choose one of the other technologies.
For creating nice formatted print-documents, I would propose to use a reporting technology, because of the flexibility they provide. You can do it also in XPS but in general, this is much more work (the more complex the layout becomes) and is also less supportable. However, it's also an effort to learn and embedd the reporting technology into your app.
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've been searching the web for over 2 days now for a good and easy to use something to print reports from a WPF application.
I've been trying to use the DocumentViewer but it's a pain to add Controls to it and style them. Is it me or can this only be done in code behind and how can a grid over multiple pages dynamically be generated?
Second I found the control FlowDocumentReader. This looks like an interesting thing since you can add Tables which are much easier to style and I was able to do this in xaml. Unfortunately, I have no clue how to print from it. I tried to edit the template of the reader but without success.
Last I found this post (What's the best approach to printing/reporting from WPF?) but it's dated to 2008 so I'm not sure if the information is still accurate.
My conclusion is that it is pretty hard to get a nice looking report printed from WPF without writing lots of code behind or editing templates which (by me) fail to do what I want.
So my question is, is there any good approach to my problem? I'm really bothered that I lost this much time for something that I thought was so trivial to do.
I was wonder, what about this guy's approach: https://stackoverflow.com/questions/17647939/how-do-we-handle-different-printing-needs-by-using-fixeddocument?rq=1?
Crystal Reports is indeed a good choice for complicated reports but if your reports will be simple in design I'll recommend using CodeReason reports, it's an xaml based reports. Too bad it's not updated anymore but it's really easy to use for simple reports.
For more information: http://wpfreports.codeplex.com/
When I think of reports I think of banded reporting. Tools like Microsoft Access, Crystal Reports, SSRS and even VisualFox use this. Dynamic behavior must be anticipated in advance and is controlled through conditional fields, subreports and parameters. These reports are perfect for financial reports or lists of things where anytime you run this (typically between some date range) the look and feel is predetermined and expected by the user.
However our company requires a solution where any user should be able to change any aspects of the report. Fields, formatting and layout are all changed anytime a report is run. It's not a traditional "report" if you will since it's not a somewhat static output.
Resorting to banded reporting in this case would banish some developers to the world of crystal reports since we generate 2-6 reports on any given day. I can't imagine a typical user being happy with having to learn how to use crystal report designer either.
What are some alternative reporting solutions that allow you to build reports without being at the whim of learning an entire reporting suite such as Crystal Reports? I've added an answer of my own to show a great alternative that we're currently using and hope to get some good input for future use. The point of this post however is to collect some alternative solutions to the one proposed.
DevExpress Snap
With some digging we discovered DevExpress Snap which allows you to build reports using a Word Processor much like Microsoft Word by dragging fields from a fields toolbox right into the document! It feels exactly like Microsoft Word with data field drag and drop capabilities. Fantastic!
We've already created a Template structure so users can save their predetermined layouts as "general" templates to start work off of but nearly every report generated contains different fields and formatting. Sometimes even images are dropped into the document to illustrate a point.
Now I don't have to be banished to the land of SSRS! This is an amazing solution though I still generate certain reports (P&L for example) through SSRS since it should be a pre-set reporting style, with it's fields and design locked away from the user.
The other solution I found that looks pretty powerful and easy to use is Windward Autotag. It's an actual plug-in for Word that just adds an extra tab at the top of the ribbon for all your report options. So you can literally design all your reports right in Word. You put your data wherever you want by going to the Autotag tab added to the ribbon and clicking a button to insert your data where you want it. I haven't tried it yet, but the website and demo video look pretty impressive.
I've been playing with WPF for some months now, and I quite like it.
But one of the things I don't get is why MS doesn't put a little more effort in helping developers by supplying basic controls, and I need to get this off my chest :)
For example, I figure most applications somewhere will need to let you edit some properties - for configuration or whatever.
What would be the most used types in a proprety-grid editor ?
text
numbers (byte, float/double, int, etc)
colors
....etc.
So why isn't there even something as simple as a control to edit numbers ? Like a generic NumericUpDown control that allows you to type in numbers (no text, no pasting invalid input) or spin them up/down according to some given rules (decimal, floating point, min/maxvalue) ?
Why isn't there a generic colorpicker, so people get the same user-experience in every application ?
Why isn't there a standard implementation of a SearchTextBox, a BreadCrumb-control, or all these other standard control types users have gotten accustomed to the last 10 years ?
(..but at least they DID have the time to implement a generic splashscreen - because everyone knows that greatly increases user-productivity....)
The well-known ideal is always to give people the same user-experience over different applications. So even if some of those controls would be easy to make - it would be preferred to have one version over different applications.
I see people all over the internet trying to do the same stuff over and over again.
Okay, so MS started a WPF Toolkit project on Codeplex that tries to implement some controls, but only did so half-heartedly and is completely dead by now (last update of the roadmap dates back to Mar 21 2009).
The result of this is that a lot of people starting a WPF-project end up spending a lot of time on trying to figure out how to create some generic controls and get really frustrated.
Wasn't the mantra "Developers, developers, developers!" ..?
/Rant
Because its ridiculously easy to make these in WPF. With WPF and silverlight microsoft's focus is on a core framework that makes many tasks (such as stylable controls) dead simple. Tools are more important than prebuilt controls. They are focusing on the NEXT thing rather than a better Winforms.
I think Microsoft - and some people responding here - are forgetting about the most important part of this post :
"The well-known ideal is always to give people the same user-experience over different applications. So even if some of those controls would be easy to make - it would be preferred to have one version over different applications"
Just Google Image Search on "WPF Color Picker" ( http://www.google.nl/images?q=wpf+color+picker ) and you'll see this idea go down the drain.
That's exactly what i thought at the beginning with WPF..
But afterall, a NumericUpDown is easily created with a cutom usercontrol, same for all the controls you will ever need, you can create it by yourself in (almost) no time, or grab some implementation googling around, and then you can still customize
I think they provided the very basic implementations for the UI elements and leaved all the custom stuff to developers and who need custom stuff, if they would have done a generic color picker, maybe it wouldn't have had all the functionalities that anyone would ever need
There are a lot of 3rd party vendors out there that provide powerful custom controls (editor, navigation, grids, menus, property grids, ...).
It's - in general - cheaper to buy from them than to rewrite your own (when it fits your need of course).
Historically, Microsoft has always encouraged a rich "component-based" eco-system around what they provider out-of-the-box features. This has been true from the beginning of component programming (VBX, OCX, ...) with Microsoft technology. This is arguable, but that's the strategy :-)
I`m working in a serial terminal project developed in VB.NET.
I need to display a lot of formatted (color, font styles) text data in a read-only control (the incoming serial data).
I don`t know if it's a good idea to use richtext control or a grid, or there's a better third party control?
Thanks
I've used Scintilla.NET for this sort of thing before: http://scintillanet.codeplex.com/
It's designed for use in text editors, but it can be made read-only, and it's pretty quick even for large quantities of text. You get efficient per-character control over colours and basic text styling, though not to the same extent as the Rich Edit control.
Negative points are that it's based on a control designed for use from C++ code, so there's not much in the way of .NET-specific documentation. And the .NET code is in C#, so it's probably best if you have a passing familiarity with that.
I think the RichTextBox would be a good place to start since it's included and then you could upgrade to a 3rd party control if you hit any limitations (I'm assuming that cost is important).
Please note though that it can be a bit slow at colouring text depending on the method used. This article shows a supposedly (I haven't tried it) faster way of doing it:
http://codebetter.com/blogs/patricksmacchia/archive/2008/07/07/some-richtextbox-tricks.aspx