Image editing .NET component. - winforms

I have created an app using SQL Server 2008 database where has Image datatype field in couple of tables. What the user needs is some simple image editing (strike a line, or measure with a ruler some distance, comment something into the picture).
So something like that to happen it needs I suppose a .NET Image Editing component.
Do you know any free stuff out there making this job? or else could check any commercial
products too.
Of course the job should happen inside my own application. (Or I can have your opinion)
Thank you.

Related

How to navigate between WPF and WinForms

I'm new to visual basic and i'm currently trying - and at the moment I've done my entire program using WPF's because I wanted to easily switch through different pages which i've hosted in a single window. Well I've come to a halt because I'm creating a page currently where a customer can enter their information and add it a data base.
Now, I have little experience in coding in visual basic(self taught for 2-3 weeks) and I have no clue how I would go about adding a database, and adding to the data base using WPF's. I have seen some examples of people adding a database, and adding to a data base using Forms.
I was curious if I am able to using WPF's(page) for most of my program, and then switch to a Form when I want to add the customer to a database, then switch back to a WPF(page)?
Yes you can...
If your main project is WPF you need WindowsFormsHost and if your main project is WinForm you need ElementHost. For more information you can read this tutorial.

Any alternative report designers other than the traditional "banded" styles?

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.

Automatic form generation software

I'm using winforms. I spend a lot of time drawing forms (maybe not a lot, but it is a boring task).
To sum up... I want to develop a simple aplication that connect to a sql server database, let the user to select a table, and put the controls in a form for me (generate the designer code), based on the tipe of each column. Then my app will name each control like the column of the table, set the maxlengh property (if the type is varchar), and create a label with the same text near the control. If the column is a FK, then the app will draw a combobox and so on. I saw that Telerik Open ORM make something like this, but I only need a simple app for the IU Generation.
If the same day I finish my little application I discover a tool that make the same... I will feel myself stupid :D
Are there any tool out there that do this work for me?
You can just drag DB columns from the Server Panel and drop them on the Form. This will generate TextField, CheckBoxes and other UI elements for you.
You can also drag the entire table and drop it on the form. Same thing will happen: all fields will get generated.
This is using plan Visual Studio 2008 IDE.
Take a look at DevExpress - they have a number of ways to do exactly this. (We're a happy user of their product.)
Take a look at Microsoft lightswitch. I had posted a similar question as yours and stumbled upon it by accident. Devexpress also has an orm like Teleriks http://www.devexpress.com/Products/Index/Frameworks.xml. I am using Lightswitch for form gen. good luck

Hosting a bare-bones XAML editor in my application?

In our application, we allow administrators of an install to design templates for name tags that are printed when they check-in from a kiosk (sort of like checking in for a flight at a kiosk and printing out a boarding pass).
For example, the template might look something like this:
[FirstName] [LastName]
[Company]
[PersonImage]
[BarCode]
Right now, we use Reporting Services to allow our administrators to design templates for name tags (some might want a picture of the person, a bar code printed out, name of their organization, etc). This works ok, but 1) Reporting Services is slow to render and 2) it's not integrated with our application very well -- they have to load up Visual Studio and design the name tag outside of our application.
XAML seems like a good fit for designing the template for name tags. Virtually any design could be handled with the format and we could use XAML to XPS to print.
The problem I'm seeing is how to integrate a visual designer that uses a subset of available XAML controls. We'd really only need simple controls such as Canvas, Grid, TextBlock, Image, etc with drag/drop support. I'm not finding much info on whether or not it's possible to host Visual Studio or Sparkle's XAML designer into a separate application. Anyone have any ideas? The RichTextBox looks like it would almost work, but a FlowDocument isn't really want we're wanting. We need to be able to drag items around and absolutely position them (like in a report designer).
I'm not sure whether you can host the MS designer/s (although I doubt it), but I think you might be able to produce your own mini-editor fairly simply. Start with a Canvas and programmatically add Labels, TextBlocks or whatever else you want (wire them up with Click handlers to move them around via Canvas.Top/Canvas.Left). You can render the Canvas to an image fairly easily for printing, or Xaml-Xps as you mentioned.
Check out Kaxaml as an example of someone who has already whipped up a mini Xaml editor (it was recently updated to SL2). There may be others out there as well.
EDIT 26-Jan-09: also check out Charles Petzold's XamlCruncher (example) - certainly beats loading up Visual Studio - seems like XamlReader.Load might be worth trying out?

What's the best approach to printing/reporting from WPF? [closed]

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/

Resources