Translate

Tuesday, 15 July 2014

Publishing a post using the Google API for Blogger!

It is not as easy as many have posted on the web! Many posts indicate that all you need to do

is send in your credentials to the service object. Not as simple as that !

Blogger API Post


This post was created with the Blogger API v3

Tuesday, 17 June 2014

Two singularly complex problems - Arrays and Lists

The delightful aspect of programming in C# is the large number of possibilities, to resolve a problem, available to a programmer in the form of different forms of implementations across versions of the underlying technology and framework.

It is delightful because two different programmers may provide a solution to the same problem, without differing in technique, because the implementation of the same language feature across the different versions of the C# language compiler are different.

It can be torrid, though, if you do not enjoy the intricacies of working with different types in the CLR and/or the underlying unmanaged types of the Windows platform.

1. Unmanaged array - the 'mysterious' object[*]

The Microsoft.Office.Interop,Excel Chart object presents a challenge in the way it exposes the Chart's series collection's data values.

For instance, if you want to read the Chart's Source Data range/Data Table, the problem is in the way the series collection exposes each series' data values. Being a System.ComObject, the series.Values (that represent each Chart Series values) returns an unmanaged array !! What is so surprising, you may ask?

The surprise is that you may convert it to an object array but may inadvertently leave out testing it as it will compile ok. At runtime, though, an error that an object of type [,] cannot be converted to an object of type [] will be thrown!

The exasperating aspect of this error has to be experienced to really appreciate the nature of the error !!

The reason it is exasperating is because you may try creating an Array with CreateInstance and while it should work, at a glance,

var array = System.Array.CreateInstance(
                            typeof(object),
                            new int[] { totalColumns },
                            new int[] { totalRows });
array = series.Values;

it does not !

The solution is to iterate through the series.Values as below:

// --- 1. Get ChartObjects in worksheet
//-- 2. iterate through the chart object's series collection

foreach (object seriesValue in series.Values as System.Array)
{
double d = (double)seriesValue;
list.Add(d);
}

The trick is to convert the unmanaged array values into an array while iterating through it !

Best Practice
3. If you are using a System.ComObject in a for... or foreach... loop make sure to release the COM object with Marshal.ReleaseComObject in the System.Runtime.Interopservices namespace in the finally block of a try...catch as below:

foreach (..... ComObject in ...){
try{
....
}
catch{}
finally{
if (object!=null)
Marshal.ReleaseComObject.(...);
}
}

Remember, you cannot set a ComObject used in a loop to null ! A runtime exception will be thrown if you attempt to do so.


2. Compare two Lists or Arrays

The option to obtain the iterated value into an array or a list is as per your requirement.

In both the cases, you may want to work with both the array or the list. 

Below are two techniques to compare, using, first, the TrueForAll Linq method (make sure to add the System.Linq namespace) as below.

                            var list = new System.Collections.Generic.List();
                            var list1 = new System.Collections.Generic.List();

                                            if (list.TrueForAll(list1.Contains) && list1.TrueForAll(list.Contains))
                                            // --

Or, convert the array into a List and use the System.Array's SequenceEqual check for an array,

object[] rangeValueArray = (from item in list select item as object).ToArray();
object[] seriesValueArray = (from item in list1 select item as object).ToArray();

if (rangeValueArray.SequenceEqual(seriesValueArray))
// --
else if (!rangeValueArray.SequenceEqual(seriesValueArray))
// --

This method helps check if the elements are equal plus in sequence !

Thursday, 15 May 2014

Logic or laundry list?

Just as a person with a good understanding of English and nodding in understanding , when told that "E is equal to MC square", does not make for a genius, similarly, piling up a list of 'permutations and combinations' does not make for good application of logic.

Below is such an example that I came across recently.

A file being opened from a Open Dialog box, of the same name and from within the same file.



I have seen some teams go into a frenzy of analysis over such a simple use-case of "Open a file" and believe it to be a thorough analysis whereas, it is the classic example of "over-kill", "over-analysis" (similar to it in normal life is what is called "Beating about the bush"), where a person uses a crane to pick up a bucket just because, being an Engineer, the 'world' (a collection of people hardly numbering above two digits) would be agreeable to the idea.

There are some fine boundaries that define every field of study, and logic, due to the increase in population, has become multi-layered for some types of people (maybe due to lack of maturity, knowledge or clarity in attitude and approach towards life) but that does not in anyway redefine the application of logic.

Even if "a 'kid' can program nowadays" adage may be true but the fact remains that the many other 'layers' in the above example, like education, training, time, context and many etcs that come before it will make a difference in either speeding up the "kid's" application of logic or in becoming a totally useless application of a  'laundry list' of scenarios that may just affect the design, performance, speed and security of the program logic!!

So, what then is 'solid logic' in today's world?

Nothing.

Only that logic that stands up to tests and succeeds, is 'logical'.

Not the knowledge of operators or all that computer science nonsense jargon but simply, tests.

Not tests as 'software testers' believe tests to be but tests that have a conceptualization point before any implementation of logic - what is called Tests Driven - Development or Design.

What makes this (TDD) the most workable technique is because of the multi-layers that the external world imposes on an use-case even before it reaches a design table.

It is like trimming and sprucing a problem to find what is the real problem that needs to be solved because unless you know what the real problem is, will you not simply be 'beating about the bush' ? :)