Blog

“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:

Simplicity is the element of the extraordinary. The first time I saw Telerik Reporting in action I was fascinated on how powerful yet simple this tool API seemed.

This tool offered numerous advantages over other reporting tools in the industry. Yet, I was hesitant due to past experience with products that the end of the day overpromised but mostly under deliver.

Today, I cannot convey enough how wonderful my experience has been with Telerik Reporting. This acquisition has given me the power to create complex reporting software in no time at all. Neither I needed to concern in the development environment; Telerik Reporting plays absolutely well with WPF, Silverlight, ASP.NET MVC and Windows Forms; with every report viewer offering a professional look and amazing modern appeal.

Unlike other tools,the software development experience with Telerik Reporting has been joyful. Developers tend to focus their attention directly to the API when they seek after understanding a development technology. Even in Forums, It is very evident the code centered characteristic of developer that get their hands on this tool for the first time. Nonetheless, Telerik Reporting counts with a powerful design viewer, which provides a fascinating “What You See Is What You Get” (WYSISYG) report generation capabilities.

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.