Loading, please wait.
In the following example we revisited the sample project where we created a Chart Object with Telerik Reporting at runtime. Every time I create Chart objects at design time, I find myself going under the hood in one way or the other, this to enhance customization. Needless to say, I am not stating that design time does not enable us for customization. However, I rather enjoy going directly to the API. My perception is that in instances this might be a faster route.
Again with some Telerik Reporting goodies. If you observe my previous post, you would notice that Telerik Reporting is not only my favorite reporting tool but also one of my favorite .NET libraries to work with. This time I write to unveil one additional solution that may not be consider one of the most intuitive or yet most proximate.
Telerik Reporting provides the ability to implement conditional formation in a global level but also in a singular level at a report item. In writing several reports, I have had to introduce numerous formatting rules. Very seldom one rule would apply for the whole report.
“Today I Shed my Old Skin” - Og Mandino. This statement introduces the first scroll defined in one of the most compelling books I have ever red, The Greatest Salesman in the World. It has also been said - “There ought to be a better way.” I love this statement because at times it becomes the principle for moving us forward.
Representing time in a linear axis is a very ancient exercise; even more ancient that the conception of the Cartesian plane. Linear representation of time, indisputably, will continue to be an indispensable tradition in the illustration of change.
In programming, it is a habit to use OLE Automation Date (OADate), a numerical representation of time, in order to talk to the richest APIs and bring about the graphical representation of time. The approach has been adequate and successful at times, yet in instances it has lacked the flexibility that the representation of time inheritably has by nature.
“Today I shed my old Skin.” And I introduced a slight different approach to the OADate when dealing with time and time reference. This approach consists of time indexing, or the representation of time through simple integer unit.
The first time I was introduced to iBook, I was far from embracing this whole new reading concept.
I have yet the vivid memory of my parent quoting Spanish philosopher Marcelino Mendez y Pelayo – “Que lastima tenerme que morir, cuando me queda tanto por leer” It translates “It Is a shame I have to die, with so many books yet to read”
I cannot avoid wondering whether Mendez y Pelayo would have welcome iBooks, and sacrifice the touch of the paper fiber at the tips of his hands with ease.
Despite early hesitations of the community to give up the millenary art of flipping a page, Book-Like interfaces have been able to engage audiences in a very profound way.
This is an area of a lot of question and hassle. During the Telerik Reporting Webinar for Quarter 2, 2012. One of the areas of inquiries was the use of Telerik Reporting with MVVM pattern.
It is possible you would find yourself in a scenario of implementing Telerik Reporting into an existing MVVM project. It is also possible that the requirements of this project consist of avoiding changes to the existing WPF views. The views may play a very important role in generating the report data. Below I provided a brief strategy for bringing Telerik Reporting and MVVM pattern together, when feeding a report from an existing view is necessary.
Best practice is to create the Report in a class library, this practice apply even when producing reports for MVVM pattern. The only key variation is to create a constructor capable of receiving the report parameters or objects needed for the report to render, i.e:
Jim Rohn stated “Don’t wish it were easier, wish you were better.” Yet, I find myself resilient in desiring for things not only to be easier but also for them to be enjoyable. It is not my goal to challenge Jim Rohn wisdom, however, I believe I will adopt a similar principle “Don’t wish it were easier, wish it be enjoyable.”
In my pilgrimage as a software developer I find excitement when stumbling upon an Application Programming Interface (API) that make application development fun and enjoyable. In a previous post, I had the opportunity to show a brief task of creating a Telerik Report table. In this post, I take on a chart creation at run time. This area is one of the most enjoyable of the Teleirk Repoting API.
Like in any charting API available, it is imperative to understand the objects or components that bring about a chart object. In the section below, I attempt to explain a few chart components, although, within the context of the Telerik Report API. Understanding these will save up a substantial amount of time, this principle holds true for any API we may encounter.