February 25, 2009 at 11:46 pm
Comments posted to this topic are about the item Add Styles to Your Reporting Services Reports
February 26, 2009 at 1:32 am
There is another way to apply "styles" to a report - by storing the report attributes, such as colour, in a database table and then retrieving them in a data set - either together with the data or just as a separate data set. Then you can either use them directly as Fields collection items or by creating parameters, which can be used in any report element regardless of the data set assigned to it. This overcomes some of the limitations that are listed in the article.
February 26, 2009 at 1:51 am
I've never tried this but woulndt it be possible to have Custom Code refering to a external stylesheet that coult be used by multiple reports?
February 26, 2009 at 2:16 am
Indeed - and this is the subject of the next article in this series, which should be out next week!
February 26, 2009 at 4:07 am
I have added all the custom code functions onto an external class and simply reference the class on all my reports and use whatever function I need, if changes are required I simply change and recomplie the function...
Quite useful for standard stuff such as Date format, company colours and so on....
February 26, 2009 at 4:31 am
Absolutely - this makes centralising styles really easy - and is handled in the third article in the series (where you will see how to add these classes to templates too)!
February 26, 2009 at 5:11 am
Boyan Penev (2/26/2009)
There is another way to apply "styles" to a report - by storing the report attributes, such as colour, in a database table and then retrieving them in a data set - either together with the data or just as a separate data set. Then you can either use them directly as Fields collection items or by creating parameters, which can be used in any report element regardless of the data set assigned to it. This overcomes some of the limitations that are listed in the article.
I was just about to post with the very same thing!
Storing as much of the style properties in a database as possible... then styles can be updated without having to republish any reports
February 26, 2009 at 5:46 am
Thanks to both of you for this one - this is a very good idea that I have not covered it in this way in the following articles so would one of you like to post this as an addition to this "mini-series" to extend the tips and techniques offered?
February 26, 2009 at 7:05 am
Nice article - nothing revolutionary, just good relevant practical advice on making life easier. Look forward to the next installments.
David McKinney.
February 26, 2009 at 7:08 am
Adam Aspin (2/26/2009)
Thanks to both of you for this one - this is a very good idea that I have not covered it in this way in the following articles so would one of you like to post this as an addition to this "mini-series" to extend the tips and techniques offered?
I've not put it into action yet.
Coincidently It was yesterday when I was looking at methods of maintaining consistant colouring when using graphs. I ended up creating some tables and associating colours with categories so when several graphs/charts are on the same report the same category e.g. "bikes" will always be shown using the same colour e.g. "red". Then one legend can be used for several charts.
The concept should be farly easy to extend to other report properties.
Image locations for branding
fonts, font colors, weights etc... for consistant titleing
colour schemes
The final adaptation ties in with using dynamic colours for graphs i.e. using hex values rather than the names for the colours.
Doing it this way gives an option for starting with a base colour - defined as a hex value, then adding or subtracting to the RGB components to give a spread of colours from the base colour
PS. If you're benched at the moment then you've probably got a lot more time than me to work on an article 😉
February 26, 2009 at 7:10 am
This is a good approach but I think that taking the styles into a stored proc or data base for that matter and then using them in the report is a better option. That way the maintenance become much more easier because you just have to alter the SP rather than opening each report in BIDS and changing it. 🙂
February 26, 2009 at 8:25 am
Hey, this is great stuff! I eagerly await the articles on using an external stylesheet and also using styles values stored in the DB.
Thank you so much for these ideas!
February 26, 2009 at 8:49 am
Thanks for the info. I applied it to an RDL template I created and saved. One other drawback however is that you can't visibly see the colors from the layout view...which when you have a lot going on in a layout can be confusing (you always have to preview to ensure you have everything. I'll continue working with this for my borders colors and styles which, in my world, are more cumbersome.
February 26, 2009 at 9:57 am
I find that it works better to put my key/value pairs into a resx file and then reference the resource key to get the desired colour. This way it's easier to manage your styles and they can be properly localized. Defining your colours in code seems kind of awkward.
February 26, 2009 at 2:23 pm
Sure, I wouldn't mind doing it. It would allow report authors to choose the method that suits them better. I will send you a draft when I am ready.
Viewing 15 posts - 1 through 15 (of 45 total)
You must be logged in to reply to this topic. Login to reply