Report designer

From the get go people have asked us how to get the data of an ECO-based system on to paper. We always said “like you would if you did not use ECO”. Then last year I wrote about the Xaml approach to define printed document here.

Today I will write about what a model driven report designer – much like crystal reports designer – might look like.

The report designer is in its first iteration and I want feedback on what the most important enhancements might be.

The model for this example:

 

Quickly whip together some viewmodels to show the data:

And since an average human life is just around 80 years we hurry along and create some default actions:

And that is enough for us to get WECPOF running to help us create some data:

And at this point it might come in handy to be able to print an invoice… And that is what this post is all about.

The Report

We create yet another viewmodel that is not intended to define a UI, it is just for data-provisioning:

Then we go to the ModlrTree and right click the new node “Reports”, add a Report:

Click open the new Report:

Choose the Report you want to change in the Combo, Click Change ViewModel to show the ViewModel Picker – Pick VMInvoice – The designer is populated with the data definition from the ViewModel.

Depending on the nesting level in your ViewModel, the number of Report Bands that are available will change.

For the root level you only get ReportHeader and ReportFooter – and data from the root level will only be draggable to these bands – and the next nesting levels headers and footers.

For the first nesting level you get a BandHeader, a BandRepeatingHeader (A header that is repeated for each page that content data occupies), a Content-Band and a BandFooter. Data from this nesting level will only be draggable to the Content-Band and – if there is a sub nesting – the sub nestings header and footer.

Ok – that might all sound very confusing – but think about it for a bit (or just use it – remember “80 years time limit”) and you will probably reach the same conclusion as we did – this is the way a report designer should work.

Now you can just drag columns to the bands – you will get a NO-DROP icon if it is not possible to drop that data on that particular band.

We are far from done, but still at least I want to see how it looks before investing more time in the report definition.

Ok – how do we do that you might ask?

The Action editor has been extended:

So I can just create a “Class Action” on Invoice, set BringUpViewModel to VMInvoice – and since VMInvoice is used by a Report – a new combobox lights up “Optional Report” – I pick the report I have been working on – I state that the RootObject for the ViewModel is “self” from the class action. And I hit run:

WECPOF again:

… well it seems to work, the images are to far to the right, everything looks plain and boring, no headers to explain what we see… But all in all we got what we asked for…

Headers and other static content

In the report designer, right click a band and choose the “Add static content”:

You get a new square on the report band, right click it and choose “Edit static content”

This is a flowdoc editor so you can do a lot of things – I have not spent enough time on the controls at the top – but you can paste in stuff from word or what have you…

So after a little fiddling:

And back to WECPOF:

Ok, better, but even if we can style the static text – the data still looks to plain and un-stylish…

Styling the data

So we need to apply style to our data.

Look at the bottom of the ReportDesigner:

Here you see a combobox with the skin-xaml-style-dictionaries that we load from here: C:\Program Files (x86)\CapableObjects\ECO\6.0\config\Styles (Could be AppComplete if you do not have ECO installed).

This file is a standard WPF resource dictionary.

Create styles and give them names like this:

 

The Name.ComponentType notation comes from us – it is just smart to be able to use the same name of a style “Style1x” for different components “TextBlock, Image, RichTextBox”.

A WPF style can set any dependency property so you can do A LOT of changes to the display by applying a style – the internet is full of explanations on what you can do with WPF styles so I will not dwell on that.

So you flip the Style combo to the resource dictionary you want to use, and then you can set the StyleRef attribute of individual items placed on the bands:

And then in WECPOF – if you use the same ResourceDictionary:

Printing it:

Adding more data:

Ok, maybe you did not want the “Pay or Die” logo on both pages – The ReportHeader and ReportFooter is repeated on every page. So if you only want the logo on the first page – just design it in the first BandHeader (not the BandRepeatingHeader).

Puh… Pretty cool? Imagine visiting a client, Reverse a database, Defines ViewModels, Create Reports, and print stuff from that database…

Oh – and no, you need not run WECPOF to use this – it is just a convenient way to get things done – don’t you think?