Jonathan

Jonathan Harding's Blog

Maintaining Table Width with Hidden Columns in SSRS

Sometimes when using SSRS to create documents such as invoices, it is necessary to include columns in a table which may or may not be shown.  Often with these documents layout is very important, and having a table changing width as columns are shown or hidden is unacceptable.  It is not possible in SSRS to give a table a fixed width, but we can use another method to simulate this without having to dig into the RDL file.

We’ll make a report that contains a table made up of 5 columns:

Product
(Static)
Colour
(Variable)
Weight
(Variable)
Delivery Date
(Variable)
Price
(Static)

Columns labelled as ‘static’ are always shown on the report, and those labelled ‘variable’ may be optionally shown or hidden by the user at run-time.  In order to make it appear that the table maintains a constant width when some columns are hidden

Test Data

First we need some test data for out report.  Use the following script to set up a small table and sample data for use in the example:

   1: CREATE TABLE [dbo].[InvoiceProducts]
   2: (   Product         VARCHAR(20) NOT NULL,
   3:     Colour          VARCHAR(10) NOT NULL,
   4:     Weight          NUMERIC(10,2) NOT NULL,
   5:     DeliveryDate    DATETIME NULL,
   6:     Price           NUMERIC(10,2) NOT NULL);
   7:  
   8: INSERT INTO [dbo].[InvoiceProducts] VALUES ('Milk','White',1500,'2013-05-13',1.45);
   9: INSERT INTO [dbo].[InvoiceProducts] VALUES ('Beans','Orange',450,NULL,0.75);
  10: INSERT INTO [dbo].[InvoiceProducts] VALUES ('Eggs','Yellow',500,'2013-06-01',1.75);

Creating the Report

Open Visual Studio and create a new blank SSRS report.  Add a data source connection to the database where you created the InvoiceProducts table, then create a new data set using:

   1: SELECT
   2:     Product
   3:    ,Colour
   4:    ,Weight
   5:    ,DeliveryDate
   6:    ,Price
   7: FROM
   8:     dbo.InvoiceProducts

Add a table to the report body, then map the data set fields to the table in the order of the SELECT statement.  Your table should look like this:

image

Next we need to add parameters to control the visibility on the Colour, Weight and Delivery Date columns.  These should be set to a type of ‘boolean’ with the default value set to true.  Finally, set the visibility on each of the variable columns to be controlled by the parameters you’ve just added.  To do this, left-click into one of the column cells, then right-click on the solid grey bar above the column header.  Select ‘column visibility’, then select the radio button labelled ‘Show or hide based on an expression’.  Click the ‘Fx’ button to bring up the expression editor, then enter an expression like:

   1: =Not(Parameters!ShowColour.Value)

Do this for each of the columns for which we need to control the visibility, using the appropriate parameter for each column.

If we test the report now, firstly with all of our parameters set to ‘true’ we should see all the columns:

image

Now set the ‘Show Colour’ parameter to false and run again.  The column is hidden and the table width is reduced by the column width:

image

To prevent this behaviour and maintain a constant table width, we need to insert and extra blank column for each column that may be conditionally hidden.  In the designer, insert 3 columns to the left of the ‘Colour’ column:

image

By setting the ‘column visibility’ properties of these columns to give the opposite effect to the columns containing our data, we can add a blank column for each data column we hide and thus maintain total table width (given that the widths of a blank column and its corresponding data column are the same).  Starting with the left-most blank column, set the column visibility property to:

   1: =Parameters!ShowColour.Value

Set the other blank columns visibility using the parameters for weight and delivery date.  The effect is the when one of the parameters is set to ‘false’ (i.e. do not show the column), the data column will be hidden, but a blank column of the same width will be shown.  With suitable formatting, this will be invisible to the end user and will give the impression that the table width stays the same.  Below shows the report with all columns showing, and then with the colour column hidden:

image image

You could merge the ‘Product’ data cells with the blank cells between it and the ‘Colour’ data cells and this would allow the product data to expand to fill the blank column.  As far as the end user is concerned, the product column has simply gotten wider.

Conclusion

For occasions when precision layout is important, maintaining the width of a table that contains optionally hidden columns may be necessary.  Using the method outlined in this post, I have shown how it is relatively easy to achieve this using standard SSRS components and simple expressions.  This is a much more sustainable solution than editing the RDL of a report at run-time!

Differences between Regular SSRS and SSRS for Dynamics AX 2012

I’ve spent quite a long time recently developing SSRS reports for Dynamics AX 2012.  In a change from AX 2009, the newer version now uses SSRS as it’s main reporting engine.  No doubt this is so that business with existing experience in the MS SQL stack can get on creating reports for their new AX 2012 installation without the need for re-training or bringing in extra people trained in X++.

So not a bad idea, however my experience has turned up a number of important differences between standard SSRS reports and those in Dynamics AX:

  • Placement of Report Code

In Dynamics AX 2012 SSRS reports you cannot use the code window found by going to the report properties.  The window is still there, and you can still type into it, but as soon as you build the report in AX the code will be stripped out of the report.  This is because when you build a report design within a Dynamics AX report model in Visual Studio, the process adds a custom code block to the report XML (a method to overwrite the report OnInit() method).  This wipes out any code you may have added.

Instead, you must add code as a new Data Method in the report model.  This can then be referenced in your report design like this: =MyMethod(arg1)

  • No ‘ResetPageNumbers’ Property on PageBreak

A great addition to SSRS 2008 was the ability to reset the page number global based on groups within your report.  This was handled by a property found by expanding out the ‘PageBreak’ property for the group.  Unfortunately this option does not exist in SSRS for Dynamics AX 2012.  There may be a good reason for this, and if anyone knows it please let me know!

To get around this I added a data method which keeps track of which group my report is on as it renders and resets the page number appropriately.

  • Conditionally Hidden Elements cause ConsumeContainerWhitespace Property to Fail

Suppose I have a one-page report that should fit onto an A4 page.  The report contains a data table and another section, which should appear at the bottom of the page regardless of the number of rows in the table.

whitespaceexample

To do this, I enclose the data table in a rectangle element which is sized such that the ‘bottom section’ is at the bottom of the page.  By setting the report property ‘consumecontainerwhitespace’ to true, I ensure that as the table grows it fills up it’s containing rectangle, but the ‘bottom section’ stays where it is.

This example would also work in AX, unless you place an element in the rectangle which can be conditionally hidden.  For example I may have a row in the table which should only be shown in certain conditions.  In standard SSRS, the report would continue to function as before, with the table consuming the rectangle and the rectangle staying the same size.  In AX however, the addition of the hidden row causes this behaviour to break and that rectangle to grow as rows are added to the table.

A workaround for this is to make the optional row ‘invisible’ by shrinking it and/or making the text and borders white so they don’t show up.