Conditional Formatting Using RDLC

I recently came across a problem on a report we needed to run that returned either a date or some text. The return value of the data then needed to be colour coded in a traffic light style so that dates in the past were red, dates in the future were Green and dates within the next month were orange. Additionally if the value was set to N/A then the field was to be turned gray.

Looking at the problem it seemed straight forward and I headed straight to the expression field of the color parameter for the column. I entered a switch statement that cast the value to the appropriate type (Date or string) and then attempted to do the logic. This turned into a large dead end as the casting of one type then seemed to not allow any further casts! After a few searches I couldn't find the answer so posted on the MSDN forums. After about 6 months of no answer I had pulled the last of my hair out and had put in a compromised solution.

The problem still nagged at me until I came across using code and shared assemblies in RDLC. To solve the problem I simply put a function into the code block and set the color parameter of the field to the expression. At last, a fix (although really its a workaround as it should have worked in the expression). Here is the function I put in:

 Public Function ColorFormat(ByVal cellValue As Object) As String
  
     Dim cellDate As Date
     Dim cellString As String
  
     cellString = CStr(cellValue)
  
     If Date.TryParse(cellString, cellDate) Then
       If (cellDate < Date.Now.AddMonths(1)) Then
         If (cellDate < Date.Now) Then
           Return "Red"
         Else
           Return "Orange"
         End If
       End If
     Else
       If String.Compare(cellString, "EXPIRED", True) = 0 Then
         Return "Red"
       End If
     End If
  
     Return "Black"
  
   End Function  

The functions in the code block need to be in VB and debugging whilst running is impossible so putting into a shared assembly is the preferred option.

Porting C++ to C#

Over the years I have built up a large portfolio of code in various languages.  A number of the projects I have reused a number of times and ported from one language to another.  Most of the projects are small scale two or three class applications or library's to perform small scale things like path finding libraries or file readers/parsers.  I recently got involved in a project where there was a potential that an old project may help solve some particular aspects of the application.  It turned out that the new project took a different direction but I had a quick look through the old C++ project and looked at building a quick test harness in C#. 

I looked at a number of options to call the old library from C# but the two options I came across ( wrap the C++ class in a COM object or expose the class through DLL exports) would probably take just as long to set up as to port the code.  The original project is around 20 years old and was originally written in C.  It was ported to C++ in 2000 and was highly optimised using pointers and threading.  There was no documentation on the project and although I had used it in a black box way for around 2 years I had never fully understood the internals.  Therefore, porting the project would also give me the opportunity to delve into the internals and check out exactly what it was doing.

The C++ project had about 8-10 classes and a few structures that needed to be converted.  In the past when I have ported projects I have gone for the big bang approach of copying the files into a new project and then tackling each class at a time.  The problem with the approach is that you soon become bogged down in errors and often you lose sight of the overall structure of the code.  There is basically no going back with this approach as it will not compile until everything has been tackled. With this in mind I went for a more evolutionary approach.  For this latest conversion I reverse engineered the C++ code into Enterprise Architect which gave me a good understanding of the structure and also enabled me to generate a skeleton C# project. 

Once I had the skeleton in place I tackled each class in turn starting with outer objects in the structure.  This enabled me to always have code that compiled after each class had been converted and I could also document each class at a time. 

The main problems I found when porting were relatively simple fixes.  The most difficult decisions came when working out whether pointers were pointing to objects, arrays or just simple types.  The existing code also use the STL in a number of areas for lists and maps so this was fairly simple to convert using the collections in C#.  The only other problems I had were operator overloading and tackling the threading.

The threading was very simple in that the system spawned a number of threads which ran a single function and then joined the threads after completion.  The thread function contained a critical section to thread safe a global object.  Using the System.threading library and the lock function gave me the threading and critical section so all that was left was the join.  The threads were in an array so I used the following technique:

TimeSpan timeout = new TimeSpan(200*numThreads)

foreach(Thread thread in threads)
{
    DateTime start = DateTime.Now

    if(!thred.Join(timeout))
    {
        throw new TimeoutException();
    }

    timeout -= (DateTime.Now - start);
}

The operator overloading was simple enough once that I found out that the operator needed to be static.

Overall the port went quite well and I was able to port the code fairly quickly.  Using EA to generate the skeleton saved a lot of time and by attacking it in a piecemeal approach was not only simpler to manage it was much better for morale as the problem never got too big.